From nobody Mon Feb 1 01:44:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4492E1B2F56 for ; Mon, 1 Feb 2016 01:44:57 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_QUOTING=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 P9Y7kRrbVeEG for ; Mon, 1 Feb 2016 01:44: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 BD12B1B2F38 for ; Mon, 1 Feb 2016 01:44:55 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id D64901AE00B6; Mon, 1 Feb 2016 10:44:53 +0100 (CET) Date: Mon, 01 Feb 2016 10:44:57 +0100 (CET) Message-Id: <20160201.104457.34946886097331906.mbj@tail-f.com> To: andy@yumaworks.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] 2 YANG 1.1 questions 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, 01 Feb 2016 09:44:57 -0000 Andy Bierman wrote: > Hi, > > > 1) leafref with a default-stmt > > list int { > key "name type"; > leaf name { type string; } > leaf type { type string; } > leaf enabled { type boolean; } > } > > typedef lref1 { > type leafref { path "/int/name"; } > default "t0"; > } > > This has the save effect as top-level mandatory nodes. > The require-instance is 'true' so the YANG validation will fail > at boot-time unless a list 'int' entry name is 't0'. > > I plan to add a YANG usage guide not to give configuration > leafref nodes a default value. Any objections or another plan? I think this is a good idea. I suggest the same recommendation for instance-identifiers. > 2) instance-identifier encoding for key type 'empty'. > > list int2 { > key "test test2"; > leaf test { type empty; } > leaf test2 { type empty; } > leaf type { type string; } > } > > Now that the empty type is allowed for a key leaf, > the and any instance-identifier type needs to > have encoding rules defined. (e.g. an instance of /int2/type) Good catch, this needs to be clarified. Since the i-i is a XPath, and we don't want to change the underlying syntax of an i-i, we need to do: /x:int2[x:test=""][x:test2=""] This can be used directly in e.g. an XPath filter to return the correct node, if it exists. I suggest we do this change to the second paragraph of 9.13, and add an example to 9.13.4: OLD: For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. NEW: For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. If a key is of type "empty", it is represented as a zero-length string (""). New example: /* instance-identifier for a list entry where the second key ("enabled") is of type empty */ /ex:system/ex:service[ex:name='foo'][ex:enabled=''] /martin From nobody Mon Feb 1 03:52:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009D81B3138 for ; Mon, 1 Feb 2016 03:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 0Kif_SE8xN2W for ; Mon, 1 Feb 2016 03:52:25 -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 8E79F1B3135 for ; Mon, 1 Feb 2016 03:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34708; q=dns/txt; s=iport; t=1454327545; x=1455537145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rF0H9o+du008HXDzGwJlx2313RiqEr7Qjpx0+Tn3kwQ=; b=Zv0sFME4BgF1m4Dva482HCvlZvbNJCYLkDxr3iCVRAou3hu6UiLZ0uOv 4cGpHbZ2epixE3BPYftFZhBtOEc680e4yJSlJZPJhpflLo9OOnIMt4r2X Z7VMDk8B0eAEaMCmm2D+/vEyKDHsBiXIInlAE4y8PHgwyXMiQKOh//fZv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQD4Ra9W/5RdJa1TCoJuTFJtBohSs?= =?us-ascii?q?VoBDYFjGAEJhSNKAhyBFzgUAQEBAQEBAYEKhEIBAQQBAQEgSwsQAgEIDioBBgM?= =?us-ascii?q?CAgIfBgsUEQIEDgUfh2cDEg6uAooPDYQkAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QSGEIFsCIJCgjeBUUAXglMrgQ8FjSWJSgGLV4FzjnCGfYdAAR4BAUKDbGqIAXw?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.22,379,1449532800"; d="scan'208,217";a="232102970" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2016 11:52:24 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u11BqOsH016075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 11:52:24 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 06:52:23 -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; Mon, 1 Feb 2016 06:52:23 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06 Thread-Index: AQHRVNmwbduiclD9G0myI4nvdhFou58HzleAgACHr4CAAAUvAIAPHOkA Date: Mon, 1 Feb 2016 11:52:23 +0000 Message-ID: References: <56A1C480.7000509@juniper.net> <5B325F51-FEEE-479B-A26D-92A38008DDA7@gmail.com> In-Reply-To: <5B325F51-FEEE-479B-A26D-92A38008DDA7@gmail.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.55.106.10] Content-Type: multipart/alternative; boundary="_000_CC3FB48ED9CA44538D6DD946C63E5F56ciscocom_" MIME-Version: 1.0 Archived-At: Cc: 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: Mon, 01 Feb 2016 11:52:28 -0000 --_000_CC3FB48ED9CA44538D6DD946C63E5F56ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQncyBhIHBpdHkgd2UgY2FuJ3QgaWRlbnRpZnkgYSBjb21tb24gbW9kdWxlIGZvciBwYWNrZXQg ZmllbGRzLiBIYXZpbmcgdHdvIHNlcGFyYXRlIHlhbmcgbW9kdWxlcyBpbiB0aGlzIGFyZWEgc2Vl bXMgbGlrZSBhIHVzYWJpbGl0eSBpc3N1ZSBmb3IgZGV2ZWxvcGVycyBhcyB0aGV5IHdpbGwgbmVl ZCB0byBsb29rIGF0IGJvdGggbW9kdWxlcyBhdCBkaWZmZXJlbnQgdGltZXMuDQoNCkFyZSB0aGVy ZSBzcGVjaWZpYyByZWFzb25zIHdoeSB3ZSBjYW4ndCBjb252ZXJnZSBvbiBhIGNvbW1vbiBtb2R1 bGUgZGVmaW5pbmcgcGFja2V0IGZpZWxkcz8NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCk9uIEph biAyMiwgMjAxNiwgYXQgOTowNCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFu aUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0K T24gSmFuIDIyLCAyMDE2LCBhdCAxMjo0NiBQTSwgTGlzYSAoWWkpIEh1YW5nIDxseWlodWFuZ0Bq dW5pcGVyLm5ldDxtYWlsdG86bHlpaHVhbmdAanVuaXBlci5uZXQ+PiB3cm90ZToNCg0KDQoNCk9u IDEvMjIvMTYsIDQ6NDAgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2Vl KSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiB3 cm90ZToNCg0KDQoNCk9uIDEvMjIvMTYsIDEyOjU2IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBF YmJlbiBBcmllcyINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBleGFAanVuaXBlci5uZXQ8bWFpbHRvOmV4YUBqdW5p cGVyLm5ldD4+IHdyb3RlOg0KDQoNCk9uIDAxLzIxLzIwMTYgMTI6NDUgQU0sIFFpbiBXdSB3cm90 ZToNCjEuIFRoaXMgZHJhZnQgZGVmaW5lcyB0d28gbW9kdWxlLCBvbmUgaXMgSUVURi1QQUNLRVQt RklFTERTLCB0aGUgb3RoZXINCmlzIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBtb2R1bGUsDQpJ IGFtIHdvbmRlcmluZyB3aGV0aGVyIGlldGYtcGFja2V0LWZpZWxkcyBtb2R1bGUgY2FuIGJlIGRl ZmluZWQgaW4gbW9yZQ0KZ2VuZXJpYyB3YXkgdGhhdCBjYW4gYmUgYXBwbGllZCB0byBvdGhlciBt b2R1bGVzIGRlZmluZWQgc29tZXdoZXJlIGVsc2U/DQplLmcuLCBpbiBpZXRmLXBhY2tldC1maWVs ZHMgbW9kdWxlLCBhY2wtaXAtaGVhZGVyLWZpZWxkcyBncm91cGluZyBpcw0KZGVmaW5lZCwgSSBh bSB3b25kZXJpbmcgd2hldGhlciBwcmVmaXggImFjbC0iIGNhbiBiZSByZW1vdmVkIHRvIG1ha2Ug aXQNCm1vcmUgZ2VuZXJpYz8NCg0KV2hhdCB5b3UnbGwgbGlrZWx5IHJ1biBpbnRvIGhlcmUgaXMg dGhhdCB0aGUgaGVhZGVyIGZpZWxkcyBkZWZpbmVkIGluDQphY2wtKi1oZWFkZXItZmllbGRzIGFy ZSBtb3JlIG9yIGxlc3MgdGhlIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3JzIGZvcg0KdGhlIGFw cGxpY2F0aW9uIG9mICJhY2wiIC0gTm90IGFsbCBoZWFkZXIgZmllbGRzIGFyZSBkZWZpbmVkIGhl cmUuDQoNCkkgc3VwcG9zZSBhbiBhcHByb2FjaCBjb3VsZCBiZSB0byBkZWZpbmUgZ2VuZXJpYyBn cm91cGluZ3Mgb2YgYWxsIGhlYWRlcg0KZmllbGRzIGFuZCBjcmVhdGUgcGVyIGFwcGxpY2F0aW9u IGdyb3VwaW5ncywgcmVmZXJlbmNpbmcgd2hhdCBpcw0Kc3VwcG9ydGVkIHdpdGggYXBwcm9wcmlh dGUgY29uc3RyYWludHMsIGV0Yy4uLiAgTm90IHN1cmUgd2hhdCB0aGF0IGJ1eXMNCmhlcmUgc2lu Y2UgeW91J3JlIGxpa2VseSB0byBoYXZlIG92ZXJsYXAgYnV0IG5vdCBjb21wbGV0ZSBwYXJpdHkg YmV0d2Vlbg0KdGhlIGRpZmZlcmVudCBjb25zdW1lcnMgb2YgdGhlc2UgcGFja2V0IGZpZWxkcy4N Cg0KRnVydGhlcm1vcmUsIHRoaXMgaXMgbm90IGEgZ2VuZXJpYyBJUCBwYWNrZXQgZmllbGRzIFlB TkcgbW9kdWxlLiBJdCBpcyBhDQptb2R1bGUgZm9yIG1hdGNoaW5nIElQIHBhY2tldCBmaWVsZHMg dXNpbmcgdHJhZGl0aW9uYWwgQUNMIHNlbWFudGljcy4NCkhlbmNlLCBjaGFuZ2luZyB0aGUgY29u dGFpbmVyIG5hbWUgd29uxIV0IGNoYW5nZSB0aGUgY29udGVudCBvciBzZW1hbnRpY3MuDQpJZiBh bnl0aGluZywgdGhlIG1vZHVsZSBuYW1lIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGluY2x1ZGUgxYJh Y2wtxYIgYW5kIG5vdA0KaW1wbHkgdGhhdCBpdCBpcyBnZW5lcmljLg0KVGhhbmtzLA0KQWNlZQ0K DQpUaGVyZSBpcyBubyBpbnRlbnRpb24gdG8gaW5jbHVkZSBhbGwgcGFja2V0IGZpZWxkcyBpbiB0 aGlzIG1vZHVsZSBidXQgUW9TDQpjb3VsZCByZXVzZSB0aGlzIG1vZHVsZS4NCg0KVGhlIFFvUyBt b2R1bGUgaGFzIGRlZmluZWQgaXRzIG93biBzZXQgb2YgZmllbGRzIHRoYXQgcGFja2V0cyBjb3Vs ZCBnZXQgY2xhc3NpZmllZCBvbiwgYW5kIGhhcyBubyBwbGFucyB0byB1c2UgdGhlIEFDTCBwYWNr ZXQgZmllbGQgZGVmaW5pdGlvbnMuDQoNCg0KVGhhbmtzLA0KTGlzYQ0KDQoNCg0KDQoNCi9lYmJl bg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9k QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5k YW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K --_000_CC3FB48ED9CA44538D6DD946C63E5F56ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSXQncyBhIHBpdHkgd2UgY2FuJ3Qg aWRlbnRpZnkgYSBjb21tb24gbW9kdWxlIGZvciBwYWNrZXQgZmllbGRzLiBIYXZpbmcgdHdvIHNl cGFyYXRlIHlhbmcgbW9kdWxlcyBpbiB0aGlzIGFyZWEgc2VlbXMgbGlrZSBhIHVzYWJpbGl0eSBp c3N1ZSBmb3IgZGV2ZWxvcGVycyBhcyB0aGV5IHdpbGwgbmVlZCB0byBsb29rIGF0IGJvdGggbW9k dWxlcyBhdCBkaWZmZXJlbnQgdGltZXMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcmUgdGhlcmUgc3BlY2lmaWMgcmVhc29ucyB3aHkgd2UgY2Fu J3QgY29udmVyZ2Ugb24gYSBjb21tb24gbW9kdWxlIGRlZmluaW5nIHBhY2tldCBmaWVsZHM/PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D aGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKYW4gMjIsIDIwMTYsIGF0IDk6MDQgUE0s IE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdt YWlsLmNvbSIgY2xhc3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IERyb2lkU2VyaWY7IGZvbnQtc2l6ZTogMTNw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KT24gSmFuIDIyLCAyMDE2LCBhdCAxMjo0NiBQTSwgTGlzYSAoWWkpIEh1YW5nICZs dDs8YSBocmVmPSJtYWlsdG86bHlpaHVhbmdAanVuaXBlci5uZXQiIGNsYXNzPSIiPmx5aWh1YW5n QGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiPk9uDQogMS8yMi8xNiwg NDo0MCBBTSwgJnF1b3Q7bmV0bW9kIG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSAoYWNlZSkmcXVv dDs8L3NwYW4+PGJyIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8 c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyI+Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5vbg0KIGJlaGFsZiBvZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmFjZWVAY2lzY28uY29tPC9hPjxzcGFuIGNs YXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7Ij4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxiciBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIGNsYXNzPSIiIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KT24gMS8yMi8xNiwgMTI6NTYgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgRWJi ZW4gQXJpZXMmcXVvdDs8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b24gYmVoYWxmIG9m PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpleGFAanVuaXBlci5uZXQiIGNsYXNzPSIiPmV4YUBqdW5pcGVyLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIDAxLzIxLzIwMTYgMTI6NDUgQU0sIFFpbiBX dSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4x LiBUaGlzIGRyYWZ0IGRlZmluZXMgdHdvIG1vZHVsZSwgb25lIGlzIElFVEYtUEFDS0VULUZJRUxE UywgdGhlIG90aGVyPGJyIGNsYXNzPSIiPg0KaXMgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1v ZHVsZSw8YnIgY2xhc3M9IiI+DQpJIGFtIHdvbmRlcmluZyB3aGV0aGVyIGlldGYtcGFja2V0LWZp ZWxkcyBtb2R1bGUgY2FuIGJlIGRlZmluZWQgaW4gbW9yZTxiciBjbGFzcz0iIj4NCmdlbmVyaWMg d2F5IHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gb3RoZXIgbW9kdWxlcyBkZWZpbmVkIHNvbWV3aGVy ZSBlbHNlPzxiciBjbGFzcz0iIj4NCmUuZy4sIGluIGlldGYtcGFja2V0LWZpZWxkcyBtb2R1bGUs IGFjbC1pcC1oZWFkZXItZmllbGRzIGdyb3VwaW5nIGlzPGJyIGNsYXNzPSIiPg0KZGVmaW5lZCwg SSBhbSB3b25kZXJpbmcgd2hldGhlciBwcmVmaXggJnF1b3Q7YWNsLSZxdW90OyBjYW4gYmUgcmVt b3ZlZCB0byBtYWtlIGl0PGJyIGNsYXNzPSIiPg0KbW9yZSBnZW5lcmljPzxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCldoYXQgeW91J2xsIGxpa2VseSBydW4gaW50 byBoZXJlIGlzIHRoYXQgdGhlIGhlYWRlciBmaWVsZHMgZGVmaW5lZCBpbjxiciBjbGFzcz0iIj4N CmFjbC0qLWhlYWRlci1maWVsZHMgYXJlIG1vcmUgb3IgbGVzcyB0aGUgbG93ZXN0IGNvbW1vbiBk ZW5vbWluYXRvcnMgZm9yPGJyIGNsYXNzPSIiPg0KdGhlIGFwcGxpY2F0aW9uIG9mICZxdW90O2Fj bCZxdW90OyAtIE5vdCBhbGwgaGVhZGVyIGZpZWxkcyBhcmUgZGVmaW5lZCBoZXJlLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgc3VwcG9zZSBhbiBhcHByb2FjaCBjb3VsZCBiZSB0byBk ZWZpbmUgZ2VuZXJpYyBncm91cGluZ3Mgb2YgYWxsIGhlYWRlcjxiciBjbGFzcz0iIj4NCmZpZWxk cyBhbmQgY3JlYXRlIHBlciBhcHBsaWNhdGlvbiBncm91cGluZ3MsIHJlZmVyZW5jaW5nIHdoYXQg aXM8YnIgY2xhc3M9IiI+DQpzdXBwb3J0ZWQgd2l0aCBhcHByb3ByaWF0ZSBjb25zdHJhaW50cywg ZXRjLi4uICZuYnNwO05vdCBzdXJlIHdoYXQgdGhhdCBidXlzPGJyIGNsYXNzPSIiPg0KaGVyZSBz aW5jZSB5b3UncmUgbGlrZWx5IHRvIGhhdmUgb3ZlcmxhcCBidXQgbm90IGNvbXBsZXRlIHBhcml0 eSBiZXR3ZWVuPGJyIGNsYXNzPSIiPg0KdGhlIGRpZmZlcmVudCBjb25zdW1lcnMgb2YgdGhlc2Ug cGFja2V0IGZpZWxkcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpGdXJ0aGVybW9yZSwgdGhpcyBpcyBub3QgYSBnZW5lcmljIElQIHBhY2tldCBmaWVsZHMgWUFO RyBtb2R1bGUuIEl0IGlzIGE8YnIgY2xhc3M9IiI+DQptb2R1bGUgZm9yIG1hdGNoaW5nIElQIHBh Y2tldCBmaWVsZHMgdXNpbmcgdHJhZGl0aW9uYWwgQUNMIHNlbWFudGljcy48YnIgY2xhc3M9IiI+ DQpIZW5jZSwgY2hhbmdpbmcgdGhlIGNvbnRhaW5lciBuYW1lIHdvbsSFdCBjaGFuZ2UgdGhlIGNv bnRlbnQgb3Igc2VtYW50aWNzLjxiciBjbGFzcz0iIj4NCklmIGFueXRoaW5nLCB0aGUgbW9kdWxl IG5hbWUgc2hvdWxkIGJlIGNoYW5nZWQgdG8gaW5jbHVkZSDFgmFjbC3FgiBhbmQgbm90PGJyIGNs YXNzPSIiPg0KaW1wbHkgdGhhdCBpdCBpcyBnZW5lcmljLjxiciBjbGFzcz0iIj4NClRoYW5rcyw8 YnIgY2xhc3M9IiI+DQpBY2VlPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz PSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8c3BhbiBjbGFzcz0iIiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyI+VGhlcmUNCiBpcyBubyBpbnRlbnRpb24gdG8gaW5jbHVkZSBhbGwgcGFja2V0 IGZpZWxkcyBpbiB0aGlzIG1vZHVsZSBidXQgUW9TPC9zcGFuPjxiciBjbGFzcz0iIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi PmNvdWxkDQogcmV1c2UgdGhpcyBtb2R1bGUuPC9zcGFuPjxiciBjbGFzcz0iIiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KVGhlIFFvUyBtb2R1bGUgaGFzIGRlZmluZWQgaXRz IG93biBzZXQgb2YgZmllbGRzIHRoYXQgcGFja2V0cyBjb3VsZCBnZXQgY2xhc3NpZmllZCBvbiwg YW5kIGhhcyBubyBwbGFucyB0byB1c2UgdGhlIEFDTCBwYWNrZXQgZmllbGQgZGVmaW5pdGlvbnMu PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogRHJvaWRTZXJpZjsgZm9udC1zaXplOiAx M3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiPlRoYW5rcyw8L3NwYW4+PGJyIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyI+TGlzYTwvc3Bhbj48YnIg Y2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxiciBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIGNsYXNzPSIiIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KL2Vi YmVuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+ bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFz cz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNwYW4gY2xhc3M9IiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0K PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiPm5ldG1vZA0KIG1haWxpbmcgbGlzdDwvc3Bh bj48YnIgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IERy b2lkU2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgYXBw bGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogRHJv aWRTZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+TWFoZXNoIEpldGhhbmFuZGFuaTwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIGNsYXNz PSIiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IERyb2lkU2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogRHJvaWRTZXJpZjsg Zm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogRHJvaWRT ZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBEcm9pZFNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5uZXRtb2QNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogRHJvaWRTZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBEcm9pZFNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IERyb2lkU2VyaWY7 IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiBzdHlsZT0iZm9u dC1mYW1pbHk6IERyb2lkU2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwv YT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CC3FB48ED9CA44538D6DD946C63E5F56ciscocom_-- From nobody Mon Feb 1 06:35:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD61A9174 for ; Mon, 1 Feb 2016 06:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 tYffkiaZNRLl for ; Mon, 1 Feb 2016 06:35:39 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id BD2831A923D for ; Mon, 1 Feb 2016 06:35:35 -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 75692C001FE0; Mon, 1 Feb 2016 15:35:31 +0100 (CET) To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160129.154836.1250045488182328568.mbj@tail-f.com> From: Jernej Tuljak Message-ID: <56AF6D2D.9000805@mg-soft.si> Date: Mon, 1 Feb 2016 15:35:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 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] chars that require quoting 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, 01 Feb 2016 14:35:45 -0000 Ladislav Lhotka je 29.1.2016 ob 15:58 napisal: >> On 29 Jan 2016, at 15:48, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>>> On 29 Jan 2016, at 12:55, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> I think the following change to sec. 6.1.3 of 6020bis is needed: >>>>> >>>>> OLD >>>>> If a string contains any space or tab characters, a semicolon (";"), >>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >>>>> it MUST be enclosed within double or single quotes. >>>>> >>>>> NEW >>>>> If a string contains any space, tab or newline characters, a semicolon >>>>> (";"), >>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >>>>> it MUST be enclosed within double or single quotes. >>>> I agree. >>>> >>>>> And what about the CR character and single or double quotes? This >>>>> seems to be legal and results in a description argument of length 5 >>>>> (in pyang at least): >>>>> >>>>> description \"hi"; >>>> I don't understand what you mean. >>> If an argument starts as unquoted, then double quotes appearing inside >>> it (or at the end) are accepted as literals. Backslash can appear >>> anywhere in an unquoted argument, but it is less of a problem. So the >>> above statement rewritten with a double-quoted argument is this: >>> >>> description "\\\"hi\""; >>> >>> I think that single and double quotes (and perhaps also backslashes) >>> shouldn't be allowed in an unquoted argument. >> Maybe, but this is a pretty big change, and the current rules "work", >> and we're just about to publish a version can be sent to the IESG, so >> I'd say that it is too late for this change. > I know, but it opens space for nasty tricks like this: > > $ cat quoting.yang > module quoting { > namespace "http://example.com/quoting"; > prefix qq; > leaf foo { > type string; > default ​"hi"; > } > } > $ pyang -f yang quoting.yang > module quoting { > namespace "http://example.com/quoting"; > prefix qq; > > leaf foo { > type string; > default "​\"hi\""; > } > } > > Weird, isn't it? It is because "ZERO WIDTH SPACE" (U+200B) immediately precedes the first double quote in the argument of "default". Consequently, the argument is parsed as unquoted, and both double quotes become part of it. I remember asking about this for 1.0. https://www.ietf.org/mail-archive/web/netmod/current/msg08586.html The text is still as unclear on this matter as back then. In our 1.0 implementation your example is syntactically invalid (missing statement separator, unexpected keyword). A quote always starts a string token (unless in comment, single quoted string or escaped in double quoted string). Jernej > > Lada > >> >> /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 Mon Feb 1 07:15:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F531ACD2E for ; Mon, 1 Feb 2016 07:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 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, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 6NMBAiCla1xH for ; Mon, 1 Feb 2016 07:15:31 -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 6964F1A00E0 for ; Mon, 1 Feb 2016 07:15:31 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:6979:6fa3:928a:64e4] (unknown [IPv6:2001:718:1a02:1:6979:6fa3:928a:64e4]) by mail.nic.cz (Postfix) with ESMTPSA id C6C27181299; Mon, 1 Feb 2016 16:15:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454339729; bh=xRT1qOy9zKdJvr+1bqJgDIMV8ns5aYoqlCiS0kn/+Yw=; h=From:Date:To; b=DlJ9Hj61fAeHTZy9ayButqQ/qwVw4jXy4/SKZZHBp2Uu5xKOW/hO2DNMOZazysNtv znKO9yL2801r6BV352K42Z89Z7suSSqd/o39nRlLzoEe3PK7ZGK7RLavZ4XvgOuQ9T 3xBKwRNMeG2291TM2ydd0EF9ryJWz48wMftpusDI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56AF6D2D.9000805@mg-soft.si> Date: Mon, 1 Feb 2016 16:15:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <135F510D-B0D3-48A5-84BC-6A3D3392A65F@nic.cz> References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160129.154836.1250045488182328568.mbj@tail-f.com> <56AF6D2D.9000805@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] chars that require quoting 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, 01 Feb 2016 15:15:33 -0000 > On 01 Feb 2016, at 15:35, Jernej Tuljak = wrote: >=20 > Ladislav Lhotka je 29.1.2016 ob 15:58 napisal: >>> On 29 Jan 2016, at 15:48, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>> On 29 Jan 2016, at 12:55, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I think the following change to sec. 6.1.3 of 6020bis is needed: >>>>>>=20 >>>>>> OLD >>>>>> If a string contains any space or tab characters, a semicolon = (";"), >>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), = then >>>>>> it MUST be enclosed within double or single quotes. >>>>>>=20 >>>>>> NEW >>>>>> If a string contains any space, tab or newline characters, a = semicolon >>>>>> (";"), >>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), = then >>>>>> it MUST be enclosed within double or single quotes. >>>>> I agree. >>>>>=20 >>>>>> And what about the CR character and single or double quotes? This >>>>>> seems to be legal and results in a description argument of length = 5 >>>>>> (in pyang at least): >>>>>>=20 >>>>>> description \"hi"; >>>>> I don't understand what you mean. >>>> If an argument starts as unquoted, then double quotes appearing = inside >>>> it (or at the end) are accepted as literals. Backslash can appear >>>> anywhere in an unquoted argument, but it is less of a problem. So = the >>>> above statement rewritten with a double-quoted argument is this: >>>>=20 >>>> description "\\\"hi\""; >>>>=20 >>>> I think that single and double quotes (and perhaps also = backslashes) >>>> shouldn't be allowed in an unquoted argument. >>> Maybe, but this is a pretty big change, and the current rules = "work", >>> and we're just about to publish a version can be sent to the IESG, = so >>> I'd say that it is too late for this change. >> I know, but it opens space for nasty tricks like this: >>=20 >> $ cat quoting.yang >> module quoting { >> namespace "http://example.com/quoting"; >> prefix qq; >> leaf foo { >> type string; >> default =E2=80=8B"hi"; >> } >> } >> $ pyang -f yang quoting.yang >> module quoting { >> namespace "http://example.com/quoting"; >> prefix qq; >>=20 >> leaf foo { >> type string; >> default "=E2=80=8B\"hi\""; >> } >> } >>=20 >> Weird, isn't it? It is because "ZERO WIDTH SPACE" (U+200B) = immediately precedes the first double quote in the argument of = "default". Consequently, the argument is parsed as unquoted, and both = double quotes become part of it. >=20 > I remember asking about this for 1.0. = https://www.ietf.org/mail-archive/web/netmod/current/msg08586.html Your example in that message, namely=20 default "; (with just a plain space between the keyword and argument) must by all = means be invalid, otherwise it would be a total disaster. On the other hand, this is not much better, and pyang has no objections: default \"; >=20 > The text is still as unclear on this matter as back then. In our 1.0 = implementation your example is syntactically invalid (missing statement = separator, unexpected keyword). A quote always starts a string token = (unless in comment, single quoted string or escaped in double quoted = string). In pyang it is valid. Does your implementation permit default \;=20 Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>>=20 >>> /martin >> -- >> 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 Mon Feb 1 07:39:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3091ACEC5 for ; Mon, 1 Feb 2016 07:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-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 jem3-ka51s_S for ; Mon, 1 Feb 2016 07:39: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 4C1541ACEBE for ; Mon, 1 Feb 2016 07:39:05 -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 3ECFFC001FE0; Mon, 1 Feb 2016 16:39:04 +0100 (CET) To: Ladislav Lhotka References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160129.154836.1250045488182328568.mbj@tail-f.com> <56AF6D2D.9000805@mg-soft.si> <135F510D-B0D3-48A5-84BC-6A3D3392A65F@nic.cz> From: Jernej Tuljak Message-ID: <56AF7C11.1080006@mg-soft.si> Date: Mon, 1 Feb 2016 16:38:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <135F510D-B0D3-48A5-84BC-6A3D3392A65F@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] chars that require quoting 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, 01 Feb 2016 15:39:07 -0000 Ladislav Lhotka je 1.2.2016 ob 16:15 napisal: >> On 01 Feb 2016, at 15:35, Jernej Tuljak wrote: >> >> Ladislav Lhotka je 29.1.2016 ob 15:58 napisal: >>>> On 29 Jan 2016, at 15:48, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >>>>>> On 29 Jan 2016, at 12:55, Martin Bjorklund wrote: >>>>>> >>>>>> Ladislav Lhotka wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I think the following change to sec. 6.1.3 of 6020bis is needed: >>>>>>> >>>>>>> OLD >>>>>>> If a string contains any space or tab characters, a semicolon (";"), >>>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >>>>>>> it MUST be enclosed within double or single quotes. >>>>>>> >>>>>>> NEW >>>>>>> If a string contains any space, tab or newline characters, a semicolon >>>>>>> (";"), >>>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >>>>>>> it MUST be enclosed within double or single quotes. >>>>>> I agree. >>>>>> >>>>>>> And what about the CR character and single or double quotes? This >>>>>>> seems to be legal and results in a description argument of length 5 >>>>>>> (in pyang at least): >>>>>>> >>>>>>> description \"hi"; >>>>>> I don't understand what you mean. >>>>> If an argument starts as unquoted, then double quotes appearing inside >>>>> it (or at the end) are accepted as literals. Backslash can appear >>>>> anywhere in an unquoted argument, but it is less of a problem. So the >>>>> above statement rewritten with a double-quoted argument is this: >>>>> >>>>> description "\\\"hi\""; >>>>> >>>>> I think that single and double quotes (and perhaps also backslashes) >>>>> shouldn't be allowed in an unquoted argument. >>>> Maybe, but this is a pretty big change, and the current rules "work", >>>> and we're just about to publish a version can be sent to the IESG, so >>>> I'd say that it is too late for this change. >>> I know, but it opens space for nasty tricks like this: >>> >>> $ cat quoting.yang >>> module quoting { >>> namespace "http://example.com/quoting"; >>> prefix qq; >>> leaf foo { >>> type string; >>> default ​"hi"; >>> } >>> } >>> $ pyang -f yang quoting.yang >>> module quoting { >>> namespace "http://example.com/quoting"; >>> prefix qq; >>> >>> leaf foo { >>> type string; >>> default "​\"hi\""; >>> } >>> } >>> >>> Weird, isn't it? It is because "ZERO WIDTH SPACE" (U+200B) immediately precedes the first double quote in the argument of "default". Consequently, the argument is parsed as unquoted, and both double quotes become part of it. >> I remember asking about this for 1.0. https://www.ietf.org/mail-archive/web/netmod/current/msg08586.html > Your example in that message, namely > > default "; > > (with just a plain space between the keyword and argument) must by all means be invalid, otherwise it would be a total disaster. > On the other hand, this is not much better, and pyang has no objections: > > default \"; > >> The text is still as unclear on this matter as back then. In our 1.0 implementation your example is syntactically invalid (missing statement separator, unexpected keyword). A quote always starts a string token (unless in comment, single quoted string or escaped in double quoted string). > In pyang it is valid. Does your implementation permit > > default \; Yes, it does permit it since it is just a backslash, not an escape, like it would be inside a double quoted string. We implemented it as if section 6.1.2 Tokens, would contain the following sentence: A quote character always starts a string token (unless inside a comment, a single quoted string or escaped in a double quoted string) which must be terminated with the same quote character. It is what Juergen and Andy were claiming back then, unless I misread it. Jernej > > Lada > >> Jernej >> >>> Lada >>> >>>> /martin >>> -- >>> 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 Mon Feb 1 07:43:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323441ACEF0 for ; Mon, 1 Feb 2016 07:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 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, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-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 YBBzDcFTNL_S for ; Mon, 1 Feb 2016 07:43:07 -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 539561ACEEE for ; Mon, 1 Feb 2016 07:43:07 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id EA94718181D; Mon, 1 Feb 2016 16:43:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454341386; bh=QS7KmyM2hwKh++c4hE2hhI82oCByfTOeJemnnrvIllM=; h=From:Date:To; b=cG6Ezn+J7Rhus+WWMsBr199Q9qgZlU4kudeb84QIYmIvqd9KDN4m4LEtk/RQXM0BU EZgffnYx2Qmw2ilZjFiO+m6h3O8hCV1broOP2xZ2h+pgi3MrUURMt3pZ3eJ+s9z1XH ikT4YmOQRzQPM9Cg7DTVlPgEq+8jLkgO6iDCGYHY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56AF7C11.1080006@mg-soft.si> Date: Mon, 1 Feb 2016 16:43:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160129.154836.1250045488182328568.mbj@tail-f.com> <56AF6D2D.9000805@mg-soft.si> <135F510D-B0D3-48A5-84BC-6A3D3392A65F@nic.cz> <56AF7C11.1080006@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] chars that require quoting 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, 01 Feb 2016 15:43:09 -0000 > On 01 Feb 2016, at 16:38, Jernej Tuljak = wrote: >=20 > Ladislav Lhotka je 1.2.2016 ob 16:15 napisal: >>> On 01 Feb 2016, at 15:35, Jernej Tuljak = wrote: >>>=20 >>> Ladislav Lhotka je 29.1.2016 ob 15:58 napisal: >>>>> On 29 Jan 2016, at 15:48, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>> On 29 Jan 2016, at 12:55, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I think the following change to sec. 6.1.3 of 6020bis is = needed: >>>>>>>>=20 >>>>>>>> OLD >>>>>>>> If a string contains any space or tab characters, a semicolon = (";"), >>>>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or = "*/"), then >>>>>>>> it MUST be enclosed within double or single quotes. >>>>>>>>=20 >>>>>>>> NEW >>>>>>>> If a string contains any space, tab or newline characters, a = semicolon >>>>>>>> (";"), >>>>>>>> braces ("{" or "}"), or comment sequences ("//", "/*", or = "*/"), then >>>>>>>> it MUST be enclosed within double or single quotes. >>>>>>> I agree. >>>>>>>=20 >>>>>>>> And what about the CR character and single or double quotes? = This >>>>>>>> seems to be legal and results in a description argument of = length 5 >>>>>>>> (in pyang at least): >>>>>>>>=20 >>>>>>>> description \"hi"; >>>>>>> I don't understand what you mean. >>>>>> If an argument starts as unquoted, then double quotes appearing = inside >>>>>> it (or at the end) are accepted as literals. Backslash can appear >>>>>> anywhere in an unquoted argument, but it is less of a problem. So = the >>>>>> above statement rewritten with a double-quoted argument is this: >>>>>>=20 >>>>>> description "\\\"hi\""; >>>>>>=20 >>>>>> I think that single and double quotes (and perhaps also = backslashes) >>>>>> shouldn't be allowed in an unquoted argument. >>>>> Maybe, but this is a pretty big change, and the current rules = "work", >>>>> and we're just about to publish a version can be sent to the IESG, = so >>>>> I'd say that it is too late for this change. >>>> I know, but it opens space for nasty tricks like this: >>>>=20 >>>> $ cat quoting.yang >>>> module quoting { >>>> namespace "http://example.com/quoting"; >>>> prefix qq; >>>> leaf foo { >>>> type string; >>>> default =E2=80=8B"hi"; >>>> } >>>> } >>>> $ pyang -f yang quoting.yang >>>> module quoting { >>>> namespace "http://example.com/quoting"; >>>> prefix qq; >>>>=20 >>>> leaf foo { >>>> type string; >>>> default "=E2=80=8B\"hi\""; >>>> } >>>> } >>>>=20 >>>> Weird, isn't it? It is because "ZERO WIDTH SPACE" (U+200B) = immediately precedes the first double quote in the argument of = "default". Consequently, the argument is parsed as unquoted, and both = double quotes become part of it. >>> I remember asking about this for 1.0. = https://www.ietf.org/mail-archive/web/netmod/current/msg08586.html >> Your example in that message, namely >>=20 >> default "; >>=20 >> (with just a plain space between the keyword and argument) must by = all means be invalid, otherwise it would be a total disaster. >> On the other hand, this is not much better, and pyang has no = objections: >>=20 >> default \"; >>=20 >>> The text is still as unclear on this matter as back then. In our 1.0 = implementation your example is syntactically invalid (missing statement = separator, unexpected keyword). A quote always starts a string token = (unless in comment, single quoted string or escaped in double quoted = string). >> In pyang it is valid. Does your implementation permit >>=20 >> default \; >=20 > Yes, it does permit it since it is just a backslash, not an escape, = like it would be inside a double quoted string. We implemented it as if = section 6.1.2 Tokens, would contain the following sentence: >=20 > A quote character always starts a string token (unless inside a = comment, a single quoted string or escaped in a double quoted string) = which must be terminated with the same quote character. >=20 > It is what Juergen and Andy were claiming back then, unless I misread = it. And it also makes a lot of sense to me. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> Jernej >>>=20 >>>> Lada >>>>=20 >>>>> /martin >>>> -- >>>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 1 07:45:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34071ACEDD for ; Mon, 1 Feb 2016 07:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 oeZYe0_qI_9x for ; Mon, 1 Feb 2016 07:45: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 9289E1ACEC1 for ; Mon, 1 Feb 2016 07:45:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 96582108F; Mon, 1 Feb 2016 16:45:37 +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 0vOI26vN0czK; Mon, 1 Feb 2016 16:45:36 +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, 1 Feb 2016 16:45:36 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1A6C2002B; Mon, 1 Feb 2016 16:45:36 +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 z2yhf5NPh577; Mon, 1 Feb 2016 16:45:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C81EE20013; Mon, 1 Feb 2016 16:45:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E1C6639D1C09; Mon, 1 Feb 2016 16:45:35 +0100 (CET) Date: Mon, 1 Feb 2016 16:45:35 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160201154535.GA11656@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] chars that require quoting 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, 01 Feb 2016 15:45:42 -0000 On Fri, Jan 29, 2016 at 01:14:27PM +0100, Ladislav Lhotka wrote: > > If an argument starts as unquoted, then double quotes appearing inside it (or at the end) are accepted as literals. Backslash can appear anywhere in an unquoted argument, but it is less of a problem. So the above statement rewritten with a double-quoted argument is this: > > description "\\\"hi\""; > > I think that single and double quotes (and perhaps also backslashes) shouldn't be allowed in an unquoted argument. > Interesting, languages seem to deal with this strings like this somewhat differently: | lang | input | output | comment | |--------+--------------+--------+-----------------------------------------------------------------| | bash | echo f"o"o | foo | | | tcl | echo f"o"o | f"o"o | | | python | print f"o"o | | SyntaxError: invalid syntax | | perl5 | print f"o"o; | | Bareword found where operator expected at - line 1, near ""o"o" | | ruby | puts f"o"o | | syntax error, unexpected tIDENTIFIER, expecting $end | It is not clear to me whether RFC 6020 or RFC 6020bis defines a certain behaviour here. There is text about quoted strings but not much about unquoted strings. So I would not be surprised if implementations behave differently here. The text in RFC 6020bis also defines backslash behaviour only inside quoted strings. It is left to an implementor's imagination what f\"oo resolves to I think (and if you comine things, what f\"o"o means). /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 Feb 1 08:01:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B171AD0BB; Mon, 1 Feb 2016 08:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 l8aDIZHWLqS0; Mon, 1 Feb 2016 08:01:47 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 EFECC1B29CD; Mon, 1 Feb 2016 08:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454342493; bh=v9oQmdx/wkuEpBxfaSXcK5L0jbkPl7XPMBLWAPwfq2w=; h=From:Subject:Date:Cc:To; b=SF2DEIFoZtbsejPhwtoNm0zxvO/y1CDyJUiXVfFbWH4b+DIqhLN7/Je4TPeQ/mnNk ueiDMs6bGKo8mxHcxPC6wAxDJX52EJrC5gwuQ37h1s0JYouG//oaJOKGNX7EWYhBzc 1e4ehuaSlzj9+ztedcDMnD+F1hJqC/rnWqDMBOr0= 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 Date: Mon, 1 Feb 2016 11:01:28 -0500 Message-Id: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) 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 262, in=3187, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@tools.ietf.org, draft-ietf-netmod-acl-model@ietf.org Subject: [netmod] draft-ietf-netmod-acl-model status 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, 01 Feb 2016 16:01:48 -0000 ACL Doc Authors: What is your status and plan to address the numerous technical = comments that have arisen since the WG LC? =20 I know there are for example, numerous detailed comments from Juergen = and I think Elliot Lear posted some too. =E2=80=94Tom From nobody Mon Feb 1 11:05:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B321B34A4 for ; Mon, 1 Feb 2016 11:05:20 -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, RP_MATCHES_RCVD=-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 ww1rVPZQvvW3 for ; Mon, 1 Feb 2016 11:05: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 EE2F21B34A1 for ; Mon, 1 Feb 2016 11:05: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 0A86D1AE00B6; Mon, 1 Feb 2016 20:05:17 +0100 (CET) Date: Mon, 01 Feb 2016 20:08:00 +0100 (CET) Message-Id: <20160201.200800.1399101643067030032.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160201154535.GA11656@elstar.local> References: <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160201154535.GA11656@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] chars that require quoting 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, 01 Feb 2016 19:05:20 -0000 Juergen Schoenwaelder wrote: > On Fri, Jan 29, 2016 at 01:14:27PM +0100, Ladislav Lhotka wrote: > > > > If an argument starts as unquoted, then double quotes appearing inside it (or at the end) are accepted as literals. Backslash can appear anywhere in an unquoted argument, but it is less of a problem. So the above statement rewritten with a double-quoted argument is this: > > > > description "\\\"hi\""; > > > > I think that single and double quotes (and perhaps also backslashes) shouldn't be allowed in an unquoted argument. > > > > Interesting, languages seem to deal with this strings like this > somewhat differently: > > | lang | input | output | comment | > |--------+--------------+--------+-----------------------------------------------------------------| > | bash | echo f"o"o | foo | | > | tcl | echo f"o"o | f"o"o | | > | python | print f"o"o | | SyntaxError: invalid syntax | > | perl5 | print f"o"o; | | Bareword found where operator expected at - line 1, near ""o"o" | > | ruby | puts f"o"o | | syntax error, unexpected tIDENTIFIER, expecting $end | > > It is not clear to me whether RFC 6020 or RFC 6020bis defines a > certain behaviour here. There is text about quoted strings but not > much about unquoted strings. So I would not be surprised if > implementations behave differently here. > > The text in RFC 6020bis also defines backslash behaviour only inside > quoted strings. It is left to an implementor's imagination what f\"oo > resolves to I think Do you mean b/c of the double-qoute character? Why would an implementor think that the backslash character is special in any way in an unquoted string? IMO it would be very odd to think that since the text doesn't mention that backslash is special in an unquoted string, it probably means that an implementation can choose to interpret it in anyway he likes. /martin From nobody Mon Feb 1 11:25:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840B41B34F4 for ; Mon, 1 Feb 2016 11:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 mTmsM3K_E0Hv for ; Mon, 1 Feb 2016 11:25:13 -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 E13C71B34F8 for ; Mon, 1 Feb 2016 11:25:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AC4016D7; Mon, 1 Feb 2016 20:25:11 +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 XVMDxTRuwLc9; Mon, 1 Feb 2016 20:25:10 +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, 1 Feb 2016 20:25:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF8E820013; Mon, 1 Feb 2016 20:25:10 +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 481fyjx0FS0L; Mon, 1 Feb 2016 20:25:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F2E62003C; Mon, 1 Feb 2016 20:25:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 70B8A39D2021; Mon, 1 Feb 2016 20:25:09 +0100 (CET) Date: Mon, 1 Feb 2016 20:25:09 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160201192509.GB12162@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160201154535.GA11656@elstar.local> <20160201.200800.1399101643067030032.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160201.200800.1399101643067030032.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] chars that require quoting 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, 01 Feb 2016 19:25:15 -0000 On Mon, Feb 01, 2016 at 08:08:00PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Fri, Jan 29, 2016 at 01:14:27PM +0100, Ladislav Lhotka wrote: > > > > > > If an argument starts as unquoted, then double quotes appearing inside it (or at the end) are accepted as literals. Backslash can appear anywhere in an unquoted argument, but it is less of a problem. So the above statement rewritten with a double-quoted argument is this: > > > > > > description "\\\"hi\""; > > > > > > I think that single and double quotes (and perhaps also backslashes) shouldn't be allowed in an unquoted argument. > > > > > > > Interesting, languages seem to deal with this strings like this > > somewhat differently: > > > > | lang | input | output | comment | > > |--------+--------------+--------+-----------------------------------------------------------------| > > | bash | echo f"o"o | foo | | > > | tcl | echo f"o"o | f"o"o | | > > | python | print f"o"o | | SyntaxError: invalid syntax | > > | perl5 | print f"o"o; | | Bareword found where operator expected at - line 1, near ""o"o" | > > | ruby | puts f"o"o | | syntax error, unexpected tIDENTIFIER, expecting $end | > > > > It is not clear to me whether RFC 6020 or RFC 6020bis defines a > > certain behaviour here. There is text about quoted strings but not > > much about unquoted strings. So I would not be surprised if > > implementations behave differently here. > > > > The text in RFC 6020bis also defines backslash behaviour only inside > > quoted strings. It is left to an implementor's imagination what f\"oo > > resolves to I think > > Do you mean b/c of the double-qoute character? > > Why would an implementor think that the backslash character is special > in any way in an unquoted string? IMO it would be very odd to think > that since the text doesn't mention that backslash is special in an > unquoted string, it probably means that an implementation can choose > to interpret it in anyway he likes. > If a specification is not explicit enough, then people often implement what they find implemented in other similar contexts. This means the code often ends up reflecting which tools an implementor was familiar with. In a shell, echo f\"oo gives you f"oo (and the same is true for Tcl, which has otherwise the behavior you implemented for pyang, treating " as a regular character in an unquoted string.) It would help to know what implementations do with identifiers like f"o"o and f\"o\"o. If they do different things, then there is likely some evidence that implementors arrived at different conclusions. /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 Feb 1 11:45:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFB1B355E for ; Mon, 1 Feb 2016 11:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-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 ggdPgkeyevnR for ; Mon, 1 Feb 2016 11:45:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF2F1B3557 for ; Mon, 1 Feb 2016 11:45:45 -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 4B1601AE00B6; Mon, 1 Feb 2016 20:45:44 +0100 (CET) Date: Mon, 01 Feb 2016 20:48:28 +0100 (CET) Message-Id: <20160201.204828.1537890819794101926.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160201192509.GB12162@elstar.local> References: <20160201154535.GA11656@elstar.local> <20160201.200800.1399101643067030032.mbj@tail-f.com> <20160201192509.GB12162@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] chars that require quoting 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, 01 Feb 2016 19:45:46 -0000 Juergen Schoenwaelder wrote: > If a specification is not explicit enough, then people often implement > what they find implemented in other similar contexts. This means the > code often ends up reflecting which tools an implementor was familiar > with. In a shell, echo f\"oo gives you f"oo (and the same is true for > Tcl, which has otherwise the behavior you implemented for pyang, > treating " as a regular character in an unquoted string.) > > It would help to know what implementations do with identifiers like > f"o"o and f\"o\"o. If they do different things, then there is likely > some evidence that implementors arrived at different conclusions. I don't mind a clarification. How about: OLD: If a string contains any space, tab, or newline characters, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes. NEW: If a string contains any space, tab, or newline characters, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes. If a string does not contain any of these characters, it MAY be unquoted. Within an unquoted string, every character is preserved. Note that this means that the backslash, single quote, and double quote characters can occur in an unquoted string. /martin From nobody Mon Feb 1 16:33:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B3E1A1A5A for ; Mon, 1 Feb 2016 16:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 sBpFRFp2zUU5 for ; Mon, 1 Feb 2016 16:32:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CC71A1A4D for ; Mon, 1 Feb 2016 16:32:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHU26243; Tue, 02 Feb 2016 00:32:55 +0000 (GMT) Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 2 Feb 2016 00:32:54 +0000 Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.48]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Tue, 2 Feb 2016 08:32:48 +0800 From: "fengchong (C)" To: "netmod@ietf.org" Thread-Topic: Why not use xpath3.0 or xpath2.0? Thread-Index: AdFdUTzymIhUPHLSTlSFl2fXoVy0Bw== Date: Tue, 2 Feb 2016 00:32:47 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D0834E1A@SZXEMI506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/related; boundary="_004_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56AFF938.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7e2f9078bc2468326e53216f720b9eea Archived-At: Subject: [netmod] Why not use xpath3.0 or xpath2.0? 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, 02 Feb 2016 00:33:01 -0000 --_004_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_ Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_" --_000_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSSBub3RpY2UgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy0wOSBzdGlsbCB1 c2VzIHhwYXRoMS4wIGFzIGEgbm90YXRpb24gZm9yIGNoZWNraW5nIG5vZGUgcmVmZXJlbmNlcyBv ciBkZXBlbmRlbmNpZXMuDQpJIGRvbqGvdCBrbm93IHdoeSB3ZSBkb26hr3QgdXNlIHhwYXRoMy4w IG9yIHhwYXRoMi4wPyB4cGF0aDMuMCBpcyBtb3JlIHBvd2VyZnVsIHRoYW4geHBhdGgxLjAuDQpG b3IgZXhhbXBsZSwgeHBhdGgzLjAgaW50cm9kdWNlZCBjb25kaXRpb25hbCBleHByZXNzaW9uLiBJ dKGvcyB2ZXJ5IHVzZWZ1bCBmb3IgbXVzdCBzdGF0ZW1lbnQuDQoNCklmIHdlIGhhdmUgYSBzY2hl bWEgdHJlZSBsaWtlIHRoaXM6DQpMaXN0IGwgew0KICBLZXkgYTsNCiAgTGVhZiBhIHuhrX0NCiAg TGVhZiBiIHuhrX0NCiAgTGVhZiBjIHuhrX0NCiAgTGVhZiBkIHuhrX0NCn0NCg0KSWYgYT0gNSBh bmQgYj0xMCBhbmQgYyA+MjAsIHRoZW4gZCBtdXN0IGJlIGxlc3MgdGhhbiAzMCBhbmQgZ3JlYXRl ciB0aGFuIDE1Lg0KSWYgdXNlIHhwYXRoMS4wLCB0aGUgTVVTVCBzdGF0ZW1lbnQgc2hvdWxkIGJl Og0KTXVzdCChsGEgIT0gNQ0KIG9yIGIgIT0gMTANCm9yIGMgPD0yMA0Kb3IgIChhID01IGFuZCBi ID0gMTAgYW5kIGM+MjAgYW5kIGQgPjE1IGFuZCBkIDwgMzApobENCmlmIHVzZSB4cGF0aDMuMDoN Cm11c3QgobBpZiAoYSA9NSBhbmQgYiA9IDEwIGFuZCBjPjIwKQ0KdGhlbiBkPjE1IGFuZCBkPDMw DQplbHNlIHRydWUoKaGxDQoNCiAgaWYgd2UgZmVlbCB4cGF0aDMuMCBpcyB0b28gY29tcGxpY2F0 ZWQsIHdlIGNhbiBzcGVjaWZ5IGEgc21hbGwgc2V0IG9mIHhwYXRoIGdyYW1tYXIgZm9yIFlBTkcu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq367PlDQq7qs6qvLzK9dPQz965 q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dvXQ0KDQpQaG9u ZToNCkZheDoNCk1vYmlsZTogMTg1MTkxMTczMTYNCkVtYWlsOiBmcmFuay5mZW5nY2hvbmdAaHVh d2VpLmNvbQ0KtdjWt6O6xM++qcrQyO28/rTztcAxMDG6xbuqzqrEz76pu/m12CDTyrHgo7oyMTAw MDENCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoNCmh0dHA6Ly93d3cuaHVhd2VpLmNv bQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luq zqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mh o737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY 0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6j rMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwg YW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9t IEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5 IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRl ZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNz ZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQo cykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5k IGRlbGV0ZSBpdCENCg== --_000_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

I = notice draft-ietf-netmod-rfc6020bis-09 still uses xpath1.0 as a notation fo= r checking node references or dependencies.

I = don=A1=AFt know why we don=A1=AFt use xpath3.0 or xpath2.0? xpath3.0 is mor= e powerful than xpath1.0.

Fo= r example, xpath3.0 introduced conditional expression. It=A1=AFs very usefu= l for must statement.

 

If= we have a schema tree like this:

Li= st l {

&n= bsp; Key a;

&n= bsp; Leaf a {=A1=AD}

&n= bsp; Leaf b {=A1=AD}

&n= bsp; Leaf c {=A1=AD}

&n= bsp; Leaf d {=A1=AD}

}<= o:p>

 

If= a=3D 5 and b=3D10 and c >20, then d must be less than 30 and greater th= an 15.

If= use xpath1.0, the MUST statement should be:

Mu= st =A1=B0a !=3D 5

&n= bsp;or b !=3D 10

o= r c <=3D20

o= r  (a =3D5 and b =3D 10 and c>20 and d >15 and d < 30)=A1=B1<= o:p>

if= use xpath3.0:

mu= st =A1=B0if (a =3D5 and b =3D 10 and c>20)

t= hen d>15 and d<30

e= lse true()=A1=B1

 

  if we feel xpath3.0 is t= oo complicated, we can specify a small set of xpath grammar for YANG.<= /o:p>

 

=B7= =EB=B3=E5
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile: 18519117316
Email: frank.fengchong@huawei.com
=B5=D8=D6=B7=A3=BA=C4=CF=BE=A9=CA=D0=C8=ED=BC=FE=B4=F3=B5=C0<= span lang=3D"EN-US">101=BA=C5=BB=AA=CE=AA=C4=CF=BE=A9=BB=F9=B5=D8 = =D3=CA=B1=E0=A3=BA210001
Huawei Technologies Co., Ltd.

http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA= =AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6= =CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5= =C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /o:p>

--_000_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_-- --_004_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 02 Feb 2016 00:32:47 GMT"; modification-date="Tue, 02 Feb 2016 00:32:47 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_5756FB984666AD4BB8E1D63E2E3AA3D0834E1ASZXEMI506MBSchina_-- From nobody Mon Feb 1 17:03:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D301A1AD3 for ; Mon, 1 Feb 2016 17:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 eEiKUy2vE7e5 for ; Mon, 1 Feb 2016 17:03:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 937E91A1ADB for ; Mon, 1 Feb 2016 17:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454374968; bh=ELGCi48yyL/A3QlFZR4Ya5jJ7JfOJVGZW10FpyOQY48=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DYK9ej9S5nO/N7ZVBGff+PngROzQ+DfBcVsS4DEPFIWBrV1atQVCT+1qgh+DpBcsW YZcv0eiFb5ps6jIAV97sMxmNa5KGC3tk8RgY0dGxyIG6hLgLFvZhw7ONH/E7agbdUD NhgfL/oJainzdgjkisy2Ld4k3qbtSYgXOHZNKv/g= 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.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <811E1525-03C8-4118-A91E-2663AB484C78@lucidvision.com> Date: Mon, 1 Feb 2016 20:02:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <811E1525-03C8-4118-A91E-2663AB484C78@lucidvision.com> To: netmod WG X-Mailer: Apple Mail (2.3112) 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=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 263, in=3191, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@tools.ietf.org Subject: Re: [netmod] Mini WG Last Call draft-ietf-netmod-yang-json-07 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, 02 Feb 2016 01:03:02 -0000 The LC has concluded. I=E2=80=99ve received private emails from = Andrew McLachlan and Juergen that they=E2=80=99ve also reviewed the = diffs and are ok with them. At this point the chairs will review the = document and pass it to the IESG shortly.=20 Thank you everyone, =E2=80=94Tom (as WG Co-chair) =20 > On Jan 28, 2016:10:52 AM, at 10:52 AM, Nadeau Thomas = wrote: >=20 >=20 > This message is to officially begin a mini WG last call on = draft-ietf-netmod-yang-json-07. Lada had to make a number of changes to = the document based on feedback from the last call, and so the co-chairs = felt that it was prudent to put this before the WG for a short LC = period. I=E2=80=99d like this period to end on Monday, February 1 at 9AM = EST. Please post comments to the list so that they can be recorded if = any are needed. >=20 > Thank you, >=20 > =E2=80=94Tom (speaking as co-chair) >=20 >=20 From nobody Tue Feb 2 00:38:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E86C1AC3CC for ; Tue, 2 Feb 2016 00:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.841 X-Spam-Level: X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 H104l4XHcPCd for ; Tue, 2 Feb 2016 00:36:00 -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 B4EB21AC3C5 for ; Tue, 2 Feb 2016 00:35:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF87611D2; Tue, 2 Feb 2016 09:35: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 3xlnQ07O6gAN; Tue, 2 Feb 2016 09:35: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; Tue, 2 Feb 2016 09:35:56 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7D722002B; Tue, 2 Feb 2016 09:35:56 +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 8zmSCKHiP9Jt; Tue, 2 Feb 2016 09:35: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 4389720013; Tue, 2 Feb 2016 09:35:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EF24F39D2969; Tue, 2 Feb 2016 09:35:53 +0100 (CET) Date: Tue, 2 Feb 2016 09:35:53 +0100 From: Juergen Schoenwaelder To: "fengchong (C)" Message-ID: <20160202083553.GA13268@elstar.local> Mail-Followup-To: "fengchong (C)" , "netmod@ietf.org" References: <5756FB984666AD4BB8E1D63E2E3AA3D0834E1A@SZXEMI506-MBS.china.huawei.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: <5756FB984666AD4BB8E1D63E2E3AA3D0834E1A@SZXEMI506-MBS.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Why not use xpath3.0 or xpath2.0? 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, 02 Feb 2016 08:36:02 -0000 Moving from xpath 1.0 to a newer version of xpath impacts certain implementations in non-trivial ways. Note that the WG charter says: The NETMOD Working Group will produce a maintenance release of the core YANG specification called YANG 1.1, that is a revision of RFC 6020. The changes to RFC 6020 are restricted in the following ways: - All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules. - All known ambiguities of YANG 1.0 and all reported defects and errata will be addressed. - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. - The changes of the specification will be kept to the minimum necessary to achieve the previously stated goals. Moving to a more powerful version of xpath is out of scope for YANG 1.1. Note that we are wrapping things up, the deadline for submitting feature requests has long passed. /js On Tue, Feb 02, 2016 at 12:32:47AM +0000, fengchong (C) wrote: > Hi all, > I notice draft-ietf-netmod-rfc6020bis-09 still uses xpath1.0 as a notation for checking node references or dependencies. > I don’t know why we don’t use xpath3.0 or xpath2.0? xpath3.0 is more powerful than xpath1.0. > For example, xpath3.0 introduced conditional expression. It’s very useful for must statement. > > If we have a schema tree like this: > List l { > Key a; > Leaf a {…} > Leaf b {…} > Leaf c {…} > Leaf d {…} > } > > If a= 5 and b=10 and c >20, then d must be less than 30 and greater than 15. > If use xpath1.0, the MUST statement should be: > Must “a != 5 > or b != 10 > or c <=20 > or (a =5 and b = 10 and c>20 and d >15 and d < 30)” > if use xpath3.0: > must “if (a =5 and b = 10 and c>20) > then d>15 and d<30 > else true()” > > if we feel xpath3.0 is too complicated, we can specify a small set of xpath grammar for YANG. > > ________________________________ > 冯冲 > 华为技术有限公司 Huawei Technologies Co., Ltd. > [Company_logo] > > Phone: > Fax: > Mobile: 18519117316 > Email: frank.fengchong@huawei.com > 地址：南京市软件大道101号华为南京基地 邮编：210001 > Huawei Technologies Co., Ltd. > > http://www.huawei.com > ________________________________ > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from HUAWEI, which > is intended only for the person or entity whose address is listed above. Any use of the > information contained herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 2 00:51:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF9F1AC3EC for ; Tue, 2 Feb 2016 00:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-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 9GvUMXkmI2MD for ; Tue, 2 Feb 2016 00:51:54 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6341A89FC for ; Tue, 2 Feb 2016 00:51:54 -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 43CAAC327640; Tue, 2 Feb 2016 09:51:50 +0100 (CET) To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <20160201154535.GA11656@elstar.local> <20160201.200800.1399101643067030032.mbj@tail-f.com> <20160201192509.GB12162@elstar.local> <20160201.204828.1537890819794101926.mbj@tail-f.com> From: Jernej Tuljak Message-ID: <56B06E20.8020405@mg-soft.si> Date: Tue, 2 Feb 2016 09:51:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160201.204828.1537890819794101926.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] chars that require quoting 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, 02 Feb 2016 08:51:57 -0000 Martin Bjorklund je 1.2.2016 ob 20:48 napisal: > Juergen Schoenwaelder wrote: >> If a specification is not explicit enough, then people often implement >> what they find implemented in other similar contexts. This means the >> code often ends up reflecting which tools an implementor was familiar >> with. In a shell, echo f\"oo gives you f"oo (and the same is true for >> Tcl, which has otherwise the behavior you implemented for pyang, >> treating " as a regular character in an unquoted string.) >> >> It would help to know what implementations do with identifiers like >> f"o"o and f\"o\"o. If they do different things, then there is likely >> some evidence that implementors arrived at different conclusions. > I don't mind a clarification. How about: > > OLD: > > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. > > NEW: > > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. If a string does not contain any of these characters, it > MAY be unquoted. > > Within an unquoted string, every character is preserved. Note that > this means that the backslash, single quote, and double quote > characters can occur in an unquoted string. I don't think this can be implemented, like I did not in the linked archive. It does not make clear whether these are two statements or a single one: default "; units "; What about this: default ";//foo"; units \"; This is not the C and C++ way of doing things (possibly not even SMIng way). These are the only languages mentioned in the document (Section 6). It also does not promote readability and makes lexers unnecessarily complex. Jernej > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 2 01:04:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7513E1AC445 for ; Tue, 2 Feb 2016 01:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 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, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 BDP3asU5yprX for ; Tue, 2 Feb 2016 01:04: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 100B61AC44E for ; Tue, 2 Feb 2016 01:04:24 -0800 (PST) Received: from [172.20.255.162] (unknown [217.31.205.2]) by mail.nic.cz (Postfix) with ESMTPSA id 07F0F181BC9; Tue, 2 Feb 2016 10:04:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454403861; bh=3Eoz3gbMsfbVfDuBER1C1YgtQlBf41/pAm5RJ/+0i1I=; h=From:Date:To; b=Y6UKA+QnneKo/LueMMTJs7TowDaY9eejF36tzCbK4ue3uy8/ms2D440tk/vG4EHCD y8VsNXnLmmyRpEYXNeg++n+HfhY9N4yD9UcdVCHwW1jTbfA8lJq9nPPF/gDzO/aKDG +WuXfekcUrw0doElyFq/QqCRd7yCp0i0ENxE5gUg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160201.204828.1537890819794101926.mbj@tail-f.com> Date: Tue, 2 Feb 2016 10:04:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76566B20-593A-4944-8EF5-A1D263890DFC@nic.cz> References: <20160201154535.GA11656@elstar.local> <20160201.200800.1399101643067030032.mbj@tail-f.com> <20160201192509.GB12162@elstar.local> <20160201.204828.1537890819794101926.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] chars that require quoting 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, 02 Feb 2016 09:04:29 -0000 > On 01 Feb 2016, at 20:48, Martin Bjorklund wrote: >=20 > Juergen Schoenwaelder wrote: >> If a specification is not explicit enough, then people often = implement >> what they find implemented in other similar contexts. This means the >> code often ends up reflecting which tools an implementor was familiar >> with. In a shell, echo f\"oo gives you f"oo (and the same is true for >> Tcl, which has otherwise the behavior you implemented for pyang, >> treating " as a regular character in an unquoted string.) >>=20 >> It would help to know what implementations do with identifiers like >> f"o"o and f\"o\"o. If they do different things, then there is likely >> some evidence that implementors arrived at different conclusions. >=20 > I don't mind a clarification. How about: >=20 > OLD: >=20 > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. >=20 > NEW:=20 >=20 > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. If a string does not contain any of these characters, it > MAY be unquoted. >=20 > Within an unquoted string, every character is preserved. Note that > this means that the backslash, single quote, and double quote > characters can occur in an unquoted string. For the reasons that I explained earlier, I think that allowing single = and double quotes in unquoted strings is a bug. This text makes it into = a feature, so I am objecting to it. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 01:16:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677991ACCEC for ; Tue, 2 Feb 2016 01:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 td7eJLbeNIKQ for ; Tue, 2 Feb 2016 01:16: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 7D3D31ACCE9 for ; Tue, 2 Feb 2016 01:16:50 -0800 (PST) Received: from [172.20.255.162] (unknown [217.31.205.2]) by mail.nic.cz (Postfix) with ESMTPSA id 9FF451803A5; Tue, 2 Feb 2016 10:16:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454404607; bh=okNC08hgCaZvl9nEhzjHBN79LqrouiR5ubyZfsapVf0=; h=From:Date:To; b=THRGWgTZIfiCM8ZPjHEEf3zXa2lZx7zhiST80H5k4+7BBTEvTSINyswNjf1btWXVU ucqg5rMPsMKx0wXJ1jkYr1FuyZshIRK+k612imxoqjEck7Yg0Y3lP2v6E1LGbz4shv +VDSdEcFaPzl17M2CGZbLkhWso+heqBBu3kKgxRE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56B06E20.8020405@mg-soft.si> Date: Tue, 2 Feb 2016 10:16:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> References: <20160201154535.GA11656@elstar.local> <20160201.200800.1399101643067030032.mbj@tail-f.com> <20160201192509.GB12162@elstar.local> <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@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] chars that require quoting 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, 02 Feb 2016 09:16:55 -0000 > On 02 Feb 2016, at 09:51, Jernej Tuljak = wrote: >=20 > Martin Bjorklund je 1.2.2016 ob 20:48 napisal: >> Juergen Schoenwaelder wrote: >>> If a specification is not explicit enough, then people often = implement >>> what they find implemented in other similar contexts. This means the >>> code often ends up reflecting which tools an implementor was = familiar >>> with. In a shell, echo f\"oo gives you f"oo (and the same is true = for >>> Tcl, which has otherwise the behavior you implemented for pyang, >>> treating " as a regular character in an unquoted string.) >>>=20 >>> It would help to know what implementations do with identifiers like >>> f"o"o and f\"o\"o. If they do different things, then there is likely >>> some evidence that implementors arrived at different conclusions. >> I don't mind a clarification. How about: >>=20 >> OLD: >>=20 >> If a string contains any space, tab, or newline characters, a >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >> "/*", or "*/"), then it MUST be enclosed within double or single >> quotes. >>=20 >> NEW: >>=20 >> If a string contains any space, tab, or newline characters, a >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >> "/*", or "*/"), then it MUST be enclosed within double or single >> quotes. If a string does not contain any of these characters, it >> MAY be unquoted. >>=20 >> Within an unquoted string, every character is preserved. Note that >> this means that the backslash, single quote, and double quote >> characters can occur in an unquoted string. >=20 > I don't think this can be implemented, like I did not in the linked = archive. It does not make clear whether these are two statements or a = single one: >=20 > default "; > units "; >=20 >=20 > What about this: >=20 > default ";//foo"; > units \"; >=20 >=20 > This is not the C and C++ way of doing things (possibly not even SMIng = way). These are the only languages mentioned in the document (Section = 6). It also does not promote readability and makes lexers unnecessarily = complex. +1 I think the safest solution would be to disallow in unquoted strings all = characters that have a special meaning anywhere in YANG syntax. This can = hardly cause any troubles to module authors. BTW, if we wanted to be extremely liberal, I don't understand why the = end-comment sequence "*/" is not allowed. Lada >=20 > Jernej >=20 >>=20 >> /martin >>=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 Tue Feb 2 02:20:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755BF1A8A59 for ; Tue, 2 Feb 2016 02:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 G84PNAZNt4Jg for ; Tue, 2 Feb 2016 02:20:41 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0107.outbound.protection.outlook.com [104.47.1.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5445C1ACE37 for ; Tue, 2 Feb 2016 02:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4IL5fk8jN7+X6/7ozaExagyuMN8GRKDcmfU0R1Zi9EA=; b=JkjAeTg23olOxGu0nbZPQQMU4yKUz5MKRImdWYMAkBK2tTNKPETNOiUl/2cGuy1it4PQkPsMm18rW3XscugGc1n6dG1fAZgB6LwmVo8+oQnS57K3Sr7wLrUx84VfBIefemsW9CjcgjQeFpFhNI1PFJBhAlqe7/7OoETDn8ntrSw= Authentication-Results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.396.15; Tue, 2 Feb 2016 10:20:36 +0000 Message-ID: <02ce01d15da2$ec979fe0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Andy Bierman , , Robert Wilton References: <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net> <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz> <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz> <56991258.1030204@cisco.com> <20160117095210.GA87004@elstar.local> <569C13BC.6040507@wilton.org.uk> Date: Tue, 2 Feb 2016 10:17:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB5PR03CA0051.eurprd03.prod.outlook.com (25.164.34.19) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 2:L8OctgA6A9tVSUmUtU95tMZZvc5aObCk9TpU71/K5noriiRowHMDaKIqj7xywAR2rKtGSi3irS+HMlGAKLuwtKQhneW1Y2xySw7w/p/ujDWzAUSqyDL5R3nCM1zc/Dq5f4i/rNF6KdqsZWPK41Emuw==; 3:ZymyFWtAp5bJfWTxCx4QRJkCl1ds20EWKQUjZTrsjg3C4kAi6kSko+VhigqK2amAbGTU3rodFXk4/1ThaGNR5cY56XPcppsfSNjjPEPQK5/UwCFFC3oChK4Vmt0KnRaN; 25:RAKIUsGIekIRvbKlxXY+ui7wKQIOJNpVcVvSB/x+B8JmPtLX5pX5BDiHo7/UcXT6njnRv5UyOthKbcvVaMjIMgIh+cKt5SB/VariWOkFt2ira8fW+hT7Y/9RNEWdMK2gH9oqbwmEn4qZ8CRtASpAZAbsyVHqoYEzj1WXIOpyOeHm1goFowiOq516gMaQhu2vuEFjgxr1u0qQpG+2JWbzm0ThFP0zUp+uhYPlx4sUMJd4z1qNEQdiMUS6BZClt1LT; 4:nHKu/U3Xv9ixbxPzwFQJ8svQpFXcCX94KqY4D88r8g2yJKUf9byqROs0F5TtGy9Y03H2dEO84T1E2FG+EAVB38ZGjSG7kVYRYTMSypQWlCFe7/K0zAMKrGrL+C23MnHtKBSFU39wonW0ioXiKCtx2e/J2/bFrVFGR0S/QFaOK3LeLkUbqWuZK1rMc3T/umqMdcQrNmlfgwphC+yYTmsnfjepxsV+xrWgYKrp0noUZrYh1Rtb31GohmtdklVncwzehHsqx+3DEPO0GFohv3L4gORDioqG8gExoVZMMrdDo/heWfCrtr8ESYQcUfa8hE4WekL7HQH8ZJXTKKBp/QTOXRyUW+FipAAHnoS5lDWpxlV2H6aepgMly/XuSVGGaCb9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-MS-Office365-Filtering-Correlation-Id: 493125dc-86f7-4c10-9fbd-08d32bba7de7 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)(10201501046)(3002001); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 084080FC15 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51444003)(377424004)(377454003)(479174004)(24454002)(14496001)(66066001)(47776003)(40100003)(1556002)(87976001)(62236002)(44716002)(189998001)(33646002)(4001150100001)(23756003)(116806002)(61296003)(93886004)(5004730100002)(92566002)(6116002)(5008740100001)(3846002)(586003)(50226001)(84392002)(1096002)(2906002)(44736004)(122386002)(86362001)(50986999)(77096005)(76176999)(107886002)(5001960100002)(81156007)(50466002)(19580405001)(81816999)(5001770100001)(230700001)(19580395003)(81686999)(1456003)(42186005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB056; 23:XcTWIN1lJvQoe69dfCiExLgbnO0PZlTLvcgSiVxG?= =?iso-8859-1?Q?55zAc/GIqHiAjiRKYzmIQbxbLB/5FfCaaS9yTAN7I2euSmmo+PcQVYbV9C?= =?iso-8859-1?Q?zy7FfGi6e9QXb03z5UKsjKiwU4EdoVyf0fmk63TwvKH5uuHdGivzkf2lH0?= =?iso-8859-1?Q?5tbCiRHft87fCofvYzC314ECMVuukS9QtNNHomjC3R5VhlA7gfUcf8pMdP?= =?iso-8859-1?Q?7x9U5wBoXG77NEExdMjGnx2I4JWUOUDb3pNBlFIPvk4t85fspIUX4RtIXb?= =?iso-8859-1?Q?lDLSJGsMz8LH4XCPIBochmmJoLlFfZ5QdXQT1M86ToP4djrqN0xKZMk2hc?= =?iso-8859-1?Q?li05dkicST80hlMKxPRTryE7L4UA9hLHYwwboEpa+PCvvRPg8SVdTtBHgC?= =?iso-8859-1?Q?z2uWHSr4IAX8vO8GWKQDg6glbWy6dvMhXTnVSgurtRdE+/xmOvaq6aLGKc?= =?iso-8859-1?Q?sesT9wnC0MbVim5fypbX4anjqRmx4lZLhA5jATJR+h2SjfbBKc8IOgBtyr?= =?iso-8859-1?Q?UG8iRQYtAAUxrvC16W9eS1MGppzIwVOXsSK5ipmBDhZ/69YcKq0MrJ2Mk9?= =?iso-8859-1?Q?JpmYISXr+QRLC+HKhpbDUYWPgP/y5JtTpFITZVoktMxMGln+9G7WGMXqgi?= =?iso-8859-1?Q?uEmzBhrEtqeMW9h+hiBYiBbWB5TJ98xTFkBMjh7L/UfcRnyu3VsyzDcO14?= =?iso-8859-1?Q?0Se4qxMYfC6TBYoExBqPP62j/Qfu5Ea4g6V4ndOenAaAC18fRcDSC9fuHt?= =?iso-8859-1?Q?+f3Cxe8DmD1b6b4uyz315IYl7gCaEWCWkQtrNI15OecdAKe9QVrD8ptBjw?= =?iso-8859-1?Q?akVGqwsH0cGS3ufMBapOPuT0H2HHhxwQ7GrWKERkvtT177pYxH4cQyzv3V?= =?iso-8859-1?Q?t99nKmrMKpqGIV8d60v2iq+Gro+PLPhljgLBrecIAOXHy3JRLDjWtPZw9k?= =?iso-8859-1?Q?mlZJsSZq44BLzqS8n7teXlwmMi5omBSDZTcd4upVlMwHALrLzsWjgNTT5T?= =?iso-8859-1?Q?oFRDwk+mwgdEF3/BbvopqaLSD45szHTnzqnKblM8w7lmkN5FPoM2ykoa8H?= =?iso-8859-1?Q?8GJEZOmYMryapoHAhubr7W+wDWNM9Bm2H20kFNf8qWCLIE6pAMpOf9YE0M?= =?iso-8859-1?Q?ovpwBYjaaQMRedsWNONO+QLArPeMTD6nQs0FOHL4QzT1MCudj3QhHEFZZA?= =?iso-8859-1?Q?uYWHYUlt88+Np+jtJz5MPqVvsc+ENB0H+/vRRO8ZZnXA99hq94ZLHmGvFM?= =?iso-8859-1?Q?Y43hMzoNUbRlumjLSwZV03CCs2LVw4+6wiErJ60BH/DeUjP0KVEYv2yKjw?= =?iso-8859-1?Q?0Exsq59TkQiGzp6zF0ICwFx+HyOz2DTREX4k8Q0wYWHbMYN0HceYjsoXPy?= =?iso-8859-1?Q?OL9fYzGE78Hh1anA6vvanBT4yc1k?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 5:ZXFBYcHb2EtieQUqARhtHNfX2+eK+jVXdga905/DsMVIx42TkZNvHQJewt2V+Gbgcf6AM5Fftkp47v4yqV+svvRyb9Lp2Z1tMkzdvLedDBsdZShprA8khSMG8/ipcmI6DdoO9TPzt8T139j9SSkx9w==; 24:g4dLA0/9mpn6OG7ypHZ9H14CFGrDfnUWVJ8zaPOqXfDb/VlSgndNS+4oFIGKtSWvXOat6rmst0h8Le2+9b0UejFfoTGT9Ahpr0AVKRBQ0Xo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2016 10:20:36.2027 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Subject: Re: [netmod] 6087bis namespace recommendations 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, 02 Feb 2016 10:20:49 -0000 ----- Original Message ----- From: "Robert Wilton" To: "Ladislav Lhotka" ; "Andy Bierman" ; Sent: Sunday, January 17, 2016 10:20 PM > On 17/01/2016 09:52, Juergen Schoenwaelder wrote: > > On Fri, Jan 15, 2016 at 03:38:00PM +0000, Robert Wilton wrote: > >> Since an ID is effectively superseded by any new versions, I think that > >> it is useful if a module defined in an ID has a revision date that > >> matches the published ID, and also a reference back to the ID version > >> that defines it. At least if someone ends up implementing that module > >> they can check its provenance. Both of these properties would also be > >> verifiable by idnits. > >> > > Right now, we seem in the "hey lets invent more rules mode" and > > tomorrow I am sure we are again in the "hey the IETF is way to > > complicated to work in" mode. > This was the approach that I followed when posting and updating the > drafts that I was working on, perhaps mis-understanding the statement > "The revision statement MUST have a reference substatement. It MUST > identify the published document that contains the module." for which I > presumed that the "published document" also includes the version number. > > > If you have a unique revision date, why is google and the like not > > sufficient to find the matching I-D? Sure, the proposed rule itself > > does not hurt, but an increasingly large collection of rules may start > > to hurt. So please, lets try to find the minimum number of rules where > > we have evidence that they avoid big problems. > I'm also against having too many rules to follow, it starts to make the > process too laborious. > > My assumption is that given the relatively slow pace that standards > models are being formally standardized that vendors/operators are likely > to want/need to temporarily ship with pre-standard versions of the > models. Hence, in this case I personally feel that the additional > clarity that is gained by explicitly referencing both date and full > document name outweighs the slight hassle in updating it when a new > version of the draft is posted. I was looking at draft-liang-rtgwg-staticrt-yang-cfg-00 which contains " file "ietf-staticrt@2015-10-16.yang" .... revision 2015-10-17 { description "Initial revision."; reference " [draft-ietf-netmod-routing-cfg-16] A YANG Data Model for Routing Management. "; and then I looked at draft-liang-rtgwg-staticrt-yang-cfg-01 which contains " file "ietf-staticrt@2015-10-16.yang" ..... revision 2015-10-16 { description "Initial revision."; reference " [draft-ietf-netmod-routing-cfg-16] A YANG Data Model for Routing Management. "; mmmm I think that this happens, and quite often. There is a gap between getting what seems to us a good set of conventions out into an RFC and getting those adopted, especially when there is nothing to catch what, to us, may seem obvious flaws. Automation, by the tools team, seems the obvious answer. The second I-D was published on 2015-12-16 which, assuming a typo, accounts for some, but not all, of the quirks. In passing, s.4.1 has an example containing description "Latest revision"; True, and it could have said "Current revision" or "Most recent revision" or ... I would change that to, say, "Revised after comments on the use of opstate" (or some such). Tom Petch > > Rob > > > > > /js From nobody Tue Feb 2 03:16:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37441AE4CB for ; Tue, 2 Feb 2016 03:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-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 oimb7YOBJG8Q for ; Tue, 2 Feb 2016 03:16: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 CA4061ADEB6 for ; Tue, 2 Feb 2016 03:16:25 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 075831AE0285; Tue, 2 Feb 2016 12:16:23 +0100 (CET) Date: Tue, 02 Feb 2016 12:16:27 +0100 (CET) Message-Id: <20160202.121627.103563641669027534.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@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] chars that require quoting 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, 02 Feb 2016 11:16:28 -0000 Ladislav Lhotka wrote: > > > On 02 Feb 2016, at 09:51, Jernej Tuljak wrote: > > > > Martin Bjorklund je 1.2.2016 ob 20:48 napisal: > >> Juergen Schoenwaelder wrote: > >>> If a specification is not explicit enough, then people often implement > >>> what they find implemented in other similar contexts. This means the > >>> code often ends up reflecting which tools an implementor was familiar > >>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for > >>> Tcl, which has otherwise the behavior you implemented for pyang, > >>> treating " as a regular character in an unquoted string.) > >>> > >>> It would help to know what implementations do with identifiers like > >>> f"o"o and f\"o\"o. If they do different things, then there is likely > >>> some evidence that implementors arrived at different conclusions. > >> I don't mind a clarification. How about: > >> > >> OLD: > >> > >> If a string contains any space, tab, or newline characters, a > >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > >> "/*", or "*/"), then it MUST be enclosed within double or single > >> quotes. > >> > >> NEW: > >> > >> If a string contains any space, tab, or newline characters, a > >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > >> "/*", or "*/"), then it MUST be enclosed within double or single > >> quotes. If a string does not contain any of these characters, it > >> MAY be unquoted. > >> > >> Within an unquoted string, every character is preserved. Note that > >> this means that the backslash, single quote, and double quote > >> characters can occur in an unquoted string. > > > > I don't think this can be implemented, like I did not in the linked archive. It does not make clear whether these are two statements or a single one: > > > > default "; > > units "; > > > > > > What about this: > > > > default ";//foo"; > > units \"; > > > > > > This is not the C and C++ way of doing things (possibly not even SMIng way). These are the only languages mentioned in the document (Section 6). It also does not promote readability and makes lexers unnecessarily complex. > > +1 > > I think the safest solution would be to disallow in unquoted strings > all characters that have a special meaning anywhere in YANG > syntax. This can hardly cause any troubles to module authors. Fine with me. Something like: NEW: If a string contains any space, tab, or newline characters, a single or double quote, semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes. If a string does not contain any of these characters, it MAY be unquoted. Within an unquoted string, every character is preserved. Note that this means that the backslash character does not have any special meaning in an unquoted string. It should be noted that this may be viewed as a backwards incompatible change, but I think it is similar to the change for escaped characters in double quoted string ("backwards incompatible bugfix"). /martin > > BTW, if we wanted to be extremely liberal, I don't understand why the end-comment sequence "*/" is not allowed. > > Lada > > > > > Jernej > > > >> > >> /martin > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Feb 2 03:21:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA11B29AB for ; Tue, 2 Feb 2016 03:21:18 -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, RP_MATCHES_RCVD=-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 xf-YPSAnY0t2 for ; Tue, 2 Feb 2016 03:21: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 5E7E21B29A5 for ; Tue, 2 Feb 2016 03:21:17 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 82E051AE0285; Tue, 2 Feb 2016 12:21:16 +0100 (CET) Date: Tue, 02 Feb 2016 12:21:19 +0100 (CET) Message-Id: <20160202.122119.1113615933596185736.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56AB2736.3020701@cisco.com> References: <56AA6492.7090802@joelhalpern.com> <20160128200139.GA3747@elstar.local> <56AB2736.3020701@cisco.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] minor question - YANG Document Guidelines: Imports 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, 02 Feb 2016 11:21:19 -0000 Robert Wilton wrote: > On 28/01/2016 20:01, Juergen Schoenwaelder wrote: > > On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: > >> I ran into something while reading a YANG internet-draft recently, and > >> I > >> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) > >> would be reasonable. > >> > >> Section 4.8 of the guidelines states that any imported modules must > >> also > >> have a reference in the references section. Which is good. But there > >> is no obvious way for a human reader to relate the two. > >> > >> Would it be sensible to recommend in this document (I don't know if it > >> would be 4.8 or a new section later in the document) that import > >> statements have a comment with them either naming the internet draft / > >> RFC they are importing from, or pointing to the reference which names > >> it? > >> > > Perhaps RFC 6087bis can give additional guidelines. The common way to > > get the references into the enclosing document is to include a > > statement before the definitions that says something like: > > > > This module imports from the defined in > > [RFCXYZ] and form the defined in [RFCABC]. > > > > To help readers that have the module and who do not want to bother > > looking up the document, including comments may help. It is kind of > > funny that YANG does not allow reference statements on imports... > It is too late to add this to Yang 1.1? > > That would seem to be the cleanest solution. It seems to me that allowing "reference" under "import" (and "include") is a "safe" change, i.e., I support adding it even though it is pretty late in the process. One thing to note is that in the current grammar, "reference" and "description" are always allowed together - does it make sense to allow "description" in the import/include as well? /martin > > I was under the, possibly mistaken, assumption that various YANG tools > effectively ignore/strip out the comments and hence comments are > better embedded directly in the model as either reference or > description statements. > > Rob > > > > > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 2 03:26:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE851B29B6 for ; Tue, 2 Feb 2016 03:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 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, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 LCMYIhOMsStx for ; Tue, 2 Feb 2016 03:26:00 -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 EFD7A1B29B4 for ; Tue, 2 Feb 2016 03:25:59 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c] (unknown [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c]) by mail.nic.cz (Postfix) with ESMTPSA id 89041180A02; Tue, 2 Feb 2016 12:25:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454412357; bh=cfxE4m1ZN0ZTkRC9xvzJky1QSQQ4FsVksUty0C6bHaM=; h=From:Date:To; b=oCZY4Xv5smgjhulL4H6WkkwgspAqHqhtjxxXbY/Vit5033dDsCTPr4qI6p8KDCSNQ +yoGTmDvzidLDy+1hYNVelBw68XEL3otP0lDDWFASuuj+LdOG48S38xtucKHEFl34f z3zg0CjfRH+TBKy5a5jrdVgUV5rNA8HN7/eiZUoE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160202.121627.103563641669027534.mbj@tail-f.com> Date: Tue, 2 Feb 2016 12:25:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.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] chars that require quoting 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, 02 Feb 2016 11:26:02 -0000 > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 02 Feb 2016, at 09:51, Jernej Tuljak = wrote: >>>=20 >>> Martin Bjorklund je 1.2.2016 ob 20:48 napisal: >>>> Juergen Schoenwaelder wrote: >>>>> If a specification is not explicit enough, then people often = implement >>>>> what they find implemented in other similar contexts. This means = the >>>>> code often ends up reflecting which tools an implementor was = familiar >>>>> with. In a shell, echo f\"oo gives you f"oo (and the same is true = for >>>>> Tcl, which has otherwise the behavior you implemented for pyang, >>>>> treating " as a regular character in an unquoted string.) >>>>>=20 >>>>> It would help to know what implementations do with identifiers = like >>>>> f"o"o and f\"o\"o. If they do different things, then there is = likely >>>>> some evidence that implementors arrived at different conclusions. >>>> I don't mind a clarification. How about: >>>>=20 >>>> OLD: >>>>=20 >>>> If a string contains any space, tab, or newline characters, a >>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>> quotes. >>>>=20 >>>> NEW: >>>>=20 >>>> If a string contains any space, tab, or newline characters, a >>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>> quotes. If a string does not contain any of these characters, it >>>> MAY be unquoted. >>>>=20 >>>> Within an unquoted string, every character is preserved. Note = that >>>> this means that the backslash, single quote, and double quote >>>> characters can occur in an unquoted string. >>>=20 >>> I don't think this can be implemented, like I did not in the linked = archive. It does not make clear whether these are two statements or a = single one: >>>=20 >>> default "; >>> units "; >>>=20 >>>=20 >>> What about this: >>>=20 >>> default ";//foo"; >>> units \"; >>>=20 >>>=20 >>> This is not the C and C++ way of doing things (possibly not even = SMIng way). These are the only languages mentioned in the document = (Section 6). It also does not promote readability and makes lexers = unnecessarily complex. >>=20 >> +1 >>=20 >> I think the safest solution would be to disallow in unquoted strings >> all characters that have a special meaning anywhere in YANG >> syntax. This can hardly cause any troubles to module authors. >=20 > Fine with me. Something like: >=20 > NEW:=20 >=20 > If a string contains any space, tab, or newline characters, a single > or double quote, semicolon (";"), braces ("{" or "}"), or comment > sequences ("//", "/*", or "*/"), then it MUST be enclosed within > double or single quotes. If a string does not contain any of these > characters, it MAY be unquoted. >=20 > Within an unquoted string, every character is preserved. Note that > this means that the backslash character does not have any special > meaning in an unquoted string. I like this. >=20 >=20 > It should be noted that this may be viewed as a backwards incompatible > change, but I think it is similar to the change for escaped characters > in double quoted string ("backwards incompatible bugfix"). Yes, I think so. Thanks, Lada >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> BTW, if we wanted to be extremely liberal, I don't understand why the = end-comment sequence "*/" is not allowed. >>=20 >> Lada >>=20 >>>=20 >>> Jernej >>>=20 >>>>=20 >>>> /martin >>>>=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 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 03:27:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92121B29BC for ; Tue, 2 Feb 2016 03:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 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, RP_MATCHES_RCVD=-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 9sNLVHe-sGoz for ; Tue, 2 Feb 2016 03:27: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 27D781B29BA for ; Tue, 2 Feb 2016 03:27:34 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c] (unknown [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c]) by mail.nic.cz (Postfix) with ESMTPSA id B8569181A1D; Tue, 2 Feb 2016 12:27:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454412452; bh=Bnqi0q4AjE1Czdw6RgMrDZQGnJyBT1xp7Fio/iNOcdw=; h=From:Date:To; b=FRjx8leLjf/uEY8Nd5wC9Wzx147h0dxroQtbCyF9afWHOml0WbSLO10EUECVaEc4l CJaajXc0gLMuxtZy504rq57rzfVUx4jtsAvsPNXiWTqDP2YIvgxyhJLRNOdW58Xu5u jaxlEAeqzMHRjAon49h5QI2wcVNueFbEI62UZWRY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160202.122119.1113615933596185736.mbj@tail-f.com> Date: Tue, 2 Feb 2016 12:27:32 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <56AA6492.7090802@joelhalpern.com> <20160128200139.GA3747@elstar.local> <56AB2736.3020701@cisco.com> <20160202.122119.1113615933596185736.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] minor question - YANG Document Guidelines: Imports 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, 02 Feb 2016 11:27:37 -0000 > On 02 Feb 2016, at 12:21, Martin Bjorklund wrote: > > Robert Wilton wrote: >> On 28/01/2016 20:01, Juergen Schoenwaelder wrote: >>> On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: >>>> I ran into something while reading a YANG internet-draft recently, and >>>> I >>>> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) >>>> would be reasonable. >>>> >>>> Section 4.8 of the guidelines states that any imported modules must >>>> also >>>> have a reference in the references section. Which is good. But there >>>> is no obvious way for a human reader to relate the two. >>>> >>>> Would it be sensible to recommend in this document (I don't know if it >>>> would be 4.8 or a new section later in the document) that import >>>> statements have a comment with them either naming the internet draft / >>>> RFC they are importing from, or pointing to the reference which names >>>> it? >>>> >>> Perhaps RFC 6087bis can give additional guidelines. The common way to >>> get the references into the enclosing document is to include a >>> statement before the definitions that says something like: >>> >>> This module imports from the defined in >>> [RFCXYZ] and form the defined in [RFCABC]. >>> >>> To help readers that have the module and who do not want to bother >>> looking up the document, including comments may help. It is kind of >>> funny that YANG does not allow reference statements on imports... >> It is too late to add this to Yang 1.1? >> >> That would seem to be the cleanest solution. > > It seems to me that allowing "reference" under "import" (and > "include") is a "safe" change, i.e., I support adding it even though > it is pretty late in the process. > > One thing to note is that in the current grammar, "reference" and > "description" are always allowed together - does it make sense to > allow "description" in the import/include as well? IMO, yes. Lada > > > /martin > > >> >> I was under the, possibly mistaken, assumption that various YANG tools >> effectively ignore/strip out the comments and hence comments are >> better embedded directly in the model as either reference or >> description statements. >> >> Rob >> >> >>> >>> /js >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 03:39:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CEC1B29E3 for ; Tue, 2 Feb 2016 03:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 rZ-f5VVgKygH for ; Tue, 2 Feb 2016 03:39:39 -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 565AF1B29E9 for ; Tue, 2 Feb 2016 03:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2947; q=dns/txt; s=iport; t=1454413179; x=1455622779; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3gydRgqQznGyjbqmwa+ZjjWvgujzLtptoO7H8akaJXs=; b=QT82G492cSv+0tdFxHxTVC6brdl1+Wxuiz2mUqQeYLn7AI9GwLsj7NB+ 1eA0yXavFFc8mCWmJ1eJ0D/d8SA8OM41QX6NW48pTMlGnpB4Aj30ugXe2 SjmoJAVp5Qoz9BuhelQWeFDBARWPPG8zsPe5E68p9VjyHeg3ne3PnkP8a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAZlbBW/xbLJq1ehAxtiFmzXBcKh?= =?us-ascii?q?SJKAoINAQEBAQEBgQuEQgEBBAEBATU2CgEQCw4KCRYPCQMCAQIBFTAGDQYCAQE?= =?us-ascii?q?XiAAOvgQBAQEBAQEBAQEBAQEBAQEBAQEBARIEhg+EN4hsAQSWcY1LiSCFUY4/Y?= =?us-ascii?q?oNkPC6JawEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="scan'208";a="623973639" 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; 02 Feb 2016 11:39:34 +0000 Received: from [10.63.23.102] (dhcp-ensft1-uk-vla370-10-63-23-102.cisco.com [10.63.23.102]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u12BdY2f026367; Tue, 2 Feb 2016 11:39:34 GMT To: Martin Bjorklund References: <56AA6492.7090802@joelhalpern.com> <20160128200139.GA3747@elstar.local> <56AB2736.3020701@cisco.com> <20160202.122119.1113615933596185736.mbj@tail-f.com> From: Robert Wilton Message-ID: <56B09576.6080407@cisco.com> Date: Tue, 2 Feb 2016 11:39:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160202.122119.1113615933596185736.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] minor question - YANG Document Guidelines: Imports 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, 02 Feb 2016 11:39:41 -0000 On 02/02/2016 11:21, Martin Bjorklund wrote: > Robert Wilton wrote: >> On 28/01/2016 20:01, Juergen Schoenwaelder wrote: >>> On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: >>>> I ran into something while reading a YANG internet-draft recently, and >>>> I >>>> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) >>>> would be reasonable. >>>> >>>> Section 4.8 of the guidelines states that any imported modules must >>>> also >>>> have a reference in the references section. Which is good. But there >>>> is no obvious way for a human reader to relate the two. >>>> >>>> Would it be sensible to recommend in this document (I don't know if it >>>> would be 4.8 or a new section later in the document) that import >>>> statements have a comment with them either naming the internet draft / >>>> RFC they are importing from, or pointing to the reference which names >>>> it? >>>> >>> Perhaps RFC 6087bis can give additional guidelines. The common way to >>> get the references into the enclosing document is to include a >>> statement before the definitions that says something like: >>> >>> This module imports from the defined in >>> [RFCXYZ] and form the defined in [RFCABC]. >>> >>> To help readers that have the module and who do not want to bother >>> looking up the document, including comments may help. It is kind of >>> funny that YANG does not allow reference statements on imports... >> It is too late to add this to Yang 1.1? >> >> That would seem to be the cleanest solution. > It seems to me that allowing "reference" under "import" (and > "include") is a "safe" change, i.e., I support adding it even though > it is pretty late in the process. > > One thing to note is that in the current grammar, "reference" and > "description" are always allowed together - does it make sense to > allow "description" in the import/include as well? I would say yes. I can't see that it would cause any harm, nor does it look like it would be particularly burdensome to implement. E.g. it could be a useful way of documenting if an import was only required for a slightly more obscure reason. In general it feels like documenting the YANG model using descriptions/references is probably better than comments which are likely to only be available in the YANG source file and then get stripped out during parsing. Rob > > > /martin > > >> I was under the, possibly mistaken, assumption that various YANG tools >> effectively ignore/strip out the comments and hence comments are >> better embedded directly in the model as either reference or >> description statements. >> >> Rob >> >> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > . > From nobody Tue Feb 2 04:05:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7561B2A55 for ; Tue, 2 Feb 2016 04:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 LwF_NfHur6OC for ; Tue, 2 Feb 2016 04:04:57 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 600AB1B2A52 for ; Tue, 2 Feb 2016 04:04:55 -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 2EF1EC001FE1; Tue, 2 Feb 2016 13:04:52 +0100 (CET) To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> From: Jernej Tuljak Message-ID: <56B09B5D.3000907@mg-soft.si> Date: Tue, 2 Feb 2016 13:04:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] chars that require quoting 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, 02 Feb 2016 12:04:59 -0000 Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: >> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>>> On 02 Feb 2016, at 09:51, Jernej Tuljak wrote: >>>> >>>> Martin Bjorklund je 1.2.2016 ob 20:48 napisal: >>>>> Juergen Schoenwaelder wrote: >>>>>> If a specification is not explicit enough, then people often implement >>>>>> what they find implemented in other similar contexts. This means the >>>>>> code often ends up reflecting which tools an implementor was familiar >>>>>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for >>>>>> Tcl, which has otherwise the behavior you implemented for pyang, >>>>>> treating " as a regular character in an unquoted string.) >>>>>> >>>>>> It would help to know what implementations do with identifiers like >>>>>> f"o"o and f\"o\"o. If they do different things, then there is likely >>>>>> some evidence that implementors arrived at different conclusions. >>>>> I don't mind a clarification. How about: >>>>> >>>>> OLD: >>>>> >>>>> If a string contains any space, tab, or newline characters, a >>>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>>> quotes. >>>>> >>>>> NEW: >>>>> >>>>> If a string contains any space, tab, or newline characters, a >>>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>>> quotes. If a string does not contain any of these characters, it >>>>> MAY be unquoted. >>>>> >>>>> Within an unquoted string, every character is preserved. Note that >>>>> this means that the backslash, single quote, and double quote >>>>> characters can occur in an unquoted string. >>>> I don't think this can be implemented, like I did not in the linked archive. It does not make clear whether these are two statements or a single one: >>>> >>>> default "; >>>> units "; >>>> >>>> >>>> What about this: >>>> >>>> default ";//foo"; >>>> units \"; >>>> >>>> >>>> This is not the C and C++ way of doing things (possibly not even SMIng way). These are the only languages mentioned in the document (Section 6). It also does not promote readability and makes lexers unnecessarily complex. >>> +1 >>> >>> I think the safest solution would be to disallow in unquoted strings >>> all characters that have a special meaning anywhere in YANG >>> syntax. This can hardly cause any troubles to module authors. >> Fine with me. Something like: >> >> NEW: >> >> If a string contains any space, tab, or newline characters, a single >> or double quote, semicolon (";"), braces ("{" or "}"), or comment >> sequences ("//", "/*", or "*/"), then it MUST be enclosed within >> double or single quotes. If a string does not contain any of these >> characters, it MAY be unquoted. >> >> Within an unquoted string, every character is preserved. Note that >> this means that the backslash character does not have any special >> meaning in an unquoted string. > I like this. +1 > >> >> It should be noted that this may be viewed as a backwards incompatible >> change, but I think it is similar to the change for escaped characters >> in double quoted string ("backwards incompatible bugfix"). > Yes, I think so. This is nothing compared to the change of the accessible tree for output. Jernej > > Thanks, Lada > >> >> >> /martin >> >> >> >>> BTW, if we wanted to be extremely liberal, I don't understand why the end-comment sequence "*/" is not allowed. >>> >>> Lada >>> >>>> Jernej >>>> >>>>> /martin >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From nobody Tue Feb 2 05:57:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11661B2AFF for ; Tue, 2 Feb 2016 05:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 S5hY-ics68WZ for ; Tue, 2 Feb 2016 05:57:50 -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 C3ED61B2AFE for ; Tue, 2 Feb 2016 05:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3209; q=dns/txt; s=iport; t=1454421469; x=1455631069; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4C9HpIVrXze7lwOrmIz0mAkMOC4JM9C+oAOci08NVME=; b=ECnRshMu+N7fItM1hPONdWi90Q6GSgk+wLDHgqRB1WL9ee16R1I0MKdI idogTXbhWzOlLNv3BQv2cryWhfnJ3CgRArG7gFcFZWlVbG2Of5GBD36dt 5OFSA+1itqfvi5FwrawnmxhU0e+gljYfLGFB79ZoZFRETaCViLcPnuwTg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCCtbBW/xbLJq1ehAxtiFmxagENg?= =?us-ascii?q?WQXCoUiSgKBehQBAQEBAQEBgQqEQgEBBAEBASAPAQU2BAYRCw4KAgIFFgsCAgk?= =?us-ascii?q?DAgECARUwBgEMBgIBAYgXDq88jnEBAQEBAQEBAQEBAQEBAQEBAQEBF3uFFIQ3h?= =?us-ascii?q?zKBOgEElnGFR4gEgVtKg3iDA4VRhW+EfoNSHgEBQoNlOy6JawEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="scan'208";a="648995222" 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; 02 Feb 2016 13:57:46 +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 u12Dvjpw017241; Tue, 2 Feb 2016 13:57:45 GMT To: Nadeau Thomas , "netmod@ietf.org" References: <20160123012947.2367.17244.idtracker@ietfa.amsl.com> <05DD4741-BE90-41E9-A9D0-1D51864F75A8@juniper.net> <750193B4-777F-4AFD-9259-88E8F2C33B6A@lucidvision.com> From: Benoit Claise Message-ID: <56B0B5D9.3050801@cisco.com> Date: Tue, 2 Feb 2016 14:57:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <750193B4-777F-4AFD-9259-88E8F2C33B6A@lucidvision.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] [yang-doctors] I-D Action: draft-ietf-netmod-opstate-reqs-04.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, 02 Feb 2016 13:57:51 -0000 Dear all, I started the IETF last call process on draft-ietf-netmod-opstate-reqs-04. Regards, Benoit > [Speaking as co-chair] > > Benoit, > > I believe the document is now ready for your AD review. > > —Tom > > > >> On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen wrote: >> >> >> [As a contributor] >> >> This update contains the following changes: >> >> >> 1) removed “(see term)” throughout >> >> 2) moved 2nd-half of the Asynchronous Configuration Operation term to new requirement 2-B >> >> 3) moved the Backwards Compatibility to new requirement 5 >> >> 4) made some may/MAY/SHOULD/MUST changes (as discussed on list) >> >> 5) replaced map/mapping with relate/relationships >> >> >> Please see the diff for details. >> >> Thanks, >> Kent >> >> >> >> >> >> On 1/22/16, 8:29 PM, "netmod on behalf of 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 : Terminology and Requirements for Enhanced Handling of Operational State >>> Authors : Kent Watsen >>> Thomas Nadeau >>> Filename : draft-ietf-netmod-opstate-reqs-04.txt >>> Pages : 6 >>> Date : 2016-01-22 >>> >>> Abstract: >>> This document primarily regards the difference between the intended >>> configuration and the applied configuration of a device and how >>> intended and applied configuration relate to the operational state of >>> a device. This document defines requirements for the applied >>> configuration's data model and its values, as well as for enabling a >>> client to know when a configuration has been fully applied or not, >>> how to access operational state, and how to relate intended >>> configuration nodes to applied configuration and derived state nodes. >>> >>> >>> 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-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Tue Feb 2 06:42:14 2016 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 D65AB1B2BB4; Tue, 2 Feb 2016 06:42:11 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160202144211.28209.47188.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 06:42:11 -0800 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-opstate-reqs@ietf.org, netmod@ietf.org Subject: [netmod] Last Call: (Terminology and Requirements for Enhanced Handling of Operational State) to Informational RFC X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 14:42:12 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Terminology and Requirements for Enhanced Handling of Operational State' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 2 09:25:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB41B2DAE for ; Tue, 2 Feb 2016 09:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_39=0.6, 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 WNkWIPfCUzq6 for ; Tue, 2 Feb 2016 09:25:05 -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 96E371B2DAA for ; Tue, 2 Feb 2016 09:25:04 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id j78so53540459lfb.1 for ; Tue, 02 Feb 2016 09:25: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=qoL5MIndmMTCFp1ciI6Rd9eEdl/wc0xUTKVWr9domMg=; b=X0qsqldHPSUXKQ6hC2046dUt11kytXmlzjwEjUbjkZYaiJ1AAHOQ3aq0P2UHq/jGX1 AMHOmrmPra8SvYQ84bP5AJvyjVaDzdQ0yvRXmzNS9xPvPfeK3NM4uaTMvZZNHMesEXJ7 2UQEZUm4Yf7EtcqW+Gutzqp3NLKCDEJDkWcnkjTsgq/CcmrV6VDhPuRzrvZ2l1M4bPNX q6I04PxqrSM94p5M8YmY6zUBXid233NYYLSi3+i53PZUSEXymkzNuDJsPPlcPcG8AF82 mNHL4eBgyPaR8DjWKf/YXgM21qaRbUuM9PYYV8s6I0KyLjlwBxy1plxXm9WVRTNr5YmG HWKA== 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=qoL5MIndmMTCFp1ciI6Rd9eEdl/wc0xUTKVWr9domMg=; b=IY5IG0LMhBxd1WOEg05bIgozzKUOc3BYp5G2lE1hsD8N+VEcsCTJXajPUou6mkUwAE BS/SX7MHNJilvgVAUSdtkSyGQbdos7NA6LdV/1zwv20x36dcHpDNwGW6eNCoYQFtXt3C 9rh4yejPHpx6JqfnFYhCeEcBz4trGtCNFIVq6XHGB3Dp4/RLjjz75jLfDx6pH55I8OeV P/iIveVg3FyZLmDplLna54IqWHOVqUR0y5lyNSG5MYhRw3xWF9n9sdv6LbZZECzj8mNg +E+gLMbHMJnDG0VYVzXKyjyKbbg5swyBCF75SdN/BXqJWj+tf+JNjgiJAVk0pDOG9aPL u3gQ== X-Gm-Message-State: AG10YOQk0RHhB6qV47OwQc+uJBciEiuQwg57uFaHRhcSL8gDPFYxVra2wFZGeL6+pLnjVav6lrlq/gIV7rJkEQ== MIME-Version: 1.0 X-Received: by 10.25.162.202 with SMTP id l193mr11738891lfe.138.1454433902489; Tue, 02 Feb 2016 09:25:02 -0800 (PST) Received: by 10.112.200.167 with HTTP; Tue, 2 Feb 2016 09:25:02 -0800 (PST) In-Reply-To: <56B09B5D.3000907@mg-soft.si> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> <56B09B5D.3000907@mg-soft.si> Date: Tue, 2 Feb 2016 09:25:02 -0800 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=001a114119ec1b86f2052accc849 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] chars that require quoting 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, 02 Feb 2016 17:25:07 -0000 --001a114119ec1b86f2052accc849 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak wrote: > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: > >> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: >>> >>> Ladislav Lhotka wrote: >>> >>>> On 02 Feb 2016, at 09:51, Jernej Tuljak >>>>> wrote: >>>>> >>>>> Martin Bjorklund je 1.2.2016 ob 20:48 napisal: >>>>> >>>>>> Juergen Schoenwaelder wrote: >>>>>> >>>>>>> If a specification is not explicit enough, then people often >>>>>>> implement >>>>>>> what they find implemented in other similar contexts. This means the >>>>>>> code often ends up reflecting which tools an implementor was familiar >>>>>>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for >>>>>>> Tcl, which has otherwise the behavior you implemented for pyang, >>>>>>> treating " as a regular character in an unquoted string.) >>>>>>> >>>>>>> It would help to know what implementations do with identifiers like >>>>>>> f"o"o and f\"o\"o. If they do different things, then there is likely >>>>>>> some evidence that implementors arrived at different conclusions. >>>>>>> >>>>>> I don't mind a clarification. How about: >>>>>> >>>>>> OLD: >>>>>> >>>>>> If a string contains any space, tab, or newline characters, a >>>>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>>>> quotes. >>>>>> >>>>>> NEW: >>>>>> >>>>>> If a string contains any space, tab, or newline characters, a >>>>>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>>>>> "/*", or "*/"), then it MUST be enclosed within double or single >>>>>> quotes. If a string does not contain any of these characters, it >>>>>> MAY be unquoted. >>>>>> >>>>>> Within an unquoted string, every character is preserved. Note that >>>>>> this means that the backslash, single quote, and double quote >>>>>> characters can occur in an unquoted string. >>>>>> >>>>> I don't think this can be implemented, like I did not in the linked >>>>> archive. It does not make clear whether these are two statements or a >>>>> single one: >>>>> >>>>> default "; >>>>> units "; >>>>> >>>>> >>>>> What about this: >>>>> >>>>> default ";//foo"; >>>>> units \"; >>>>> >>>>> >>>>> This is not the C and C++ way of doing things (possibly not even SMIng >>>>> way). These are the only languages mentioned in the document (Section 6). >>>>> It also does not promote readability and makes lexers unnecessarily complex. >>>>> >>>> +1 >>>> >>>> I think the safest solution would be to disallow in unquoted strings >>>> all characters that have a special meaning anywhere in YANG >>>> syntax. This can hardly cause any troubles to module authors. >>>> >>> Fine with me. Something like: >>> >>> NEW: >>> >>> If a string contains any space, tab, or newline characters, a single >>> or double quote, semicolon (";"), braces ("{" or "}"), or comment >>> sequences ("//", "/*", or "*/"), then it MUST be enclosed within >>> double or single quotes. If a string does not contain any of these >>> characters, it MAY be unquoted. >>> >>> Within an unquoted string, every character is preserved. Note that >>> this means that the backslash character does not have any special >>> meaning in an unquoted string. >>> >> I like this. >> > > +1 > > >> I don't understand this text. The parser looks for certain tokens in specific contexts. container A;container B;container C; container foo{container bar{container baz;}} augment /foo/bar/baz{container Z;} pyang and yangdump-pro handle these unquoted strings correctly. I think your text is supposed to mean that chars with special meanings in specific contexts need to be quoted to use them as plain chars without any special meaning. I strongly object to this new text since it tells the YANG author they cannot use unquoted strings like the examples above. Andy >>> It should be noted that this may be viewed as a backwards incompatible >>> change, but I think it is similar to the change for escaped characters >>> in double quoted string ("backwards incompatible bugfix"). >>> >> Yes, I think so. >> > > This is nothing compared to the change of the accessible tree for output. > > Jernej > > >> Thanks, Lada >> >> >>> >>> /martin >>> >>> >>> >>> BTW, if we wanted to be extremely liberal, I don't understand why the >>>> end-comment sequence "*/" is not allowed. >>>> >>>> Lada >>>> >>>> Jernej >>>>> >>>>> /martin >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> -- >>>> 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 > --001a114119ec1b86f2052accc849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak <jernej.tuljak@mg= -soft.si> wrote:
Ladislav Lhotka je 2.2= .2016 ob 12:25 napisal:
On 02 Feb 2016, at 12:16, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
On 02 Feb 2016, at 09:51, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:

Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
If a specification is not explicit enough, then people often implement
what they find implemented in other similar contexts. This means the
code often ends up reflecting which tools an implementor was familiar
with. In a shell, echo f\"oo gives you f"oo (and the same is true= for
Tcl, which has otherwise the behavior you implemented for pyang,
treating " as a regular character in an unquoted string.)

It would help to know what implementations do with identifiers like
f"o"o and f\"o\"o. If they do different things, then th= ere is likely
some evidence that implementors arrived at different conclusions.
I don't mind a clarification.=C2=A0 How about:

OLD:

=C2=A0 If a string contains any space, tab, or newline characters, a
=C2=A0 semicolon (";"), braces ("{" or "}"), = or comment sequences ("//",
=C2=A0 "/*", or "*/"), then it MUST be enclosed within = double or single
=C2=A0 quotes.

NEW:

=C2=A0 If a string contains any space, tab, or newline characters, a
=C2=A0 semicolon (";"), braces ("{" or "}"), = or comment sequences ("//",
=C2=A0 "/*", or "*/"), then it MUST be enclosed within = double or single
=C2=A0 quotes.=C2=A0 If a string does not contain any of these characters, = it
=C2=A0 MAY be unquoted.

=C2=A0 Within an unquoted string, every character is preserved.=C2=A0 Note = that
=C2=A0 this means that the backslash, single quote, and double quote
=C2=A0 characters can occur in an unquoted string.
I don't think this can be implemented, like I did not in the linked arc= hive. It does not make clear whether these are two statements or a single o= ne:

=C2=A0 default ";
=C2=A0 units ";


What about this:

=C2=A0 default ";//foo";
=C2=A0 units \";


This is not the C and C++ way of doing things (possibly not even SMIng way)= . These are the only languages mentioned in the document (Section 6). It al= so does not promote readability and makes lexers unnecessarily complex.
+1

I think the safest solution would be to disallow in unquoted strings
all characters that have a special meaning anywhere in YANG
syntax. This can hardly cause any troubles to module authors.
Fine with me.=C2=A0 Something like:

NEW:

=C2=A0 If a string contains any space, tab, or newline characters, a single=
=C2=A0 or double quote, semicolon (";"), braces ("{" or= "}"), or comment
=C2=A0 sequences ("//", "/*", or "*/"), then = it MUST be enclosed within
=C2=A0 double or single quotes.=C2=A0 If a string does not contain any of t= hese
=C2=A0 characters, it MAY be unquoted.

=C2=A0 Within an unquoted string, every character is preserved.=C2=A0 Note = that
=C2=A0 this means that the backslash character does not have any special =C2=A0 meaning in an unquoted string.
I like this.

+1



I don't understand th= is text.
The parser looks for certain tokens in specific contexts= .=C2=A0


=C2=A0 container A;con= tainer B;container C;

=C2=A0 container foo{contain= er bar{container baz;}}

=C2=A0 augment /foo/bar/ba= z{container Z;}

pyang and yangdump-pro handl= e these unquoted strings correctly.

I think your t= ext is supposed to mean that chars with special meanings
in speci= fic contexts need to be quoted to use them as plain chars without
any special meaning.

I strongly object to this ne= w text since it tells the YANG author they
cannot use unquoted st= rings like the examples above.


Andy=


It should be noted that this may be viewed as a backwards incompatible
change, but I think it is similar to the change for escaped characters
in double quoted string ("backwards incompatible bugfix").
Yes, I think so.

This is nothing compared to the change of the accessible tree for output.
Jernej


Thanks, Lada



/martin



BTW, if we wanted to be extremely liberal, I don't understand why the e= nd-comment sequence "*/" is not allowed.

Lada

Jernej

/martin

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

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

--001a114119ec1b86f2052accc849-- From nobody Tue Feb 2 09:39:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A260C1B2DCB for ; Tue, 2 Feb 2016 09:39:55 -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 46UjbmWZDtb9 for ; Tue, 2 Feb 2016 09:39:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB351B2DC8 for ; Tue, 2 Feb 2016 09:39:52 -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.396.15; Tue, 2 Feb 2016 17:39:35 +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.0396.020; Tue, 2 Feb 2016 17:39:35 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: 'uses' as a sub-statement to 'choice' statement? Thread-Index: AQHRXeCuGy7kLlbqK0mP0S2qDFZcKQ== Date: Tue, 2 Feb 2016 17:39:35 +0000 Message-ID: <20D5759D-30CF-4E05-8A25-BD1D25D21321@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: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:Xah959yZjR053CoFi91doiTW66TuxnjeN72kEszRNMr5bwzufHeUshgUTPze8xjihstFH4kTuOg9Meel18Q/DfE8Sn4Fjsp5hIHEkl+WfezID1qe++Qn5hk4bufhoMU6d/jCilQpLtdNBARCoswaVw==; 24:VQI1z8i7IJ4dFknbQ1hM2STMZA5cikCNsW7wediY2JbSR6iOKHvOo1fcDchlcX38Izv6MvE5z7yQjRFCViJlhId/zBu4xuYtAvZN4S+QmRs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 7093b884-3388-4ffd-5528-08d32bf7d122 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)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(1730700002)(83716003)(106116001)(229853001)(99286002)(2351001)(92566002)(2900100001)(10400500002)(5002640100001)(82746002)(6116002)(5008740100001)(86362001)(66066001)(5004730100002)(40100003)(122556002)(50986999)(3660700001)(11100500001)(2501003)(54356999)(189998001)(3280700002)(87936001)(450100001)(1220700001)(5001960100002)(586003)(107886002)(3846002)(33656002)(102836003)(110136002)(77096005)(36756003)(2906002)(1096002)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_20D5759D30CF4E058A25BD1D25D21321junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2016 17:39:35.3414 (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: Subject: [netmod] 'uses' as a sub-statement to 'choice' statement? 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, 02 Feb 2016 17:39:55 -0000 --_000_20D5759D30CF4E058A25BD1D25D21321junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJbiBhIG1vZGVsIHdoZXJlIHRoZSBjaG9pY2Ugc2hvcnRoYW5kIG5vdGF0aW9uIGlzIGJlaW5n IHVzZWQsIGl0IGlzIG5lY2Vzc2FyeSB0byB1c2UgbG9uZ2hhbmQgbm90YXRpb24gaWYgd2FudGlu ZyBhIGNhc2Ugc3RhdGVtZW50IHRvIGJlIGRlZmluZWQgYnkgdGhlIOKAmHVzZXPigJkgc3RhdGVt ZW50LiAgIFRoYXQgaXMsIDYwMjBiaXMgYWxsb3dzIOKAmHVzZXPigJkgYXMgYSBzdWItc3RhdGVt ZW50IHRvIHRoZSDigJhjYXNl4oCZIHN0YXRlbWVudCwgYnV0IG5vdCB0byB0aGUg4oCYY2hvaWNl 4oCZIHN0YXRlbWVudC4gIEFzIGFuIGV4YW1wbGUsIHRoaXMgY2hvaWNlIHN0YXRlbWVudDoNCg0K ICAgICBjaG9pY2UgaW50ZXJmYWNlLXR5cGUgew0KICAgICAgIGNhc2UgZXRoZXJuZXQgew0KICAg ICAgICAgdXNlcyBldGhlcm5ldDsNCiAgICAgICB9DQogICAgICAgY2FzZSBvcHRpY2FsIHsNCiAg ICAgICAgIHVzZXMgb3B0aWNhbDsNCiAgICAgICB9DQogICAgIH0NCg0KQ2Fubm90IHVzZSBzaG9y dGhhbmQgbm90YXRpb246DQoNCiAgICAgY2hvaWNlIGludGVyZmFjZS10eXBlIHsNCiAgICAgICB1 c2VzIGV0aGVybmV0Ow0KICAgICAgIHVzZXMgb3B0aWNhbDsNCiAgICAgfQ0KDQoNClRoaXMgc2Vl bXMgbGlrZSBhIGJ1ZyB0byBtZS4gICBJcyBpdCB0b28gbGF0ZSB0byBmaXggaW4gNjAyMGJpcyBh cyBhbiBpc3N1ZSByYWlzZWQgYnkgV0dMQz8NCg0KS2VudCAgLy8gYXMgYSBjb250cmlidXRvcg0K DQoNCg== --_000_20D5759D30CF4E058A25BD1D25D21321junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpJbiBhIG1vZGVsIHdo ZXJlIHRoZSBjaG9pY2Ugc2hvcnRoYW5kIG5vdGF0aW9uIGlzIGJlaW5nIHVzZWQsIGl0IGlzIG5l Y2Vzc2FyeSB0byB1c2UgbG9uZ2hhbmQgbm90YXRpb24gaWYgd2FudGluZyBhIGNhc2Ugc3RhdGVt ZW50IHRvIGJlIGRlZmluZWQgYnkgdGhlIOKAmHVzZXPigJkgc3RhdGVtZW50LiAmbmJzcDsgVGhh dCBpcywgNjAyMGJpcyBhbGxvd3Mg4oCYdXNlc+KAmSBhcyBhIHN1Yi1zdGF0ZW1lbnQgdG8gdGhl IOKAmGNhc2XigJkgc3RhdGVtZW50LCBidXQgbm90IHRvDQogdGhlIOKAmGNob2ljZeKAmSBzdGF0 ZW1lbnQuICZuYnNwO0FzIGFuIGV4YW1wbGUsIHRoaXMgY2hvaWNlIHN0YXRlbWVudDo8L2Rpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hvaWNlIGlu dGVyZmFjZS10eXBlIHs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaTsiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y2FzZSBldGhlcm5ldCB7PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmk7Ij48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzIGV0aGVybmV0OzwvZm9udD48L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9mb250PjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2Ugb3B0aWNhbCB7PC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzJm5ic3A7 PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPm9w dGljYWw8L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj47PC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L2ZvbnQ+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaTsiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Q2Fubm90IHVzZSBz aG9ydGhhbmQgbm90YXRpb246PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmk7Ij48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwO2Nob2ljZSBpbnRlcmZhY2UtdHlwZSB7PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3VzZXMgZXRoZXJuZXQ7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZXMmbmJzcDs8 L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij5vcHRpY2FsPC9zcGFuPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwO308L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj5UaGlzIHNlZW1zIGxpa2UgYSBidWcgdG8gbWUuICZuYnNwOyBJcyBpdCB0b28g bGF0ZSB0byBmaXggaW4gNjAyMGJpcyBhcyBhbiBpc3N1ZSByYWlzZWQgYnkgV0dMQz88L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PktlbnQgJm5ic3A7Ly8gYXMgYSBjb250cmlidXRvcjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_20D5759D30CF4E058A25BD1D25D21321junipernet_-- From nobody Tue Feb 2 09:50:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55941B2E03 for ; Tue, 2 Feb 2016 09:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.148 X-Spam-Level: * X-Spam-Status: No, score=1.148 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-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 89Hbmz-DkBlz for ; Tue, 2 Feb 2016 09:50: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 B571B1B2E01 for ; Tue, 2 Feb 2016 09:50:34 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:6124:1432:1d4c:9916] (unknown [IPv6:2a01:5e0:29:ffff:6124:1432:1d4c:9916]) by mail.nic.cz (Postfix) with ESMTPSA id F189B180C47; Tue, 2 Feb 2016 18:50:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454435433; bh=LAO+TDbF6feOCzvasegFsk7h03+FT35Az3CVoJenZn0=; h=From:Date:To; b=M+rk4hD/MrNJAcgBPAtF/Qh/bizSUQ9MRyK7ZZtcTXwMKbftVd9LlNvLHfeWgxcFr RWT0XYm/TDi593FfaXpA6+v/eWkDnmxZpkdkDKu51+Lg8MViB947BPIz1XCwk8l9g2 GtfO6+iiu3dUIt7N2FGJpGUza/N3iWWYTQvEQJOY= 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, 2 Feb 2016 18:50:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8943AE12-3A15-456A-8B97-B2859278CDE2@nic.cz> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> <56B09B5D.3000907@mg-soft.si> 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] chars that require quoting 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, 02 Feb 2016 17:50:37 -0000 > On 02 Feb 2016, at 18:25, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak = wrote: > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: > On 02 Feb 2016, at 09:51, Jernej Tuljak = wrote: >=20 > Martin Bjorklund je 1.2.2016 ob 20:48 napisal: > Juergen Schoenwaelder wrote: > If a specification is not explicit enough, then people often implement > what they find implemented in other similar contexts. This means the > code often ends up reflecting which tools an implementor was familiar > with. In a shell, echo f\"oo gives you f"oo (and the same is true for > Tcl, which has otherwise the behavior you implemented for pyang, > treating " as a regular character in an unquoted string.) >=20 > It would help to know what implementations do with identifiers like > f"o"o and f\"o\"o. If they do different things, then there is likely > some evidence that implementors arrived at different conclusions. > I don't mind a clarification. How about: >=20 > OLD: >=20 > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. >=20 > NEW: >=20 > If a string contains any space, tab, or newline characters, a > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > "/*", or "*/"), then it MUST be enclosed within double or single > quotes. If a string does not contain any of these characters, it > MAY be unquoted. >=20 > Within an unquoted string, every character is preserved. Note that > this means that the backslash, single quote, and double quote > characters can occur in an unquoted string. > I don't think this can be implemented, like I did not in the linked = archive. It does not make clear whether these are two statements or a = single one: >=20 > default "; > units "; >=20 >=20 > What about this: >=20 > default ";//foo"; > units \"; >=20 >=20 > This is not the C and C++ way of doing things (possibly not even SMIng = way). These are the only languages mentioned in the document (Section = 6). It also does not promote readability and makes lexers unnecessarily = complex. > +1 >=20 > I think the safest solution would be to disallow in unquoted strings > all characters that have a special meaning anywhere in YANG > syntax. This can hardly cause any troubles to module authors. > Fine with me. Something like: >=20 > NEW: >=20 > If a string contains any space, tab, or newline characters, a single > or double quote, semicolon (";"), braces ("{" or "}"), or comment > sequences ("//", "/*", or "*/"), then it MUST be enclosed within > double or single quotes. If a string does not contain any of these > characters, it MAY be unquoted. >=20 > Within an unquoted string, every character is preserved. Note that > this means that the backslash character does not have any special > meaning in an unquoted string. > I like this. >=20 > +1 >=20 >=20 >=20 > I don't understand this text. > The parser looks for certain tokens in specific contexts.=20 >=20 >=20 > container A;container B;container C; >=20 > container foo{container bar{container baz;}} >=20 > augment /foo/bar/baz{container Z;} >=20 > pyang and yangdump-pro handle these unquoted strings correctly. >=20 > I think your text is supposed to mean that chars with special meanings > in specific contexts need to be quoted to use them as plain chars = without > any special meaning. >=20 > I strongly object to this new text since it tells the YANG author they > cannot use unquoted strings like the examples above. Why do you think there is anything in the new text to this effect? All = of your examples remain perfectly OK. The only change compared to = 6020bis-09 is that the newline, single- and double-quote characters = cannot appear in unquoted argument strings. Lada=20 >=20 >=20 > Andy >=20 >=20 > It should be noted that this may be viewed as a backwards incompatible > change, but I think it is similar to the change for escaped characters > in double quoted string ("backwards incompatible bugfix"). > Yes, I think so. >=20 > This is nothing compared to the change of the accessible tree for = output. >=20 > Jernej >=20 >=20 > Thanks, Lada >=20 >=20 >=20 > /martin >=20 >=20 >=20 > BTW, if we wanted to be extremely liberal, I don't understand why the = end-comment sequence "*/" is not allowed. >=20 > Lada >=20 > Jernej >=20 > /martin >=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 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=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 Tue Feb 2 09:55:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0271B2E09 for ; Tue, 2 Feb 2016 09:55:09 -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 lqaCDku_vkRU for ; Tue, 2 Feb 2016 09:55:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1D41B2E0E for ; Tue, 2 Feb 2016 09:55: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.396.15; Tue, 2 Feb 2016 17:54:41 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0396.020; Tue, 2 Feb 2016 17:54:41 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRXeLKOW+rjqCc7kiS321+Ltbrbg== Date: Tue, 2 Feb 2016 17:54:41 +0000 Message-ID: References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> In-Reply-To: <20160202153033.9430.65698.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: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:7obnCYE+0LJKeqgyPyDO9iewyCwBEnN0vF25+Z0VUka7gbQVLFsGD2VNtmBLVto+ueYeIrATIwfwg1SYPjZKPogCrpVQx1jWZNXMajrgKmjclrswpLhrdTlvgrzO7qk60ll51dx4Ff2KVMN6Mvrhiw==; 24:3DHTZPAM3aJg3nDCWzcYCHAAYBH+AXZtvX68N80OBbbE4Pjlh8Lbml5/j2BfHfQb9BO4XoVjYaAxidcP43t6u8RuOAgHlWbcRoGklqVyqw8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: 7e354da9-2346-49a8-4c1f-08d32bf9ecff 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)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(479174004)(377454003)(53754006)(377424004)(24454002)(189998001)(450100001)(1220700001)(40100003)(110136002)(19580395003)(33656002)(586003)(107886002)(83716003)(6116002)(102836003)(5001960100002)(87936001)(5008740100001)(1096002)(2501003)(19580405001)(11100500001)(5002640100001)(77096005)(92566002)(36756003)(5004730100002)(3846002)(122556002)(2351001)(76176999)(54356999)(15975445007)(50986999)(106116001)(10400500002)(3280700002)(3660700001)(86362001)(2906002)(2950100001)(2900100001)(230783001)(82746002)(99286002)(66066001)(1730700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9214F9050D9D724DBA3A6EDCE29390F0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2016 17:54:41.0970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Tue, 02 Feb 2016 17:55:09 -0000 DQpIaSBBbGwsDQoNCkkgZGlkbuKAmXQgcmVjZWl2ZSB0aGUgdXN1YWwgYW5ub3VuY2VtZW50IEND LWVkIHRvIHRoZSBuZXRtb2QgbGlzdCwgc28gSeKAmW0gcmVwbHlpbmcgdG8gdGhpcyBvbmUgc2Vu dCB0byB0aGUgaWQtYW5ub3VuY2UgbGlzdCBpbnN0ZWFkLg0KDQpBbnl3YXksIHRoaXMgbW9ybmlu ZyBJIHBvc3RlZCAtMDEgb2YgdGhpcyBkcmFmdCBhbmQgdGhlbiBzaG9ydGx5IGFmdGVyIC0wMiB0 byBmaXggc29tZSBjbGVhbnVwIGl0ZW1zIEkgb25seSBub3RpY2VkIGFmdGVyIC0wMSB3YXMgcG9z dGVkICA6b29vcHM6DQoNCkVpdGhlciB3YXksIHRoaXMgdXBkYXRlIGlzIGFuIG92ZXJoYXVsIHRv IHRoZSBvcmlnaW5hbCBkcmFmdCBwb3N0ZWQgbGFzdCBTZXB0ZW1iZXIuDQoNCktlbnQNCg0KDQoN Cg0KDQpPbiAyLzIvMTYsIDEwOjMwIEFNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCj4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IE9wZXJhdGlvbmFsIFN0YXRlIEVu aGFuY2VtZW50cyBmb3IgWUFORywgTkVUQ09ORiwgYW5kIFJFU1RDT05GDQo+ICAgICAgICBBdXRo b3JzICAgICAgICAgOiBLZW50IFdhdHNlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgQW5k eSBCaWVybWFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gQmpvcmtsdW5kDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4JRmlsZW5h bWUgICAgICAgIDogZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0wMi50eHQNCj4JUGFnZXMg ICAgICAgICAgIDogMjcNCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNi0wMi0wMg0KPg0KPkFic3Ry YWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgZW5oYW5jZW1lbnRzIHRvIFlBTkcsIE5F VENPTkYsIGFuZCBSRVNUQ09ORg0KPiAgIHNhdGlzZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBzZXQg Zm9ydGggaW4gVGVybWlub2xvZ3kgYW5kIFJlcXVpcmVtZW50cw0KPiAgIGZvciBFbmhhbmNlZCBI YW5kbGluZyBvZiBPcGVyYXRpb25hbCBTdGF0ZS4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLw0KPg0KPlRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAyDQo+DQo+QSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAyDQo+DQo+DQo+ UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5JLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+SS1ELUFubm91bmNl QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5u b3VuY2UNCj5JbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbA0KPm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0 DQo+DQo= From nobody Tue Feb 2 10:03:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF01B2E42 for ; Tue, 2 Feb 2016 10:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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, RP_MATCHES_RCVD=-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 LwUirkLTbmox for ; Tue, 2 Feb 2016 10:03:31 -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 893AB1B2E3F for ; Tue, 2 Feb 2016 10:03:31 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:6124:1432:1d4c:9916] (unknown [IPv6:2a01:5e0:29:ffff:6124:1432:1d4c:9916]) by mail.nic.cz (Postfix) with ESMTPSA id 490AC181806 for ; Tue, 2 Feb 2016 19:03:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454436210; bh=6rSzuSBI4tmEbWyuVjeYSkaEkWuy/SFuse/H+lPF5h0=; h=From:Date:To; b=huvCfViumc5ZDGV51XYlvYnHfYnmLQITbXA/9UbTZRM3cIM83+09TDE/SYPv5SSRB P4a5dNoAR9aCjCye/DIQp2jblWyqIjU5IqJGrVjCCYH1pOmR09nUdNKZOHn0qE3Hs2 MgsUIUaRySHODpFbo4owwAfhkyggBv8dXYKTCSew= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20D5759D-30CF-4E05-8A25-BD1D25D21321@juniper.net> Date: Tue, 2 Feb 2016 19:03:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FD9ED89-72E7-40F7-9259-7AB0489C8E82@nic.cz> References: <20D5759D-30CF-4E05-8A25-BD1D25D21321@juniper.net> 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] 'uses' as a sub-statement to 'choice' statement? 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, 02 Feb 2016 18:03:32 -0000 > On 02 Feb 2016, at 18:39, Kent Watsen wrote: >=20 >=20 > In a model where the choice shorthand notation is being used, it is = necessary to use longhand notation if wanting a case statement to be = defined by the =E2=80=98uses=E2=80=99 statement. That is, 6020bis = allows =E2=80=98uses=E2=80=99 as a sub-statement to the =E2=80=98case=E2=80= =99 statement, but not to the =E2=80=98choice=E2=80=99 statement. As an = example, this choice statement: >=20 > choice interface-type { > case ethernet { > uses ethernet; > } > case optical { > uses optical; > } > } >=20 > Cannot use shorthand notation: >=20 > choice interface-type { > uses ethernet; > uses optical; > } >=20 >=20 > This seems like a bug to me. Is it too late to fix in 6020bis as an = issue raised by WGLC? This has already been discussed, see = https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&inde= x=3DuF7kbBPMxIBAMUm03D3AqxaJvK4 Lada >=20 > Kent // as a contributor >=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 Feb 2 10:07:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BA1B2E67 for ; Tue, 2 Feb 2016 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 A165uzYVkGsX for ; Tue, 2 Feb 2016 10:07:50 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 99A201B2E66 for ; Tue, 2 Feb 2016 10:07:49 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id bc4so99448345lbc.2 for ; Tue, 02 Feb 2016 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=a8LQzQpKmlj36lWck3zStr0W/n9mUtRqXZapLYasGNU=; b=ZZpNQvPYsuF0UvXPOVVgyJiL3t09scNVt3WIcm/gKk5W6N9bcyub9awpkJagXLE2a6 mINgKBJ1Z+Pet/tsUv2Kv5B4oXL9sitH4IXIn/EwObR40uOC7xef7ur48bME26sClESz CyGi/sMvOjhSULsAhrGX6UQ3xZM+D17aISQH9S31BtXbA2698b1PsUEglMQuB4PjNVMH 6AKhOFODs2rZ74m6+og3YyO+flMV+GczLqnir6TomZ25rwveKuAbCsGjxbJlPOj6Na/o dabg3/54BYD1B3TfnrZv4GaJUyqhuTEW7L7U52I24RQAUfGUmyF1/VIpDkw6cfvmbS2o 2+kg== 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=a8LQzQpKmlj36lWck3zStr0W/n9mUtRqXZapLYasGNU=; b=AQg72ZrkCf1yg2D2aYfFuW26zBQljqZCWN33HDHcF4z08uGU/v52XxuvHeeTbL12kL 395tw4phfSWR+K9UjNpTrJKS/xZtFnztN63zC8CFU0byraHchO0izud8PKjbp6P68mzx lTKCg5QzhbPYFjcU06tQARq6lBKqvZ2jgv3RTUY6sNcafuq59ZhlPhR6tMqPLon1/ncw twrPzGcBjuufn9JyB76yguMn9gUxR15bNzwl2hcxeO4G93bDV28iGN1TXnhRCtBfOWmP qBThhLPHZrLP+blfsFCXprT5w3thhWCE/29PWXofDiKwsea1LhVsPBB0nSdk+jLOIenF yCFw== X-Gm-Message-State: AG10YOTrh5O/G3KBc8mJhjbV8au8rEkd6bHeOlmP4hrr6b2z6vg/s4+mrIMiepR5NVIsmE/i3VH//I0yX3rioQ== MIME-Version: 1.0 X-Received: by 10.112.12.2 with SMTP id u2mr11791072lbb.145.1454436467855; Tue, 02 Feb 2016 10:07:47 -0800 (PST) Received: by 10.112.200.167 with HTTP; Tue, 2 Feb 2016 10:07:47 -0800 (PST) In-Reply-To: <20D5759D-30CF-4E05-8A25-BD1D25D21321@juniper.net> References: <20D5759D-30CF-4E05-8A25-BD1D25D21321@juniper.net> Date: Tue, 2 Feb 2016 10:07:47 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c3f18403edf7052acd61f8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 'uses' as a sub-statement to 'choice' statement? 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, 02 Feb 2016 18:07:51 -0000 --001a11c3f18403edf7052acd61f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I do not think this is a bug. The uses-stmt has no node name, just a grouping name, which may have a prefix. In the example above 'ethernet' and 'optical' are forced to be local names and be unique local names. Andy On Tue, Feb 2, 2016 at 9:39 AM, Kent Watsen wrote: > > In a model where the choice shorthand notation is being used, it is > necessary to use longhand notation if wanting a case statement to be > defined by the =E2=80=98uses=E2=80=99 statement. That is, 6020bis allow= s =E2=80=98uses=E2=80=99 as a > sub-statement to the =E2=80=98case=E2=80=99 statement, but not to the =E2= =80=98choice=E2=80=99 statement. > As an example, this choice statement: > > choice interface-type { > case ethernet { > uses ethernet; > } > case optical { > uses optical; > } > } > > Cannot use shorthand notation: > > choice interface-type { > uses ethernet; > uses optical; > } > > > This seems like a bug to me. Is it too late to fix in 6020bis as an > issue raised by WGLC? > > Kent // as a contributor > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c3f18403edf7052acd61f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I do not think this is a bug.
=
The uses-stmt has no node name, just a grouping name,
which = may have a prefix.=C2=A0

In the example above '= ;ethernet' and 'optical' are forced to
be local names= and be unique local names.


Andy


On Tue, Feb 2, 2016 at 9:39 AM, Kent Watsen <kwatsen@juniper.net<= /a>> wrote:

In a model where the choice shorthand notation is being used, it is necessa= ry to use longhand notation if wanting a case statement to be defined by th= e =E2=80=98uses=E2=80=99 statement. =C2=A0 That is, 6020bis allows =E2=80= =98uses=E2=80=99 as a sub-statement to the =E2=80=98case=E2=80=99 statement= , but not to the =E2=80=98choice=E2=80=99 statement.=C2=A0 As an example, this choice s= tatement:

=C2=A0= =C2=A0 =C2=A0choice interface-type {
=C2=A0= =C2=A0 =C2=A0 =C2=A0case ethernet {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ethernet;
=C2=A0= =C2=A0 =C2=A0 =C2=A0}
=C2=A0= =C2=A0 =C2=A0 =C2=A0case optical {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0uses=C2=A0optical;
=C2=A0= =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}

Cannot= use shorthand notation:

=C2=A0 =C2=A0 =C2=A0choice interface= -type {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uses ethe= rnet;
=C2=A0 =C2=A0 =C2=A0 =C2=A0uses=C2= =A0opt= ical;
=C2=A0 =C2=A0 =C2=A0}


This seems like a bug to me. =C2=A0 Is it too late to fix in 6020bis a= s an issue raised by WGLC?

Kent =C2=A0// as a contributor



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


--001a11c3f18403edf7052acd61f8-- From nobody Tue Feb 2 10:15:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332811B2E83 for ; Tue, 2 Feb 2016 10:15:10 -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, RP_MATCHES_RCVD=-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 MyttRYN432g0 for ; Tue, 2 Feb 2016 10:15: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 DD1731B2E7E for ; Tue, 2 Feb 2016 10:15:05 -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 C7CA01AE0285; Tue, 2 Feb 2016 19:15:04 +0100 (CET) Date: Tue, 02 Feb 2016 19:17:57 +0100 (CET) Message-Id: <20160202.191757.1627768584700080838.mbj@tail-f.com> To: camoberg@cisco.com From: Martin Bjorklund In-Reply-To: References: <56A79015.4040105@cisco.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-chairs@tools.ietf.org, netmod@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: Tue, 02 Feb 2016 18:15:10 -0000 "Carl Moberg (camoberg)" wrote: > > I am not aware of any IPR. Me neither. /martin > > > On Jan 26, 2016, at 4:26 PM, Benoit Claise (bclaise) wrote: > > > > I'm not aware of any IPR. > > > > Regards, Benoit > >> 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 > >> . > >> > > > > _______________________________________________ > > 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 Feb 2 10:49:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606C1B2ED7 for ; Tue, 2 Feb 2016 10:49:37 -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 yUiZpoP2-dMA for ; Tue, 2 Feb 2016 10:49:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA001B2F3A for ; Tue, 2 Feb 2016 10:49:35 -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.396.15; Tue, 2 Feb 2016 18:49:33 +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.0396.020; Tue, 2 Feb 2016 18:49:33 +0000 From: Kent Watsen To: Ladislav Lhotka , NETMOD WG Thread-Topic: [netmod] 'uses' as a sub-statement to 'choice' statement? Thread-Index: AQHRXeCuGy7kLlbqK0mP0S2qDFZcKZ8ZDEoA//+5CgA= Date: Tue, 2 Feb 2016 18:49:33 +0000 Message-ID: <8F6DB386-DC96-468A-B567-909EE000FBA3@juniper.net> References: <20D5759D-30CF-4E05-8A25-BD1D25D21321@juniper.net> <5FD9ED89-72E7-40F7-9259-7AB0489C8E82@nic.cz> In-Reply-To: <5FD9ED89-72E7-40F7-9259-7AB0489C8E82@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: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:STY9Sc1rrs5oKZhZ9oubUGbgOokJbMxKbi9p19/iX6QMD7TBa5Lo09iHj/g410RhVtUOaSA7fqNehZ4M+wtbB/msbuEPn/rBKdVdDJL0RF+St2qIj3yfLaZOCvEk8nGLDevkzukE6/nkobkZfesbUA==; 24:KHtLwKy+2vjdLk8587VS3DoqrAtIgybxgPbKNDV/QeACF6G/nZi/Nk0+Hsvf3mFLudX0tRmYcNl+PtffeNnoO2D4v55KmN5zOz8E3WO/x9A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 87beb634-6bec-40ee-c610-08d32c01976f x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(11100500001)(3660700001)(54356999)(40100003)(122556002)(50986999)(189998001)(3280700002)(5008740100001)(6116002)(87936001)(82746002)(66066001)(86362001)(15975445007)(83506001)(5004730100002)(2906002)(1096002)(36756003)(76176999)(77096005)(4001350100001)(3846002)(107886002)(1220700001)(5001960100002)(586003)(5001770100001)(102836003)(33656002)(558084003)(106116001)(83716003)(99286002)(5002640100001)(19580395003)(92566002)(2950100001)(2900100001)(10400500002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 02 Feb 2016 18:49:33.5239 (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: Subject: Re: [netmod] 'uses' as a sub-statement to 'choice' statement? 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, 02 Feb 2016 18:49:37 -0000 DQo+VGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCwgc2VlDQo+DQo+aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1uZXRtb2QmZ2J0PTEmaW5k ZXg9dUY3a2JCUE14SUJBTVVtMDNEM0FxeGFKdks0DQoNCg0KT2theSwgZ29vZCBhbnN3ZXIuICBO ZXZlciBtaW5kLg0KDQpUaGFua3MsDQpLZW50DQoNCg== From nobody Tue Feb 2 11:04:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAD11B2F3B for ; Tue, 2 Feb 2016 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 eDUFqtPyxyOm for ; Tue, 2 Feb 2016 11:04:26 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 009E01B2F74 for ; Tue, 2 Feb 2016 11:04:25 -0800 (PST) Received: (qmail 27019 invoked by uid 0); 2 Feb 2016 19:04:24 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 2 Feb 2016 19:04:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id DX4H1s0022SSUrH01X4LvP; Tue, 02 Feb 2016 12:04:22 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=_zdN4_mg0I77hZG3TLsA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Cc:To:Subject:From; bh=wuHnXPF/kRQl8CwRuYJzsjdt5R5Hbh2ebbPaQRYz5AM=; b=qYz/RXtb0MFXOtN84VHQKpvyDd3gsmLoStnh4OgnDVZTyli43E8aDVJLbWZ0XpSSj2TVs3I1FdgLIBODhJ5cf3/uzDaThD2MiwyjWOUMDyloIdOPThsFimJ/u/CqDO/3; Received: from box313.bluehost.com ([69.89.31.113]:44396 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aQgFO-0008ID-QX; Tue, 02 Feb 2016 12:04:18 -0700 From: Lou Berger X-Enigmail-Draft-Status: N1110 To: netmod WG Message-ID: <56B0FDAC.3090100@labn.net> Date: Tue, 2 Feb 2016 14:04:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: [netmod] Yang mount / ysdl example use case 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, 02 Feb 2016 19:04:27 -0000 I thought it would be worth summarizing what we're looking for in our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case you missed it) with respect to the draft-lhotka-netmod-ysdl and draft-bjorklund-netmod-structural-mount drafts. This is just my view, so my co-authors may wish to chime in and correct me. I'd be interested in hearing from the authors of YSDL and structural-mount, or anyone else for that matter, on how they see to best meet these needs. Here's what I think our draft needs: 1. that there be a mechanism that allows the incorporation (or 'mounting') of the data model defined by one top-level module within another module. The implication here is that when information is instantiated for the parent model it is also instantiated for the incorporated/mounted model. In our case we expect to do this on list element creation. Both solutions drafts cover the path implications, so these are not repeated here. 2. that this mechanism allow identification of specific modules to be incorporated/mounted at time of module definition, i.e. that no additional module is needed to support 1. This doesn't preclude definition of such a module. 3. that this mechanism allow for a server to control (and identify) which modules are incorporated/mounted. (see Section 3 LNE in our draft for an envisioned usage.) 4. that all capabilities that exist with the mounted module are available e.g. RPC operations and notifications. 5. while our primary requirement is for 'mounting' of top level modules, mounting of submodules may also be useful. (DT not draft driven.) We make use of the above in sections 3 and 4 of rtgwg-device-model. We see having a solution as critical for the simplifications/flexibility represented in the -02 version of our draft vs the -03 rev. We don't see wither solution draft as significantly different and just hope for a standard solution as soon as possible. (a draft-ietf-netmod solutions draft on the topic by BA would be fantastic given the impact on routing area -- even if it had to document two variations / alternative solutions.) Again, this is just my opinion and my coauthors or others on the rtg area yang DT may choose to chime in. Lou From nobody Tue Feb 2 18:25:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154AF1B31D3; Tue, 2 Feb 2016 18:25:19 -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 Q3qrmahv8kox; Tue, 2 Feb 2016 18:25:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B631B31C9; Tue, 2 Feb 2016 18:25:13 -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.396.15; Wed, 3 Feb 2016 02:24:55 +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.0396.020; Wed, 3 Feb 2016 02:24:55 +0000 From: Kent Watsen To: Lou Berger , netmod WG Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcA Date: Wed, 3 Feb 2016 02:24:54 +0000 Message-ID: <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> References: <56B0FDAC.3090100@labn.net> In-Reply-To: <56B0FDAC.3090100@labn.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: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:p8lXGNaVC8qtBCxNsuMTuyeFlVvDaC7TBi24pY/su7agkjunhd/ROpcs1QwP/nPvz8bgedOBygWk7YwwyWQiYG8q767iaUieKPzj/6KW/qZHmfotYFB2RBWdhLsOWaHEjOcZNcjnIQ/KspZBys2YHQ==; 24:h+B96UAIc+g4Oisl6zuwukw6Lo3RQy8TwXjsKhwTNrq48NMbpta4uy+bvyBIyrY/dpXa3/6OEqW6LXP2woAYTWy3QGzGNX5gPb6rzN64xbU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: 33c66c29-7776-49d3-1204-08d32c413441 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(164054003)(377454003)(24454002)(189998001)(1220700001)(19580395003)(40100003)(33656002)(586003)(83716003)(102836003)(5008740100001)(6116002)(5001960100002)(4326007)(19580405001)(5002640100001)(87936001)(1096002)(11100500001)(77096005)(86362001)(92566002)(3846002)(122556002)(36756003)(4001350100001)(54356999)(76176999)(15975445007)(50986999)(2950100001)(10400500002)(3660700001)(3280700002)(2906002)(2900100001)(5001770100001)(82746002)(99286002)(106116001)(83506001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <35DA6A83BA0D9E419EC25B21B0CAA3B8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 02:24:54.7735 (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: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 02:25:19 -0000 DQpbQ2hhaXIgaGF0IG9uXQ0KDQpHaXZlbiB0aGUgbnVtYmVyIG9mIGNvbXBldGluZy9jb21wbGVt ZW50aW5nIGRyYWZ0cyBpbnZvbHZlZCwgYW5kIHRoZSBnZW5lcmFsIGxhY2sgb2YgZGlzY3Vzc2lv biBvbiBhbnkgb2YgdGhlbSwgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBtaWdodCBiZSBhbiBl eHBlZGllbnQgd2F5IHRvIHByb2NlZWQuICBJbiBmYWlybmVzcywgd2Uga25vdyB0aGF0IHRoZXJl IGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiwgYnV0IGl0IGhhc27igJl0IGJlZW4gcGlja2VkIHVw IHlldCBpbiBhIGJpZyB3YXksIGFuZCBub3cgTG91IGhhcyBhbiB1cGRhdGVkIGRyYWZ0LiAgDQoN ClRoZSBjaGFpcnMgZGlzY3Vzc2VkIG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBhIGNvdXBsZSB3 ZWVrcyBmcm9tIG5vdywgcGVyaGFwcyBUaHVyc2RheSBGZWIgMTggc3RhcnRpbmcgYXQgMTBhbSBF U1Q/ICAgSSdtIHRoaW5raW5nIGFib3V0IHRoaXMgc2xvdCBvbmx5IHNpbmNlIGl0IHdvcmtlZCBm b3IgdXMgZm9yIHByZXZpb3VzbHkuICBJcyB0aGlzIGEgZ29vZCB0aW1lIHNsb3Q/ICBJIGFzc3Vt ZSB0byBzY2hlZHVsZSBmb3IgMiBob3Vycywgd2l0aCBhIHBsYW4gdG8gZW5kIGVhcmx5IGlmIG5l ZWRlZCAtIG1ha2VzIHNlbnNlPyAgICAgV2UgYWxzbyBuZWVkIHRvIHB1dCB0b2dldGhlciBhIHBy b3BlciBhZ2VuZGEsIHBlcmhhcHMgdGhlIGZvbGxvd2luZz8NCg0KICAxMCBtaW46IFJURyBEVCBZ QU5HIEFyY2ggdGVhbSB1c2UtY2FzZSBzdW1tYXJ5DQogIDIwIG1pbjogZHJhZnQtcnRneWFuZ2R0 LXJ0Z3dnLWRldmljZS1tb2RlbA0KICAyMCBtaW46IGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbA0K ICAyMCBtaW46IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3RydWN0dXJhbC1tb3VudA0KICA1MCBt aW46IGdlbmVyYWwgZGlzY3Vzc2lvbiBvciBlbmQgZWFybHkNCg0KDQpXZSBob3BlIHRvIHNjaGVk dWxlIHRoZSBtZWV0aW5nIGl0c2VsZiB0b21vcnJvdyBvciB0aGUgbmV4dCBkYXksIHNvIHBsZWFz ZSByZXNwb25kIHF1aWNrbHkgdG8gdGhpcyBlbWFpbCBpZiBwb3NzaWJsZS4NCg0KVGhhbmtzLA0K S2VudCBhbmQgVG9tDQoNCg0KDQoNCk9uIDIvMi8xNiwgMjowNCBQTSwgIm5ldG1vZCBvbiBiZWhh bGYgb2YgTG91IEJlcmdlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBs YmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KPg0KPkkgdGhvdWdodCBpdCB3b3VsZCBiZSB3b3J0 aCBzdW1tYXJpemluZyB3aGF0IHdlJ3JlIGxvb2tpbmcgZm9yIGluIG91cg0KPmRyYWZ0LCBkcmFm dC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTAyIChub3RlIG5ldyB2ZXJzaW9uIGluIGNh c2UNCj55b3UgbWlzc2VkIGl0KSB3aXRoIHJlc3BlY3QgdG8gdGhlIGRyYWZ0LWxob3RrYS1uZXRt b2QteXNkbCBhbmQNCj5kcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQgZHJh ZnRzLiBUaGlzIGlzIGp1c3QgbXkgdmlldywgc28NCj5teSBjby1hdXRob3JzIG1heSB3aXNoIHRv IGNoaW1lIGluIGFuZCBjb3JyZWN0IG1lLg0KPg0KPkknZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJp bmcgZnJvbSB0aGUgYXV0aG9ycyBvZiBZU0RMIGFuZA0KPnN0cnVjdHVyYWwtbW91bnQsIG9yIGFu eW9uZSBlbHNlIGZvciB0aGF0IG1hdHRlciwgb24gaG93IHRoZXkgc2VlIHRvDQo+YmVzdCBtZWV0 IHRoZXNlIG5lZWRzLg0KPg0KPkhlcmUncyB3aGF0IEkgdGhpbmsgb3VyIGRyYWZ0IG5lZWRzOg0K Pg0KPjEuIHRoYXQgdGhlcmUgYmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdGhlIGluY29ycG9y YXRpb24gKG9yDQo+ICAgJ21vdW50aW5nJykgb2YgdGhlIGRhdGEgbW9kZWwgZGVmaW5lZCBieSBv bmUgdG9wLWxldmVsIG1vZHVsZQ0KPiAgIHdpdGhpbiBhbm90aGVyIG1vZHVsZS4NCj4NCj4gICBU aGUgaW1wbGljYXRpb24gaGVyZSBpcyB0aGF0IHdoZW4gaW5mb3JtYXRpb24gaXMgaW5zdGFudGlh dGVkDQo+ICAgZm9yIHRoZSBwYXJlbnQgbW9kZWwgaXQgaXMgYWxzbyBpbnN0YW50aWF0ZWQgZm9y IHRoZQ0KPiAgIGluY29ycG9yYXRlZC9tb3VudGVkIG1vZGVsLiBJbiBvdXIgY2FzZSB3ZSBleHBl Y3QgdG8gZG8gdGhpcyBvbg0KPiAgIGxpc3QgZWxlbWVudCBjcmVhdGlvbi4gQm90aCBzb2x1dGlv bnMgZHJhZnRzIGNvdmVyIHRoZSBwYXRoDQo+ICAgaW1wbGljYXRpb25zLCBzbyB0aGVzZSBhcmUg bm90IHJlcGVhdGVkIGhlcmUuDQo+DQo+Mi4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBpZGVu dGlmaWNhdGlvbiBvZiBzcGVjaWZpYyBtb2R1bGVzIHRvDQo+ICAgYmUgaW5jb3Jwb3JhdGVkL21v dW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0DQo+ICAgbm8gYWRk aXRpb25hbCBtb2R1bGUgaXMgbmVlZGVkIHRvIHN1cHBvcnQgMS4gVGhpcyBkb2Vzbid0DQo+ICAg cHJlY2x1ZGUgZGVmaW5pdGlvbiBvZiBzdWNoIGEgbW9kdWxlLg0KPg0KPjMuIHRoYXQgdGhpcyBt ZWNoYW5pc20gYWxsb3cgZm9yIGEgc2VydmVyIHRvIGNvbnRyb2wgKGFuZA0KPiAgIGlkZW50aWZ5 KSB3aGljaCBtb2R1bGVzIGFyZSBpbmNvcnBvcmF0ZWQvbW91bnRlZC4gKHNlZSBTZWN0aW9uDQo+ ICAgMyBMTkUgaW4gb3VyIGRyYWZ0IGZvciBhbiBlbnZpc2lvbmVkIHVzYWdlLikNCj4NCj40LiB0 aGF0IGFsbCBjYXBhYmlsaXRpZXMgdGhhdCBleGlzdCB3aXRoIHRoZSBtb3VudGVkIG1vZHVsZSBh cmUNCj4gICBhdmFpbGFibGUgZS5nLiBSUEMgb3BlcmF0aW9ucyBhbmQgbm90aWZpY2F0aW9ucy4N Cj4NCj41LiB3aGlsZSBvdXIgcHJpbWFyeSByZXF1aXJlbWVudCBpcyBmb3IgJ21vdW50aW5nJyBv ZiB0b3AgbGV2ZWwNCj4gICBtb2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNv IGJlIHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPiAgIGRyaXZlbi4pDQo+DQo+V2UgbWFrZSB1c2Ug b2YgdGhlIGFib3ZlIGluIHNlY3Rpb25zIDMgYW5kIDQgb2YgcnRnd2ctZGV2aWNlLW1vZGVsLiAg V2UNCj5zZWUgaGF2aW5nIGEgc29sdXRpb24gYXMgY3JpdGljYWwgZm9yIHRoZSBzaW1wbGlmaWNh dGlvbnMvZmxleGliaWxpdHkNCj5yZXByZXNlbnRlZCBpbiB0aGUgLTAyIHZlcnNpb24gb2Ygb3Vy IGRyYWZ0IHZzIHRoZSAtMDMgcmV2LiAgV2UgZG9uJ3QNCj5zZWUgd2l0aGVyIHNvbHV0aW9uIGRy YWZ0IGFzIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGFuZCBqdXN0IGhvcGUgZm9yIGENCj5zdGFu ZGFyZCBzb2x1dGlvbiBhcyBzb29uIGFzIHBvc3NpYmxlLiAgKGEgZHJhZnQtaWV0Zi1uZXRtb2Qg c29sdXRpb25zDQo+ZHJhZnQgb24gdGhlIHRvcGljIGJ5IEJBIHdvdWxkIGJlIGZhbnRhc3RpYyBn aXZlbiB0aGUgaW1wYWN0IG9uIHJvdXRpbmcNCj5hcmVhIC0tIGV2ZW4gaWYgaXQgaGFkIHRvIGRv Y3VtZW50IHR3byB2YXJpYXRpb25zIC8gYWx0ZXJuYXRpdmUgc29sdXRpb25zLikNCj4NCj5BZ2Fp biwgdGhpcyBpcyBqdXN0IG15IG9waW5pb24gYW5kIG15IGNvYXV0aG9ycyBvciBvdGhlcnMgb24g dGhlIHJ0Zw0KPmFyZWEgeWFuZyBEVCBtYXkgY2hvb3NlIHRvIGNoaW1lIGluLg0KPg0KPkxvdQ0K Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Feb 2 20:03:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18B91A0052 for ; Tue, 2 Feb 2016 20:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_39=0.6, 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 TO2uxBYn8IdE for ; Tue, 2 Feb 2016 20:03:01 -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 9159F1A004C for ; Tue, 2 Feb 2016 20:03:00 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id 78so5441281lfy.3 for ; Tue, 02 Feb 2016 20:03:00 -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=x+rQHHbmIc/AcsoyHQADupijBntLacz4ZBMc0IExJWI=; b=LqoRCr88u9xqr74hI9NFYNBK+xxfqJGKDGhlzqEJCEQy4kWwUWUCYNc0vds6Jy2uQ/ vQ1h4XiGu8xcz/v/dd3+eO8ESIgCYGAAzJiAx5quA4IKrhmQ/tlSkV7FbEW30QTdQGC4 c2zbSVe5Whxr1L+/yiVe6U4Xz2Z/lbUCi/LxId5qyHZhIgm4/N/L1jaBY4+nc5194nTS YQceSplJPIwdQv3QqUPDqt/FOBqFwRsQq43VGLRS+OCyyJXYaaQK5gAiy9u1ILvIYPvR kUoJ7Co9vWEahb2otuJn2tFLkacoS1PN51sLdu1qK72G8t0KgPDhXSio/YRx8XpRaPll 9cig== 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=x+rQHHbmIc/AcsoyHQADupijBntLacz4ZBMc0IExJWI=; b=Sw3VlKaa+sjePgaCoJ0S22119em/uLXZ607oFwGrR3WCKtu4TB62RfB+zcsjxM0/dn wlovX9pcleNBqly73lS5UxfjwDKGrsSFNxLfShftnZXtQor5rCoJpq9eEdx8l4JjocXI WFxS3sXuiNKMY0YHcdmuAajij8jwKZjawN/WLVV7P1FU9FIc8qtuRxtjM0q8l65k8w4t Gar7cc7eZVM//KZvk/sZ7R98S/SlMaRC6JZMeMmYUlgHL1bWgHKroeY5hFVJ4C9nlzAk AVd1ZJzFFQ7+i9uwiGzGKhNeSNNnpdksn7jUeFgRWmpuXjL0BRV58bIFw2vdTnyKHGPA XEug== X-Gm-Message-State: AG10YORgFQzlP1uXVXLcSo18Q/gPg/gx9xFVHrbxV4teLZcNUYd3AlxCBEE74uC3/XFFj3LkRbYv0RJ34ix1hg== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr13421848lfe.8.1454472178768; Tue, 02 Feb 2016 20:02:58 -0800 (PST) Received: by 10.112.200.167 with HTTP; Tue, 2 Feb 2016 20:02:58 -0800 (PST) In-Reply-To: <8943AE12-3A15-456A-8B97-B2859278CDE2@nic.cz> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> <56B09B5D.3000907@mg-soft.si> <8943AE12-3A15-456A-8B97-B2859278CDE2@nic.cz> Date: Tue, 2 Feb 2016 20:02:58 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113fbdd48d3767052ad5b13b Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] chars that require quoting 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, 03 Feb 2016 04:03:04 -0000 --001a113fbdd48d3767052ad5b13b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka wrote: > > > On 02 Feb 2016, at 18:25, Andy Bierman wrote: > > > > > > > > On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak > wrote: > > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: > > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > > On 02 Feb 2016, at 09:51, Jernej Tuljak > wrote: > > > > Martin Bjorklund je 1.2.2016 ob 20:48 napisal: > > Juergen Schoenwaelder wrote: > > If a specification is not explicit enough, then people often implement > > what they find implemented in other similar contexts. This means the > > code often ends up reflecting which tools an implementor was familiar > > with. In a shell, echo f\"oo gives you f"oo (and the same is true for > > Tcl, which has otherwise the behavior you implemented for pyang, > > treating " as a regular character in an unquoted string.) > > > > It would help to know what implementations do with identifiers like > > f"o"o and f\"o\"o. If they do different things, then there is likely > > some evidence that implementors arrived at different conclusions. > > I don't mind a clarification. How about: > > > > OLD: > > > > If a string contains any space, tab, or newline characters, a > > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > > "/*", or "*/"), then it MUST be enclosed within double or single > > quotes. > > > > NEW: > > > > If a string contains any space, tab, or newline characters, a > > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > > "/*", or "*/"), then it MUST be enclosed within double or single > > quotes. If a string does not contain any of these characters, it > > MAY be unquoted. > > > > Within an unquoted string, every character is preserved. Note that > > this means that the backslash, single quote, and double quote > > characters can occur in an unquoted string. > > I don't think this can be implemented, like I did not in the linked > archive. It does not make clear whether these are two statements or a > single one: > > > > default "; > > units "; > > > > > > What about this: > > > > default ";//foo"; > > units \"; > > > > > > This is not the C and C++ way of doing things (possibly not even SMIng > way). These are the only languages mentioned in the document (Section 6). > It also does not promote readability and makes lexers unnecessarily complex. > > +1 > > > > I think the safest solution would be to disallow in unquoted strings > > all characters that have a special meaning anywhere in YANG > > syntax. This can hardly cause any troubles to module authors. > > Fine with me. Something like: > > > > NEW: > > > > If a string contains any space, tab, or newline characters, a single > > or double quote, semicolon (";"), braces ("{" or "}"), or comment > > sequences ("//", "/*", or "*/"), then it MUST be enclosed within > > double or single quotes. If a string does not contain any of these > > characters, it MAY be unquoted. > > > > Within an unquoted string, every character is preserved. Note that > > this means that the backslash character does not have any special > > meaning in an unquoted string. > > I like this. > > > > +1 > > > > > > > > I don't understand this text. > > The parser looks for certain tokens in specific contexts. > > > > > > container A;container B;container C; > > > > container foo{container bar{container baz;}} > > > > augment /foo/bar/baz{container Z;} > > > > pyang and yangdump-pro handle these unquoted strings correctly. > > > > I think your text is supposed to mean that chars with special meanings > > in specific contexts need to be quoted to use them as plain chars without > > any special meaning. > > > > I strongly object to this new text since it tells the YANG author they > > cannot use unquoted strings like the examples above. > > Why do you think there is anything in the new text to this effect? All of > your examples remain perfectly OK. The only change compared to 6020bis-09 > is that the newline, single- and double-quote characters cannot appear in > unquoted argument strings. > > *If a string contains* any space, tab, or newline characters, a single > or double quote, *semicolon (";"),* braces ("{" or "}"), or comment > sequences ("//", "/*", or "*/"), t *hen it MUST be enclosed within> double or single quotes. * This is not true; The example above contains valid unquoted strings that contain a semicolon. The only strings that MUST be encoded in quotes are a single quote or double quote. All parsers will look for the closing quote and there won't be one. IMO the only next needed: NEW: If a string contains any single quote characters, then it MUST be enclosed within double quotes. If a string contains any double quote characters, then it MUST be enclosed within single quotes, or encoded within double quotes using an escape character '\', followed by the double quote character '"'. > Lada > > Andy > > > > > > Andy > > > > > > It should be noted that this may be viewed as a backwards incompatible > > change, but I think it is similar to the change for escaped characters > > in double quoted string ("backwards incompatible bugfix"). > > Yes, I think so. > > > > This is nothing compared to the change of the accessible tree for output. > > > > Jernej > > > > > > Thanks, Lada > > > > > > > > /martin > > > > > > > > BTW, if we wanted to be extremely liberal, I don't understand why the > end-comment sequence "*/" is not allowed. > > > > Lada > > > > Jernej > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a113fbdd48d3767052ad5b13b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 02 Feb 2016, at 18:25, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
> On 02 Feb 2016, at 12:16, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> On 02 Feb 2016, at 09:51, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
>
> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> If a specification is not explicit enough, then people often implement=
> what they find implemented in other similar contexts. This means the > code often ends up reflecting which tools an implementor was familiar<= br> > with. In a shell, echo f\"oo gives you f"oo (and the same is= true for
> Tcl, which has otherwise the behavior you implemented for pyang,
> treating " as a regular character in an unquoted string.)
>
> It would help to know what implementations do with identifiers like > f"o"o and f\"o\"o. If they do different things, th= en there is likely
> some evidence that implementors arrived at different conclusions.
> I don't mind a clarification.=C2=A0 How about:
>
> OLD:
>
>=C2=A0 =C2=A0If a string contains any space, tab, or newline characters= , a
>=C2=A0 =C2=A0semicolon (";"), braces ("{" or "= }"), or comment sequences ("//",
>=C2=A0 =C2=A0"/*", or "*/"), then it MUST be enclos= ed within double or single
>=C2=A0 =C2=A0quotes.
>
> NEW:
>
>=C2=A0 =C2=A0If a string contains any space, tab, or newline characters= , a
>=C2=A0 =C2=A0semicolon (";"), braces ("{" or "= }"), or comment sequences ("//",
>=C2=A0 =C2=A0"/*", or "*/"), then it MUST be enclos= ed within double or single
>=C2=A0 =C2=A0quotes.=C2=A0 If a string does not contain any of these ch= aracters, it
>=C2=A0 =C2=A0MAY be unquoted.
>
>=C2=A0 =C2=A0Within an unquoted string, every character is preserved.= =C2=A0 Note that
>=C2=A0 =C2=A0this means that the backslash, single quote, and double qu= ote
>=C2=A0 =C2=A0characters can occur in an unquoted string.
> I don't think this can be implemented, like I did not in the linke= d archive. It does not make clear whether these are two statements or a sin= gle one:
>
>=C2=A0 =C2=A0default ";
>=C2=A0 =C2=A0units ";
>
>
> What about this:
>
>=C2=A0 =C2=A0default ";//foo";
>=C2=A0 =C2=A0units \";
>
>
> This is not the C and C++ way of doing things (possibly not even SMIng= way). These are the only languages mentioned in the document (Section 6). = It also does not promote readability and makes lexers unnecessarily complex= .
> +1
>
> I think the safest solution would be to disallow in unquoted strings > all characters that have a special meaning anywhere in YANG
> syntax. This can hardly cause any troubles to module authors.
> Fine with me.=C2=A0 Something like:
>
> NEW:
>
>=C2=A0 =C2=A0If a string contains any space, tab, or newline characters= , a single
>=C2=A0 =C2=A0or double quote, semicolon (";"), braces ("= {" or "}"), or comment
>=C2=A0 =C2=A0sequences ("//", "/*", or "*/&quo= t;), then it MUST be enclosed within
>=C2=A0 =C2=A0double or single quotes.=C2=A0 If a string does not contai= n any of these
>=C2=A0 =C2=A0characters, it MAY be unquoted.
>
>=C2=A0 =C2=A0Within an unquoted string, every character is preserved.= =C2=A0 Note that
>=C2=A0 =C2=A0this means that the backslash character does not have any = special
>=C2=A0 =C2=A0meaning in an unquoted string.
> I like this.
>
> +1
>
>
>
> I don't understand this text.
> The parser looks for certain tokens in specific contexts.
>
>
>=C2=A0 =C2=A0container A;container B;container C;
>
>=C2=A0 =C2=A0container foo{container bar{container baz;}}
>
>=C2=A0 =C2=A0augment /foo/bar/baz{container Z;}
>
> pyang and yangdump-pro handle these unquoted strings correctly.
>
> I think your text is supposed to mean that chars with special meanings=
> in specific contexts need to be quoted to use them as plain chars with= out
> any special meaning.
>
> I strongly object to this new text since it tells the YANG author they=
> cannot use unquoted strings like the examples above.

Why do you think there is anything in the new text to this effect? All of y= our examples remain perfectly OK. The only change compared to 6020bis-09 is= that the newline, single- and double-quote characters cannot appear in unq= uoted argument strings.



If a string contains= any space, tab, or newline characters, a single
>=C2=A0 =C2=A0or= double quote, semicolon (";"), braces ("{" or &= quot;}"), or comment
>=C2=A0 =C2=A0sequences ("//", &q= uot;/*", or "*/"), then it MUST be enclosed within
>= ;=C2=A0 =C2=A0double or single quotes.=C2=A0


This is not true; =C2=A0The example above contains valid = unquoted strings that contain a semicolon.

The onl= y strings that MUST be encoded in quotes are a single quote or double quote= .
All parsers will look for the closing quote and there won't= be one.


IMO the only next needed:<= /div>

NEW:

=C2=A0 =C2=A0If a string contai= ns any single=C2=A0quote characters, then it MUST be enclosed within
=C2= =A0 =C2=A0double quotes.=C2=A0 If a string contains any double quote charac= ters, then it MUST be
=C2=A0 =C2=A0enclosed within single quotes,= or encoded within double quotes using an escape
=C2=A0 =C2=A0cha= racter '\', followed by the double quote character '"'= .


=C2=A0
Lada



Andy
=C2=A0
>
>
> Andy
>
>
> It should be noted that this may be viewed as a backwards incompatible=
> change, but I think it is similar to the change for escaped characters=
> in double quoted string ("backwards incompatible bugfix"). > Yes, I think so.
>
> This is nothing compared to the change of the accessible tree for outp= ut.
>
> Jernej
>
>
> Thanks, Lada
>
>
>
> /martin
>
>
>
> BTW, if we wanted to be extremely liberal, I don't understand why = the end-comment sequence "*/" is not allowed.
>
> Lada
>
> Jernej
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod > --
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a113fbdd48d3767052ad5b13b-- From nobody Tue Feb 2 21:59:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7E1A1E0E for ; Tue, 2 Feb 2016 21:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 7COVYF4-ZmUJ for ; Tue, 2 Feb 2016 21:59:19 -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 045111A1E0B for ; Tue, 2 Feb 2016 21:59:19 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:7135:8f16:dc93:99d3] (unknown [IPv6:2a01:5e0:29:ffff:7135:8f16:dc93:99d3]) by mail.nic.cz (Postfix) with ESMTPSA id 2D489181743; Wed, 3 Feb 2016 06:59:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454479157; bh=564eFs6x46kkvl0xdHOlfWNh30yO+cfKyNTlJuOlWe0=; h=From:Date:To; b=R8LqJd/uoynbEy/6y2j8Z9fXblVh+BDOsaXdC6edWJfwZfWehevGP3I2jK5XqbSp1 cqd8Nkoded4CHLjZKzvND+6DXfwu6eXM19UweSlX1qaDncBCLhh3d35BwUdKkwcsHD QItTR8awcIfxddkuc3BmCCreD/ig3QdRgwQ9qydE= 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, 3 Feb 2016 06:59:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76FCEA86-3B02-4E34-99F4-B17BE5A30952@nic.cz> References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> <56B09B5D.3000907@mg-soft.si> <8943AE12-3A15-456A-8B97-B2859278CDE2@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@ietf.org" Subject: Re: [netmod] chars that require quoting 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, 03 Feb 2016 05:59:22 -0000 > On 03 Feb 2016, at 05:02, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka wrote: >=20 > > On 02 Feb 2016, at 18:25, Andy Bierman wrote: > > > > > > > > On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak = wrote: > > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: > > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > > On 02 Feb 2016, at 09:51, Jernej Tuljak = wrote: > > > > Martin Bjorklund je 1.2.2016 ob 20:48 napisal: > > Juergen Schoenwaelder wrote: > > If a specification is not explicit enough, then people often = implement > > what they find implemented in other similar contexts. This means the > > code often ends up reflecting which tools an implementor was = familiar > > with. In a shell, echo f\"oo gives you f"oo (and the same is true = for > > Tcl, which has otherwise the behavior you implemented for pyang, > > treating " as a regular character in an unquoted string.) > > > > It would help to know what implementations do with identifiers like > > f"o"o and f\"o\"o. If they do different things, then there is likely > > some evidence that implementors arrived at different conclusions. > > I don't mind a clarification. How about: > > > > OLD: > > > > If a string contains any space, tab, or newline characters, a > > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > > "/*", or "*/"), then it MUST be enclosed within double or single > > quotes. > > > > NEW: > > > > If a string contains any space, tab, or newline characters, a > > semicolon (";"), braces ("{" or "}"), or comment sequences ("//", > > "/*", or "*/"), then it MUST be enclosed within double or single > > quotes. If a string does not contain any of these characters, it > > MAY be unquoted. > > > > Within an unquoted string, every character is preserved. Note = that > > this means that the backslash, single quote, and double quote > > characters can occur in an unquoted string. > > I don't think this can be implemented, like I did not in the linked = archive. It does not make clear whether these are two statements or a = single one: > > > > default "; > > units "; > > > > > > What about this: > > > > default ";//foo"; > > units \"; > > > > > > This is not the C and C++ way of doing things (possibly not even = SMIng way). These are the only languages mentioned in the document = (Section 6). It also does not promote readability and makes lexers = unnecessarily complex. > > +1 > > > > I think the safest solution would be to disallow in unquoted strings > > all characters that have a special meaning anywhere in YANG > > syntax. This can hardly cause any troubles to module authors. > > Fine with me. Something like: > > > > NEW: > > > > If a string contains any space, tab, or newline characters, a = single > > or double quote, semicolon (";"), braces ("{" or "}"), or comment > > sequences ("//", "/*", or "*/"), then it MUST be enclosed within > > double or single quotes. If a string does not contain any of = these > > characters, it MAY be unquoted. > > > > Within an unquoted string, every character is preserved. Note = that > > this means that the backslash character does not have any special > > meaning in an unquoted string. > > I like this. > > > > +1 > > > > > > > > I don't understand this text. > > The parser looks for certain tokens in specific contexts. > > > > > > container A;container B;container C; > > > > container foo{container bar{container baz;}} > > > > augment /foo/bar/baz{container Z;} > > > > pyang and yangdump-pro handle these unquoted strings correctly. > > > > I think your text is supposed to mean that chars with special = meanings > > in specific contexts need to be quoted to use them as plain chars = without > > any special meaning. > > > > I strongly object to this new text since it tells the YANG author = they > > cannot use unquoted strings like the examples above. >=20 > Why do you think there is anything in the new text to this effect? All = of your examples remain perfectly OK. The only change compared to = 6020bis-09 is that the newline, single- and double-quote characters = cannot appear in unquoted argument strings. >=20 >=20 >=20 > If a string contains any space, tab, or newline characters, a single > > or double quote, semicolon (";"), braces ("{" or "}"), or comment > > sequences ("//", "/*", or "*/"), then it MUST be enclosed within > > double or single quotes.=20 >=20 >=20 > This is not true; The example above contains valid unquoted strings = that contain a semicolon. Huh? The text is about characters in unquoted *argument* strings. The = semicolons in your examples aren't syntactically part of an argument. = This hasn't changed: semicolons and curly braces were not permitted in = an unquoted argument already in YANG 1.0. Lada >=20 > The only strings that MUST be encoded in quotes are a single quote or = double quote. > All parsers will look for the closing quote and there won't be one. >=20 >=20 > IMO the only next needed: >=20 > NEW: >=20 > If a string contains any single quote characters, then it MUST be = enclosed within > double quotes. If a string contains any double quote characters, = then it MUST be > enclosed within single quotes, or encoded within double quotes = using an escape > character '\', followed by the double quote character '"'. >=20 >=20 > =20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > > > Andy > > > > > > It should be noted that this may be viewed as a backwards = incompatible > > change, but I think it is similar to the change for escaped = characters > > in double quoted string ("backwards incompatible bugfix"). > > Yes, I think so. > > > > This is nothing compared to the change of the accessible tree for = output. > > > > Jernej > > > > > > Thanks, Lada > > > > > > > > /martin > > > > > > > > BTW, if we wanted to be extremely liberal, I don't understand why = the end-comment sequence "*/" is not allowed. > > > > Lada > > > > Jernej > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > 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 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 22:18:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF41A3BA3; Tue, 2 Feb 2016 22:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 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, RP_MATCHES_RCVD=-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 T1UUhIIIOZnu; Tue, 2 Feb 2016 22:18: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 643241A3BA2; Tue, 2 Feb 2016 22:18:12 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:7135:8f16:dc93:99d3] (unknown [IPv6:2a01:5e0:29:ffff:7135:8f16:dc93:99d3]) by mail.nic.cz (Postfix) with ESMTPSA id 80AB41803AB; Wed, 3 Feb 2016 07:18:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454480290; bh=mSRTSPs7zsQ8LoR22L5FTEdtHveZHj+T1LuSoWpf+wA=; h=From:Date:To; b=IS3L7FNQa2OHe10XUbOazpZbEeFn/AjOY4iAr40Ij0o6/wALecFs7fRHeb6je9sTA L1WnsPfYTqkwaxyI2s4Dk/gsb78KtQejIwOD6a7SbQ3phwsmsSFO/dtY5SJnXt97TZ bb7brZkitwVxGFSfgwMO4scLjWpcquba39WZ3Ji0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> Date: Wed, 3 Feb 2016 07:18:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> 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: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , netmod WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 06:18:14 -0000 > On 03 Feb 2016, at 03:24, Kent Watsen wrote: >=20 >=20 > [Chair hat on] >=20 > Given the number of competing/complementing drafts involved, and the = general lack of discussion on any of them, a virtual interim meeting = might be an expedient way to proceed. In fairness, we know that there = has been some discussion, but it hasn=E2=80=99t been picked up yet in a = big way, and now Lou has an updated draft. =20 >=20 > The chairs discussed maybe scheduling one for a couple weeks from now, = perhaps Thursday Feb 18 starting at 10am EST? I'm thinking Thursday at this time doesn't suit me very well, Monday till Wednesday = of that week are OK. Lada > about this slot only since it worked for us for previously. Is this = a good time slot? I assume to schedule for 2 hours, with a plan to end = early if needed - makes sense? We also need to put together a proper = agenda, perhaps the following? >=20 > 10 min: RTG DT YANG Arch team use-case summary > 20 min: draft-rtgyangdt-rtgwg-device-model > 20 min: draft-lhotka-netmod-ysdl > 20 min: draft-bjorklund-netmod-structural-mount > 50 min: general discussion or end early >=20 >=20 > We hope to schedule the meeting itself tomorrow or the next day, so = please respond quickly to this email if possible. >=20 > Thanks, > Kent and Tom >=20 >=20 >=20 >=20 > On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" = wrote: >=20 >>=20 >> I thought it would be worth summarizing what we're looking for in our >> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in = case >> you missed it) with respect to the draft-lhotka-netmod-ysdl and >> draft-bjorklund-netmod-structural-mount drafts. This is just my view, = so >> my co-authors may wish to chime in and correct me. >>=20 >> I'd be interested in hearing from the authors of YSDL and >> structural-mount, or anyone else for that matter, on how they see to >> best meet these needs. >>=20 >> Here's what I think our draft needs: >>=20 >> 1. that there be a mechanism that allows the incorporation (or >> 'mounting') of the data model defined by one top-level module >> within another module. >>=20 >> The implication here is that when information is instantiated >> for the parent model it is also instantiated for the >> incorporated/mounted model. In our case we expect to do this on >> list element creation. Both solutions drafts cover the path >> implications, so these are not repeated here. >>=20 >> 2. that this mechanism allow identification of specific modules to >> be incorporated/mounted at time of module definition, i.e. that >> no additional module is needed to support 1. This doesn't >> preclude definition of such a module. >>=20 >> 3. that this mechanism allow for a server to control (and >> identify) which modules are incorporated/mounted. (see Section >> 3 LNE in our draft for an envisioned usage.) >>=20 >> 4. that all capabilities that exist with the mounted module are >> available e.g. RPC operations and notifications. >>=20 >> 5. while our primary requirement is for 'mounting' of top level >> modules, mounting of submodules may also be useful. (DT not draft >> driven.) >>=20 >> We make use of the above in sections 3 and 4 of rtgwg-device-model. = We >> see having a solution as critical for the simplifications/flexibility >> represented in the -02 version of our draft vs the -03 rev. We don't >> see wither solution draft as significantly different and just hope = for a >> standard solution as soon as possible. (a draft-ietf-netmod = solutions >> draft on the topic by BA would be fantastic given the impact on = routing >> area -- even if it had to document two variations / alternative = solutions.) >>=20 >> Again, this is just my opinion and my coauthors or others on the rtg >> area yang DT may choose to chime in. >>=20 >> Lou >>=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 Feb 3 00:03:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6741B3369 for ; Wed, 3 Feb 2016 00:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-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 dGmL91UPgCRE for ; Wed, 3 Feb 2016 00:03:33 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id C30211B3364 for ; Wed, 3 Feb 2016 00:03:32 -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 29776C001FE0; Wed, 3 Feb 2016 09:03:31 +0100 (CET) To: Ladislav Lhotka , Andy Bierman References: <20160201.204828.1537890819794101926.mbj@tail-f.com> <56B06E20.8020405@mg-soft.si> <4B26590E-8453-48E1-A63E-25B795B286D9@nic.cz> <20160202.121627.103563641669027534.mbj@tail-f.com> <968D4208-0D09-4B58-BEF5-A009EF225362@nic.cz> <56B09B5D.3000907@mg-soft.si> <8943AE12-3A15-456A-8B97-B2859278CDE2@nic.cz> <76FCEA86-3B02-4E34-99F4-B17BE5A30952@nic.cz> From: Jernej Tuljak Message-ID: <56B1B452.5070404@mg-soft.si> Date: Wed, 3 Feb 2016 09:03:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <76FCEA86-3B02-4E34-99F4-B17BE5A30952@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] chars that require quoting 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, 03 Feb 2016 08:03:36 -0000 Ladislav Lhotka je 3.2.2016 ob 6:59 napisal: >> On 03 Feb 2016, at 05:02, Andy Bierman wrote: >> >> >> >> On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka wrote: >> >>> On 02 Feb 2016, at 18:25, Andy Bierman wrote: >>> >>> >>> >>> On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak wrote: >>> Ladislav Lhotka je 2.2.2016 ob 12:25 napisal: >>> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote: >>> >>> Ladislav Lhotka wrote: >>> On 02 Feb 2016, at 09:51, Jernej Tuljak wrote: >>> >>> Martin Bjorklund je 1.2.2016 ob 20:48 napisal: >>> Juergen Schoenwaelder wrote: >>> If a specification is not explicit enough, then people often implement >>> what they find implemented in other similar contexts. This means the >>> code often ends up reflecting which tools an implementor was familiar >>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for >>> Tcl, which has otherwise the behavior you implemented for pyang, >>> treating " as a regular character in an unquoted string.) >>> >>> It would help to know what implementations do with identifiers like >>> f"o"o and f\"o\"o. If they do different things, then there is likely >>> some evidence that implementors arrived at different conclusions. >>> I don't mind a clarification. How about: >>> >>> OLD: >>> >>> If a string contains any space, tab, or newline characters, a >>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>> "/*", or "*/"), then it MUST be enclosed within double or single >>> quotes. >>> >>> NEW: >>> >>> If a string contains any space, tab, or newline characters, a >>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", >>> "/*", or "*/"), then it MUST be enclosed within double or single >>> quotes. If a string does not contain any of these characters, it >>> MAY be unquoted. >>> >>> Within an unquoted string, every character is preserved. Note that >>> this means that the backslash, single quote, and double quote >>> characters can occur in an unquoted string. >>> I don't think this can be implemented, like I did not in the linked archive. It does not make clear whether these are two statements or a single one: >>> >>> default "; >>> units "; >>> >>> >>> What about this: >>> >>> default ";//foo"; >>> units \"; >>> >>> >>> This is not the C and C++ way of doing things (possibly not even SMIng way). These are the only languages mentioned in the document (Section 6). It also does not promote readability and makes lexers unnecessarily complex. >>> +1 >>> >>> I think the safest solution would be to disallow in unquoted strings >>> all characters that have a special meaning anywhere in YANG >>> syntax. This can hardly cause any troubles to module authors. >>> Fine with me. Something like: >>> >>> NEW: >>> >>> If a string contains any space, tab, or newline characters, a single >>> or double quote, semicolon (";"), braces ("{" or "}"), or comment >>> sequences ("//", "/*", or "*/"), then it MUST be enclosed within >>> double or single quotes. If a string does not contain any of these >>> characters, it MAY be unquoted. >>> >>> Within an unquoted string, every character is preserved. Note that >>> this means that the backslash character does not have any special >>> meaning in an unquoted string. >>> I like this. >>> >>> +1 >>> >>> >>> >>> I don't understand this text. >>> The parser looks for certain tokens in specific contexts. >>> >>> >>> container A;container B;container C; >>> >>> container foo{container bar{container baz;}} >>> >>> augment /foo/bar/baz{container Z;} >>> >>> pyang and yangdump-pro handle these unquoted strings correctly. >>> >>> I think your text is supposed to mean that chars with special meanings >>> in specific contexts need to be quoted to use them as plain chars without >>> any special meaning. >>> >>> I strongly object to this new text since it tells the YANG author they >>> cannot use unquoted strings like the examples above. >> Why do you think there is anything in the new text to this effect? All of your examples remain perfectly OK. The only change compared to 6020bis-09 is that the newline, single- and double-quote characters cannot appear in unquoted argument strings. >> >> >> >> If a string contains any space, tab, or newline characters, a single >>> or double quote, semicolon (";"), braces ("{" or "}"), or comment >>> sequences ("//", "/*", or "*/"), then it MUST be enclosed within >>> double or single quotes. >> >> This is not true; The example above contains valid unquoted strings that contain a semicolon. > Huh? The text is about characters in unquoted *argument* strings. The semicolons in your examples aren't syntactically part of an argument. This hasn't changed: semicolons and curly braces were not permitted in an unquoted argument already in YANG 1.0. I agree. container A ; container B ; container C ; container foo { container bar { container baz ; } } augment /foo/bar/baz { container Z ; } The semantics of the above should be equivalent to Andy's example. This is probably some sort of a misunderstanding. The new text is only adding quotes and newlines to the list of characters that need to be inside quoted strings in order to not be recognized as a token, a token start or a token separator. Jernej > > Lada > >> The only strings that MUST be encoded in quotes are a single quote or double quote. >> All parsers will look for the closing quote and there won't be one. >> >> >> IMO the only next needed: >> >> NEW: >> >> If a string contains any single quote characters, then it MUST be enclosed within >> double quotes. If a string contains any double quote characters, then it MUST be >> enclosed within single quotes, or encoded within double quotes using an escape >> character '\', followed by the double quote character '"'. >> >> >> >> Lada >> >> >> >> Andy >> >>> >>> Andy >>> >>> >>> It should be noted that this may be viewed as a backwards incompatible >>> change, but I think it is similar to the change for escaped characters >>> in double quoted string ("backwards incompatible bugfix"). >>> Yes, I think so. >>> >>> This is nothing compared to the change of the accessible tree for output. >>> >>> Jernej >>> >>> >>> Thanks, Lada >>> >>> >>> >>> /martin >>> >>> >>> >>> BTW, if we wanted to be extremely liberal, I don't understand why the end-comment sequence "*/" is not allowed. >>> >>> Lada >>> >>> Jernej >>> >>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> 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 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From nobody Wed Feb 3 00:59:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0971A6FE0 for ; Wed, 3 Feb 2016 00:59:20 -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, KHOP_DYNAMIC=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 T2hUXuuZ37sV for ; Wed, 3 Feb 2016 00:59:18 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C151A6FDC for ; Wed, 3 Feb 2016 00:59:18 -0800 (PST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u138fwgR005794 for ; Wed, 3 Feb 2016 00:59:18 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 20rwf31aj6-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 03 Feb 2016 00:59:18 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 01:59:09 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 09:59:07 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 3 Feb 2016 09:59:07 +0100 From: William Ivory To: "netmod@ietf.org" Thread-Topic: Where can I insert new YANG substatements? Thread-Index: AdFeYJUcfd1aQ+BIRySt2Lm2mL07Fg== Date: Wed, 3 Feb 2016 08:58:51 +0000 Deferred-Delivery: Wed, 3 Feb 2016 08:58:25 +0000 Message-ID: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.156] Content-Type: multipart/alternative; boundary="_000_0504bc5b25454d8e93c6906b179fc1afEMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602030159 Archived-At: Subject: [netmod] Where can I insert new YANG substatements? 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, 03 Feb 2016 08:59:20 -0000 --_000_0504bc5b25454d8e93c6906b179fc1afEMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, My colleagues and I are looking for clarification of the last point in Section 10 of YANG 1.0: ' In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered.' We understand that existing statements must not be reordered in a new revision of a YANG module, but we're not clear if new statements may be inserted between existing statements, or must always come at the 'end' of a list or container definition. A specific example we're concerned with is where a grouping is used, and then later that grouping has an extra element added, but the new node could also be added directly. Eg: Container foo { Leaf A Uses grouping B; Leaf C Leaf D } Is it valid in a new revision of the module to do the following, or must the order be A, B, C, D, E? What if grouping B has gained a new statement? Container foo { Leaf A Uses grouping B; Leaf C Leaf E < ---- ADDED Leaf D } Thanks, William --_000_0504bc5b25454d8e93c6906b179fc1afEMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
My colleagues and I are looking for clarification of the last point in= Section 10 of YANG 1.0:
 
‘   In statements that have any data definition statem= ents as
   substatements, those data definition substatements MUST N= OT be
   reordered.’
 
We understand that existing statements must not be reordered in a new = revision of a YANG module, but we’re not clear if new statements may = be inserted between existing statements, or must always come at the ‘= end’ of a list or container definition.  A specific example we’re concerned with is where a grouping is used, and then la= ter that grouping has an extra element added, but the new node could also b= e added directly.  Eg:
 
Container foo {
        Leaf A
        Uses grouping B;
        Leaf C
        Leaf D
}
 
Is it valid in a new revision of the module to do the following, or mu= st the order be A, B, C, D, E?  What if grouping B has gained a new st= atement?
 
Container foo {
        Leaf A
        Uses grouping B;
        Leaf C
        Leaf E < ---- ADDED
        Leaf D
}
 
Thanks,
 
William
 
 
 --_000_0504bc5b25454d8e93c6906b179fc1afEMEAWPEXMB12corpbrocade_-- From nobody Wed Feb 3 01:19:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656E81A8716 for ; Wed, 3 Feb 2016 01:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 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, RP_MATCHES_RCVD=-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 kZYDByYYF23Q for ; Wed, 3 Feb 2016 01:19:29 -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 5129F1A870F for ; Wed, 3 Feb 2016 01:19:29 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48] (unknown [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48]) by mail.nic.cz (Postfix) with ESMTPSA id C9CEC1802DC; Wed, 3 Feb 2016 10:19:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454491167; bh=IpHX376QuqRU3X3qnQqQbIZNhAfwA+bWJuMV+a2/ftw=; h=From:Date:To; b=Eqv9iipXjX+aTDSnKyuAEYbJ5FACEpXCITmoJcGgD4JJiVmND4NH6DbUqUMquYRsU UrgdxQWIbJJweFw6rXmKOKRO/+AmGSh7NOkHjezRtCQORU9soyDluFznWV6iOyPOgy p0bToxb2q/YZV2WNrweNbXKH42OM+JDqGrV2LOBk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> Date: Wed, 3 Feb 2016 10:19:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> To: William Ivory 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] Where can I insert new YANG substatements? 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, 03 Feb 2016 09:19:31 -0000 Hi William, > On 03 Feb 2016, at 09:58, William Ivory wrote: >=20 > Hi, > =20 > My colleagues and I are looking for clarification of the last point in = Section 10 of YANG 1.0: > =20 > =E2=80=98 In statements that have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered.=E2=80=99 This was already discussed: https://mailarchive.ietf.org/arch/msg/netmod/CiVOMEDXfbQKKbgTXTznZh2HQQw My understanding was that the paragraph you cite would be modified in = 6020bis, but apparently it hasn't been so far. I don't see any reason = for insisting on the order of sibling data node definitions in = configuration and state data since in instance documents the order is = arbitrary in both XML and JSON encoding. > =20 > We understand that existing statements must not be reordered in a new = revision of a YANG module, but we=E2=80=99re not clear if new statements = may be inserted between existing statements, or must always come at the = =E2=80=98end=E2=80=99 of a list or container definition. A specific = example we=E2=80=99re concerned with is where a grouping is used, and = then later that grouping has an extra element added, but the new node = could also be added directly. Eg: > =20 > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf D=20 > } > =20 > Is it valid in a new revision of the module to do the following, or = must the order be A, B, C, D, E? What if grouping B has gained a new = statement? > =20 > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf E < ---- ADDED > Leaf D > } I think this is allowed in any case. Lada > =20 > Thanks, > =20 > 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 Wed Feb 3 01:56:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED741A888B for ; Wed, 3 Feb 2016 01:56:37 -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, KHOP_DYNAMIC=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 o4eAUUgHu56V for ; Wed, 3 Feb 2016 01:56:36 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBC71A8889 for ; Wed, 3 Feb 2016 01:56:35 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u139sBfQ025404; Wed, 3 Feb 2016 01:56:26 -0800 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 20rup61sse-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Feb 2016 01:56:25 -0800 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 02:56:09 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 10:56:07 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 3 Feb 2016 10:56:07 +0100 From: William Ivory To: Ladislav Lhotka Thread-Topic: [netmod] Where can I insert new YANG substatements? Thread-Index: AdFeYJUcfd1aQ+BIRySt2Lm2mL07Fv//9ggA///l7QA= Date: Wed, 3 Feb 2016 09:55:40 +0000 Deferred-Delivery: Wed, 3 Feb 2016 09:55:06 +0000 Message-ID: References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.156] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602030181 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Where can I insert new YANG substatements? 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, 03 Feb 2016 09:56:37 -0000 SGkgTGFkYSwNCg0KSSB3YXMgaG9waW5nIGZvciBtb3JlIHRoYW4gJ0kgdGhpbmsnIGFuZCAnIEht bS4gIFRoZSBydWxlIGlzIG5vdCBjbGVhci4gIEluIGZhY3QsIG9uZSBjYW4gYXJndWUgdGhhdCBp dCBpcyB3cm9uZzonLiAgSXMgYW55b25lIHdpbGxpbmcgLyBhYmxlIHRvIGdpdmUgbWUgYSBkZWZp bml0aXZlIGFuc3dlcj8NCg0KVGhhbmtzLA0KDQpXaWxsaWFtDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XSAN ClNlbnQ6IDAzIEZlYnJ1YXJ5IDIwMTYgMDk6MTkNClRvOiBXaWxsaWFtIEl2b3J5IDx3aXZvcnlA QnJvY2FkZS5jb20+DQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0g V2hlcmUgY2FuIEkgaW5zZXJ0IG5ldyBZQU5HIHN1YnN0YXRlbWVudHM/DQoNCkhpIFdpbGxpYW0s DQoNCg0KPiBPbiAwMyBGZWIgMjAxNiwgYXQgMDk6NTgsIFdpbGxpYW0gSXZvcnkgPHdpdm9yeUBC cm9jYWRlLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gIA0KPiBNeSBjb2xsZWFndWVzIGFuZCBJ IGFyZSBsb29raW5nIGZvciBjbGFyaWZpY2F0aW9uIG9mIHRoZSBsYXN0IHBvaW50IGluIFNlY3Rp b24gMTAgb2YgWUFORyAxLjA6DQo+ICANCj4g4oCYICAgSW4gc3RhdGVtZW50cyB0aGF0IGhhdmUg YW55IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIGFzDQo+ICAgIHN1YnN0YXRlbWVudHMsIHRo b3NlIGRhdGEgZGVmaW5pdGlvbiBzdWJzdGF0ZW1lbnRzIE1VU1QgTk9UIGJlDQo+ICAgIHJlb3Jk ZXJlZC7igJkNCg0KVGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQ6DQoNCmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuaWV0Zi5v cmdfYXJjaF9tc2dfbmV0bW9kX0NpVk9NRURYZmJRS0tiZ1RYVHpuWmgySFFRdyZkPUN3SUZhUSZj PUlMX1hxUVdPanViZ2ZxSU5pMmpUemcmcj1HQnlMZWc5alp2T3ZfQWxnQm85dXZkRHJ4aXpsT1I3 bF9TblRYb3d5SlU4Jm09SVZXbkhQSW0wcUVIbXhzdzZIaHBfMXhoZG4ybElDNENTek1Dc2poLXpM byZzPVNxVTd3LW11UzR0X3poSDE5XzFpeVBMVmwzdEQyNE9VZ0ppamtwNE5YNEUmZT0gDQoNCk15 IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhlIHBhcmFncmFwaCB5b3UgY2l0ZSB3b3VsZCBiZSBt b2RpZmllZCBpbiA2MDIwYmlzLCBidXQgYXBwYXJlbnRseSBpdCBoYXNuJ3QgYmVlbiBzbyBmYXIu IEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gZm9yIGluc2lzdGluZyBvbiB0aGUgb3JkZXIgb2Ygc2li bGluZyBkYXRhIG5vZGUgZGVmaW5pdGlvbnMgaW4gY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0 YSBzaW5jZSBpbiBpbnN0YW5jZSBkb2N1bWVudHMgdGhlIG9yZGVyIGlzIGFyYml0cmFyeSBpbiBi b3RoIFhNTCBhbmQgSlNPTiBlbmNvZGluZy4NCg0KPiAgDQo+IFdlIHVuZGVyc3RhbmQgdGhhdCBl eGlzdGluZyBzdGF0ZW1lbnRzIG11c3Qgbm90IGJlIHJlb3JkZXJlZCBpbiBhIG5ldyByZXZpc2lv biBvZiBhIFlBTkcgbW9kdWxlLCBidXQgd2XigJlyZSBub3QgY2xlYXIgaWYgbmV3IHN0YXRlbWVu dHMgbWF5IGJlIGluc2VydGVkIGJldHdlZW4gZXhpc3Rpbmcgc3RhdGVtZW50cywgb3IgbXVzdCBh bHdheXMgY29tZSBhdCB0aGUg4oCYZW5k4oCZIG9mIGEgbGlzdCBvciBjb250YWluZXIgZGVmaW5p dGlvbi4gIEEgc3BlY2lmaWMgZXhhbXBsZSB3ZeKAmXJlIGNvbmNlcm5lZCB3aXRoIGlzIHdoZXJl IGEgZ3JvdXBpbmcgaXMgdXNlZCwgYW5kIHRoZW4gbGF0ZXIgdGhhdCBncm91cGluZyBoYXMgYW4g ZXh0cmEgZWxlbWVudCBhZGRlZCwgYnV0IHRoZSBuZXcgbm9kZSBjb3VsZCBhbHNvIGJlIGFkZGVk IGRpcmVjdGx5LiAgRWc6DQo+ICANCj4gQ29udGFpbmVyIGZvbyB7DQo+ICAgICAgICAgTGVhZiBB DQo+ICAgICAgICAgVXNlcyBncm91cGluZyBCOw0KPiAgICAgICAgIExlYWYgQw0KPiAgICAgICAg IExlYWYgRCANCj4gfQ0KPiAgDQo+IElzIGl0IHZhbGlkIGluIGEgbmV3IHJldmlzaW9uIG9mIHRo ZSBtb2R1bGUgdG8gZG8gdGhlIGZvbGxvd2luZywgb3IgbXVzdCB0aGUgb3JkZXIgYmUgQSwgQiwg QywgRCwgRT8gIFdoYXQgaWYgZ3JvdXBpbmcgQiBoYXMgZ2FpbmVkIGEgbmV3IHN0YXRlbWVudD8N Cj4gIA0KPiBDb250YWluZXIgZm9vIHsNCj4gICAgICAgICBMZWFmIEENCj4gICAgICAgICBVc2Vz IGdyb3VwaW5nIEI7DQo+ICAgICAgICAgTGVhZiBDDQo+ICAgICAgICAgTGVhZiBFIDwgLS0tLSBB RERFRA0KPiAgICAgICAgIExlYWYgRA0KPiB9DQoNCkkgdGhpbmsgdGhpcyBpcyBhbGxvd2VkIGlu IGFueSBjYXNlLg0KDQpMYWRhDQoNCj4gIA0KPiBUaGFua3MsDQo+ICANCj4gV2lsbGlhbQ0KPiAg DQo+ICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19uZXRtb2QmZD1Dd0lGYVEmYz1JTF9YcVFXT2p1YmdmcUlOaTJqVHpnJnI9 R0J5TGVnOWpadk92X0FsZ0JvOXV2ZERyeGl6bE9SN2xfU25UWG93eUpVOCZtPUlWV25IUEltMHFF SG14c3c2SGhwXzF4aGRuMmxJQzRDU3pNQ3NqaC16TG8mcz0walFWMjJWZUNVZzVQRHhnR2owZmlo OG9yMTN5RlNZRXNNcUsxQUxhZ3U4JmU9IA0KDQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMg TGFicw0KUEdQIEtleSBJRDogRTc0RThDMEMNCg0KDQoNCg0K From nobody Wed Feb 3 02:19:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AFE1A8927 for ; Wed, 3 Feb 2016 02:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 HS9rb0sgDkIh for ; Wed, 3 Feb 2016 02:19:36 -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 CCC771A891A for ; Wed, 3 Feb 2016 02:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11066; q=dns/txt; s=iport; t=1454494775; x=1455704375; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=amiaWGqABlAsAgv3+ArO2U+cmOXe0AOs9vllpx8vWq4=; b=jWs7b5rrN7yVQzAPJHrpC1Yx9OEhFNTfnvExdigTc8k+43RAXr0itbqR YKN9BYszbmc+QKSM1aUNUojtH6HZlXRsmqU0Zp763uUnA+vjLAWOXLFYy JMOkpZTj3AK4VFCHCoH93CjUGojuC1/QUwXnJh5wvBWrwVgjuBko528te o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBACZ07FW/xbLJq1VCYQMZwaIW7MxI?= =?us-ascii?q?4VqAoIEAQEBAQEBgQuEQgEBBCNVESwWCwICCQMCAQIBRQYBDAgBAYgXCQWwSo8?= =?us-ascii?q?PAQEBAQEBAQEBAQEBAQEBAQEBAReGEohAgymBOgWFTYdYiUyFSYJsgmOCNYIlh?= =?us-ascii?q?nuFUYcQhzBig2U7LgGJagEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,389,1449532800"; d="scan'208,217";a="630201616" 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; 03 Feb 2016 10:19:33 +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 u13AJXgF010061; Wed, 3 Feb 2016 10:19:33 GMT References: <56B0DD74.4060309@cisco.com> From: Benoit Claise To: NETMOD Working Group , lhotka@nic.cz X-Forwarded-Message-Id: <56B0DD74.4060309@cisco.com> Message-ID: <56B1D435.7030506@cisco.com> Date: Wed, 3 Feb 2016 11:19:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B0DD74.4060309@cisco.com> Content-Type: multipart/alternative; boundary="------------010208070202030305050505" Archived-At: Subject: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 10:19:39 -0000 This is a multi-part message in MIME format. --------------010208070202030305050505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I understood from the chairs that draft-ietf-netmod-yang-json is now ready and that the write-up will be completed end of this week. In order to speed up the publication, here is my AD review. - Editorial: This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. "RPC operation or action input and output parameters" ", or ... and, " it's always complicated. Why not only "RPC operation or action"? At the very minimum "input and output parameters" to "input/output parameters" Same remark for section 1.1 The specification of YANG 1.1 data modelling language [I-D.ietf-netmod-rfc6020bis ] defines only XML encoding for data instances, i.e., contents of configuration datastores, state data, RPC operation or action input and output parameters, and event notifications. If you want to extend, also fine. The specification of YANG 1.1 data modelling language [I-D.ietf-netmod-rfc6020bis ] defines only XML encoding for data instances, i.e., contents of configuration datastores, state data, RPC operation input and output parameters, action input and output parameters, and event notifications. Btw, "RPC", "action" and "input and output parameters" are only mentioned in the abstract and this introduction, not anymore in the body of the document. There is nothing specific to these worth noting? Not even an example? - Editorial In the introduction, you might want to complete the last sentence NEW: The specification of YANG 1.1 data modelling language [I-D.ietf-netmod-rfc6020bis ] defines only XML encoding for data instances, i.e., contents of configuration datastores, state data, RPC operation or action input and output parameters, and event notifications. The aim of this document is to define rules for encoding the same data as JavaScript Object Notation (JSON) text [RFC7159 ]. NEW: The specification of YANG 1.1 data modelling language [I-D.ietf-netmod-rfc6020bis ] defines only XML encoding for data instances, i.e., contents of configuration datastores, state data, RPC operation or action input and output parameters, and event notifications. The aim of this document is to define rules for encoding the same data as JavaScript Object Notation (JSON) text [RFC7159 ], most precisely the Internet JSON (I-JSON) restricted profile [RFC7493 ]. - section 2: The following terms are defined in [I-D.ietf-netmod-rfc6020bis ]: ... o identity, There is no identity definition in the RFC 6020 terminology section. Are you referring to the identity statement, https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 ? - Editorial. OLD: An object member name MUST be in one of the following forms: NEW: A JSON object member name MUST be encoded in one of the following forms: - module foomod { namespace"http://example.com/foomod"; prefix "foo"; container top { leaf foo { type uint8; } } } Use "example-" in the module name, as mentioned inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: Example modules are non-normative, and SHOULD be named with the prefix "example-". Same remark for module barmod (and btw, pay attention to the "import foomod") and module exmod - Editorial (Appendix A): OLD: The "if-mib" feature defined in the "ietf- interfaces" module is considered to be active. NEW: The "if-mib" feature defined in the "ietf- interfaces" module is supported. Regards, Benoit --------------010208070202030305050505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

I understood from the chairs that draft-ietf-netmod-yang-json is now ready and that the write-up will be completed end of this week.
In order to speed up the publication, here is my AD review.

- Editorial:

   This document defines encoding rules for representing configuration,
   state data, RPC operation or action input and output parameters, and
   notifications defined using YANG as JavaScript Object Notation (JSON)
   text.
"RPC operation or action input and output parameters"
", or ... and, " it's always complicated.
Why not only "RPC operation or action"?

At the very minimum "input and output parameters" to "input/output parameters"

Same remark for section 1.1
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis] defines only XML encoding for data
   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.
If you want to extend, also fine.

   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis] defines only XML encoding for data
   instances, i.e., contents of configuration datastores, state data,
   RPC operation input and output parameters, action input and output 
   parameters, and event notifications.
Btw, "RPC", "action" and "input and output parameters" are only mentioned in the abstract and this introduction, not anymore in the body of the document. There is nothing specific to these worth noting? Not even an example?

- Editorial

In the introduction, you might want to complete the last sentence 
NEW:
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis] defines only XML encoding for data
   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159].

NEW: 
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis] defines only XML encoding for data
   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159], most precisely the Internet JSON (I-JSON) restricted 
   profile [RFC7493].

-
section 2:
   The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:
      ...

   o  identity,
There is no identity definition in the RFC 6020 terminology section.
Are you referring to the identity statement, https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 ?

- Editorial. 
OLD:
	An object member name MUST be in one of the following forms:
NEW:
	A JSON object member name MUST be encoded in one of the following forms:


- 
  module foomod {

     namespace "http://example.com/foomod";

     prefix "foo";

     container top {
       leaf foo {
         type uint8;
       }
     }
   }

Use "example-" in the module name, as mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: 

   Example modules are non-normative, and SHOULD be named with the
   prefix "example-".
Same remark for module barmod (and btw, pay attention to the "import foomod") and module exmod


- Editorial (Appendix A):
OLD:
   The "if-mib" feature defined in the "ietf-
   interfaces" module is considered to be active.

NEW: 
   The "if-mib" feature defined in the "ietf-
   interfaces" module is supported.
Regards, Benoit
--------------010208070202030305050505-- From nobody Wed Feb 3 02:42:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341011A8A84; Wed, 3 Feb 2016 02:42:31 -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 vr_u2KTI1Og2; Wed, 3 Feb 2016 02:42:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.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 B371D1A8A83; Wed, 3 Feb 2016 02:42:27 -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.396.15; Wed, 3 Feb 2016 10:42:24 +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.0396.020; Wed, 3 Feb 2016 10:42:24 +0000 From: Kent Watsen To: Ladislav Lhotka Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgACU/gD///YCAA== Date: Wed, 3 Feb 2016 10:42:24 +0000 Message-ID: <5B1FBBFD-35F2-4849-9B21-9002CF270B3B@juniper.net> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:qHH7WJeMjztF7aUF3ctOrt055sfDR41S4PqzPhbMJhvaYAfyLLWzsNxCIL+ZMS08FJ8tzKb7uO9AliixyPp5c4zvNK62O1NlVj9Tl53J1J2bj2Ge1ZAMQvYcqYIO9DbEzIeX2RpcfKIC/kjgOXQTMQ==; 24:ZHRuuH+Gv02u4mpjL7Li3eAFf8/S7NAfseNgnfgV+lA1G5o9jx3STW14ovz8csUPR0R/u2fFkHgV43MdkgdLmrq+cqo4f5UFh6vWjeU4rY4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 1288343c-0936-4059-e149-08d32c86b416 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(377454003)(479174004)(5001960100002)(36756003)(5008740100001)(40100003)(33656002)(122556002)(15395725005)(189998001)(66066001)(3660700001)(3280700002)(83716003)(110136002)(5004730100002)(2906002)(77096005)(5002640100001)(10400500002)(106116001)(6116002)(2950100001)(2900100001)(87936001)(15975445007)(4001350100001)(4326007)(11100500001)(3846002)(76176999)(92566002)(83506001)(586003)(19580405001)(82746002)(99286002)(575784001)(54356999)(86362001)(19580395003)(50986999)(1096002)(1720100001)(1220700001)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <977755A2E39AFF479AC8346295D6C48A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 10:42:24.6760 (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: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , netmod WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 10:42:31 -0000 DQoNCk9rYXksIEkgc2V0IHVwIGEgZG9vZGxlIHBvbGwgdG8gaGVscCB1cyBwaWNrIGEgdGltZToN Cg0KCWh0dHA6Ly9kb29kbGUuY29tL3BvbGwvZHY2OHBzeG4zM3l0NGVoZg0KDQpXb3VsZCB0aGUg ZHJhZnQgYXV0aG9ycyBhbmQgb3RoZXIga2V5IHBhcnRpY2lwYW50cyBwbGVhc2UgZmlsbCBpbiB0 aGVpciBhdmFpbGFiaWxpdHk/DQoNClRoYW5rcywNCktlbnQNCg0KDQoNCg0KT24gMi8zLzE2LCAx OjE4IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQoNCj4NCj4+ IE9uIDAzIEZlYiAyMDE2LCBhdCAwMzoyNCwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5u ZXQ+IHdyb3RlOg0KPj4gDQo+PiANCj4+IFtDaGFpciBoYXQgb25dDQo+PiANCj4+IEdpdmVuIHRo ZSBudW1iZXIgb2YgY29tcGV0aW5nL2NvbXBsZW1lbnRpbmcgZHJhZnRzIGludm9sdmVkLCBhbmQg dGhlIGdlbmVyYWwgbGFjayBvZiBkaXNjdXNzaW9uIG9uIGFueSBvZiB0aGVtLCBhIHZpcnR1YWwg aW50ZXJpbSBtZWV0aW5nIG1pZ2h0IGJlIGFuIGV4cGVkaWVudCB3YXkgdG8gcHJvY2VlZC4gIElu IGZhaXJuZXNzLCB3ZSBrbm93IHRoYXQgdGhlcmUgaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uLCBi dXQgaXQgaGFzbuKAmXQgYmVlbiBwaWNrZWQgdXAgeWV0IGluIGEgYmlnIHdheSwgYW5kIG5vdyBM b3UgaGFzIGFuIHVwZGF0ZWQgZHJhZnQuICANCj4+IA0KPj4gVGhlIGNoYWlycyBkaXNjdXNzZWQg bWF5YmUgc2NoZWR1bGluZyBvbmUgZm9yIGEgY291cGxlIHdlZWtzIGZyb20gbm93LCBwZXJoYXBz IFRodXJzZGF5IEZlYiAxOCBzdGFydGluZyBhdCAxMGFtIEVTVD8gICBJJ20gdGhpbmtpbmcNCj4N Cj5UaHVyc2RheSBhdCB0aGlzIHRpbWUgZG9lc24ndCBzdWl0IG1lIHZlcnkgd2VsbCwgTW9uZGF5 IHRpbGwgV2VkbmVzZGF5IG9mIHRoYXQgd2VlayBhcmUgT0suDQo+DQo+TGFkYQ0KPg0KPj4gIGFi b3V0IHRoaXMgc2xvdCBvbmx5IHNpbmNlIGl0IHdvcmtlZCBmb3IgdXMgZm9yIHByZXZpb3VzbHku ICBJcyB0aGlzIGEgZ29vZCB0aW1lIHNsb3Q/ICBJIGFzc3VtZSB0byBzY2hlZHVsZSBmb3IgMiBo b3Vycywgd2l0aCBhIHBsYW4gdG8gZW5kIGVhcmx5IGlmIG5lZWRlZCAtIG1ha2VzIHNlbnNlPyAg ICAgV2UgYWxzbyBuZWVkIHRvIHB1dCB0b2dldGhlciBhIHByb3BlciBhZ2VuZGEsIHBlcmhhcHMg dGhlIGZvbGxvd2luZz8NCj4+IA0KPj4gIDEwIG1pbjogUlRHIERUIFlBTkcgQXJjaCB0ZWFtIHVz ZS1jYXNlIHN1bW1hcnkNCj4+ICAyMCBtaW46IGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2Ut bW9kZWwNCj4+ICAyMCBtaW46IGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbA0KPj4gIDIwIG1pbjog ZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50DQo+PiAgNTAgbWluOiBnZW5l cmFsIGRpc2N1c3Npb24gb3IgZW5kIGVhcmx5DQo+PiANCj4+IA0KPj4gV2UgaG9wZSB0byBzY2hl ZHVsZSB0aGUgbWVldGluZyBpdHNlbGYgdG9tb3Jyb3cgb3IgdGhlIG5leHQgZGF5LCBzbyBwbGVh c2UgcmVzcG9uZCBxdWlja2x5IHRvIHRoaXMgZW1haWwgaWYgcG9zc2libGUuDQo+PiANCj4+IFRo YW5rcywNCj4+IEtlbnQgYW5kIFRvbQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBPbiAyLzIvMTYs IDI6MDQgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExvdSBCZXJnZXIiIDxuZXRtb2QtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+PiANCj4+ PiANCj4+PiBJIHRob3VnaHQgaXQgd291bGQgYmUgd29ydGggc3VtbWFyaXppbmcgd2hhdCB3ZSdy ZSBsb29raW5nIGZvciBpbiBvdXINCj4+PiBkcmFmdCwgZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRl dmljZS1tb2RlbC0wMiAobm90ZSBuZXcgdmVyc2lvbiBpbiBjYXNlDQo+Pj4geW91IG1pc3NlZCBp dCkgd2l0aCByZXNwZWN0IHRvIHRoZSBkcmFmdC1saG90a2EtbmV0bW9kLXlzZGwgYW5kDQo+Pj4g ZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50IGRyYWZ0cy4gVGhpcyBpcyBq dXN0IG15IHZpZXcsIHNvDQo+Pj4gbXkgY28tYXV0aG9ycyBtYXkgd2lzaCB0byBjaGltZSBpbiBh bmQgY29ycmVjdCBtZS4NCj4+PiANCj4+PiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZy b20gdGhlIGF1dGhvcnMgb2YgWVNETCBhbmQNCj4+PiBzdHJ1Y3R1cmFsLW1vdW50LCBvciBhbnlv bmUgZWxzZSBmb3IgdGhhdCBtYXR0ZXIsIG9uIGhvdyB0aGV5IHNlZSB0bw0KPj4+IGJlc3QgbWVl dCB0aGVzZSBuZWVkcy4NCj4+PiANCj4+PiBIZXJlJ3Mgd2hhdCBJIHRoaW5rIG91ciBkcmFmdCBu ZWVkczoNCj4+PiANCj4+PiAxLiB0aGF0IHRoZXJlIGJlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dz IHRoZSBpbmNvcnBvcmF0aW9uIChvcg0KPj4+ICAnbW91bnRpbmcnKSBvZiB0aGUgZGF0YSBtb2Rl bCBkZWZpbmVkIGJ5IG9uZSB0b3AtbGV2ZWwgbW9kdWxlDQo+Pj4gIHdpdGhpbiBhbm90aGVyIG1v ZHVsZS4NCj4+PiANCj4+PiAgVGhlIGltcGxpY2F0aW9uIGhlcmUgaXMgdGhhdCB3aGVuIGluZm9y bWF0aW9uIGlzIGluc3RhbnRpYXRlZA0KPj4+ICBmb3IgdGhlIHBhcmVudCBtb2RlbCBpdCBpcyBh bHNvIGluc3RhbnRpYXRlZCBmb3IgdGhlDQo+Pj4gIGluY29ycG9yYXRlZC9tb3VudGVkIG1vZGVs LiBJbiBvdXIgY2FzZSB3ZSBleHBlY3QgdG8gZG8gdGhpcyBvbg0KPj4+ICBsaXN0IGVsZW1lbnQg Y3JlYXRpb24uIEJvdGggc29sdXRpb25zIGRyYWZ0cyBjb3ZlciB0aGUgcGF0aA0KPj4+ICBpbXBs aWNhdGlvbnMsIHNvIHRoZXNlIGFyZSBub3QgcmVwZWF0ZWQgaGVyZS4NCj4+PiANCj4+PiAyLiB0 aGF0IHRoaXMgbWVjaGFuaXNtIGFsbG93IGlkZW50aWZpY2F0aW9uIG9mIHNwZWNpZmljIG1vZHVs ZXMgdG8NCj4+PiAgYmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVm aW5pdGlvbiwgaS5lLiB0aGF0DQo+Pj4gIG5vIGFkZGl0aW9uYWwgbW9kdWxlIGlzIG5lZWRlZCB0 byBzdXBwb3J0IDEuIFRoaXMgZG9lc24ndA0KPj4+ICBwcmVjbHVkZSBkZWZpbml0aW9uIG9mIHN1 Y2ggYSBtb2R1bGUuDQo+Pj4gDQo+Pj4gMy4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBmb3Ig YSBzZXJ2ZXIgdG8gY29udHJvbCAoYW5kDQo+Pj4gIGlkZW50aWZ5KSB3aGljaCBtb2R1bGVzIGFy ZSBpbmNvcnBvcmF0ZWQvbW91bnRlZC4gKHNlZSBTZWN0aW9uDQo+Pj4gIDMgTE5FIGluIG91ciBk cmFmdCBmb3IgYW4gZW52aXNpb25lZCB1c2FnZS4pDQo+Pj4gDQo+Pj4gNC4gdGhhdCBhbGwgY2Fw YWJpbGl0aWVzIHRoYXQgZXhpc3Qgd2l0aCB0aGUgbW91bnRlZCBtb2R1bGUgYXJlDQo+Pj4gIGF2 YWlsYWJsZSBlLmcuIFJQQyBvcGVyYXRpb25zIGFuZCBub3RpZmljYXRpb25zLg0KPj4+IA0KPj4+ IDUuIHdoaWxlIG91ciBwcmltYXJ5IHJlcXVpcmVtZW50IGlzIGZvciAnbW91bnRpbmcnIG9mIHRv cCBsZXZlbA0KPj4+ICBtb2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNvIGJl IHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPj4+ICBkcml2ZW4uKQ0KPj4+IA0KPj4+IFdlIG1ha2Ug dXNlIG9mIHRoZSBhYm92ZSBpbiBzZWN0aW9ucyAzIGFuZCA0IG9mIHJ0Z3dnLWRldmljZS1tb2Rl bC4gIFdlDQo+Pj4gc2VlIGhhdmluZyBhIHNvbHV0aW9uIGFzIGNyaXRpY2FsIGZvciB0aGUgc2lt cGxpZmljYXRpb25zL2ZsZXhpYmlsaXR5DQo+Pj4gcmVwcmVzZW50ZWQgaW4gdGhlIC0wMiB2ZXJz aW9uIG9mIG91ciBkcmFmdCB2cyB0aGUgLTAzIHJldi4gIFdlIGRvbid0DQo+Pj4gc2VlIHdpdGhl ciBzb2x1dGlvbiBkcmFmdCBhcyBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBhbmQganVzdCBob3Bl IGZvciBhDQo+Pj4gc3RhbmRhcmQgc29sdXRpb24gYXMgc29vbiBhcyBwb3NzaWJsZS4gIChhIGRy YWZ0LWlldGYtbmV0bW9kIHNvbHV0aW9ucw0KPj4+IGRyYWZ0IG9uIHRoZSB0b3BpYyBieSBCQSB3 b3VsZCBiZSBmYW50YXN0aWMgZ2l2ZW4gdGhlIGltcGFjdCBvbiByb3V0aW5nDQo+Pj4gYXJlYSAt LSBldmVuIGlmIGl0IGhhZCB0byBkb2N1bWVudCB0d28gdmFyaWF0aW9ucyAvIGFsdGVybmF0aXZl IHNvbHV0aW9ucy4pDQo+Pj4gDQo+Pj4gQWdhaW4sIHRoaXMgaXMganVzdCBteSBvcGluaW9uIGFu ZCBteSBjb2F1dGhvcnMgb3Igb3RoZXJzIG9uIHRoZSBydGcNCj4+PiBhcmVhIHlhbmcgRFQgbWF5 IGNob29zZSB0byBjaGltZSBpbi4NCj4+PiANCj4+PiBMb3UNCj4+PiANCj4+PiANCj4+PiANCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGth LCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQo= From nobody Wed Feb 3 02:49:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF881A9040 for ; Wed, 3 Feb 2016 02:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 j0VHcoL5A-Q4 for ; Wed, 3 Feb 2016 02:49:50 -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 A59461A9038 for ; Wed, 3 Feb 2016 02:49:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A91938EE; Wed, 3 Feb 2016 11:49:48 +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 yguuxej2i1RD; Wed, 3 Feb 2016 11:49:48 +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, 3 Feb 2016 11:49:48 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED6B52002C; Wed, 3 Feb 2016 11:49:47 +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 HHHbL3hoUlM4; Wed, 3 Feb 2016 11:49:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A97FD20013; Wed, 3 Feb 2016 11:49:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 00CD239DDD66; Wed, 3 Feb 2016 11:49:46 +0100 (CET) Date: Wed, 3 Feb 2016 11:49:46 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20160203104946.GB19098@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group , lhotka@nic.cz References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B1D435.7030506@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 10:49:53 -0000 On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote: > module foomod { > > namespace"http://example.com/foomod"; > > prefix "foo"; > > container top { > leaf foo { > type uint8; > } > } > } > > Use "example-" in the module name, as mentioned > inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: > > Example modules are non-normative, and SHOULD be named with the > prefix "example-". > > Same remark for module barmod (and btw, pay attention to the "import > foomod") and module exmod I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs fixing to distinguish between examples that should be subject to validation and examples that are just there for documentation purposes and which are typically designed to be incomplete in order to aid the reader. /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 Feb 3 03:56:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD561B3489 for ; Wed, 3 Feb 2016 03:56: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 JWhyg_iH2Exa for ; Wed, 3 Feb 2016 03:56:19 -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 2E34D1B3487 for ; Wed, 3 Feb 2016 03:56:19 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id cw1so10562007lbb.1 for ; Wed, 03 Feb 2016 03:56: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=q/Vcx7vLc2dCOWbZrS3JQIWmMeL9Rv/4J3xRnC9r5wM=; b=eaO5Q46oN2pbpy7bhwHv/lhXTxEoMiygtuThYSNVIGFV5QGxUCR8c9tz/rmtbELrRE AvfRgDcaWQmOfjVyEgeSu/++lwnhKI/gCIFEdwkpPmClb87DWg0GB8hI6ecEIzMl4T8U NvXvIRDRHfUv+g0JL7s2BeBrwUCYfSvElxzdnQOz7qV5ZYVIBmbE7+5Xyj8E/qILwza2 f3Jd7ETY9RETyMHc7bJIVHfYg5MxMbvrhvdn4uoPYycJf8NAy9iIt9noInmdbuZTrNCx klaL99rUM5KZAWt13SGiRRK7brBcvDCVBJsEC0xqyJG75GuHhMsrtSABOXS1Wm2e5XWQ 2ljQ== 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=q/Vcx7vLc2dCOWbZrS3JQIWmMeL9Rv/4J3xRnC9r5wM=; b=UBNqC8mj8P57ZMqKwto8japCCzscLtTbAJK0LZ4LDOHZ2TmpJpLuxvKSIjkzYmtq8i iRkvnDMBJkekm0nUxjJJThHbLpQSUTlLs33Qt52x8CwFd1WzeX9EmcP5z3zyhQZcPm7r /sFH3hIxfukloXyxi2bFnQa0aEoBSoQqECj8QRhdIVFQilvcVgp5OJUCsRkU6xdvzuRQ j6umbB9mHpfvULDjvPqfPkgmG7XR9wRvKvyd8L1aT9k49mogD6RgnFhCYtcY7/x+E6J6 htdKXuh4WbLXstGomu9TmNIZj2G6ROH4FT4AmNFn/5JQ3n8H18gWCA+IbK0hJ6qOOIyM OlIA== X-Gm-Message-State: AG10YORGoBf2m1MlcW+Y/1CyVeLD6KAvicvL1lj2IqAnL5Ao6j8LMVX7fhImc7HnL7+m5uvomjLsPq1crUGWog== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr561592lbb.66.1454500577297; Wed, 03 Feb 2016 03:56:17 -0800 (PST) Received: by 10.112.200.167 with HTTP; Wed, 3 Feb 2016 03:56:17 -0800 (PST) In-Reply-To: References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> Date: Wed, 3 Feb 2016 03:56:17 -0800 Message-ID: From: Andy Bierman To: William Ivory Content-Type: multipart/alternative; boundary=089e01161bf43c765b052adc4e8a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Where can I insert new YANG substatements? 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, 03 Feb 2016 11:56:21 -0000 --089e01161bf43c765b052adc4e8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 1:55 AM, William Ivory wrote: > Hi Lada, > > I was hoping for more than 'I think' and ' Hmm. The rule is not clear. > In fact, one can argue that it is wrong:'. Is anyone willing / able to > give me a definitive answer? > > Thanks, > > William > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: 03 February 2016 09:19 > To: William Ivory > Cc: netmod@ietf.org > Subject: Re: [netmod] Where can I insert new YANG substatements? > > Hi William, > > > > On 03 Feb 2016, at 09:58, William Ivory wrote: > > > > Hi, > > > > My colleagues and I are looking for clarification of the last point in > Section 10 of YANG 1.0: > > > > =E2=80=98 In statements that have any data definition statements as > > substatements, those data definition substatements MUST NOT be > > reordered.=E2=80=99 > > This was already discussed: > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.o= rg_arch_msg_netmod_CiVOMEDXfbQKKbgTXTznZh2HQQw&d=3DCwIFaQ&c=3DIL_XqQWOjubgf= qINi2jTzg&r=3DGByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3DIVWnHPIm0qEHm= xsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=3DSqU7w-muS4t_zhH19_1iyPLVl3tD24OUgJijkp4N= X4E&e=3D > > My understanding was that the paragraph you cite would be modified in > 6020bis, but apparently it hasn't been so far. I don't see any reason for > insisting on the order of sibling data node definitions in configuration > and state data since in instance documents the order is arbitrary in both > XML and JSON encoding. > > I have also mentioned in the past that this MUST NOT needs to be changed or at least clarified. According to RFC 2119, "MUST NOT" is supposed to be used when harm to inter-operability needs to be prevented. There are only 2 corner-cases where YANG-stmt order matters - default-stmt for a leaf-list - auto-numbering for enum or bits There are already update rules to prevent these statements from being reordered, so this MUST NOT is not needed at all. > > > We understand that existing statements must not be reordered in a new > revision of a YANG module, but we=E2=80=99re not clear if new statements = may be > inserted between existing statements, or must always come at the =E2=80= =98end=E2=80=99 of a > list or container definition. A specific example we=E2=80=99re concerned= with is > where a grouping is used, and then later that grouping has an extra eleme= nt > added, but the new node could also be added directly. Eg: > > > > Container foo { > > Leaf A > > Uses grouping B; > > Leaf C > > Leaf D > > } > > > > Is it valid in a new revision of the module to do the following, or mus= t > the order be A, B, C, D, E? What if grouping B has gained a new statemen= t? > > > > Container foo { > > Leaf A > > Uses grouping B; > > Leaf C > > Leaf E < ---- ADDED > > Leaf D > > } > > I think this is allowed in any case. > > This is allowed. It is also allowed to move objects to/from submodules and there is no fixed order to submodules within a module. This is also allowed, which has the same affect: container bar { uses foo; /// <--- add leaf E after D, still reorders X leaf X{} } > Lada > > Andy > > > > Thanks, > > > > William > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_netmod&d=3DCwIFaQ&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvOv_A= lgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3DIVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-z= Lo&s=3D0jQV22VeCUg5PDxgGj0fih8or13yFSYEsMqK1ALagu8&e=3D > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01161bf43c765b052adc4e8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 3, 2016 at 1:55 AM, William Ivory <wivory@brocade.com= > wrote:
Hi Lada,

I was hoping for more than 'I think' and ' Hmm.=C2=A0 The rule = is not clear.=C2=A0 In fact, one can argue that it is wrong:'.=C2=A0 Is= anyone willing / able to give me a definitive answer?

Thanks,

William

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.c= z]
Sent: 03 February 2016 09:19
To: William Ivory <wivory@Brocade.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I insert new YANG substatements?

Hi William,


> On 03 Feb 2016, at 09:58, William Ivory <wivory@Brocade.com> wro= te:
>
> Hi,
>
> My colleagues and I are looking for clarification of the last point in= Section 10 of YANG 1.0:
>
> =E2=80=98=C2=A0 =C2=A0In statements that have any data definition stat= ements as
>=C2=A0 =C2=A0 substatements, those data definition substatements MUST N= OT be
>=C2=A0 =C2=A0 reordered.=E2=80=99

This was already discussed:

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.iet= f.org_arch_msg_netmod_CiVOMEDXfbQKKbgTXTznZh2HQQw&d=3DCwIFaQ&c=3DIL= _XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&am= p;m=3DIVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=3DSqU7w-muS4t_zhH19= _1iyPLVl3tD24OUgJijkp4NX4E&e=3D

My understanding was that the paragraph you cite would be modified in 6020b= is, but apparently it hasn't been so far. I don't see any reason fo= r insisting on the order of sibling data node definitions in configuration = and state data since in instance documents the order is arbitrary in both X= ML and JSON encoding.



I have also mentioned i= n the past that this MUST NOT needs to be changed
or at least cla= rified.

According to RFC 2119, "MUST NOT"= ; is supposed to be used when harm
to inter-operability needs to = be prevented. There are only 2 corner-cases where YANG-stmt order matters
=C2=A0- default-stmt for a leaf-list
=C2=A0- auto-number= ing for enum or bits

There are already update rule= s to prevent these statements from being reordered,
so this MUST = NOT is not needed at all.



>
> We understand that existing statements must not be reordered in a new = revision of a YANG module, but we=E2=80=99re not clear if new statements ma= y be inserted between existing statements, or must always come at the =E2= =80=98end=E2=80=99 of a list or container definition.=C2=A0 A specific exam= ple we=E2=80=99re concerned with is where a grouping is used, and then late= r that grouping has an extra element added, but the new node could also be = added directly.=C2=A0 Eg:
>
> Container foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Uses grouping B;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf D
> }
>
> Is it valid in a new revision of the module to do the following, or mu= st the order be A, B, C, D, E?=C2=A0 What if grouping B has gained a new st= atement?
>
> Container foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Uses grouping B;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf E < ---- ADDED
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf D
> }

I think this is allowed in any case.



This is allowed.
<= div>
It is also allowed to move objects to/from submodules an= d there is
no fixed order to submodules within a module.

This is also allowed, which has the same affect:

=C2=A0 =C2=A0container bar {
=C2=A0 =C2=A0 =C2=A0= uses foo; =C2=A0 /// <--- add leaf E after D, still reorders X
=C2=A0 =C2=A0 =C2=A0 leaf X{}
=C2=A0 =C2=A0}


=C2=A0
Lada



Andy

--089e01161bf43c765b052adc4e8a-- From nobody Wed Feb 3 03:59:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68E51B3487; Wed, 3 Feb 2016 03:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 a3mfgrnnX_cN; Wed, 3 Feb 2016 03:59:08 -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 9B7F61B3489; Wed, 3 Feb 2016 03:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6012; q=dns/txt; s=iport; t=1454500748; x=1455710348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NTJWzrGEZbytEWLaEZlVH3PWid/OUOLAZwPOzFMPJIs=; b=b9lungc+wTOLsub8k4U7x70EPMiHqfRie3JGF+ZuOy0SybVPthsSw38w 9wlNSkLEaH9m0cubms057lIxRbupqMEFnN0RA9u7x6oF8ZeK/SaaebA1d FT0leNuZMdu6rGuoEDbyY5EHlcdcnAE3RKlLQilSOGpV6l/tk1AWqXluR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAgAH67FW/4MNJK1UCoM6Um0GhCmEL?= =?us-ascii?q?LE+AQ2BZBcKhSJKAhyBJTgUAQEBAQEBAYEKhEEBAQEDAQEBASAROgsQAgEIGAI?= =?us-ascii?q?CJgICAiULFRACBAENBRuHeAgOsEaPDAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe?= =?us-ascii?q?4lOhAIGCwEGgxiBOgWWcQGNTIFbhEKIVI4/AR4BAUKDZGqIOzR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,390,1449532800"; d="scan'208";a="234356053" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 11:59:07 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u13Bx7No010810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 11:59:07 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, 3 Feb 2016 06:59:06 -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, 3 Feb 2016 06:59:06 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , Kent Watsen Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgADo0ACAAAttAA== Date: Wed, 3 Feb 2016 11:59:06 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> 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.196] Content-Type: text/plain; charset="utf-8" Content-ID: <53F941B51F2FD1478809C6F9DDB91E47@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , netmod WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 11:59:10 -0000 DQoNCk9uIDIvMy8xNiwgMToxOCBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+ IHdyb3RlOg0KDQo+DQo+PiBPbiAwMyBGZWIgMjAxNiwgYXQgMDM6MjQsIEtlbnQgV2F0c2VuIDxr d2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+IA0KPj4gDQo+PiBbQ2hhaXIgaGF0IG9uXQ0K Pj4gDQo+PiBHaXZlbiB0aGUgbnVtYmVyIG9mIGNvbXBldGluZy9jb21wbGVtZW50aW5nIGRyYWZ0 cyBpbnZvbHZlZCwgYW5kIHRoZQ0KPj5nZW5lcmFsIGxhY2sgb2YgZGlzY3Vzc2lvbiBvbiBhbnkg b2YgdGhlbSwgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZw0KPj5taWdodCBiZSBhbiBleHBlZGll bnQgd2F5IHRvIHByb2NlZWQuICBJbiBmYWlybmVzcywgd2Uga25vdyB0aGF0IHRoZXJlDQo+Pmhh cyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiwgYnV0IGl0IGhhc27igJl0IGJlZW4gcGlja2VkIHVwIHll dCBpbiBhIGJpZyB3YXksDQo+PmFuZCBub3cgTG91IGhhcyBhbiB1cGRhdGVkIGRyYWZ0Lg0KPj4g DQo+PiBUaGUgY2hhaXJzIGRpc2N1c3NlZCBtYXliZSBzY2hlZHVsaW5nIG9uZSBmb3IgYSBjb3Vw bGUgd2Vla3MgZnJvbSBub3csDQo+PnBlcmhhcHMgVGh1cnNkYXkgRmViIDE4IHN0YXJ0aW5nIGF0 IDEwYW0gRVNUPyAgIEknbSB0aGlua2luZw0KPg0KPlRodXJzZGF5IGF0IHRoaXMgdGltZSBkb2Vz bid0IHN1aXQgbWUgdmVyeSB3ZWxsLCBNb25kYXkgdGlsbCBXZWRuZXNkYXkgb2YNCj50aGF0IHdl ZWsgYXJlIE9LLg0KDQpJ4oCZbSBvdXQgdGhlIGVudGlyZSB3ZWVrIG9mIEZlYiAxNHRoLg0KDQpU aGFua3MsDQpBY2VlIA0KDQoNCj4NCj5MYWRhDQo+DQo+PiAgYWJvdXQgdGhpcyBzbG90IG9ubHkg c2luY2UgaXQgd29ya2VkIGZvciB1cyBmb3IgcHJldmlvdXNseS4gIElzIHRoaXMgYQ0KPj5nb29k IHRpbWUgc2xvdD8gIEkgYXNzdW1lIHRvIHNjaGVkdWxlIGZvciAyIGhvdXJzLCB3aXRoIGEgcGxh biB0byBlbmQNCj4+ZWFybHkgaWYgbmVlZGVkIC0gbWFrZXMgc2Vuc2U/ICAgICBXZSBhbHNvIG5l ZWQgdG8gcHV0IHRvZ2V0aGVyIGEgcHJvcGVyDQo+PmFnZW5kYSwgcGVyaGFwcyB0aGUgZm9sbG93 aW5nPw0KPj4gDQo+PiAgMTAgbWluOiBSVEcgRFQgWUFORyBBcmNoIHRlYW0gdXNlLWNhc2Ugc3Vt bWFyeQ0KPj4gIDIwIG1pbjogZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbA0KPj4g IDIwIG1pbjogZHJhZnQtbGhvdGthLW5ldG1vZC15c2RsDQo+PiAgMjAgbWluOiBkcmFmdC1iam9y a2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQNCj4+ICA1MCBtaW46IGdlbmVyYWwgZGlzY3Vz c2lvbiBvciBlbmQgZWFybHkNCj4+IA0KPj4gDQo+PiBXZSBob3BlIHRvIHNjaGVkdWxlIHRoZSBt ZWV0aW5nIGl0c2VsZiB0b21vcnJvdyBvciB0aGUgbmV4dCBkYXksIHNvDQo+PnBsZWFzZSByZXNw b25kIHF1aWNrbHkgdG8gdGhpcyBlbWFpbCBpZiBwb3NzaWJsZS4NCj4+IA0KPj4gVGhhbmtzLA0K Pj4gS2VudCBhbmQgVG9tDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIDIvMi8xNiwgMjowNCBQ TSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91IEJlcmdlciINCj4+PG5ldG1vZC1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+IA0KPj4+IA0K Pj4+IEkgdGhvdWdodCBpdCB3b3VsZCBiZSB3b3J0aCBzdW1tYXJpemluZyB3aGF0IHdlJ3JlIGxv b2tpbmcgZm9yIGluIG91cg0KPj4+IGRyYWZ0LCBkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNl LW1vZGVsLTAyIChub3RlIG5ldyB2ZXJzaW9uIGluIGNhc2UNCj4+PiB5b3UgbWlzc2VkIGl0KSB3 aXRoIHJlc3BlY3QgdG8gdGhlIGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbCBhbmQNCj4+PiBkcmFm dC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQgZHJhZnRzLiBUaGlzIGlzIGp1c3Qg bXkgdmlldywNCj4+PnNvDQo+Pj4gbXkgY28tYXV0aG9ycyBtYXkgd2lzaCB0byBjaGltZSBpbiBh bmQgY29ycmVjdCBtZS4NCj4+PiANCj4+PiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZy b20gdGhlIGF1dGhvcnMgb2YgWVNETCBhbmQNCj4+PiBzdHJ1Y3R1cmFsLW1vdW50LCBvciBhbnlv bmUgZWxzZSBmb3IgdGhhdCBtYXR0ZXIsIG9uIGhvdyB0aGV5IHNlZSB0bw0KPj4+IGJlc3QgbWVl dCB0aGVzZSBuZWVkcy4NCj4+PiANCj4+PiBIZXJlJ3Mgd2hhdCBJIHRoaW5rIG91ciBkcmFmdCBu ZWVkczoNCj4+PiANCj4+PiAxLiB0aGF0IHRoZXJlIGJlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dz IHRoZSBpbmNvcnBvcmF0aW9uIChvcg0KPj4+ICAnbW91bnRpbmcnKSBvZiB0aGUgZGF0YSBtb2Rl bCBkZWZpbmVkIGJ5IG9uZSB0b3AtbGV2ZWwgbW9kdWxlDQo+Pj4gIHdpdGhpbiBhbm90aGVyIG1v ZHVsZS4NCj4+PiANCj4+PiAgVGhlIGltcGxpY2F0aW9uIGhlcmUgaXMgdGhhdCB3aGVuIGluZm9y bWF0aW9uIGlzIGluc3RhbnRpYXRlZA0KPj4+ICBmb3IgdGhlIHBhcmVudCBtb2RlbCBpdCBpcyBh bHNvIGluc3RhbnRpYXRlZCBmb3IgdGhlDQo+Pj4gIGluY29ycG9yYXRlZC9tb3VudGVkIG1vZGVs LiBJbiBvdXIgY2FzZSB3ZSBleHBlY3QgdG8gZG8gdGhpcyBvbg0KPj4+ICBsaXN0IGVsZW1lbnQg Y3JlYXRpb24uIEJvdGggc29sdXRpb25zIGRyYWZ0cyBjb3ZlciB0aGUgcGF0aA0KPj4+ICBpbXBs aWNhdGlvbnMsIHNvIHRoZXNlIGFyZSBub3QgcmVwZWF0ZWQgaGVyZS4NCj4+PiANCj4+PiAyLiB0 aGF0IHRoaXMgbWVjaGFuaXNtIGFsbG93IGlkZW50aWZpY2F0aW9uIG9mIHNwZWNpZmljIG1vZHVs ZXMgdG8NCj4+PiAgYmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVm aW5pdGlvbiwgaS5lLiB0aGF0DQo+Pj4gIG5vIGFkZGl0aW9uYWwgbW9kdWxlIGlzIG5lZWRlZCB0 byBzdXBwb3J0IDEuIFRoaXMgZG9lc24ndA0KPj4+ICBwcmVjbHVkZSBkZWZpbml0aW9uIG9mIHN1 Y2ggYSBtb2R1bGUuDQo+Pj4gDQo+Pj4gMy4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBmb3Ig YSBzZXJ2ZXIgdG8gY29udHJvbCAoYW5kDQo+Pj4gIGlkZW50aWZ5KSB3aGljaCBtb2R1bGVzIGFy ZSBpbmNvcnBvcmF0ZWQvbW91bnRlZC4gKHNlZSBTZWN0aW9uDQo+Pj4gIDMgTE5FIGluIG91ciBk cmFmdCBmb3IgYW4gZW52aXNpb25lZCB1c2FnZS4pDQo+Pj4gDQo+Pj4gNC4gdGhhdCBhbGwgY2Fw YWJpbGl0aWVzIHRoYXQgZXhpc3Qgd2l0aCB0aGUgbW91bnRlZCBtb2R1bGUgYXJlDQo+Pj4gIGF2 YWlsYWJsZSBlLmcuIFJQQyBvcGVyYXRpb25zIGFuZCBub3RpZmljYXRpb25zLg0KPj4+IA0KPj4+ IDUuIHdoaWxlIG91ciBwcmltYXJ5IHJlcXVpcmVtZW50IGlzIGZvciAnbW91bnRpbmcnIG9mIHRv cCBsZXZlbA0KPj4+ICBtb2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNvIGJl IHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPj4+ICBkcml2ZW4uKQ0KPj4+IA0KPj4+IFdlIG1ha2Ug dXNlIG9mIHRoZSBhYm92ZSBpbiBzZWN0aW9ucyAzIGFuZCA0IG9mIHJ0Z3dnLWRldmljZS1tb2Rl bC4gIFdlDQo+Pj4gc2VlIGhhdmluZyBhIHNvbHV0aW9uIGFzIGNyaXRpY2FsIGZvciB0aGUgc2lt cGxpZmljYXRpb25zL2ZsZXhpYmlsaXR5DQo+Pj4gcmVwcmVzZW50ZWQgaW4gdGhlIC0wMiB2ZXJz aW9uIG9mIG91ciBkcmFmdCB2cyB0aGUgLTAzIHJldi4gIFdlIGRvbid0DQo+Pj4gc2VlIHdpdGhl ciBzb2x1dGlvbiBkcmFmdCBhcyBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBhbmQganVzdCBob3Bl IGZvcg0KPj4+YQ0KPj4+IHN0YW5kYXJkIHNvbHV0aW9uIGFzIHNvb24gYXMgcG9zc2libGUuICAo YSBkcmFmdC1pZXRmLW5ldG1vZCBzb2x1dGlvbnMNCj4+PiBkcmFmdCBvbiB0aGUgdG9waWMgYnkg QkEgd291bGQgYmUgZmFudGFzdGljIGdpdmVuIHRoZSBpbXBhY3Qgb24gcm91dGluZw0KPj4+IGFy ZWEgLS0gZXZlbiBpZiBpdCBoYWQgdG8gZG9jdW1lbnQgdHdvIHZhcmlhdGlvbnMgLyBhbHRlcm5h dGl2ZQ0KPj4+c29sdXRpb25zLikNCj4+PiANCj4+PiBBZ2FpbiwgdGhpcyBpcyBqdXN0IG15IG9w aW5pb24gYW5kIG15IGNvYXV0aG9ycyBvciBvdGhlcnMgb24gdGhlIHJ0Zw0KPj4+IGFyZWEgeWFu ZyBEVCBtYXkgY2hvb3NlIHRvIGNoaW1lIGluLg0KPj4+IA0KPj4+IExvdQ0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+LS0NCj5MYWRpc2xh diBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMNCj4NCj4NCj4NCj4N Cg0K From nobody Wed Feb 3 04:06:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB211B2FFA for ; Wed, 3 Feb 2016 04:06:31 -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 P0Z-tHdhM3iQ for ; Wed, 3 Feb 2016 04:06:29 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E488F1B2F07 for ; Wed, 3 Feb 2016 04:06:28 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4261E1CC006C; Wed, 3 Feb 2016 13:06:28 +0100 (CET) From: Ladislav Lhotka To: Benoit Claise , NETMOD Working Group In-Reply-To: <56B1D435.7030506@cisco.com> References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 03 Feb 2016 13:06:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 12:06:31 -0000 Hi Benoit, thank you for the review, please see my responses inline. Benoit Claise writes: > Dear all, > > I understood from the chairs that draft-ietf-netmod-yang-json is now > ready and that the write-up will be completed end of this week. > In order to speed up the publication, here is my AD review. > > - Editorial: > > This document defines encoding rules for representing configuration, > state data, RPC operation or action input and output parameters, and > notifications defined using YANG as JavaScript Object Notation (JSON) > text. > > "RPC operation or action input and output parameters" > ", or ... and, " it's always complicated. > Why not only "RPC operation or action"? Because we aren't encoding operations, just their parameters. > > At the very minimum "input and output parameters" to "input/output > parameters" OK, so how about using just "parameters of RPC operations or actions" in the abstract, and "input/output parameters of RPC operations or actions" elsewhere? > > Same remark for section 1.1 > > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > ] defines only XML encoding for data > instances, i.e., contents of configuration datastores, state data, > RPC operation or action input and output parameters, and event > notifications. > > If you want to extend, also fine. > > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > ] defines only XML encoding for data > instances, i.e., contents of configuration datastores, state data, > RPC operation input and output parameters, action input and output > parameters, and event notifications. > > Btw, "RPC", "action" and "input and output parameters" are only > mentioned in the abstract and this introduction, not anymore in the body > of the document. There is nothing specific to these worth noting? Not > even an example? This document is about encoding YANG data nodes, and the rules are the same for any data tree. Encoding of operations or notifications is a subject for a protocol spec, and RESTCONF does provide examples. > > - Editorial > > In the introduction, you might want to complete the last sentence > > NEW: > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > ] defines only XML encoding for data > instances, i.e., contents of configuration datastores, state data, > RPC operation or action input and output parameters, and event > notifications. The aim of this document is to define rules for > encoding the same data as JavaScript Object Notation (JSON) > text [RFC7159 ]. > > NEW: > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > ] defines only XML encoding for data > instances, i.e., contents of configuration datastores, state data, > RPC operation or action input and output parameters, and event > notifications. The aim of this document is to define rules for > encoding the same data as JavaScript Object Notation (JSON) > text [RFC7159 ], most precisely the Internet JSON (I-JSON) restricted > profile [RFC7493 ]. I would say that for the introduction the more general term (JSON) is appropriate, the reasons for sticking to I-JSON are explained later. In fact, this document specifies a profile that's even more restricted than I-JSON. > > > - > section 2: > > The following terms are defined in [I-D.ietf-netmod-rfc6020bis > ]: > ... > > o identity, > > There is no identity definition in the RFC 6020 terminology section. Maybe it is an omission in 6020bis? > Are you referring to the identity statement, > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 > ? No, I am referring to a "globally unique, abstract, and untyped identity" (sec. 7.18 in 6020bis) that's defined by an "identity" statement. > > - Editorial. > > OLD: > An object member name MUST be in one of the following forms: > NEW: > A JSON object member name MUST be encoded in one of the following forms: > OK. > > - > module foomod { > > namespace"http://example.com/foomod"; > > prefix "foo"; > > container top { > leaf foo { > type uint8; > } > } > } > > Use "example-" in the module name, as mentioned inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: > > Example modules are non-normative, and SHOULD be named with the > prefix "example-". > > Same remark for module barmod (and btw, pay attention to the "import > foomod") and module exmod I agree with Juergen that 6087bis should distinguish between complete example modules and short module snippets that are used for explaining a certain YANG language or encoding issue. If you look at this particular example, then changing the JSON document on p. 6 to { "example-foomod:top": { "foo": 54, "example-barmod:bar": true } } would IMO just add noise and blur the message the example is supposed to convey. > > > - Editorial (Appendix A): > > OLD: > The "if-mib" feature defined in the "ietf- > interfaces" module is considered to be active. > > NEW: > The "if-mib" feature defined in the "ietf- > interfaces" module is supported. Yes, right. Thanks, Lada > > Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 3 04:58:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6331A8A20 for ; Wed, 3 Feb 2016 04:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 zyg3FXyRbXD0 for ; Wed, 3 Feb 2016 04:58:05 -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 DDCE21A8A1C for ; Wed, 3 Feb 2016 04:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5906; q=dns/txt; s=iport; t=1454504285; x=1455713885; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TTOXYxjR1RaWxw2e965PHStx7CzNdBYFF7eA5uOh81E=; b=S5mCFLTWvTxUzWyRKIvg7Pj8tRE+1His/eW2KKupt6XmNLg+Sk8Mj9QK H1vT4kXYfF6qC4HktZyYv9LwZhr+diiUBpHntJ125WX3YTMAG3cX9AlHs Hj+uf3+eGVPucyaaiBfy4uiavw3sdzl6w0AYGbXDF6eT0oNxfjlUohpKc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAZ+bFW/xbLJq1VCYQMZwaIW7E+A?= =?us-ascii?q?Q2BZCOFagKBehQBAQEBAQEBgQqEQgEBAwE4QBELIRYPCQMCAQIBRQYBDAYCAQG?= =?us-ascii?q?IDwgJBb9eAQEBAQEBAQEBAQEBAQEBAQEBAQEWhhKEN4QJhGMBBIVNh1iJTIVJg?= =?us-ascii?q?myCY4I1gVtKg3iDA4VRhxCHMB4BAUKDZTsuAYlqAQEB?= X-IronPort-AV: E=Sophos;i="5.22,390,1449532800"; d="scan'208";a="649019909" 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; 03 Feb 2016 12:58: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 u13Cw0rT010496; Wed, 3 Feb 2016 12:58:00 GMT To: Ladislav Lhotka , NETMOD Working Group References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> From: Benoit Claise Message-ID: <56B1F958.5030206@cisco.com> Date: Wed, 3 Feb 2016 13:58:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 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] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 12:58:07 -0000 Hi Lada, Thanks for the quick reply. > Hi Benoit, > > thank you for the review, please see my responses inline. > > Benoit Claise writes: > >> Dear all, >> >> I understood from the chairs that draft-ietf-netmod-yang-json is now >> ready and that the write-up will be completed end of this week. >> In order to speed up the publication, here is my AD review. >> >> - Editorial: >> >> This document defines encoding rules for representing configuration, >> state data, RPC operation or action input and output parameters, and >> notifications defined using YANG as JavaScript Object Notation (JSON) >> text. >> >> "RPC operation or action input and output parameters" >> ", or ... and, " it's always complicated. >> Why not only "RPC operation or action"? > Because we aren't encoding operations, just their parameters. Good point. > >> At the very minimum "input and output parameters" to "input/output >> parameters" > OK, so how about using just "parameters of RPC operations or actions" in > the abstract, and "input/output parameters of RPC operations or actions" > elsewhere? Sure. > >> Same remark for section 1.1 >> >> The specification of YANG 1.1 data modelling language >> [I-D.ietf-netmod-rfc6020bis >> ] defines only XML encoding for data >> instances, i.e., contents of configuration datastores, state data, >> RPC operation or action input and output parameters, and event >> notifications. >> >> If you want to extend, also fine. >> >> The specification of YANG 1.1 data modelling language >> [I-D.ietf-netmod-rfc6020bis >> ] defines only XML encoding for data >> instances, i.e., contents of configuration datastores, state data, >> RPC operation input and output parameters, action input and output >> parameters, and event notifications. >> >> Btw, "RPC", "action" and "input and output parameters" are only >> mentioned in the abstract and this introduction, not anymore in the body >> of the document. There is nothing specific to these worth noting? Not >> even an example? > This document is about encoding YANG data nodes, and the rules are the > same for any data tree. Not worth mentioning something such as " There is nothing specific to input and output parameters compared to any other data tree..."? > Encoding of operations or notifications is a > subject for a protocol spec, and RESTCONF does provide examples. > >> - Editorial >> >> In the introduction, you might want to complete the last sentence >> >> NEW: >> The specification of YANG 1.1 data modelling language >> [I-D.ietf-netmod-rfc6020bis >> ] defines only XML encoding for data >> instances, i.e., contents of configuration datastores, state data, >> RPC operation or action input and output parameters, and event >> notifications. The aim of this document is to define rules for >> encoding the same data as JavaScript Object Notation (JSON) >> text [RFC7159 ]. >> >> NEW: >> The specification of YANG 1.1 data modelling language >> [I-D.ietf-netmod-rfc6020bis >> ] defines only XML encoding for data >> instances, i.e., contents of configuration datastores, state data, >> RPC operation or action input and output parameters, and event >> notifications. The aim of this document is to define rules for >> encoding the same data as JavaScript Object Notation (JSON) >> text [RFC7159 ], most precisely the Internet JSON (I-JSON) restricted >> profile [RFC7493 ]. > I would say that for the introduction the more general term (JSON) is > appropriate, the reasons for sticking to I-JSON are explained later. In > fact, this document specifies a profile that's even more restricted than > I-JSON. Fair enough. > >> >> - >> section 2: >> >> The following terms are defined in [I-D.ietf-netmod-rfc6020bis >> ]: >> ... >> >> o identity, >> >> There is no identity definition in the RFC 6020 terminology section. > Maybe it is an omission in 6020bis? Ok, let's fix it in 6020bis then. > >> - >> module foomod { >> >> namespace"http://example.com/foomod"; >> >> prefix "foo"; >> >> container top { >> leaf foo { >> type uint8; >> } >> } >> } >> >> Use "example-" in the module name, as mentioned inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: >> >> Example modules are non-normative, and SHOULD be named with the >> prefix "example-". >> >> Same remark for module barmod (and btw, pay attention to the "import >> foomod") and module exmod > I agree with Juergen that 6087bis should distinguish between complete > example modules and short module snippets that are used for explaining a > certain YANG language or encoding issue. If you look at this particular > example, then changing the JSON document on p. 6 to > > { > "example-foomod:top": { > "foo": 54, > "example-barmod:bar": true > } > } > > would IMO just add noise and blur the message the example is supposed to > convey. So please fix the text in 6087bis. Until it's done, I'll stick to the current rule. Regards, Benoit From nobody Wed Feb 3 05:28:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF671A8AEB for ; Wed, 3 Feb 2016 05:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 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, RP_MATCHES_RCVD=-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 bvm4BjbFwMck for ; Wed, 3 Feb 2016 05:28:25 -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 6E6471A8AE7 for ; Wed, 3 Feb 2016 05:28:25 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48] (unknown [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48]) by mail.nic.cz (Postfix) with ESMTPSA id 81584180878; Wed, 3 Feb 2016 14:28:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454506103; bh=wUJGDwCuoi7KWGuXbaNpAxn04IJvvGvtCD0b7uItbgw=; h=From:Date:To; b=j2Zv5a36DaXQ/9YDXLtzi24Wkc0MySFV+IRm8JXamM7SQluS2vrZc+NTti8Yl3Dro rHXBWthWD/TvWlEX7PR7cwpn+sbEWF6yM6mPMyjTsn1QPQxpVrpWG5RAPS2HzEgL5b +lR90rbPUwWKuom2g6BaeoAxzlDVmWxmyZndo7ms= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56B1F958.5030206@cisco.com> Date: Wed, 3 Feb 2016 14:28:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <56B1F958.5030206@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 Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 13:28:28 -0000 > On 03 Feb 2016, at 13:58, Benoit Claise wrote: >=20 > Hi Lada, >=20 > Thanks for the quick reply. >> Hi Benoit, >>=20 >> thank you for the review, please see my responses inline. >>=20 >> Benoit Claise writes: >>=20 >>> Dear all, >>>=20 >>> I understood from the chairs that draft-ietf-netmod-yang-json is now >>> ready and that the write-up will be completed end of this week. >>> In order to speed up the publication, here is my AD review. >>>=20 >>> - Editorial: >>>=20 >>> This document defines encoding rules for representing = configuration, >>> state data, RPC operation or action input and output parameters, = and >>> notifications defined using YANG as JavaScript Object Notation = (JSON) >>> text. >>>=20 >>> "RPC operation or action input and output parameters" >>> ", or ... and, " it's always complicated. >>> Why not only "RPC operation or action"? >> Because we aren't encoding operations, just their parameters. > Good point. >>=20 >>> At the very minimum "input and output parameters" to "input/output >>> parameters" >> OK, so how about using just "parameters of RPC operations or actions" = in >> the abstract, and "input/output parameters of RPC operations or = actions" >> elsewhere? > Sure. Done. >>=20 >>> Same remark for section 1.1 >>>=20 >>> The specification of YANG 1.1 data modelling language >>> [I-D.ietf-netmod-rfc6020bis >>> = ] defines only XML encoding for data >>> instances, i.e., contents of configuration datastores, state = data, >>> RPC operation or action input and output parameters, and event >>> notifications. >>>=20 >>> If you want to extend, also fine. >>>=20 >>> The specification of YANG 1.1 data modelling language >>> [I-D.ietf-netmod-rfc6020bis >>> = ] defines only XML encoding for data >>> instances, i.e., contents of configuration datastores, state = data, >>> RPC operation input and output parameters, action input and = output >>> parameters, and event notifications. >>>=20 >>> Btw, "RPC", "action" and "input and output parameters" are only >>> mentioned in the abstract and this introduction, not anymore in the = body >>> of the document. There is nothing specific to these worth noting? = Not >>> even an example? >> This document is about encoding YANG data nodes, and the rules are = the >> same for any data tree. > Not worth mentioning something such as > " There is nothing specific to input and output parameters compared to = any other data tree..."? OK, I'll add such a note. ... >> I agree with Juergen that 6087bis should distinguish between complete >> example modules and short module snippets that are used for = explaining a >> certain YANG language or encoding issue. If you look at this = particular >> example, then changing the JSON document on p. 6 to >>=20 >> { >> "example-foomod:top": { >> "foo": 54, >> "example-barmod:bar": true >> } >> } >>=20 >> would IMO just add noise and blur the message the example is supposed = to >> convey. > So please fix the text in 6087bis. > Until it's done, I'll stick to the current rule. I don't want to be excessively bureaucratic but, strictly speaking, = current rules are those of RFC 6087 that contains no such requirement, = so we should be OK for now. And I think there is enough consensus to = change the corresponding 6087bis text - after all, 6020bis also has = example modules whose names don't start with "example-". Thanks, Lada >=20 > Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 3 05:37:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CC31AC3E2 for ; Wed, 3 Feb 2016 05:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 2vQld9ajWdOM for ; Wed, 3 Feb 2016 05:37:16 -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 0238E1A8A1D for ; Wed, 3 Feb 2016 05:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1103; q=dns/txt; s=iport; t=1454506636; x=1455716236; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=klRnwtuYjgz2HNF+DARDQi8E9CtOx+WgL5PsAgVcKRg=; b=UBY4EzRr1huNsJf0QPnF9+MnjnRSRMLWOarbv5PI/fgeQnM6UPNkjfOH 1CMQiGWIhE4CB0B9onfQMgcv3Gu90Zuo9oC4qzhM3KBCwTmCsUJaj692C Wl+/iitEFmcOVTd12A17ztAn6dTPfi/dRCZi25lnGP9edOmdEPKtnGp8P k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADdAbJW/xbLJq1ejVSzMYYNAoISA?= =?us-ascii?q?QEBAQEBgQuEQgEBBDIBBUABEAshFg8JAwIBAgFFBg0IAQGIF79yAQEBAQEBAQE?= =?us-ascii?q?CAQEBAQEBARmGEoQ3iGwBBJZxjU2BW4RCgwOFUY5AYoNlO4oZAQEB?= X-IronPort-AV: E=Sophos;i="5.22,390,1449532800"; d="scan'208";a="624001059" 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; 03 Feb 2016 13:37:12 +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 u13DbC7h028986; Wed, 3 Feb 2016 13:37:12 GMT To: Ladislav Lhotka References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <56B1F958.5030206@cisco.com> <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> From: Benoit Claise Message-ID: <56B20288.6070204@cisco.com> Date: Wed, 3 Feb 2016 14:37:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 13:37:20 -0000 Hi Lada, > >>> I agree with Juergen that 6087bis should distinguish between complete >>> example modules and short module snippets that are used for explaining a >>> certain YANG language or encoding issue. If you look at this particular >>> example, then changing the JSON document on p. 6 to >>> >>> { >>> "example-foomod:top": { >>> "foo": 54, >>> "example-barmod:bar": true >>> } >>> } >>> >>> would IMO just add noise and blur the message the example is supposed to >>> convey. >> So please fix the text in 6087bis. >> Until it's done, I'll stick to the current rule. > I don't want to be excessively bureaucratic but, strictly speaking, current rules are those of RFC 6087 that contains no such requirement, so we should be OK for now. And I think there is enough consensus so Jrgen and you? > to change the corresponding 6087bis text - after all, 6020bis also has example modules whose names don't start with "example-". I'll still have to review it and that will be one of my comments, for sure. Consistency first. Regards ,Benoit From nobody Wed Feb 3 05:47:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B6D1AC3D6 for ; Wed, 3 Feb 2016 05:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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, RP_MATCHES_RCVD=-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 ZjJD-BkUfsfz for ; Wed, 3 Feb 2016 05:47:24 -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 E39AB1AC419 for ; Wed, 3 Feb 2016 05:47:23 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48] (unknown [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48]) by mail.nic.cz (Postfix) with ESMTPSA id 687C3181A48; Wed, 3 Feb 2016 14:47:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454507242; bh=47ufn+1Zlpluxxvf5HFrS2m0PHA5vqEPDAusthAFe+E=; h=From:Date:To; b=O289NwVdpQXLSWl2s4MF82zm3SBUlvIINaACQwE1o6KR2KAjAKThV63NgxjH1MyOb RFS5n8X4nR71T5MyQ1buwvXlS2gHBH+RwvM/yVenbG/giZnh3VZdrOawxGw1BPSRKQ xswrdncIbwYp7jlv6xzfPQyh7OvuK+yHzkkEzI+E= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56B20288.6070204@cisco.com> Date: Wed, 3 Feb 2016 14:47:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <56B1F958.5030206@cisco.com> <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> <56B20288.6070204@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 Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 13:47:24 -0000 > On 03 Feb 2016, at 14:37, Benoit Claise wrote: >=20 > Hi Lada, >>=20 >>>> I agree with Juergen that 6087bis should distinguish between = complete >>>> example modules and short module snippets that are used for = explaining a >>>> certain YANG language or encoding issue. If you look at this = particular >>>> example, then changing the JSON document on p. 6 to >>>>=20 >>>> { >>>> "example-foomod:top": { >>>> "foo": 54, >>>> "example-barmod:bar": true >>>> } >>>> } >>>>=20 >>>> would IMO just add noise and blur the message the example is = supposed to >>>> convey. >>> So please fix the text in 6087bis. >>> Until it's done, I'll stick to the current rule. >> I don't want to be excessively bureaucratic but, strictly speaking, = current rules are those of RFC 6087 that contains no such requirement, = so we should be OK for now. And I think there is enough consensus > so J=FCrgen and you? I guess Martin as well, given that 6020bis doesn't follow that rule. Lada >> to change the corresponding 6087bis text - after all, 6020bis also = has example modules whose names don't start with "example-". > I'll still have to review it and that will be one of my comments, for = sure. Consistency first. >=20 > Regards ,Benoit >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 3 05:51:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192D1AC425; Wed, 3 Feb 2016 05:51:19 -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 pqumecQJthEk; Wed, 3 Feb 2016 05:51:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771091AC3EC; Wed, 3 Feb 2016 05:51:14 -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.396.15; Wed, 3 Feb 2016 13:50:55 +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.0396.020; Wed, 3 Feb 2016 13:50:55 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Ladislav Lhotka Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgACU/gCAAF9CAP//y2sA Date: Wed, 3 Feb 2016 13:50:55 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:b/O/o0tyP753A+Kuvj9hREC4mv1JxhWfM5AjINxAv4XT55LFxaLJ7PVMx8mQtT3v+xpJmSWiHs7Gqph7VtRGHo9AVoX9T5C9lLOvKGIj+WbLN0s0FI0cnYMikwssX3PK6g2aOwsK2QHGCZ2ZclM0dg==; 24:LTjbysNG8xybTWygIE7H58dROjAqx6yLJ25q5vBWlriZAuJbkwvvbbwkdDxB6+qpw8tXVD9NmYj5pJr+zhyAf33osPMzgq9NOKIAdhtrTlQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: db677c5e-e0ad-4d47-d109-08d32ca1099c 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)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(164054003)(377454003)(24454002)(189998001)(1220700001)(19580395003)(40100003)(33656002)(586003)(83716003)(5001960100002)(102836003)(5008740100001)(11100500001)(6116002)(15395725005)(4326007)(1096002)(5002640100001)(19580405001)(92566002)(36756003)(5004730100002)(4001350100001)(76176999)(93886004)(54356999)(15975445007)(86362001)(50986999)(77096005)(10400500002)(575784001)(2950100001)(2906002)(5001770100001)(2900100001)(66066001)(87936001)(122556002)(1720100001)(83506001)(106116001)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 03 Feb 2016 13:50:55.0750 (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: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , netmod WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 13:51:19 -0000 DQpObyBwcm9ibGVtLCBJIGp1c3QgY3JlYXRlZCBhbm90aGVyIHBvbGwgZm9yIHRoZSBmb2xsb3dp bmcgd2VlazoNCg0KCWh0dHA6Ly9kb29kbGUuY29tL3BvbGwvYnl1Z3A0dW15Mm00Zndkeg0KDQpU aGUgZmlyc3QgcG9sbCBpcyBub3cgZGVsZXRlZC4gIEZvciB0aGUgY291cGxlIG9mIGZvbGtzIHRo YXQgcHV0IHZhbHVlcyB0aGVyZSwgcGxlYXNlIGZpbGwgaW4geW91ciB2YWx1ZXMgYWdhaW4gb24g dGhpcyBuZXcgcG9sbC4NCg0KS2VudA0KDQoNCg0KDQoNCk9uIDIvMy8xNiwgNjo1OSBBTSwgIkFj ZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCg0KPg0KPg0KPk9uIDIv My8xNiwgMToxOCBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0K Pg0KPj4NCj4+PiBPbiAwMyBGZWIgMjAxNiwgYXQgMDM6MjQsIEtlbnQgV2F0c2VuIDxrd2F0c2Vu QGp1bmlwZXIubmV0PiB3cm90ZToNCj4+PiANCj4+PiANCj4+PiBbQ2hhaXIgaGF0IG9uXQ0KPj4+ IA0KPj4+IEdpdmVuIHRoZSBudW1iZXIgb2YgY29tcGV0aW5nL2NvbXBsZW1lbnRpbmcgZHJhZnRz IGludm9sdmVkLCBhbmQgdGhlDQo+Pj5nZW5lcmFsIGxhY2sgb2YgZGlzY3Vzc2lvbiBvbiBhbnkg b2YgdGhlbSwgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZw0KPj4+bWlnaHQgYmUgYW4gZXhwZWRp ZW50IHdheSB0byBwcm9jZWVkLiAgSW4gZmFpcm5lc3MsIHdlIGtub3cgdGhhdCB0aGVyZQ0KPj4+ aGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uLCBidXQgaXQgaGFzbuKAmXQgYmVlbiBwaWNrZWQgdXAg eWV0IGluIGEgYmlnIHdheSwNCj4+PmFuZCBub3cgTG91IGhhcyBhbiB1cGRhdGVkIGRyYWZ0Lg0K Pj4+IA0KPj4+IFRoZSBjaGFpcnMgZGlzY3Vzc2VkIG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBh IGNvdXBsZSB3ZWVrcyBmcm9tIG5vdywNCj4+PnBlcmhhcHMgVGh1cnNkYXkgRmViIDE4IHN0YXJ0 aW5nIGF0IDEwYW0gRVNUPyAgIEknbSB0aGlua2luZw0KPj4NCj4+VGh1cnNkYXkgYXQgdGhpcyB0 aW1lIGRvZXNuJ3Qgc3VpdCBtZSB2ZXJ5IHdlbGwsIE1vbmRheSB0aWxsIFdlZG5lc2RheSBvZg0K Pj50aGF0IHdlZWsgYXJlIE9LLg0KPg0KPknigJltIG91dCB0aGUgZW50aXJlIHdlZWsgb2YgRmVi IDE0dGguDQo+DQo+VGhhbmtzLA0KPkFjZWUgDQo+DQo+DQo+Pg0KPj5MYWRhDQo+Pg0KPj4+ICBh Ym91dCB0aGlzIHNsb3Qgb25seSBzaW5jZSBpdCB3b3JrZWQgZm9yIHVzIGZvciBwcmV2aW91c2x5 LiAgSXMgdGhpcyBhDQo+Pj5nb29kIHRpbWUgc2xvdD8gIEkgYXNzdW1lIHRvIHNjaGVkdWxlIGZv ciAyIGhvdXJzLCB3aXRoIGEgcGxhbiB0byBlbmQNCj4+PmVhcmx5IGlmIG5lZWRlZCAtIG1ha2Vz IHNlbnNlPyAgICAgV2UgYWxzbyBuZWVkIHRvIHB1dCB0b2dldGhlciBhIHByb3Blcg0KPj4+YWdl bmRhLCBwZXJoYXBzIHRoZSBmb2xsb3dpbmc/DQo+Pj4gDQo+Pj4gIDEwIG1pbjogUlRHIERUIFlB TkcgQXJjaCB0ZWFtIHVzZS1jYXNlIHN1bW1hcnkNCj4+PiAgMjAgbWluOiBkcmFmdC1ydGd5YW5n ZHQtcnRnd2ctZGV2aWNlLW1vZGVsDQo+Pj4gIDIwIG1pbjogZHJhZnQtbGhvdGthLW5ldG1vZC15 c2RsDQo+Pj4gIDIwIG1pbjogZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50 DQo+Pj4gIDUwIG1pbjogZ2VuZXJhbCBkaXNjdXNzaW9uIG9yIGVuZCBlYXJseQ0KPj4+IA0KPj4+ IA0KPj4+IFdlIGhvcGUgdG8gc2NoZWR1bGUgdGhlIG1lZXRpbmcgaXRzZWxmIHRvbW9ycm93IG9y IHRoZSBuZXh0IGRheSwgc28NCj4+PnBsZWFzZSByZXNwb25kIHF1aWNrbHkgdG8gdGhpcyBlbWFp bCBpZiBwb3NzaWJsZS4NCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gS2VudCBhbmQgVG9tDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gMi8yLzE2LCAyOjA0IFBNLCAibmV0bW9kIG9uIGJl aGFsZiBvZiBMb3UgQmVyZ2VyIg0KPj4+PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+PiANCj4+Pj4gDQo+Pj4+IEkgdGhvdWdo dCBpdCB3b3VsZCBiZSB3b3J0aCBzdW1tYXJpemluZyB3aGF0IHdlJ3JlIGxvb2tpbmcgZm9yIGlu IG91cg0KPj4+PiBkcmFmdCwgZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wMiAo bm90ZSBuZXcgdmVyc2lvbiBpbiBjYXNlDQo+Pj4+IHlvdSBtaXNzZWQgaXQpIHdpdGggcmVzcGVj dCB0byB0aGUgZHJhZnQtbGhvdGthLW5ldG1vZC15c2RsIGFuZA0KPj4+PiBkcmFmdC1iam9ya2x1 bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQgZHJhZnRzLiBUaGlzIGlzIGp1c3QgbXkgdmlldywN Cj4+Pj5zbw0KPj4+PiBteSBjby1hdXRob3JzIG1heSB3aXNoIHRvIGNoaW1lIGluIGFuZCBjb3Jy ZWN0IG1lLg0KPj4+PiANCj4+Pj4gSSdkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyBmcm9tIHRo ZSBhdXRob3JzIG9mIFlTREwgYW5kDQo+Pj4+IHN0cnVjdHVyYWwtbW91bnQsIG9yIGFueW9uZSBl bHNlIGZvciB0aGF0IG1hdHRlciwgb24gaG93IHRoZXkgc2VlIHRvDQo+Pj4+IGJlc3QgbWVldCB0 aGVzZSBuZWVkcy4NCj4+Pj4gDQo+Pj4+IEhlcmUncyB3aGF0IEkgdGhpbmsgb3VyIGRyYWZ0IG5l ZWRzOg0KPj4+PiANCj4+Pj4gMS4gdGhhdCB0aGVyZSBiZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93 cyB0aGUgaW5jb3Jwb3JhdGlvbiAob3INCj4+Pj4gICdtb3VudGluZycpIG9mIHRoZSBkYXRhIG1v ZGVsIGRlZmluZWQgYnkgb25lIHRvcC1sZXZlbCBtb2R1bGUNCj4+Pj4gIHdpdGhpbiBhbm90aGVy IG1vZHVsZS4NCj4+Pj4gDQo+Pj4+ICBUaGUgaW1wbGljYXRpb24gaGVyZSBpcyB0aGF0IHdoZW4g aW5mb3JtYXRpb24gaXMgaW5zdGFudGlhdGVkDQo+Pj4+ICBmb3IgdGhlIHBhcmVudCBtb2RlbCBp dCBpcyBhbHNvIGluc3RhbnRpYXRlZCBmb3IgdGhlDQo+Pj4+ICBpbmNvcnBvcmF0ZWQvbW91bnRl ZCBtb2RlbC4gSW4gb3VyIGNhc2Ugd2UgZXhwZWN0IHRvIGRvIHRoaXMgb24NCj4+Pj4gIGxpc3Qg ZWxlbWVudCBjcmVhdGlvbi4gQm90aCBzb2x1dGlvbnMgZHJhZnRzIGNvdmVyIHRoZSBwYXRoDQo+ Pj4+ICBpbXBsaWNhdGlvbnMsIHNvIHRoZXNlIGFyZSBub3QgcmVwZWF0ZWQgaGVyZS4NCj4+Pj4g DQo+Pj4+IDIuIHRoYXQgdGhpcyBtZWNoYW5pc20gYWxsb3cgaWRlbnRpZmljYXRpb24gb2Ygc3Bl Y2lmaWMgbW9kdWxlcyB0bw0KPj4+PiAgYmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQgYXQgdGltZSBv ZiBtb2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0DQo+Pj4+ICBubyBhZGRpdGlvbmFsIG1vZHVs ZSBpcyBuZWVkZWQgdG8gc3VwcG9ydCAxLiBUaGlzIGRvZXNuJ3QNCj4+Pj4gIHByZWNsdWRlIGRl ZmluaXRpb24gb2Ygc3VjaCBhIG1vZHVsZS4NCj4+Pj4gDQo+Pj4+IDMuIHRoYXQgdGhpcyBtZWNo YW5pc20gYWxsb3cgZm9yIGEgc2VydmVyIHRvIGNvbnRyb2wgKGFuZA0KPj4+PiAgaWRlbnRpZnkp IHdoaWNoIG1vZHVsZXMgYXJlIGluY29ycG9yYXRlZC9tb3VudGVkLiAoc2VlIFNlY3Rpb24NCj4+ Pj4gIDMgTE5FIGluIG91ciBkcmFmdCBmb3IgYW4gZW52aXNpb25lZCB1c2FnZS4pDQo+Pj4+IA0K Pj4+PiA0LiB0aGF0IGFsbCBjYXBhYmlsaXRpZXMgdGhhdCBleGlzdCB3aXRoIHRoZSBtb3VudGVk IG1vZHVsZSBhcmUNCj4+Pj4gIGF2YWlsYWJsZSBlLmcuIFJQQyBvcGVyYXRpb25zIGFuZCBub3Rp ZmljYXRpb25zLg0KPj4+PiANCj4+Pj4gNS4gd2hpbGUgb3VyIHByaW1hcnkgcmVxdWlyZW1lbnQg aXMgZm9yICdtb3VudGluZycgb2YgdG9wIGxldmVsDQo+Pj4+ICBtb2R1bGVzLCBtb3VudGluZyBv ZiBzdWJtb2R1bGVzIG1heSBhbHNvIGJlIHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPj4+PiAgZHJp dmVuLikNCj4+Pj4gDQo+Pj4+IFdlIG1ha2UgdXNlIG9mIHRoZSBhYm92ZSBpbiBzZWN0aW9ucyAz IGFuZCA0IG9mIHJ0Z3dnLWRldmljZS1tb2RlbC4gIFdlDQo+Pj4+IHNlZSBoYXZpbmcgYSBzb2x1 dGlvbiBhcyBjcml0aWNhbCBmb3IgdGhlIHNpbXBsaWZpY2F0aW9ucy9mbGV4aWJpbGl0eQ0KPj4+ PiByZXByZXNlbnRlZCBpbiB0aGUgLTAyIHZlcnNpb24gb2Ygb3VyIGRyYWZ0IHZzIHRoZSAtMDMg cmV2LiAgV2UgZG9uJ3QNCj4+Pj4gc2VlIHdpdGhlciBzb2x1dGlvbiBkcmFmdCBhcyBzaWduaWZp Y2FudGx5IGRpZmZlcmVudCBhbmQganVzdCBob3BlIGZvcg0KPj4+PmENCj4+Pj4gc3RhbmRhcmQg c29sdXRpb24gYXMgc29vbiBhcyBwb3NzaWJsZS4gIChhIGRyYWZ0LWlldGYtbmV0bW9kIHNvbHV0 aW9ucw0KPj4+PiBkcmFmdCBvbiB0aGUgdG9waWMgYnkgQkEgd291bGQgYmUgZmFudGFzdGljIGdp dmVuIHRoZSBpbXBhY3Qgb24gcm91dGluZw0KPj4+PiBhcmVhIC0tIGV2ZW4gaWYgaXQgaGFkIHRv IGRvY3VtZW50IHR3byB2YXJpYXRpb25zIC8gYWx0ZXJuYXRpdmUNCj4+Pj5zb2x1dGlvbnMuKQ0K Pj4+PiANCj4+Pj4gQWdhaW4sIHRoaXMgaXMganVzdCBteSBvcGluaW9uIGFuZCBteSBjb2F1dGhv cnMgb3Igb3RoZXJzIG9uIHRoZSBydGcNCj4+Pj4gYXJlYSB5YW5nIERUIG1heSBjaG9vc2UgdG8g Y2hpbWUgaW4uDQo+Pj4+IA0KPj4+PiBMb3UNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+DQo+Pi0tDQo+PkxhZGlzbGF2IExob3Rr YSwgQ1ouTklDIExhYnMNCj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+DQo+Pg0KPj4NCj4+DQo+ DQo= From nobody Wed Feb 3 06:08:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642B11ACCE2 for ; Wed, 3 Feb 2016 06:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ofJ1OL8aYwx6 for ; Wed, 3 Feb 2016 06:07:56 -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 2A9441ACCE1 for ; Wed, 3 Feb 2016 06:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5114; q=dns/txt; s=iport; t=1454508476; x=1455718076; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RNdukvaK1dINSIyQPG2cqc8IGwatTTDMZfwjRmvvatY=; b=e1R6TEaMQGkuBnrndXFMxQA7KxRgWy5njcG4wDd6MWLswMzFw9wQUVlw UNAudtmcWy5jBQuONiBahLAM9eluXlg+bFQXcfc4I1i11wvJGEQYb+uBq B/SyRUJWndwqaVrBoVC/ba01D78ltg0wUV09wFw6QUU4XwzB4SklghDzc U=; X-IronPort-AV: E=Sophos;i="5.22,391,1449532800"; d="scan'208";a="624001555" 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; 03 Feb 2016 14:07:54 +0000 Received: from [10.63.23.97] (dhcp-ensft1-uk-vla370-10-63-23-97.cisco.com [10.63.23.97]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u13E7rfN025196; Wed, 3 Feb 2016 14:07:53 GMT To: Kent Watsen References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> From: Robert Wilton Message-ID: <56B209B9.2050504@cisco.com> Date: Wed, 3 Feb 2016 14:07:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 14:08:03 -0000 Hi Kent, There is also another Yang Mount related draft: draft-clemm-netmod-mount-03 Now, this draft doesn't directly address the RTG DT Arch team use-case, and seems to cover two more complex problem scenarios (remote mount and alias mount), but these do appear to be a valid mount use cases (e.g. I think that it is used by OpenDaylight SDN controller), and I know that there is at least one implementation of this draft. So, I want to echo Eric Voit's comments that it would be good if whatever basic YANG mount draft we converge on is able to be cleanly extended to cover the more complex mount scenarios. As such, if Alex Clemm or Eric Voit are willing, I think that it would be useful if one of them could comment on how feasible it is to extend either netmod-structual-mount or netmod-ysdl to cover the remote mount and alias mount scenarios described in draft-clemm-netmod-mount-03. Hence, if they agree, do you think that you would be able to add a 15 min slot to the agenda to cover this please? Thanks, Rob On 03/02/2016 02:24, Kent Watsen wrote: > [Chair hat on] > > Given the number of competing/complementing drafts involved, and the general lack of discussion on any of them, a virtual interim meeting might be an expedient way to proceed. In fairness, we know that there has been some discussion, but it hasn’t been picked up yet in a big way, and now Lou has an updated draft. > > The chairs discussed maybe scheduling one for a couple weeks from now, perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this slot only since it worked for us for previously. Is this a good time slot? I assume to schedule for 2 hours, with a plan to end early if needed - makes sense? We also need to put together a proper agenda, perhaps the following? > > 10 min: RTG DT YANG Arch team use-case summary > 20 min: draft-rtgyangdt-rtgwg-device-model > 20 min: draft-lhotka-netmod-ysdl > 20 min: draft-bjorklund-netmod-structural-mount > 50 min: general discussion or end early > > > We hope to schedule the meeting itself tomorrow or the next day, so please respond quickly to this email if possible. > > Thanks, > Kent and Tom > > > > > On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" wrote: > >> I thought it would be worth summarizing what we're looking for in our >> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case >> you missed it) with respect to the draft-lhotka-netmod-ysdl and >> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so >> my co-authors may wish to chime in and correct me. >> >> I'd be interested in hearing from the authors of YSDL and >> structural-mount, or anyone else for that matter, on how they see to >> best meet these needs. >> >> Here's what I think our draft needs: >> >> 1. that there be a mechanism that allows the incorporation (or >> 'mounting') of the data model defined by one top-level module >> within another module. >> >> The implication here is that when information is instantiated >> for the parent model it is also instantiated for the >> incorporated/mounted model. In our case we expect to do this on >> list element creation. Both solutions drafts cover the path >> implications, so these are not repeated here. >> >> 2. that this mechanism allow identification of specific modules to >> be incorporated/mounted at time of module definition, i.e. that >> no additional module is needed to support 1. This doesn't >> preclude definition of such a module. >> >> 3. that this mechanism allow for a server to control (and >> identify) which modules are incorporated/mounted. (see Section >> 3 LNE in our draft for an envisioned usage.) >> >> 4. that all capabilities that exist with the mounted module are >> available e.g. RPC operations and notifications. >> >> 5. while our primary requirement is for 'mounting' of top level >> modules, mounting of submodules may also be useful. (DT not draft >> driven.) >> >> We make use of the above in sections 3 and 4 of rtgwg-device-model. We >> see having a solution as critical for the simplifications/flexibility >> represented in the -02 version of our draft vs the -03 rev. We don't >> see wither solution draft as significantly different and just hope for a >> standard solution as soon as possible. (a draft-ietf-netmod solutions >> draft on the topic by BA would be fantastic given the impact on routing >> area -- even if it had to document two variations / alternative solutions.) >> >> Again, this is just my opinion and my coauthors or others on the rtg >> area yang DT may choose to chime in. >> >> Lou >> >> >> >> _______________________________________________ >> 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 Feb 3 06:35:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121131ACD52 for ; Wed, 3 Feb 2016 06:35:44 -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, RP_MATCHES_RCVD=-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 rDLsithhmKNX for ; Wed, 3 Feb 2016 06:35: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 836871ACD4F for ; Wed, 3 Feb 2016 06:35:41 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 078001AE018C; Wed, 3 Feb 2016 15:35:39 +0100 (CET) Date: Wed, 03 Feb 2016 15:35:43 +0100 (CET) Message-Id: <20160203.153543.909025237652860519.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <56B1F958.5030206@cisco.com> References: <56B1D435.7030506@cisco.com> <56B1F958.5030206@cisco.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] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 14:35:44 -0000 Benoit Claise wrote: > Hi Lada, > > Thanks for the quick reply. > > Hi Benoit, > > > > thank you for the review, please see my responses inline. > > > > Benoit Claise writes: [...] > >> o identity, > >> > >> There is no identity definition in the RFC 6020 terminology section. > > Maybe it is an omission in 6020bis? > Ok, let's fix it in 6020bis then. Ok. First I wrote: o identity: A globally unique, abstract, and untyped identity. But this is kind of recursive... o identity: A globally unique, abstract, and untyped label. Any other proposal? /martin > > > >> - > >> module foomod { > >> > >> namespace"http://example.com/foomod"; > >> > >> prefix "foo"; > >> > >> container top { > >> leaf foo { > >> type uint8; > >> } > >> } > >> } > >> > >> Use "example-" in the module name, as mentioned > >> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: > >> > >> Example modules are non-normative, and SHOULD be named with the > >> prefix "example-". > >> > >> Same remark for module barmod (and btw, pay attention to the "import > >> foomod") and module exmod > > I agree with Juergen that 6087bis should distinguish between complete > > example modules and short module snippets that are used for explaining > > a > > certain YANG language or encoding issue. If you look at this > > particular > > example, then changing the JSON document on p. 6 to > > > > { > > "example-foomod:top": { > > "foo": 54, > > "example-barmod:bar": true > > } > > } > > > > would IMO just add noise and blur the message the example is supposed > > to > > convey. > So please fix the text in 6087bis. > Until it's done, I'll stick to the current rule. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Feb 3 06:40:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0088D1ACD65 for ; Wed, 3 Feb 2016 06:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 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, RP_MATCHES_RCVD=-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 f7l1VH67Tuq3 for ; Wed, 3 Feb 2016 06:40: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 07C3B1ACD61 for ; Wed, 3 Feb 2016 06:40:41 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48] (unknown [IPv6:2001:718:1a02:1:50fd:c930:6a88:7f48]) by mail.nic.cz (Postfix) with ESMTPSA id 44E72181BC9; Wed, 3 Feb 2016 15:40:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454510440; bh=VoSnn3NL7LhhhQDHzEXtxS40vFtYaA07HQ1RERgNa+c=; h=From:Date:To; b=GJTFOfcQC7Crv5o8xo722jfE+VWzlnIkOFq+Li23hDlNo0AI1m9f9EqV/C8U5g4J/ oSs1dFL0iauDdkUQkpwhWLtmGZcV/EccEvLv3kIXitcGYDl7QlZvJoX201BRvkLP9B 6/lP0ra2QfgugtKtk4/bJtkm6rXtVQzyuhpv3vaI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160203.153543.909025237652860519.mbj@tail-f.com> Date: Wed, 3 Feb 2016 15:40:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <56B1D435.7030506@cisco.com> <56B1F958.5030206@cisco.com> <20160203.153543.909025237652860519.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] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 14:40:44 -0000 > On 03 Feb 2016, at 15:35, Martin Bjorklund wrote: > > Benoit Claise wrote: >> Hi Lada, >> >> Thanks for the quick reply. >>> Hi Benoit, >>> >>> thank you for the review, please see my responses inline. >>> >>> Benoit Claise writes: > > [...] > >>>> o identity, >>>> >>>> There is no identity definition in the RFC 6020 terminology section. >>> Maybe it is an omission in 6020bis? >> Ok, let's fix it in 6020bis then. > > Ok. First I wrote: > > o identity: A globally unique, abstract, and untyped identity. > > But this is kind of recursive... > > o identity: A globally unique, abstract, and untyped label. > > Any other proposal? s/label/name/ ? Lada > > > > /martin > > > > > > > >>> >>>> - >>>> module foomod { >>>> >>>> namespace"http://example.com/foomod"; >>>> >>>> prefix "foo"; >>>> >>>> container top { >>>> leaf foo { >>>> type uint8; >>>> } >>>> } >>>> } >>>> >>>> Use "example-" in the module name, as mentioned >>>> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: >>>> >>>> Example modules are non-normative, and SHOULD be named with the >>>> prefix "example-". >>>> >>>> Same remark for module barmod (and btw, pay attention to the "import >>>> foomod") and module exmod >>> I agree with Juergen that 6087bis should distinguish between complete >>> example modules and short module snippets that are used for explaining >>> a >>> certain YANG language or encoding issue. If you look at this >>> particular >>> example, then changing the JSON document on p. 6 to >>> >>> { >>> "example-foomod:top": { >>> "foo": 54, >>> "example-barmod:bar": true >>> } >>> } >>> >>> would IMO just add noise and blur the message the example is supposed >>> to >>> convey. >> So please fix the text in 6087bis. >> Until it's done, I'll stick to the current rule. >> >> Regards, Benoit >> >> _______________________________________________ >> 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 Feb 3 06:48:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6FA1ACD8C; Wed, 3 Feb 2016 06:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 RPmMpiOzsicy; Wed, 3 Feb 2016 06:48:06 -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 820131ACDA3; Wed, 3 Feb 2016 06:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7116; q=dns/txt; s=iport; t=1454510886; x=1455720486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F2q/MDJrK5LaNgLI0yM6m9YLdozJyF4ZyV2LUcKOmDU=; b=itEkGG9M+pzaISleAQ++GpEAQkLv+oegXnV70Cc3Ml8HiBANZ6I6W/oX +j8WvVlGg5xBG8XuUjPtW6Erbkthp3uiQsSunXrufkknJ38OyNdFpnRgs N7Gq76pfoSZ+bNBS9BQSBkPP/K6Fdv3+Z0DxW34e08cCRtjkdr1hVZyZZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgD3ErJW/40NJK1UCoM6Um0GhCmEL?= =?us-ascii?q?LEKAQ2BZRcKhSJKAhyBKzgUAQEBAQEBAYEKhEIBAQQBAQEgEToLEAIBCA4KAgI?= =?us-ascii?q?mAgICJQsVEAIEAQ0FG4gADrBqjwkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4lOh?= =?us-ascii?q?AIGCwEGFoMCgToFlnEBhUiIBIFbSoN4iFSKboNRAR4BAUKDZGqIOzR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,391,1449532800"; d="scan'208";a="234407136" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 14:48:05 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u13Em5MJ018917 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 14:48:05 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, 3 Feb 2016 09:48:04 -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, 3 Feb 2016 09:48:04 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Ladislav Lhotka Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgADo0ACAAAttAIAAcxKA//+8I4A= Date: Wed, 3 Feb 2016 14:48:04 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> 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.196] Content-Type: text/plain; charset="utf-8" Content-ID: <8E7BB93451065645822103270ABF899F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" , netmod WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 14:48:10 -0000 S2VudCAtIEnigJltIGFzc3VtaW5nIHRoZSBwb2xsIGlzIEVTVCBnaXZlbiB0aGF0IGlzIHdoZXJl IHlvdSBhcmUgbG9jYXRlZC4NClRoYW5rcywNCkFjZWUNCg0KT24gMi8zLzE2LCA4OjUwIEFNLCAi S2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPg0KPk5vIHByb2Js ZW0sIEkganVzdCBjcmVhdGVkIGFub3RoZXIgcG9sbCBmb3IgdGhlIGZvbGxvd2luZyB3ZWVrOg0K Pg0KPglodHRwOi8vZG9vZGxlLmNvbS9wb2xsL2J5dWdwNHVteTJtNGZ3ZHoNCj4NCj5UaGUgZmly c3QgcG9sbCBpcyBub3cgZGVsZXRlZC4gIEZvciB0aGUgY291cGxlIG9mIGZvbGtzIHRoYXQgcHV0 IHZhbHVlcw0KPnRoZXJlLCBwbGVhc2UgZmlsbCBpbiB5b3VyIHZhbHVlcyBhZ2FpbiBvbiB0aGlz IG5ldyBwb2xsLg0KPg0KPktlbnQNCj4NCj4NCj4NCj4NCj4NCj5PbiAyLzMvMTYsIDY6NTkgQU0s ICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+Pg0KPj4N Cj4+T24gMi8zLzE2LCAxOjE4IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4g d3JvdGU6DQo+Pg0KPj4+DQo+Pj4+IE9uIDAzIEZlYiAyMDE2LCBhdCAwMzoyNCwgS2VudCBXYXRz ZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFtDaGFp ciBoYXQgb25dDQo+Pj4+IA0KPj4+PiBHaXZlbiB0aGUgbnVtYmVyIG9mIGNvbXBldGluZy9jb21w bGVtZW50aW5nIGRyYWZ0cyBpbnZvbHZlZCwgYW5kIHRoZQ0KPj4+PmdlbmVyYWwgbGFjayBvZiBk aXNjdXNzaW9uIG9uIGFueSBvZiB0aGVtLCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nDQo+Pj4+ bWlnaHQgYmUgYW4gZXhwZWRpZW50IHdheSB0byBwcm9jZWVkLiAgSW4gZmFpcm5lc3MsIHdlIGtu b3cgdGhhdCB0aGVyZQ0KPj4+PmhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiwgYnV0IGl0IGhhc27i gJl0IGJlZW4gcGlja2VkIHVwIHlldCBpbiBhIGJpZw0KPj4+PndheSwNCj4+Pj5hbmQgbm93IExv dSBoYXMgYW4gdXBkYXRlZCBkcmFmdC4NCj4+Pj4gDQo+Pj4+IFRoZSBjaGFpcnMgZGlzY3Vzc2Vk IG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBhIGNvdXBsZSB3ZWVrcyBmcm9tIG5vdywNCj4+Pj5w ZXJoYXBzIFRodXJzZGF5IEZlYiAxOCBzdGFydGluZyBhdCAxMGFtIEVTVD8gICBJJ20gdGhpbmtp bmcNCj4+Pg0KPj4+VGh1cnNkYXkgYXQgdGhpcyB0aW1lIGRvZXNuJ3Qgc3VpdCBtZSB2ZXJ5IHdl bGwsIE1vbmRheSB0aWxsIFdlZG5lc2RheQ0KPj4+b2YNCj4+PnRoYXQgd2VlayBhcmUgT0suDQo+ Pg0KPj5J4oCZbSBvdXQgdGhlIGVudGlyZSB3ZWVrIG9mIEZlYiAxNHRoLg0KPj4NCj4+VGhhbmtz LA0KPj5BY2VlIA0KPj4NCj4+DQo+Pj4NCj4+PkxhZGENCj4+Pg0KPj4+PiAgYWJvdXQgdGhpcyBz bG90IG9ubHkgc2luY2UgaXQgd29ya2VkIGZvciB1cyBmb3IgcHJldmlvdXNseS4gIElzIHRoaXMN Cj4+Pj5hDQo+Pj4+Z29vZCB0aW1lIHNsb3Q/ICBJIGFzc3VtZSB0byBzY2hlZHVsZSBmb3IgMiBo b3Vycywgd2l0aCBhIHBsYW4gdG8gZW5kDQo+Pj4+ZWFybHkgaWYgbmVlZGVkIC0gbWFrZXMgc2Vu c2U/ICAgICBXZSBhbHNvIG5lZWQgdG8gcHV0IHRvZ2V0aGVyIGENCj4+Pj5wcm9wZXINCj4+Pj5h Z2VuZGEsIHBlcmhhcHMgdGhlIGZvbGxvd2luZz8NCj4+Pj4gDQo+Pj4+ICAxMCBtaW46IFJURyBE VCBZQU5HIEFyY2ggdGVhbSB1c2UtY2FzZSBzdW1tYXJ5DQo+Pj4+ICAyMCBtaW46IGRyYWZ0LXJ0 Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwNCj4+Pj4gIDIwIG1pbjogZHJhZnQtbGhvdGthLW5l dG1vZC15c2RsDQo+Pj4+ICAyMCBtaW46IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3RydWN0dXJh bC1tb3VudA0KPj4+PiAgNTAgbWluOiBnZW5lcmFsIGRpc2N1c3Npb24gb3IgZW5kIGVhcmx5DQo+ Pj4+IA0KPj4+PiANCj4+Pj4gV2UgaG9wZSB0byBzY2hlZHVsZSB0aGUgbWVldGluZyBpdHNlbGYg dG9tb3Jyb3cgb3IgdGhlIG5leHQgZGF5LCBzbw0KPj4+PnBsZWFzZSByZXNwb25kIHF1aWNrbHkg dG8gdGhpcyBlbWFpbCBpZiBwb3NzaWJsZS4NCj4+Pj4gDQo+Pj4+IFRoYW5rcywNCj4+Pj4gS2Vu dCBhbmQgVG9tDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiAyLzIvMTYsIDI6 MDQgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExvdSBCZXJnZXIiDQo+Pj4+PG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IEkgdGhvdWdodCBpdCB3b3VsZCBiZSB3b3J0aCBzdW1tYXJpemluZyB3 aGF0IHdlJ3JlIGxvb2tpbmcgZm9yIGluIG91cg0KPj4+Pj4gZHJhZnQsIGRyYWZ0LXJ0Z3lhbmdk dC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDIgKG5vdGUgbmV3IHZlcnNpb24gaW4NCj4+Pj4+Y2FzZQ0K Pj4+Pj4geW91IG1pc3NlZCBpdCkgd2l0aCByZXNwZWN0IHRvIHRoZSBkcmFmdC1saG90a2EtbmV0 bW9kLXlzZGwgYW5kDQo+Pj4+PiBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91 bnQgZHJhZnRzLiBUaGlzIGlzIGp1c3QgbXkgdmlldywNCj4+Pj4+c28NCj4+Pj4+IG15IGNvLWF1 dGhvcnMgbWF5IHdpc2ggdG8gY2hpbWUgaW4gYW5kIGNvcnJlY3QgbWUuDQo+Pj4+PiANCj4+Pj4+ IEknZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgZnJvbSB0aGUgYXV0aG9ycyBvZiBZU0RMIGFu ZA0KPj4+Pj4gc3RydWN0dXJhbC1tb3VudCwgb3IgYW55b25lIGVsc2UgZm9yIHRoYXQgbWF0dGVy LCBvbiBob3cgdGhleSBzZWUgdG8NCj4+Pj4+IGJlc3QgbWVldCB0aGVzZSBuZWVkcy4NCj4+Pj4+ IA0KPj4+Pj4gSGVyZSdzIHdoYXQgSSB0aGluayBvdXIgZHJhZnQgbmVlZHM6DQo+Pj4+PiANCj4+ Pj4+IDEuIHRoYXQgdGhlcmUgYmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdGhlIGluY29ycG9y YXRpb24gKG9yDQo+Pj4+PiAgJ21vdW50aW5nJykgb2YgdGhlIGRhdGEgbW9kZWwgZGVmaW5lZCBi eSBvbmUgdG9wLWxldmVsIG1vZHVsZQ0KPj4+Pj4gIHdpdGhpbiBhbm90aGVyIG1vZHVsZS4NCj4+ Pj4+IA0KPj4+Pj4gIFRoZSBpbXBsaWNhdGlvbiBoZXJlIGlzIHRoYXQgd2hlbiBpbmZvcm1hdGlv biBpcyBpbnN0YW50aWF0ZWQNCj4+Pj4+ICBmb3IgdGhlIHBhcmVudCBtb2RlbCBpdCBpcyBhbHNv IGluc3RhbnRpYXRlZCBmb3IgdGhlDQo+Pj4+PiAgaW5jb3Jwb3JhdGVkL21vdW50ZWQgbW9kZWwu IEluIG91ciBjYXNlIHdlIGV4cGVjdCB0byBkbyB0aGlzIG9uDQo+Pj4+PiAgbGlzdCBlbGVtZW50 IGNyZWF0aW9uLiBCb3RoIHNvbHV0aW9ucyBkcmFmdHMgY292ZXIgdGhlIHBhdGgNCj4+Pj4+ICBp bXBsaWNhdGlvbnMsIHNvIHRoZXNlIGFyZSBub3QgcmVwZWF0ZWQgaGVyZS4NCj4+Pj4+IA0KPj4+ Pj4gMi4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBpZGVudGlmaWNhdGlvbiBvZiBzcGVjaWZp YyBtb2R1bGVzIHRvDQo+Pj4+PiAgYmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQgYXQgdGltZSBvZiBt b2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0DQo+Pj4+PiAgbm8gYWRkaXRpb25hbCBtb2R1bGUg aXMgbmVlZGVkIHRvIHN1cHBvcnQgMS4gVGhpcyBkb2Vzbid0DQo+Pj4+PiAgcHJlY2x1ZGUgZGVm aW5pdGlvbiBvZiBzdWNoIGEgbW9kdWxlLg0KPj4+Pj4gDQo+Pj4+PiAzLiB0aGF0IHRoaXMgbWVj aGFuaXNtIGFsbG93IGZvciBhIHNlcnZlciB0byBjb250cm9sIChhbmQNCj4+Pj4+ICBpZGVudGlm eSkgd2hpY2ggbW9kdWxlcyBhcmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQuIChzZWUgU2VjdGlvbg0K Pj4+Pj4gIDMgTE5FIGluIG91ciBkcmFmdCBmb3IgYW4gZW52aXNpb25lZCB1c2FnZS4pDQo+Pj4+ PiANCj4+Pj4+IDQuIHRoYXQgYWxsIGNhcGFiaWxpdGllcyB0aGF0IGV4aXN0IHdpdGggdGhlIG1v dW50ZWQgbW9kdWxlIGFyZQ0KPj4+Pj4gIGF2YWlsYWJsZSBlLmcuIFJQQyBvcGVyYXRpb25zIGFu ZCBub3RpZmljYXRpb25zLg0KPj4+Pj4gDQo+Pj4+PiA1LiB3aGlsZSBvdXIgcHJpbWFyeSByZXF1 aXJlbWVudCBpcyBmb3IgJ21vdW50aW5nJyBvZiB0b3AgbGV2ZWwNCj4+Pj4+ICBtb2R1bGVzLCBt b3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNvIGJlIHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0K Pj4+Pj4gIGRyaXZlbi4pDQo+Pj4+PiANCj4+Pj4+IFdlIG1ha2UgdXNlIG9mIHRoZSBhYm92ZSBp biBzZWN0aW9ucyAzIGFuZCA0IG9mIHJ0Z3dnLWRldmljZS1tb2RlbC4NCj4+Pj4+V2UNCj4+Pj4+ IHNlZSBoYXZpbmcgYSBzb2x1dGlvbiBhcyBjcml0aWNhbCBmb3IgdGhlIHNpbXBsaWZpY2F0aW9u cy9mbGV4aWJpbGl0eQ0KPj4+Pj4gcmVwcmVzZW50ZWQgaW4gdGhlIC0wMiB2ZXJzaW9uIG9mIG91 ciBkcmFmdCB2cyB0aGUgLTAzIHJldi4gIFdlIGRvbid0DQo+Pj4+PiBzZWUgd2l0aGVyIHNvbHV0 aW9uIGRyYWZ0IGFzIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGFuZCBqdXN0IGhvcGUNCj4+Pj4+ Zm9yDQo+Pj4+PmENCj4+Pj4+IHN0YW5kYXJkIHNvbHV0aW9uIGFzIHNvb24gYXMgcG9zc2libGUu ICAoYSBkcmFmdC1pZXRmLW5ldG1vZA0KPj4+Pj5zb2x1dGlvbnMNCj4+Pj4+IGRyYWZ0IG9uIHRo ZSB0b3BpYyBieSBCQSB3b3VsZCBiZSBmYW50YXN0aWMgZ2l2ZW4gdGhlIGltcGFjdCBvbg0KPj4+ Pj5yb3V0aW5nDQo+Pj4+PiBhcmVhIC0tIGV2ZW4gaWYgaXQgaGFkIHRvIGRvY3VtZW50IHR3byB2 YXJpYXRpb25zIC8gYWx0ZXJuYXRpdmUNCj4+Pj4+c29sdXRpb25zLikNCj4+Pj4+IA0KPj4+Pj4g QWdhaW4sIHRoaXMgaXMganVzdCBteSBvcGluaW9uIGFuZCBteSBjb2F1dGhvcnMgb3Igb3RoZXJz IG9uIHRoZSBydGcNCj4+Pj4+IGFyZWEgeWFuZyBEVCBtYXkgY2hvb3NlIHRvIGNoaW1lIGluLg0K Pj4+Pj4gDQo+Pj4+PiBMb3UNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4NCj4+Pi0tDQo+Pj5MYWRpc2xhdiBMaG90 a2EsIENaLk5JQyBMYWJzDQo+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+DQo+Pj4NCj4+Pg0K Pj4+DQo+Pg0KDQo= From nobody Wed Feb 3 06:57:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48151ACDCB; Wed, 3 Feb 2016 06:57: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 RkwCbG6qP8Ti; Wed, 3 Feb 2016 06:57:10 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E28D1ACDC5; Wed, 3 Feb 2016 06:57:08 -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.396.15; Wed, 3 Feb 2016 14:57:07 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0396.020; Wed, 3 Feb 2016 14:57:07 +0000 From: Kent Watsen To: "Acee Lindem (acee)" Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgACU/gCAAF9CAP//y2sAgABjygCAAAKHMg== Date: Wed, 3 Feb 2016 14:57:06 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [96.231.191.4] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:cq3kK2A5Zg67Z1AJku1olXCmQgwWrl8B+q1RECW6TEX7VmyiDvkOg4DgmeFr1PJGn5JPInzECj69mfzpktuOVYOgVA4fkWa/fq40qbWVVgUGi6kgO+3v8YD3U0lD7GeUVnTNdhS6yAXlNvP4RAZ9MQ==; 24:U5und0qY5wzyaJV7+LHVVkorZCywiU9diP+29kYdSw7+HwQFP05kpY7srES6lD16X2NmBFX6KLM/bEsPu9W3p0AwgRDZHyHsUmnGaMWdTg0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 9867d367-8d77-437f-88d3-08d32caa4908 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)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(164054003)(377454003)(11100500001)(40100003)(54356999)(122556002)(1720100001)(50986999)(189998001)(6116002)(5008740100001)(87936001)(82746002)(66066001)(86362001)(15975445007)(575784001)(2906002)(36756003)(76176999)(77096005)(15395725005)(33656002)(5004730100002)(1096002)(586003)(1220700001)(102836003)(83716003)(93886004)(4326007)(19580405001)(5001960100002)(19580395003)(106116001)(10400500002)(2950100001)(2900100001)(92566002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 14:57:06.9569 (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 WG , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "draft-bjorklund-netmod-structural-mount@ietf.org" , "draft-lhotka-netmod-ysdl@ietf.org" Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 14:57:16 -0000 Yes, the meeting times are in timezone EST. Doodle should display the tim= ezone and let you set your own. =20 Kent > On Feb 3, 2016, at 9:48 AM, Acee Lindem (acee) wrote: >=20 > Kent - I=92m assuming the poll is EST given that is where you are located= . > Thanks, > Acee >=20 >> On 2/3/16, 8:50 AM, "Kent Watsen" wrote: >>=20 >>=20 >> No problem, I just created another poll for the following week: >>=20 >> http://doodle.com/poll/byugp4umy2m4fwdz >>=20 >> The first poll is now deleted. For the couple of folks that put values >> there, please fill in your values again on this new poll. >>=20 >> Kent >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 2/3/16, 6:59 AM, "Acee Lindem (acee)" wrote: >>>=20 >>>=20 >>>=20 >>>> On 2/3/16, 1:18 AM, "Ladislav Lhotka" wrote: >>>>=20 >>>>=20 >>>>> On 03 Feb 2016, at 03:24, Kent Watsen wrote: >>>>>=20 >>>>>=20 >>>>> [Chair hat on] >>>>>=20 >>>>> Given the number of competing/complementing drafts involved, and the >>>>> general lack of discussion on any of them, a virtual interim meeting >>>>> might be an expedient way to proceed. In fairness, we know that ther= e >>>>> has been some discussion, but it hasn=92t been picked up yet in a big >>>>> way, >>>>> and now Lou has an updated draft. >>>>>=20 >>>>> The chairs discussed maybe scheduling one for a couple weeks from now= , >>>>> perhaps Thursday Feb 18 starting at 10am EST? I'm thinking >>>>=20 >>>> Thursday at this time doesn't suit me very well, Monday till Wednesday >>>> of >>>> that week are OK. >>>=20 >>> I=92m out the entire week of Feb 14th. >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>>>=20 >>>> Lada >>>>=20 >>>>> about this slot only since it worked for us for previously. Is this >>>>> a >>>>> good time slot? I assume to schedule for 2 hours, with a plan to end >>>>> early if needed - makes sense? We also need to put together a >>>>> proper >>>>> agenda, perhaps the following? >>>>>=20 >>>>> 10 min: RTG DT YANG Arch team use-case summary >>>>> 20 min: draft-rtgyangdt-rtgwg-device-model >>>>> 20 min: draft-lhotka-netmod-ysdl >>>>> 20 min: draft-bjorklund-netmod-structural-mount >>>>> 50 min: general discussion or end early >>>>>=20 >>>>>=20 >>>>> We hope to schedule the meeting itself tomorrow or the next day, so >>>>> please respond quickly to this email if possible. >>>>>=20 >>>>> Thanks, >>>>> Kent and Tom >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> I thought it would be worth summarizing what we're looking for in ou= r >>>>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in >>>>>> case >>>>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and >>>>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view= , >>>>>> so >>>>>> my co-authors may wish to chime in and correct me. >>>>>>=20 >>>>>> I'd be interested in hearing from the authors of YSDL and >>>>>> structural-mount, or anyone else for that matter, on how they see to >>>>>> best meet these needs. >>>>>>=20 >>>>>> Here's what I think our draft needs: >>>>>>=20 >>>>>> 1. that there be a mechanism that allows the incorporation (or >>>>>> 'mounting') of the data model defined by one top-level module >>>>>> within another module. >>>>>>=20 >>>>>> The implication here is that when information is instantiated >>>>>> for the parent model it is also instantiated for the >>>>>> incorporated/mounted model. In our case we expect to do this on >>>>>> list element creation. Both solutions drafts cover the path >>>>>> implications, so these are not repeated here. >>>>>>=20 >>>>>> 2. that this mechanism allow identification of specific modules to >>>>>> be incorporated/mounted at time of module definition, i.e. that >>>>>> no additional module is needed to support 1. This doesn't >>>>>> preclude definition of such a module. >>>>>>=20 >>>>>> 3. that this mechanism allow for a server to control (and >>>>>> identify) which modules are incorporated/mounted. (see Section >>>>>> 3 LNE in our draft for an envisioned usage.) >>>>>>=20 >>>>>> 4. that all capabilities that exist with the mounted module are >>>>>> available e.g. RPC operations and notifications. >>>>>>=20 >>>>>> 5. while our primary requirement is for 'mounting' of top level >>>>>> modules, mounting of submodules may also be useful. (DT not draft >>>>>> driven.) >>>>>>=20 >>>>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>>>> We >>>>>> see having a solution as critical for the simplifications/flexibilit= y >>>>>> represented in the -02 version of our draft vs the -03 rev. We don'= t >>>>>> see wither solution draft as significantly different and just hope >>>>>> for >>>>>> a >>>>>> standard solution as soon as possible. (a draft-ietf-netmod >>>>>> solutions >>>>>> draft on the topic by BA would be fantastic given the impact on >>>>>> routing >>>>>> area -- even if it had to document two variations / alternative >>>>>> solutions.) >>>>>>=20 >>>>>> Again, this is just my opinion and my coauthors or others on the rtg >>>>>> area yang DT may choose to chime in. >>>>>>=20 >>>>>> Lou >>>>>>=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 >=20 From nobody Wed Feb 3 07:35:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA61ACE5B; Wed, 3 Feb 2016 07:35:57 -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 zkhSJNTP304u; Wed, 3 Feb 2016 07:35:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EE41ACE49; Wed, 3 Feb 2016 07:35:50 -0800 (PST) Received: from BLUPR05MB069.namprd05.prod.outlook.com (10.255.214.14) by BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) with Microsoft SMTP Server (TLS) id 15.1.396.15; Wed, 3 Feb 2016 15:35:30 +0000 Received: from BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.90]) by BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.137]) with mapi id 15.01.0396.020; Wed, 3 Feb 2016 15:35:30 +0000 From: "Lisa (Yi) Huang" To: Nadeau Thomas , NETMOD Working Group Thread-Topic: [netmod] draft-ietf-netmod-acl-model status Thread-Index: AQHRXQneGGHxPsbwMka+ePMolPLl258Z8NEA Date: Wed, 3 Feb 2016 15:35:29 +0000 Message-ID: References: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> In-Reply-To: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.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: lucidvision.com; dkim=none (message not signed) header.d=none;lucidvision.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BLUPR05MB071; 5:X4nP5EM0JE8wjb2MdI+SJy/5jIREOU03K0QM1XsU5CvgBYyjWH7Ec5MR3ZuJ8m0bX0Gar1CCEMBdIROrYW3uqJy+CZG0aHYHU5KToJ7SYNgl8/NsalHm9XiPk5Lgd7fOjAIXwfG9NCyPhe/yTt9Avg==; 24:mAfx1wjCQd6itVCAvtTTB2LS1DWiur08XwTkDaGwilZ7X0kFQQpIBFZUhjr0WnXXLb+GrL66Ap4dNqXPnRZLpWYxlQv0PWisnpzPfCbSeVI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB071; x-ms-office365-filtering-correlation-id: 095ba0dc-5ad0-4b0a-b522-08d32cafa5ef 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)(3002001)(10201501046); SRVR:BLUPR05MB071; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB071; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(24454002)(479174004)(19580405001)(40100003)(4001350100001)(230783001)(36756003)(5001770100001)(5001960100002)(2900100001)(2950100001)(19580395003)(189998001)(92566002)(2906002)(87936001)(5008740100001)(3280700002)(3846002)(15975445007)(586003)(3660700001)(83506001)(4326007)(76176999)(1220700001)(102836003)(6116002)(54356999)(50986999)(1096002)(5004730100002)(122556002)(99286002)(10400500002)(5002640100001)(86362001)(66066001)(106116001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB071; H:BLUPR05MB069.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 15:35:29.5327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB071 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-acl-model status 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, 03 Feb 2016 15:35:57 -0000 Tom, We discussed the review comments in the working group in offline meeting. Will publish a new draft to address comments. Thanks, Lisa On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas" wrote: > > ACL Doc Authors: > > What is your status and plan to address the numerous technical comments >that have arisen since the WG LC? >I know there are for example, numerous detailed comments from Juergen and >I think Elliot Lear posted some too. > > =8BTom > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 3 08:33:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE421B29CC for ; Wed, 3 Feb 2016 08:33:28 -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, RP_MATCHES_RCVD=-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 uQc5PuNS-40l for ; Wed, 3 Feb 2016 08:33: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 AFAD11B29CA for ; Wed, 3 Feb 2016 08:33:26 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 17E731AE018C; Wed, 3 Feb 2016 17:33:25 +0100 (CET) Date: Wed, 03 Feb 2016 17:33:28 +0100 (CET) Message-Id: <20160203.173328.2114908676730595749.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> <56B20288.6070204@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 16:33:28 -0000 Ladislav Lhotka wrote: > = > > On 03 Feb 2016, at 14:37, Benoit Claise wrote: > > = > > Hi Lada, > >> = > >>>> I agree with Juergen that 6087bis should distinguish between com= plete > >>>> example modules and short module snippets that are used for expl= aining a > >>>> certain YANG language or encoding issue. If you look at this par= ticular > >>>> example, then changing the JSON document on p. 6 to > >>>> = > >>>> { > >>>> "example-foomod:top": { > >>>> "foo": 54, > >>>> "example-barmod:bar": true > >>>> } > >>>> } > >>>> = > >>>> would IMO just add noise and blur the message the example is sup= posed to > >>>> convey. > >>> So please fix the text in 6087bis. > >>> Until it's done, I'll stick to the current rule. > >> I don't want to be excessively bureaucratic but, strictly > speaking, current rules are those of RFC 6087 that contains no such > requirement, so we should be OK for now. And I think there is enough > consensus > > so J=FCrgen and you? > = > I guess Martin as well, given that 6020bis doesn't follow that rule. I agree that not all modules must compile, e.g. we have things like: module example-foo { ... container bar { ... } } Having said that, in the upcoming version of 6020bis, I have changed things like "module acme-system" to "module example-system". /martin > = > Lada > = > >> to change the corresponding 6087bis text - after all, 6020bis also= has example modules whose names don't start with "example-". > > I'll still have to review it and that will be one of my comments, f= or sure. Consistency first. > > = > > Regards ,Benoit > > = > = > -- > 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 Feb 3 08:45:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C61ACCFB; Wed, 3 Feb 2016 08:45: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 OjP4SsbWmQQT; Wed, 3 Feb 2016 08:45:23 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 8BF901B2A04; Wed, 3 Feb 2016 08:45:23 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id p63so79288332wmp.1; Wed, 03 Feb 2016 08:45:23 -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=90XtjQYc7lGAnV4aKpl1h7yQ247x5qhuZLs16WZZNhc=; b=HnA0wLSSE9cCZeNVGFl6j1syYWxYdnbpatJSXO+kLWApFSav/w8FMN2S+iroLQ53xE wiQ7bW7XVmzhrInrPYJmPpbZ4B+3QWv8pbbE0j4dSAdBe5O6dbKDOjcwsMD1XYlcTSvv dtJ0qOywZgra4S1ojn7pEXZx5uQ88fnhzxKgpwKJybcEPcVtIdAQU2ij+5yMmxx+nUiC sEJR3sOxopv/+v4NGvFppVVwYOFoEuvfe+LBirtwcUITyPZ9mT6HV+FgkwDH4+c1/Gkb ICRqPtl6a/JlLW6tWF2b2MVAYCl3Gp8V/xdK3iCZtsJ1UvOejkbGrXiShk6r8kTbj3Sg aVsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=90XtjQYc7lGAnV4aKpl1h7yQ247x5qhuZLs16WZZNhc=; b=IkMjNT9eCNblQly2jDv4erF66kGUMuiIbB8QVsvk/fqEUXwyOVeL5AwENHkpomQ5rP l2mXDk5+vm5G08vfv98dNXYYMFW2t6dx3qpgw9wx6s6GGF6ClrdwFOC2+yAn6ByRzm+D jYASUQ5RGQ67yeZoEbJT2j2ucxbckAgOORXuEQAlibcXBeEVgAExVclW9N0rr1bbVMjb CqSOKSMUj0AZrYdUJk+dUmmKqJ3eUofkSaEXOAv7jlWsIiKxVPfqgbEoOluR9LivXnir lsqyv2kJRPZGtVbVjuHiTEKqG5g6m/kdGZydj3nWilPatFF7o4R8qqu+vb/bPwhTiWEx 45/w== X-Gm-Message-State: AG10YOQYg9ch5hB1GA3EBmy9Yg8k9omIBrxNOVdceDXxGSKkv3TY3AU9IzC9ywhK8H1NLw== X-Received: by 10.28.46.87 with SMTP id u84mr5259820wmu.102.1454517921892; Wed, 03 Feb 2016 08:45:21 -0800 (PST) Received: from [192.168.254.183] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id lw7sm7330107wjb.19.2016.02.03.08.45.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Feb 2016 08:45:21 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Wed, 3 Feb 2016 17:45:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E9CAE8F-14EE-4759-8463-9E0D687D597B@gmail.com> References: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> To: "Lisa (Yi) Huang" , Nadeau Thomas X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" , NETMOD Working Group Subject: Re: [netmod] draft-ietf-netmod-acl-model status 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, 03 Feb 2016 16:45:30 -0000 Tom, We will publish ACL model requiring YANG 1.1 as per discussion on the = list Dean > On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang = wrote: >=20 > Tom, >=20 > We discussed the review comments in the working group in offline = meeting. > Will publish a new draft to address comments. Thanks, >=20 > Lisa >=20 > On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas" > wrote: >=20 >>=20 >> ACL Doc Authors: >>=20 >> What is your status and plan to address the numerous technical = comments >> that have arisen since the WG LC? >> I know there are for example, numerous detailed comments from Juergen = and >> I think Elliot Lear posted some too. >>=20 >> =8BTom >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Wed Feb 3 09:06:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F181B2A5B for ; Wed, 3 Feb 2016 09:06:15 -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, RP_MATCHES_RCVD=-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 CXr__AGBXQ0S for ; Wed, 3 Feb 2016 09:06:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC3C1B2A79 for ; Wed, 3 Feb 2016 09:06:13 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 57E541AE018C; Wed, 3 Feb 2016 18:06:12 +0100 (CET) Date: Wed, 03 Feb 2016 18:06:15 +0100 (CET) Message-Id: <20160203.180615.336308990853092641.mbj@tail-f.com> To: wivory@Brocade.com From: Martin Bjorklund In-Reply-To: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.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] Where can I insert new YANG substatements? 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, 03 Feb 2016 17:06:15 -0000 Hi, William Ivory wrote: > Hi, > > My colleagues and I are looking for clarification of the last point in > Section 10 of YANG 1.0: > > ' In statements that have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered.' > > We understand that existing statements must not be reordered in a new > revision of a YANG module, but we're not clear if new statements may > be inserted between existing statements, or must always come at the > 'end' of a list or container definition. They can be inserted anywhere. As Lada pointed out, this should be clarified in 6020bis. I will do: OLD: In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. NEW: In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. If new data definition statements are added, they can be added anywhere between these substatement. > A specific example we're > concerned with is where a grouping is used, and then later that > grouping has an extra element added, but the new node could also be > added directly. Eg: > > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf D > } > > Is it valid in a new revision of the module to do the following, or > must the order be A, B, C, D, E? What if grouping B has gained a new > statement? > > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf E < ---- ADDED > Leaf D > } This is valid. /martin > > Thanks, > > William > > From nobody Wed Feb 3 09:22:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F46C1B3548 for ; Wed, 3 Feb 2016 09:22:23 -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, KHOP_DYNAMIC=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 lz_SQxbbDCmo for ; Wed, 3 Feb 2016 09:22:21 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939531B3544 for ; Wed, 3 Feb 2016 09:22:21 -0800 (PST) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u13H3VBI002373; Wed, 3 Feb 2016 09:22:16 -0800 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 20rwbctnss-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Feb 2016 09:22:16 -0800 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 10:22:14 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 18:22:12 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 3 Feb 2016 18:22:12 +0100 From: William Ivory To: Martin Bjorklund Thread-Topic: [netmod] Where can I insert new YANG substatements? Thread-Index: AdFeYJUcfd1aQ+BIRySt2Lm2mL07FgAPDnSAAAKSEyA= Date: Wed, 3 Feb 2016 17:22:01 +0000 Deferred-Delivery: Wed, 3 Feb 2016 17:21:06 +0000 Message-ID: <090409365fe5457a9fe9fdf3ed136503@EMEAWP-EXMB12.corp.brocade.com> References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> <20160203.180615.336308990853092641.mbj@tail-f.com> In-Reply-To: <20160203.180615.336308990853092641.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.50.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602030287 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Where can I insert new YANG substatements? 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, 03 Feb 2016 17:22:23 -0000 Hi Martin, Thanks - that looks good to me. William -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 03 February 2016 17:06 To: William Ivory Cc: netmod@ietf.org Subject: Re: [netmod] Where can I insert new YANG substatements? Hi, William Ivory wrote: > Hi, > > My colleagues and I are looking for clarification of the last point in > Section 10 of YANG 1.0: > > ' In statements that have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered.' > > We understand that existing statements must not be reordered in a new > revision of a YANG module, but we're not clear if new statements may > be inserted between existing statements, or must always come at the > 'end' of a list or container definition. They can be inserted anywhere. As Lada pointed out, this should be clarified in 6020bis. I will do: OLD: In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. NEW: In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. If new data definition statements are added, they can be added anywhere between these substatement. > A specific example we're > concerned with is where a grouping is used, and then later that > grouping has an extra element added, but the new node could also be > added directly. Eg: > > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf D > } > > Is it valid in a new revision of the module to do the following, or > must the order be A, B, C, D, E? What if grouping B has gained a new > statement? > > Container foo { > Leaf A > Uses grouping B; > Leaf C > Leaf E < ---- ADDED > Leaf D > } This is valid. /martin > > Thanks, > > William > > From nobody Wed Feb 3 09:32:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBA1B3582 for ; Wed, 3 Feb 2016 09:32:43 -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 7wpCph_w4JQu for ; Wed, 3 Feb 2016 09:32:42 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 65FCB1B355A for ; Wed, 3 Feb 2016 09:32:41 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id l143so19139183lfe.2 for ; Wed, 03 Feb 2016 09:32: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=NtxWcO+Rho+qt7INPYzbj7VCW6iIYGyvu054kdZF768=; b=Aj9DROFORxC5qWL1vCZI40/+XNjN1LKP2FlnvkvOQrnVo9Qlnr9Ne1nH/eYWddU9kS 9ZJO5WpRhJs4rJ/K6+zK6DkVjA9TKgrQ8cn1OoN2rQ5Ax+bE9I2QXi2Z1WQ9A1xoz3nQ hyWfpsclcce1XwCPVd0JsLSKP7t4n8K7qqpyjBJLiITXlXr0wmwiBNRYw186z3pNNtTV U5IUcYpf9/iEubw0mavuhllEixeZhRZPyxZ1AEL6E4PFnNSgym1+pKutE39DvBJNIlgC hSlRfGujLfj5FqeujtZLa8KRMny1nVIgbKAbtOv0PzFWgN91MvC2j7I3KBXnX8uPj5MV 518g== 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=NtxWcO+Rho+qt7INPYzbj7VCW6iIYGyvu054kdZF768=; b=Cei9ebDaXVP6FHv5ZpsKv31PpxfI1RQ3LKkieRcusMfWd7QzBJHr1rx5+TYmH5CChX Y3uKpQ6drx3Waz8ELvhMJMB2mRBuYI84QtTBUvv7iD4GPegYZDHvJr0cS7Fx02AhYZbg V7pstCmbVrlPbvlREl7LzLTBh4P9tn9NghZaQKhiF6gHYMZGclPxuDjSSikJTkjRJ3ck NIzB7C14X2FDjZpObX5me0kopXjaENGiVBlw7x6CsMYd+eCQAfQ5ZqNc2AEz+PaaL4Tf rnLwcBEsH15AD1CxNXxlAH9b+KHv2FUhbkx9e47ynv/TnemkAghVbjnSHl8AjJo40EiI fJYA== X-Gm-Message-State: AG10YOTIW3xukhnLlSIuEovj41Mufpqg302zMhikqSxQvkQwThhpSe5fIG4w68CoBrrYpnE9c0SQ94cGnnEReA== MIME-Version: 1.0 X-Received: by 10.25.85.20 with SMTP id j20mr1368205lfb.131.1454520759655; Wed, 03 Feb 2016 09:32:39 -0800 (PST) Received: by 10.112.200.167 with HTTP; Wed, 3 Feb 2016 09:32:39 -0800 (PST) In-Reply-To: <20160203.180615.336308990853092641.mbj@tail-f.com> References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> <20160203.180615.336308990853092641.mbj@tail-f.com> Date: Wed, 3 Feb 2016 09:32:39 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1141c53232bad1052ae10101 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Where can I insert new YANG substatements? 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, 03 Feb 2016 17:32:43 -0000 --001a1141c53232bad1052ae10101 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund wrote: > Hi, > > William Ivory wrote: > > Hi, > > > > My colleagues and I are looking for clarification of the last point in > > Section 10 of YANG 1.0: > > > > ' In statements that have any data definition statements as > > substatements, those data definition substatements MUST NOT be > > reordered.' > > > > We understand that existing statements must not be reordered in a new > > revision of a YANG module, but we're not clear if new statements may > > be inserted between existing statements, or must always come at the > > 'end' of a list or container definition. > > They can be inserted anywhere. > > As Lada pointed out, this should be clarified in 6020bis. I will do: > > OLD: > > In statements that have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered. > > NEW: > > In statements that have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered. If new data definition statements are added, they can be > added anywhere between these substatement. > > > This is not very good. You should explain exactly what interoperability is lost if a data-def-stmt changes relative order from 1 release to the next. If it is a MUST NOT, then this should obvious. Given that list keys MUST be encoded first, and XML and JSON allow reordering anyway, it is a completely mystery to me why this CLR exists at all. (BTW, it has no affect at all on default-stmt, bit-stmt, or enum-stmt, the only 3 YANG statements where schema-order is actually relevant). Andy > > A specific example we're > > concerned with is where a grouping is used, and then later that > > grouping has an extra element added, but the new node could also be > > added directly. Eg: > > > > Container foo { > > Leaf A > > Uses grouping B; > > Leaf C > > Leaf D > > } > > > > Is it valid in a new revision of the module to do the following, or > > must the order be A, B, C, D, E? What if grouping B has gained a new > > statement? > > > > Container foo { > > Leaf A > > Uses grouping B; > > Leaf C > > Leaf E < ---- ADDED > > Leaf D > > } > > This is valid. > > > /martin > > > > > > Thanks, > > > > William > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1141c53232bad1052ae10101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Hi,

William Ivory <wivory@Brocade.com> wrote:
> Hi,
>
> My colleagues and I are looking for clarification of the last point in=
> Section 10 of YANG 1.0:
>
> '=C2=A0 =C2=A0In statements that have any data definition statemen= ts as
>=C2=A0 =C2=A0 substatements, those data definition substatements MUST N= OT be
>=C2=A0 =C2=A0 reordered.'
>
> We understand that existing statements must not be reordered in a new<= br> > revision of a YANG module, but we're not clear if new statements m= ay
> be inserted between existing statements, or must always come at the > 'end' of a list or container definition.

They can be inserted anywhere.

As Lada pointed out, this should be clarified in 6020bis.=C2=A0 I will do:<= br>
OLD:

=C2=A0 In statements that have any data definition statements as
=C2=A0 substatements, those data definition substatements MUST NOT be
=C2=A0 reordered.

NEW:

=C2=A0 In statements that have any data definition statements as
=C2=A0 substatements, those data definition substatements MUST NOT be
=C2=A0 reordered.=C2=A0 If new data definition statements are added, they c= an be
=C2=A0 added anywhere between these substatement.




This is not very good.<= /div>
You should explain exactly what interoperability is lost if a dat= a-def-stmt
changes relative order from 1 release to the next.=C2= =A0 If it is a MUST NOT,
then this should obvious.=C2=A0 Given th= at list keys MUST be encoded first,
and XML and JSON allow reorde= ring anyway, it is a completely
mystery to me why this CLR exists= at all.

(BTW, it has no affect at all on default-= stmt, bit-stmt, or enum-stmt,
the only 3 YANG statements where sc= hema-order is actually relevant).


A= ndy

=C2=A0
> A specific example we're
> concerned with is where a grouping is used, and then later that
> grouping has an extra element added, but the new node could also be > added directly.=C2=A0 Eg:
>
> Container foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Uses grouping B;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf D
> }
>
> Is it valid in a new revision of the module to do the following, or > must the order be A, B, C, D, E?=C2=A0 What if grouping B has gained a= new
> statement?
>
> Container foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Uses grouping B;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf E < ---- ADDED
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Leaf D
> }

This is valid.


/martin


>
> Thanks,
>
> William
>
>

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

--001a1141c53232bad1052ae10101-- From nobody Wed Feb 3 10:42:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859A1B2B02 for ; Wed, 3 Feb 2016 10:42:55 -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, RP_MATCHES_RCVD=-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 e-MlAF5nPu1H for ; Wed, 3 Feb 2016 10:42:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2FC1B2AE9 for ; Wed, 3 Feb 2016 10:42:51 -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 424B61AE018C; Wed, 3 Feb 2016 19:42:49 +0100 (CET) Date: Wed, 03 Feb 2016 19:45:51 +0100 (CET) Message-Id: <20160203.194551.109558520703434579.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <0504bc5b25454d8e93c6906b179fc1af@EMEAWP-EXMB12.corp.brocade.com> <20160203.180615.336308990853092641.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] Where can I insert new YANG substatements? 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, 03 Feb 2016 18:42:55 -0000 Andy Bierman wrote: > On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund wrote: > > > Hi, > > > > William Ivory wrote: > > > Hi, > > > > > > My colleagues and I are looking for clarification of the last point in > > > Section 10 of YANG 1.0: > > > > > > ' In statements that have any data definition statements as > > > substatements, those data definition substatements MUST NOT be > > > reordered.' > > > > > > We understand that existing statements must not be reordered in a new > > > revision of a YANG module, but we're not clear if new statements may > > > be inserted between existing statements, or must always come at the > > > 'end' of a list or container definition. > > > > They can be inserted anywhere. > > > > As Lada pointed out, this should be clarified in 6020bis. I will do: > > > > OLD: > > > > In statements that have any data definition statements as > > substatements, those data definition substatements MUST NOT be > > reordered. > > > > NEW: > > > > In statements that have any data definition statements as > > substatements, those data definition substatements MUST NOT be > > reordered. If new data definition statements are added, they can be > > added anywhere between these substatement. > > > > > > > > This is not very good. > You should explain exactly what interoperability is lost if a data-def-stmt > changes relative order from 1 release to the next. Note that this how YANG 1.0 works. The reason for this rule is that the order does matter for rpc input/output - they are encoded in XML in the order they are defined. The rule could be limited to input/output, but groupings might be used, so it would have to be input/output and groupings. /martin > If it is a MUST NOT, > then this should obvious. Given that list keys MUST be encoded first, > and XML and JSON allow reordering anyway, it is a completely > mystery to me why this CLR exists at all. > > (BTW, it has no affect at all on default-stmt, bit-stmt, or enum-stmt, > the only 3 YANG statements where schema-order is actually relevant). > > > Andy > > > > > > A specific example we're > > > concerned with is where a grouping is used, and then later that > > > grouping has an extra element added, but the new node could also be > > > added directly. Eg: > > > > > > Container foo { > > > Leaf A > > > Uses grouping B; > > > Leaf C > > > Leaf D > > > } > > > > > > Is it valid in a new revision of the module to do the following, or > > > must the order be A, B, C, D, E? What if grouping B has gained a new > > > statement? > > > > > > Container foo { > > > Leaf A > > > Uses grouping B; > > > Leaf C > > > Leaf E < ---- ADDED > > > Leaf D > > > } > > > > This is valid. > > > > > > /martin > > > > > > > > > > Thanks, > > > > > > William > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Feb 3 10:52:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345661B2B0D; Wed, 3 Feb 2016 10:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 v6OVwxFzwHfD; Wed, 3 Feb 2016 10:52:19 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 67AFC1B2B05; Wed, 3 Feb 2016 10:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454525524; bh=a8NdzN4xGLr2jvZe78ydHmZwKLYjpLAR4x28lCw2GKA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EPW1hYahoGxsST7Zm40kFdP/RW+LPRC3A9mTxxJOktAWUZv0hE4CEGpR8a/HSpJn+ IaautMSzqfGZ/RxDzcdUY11rDTIbibw8Wnn6wGnde8QeYkCUaDsFQ/JuPueE7/qSXq yKq5dHqZdqhrGmziBWin2Og5LZF31wKmvBdeokcM= 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.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <1E9CAE8F-14EE-4759-8463-9E0D687D597B@gmail.com> Date: Wed, 3 Feb 2016 13:52:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C8E5C04-0B26-40BD-950A-9A31381A9267@lucidvision.com> References: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> <1E9CAE8F-14EE-4759-8463-9E0D687D597B@gmail.com> To: Dean Bogdanovic X-Mailer: Apple Mail (2.3112) 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 264, in=3210, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" , NETMOD Working Group Subject: Re: [netmod] draft-ietf-netmod-acl-model status 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, 03 Feb 2016 18:52:21 -0000 Will your model require any updates once 1.1 is ratified? We = don=92t want to predicate having a bunch of models move forward on the = 1.1 work moving forward.=20 =97Tom > On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic = wrote: >=20 > Tom, >=20 > We will publish ACL model requiring YANG 1.1 as per discussion on the = list >=20 > Dean >=20 >> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang = wrote: >>=20 >> Tom, >>=20 >> We discussed the review comments in the working group in offline = meeting. >> Will publish a new draft to address comments. Thanks, >>=20 >> Lisa >>=20 >> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas" >> wrote: >>=20 >>>=20 >>> ACL Doc Authors: >>>=20 >>> What is your status and plan to address the numerous technical = comments >>> that have arisen since the WG LC? >>> I know there are for example, numerous detailed comments from = Juergen and >>> I think Elliot Lear posted some too. >>>=20 >>> =8BTom >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 From nobody Wed Feb 3 10:57:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF671B2B13; Wed, 3 Feb 2016 10:57:15 -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 IGmxCyWhmhp6; Wed, 3 Feb 2016 10:57:13 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 1FD0D1B2B11; Wed, 3 Feb 2016 10:57:13 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id p63so84679073wmp.1; Wed, 03 Feb 2016 10:57:13 -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=pkALSRSmvsdC3YkDgIpjpP0Oh5FiE2Bni6b6VmBbHUs=; b=Wc2oMR7V/JnhDuQkVbP+8RCrgsjPx/HddNT5znIrVWcVjRDp5f9eT4Wp3PmXJbKOkG 1Szb4Xt2PGIqMIX46cteRi2J/lD0SWLZ1OA1XuM0F1c0CmHSfe3nKwoMOam7qCjHB1EB 9tsWV8NiQ53lIlYjnQcfsjRvlJe9PidnLvWiva363uqxXLlb0M230r6sdfxYuM2jX8/8 qv1s3VJ2fibRzZKHAaqRqjgZxaS+dl28qZnpGHjYF058gfpv8GOE3vNQK/KLk4e+fEHn ReOPsa2W5xXJZWSnFdf5mhW5Aer2JleTrBaTPoQMN06P5yBAu+LUPU8MrNv8+gpZPkPp vdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pkALSRSmvsdC3YkDgIpjpP0Oh5FiE2Bni6b6VmBbHUs=; b=lxvh5/gDjcBK0WCUtm2joJRnUKbVJR4PTZk7Pd1eb9xxww6We3/TI8HrOulnUOYMBQ hV0Q7fFC+HEzd1g2UmxhcSHx/mfcuR8UC0eB48AHerNahFtuKZByujhP+shIBmg79tvt CwR0JxD5SFDriGEFO2EGuneaK6iefKKPvoZW3suQDHdf8uYjVrk/XOXmnW0OF35CG6mv o5XBddVN11qhaXmIclcSCf7FB4KPMVEXsHNoV8ek0/83UIDViKXClaSSLnRTqMgudttS qPJJ6q1FNJctG6UULlU9aLfGAD8/CnQcoqBvcvVoDTveEXwk+YDErTLjUpWe/tX7zvSb 3F/Q== X-Gm-Message-State: AG10YOSPn4Lx+U7OYd95c26b0GKYoy/RMsUKLbgkZPY7/ZEbOCKGRXvwYXBlZOVfCh+A3w== X-Received: by 10.195.11.100 with SMTP id eh4mr3834835wjd.83.1454525831602; Wed, 03 Feb 2016 10:57:11 -0800 (PST) Received: from [192.168.254.183] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id s8sm7790901wje.35.2016.02.03.10.57.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Feb 2016 10:57:11 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <6C8E5C04-0B26-40BD-950A-9A31381A9267@lucidvision.com> Date: Wed, 3 Feb 2016 19:57:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FCAD8C4-A5B7-4EE2-8C0B-09208ED73A2A@gmail.com> References: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> <1E9CAE8F-14EE-4759-8463-9E0D687D597B@gmail.com> <6C8E5C04-0B26-40BD-950A-9A31381A9267@lucidvision.com> To: Nadeau Thomas X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" , NETMOD Working Group Subject: Re: [netmod] draft-ietf-netmod-acl-model status 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, 03 Feb 2016 18:57:15 -0000 Tom, One mailing list suggestion was using yang 1.1 construct. If we do it = without that suggestion, then the model doesn=92t require update, but it = is better with this suggestion Dean > On Feb 3, 2016, at 7:52 PM, Nadeau Thomas = wrote: >=20 >=20 > Will your model require any updates once 1.1 is ratified? We = don=92t want to predicate having a bunch of models move forward on the = 1.1 work moving forward.=20 >=20 > =97Tom >=20 >=20 >> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic = wrote: >>=20 >> Tom, >>=20 >> We will publish ACL model requiring YANG 1.1 as per discussion on the = list >>=20 >> Dean >>=20 >>> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang = wrote: >>>=20 >>> Tom, >>>=20 >>> We discussed the review comments in the working group in offline = meeting. >>> Will publish a new draft to address comments. Thanks, >>>=20 >>> Lisa >>>=20 >>> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas" >>> = wrote: >>>=20 >>>>=20 >>>> ACL Doc Authors: >>>>=20 >>>> What is your status and plan to address the numerous technical = comments >>>> that have arisen since the WG LC? >>>> I know there are for example, numerous detailed comments from = Juergen and >>>> I think Elliot Lear posted some too. >>>>=20 >>>> =8BTom >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >=20 From nobody Wed Feb 3 11:04:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F861B2B4A; Wed, 3 Feb 2016 11:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 RSnUNFOLvdyU; Wed, 3 Feb 2016 11:04:10 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 D5C5B1B2B49; Wed, 3 Feb 2016 11:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454526236; bh=ns7FxyDSCSj+LkiU4cOvFu+bqWTtXUNEVp4FDr8p170=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=L4kN41kKz7hEcGtxFbNNg9PfehY+EPjx0FH3Ri29ZxSL4F0hO+QV8DzKupGHOQuAB yHGVtDE6z1aqoziOc7udf970+SHUfRTSaMDackpUTq0UM15XzQcHXQGKvvB2FUhZdW D6ikZQxeoCw/vCOkBZvOPx2OKdh94jpCt1x/5AEs= 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.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <5FCAD8C4-A5B7-4EE2-8C0B-09208ED73A2A@gmail.com> Date: Wed, 3 Feb 2016 14:04:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <484999C4-CCB1-467B-BE09-05E0EBA41906@lucidvision.com> References: <06680F3C-00B0-48D4-8989-1C5436DC3746@lucidvision.com> <1E9CAE8F-14EE-4759-8463-9E0D687D597B@gmail.com> <6C8E5C04-0B26-40BD-950A-9A31381A9267@lucidvision.com> <5FCAD8C4-A5B7-4EE2-8C0B-09208ED73A2A@gmail.com> To: Dean Bogdanovic X-Mailer: Apple Mail (2.3112) 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=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 264, in=3212, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" , NETMOD Working Group Subject: Re: [netmod] draft-ietf-netmod-acl-model status 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, 03 Feb 2016 19:04:12 -0000 I don=92t think we need to block on that. The 1.1 drafts are = nearly done and ready to go according to Juergen, so we shouldn=92t = wait. If something happens to change that causes something to break = compilation-wise, that is easily fixed in the edit stages. Also, since = your document references those, it cannot be progressed ahead of them in = the editor process. =97Tom > On Feb 3, 2016:1:57 PM, at 1:57 PM, Dean Bogdanovic = wrote: >=20 > Tom, >=20 > One mailing list suggestion was using yang 1.1 construct. If we do it = without that suggestion, then the model doesn=92t require update, but it = is better with this suggestion >=20 > Dean >=20 >> On Feb 3, 2016, at 7:52 PM, Nadeau Thomas = wrote: >>=20 >>=20 >> Will your model require any updates once 1.1 is ratified? We = don=92t want to predicate having a bunch of models move forward on the = 1.1 work moving forward.=20 >>=20 >> =97Tom >>=20 >>=20 >>> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic = wrote: >>>=20 >>> Tom, >>>=20 >>> We will publish ACL model requiring YANG 1.1 as per discussion on = the list >>>=20 >>> Dean >>>=20 >>>> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang = wrote: >>>>=20 >>>> Tom, >>>>=20 >>>> We discussed the review comments in the working group in offline = meeting. >>>> Will publish a new draft to address comments. Thanks, >>>>=20 >>>> Lisa >>>>=20 >>>> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas" >>>> = wrote: >>>>=20 >>>>>=20 >>>>> ACL Doc Authors: >>>>>=20 >>>>> What is your status and plan to address the numerous technical = comments >>>>> that have arisen since the WG LC? >>>>> I know there are for example, numerous detailed comments from = Juergen and >>>>> I think Elliot Lear posted some too. >>>>>=20 >>>>> =8BTom >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Feb 3 11:27:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1A1B2BA4 for ; Wed, 3 Feb 2016 11:27:24 -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 QEw2CpHL74kO for ; Wed, 3 Feb 2016 11:27:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80EC1B2BA6 for ; Wed, 3 Feb 2016 11:27:21 -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.396.15; Wed, 3 Feb 2016 19:27:20 +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.0396.020; Wed, 3 Feb 2016 19:27:20 +0000 From: Kent Watsen To: Robert Wilton Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyNt/rQUwS4I0uR3EZ/4LXn2J8ZRHcAgAEYO4CAAAVugA== Date: Wed, 3 Feb 2016 19:27:20 +0000 Message-ID: <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> In-Reply-To: <56B209B9.2050504@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: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:A407huqqXEfqOe1J+6d+rNBX5utJ7fioNFb3ez/1MrMa8UqPNdgF3WyaPrYbW09NQrwPPFeTnyivv4uYuHr5ON+yXaEkxPfKf6VAcARbxDh2JZDzydiUW6I4+DT0su1oHMV9VbWi+umHmaAHgdX5Dw==; 24:GrWNZpCdjLhfaffL12QDCed0nJLVpm5nZURk1XSn20iQZf43ZnR8vg6ULnIPbb7/JLDU5SRnZR00nLXkmZuJjCFnLmrjuHHilboev0GVg60= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-ms-office365-filtering-correlation-id: 32ba6606-b71d-4516-1bf7-08d32cd008f3 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)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(479174004)(24454002)(2906002)(4326007)(66066001)(19580395003)(3846002)(586003)(19580405001)(102836003)(6116002)(82746002)(87936001)(40100003)(86362001)(189998001)(122556002)(10400500002)(5004730100002)(99286002)(106116001)(83716003)(5002640100001)(54356999)(15975445007)(33656002)(1220700001)(36756003)(5001960100002)(5008740100001)(92566002)(1096002)(50986999)(77096005)(2950100001)(11100500001)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4B30DC5DA1309041892F045C5F9DFCDF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 19:27:20.3091 (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 WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 19:27:24 -0000 DQpJIHdhcyBsZWQgdG8gYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IHNldCBvZiBkcmFmdHMgc3Vi c3VtZSBkcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQuICBJZiB0aGF04oCZcyBub3QgdHJ1ZSwgdGhl biBhYnNvbHV0ZWx5IHRoZXJlIHNob3VsZCBiZSBhIHNsb3QgZm9yIHRoYXQgZHJhZnQgdG8gYmUg ZGlzY3Vzc2VkIGFzIHdlbGwuICBQbGVhc2UgYWR2aXNlLg0KDQpLZW50DQoNCg0KDQoNCg0KDQpP biAyLzMvMTYsIDk6MDcgQU0sICJSb2JlcnQgV2lsdG9uIiA8cndpbHRvbkBjaXNjby5jb20+IHdy b3RlOg0KDQo+SGkgS2VudCwNCj4NCj5UaGVyZSBpcyBhbHNvIGFub3RoZXIgWWFuZyBNb3VudCBy ZWxhdGVkIGRyYWZ0OiBkcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQtMDMNCj4NCj5Ob3csIHRoaXMg ZHJhZnQgZG9lc24ndCBkaXJlY3RseSBhZGRyZXNzIHRoZSBSVEcgRFQgQXJjaCB0ZWFtIHVzZS1j YXNlLCANCj5hbmQgc2VlbXMgdG8gY292ZXIgdHdvIG1vcmUgY29tcGxleCBwcm9ibGVtIHNjZW5h cmlvcyAocmVtb3RlIG1vdW50IGFuZCANCj5hbGlhcyBtb3VudCksIGJ1dCB0aGVzZSBkbyBhcHBl YXIgdG8gYmUgYSB2YWxpZCBtb3VudCB1c2UgY2FzZXMgKGUuZy4gSSANCj50aGluayB0aGF0IGl0 IGlzIHVzZWQgYnkgT3BlbkRheWxpZ2h0IFNETiBjb250cm9sbGVyKSwgYW5kIEkga25vdyB0aGF0 IA0KPnRoZXJlIGlzIGF0IGxlYXN0IG9uZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0K Pg0KPlNvLCBJIHdhbnQgdG8gZWNobyBFcmljIFZvaXQncyBjb21tZW50cyB0aGF0IGl0IHdvdWxk IGJlIGdvb2QgaWYgDQo+d2hhdGV2ZXIgYmFzaWMgWUFORyBtb3VudCBkcmFmdCB3ZSBjb252ZXJn ZSBvbiBpcyBhYmxlIHRvIGJlIGNsZWFubHkgDQo+ZXh0ZW5kZWQgdG8gY292ZXIgdGhlIG1vcmUg Y29tcGxleCBtb3VudCBzY2VuYXJpb3MuDQo+DQo+QXMgc3VjaCwgaWYgQWxleCBDbGVtbSBvciBF cmljIFZvaXQgYXJlIHdpbGxpbmcsIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCANCj5iZSB1c2VmdWwg aWYgb25lIG9mIHRoZW0gY291bGQgY29tbWVudCBvbiBob3cgZmVhc2libGUgaXQgaXMgdG8gZXh0 ZW5kIA0KPmVpdGhlciBuZXRtb2Qtc3RydWN0dWFsLW1vdW50IG9yIG5ldG1vZC15c2RsIHRvIGNv dmVyIHRoZSByZW1vdGUgbW91bnQgDQo+YW5kIGFsaWFzIG1vdW50IHNjZW5hcmlvcyBkZXNjcmli ZWQgaW4gZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50LTAzLiAgDQo+SGVuY2UsIGlmIHRoZXkgYWdy ZWUsIGRvIHlvdSB0aGluayB0aGF0IHlvdSB3b3VsZCBiZSBhYmxlIHRvIGFkZCBhIDE1IA0KPm1p biBzbG90IHRvIHRoZSBhZ2VuZGEgdG8gY292ZXIgdGhpcyBwbGVhc2U/DQo+DQo+VGhhbmtzLA0K PlJvYg0KPg0KPg0KPk9uIDAzLzAyLzIwMTYgMDI6MjQsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPj4g W0NoYWlyIGhhdCBvbl0NCj4+DQo+PiBHaXZlbiB0aGUgbnVtYmVyIG9mIGNvbXBldGluZy9jb21w bGVtZW50aW5nIGRyYWZ0cyBpbnZvbHZlZCwgYW5kIHRoZSBnZW5lcmFsIGxhY2sgb2YgZGlzY3Vz c2lvbiBvbiBhbnkgb2YgdGhlbSwgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBtaWdodCBiZSBh biBleHBlZGllbnQgd2F5IHRvIHByb2NlZWQuICBJbiBmYWlybmVzcywgd2Uga25vdyB0aGF0IHRo ZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiwgYnV0IGl0IGhhc27igJl0IGJlZW4gcGlja2Vk IHVwIHlldCBpbiBhIGJpZyB3YXksIGFuZCBub3cgTG91IGhhcyBhbiB1cGRhdGVkIGRyYWZ0Lg0K Pj4NCj4+IFRoZSBjaGFpcnMgZGlzY3Vzc2VkIG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBhIGNv dXBsZSB3ZWVrcyBmcm9tIG5vdywgcGVyaGFwcyBUaHVyc2RheSBGZWIgMTggc3RhcnRpbmcgYXQg MTBhbSBFU1Q/ICAgSSdtIHRoaW5raW5nIGFib3V0IHRoaXMgc2xvdCBvbmx5IHNpbmNlIGl0IHdv cmtlZCBmb3IgdXMgZm9yIHByZXZpb3VzbHkuICBJcyB0aGlzIGEgZ29vZCB0aW1lIHNsb3Q/ICBJ IGFzc3VtZSB0byBzY2hlZHVsZSBmb3IgMiBob3Vycywgd2l0aCBhIHBsYW4gdG8gZW5kIGVhcmx5 IGlmIG5lZWRlZCAtIG1ha2VzIHNlbnNlPyAgICAgV2UgYWxzbyBuZWVkIHRvIHB1dCB0b2dldGhl ciBhIHByb3BlciBhZ2VuZGEsIHBlcmhhcHMgdGhlIGZvbGxvd2luZz8NCj4+DQo+PiAgICAxMCBt aW46IFJURyBEVCBZQU5HIEFyY2ggdGVhbSB1c2UtY2FzZSBzdW1tYXJ5DQo+PiAgICAyMCBtaW46 IGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwNCj4+ICAgIDIwIG1pbjogZHJhZnQt bGhvdGthLW5ldG1vZC15c2RsDQo+PiAgICAyMCBtaW46IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qt c3RydWN0dXJhbC1tb3VudA0KPj4gICAgNTAgbWluOiBnZW5lcmFsIGRpc2N1c3Npb24gb3IgZW5k IGVhcmx5DQo+Pg0KPj4NCj4+IFdlIGhvcGUgdG8gc2NoZWR1bGUgdGhlIG1lZXRpbmcgaXRzZWxm IHRvbW9ycm93IG9yIHRoZSBuZXh0IGRheSwgc28gcGxlYXNlIHJlc3BvbmQgcXVpY2tseSB0byB0 aGlzIGVtYWlsIGlmIHBvc3NpYmxlLg0KPj4NCj4+IFRoYW5rcywNCj4+IEtlbnQgYW5kIFRvbQ0K Pj4NCj4+DQo+Pg0KPj4NCj4+IE9uIDIvMi8xNiwgMjowNCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgTG91IEJlcmdlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVy Z2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+DQo+Pj4gSSB0aG91Z2h0IGl0IHdvdWxkIGJlIHdvcnRo IHN1bW1hcml6aW5nIHdoYXQgd2UncmUgbG9va2luZyBmb3IgaW4gb3VyDQo+Pj4gZHJhZnQsIGRy YWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDIgKG5vdGUgbmV3IHZlcnNpb24gaW4g Y2FzZQ0KPj4+IHlvdSBtaXNzZWQgaXQpIHdpdGggcmVzcGVjdCB0byB0aGUgZHJhZnQtbGhvdGth LW5ldG1vZC15c2RsIGFuZA0KPj4+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3RydWN0dXJhbC1t b3VudCBkcmFmdHMuIFRoaXMgaXMganVzdCBteSB2aWV3LCBzbw0KPj4+IG15IGNvLWF1dGhvcnMg bWF5IHdpc2ggdG8gY2hpbWUgaW4gYW5kIGNvcnJlY3QgbWUuDQo+Pj4NCj4+PiBJJ2QgYmUgaW50 ZXJlc3RlZCBpbiBoZWFyaW5nIGZyb20gdGhlIGF1dGhvcnMgb2YgWVNETCBhbmQNCj4+PiBzdHJ1 Y3R1cmFsLW1vdW50LCBvciBhbnlvbmUgZWxzZSBmb3IgdGhhdCBtYXR0ZXIsIG9uIGhvdyB0aGV5 IHNlZSB0bw0KPj4+IGJlc3QgbWVldCB0aGVzZSBuZWVkcy4NCj4+Pg0KPj4+IEhlcmUncyB3aGF0 IEkgdGhpbmsgb3VyIGRyYWZ0IG5lZWRzOg0KPj4+DQo+Pj4gMS4gdGhhdCB0aGVyZSBiZSBhIG1l Y2hhbmlzbSB0aGF0IGFsbG93cyB0aGUgaW5jb3Jwb3JhdGlvbiAob3INCj4+PiAgICAnbW91bnRp bmcnKSBvZiB0aGUgZGF0YSBtb2RlbCBkZWZpbmVkIGJ5IG9uZSB0b3AtbGV2ZWwgbW9kdWxlDQo+ Pj4gICAgd2l0aGluIGFub3RoZXIgbW9kdWxlLg0KPj4+DQo+Pj4gICAgVGhlIGltcGxpY2F0aW9u IGhlcmUgaXMgdGhhdCB3aGVuIGluZm9ybWF0aW9uIGlzIGluc3RhbnRpYXRlZA0KPj4+ICAgIGZv ciB0aGUgcGFyZW50IG1vZGVsIGl0IGlzIGFsc28gaW5zdGFudGlhdGVkIGZvciB0aGUNCj4+PiAg ICBpbmNvcnBvcmF0ZWQvbW91bnRlZCBtb2RlbC4gSW4gb3VyIGNhc2Ugd2UgZXhwZWN0IHRvIGRv IHRoaXMgb24NCj4+PiAgICBsaXN0IGVsZW1lbnQgY3JlYXRpb24uIEJvdGggc29sdXRpb25zIGRy YWZ0cyBjb3ZlciB0aGUgcGF0aA0KPj4+ICAgIGltcGxpY2F0aW9ucywgc28gdGhlc2UgYXJlIG5v dCByZXBlYXRlZCBoZXJlLg0KPj4+DQo+Pj4gMi4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBp ZGVudGlmaWNhdGlvbiBvZiBzcGVjaWZpYyBtb2R1bGVzIHRvDQo+Pj4gICAgYmUgaW5jb3Jwb3Jh dGVkL21vdW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0DQo+Pj4g ICAgbm8gYWRkaXRpb25hbCBtb2R1bGUgaXMgbmVlZGVkIHRvIHN1cHBvcnQgMS4gVGhpcyBkb2Vz bid0DQo+Pj4gICAgcHJlY2x1ZGUgZGVmaW5pdGlvbiBvZiBzdWNoIGEgbW9kdWxlLg0KPj4+DQo+ Pj4gMy4gdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvdyBmb3IgYSBzZXJ2ZXIgdG8gY29udHJvbCAo YW5kDQo+Pj4gICAgaWRlbnRpZnkpIHdoaWNoIG1vZHVsZXMgYXJlIGluY29ycG9yYXRlZC9tb3Vu dGVkLiAoc2VlIFNlY3Rpb24NCj4+PiAgICAzIExORSBpbiBvdXIgZHJhZnQgZm9yIGFuIGVudmlz aW9uZWQgdXNhZ2UuKQ0KPj4+DQo+Pj4gNC4gdGhhdCBhbGwgY2FwYWJpbGl0aWVzIHRoYXQgZXhp c3Qgd2l0aCB0aGUgbW91bnRlZCBtb2R1bGUgYXJlDQo+Pj4gICAgYXZhaWxhYmxlIGUuZy4gUlBD IG9wZXJhdGlvbnMgYW5kIG5vdGlmaWNhdGlvbnMuDQo+Pj4NCj4+PiA1LiB3aGlsZSBvdXIgcHJp bWFyeSByZXF1aXJlbWVudCBpcyBmb3IgJ21vdW50aW5nJyBvZiB0b3AgbGV2ZWwNCj4+PiAgICBt b2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNvIGJlIHVzZWZ1bC4gKERUIG5v dCBkcmFmdA0KPj4+ICAgIGRyaXZlbi4pDQo+Pj4NCj4+PiBXZSBtYWtlIHVzZSBvZiB0aGUgYWJv dmUgaW4gc2VjdGlvbnMgMyBhbmQgNCBvZiBydGd3Zy1kZXZpY2UtbW9kZWwuICBXZQ0KPj4+IHNl ZSBoYXZpbmcgYSBzb2x1dGlvbiBhcyBjcml0aWNhbCBmb3IgdGhlIHNpbXBsaWZpY2F0aW9ucy9m bGV4aWJpbGl0eQ0KPj4+IHJlcHJlc2VudGVkIGluIHRoZSAtMDIgdmVyc2lvbiBvZiBvdXIgZHJh ZnQgdnMgdGhlIC0wMyByZXYuICBXZSBkb24ndA0KPj4+IHNlZSB3aXRoZXIgc29sdXRpb24gZHJh ZnQgYXMgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQgYW5kIGp1c3QgaG9wZSBmb3IgYQ0KPj4+IHN0 YW5kYXJkIHNvbHV0aW9uIGFzIHNvb24gYXMgcG9zc2libGUuICAoYSBkcmFmdC1pZXRmLW5ldG1v ZCBzb2x1dGlvbnMNCj4+PiBkcmFmdCBvbiB0aGUgdG9waWMgYnkgQkEgd291bGQgYmUgZmFudGFz dGljIGdpdmVuIHRoZSBpbXBhY3Qgb24gcm91dGluZw0KPj4+IGFyZWEgLS0gZXZlbiBpZiBpdCBo YWQgdG8gZG9jdW1lbnQgdHdvIHZhcmlhdGlvbnMgLyBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMuKQ0K Pj4+DQo+Pj4gQWdhaW4sIHRoaXMgaXMganVzdCBteSBvcGluaW9uIGFuZCBteSBjb2F1dGhvcnMg b3Igb3RoZXJzIG9uIHRoZSBydGcNCj4+PiBhcmVhIHlhbmcgRFQgbWF5IGNob29zZSB0byBjaGlt ZSBpbi4NCj4+Pg0KPj4+IExvdQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K From nobody Wed Feb 3 12:48:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5F81B2C04 for ; Wed, 3 Feb 2016 12:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 tPXCF8VGaAXa for ; Wed, 3 Feb 2016 12:48:21 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 2AABC1B2C01 for ; Wed, 3 Feb 2016 12:48:21 -0800 (PST) Received: (qmail 17516 invoked by uid 0); 3 Feb 2016 20:48:19 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 3 Feb 2016 20:48:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id DwoD1s01S2SSUrH01woGBy; Wed, 03 Feb 2016 13:48:19 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=tgSTpmU_1EcA:10 a=jFJIQSaiL_oA:10 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=X_OgpN5mWXBjQk8Gd-0A:9 a=VZtcZlHW8vvbFgFO:21 a=T9qCjcZZUG5h85kH:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=plqwPcSwluStZC3KBhATDgOn+U+pGOA380JrDh2/sxY=; b=Aj1IensZE5IkiM3XZNXZvYH8eHGkI5btsgW1wuS/h2Ugg9MZiZdBfrfgJ1IjmjWVeT3V5j4c/tnm05q5WGZiYY+R3s9HluvHGfAT7tTrrhp/24BiRdGJ0sJgXylW7IL9; Received: from [172.58.184.226] (port=62779 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aR4LV-0003ax-Ic; Wed, 03 Feb 2016 13:48:13 -0700 From: Lou Berger To: Kent Watsen , Robert Wilton Date: Wed, 03 Feb 2016 15:48:08 -0500 Message-ID: <152a8e46b40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.58.184.226 authed with lberger@labn.net} Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 20:48:24 -0000 I don't see how draft Clemm addresses our draft's use case. That said, if alex thinks it does - let's hear about it. Alex, Can you look at the mail I sent the other day about our planned usage and see what you think - and let us know what you find? Thanks, Lou On February 3, 2016 2:27:44 PM Kent Watsen wrote: > > I was led to believe that the current set of drafts subsume > draft-clemm-netmod-mount. If that’s not true, then absolutely there should > be a slot for that draft to be discussed as well. Please advise. > > Kent > > > > > > > On 2/3/16, 9:07 AM, "Robert Wilton" wrote: > >>Hi Kent, >> >>There is also another Yang Mount related draft: draft-clemm-netmod-mount-03 >> >>Now, this draft doesn't directly address the RTG DT Arch team use-case, >>and seems to cover two more complex problem scenarios (remote mount and >>alias mount), but these do appear to be a valid mount use cases (e.g. I >>think that it is used by OpenDaylight SDN controller), and I know that >>there is at least one implementation of this draft. >> >>So, I want to echo Eric Voit's comments that it would be good if >>whatever basic YANG mount draft we converge on is able to be cleanly >>extended to cover the more complex mount scenarios. >> >>As such, if Alex Clemm or Eric Voit are willing, I think that it would >>be useful if one of them could comment on how feasible it is to extend >>either netmod-structual-mount or netmod-ysdl to cover the remote mount >>and alias mount scenarios described in draft-clemm-netmod-mount-03. >>Hence, if they agree, do you think that you would be able to add a 15 >>min slot to the agenda to cover this please? >> >>Thanks, >>Rob >> >> >>On 03/02/2016 02:24, Kent Watsen wrote: >>> [Chair hat on] >>> >>> Given the number of competing/complementing drafts involved, and the >>> general lack of discussion on any of them, a virtual interim meeting might >>> be an expedient way to proceed. In fairness, we know that there has been >>> some discussion, but it hasn’t been picked up yet in a big way, and now Lou >>> has an updated draft. >>> >>> The chairs discussed maybe scheduling one for a couple weeks from now, >>> perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this >>> slot only since it worked for us for previously. Is this a good time slot? >>> I assume to schedule for 2 hours, with a plan to end early if needed - >>> makes sense? We also need to put together a proper agenda, perhaps the >>> following? >>> >>> 10 min: RTG DT YANG Arch team use-case summary >>> 20 min: draft-rtgyangdt-rtgwg-device-model >>> 20 min: draft-lhotka-netmod-ysdl >>> 20 min: draft-bjorklund-netmod-structural-mount >>> 50 min: general discussion or end early >>> >>> >>> We hope to schedule the meeting itself tomorrow or the next day, so please >>> respond quickly to this email if possible. >>> >>> Thanks, >>> Kent and Tom >>> >>> >>> >>> >>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>> wrote: >>> >>>> I thought it would be worth summarizing what we're looking for in our >>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case >>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and >>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so >>>> my co-authors may wish to chime in and correct me. >>>> >>>> I'd be interested in hearing from the authors of YSDL and >>>> structural-mount, or anyone else for that matter, on how they see to >>>> best meet these needs. >>>> >>>> Here's what I think our draft needs: >>>> >>>> 1. that there be a mechanism that allows the incorporation (or >>>> 'mounting') of the data model defined by one top-level module >>>> within another module. >>>> >>>> The implication here is that when information is instantiated >>>> for the parent model it is also instantiated for the >>>> incorporated/mounted model. In our case we expect to do this on >>>> list element creation. Both solutions drafts cover the path >>>> implications, so these are not repeated here. >>>> >>>> 2. that this mechanism allow identification of specific modules to >>>> be incorporated/mounted at time of module definition, i.e. that >>>> no additional module is needed to support 1. This doesn't >>>> preclude definition of such a module. >>>> >>>> 3. that this mechanism allow for a server to control (and >>>> identify) which modules are incorporated/mounted. (see Section >>>> 3 LNE in our draft for an envisioned usage.) >>>> >>>> 4. that all capabilities that exist with the mounted module are >>>> available e.g. RPC operations and notifications. >>>> >>>> 5. while our primary requirement is for 'mounting' of top level >>>> modules, mounting of submodules may also be useful. (DT not draft >>>> driven.) >>>> >>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. We >>>> see having a solution as critical for the simplifications/flexibility >>>> represented in the -02 version of our draft vs the -03 rev. We don't >>>> see wither solution draft as significantly different and just hope for a >>>> standard solution as soon as possible. (a draft-ietf-netmod solutions >>>> draft on the topic by BA would be fantastic given the impact on routing >>>> area -- even if it had to document two variations / alternative solutions.) >>>> >>>> Again, this is just my opinion and my coauthors or others on the rtg >>>> area yang DT may choose to chime in. >>>> >>>> Lou >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Feb 3 12:55:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC901B2C82 for ; Wed, 3 Feb 2016 12:55: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, RP_MATCHES_RCVD=-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 0y51yMYDT0d8 for ; Wed, 3 Feb 2016 12:55:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 212E91B2CB7 for ; Wed, 3 Feb 2016 12:55:31 -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 81E2C1AE018C; Wed, 3 Feb 2016 21:55:29 +0100 (CET) Date: Wed, 03 Feb 2016 21:58:32 +0100 (CET) Message-Id: <20160203.215832.1983614023979507581.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> References: <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 03 Feb 2016 20:55:33 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEkg d2FzIGxlZCB0byBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgc2V0IG9mIGRyYWZ0cyBzdWJzdW1l DQo+IGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC4NCg0KVGhlIG1lY2hhbmlzbSBpbiBkcmFmdC1j bGVtbS1uZXRtb2QtbW91bnQgcHJpbWFyaWx5IG1vdW50cyByZW1vdGUNCmRhdGFzdG9yZXMgaW50 byBhIGRhdGFzdG9yZS4NCg0KU3RydWN0dXJhbCBtb3VudCBmb2N1c2VzIG9uIGNvbWJpbmluZyAq c2NoZW1hcyouICBUaGlzIGFwcHJvYWNoIGNhbg0Kc3VwcG9ydCBkaWZmZXJlbnQgaW1wbGVtZW50 YXRpb24gc3RyYXRlZ2llcywgd2hlcmUgcmVtb3RlIG1vdW50aW5nDQpjb3VsZCBiZSBvbmUuICBI b3dldmVyLCB0aGUgc3RydWN0dXJhbCBtb3VudCBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5DQphbnkg c3VjaCBpbXBsZW1lbnRhdGlvbiBzdHJhdGVnaWVzOyB0aGUgaWRlYSB3YXMgdGhhdCBzdWNoIHN0 cmF0ZWdpZXMNCmNvdWxkIGJlIGRlZmluZWQgaW4gc2VwYXJhdGUgZG9jdW1lbnRzICh0aGF0IHdv dWxkIHJlZmVyZW5jZSB0aGUNCnN0cnVjdHVyYWwgbW91bnQgZG9jKS4NCg0KDQovbWFydGluDQog DQo+IElmIHRoYXTigJlzIG5vdCB0cnVlLCB0aGVuIGFic29sdXRlbHkgdGhlcmUNCj4gc2hvdWxk IGJlIGEgc2xvdCBmb3IgdGhhdCBkcmFmdCB0byBiZSBkaXNjdXNzZWQgYXMgd2VsbC4gIFBsZWFz ZQ0KPiBhZHZpc2UuDQo+IA0KPiBLZW50DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IE9uIDIv My8xNiwgOTowNyBBTSwgIlJvYmVydCBXaWx0b24iIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6 DQo+IA0KPiA+SGkgS2VudCwNCj4gPg0KPiA+VGhlcmUgaXMgYWxzbyBhbm90aGVyIFlhbmcgTW91 bnQgcmVsYXRlZCBkcmFmdDoNCj4gPmRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMw0KPiA+DQo+ ID5Ob3csIHRoaXMgZHJhZnQgZG9lc24ndCBkaXJlY3RseSBhZGRyZXNzIHRoZSBSVEcgRFQgQXJj aCB0ZWFtDQo+ID51c2UtY2FzZSwNCj4gPmFuZCBzZWVtcyB0byBjb3ZlciB0d28gbW9yZSBjb21w bGV4IHByb2JsZW0gc2NlbmFyaW9zIChyZW1vdGUgbW91bnQNCj4gPmFuZA0KPiA+YWxpYXMgbW91 bnQpLCBidXQgdGhlc2UgZG8gYXBwZWFyIHRvIGJlIGEgdmFsaWQgbW91bnQgdXNlIGNhc2VzDQo+ ID4oZS5nLiBJDQo+ID50aGluayB0aGF0IGl0IGlzIHVzZWQgYnkgT3BlbkRheWxpZ2h0IFNETiBj b250cm9sbGVyKSwgYW5kIEkga25vdyB0aGF0DQo+ID50aGVyZSBpcyBhdCBsZWFzdCBvbmUgaW1w bGVtZW50YXRpb24gb2YgdGhpcyBkcmFmdC4NCj4gPg0KPiA+U28sIEkgd2FudCB0byBlY2hvIEVy aWMgVm9pdCdzIGNvbW1lbnRzIHRoYXQgaXQgd291bGQgYmUgZ29vZCBpZiANCj4gPndoYXRldmVy IGJhc2ljIFlBTkcgbW91bnQgZHJhZnQgd2UgY29udmVyZ2Ugb24gaXMgYWJsZSB0byBiZSBjbGVh bmx5IA0KPiA+ZXh0ZW5kZWQgdG8gY292ZXIgdGhlIG1vcmUgY29tcGxleCBtb3VudCBzY2VuYXJp b3MuDQo+ID4NCj4gPkFzIHN1Y2gsIGlmIEFsZXggQ2xlbW0gb3IgRXJpYyBWb2l0IGFyZSB3aWxs aW5nLCBJIHRoaW5rIHRoYXQgaXQgd291bGQNCj4gPmJlIHVzZWZ1bCBpZiBvbmUgb2YgdGhlbSBj b3VsZCBjb21tZW50IG9uIGhvdyBmZWFzaWJsZSBpdCBpcyB0byBleHRlbmQNCj4gPmVpdGhlciBu ZXRtb2Qtc3RydWN0dWFsLW1vdW50IG9yIG5ldG1vZC15c2RsIHRvIGNvdmVyIHRoZSByZW1vdGUg bW91bnQNCj4gPmFuZCBhbGlhcyBtb3VudCBzY2VuYXJpb3MgZGVzY3JpYmVkIGluIGRyYWZ0LWNs ZW1tLW5ldG1vZC1tb3VudC0wMy4gIA0KPiA+SGVuY2UsIGlmIHRoZXkgYWdyZWUsIGRvIHlvdSB0 aGluayB0aGF0IHlvdSB3b3VsZCBiZSBhYmxlIHRvIGFkZCBhIDE1IA0KPiA+bWluIHNsb3QgdG8g dGhlIGFnZW5kYSB0byBjb3ZlciB0aGlzIHBsZWFzZT8NCj4gPg0KPiA+VGhhbmtzLA0KPiA+Um9i DQo+ID4NCj4gPg0KPiA+T24gMDMvMDIvMjAxNiAwMjoyNCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ ID4+IFtDaGFpciBoYXQgb25dDQo+ID4+DQo+ID4+IEdpdmVuIHRoZSBudW1iZXIgb2YgY29tcGV0 aW5nL2NvbXBsZW1lbnRpbmcgZHJhZnRzIGludm9sdmVkLCBhbmQgdGhlDQo+ID4+IGdlbmVyYWwg bGFjayBvZiBkaXNjdXNzaW9uIG9uIGFueSBvZiB0aGVtLCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0 aW5nDQo+ID4+IG1pZ2h0IGJlIGFuIGV4cGVkaWVudCB3YXkgdG8gcHJvY2VlZC4gIEluIGZhaXJu ZXNzLCB3ZSBrbm93IHRoYXQgdGhlcmUNCj4gPj4gaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uLCBi dXQgaXQgaGFzbuKAmXQgYmVlbiBwaWNrZWQgdXAgeWV0IGluIGEgYmlnDQo+ID4+IHdheSwgYW5k IG5vdyBMb3UgaGFzIGFuIHVwZGF0ZWQgZHJhZnQuDQo+ID4+DQo+ID4+IFRoZSBjaGFpcnMgZGlz Y3Vzc2VkIG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBhIGNvdXBsZSB3ZWVrcyBmcm9tIG5vdywN Cj4gPj4gcGVyaGFwcyBUaHVyc2RheSBGZWIgMTggc3RhcnRpbmcgYXQgMTBhbSBFU1Q/ICBJJ20g dGhpbmtpbmcgYWJvdXQgdGhpcw0KPiA+PiBzbG90IG9ubHkgc2luY2UgaXQgd29ya2VkIGZvciB1 cyBmb3IgcHJldmlvdXNseS4gIElzIHRoaXMgYSBnb29kIHRpbWUNCj4gPj4gc2xvdD8gIEkgYXNz dW1lIHRvIHNjaGVkdWxlIGZvciAyIGhvdXJzLCB3aXRoIGEgcGxhbiB0byBlbmQgZWFybHkgaWYN Cj4gPj4gbmVlZGVkIC0gbWFrZXMgc2Vuc2U/ICBXZSBhbHNvIG5lZWQgdG8gcHV0IHRvZ2V0aGVy IGEgcHJvcGVyIGFnZW5kYSwNCj4gPj4gcGVyaGFwcyB0aGUgZm9sbG93aW5nPw0KPiA+Pg0KPiA+ PiAgICAxMCBtaW46IFJURyBEVCBZQU5HIEFyY2ggdGVhbSB1c2UtY2FzZSBzdW1tYXJ5DQo+ID4+ ICAgIDIwIG1pbjogZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbA0KPiA+PiAgICAy MCBtaW46IGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbA0KPiA+PiAgICAyMCBtaW46IGRyYWZ0LWJq b3JrbHVuZC1uZXRtb2Qtc3RydWN0dXJhbC1tb3VudA0KPiA+PiAgICA1MCBtaW46IGdlbmVyYWwg ZGlzY3Vzc2lvbiBvciBlbmQgZWFybHkNCj4gPj4NCj4gPj4NCj4gPj4gV2UgaG9wZSB0byBzY2hl ZHVsZSB0aGUgbWVldGluZyBpdHNlbGYgdG9tb3Jyb3cgb3IgdGhlIG5leHQgZGF5LCBzbw0KPiA+ PiBwbGVhc2UgcmVzcG9uZCBxdWlja2x5IHRvIHRoaXMgZW1haWwgaWYgcG9zc2libGUuDQo+ID4+ DQo+ID4+IFRoYW5rcywNCj4gPj4gS2VudCBhbmQgVG9tDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+IE9uIDIvMi8xNiwgMjowNCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91IEJlcmdl ciINCj4gPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxh Ym4ubmV0PiB3cm90ZToNCj4gPj4NCj4gPj4+IEkgdGhvdWdodCBpdCB3b3VsZCBiZSB3b3J0aCBz dW1tYXJpemluZyB3aGF0IHdlJ3JlIGxvb2tpbmcgZm9yIGluIG91cg0KPiA+Pj4gZHJhZnQsIGRy YWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDIgKG5vdGUgbmV3IHZlcnNpb24gaW4g Y2FzZQ0KPiA+Pj4geW91IG1pc3NlZCBpdCkgd2l0aCByZXNwZWN0IHRvIHRoZSBkcmFmdC1saG90 a2EtbmV0bW9kLXlzZGwgYW5kDQo+ID4+PiBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVy YWwtbW91bnQgZHJhZnRzLiBUaGlzIGlzIGp1c3QgbXkgdmlldywNCj4gPj4+IHNvDQo+ID4+PiBt eSBjby1hdXRob3JzIG1heSB3aXNoIHRvIGNoaW1lIGluIGFuZCBjb3JyZWN0IG1lLg0KPiA+Pj4N Cj4gPj4+IEknZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgZnJvbSB0aGUgYXV0aG9ycyBvZiBZ U0RMIGFuZA0KPiA+Pj4gc3RydWN0dXJhbC1tb3VudCwgb3IgYW55b25lIGVsc2UgZm9yIHRoYXQg bWF0dGVyLCBvbiBob3cgdGhleSBzZWUgdG8NCj4gPj4+IGJlc3QgbWVldCB0aGVzZSBuZWVkcy4N Cj4gPj4+DQo+ID4+PiBIZXJlJ3Mgd2hhdCBJIHRoaW5rIG91ciBkcmFmdCBuZWVkczoNCj4gPj4+ DQo+ID4+PiAxLiB0aGF0IHRoZXJlIGJlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHRoZSBpbmNv cnBvcmF0aW9uIChvcg0KPiA+Pj4gICAgJ21vdW50aW5nJykgb2YgdGhlIGRhdGEgbW9kZWwgZGVm aW5lZCBieSBvbmUgdG9wLWxldmVsIG1vZHVsZQ0KPiA+Pj4gICAgd2l0aGluIGFub3RoZXIgbW9k dWxlLg0KPiA+Pj4NCj4gPj4+ICAgIFRoZSBpbXBsaWNhdGlvbiBoZXJlIGlzIHRoYXQgd2hlbiBp bmZvcm1hdGlvbiBpcyBpbnN0YW50aWF0ZWQNCj4gPj4+ICAgIGZvciB0aGUgcGFyZW50IG1vZGVs IGl0IGlzIGFsc28gaW5zdGFudGlhdGVkIGZvciB0aGUNCj4gPj4+ICAgIGluY29ycG9yYXRlZC9t b3VudGVkIG1vZGVsLiBJbiBvdXIgY2FzZSB3ZSBleHBlY3QgdG8gZG8gdGhpcyBvbg0KPiA+Pj4g ICAgbGlzdCBlbGVtZW50IGNyZWF0aW9uLiBCb3RoIHNvbHV0aW9ucyBkcmFmdHMgY292ZXIgdGhl IHBhdGgNCj4gPj4+ICAgIGltcGxpY2F0aW9ucywgc28gdGhlc2UgYXJlIG5vdCByZXBlYXRlZCBo ZXJlLg0KPiA+Pj4NCj4gPj4+IDIuIHRoYXQgdGhpcyBtZWNoYW5pc20gYWxsb3cgaWRlbnRpZmlj YXRpb24gb2Ygc3BlY2lmaWMgbW9kdWxlcyB0bw0KPiA+Pj4gICAgYmUgaW5jb3Jwb3JhdGVkL21v dW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0DQo+ID4+PiAgICBu byBhZGRpdGlvbmFsIG1vZHVsZSBpcyBuZWVkZWQgdG8gc3VwcG9ydCAxLiBUaGlzIGRvZXNuJ3QN Cj4gPj4+ICAgIHByZWNsdWRlIGRlZmluaXRpb24gb2Ygc3VjaCBhIG1vZHVsZS4NCj4gPj4+DQo+ ID4+PiAzLiB0aGF0IHRoaXMgbWVjaGFuaXNtIGFsbG93IGZvciBhIHNlcnZlciB0byBjb250cm9s IChhbmQNCj4gPj4+ICAgIGlkZW50aWZ5KSB3aGljaCBtb2R1bGVzIGFyZSBpbmNvcnBvcmF0ZWQv bW91bnRlZC4gKHNlZSBTZWN0aW9uDQo+ID4+PiAgICAzIExORSBpbiBvdXIgZHJhZnQgZm9yIGFu IGVudmlzaW9uZWQgdXNhZ2UuKQ0KPiA+Pj4NCj4gPj4+IDQuIHRoYXQgYWxsIGNhcGFiaWxpdGll cyB0aGF0IGV4aXN0IHdpdGggdGhlIG1vdW50ZWQgbW9kdWxlIGFyZQ0KPiA+Pj4gICAgYXZhaWxh YmxlIGUuZy4gUlBDIG9wZXJhdGlvbnMgYW5kIG5vdGlmaWNhdGlvbnMuDQo+ID4+Pg0KPiA+Pj4g NS4gd2hpbGUgb3VyIHByaW1hcnkgcmVxdWlyZW1lbnQgaXMgZm9yICdtb3VudGluZycgb2YgdG9w IGxldmVsDQo+ID4+PiAgICBtb2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNv IGJlIHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPiA+Pj4gICAgZHJpdmVuLikNCj4gPj4+DQo+ID4+ PiBXZSBtYWtlIHVzZSBvZiB0aGUgYWJvdmUgaW4gc2VjdGlvbnMgMyBhbmQgNCBvZiBydGd3Zy1k ZXZpY2UtbW9kZWwuDQo+ID4+PiBXZQ0KPiA+Pj4gc2VlIGhhdmluZyBhIHNvbHV0aW9uIGFzIGNy aXRpY2FsIGZvciB0aGUgc2ltcGxpZmljYXRpb25zL2ZsZXhpYmlsaXR5DQo+ID4+PiByZXByZXNl bnRlZCBpbiB0aGUgLTAyIHZlcnNpb24gb2Ygb3VyIGRyYWZ0IHZzIHRoZSAtMDMgcmV2LiAgV2Ug ZG9uJ3QNCj4gPj4+IHNlZSB3aXRoZXIgc29sdXRpb24gZHJhZnQgYXMgc2lnbmlmaWNhbnRseSBk aWZmZXJlbnQgYW5kIGp1c3QgaG9wZSBmb3INCj4gPj4+IGENCj4gPj4+IHN0YW5kYXJkIHNvbHV0 aW9uIGFzIHNvb24gYXMgcG9zc2libGUuICAoYSBkcmFmdC1pZXRmLW5ldG1vZCBzb2x1dGlvbnMN Cj4gPj4+IGRyYWZ0IG9uIHRoZSB0b3BpYyBieSBCQSB3b3VsZCBiZSBmYW50YXN0aWMgZ2l2ZW4g dGhlIGltcGFjdCBvbg0KPiA+Pj4gcm91dGluZw0KPiA+Pj4gYXJlYSAtLSBldmVuIGlmIGl0IGhh ZCB0byBkb2N1bWVudCB0d28gdmFyaWF0aW9ucyAvIGFsdGVybmF0aXZlDQo+ID4+PiBzb2x1dGlv bnMuKQ0KPiA+Pj4NCj4gPj4+IEFnYWluLCB0aGlzIGlzIGp1c3QgbXkgb3BpbmlvbiBhbmQgbXkg Y29hdXRob3JzIG9yIG90aGVycyBvbiB0aGUgcnRnDQo+ID4+PiBhcmVhIHlhbmcgRFQgbWF5IGNo b29zZSB0byBjaGltZSBpbi4NCj4gPj4+DQo+ID4+PiBMb3UNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG5ldG1vZCBtYWls aW5nIGxpc3QNCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN Cg== From nobody Wed Feb 3 13:12:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52C1B2D0B for ; Wed, 3 Feb 2016 13:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 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, RP_MATCHES_RCVD=-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 MNOMelddtZSg for ; Wed, 3 Feb 2016 13:12: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 0C77C1B2D0F for ; Wed, 3 Feb 2016 13:11:59 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:c871:d1cd:7f05:6f14] (unknown [IPv6:2a01:5e0:29:ffff:c871:d1cd:7f05:6f14]) by mail.nic.cz (Postfix) with ESMTPSA id 8DCCE180324; Wed, 3 Feb 2016 22:11:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454533917; bh=splwoXSRIe3rBu/oVVh7r2cs5jbIcmWPMHfrHm/DN8U=; h=From:Date:To; b=BilHbAsEzzE371C1CGqr+KGwWrkdXbakXdgvhRx/EFJSQvy/F0ybyc0WOHLxoRE2f ZrOXqbuze1UISClvihTc159vHs4onywxrXW/ZpZcFyTCGcbsxq7WgGZkm1zvRyCmaY Yxo1KVXaBXu2Btrg5jqhj4oDEplTBEZxjAIpaz9Y= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160203.173328.2114908676730595749.mbj@tail-f.com> Date: Wed, 3 Feb 2016 22:11:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9244479E-E226-4B8D-AD39-2209D49D870F@nic.cz> References: <9B660354-6F9B-4970-BA84-CD47E9C6E7D2@nic.cz> <56B20288.6070204@cisco.com> <20160203.173328.2114908676730595749.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= 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] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 21:12:05 -0000 > On 03 Feb 2016, at 17:33, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 03 Feb 2016, at 14:37, Benoit Claise wrote: >>>=20 >>> Hi Lada, >>>>=20 >>>>>> I agree with Juergen that 6087bis should distinguish between = complete >>>>>> example modules and short module snippets that are used for = explaining a >>>>>> certain YANG language or encoding issue. If you look at this = particular >>>>>> example, then changing the JSON document on p. 6 to >>>>>>=20 >>>>>> { >>>>>> "example-foomod:top": { >>>>>> "foo": 54, >>>>>> "example-barmod:bar": true >>>>>> } >>>>>> } >>>>>>=20 >>>>>> would IMO just add noise and blur the message the example is = supposed to >>>>>> convey. >>>>> So please fix the text in 6087bis. >>>>> Until it's done, I'll stick to the current rule. >>>> I don't want to be excessively bureaucratic but, strictly >> speaking, current rules are those of RFC 6087 that contains no such >> requirement, so we should be OK for now. And I think there is enough >> consensus >>> so J=FCrgen and you? >>=20 >> I guess Martin as well, given that 6020bis doesn't follow that rule. >=20 > I agree that not all modules must compile, e.g. we have things like: >=20 > module example-foo { > ... > container bar { ... } > } >=20 > Having said that, in the upcoming version of 6020bis, I have changed > things like "module acme-system" to "module example-system". OK, so I will also add the "example-" prefix in yang-json. Lada >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>> to change the corresponding 6087bis text - after all, 6020bis also = has example modules whose names don't start with "example-". >>> I'll still have to review it and that will be one of my comments, = for sure. Consistency first. >>>=20 >>> Regards ,Benoit >>>=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 Wed Feb 3 13:38:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574501B2D9F for ; Wed, 3 Feb 2016 13:38:47 -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 mpRbV0Y-gbrX for ; Wed, 3 Feb 2016 13:38:45 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 7B6641B2D99 for ; Wed, 3 Feb 2016 13:38:45 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id w123so20443739pfb.0 for ; Wed, 03 Feb 2016 13:38:45 -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=IlApEkQ4oc6sCc3RRe5rkrMifKVOEekJYWgTuDINuvU=; b=LAeOt/6ax2c+SmNJrrd72eKoEUQUyJwhabeA9YTe20WSAMF8/42kxjifvoAf58J6ek X/8Jie4V18CvPSdp3O00PLLlYkPD5PofCTKdPBQJDUOwfhB2pzdKua+LZ1U+fwCVUCKO Lp8GzwkPb9VZTzO7Guua4dCb/rer9eRHhxIJex3rmBCua2Fa+ng8TEWSUd+6ArOGRehE ORq8soKr14cdg3j/ogq5O/m6bn+q022uQ1bvk+Se1xH9w9foVtFvWl56k97YYWrfVzYT nPDPum87aQiATrr8Ps+0ZoCO1Bg0Azdv+A8EH366j8eUagf7/qTW0JHhNv7oO1nBSoek zfag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IlApEkQ4oc6sCc3RRe5rkrMifKVOEekJYWgTuDINuvU=; b=fvgyviuC12FBK0Gj3ZguGv3u9jvFwV5WUGBiCj56etsFBFFakD8xVuth/Z0WORrXv5 XQSn1jrFjsjg1eFmUDnN49BzZLieIgcX2HKfPJ3aQPBJti85tlABF7YbWOIrMJ+TzNpj eFD1PTgwgMV79uH2VBuzRqgdlYakYYAdz+d4sjO82oQLBBGROzBy7BK7LPwqf3RFZjNh aPxhswCKz0bIcsqlEE+HRKQ7VIv0tAp3OfbPYGwnqF75CtcRH59ALjM5R2Y3VKValEmb 8XEsSkx0qFr7Y96KubYuy1y7JxJ3ExLTRYTOTLkgqq6MNcqDHgPygidFZeaG0o6uG8wR iKzg== X-Gm-Message-State: AG10YOSz23bO8Y91tH6gvrsXSniw0VGvAXiP/+QRAbsT7GY5EtiKLcz6tckH4iBFn+rRMw== X-Received: by 10.98.42.81 with SMTP id q78mr5851289pfq.142.1454535525173; Wed, 03 Feb 2016 13:38:45 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1002::56a? ([2001:420:c0c8:1002::56a]) by smtp.gmail.com with ESMTPSA id ya4sm11976630pab.22.2016.02.03.13.38.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Feb 2016 13:38:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_89EE3AA1-0DF1-454D-A2CB-602E8D797D83" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <20160203104946.GB19098@elstar.local> Date: Wed, 3 Feb 2016 13:38:45 -0800 Message-Id: References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <20160203104946.GB19098@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 21:38:47 -0000 --Apple-Mail=_89EE3AA1-0DF1-454D-A2CB-602E8D797D83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder = wrote: >=20 > On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote: >=20 >> module foomod { >>=20 >> namespace"http://example.com/foomod"; >>=20 >> prefix "foo"; >>=20 >> container top { >> leaf foo { >> type uint8; >> } >> } >> } >>=20 >> Use "example-" in the module name, as mentioned=20 >> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: >>=20 >> Example modules are non-normative, and SHOULD be named with the >> prefix "example-". >>=20 >> Same remark for module barmod (and btw, pay attention to the "import=20= >> foomod") and module exmod >=20 > I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs > fixing to distinguish between examples that should be subject to > validation and examples that are just there for documentation purposes > and which are typically designed to be incomplete in order to aid the > reader. I agree. Currently there is no way to distinguish between models that = are examples, meant to be extracted and validated, and what I call = snippets of an example that are designed to incomplete and for = demonstrating a point.=20 Should there be a stipulation in 6087bis that incomplete examples should = NOT use the prefix example-? >=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 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_89EE3AA1-0DF1-454D-A2CB-602E8D797D83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Feb 03, 2016 = at 11:19:33AM +0100, Benoit Claise wrote:

 module foomod = {

    namespace"http://example.com/foomod";

=     prefix "foo";

=     container top {
=       leaf foo {
=         type uint8;
=       }
=     }
  }

Use "example-" in the module name, as mentioned
inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:<= /a>

=       Example modules are non-normative, = and SHOULD be named with the
=       prefix "example-".

Same remark for module barmod (and btw, pay attention to the = "import
foomod") and module exmod

I still believe the text in = draft-ietf-netmod-rfc6087bis-05 needs
fixing to = distinguish between examples that should be subject to
validation and examples that are just there for documentation = purposes
and which are typically designed to be incomplete = in order to aid the
reader.

I agree. = Currently there is no way to distinguish between models that are = examples, meant to be extracted and validated, and what I call snippets = of an example that are designed to incomplete and for demonstrating a = point. 


Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_89EE3AA1-0DF1-454D-A2CB-602E8D797D83-- From nobody Wed Feb 3 13:59:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928F81B2D6B for ; Wed, 3 Feb 2016 13:59:22 -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 lcTmO7vRCvCI for ; Wed, 3 Feb 2016 13:59:20 -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 E80981B3586 for ; Wed, 3 Feb 2016 13:59:19 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id l143so23835213lfe.2 for ; Wed, 03 Feb 2016 13:59: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=D7klg3PGhvth43rqRc464VvbGjH/wVA3eHo/Smh03VQ=; b=VgINyGGaUcAz/SRJz/xe355EVdQW6AZLWHbZLXKr6tfAWZoJROjr0psT1PMgKtD1l3 FJSdaXHfESVrjs+YtsC/ie78gpX5hjU4w19n9VV39mABZZth0C5sdR+dSyIrawwtg3d/ jtNsjYvG/kDTlzy2DaYgfKcww2ckLir1Hndcz2SS5cxZYOjFIvbbktMbkFyWdbSQTTYn gAyqlboa2lCdV6bkMBIIv+nhtEN48NglKKjitYBntgssOU/7eH3IiNmseFKWupgY0UUL iAxOmNNL19Krg2S+R4YRy6gZYittill7tAN0Ye1eRVqozH+0CnC/eq/+fUIP4bWpj4hQ WM1A== 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=D7klg3PGhvth43rqRc464VvbGjH/wVA3eHo/Smh03VQ=; b=UmRcV0SPwAODWoF8QXeHAb5gpiNfS+t0Pojq0Khj/gzobRyXeuBqhpQJzJeqpW0DDk yurMgjjoSaGCfMHgZjredbzkyhcBfm5R3ovsSwyZO5vOt1I6VkKXB0KQ+FhCJGl6V3pA zvFqYVu7qtRzW8ickAxQGOJ6YbBJkVx0VpWsIBzj0zmW/TEHomkTFUdttzAgoNIgs0sw qcrMWobjEdYpLadyaHexaZ6shAc89trGtL1Phph3o07sKSHw6D+/O0W1xnO+Hkp3T70R Qg9tKCxw4sKE0YEnASzK6P6i8mETBh38pYBNUrT+gB6AEmVaa+RVLNn3+Tq1GrPLiTDT A4cQ== X-Gm-Message-State: AG10YOTSGb+mkTU1KdZMNcobdATNArVTnpQ/TVY1SHjywXFLz5k+Zy91TWJXYBvXJUrtynn62sl6LYgvltLFPA== MIME-Version: 1.0 X-Received: by 10.25.39.134 with SMTP id n128mr2062398lfn.54.1454536758184; Wed, 03 Feb 2016 13:59:18 -0800 (PST) Received: by 10.112.200.167 with HTTP; Wed, 3 Feb 2016 13:59:18 -0800 (PST) In-Reply-To: References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <20160203104946.GB19098@elstar.local> Date: Wed, 3 Feb 2016 13:59:18 -0800 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a11410470c8da30052ae4ba1a Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 03 Feb 2016 21:59:22 -0000 --001a11410470c8da30052ae4ba1a Content-Type: text/plain; charset=UTF-8 Hi, I entered a new 6087bis issue: https://github.com/netmod-wg/rfc6087bis/issues/27 I agree the conventions need to be spelled out. IMO there are many problematic examples in 6020bis. The convention "..." is used and some newbie could think it was some valid YANG syntax. There are also example modules that use prefixes although no prefix-stmt or import-stmt is shown to match up the prefix. This is a bigger problem than automated tools extracting modules. People learn from examples (more than we would like) so it needs to be clear in every YANG draft whether a YANG example is complete vs. trimmed for readability and not meant to be compiled. Let's not use 'example' as a hack to indicate 1 or the other. Compiler writers want deterministic syntax, not ad-hoc conventions. There are 3 scenarios: 1) normative: has and complete YANG module 2) example: no but complete YANG module, intended to be compiled 3) snippet: no and not complete, not intended to be compiled So we cannot tell the difference between (2) and (3). IMO we should have for (2) so it can be extracted automatically and distinguished from (3). Andy On Wed, Feb 3, 2016 at 1:38 PM, Mahesh Jethanandani wrote: > > On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote: > > module foomod { > > namespace"http://example.com/foomod"; > > prefix "foo"; > > container top { > leaf foo { > type uint8; > } > } > } > > Use "example-" in the module name, as mentioned > inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: > > Example modules are non-normative, and SHOULD be named with the > prefix "example-". > > Same remark for module barmod (and btw, pay attention to the "import > foomod") and module exmod > > > I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs > fixing to distinguish between examples that should be subject to > validation and examples that are just there for documentation purposes > and which are typically designed to be incomplete in order to aid the > reader. > > > I agree. Currently there is no way to distinguish between models that are > examples, meant to be extracted and validated, and what I call snippets of > an example that are designed to incomplete and for demonstrating a point. > > Should there be a stipulation in 6087bis that incomplete examples should > NOT use the prefix example-? > > > /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 > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11410470c8da30052ae4ba1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I entered a new 6087bis issue:

I agree the conventions need to be spelled out.
IMO there are ma= ny problematic examples in 6020bis.
The convention "..."= ; is used and some newbie could think
it was some valid YANG synt= ax.=C2=A0 There are also example
modules that use prefixes althou= gh no prefix-stmt or import-stmt
is shown to match up the prefix.=

This is a bigger problem than automated tools ext= racting modules.
People learn from examples (more than we would l= ike) so it needs
to be clear in every YANG draft whether a YANG e= xample
is complete vs. trimmed for readability and not meant to b= e compiled.

Let's not use 'example' as= a hack to indicate 1 or the other.
Compiler writers want determi= nistic syntax, not ad-hoc conventions.

There are 3= scenarios:

1) normative: has <CODE BEGINS> = and complete YANG module


2) example= : no <CODE BEGINS> but complete YANG module,
=C2=A0 =C2= =A0 intended to be compiled

3) snippet: no <COD= E BEGINS> and not complete, not intended to be compiled


So we cannot tell the difference between (2) and (3= ).

IMO we should have <EXAMPLE BEGINS> for (= 2) so it can be
extracted automatically and distinguished from (3= ).


Andy

<= div class=3D"gmail_extra">
On Wed, Feb 3, 201= 6 at 1:38 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

On Feb 3, 2016, at 2:49 AM,= Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrot= e:

On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wr= ote:

=C2=A0module foomod {

=C2=A0= =C2=A0=C2=A0=C2=A0namespace"http://example.com/foomod";

=C2=A0=C2=A0=C2= =A0=C2=A0prefix "foo";

=C2=A0=C2=A0=C2=A0=C2=A0container = top {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf foo {
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type uint8;
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0}
=C2=A0=C2=A0=C2=A0=C2=A0}
=C2=A0=C2=A0}

Use= "example-" in the module name, as mentioned
inhttps://too= ls.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Example modules are non-normative, and SHOULD be na= med with the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0prefix "example-&= quot;.

Same remark for module barmod (and btw, pay attention to the = "import
foomod") and module exmod

I still= believe the text in draft-ietf-netmod-rfc6087bis-05 needs
fixing to dis= tinguish between examples that should be subject to
validation and examp= les that are just there for documentation purposes
and which are typical= ly designed to be incomplete in order to aid the
reader.

I agree. Currently there is no way to distinguish bet= ween models that are examples, meant to be extracted and validated, and wha= t I call snippets of an example that are designed to incomplete and for dem= onstrating a point.=C2=A0

Should there be a stipul= ation in 6087bis that incomplete examples should NOT use the prefix example= -?


/js

--
Juerg= en Schoenwaelder =C2=A0=C2=A0=C2=A0=C2=A0=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=A0=C2=A0=C2=A0=C2=A0Campus Ring 1 | 28759 Bremen | Germany<= br>Fax: =C2=A0=C2=A0+49 421 200 3103 =C2=A0=C2=A0=C2=A0=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/ma= ilman/listinfo/netmod

Mahesh Jethanandani






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


--001a11410470c8da30052ae4ba1a-- From nobody Wed Feb 3 17:35:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E4E1B3804 for ; Wed, 3 Feb 2016 17:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 aEXovvi28mdZ for ; Wed, 3 Feb 2016 17:35:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050C21B3803 for ; Wed, 3 Feb 2016 17:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9710; q=dns/txt; s=iport; t=1454549729; x=1455759329; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LFLwGNwN1xmlAQj0WXSR0FJ4QAnTCoQtyP+SLkC+oTM=; b=KK2x1S8iYJaxusGvzlVbOJo47ljXEP8gM13bmBPyJgabkP19aVZXHGdG 8PhZ9K+chKxoaF6ZwBLIN1GZwhQbVswT38PYxCVa4B06rXL6v+L7k63Vm JWbDyW9YneHd5kAn34XFCv1VYQAD/ruFrtW87QqvlsoNx8FKqqV2Z7hoZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAwBeqrJW/5ldJa1UCoM6Um0GhCmEL?= =?us-ascii?q?LEbAQ2BZhcKhSJKAhyBJTgUAQEBAQEBAYEKhEEBAQEEAQEBIBE6CwwEAgEIDgM?= =?us-ascii?q?EAQEBAgIjAwICAiULFAEICAIEDgUIE4gADrFdjxgBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQERBHuJToQCBgQHAQYugmqBOgWWcQGNRYFihEKIVI4/AR4BAUKDZGqIMgk?= =?us-ascii?q?XHXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,393,1449532800"; d="scan'208";a="234053043" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2016 01:35:27 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u141ZRiL027609 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 01:35:27 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 20:35:26 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 20:35:26 -0500 From: "Alexander Clemm (alex)" To: Kent Watsen , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyQ7D2KRUiAW0+6Gca0wXUbR58Z7BoAgADEaoCAAFlAAIAADNdQ Date: Thu, 4 Feb 2016 01:35:26 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> In-Reply-To: <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.86.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 01:35:31 -0000 SGkgS2VudCwNCg0KSSBkbyB0aGluayB0aGF0IHdlIHNob3VsZCBoYXZlIGEgc2xvdCBmb3IgdGhh dCBkcmFmdCBhcyB3ZWxsLiAgVGhlIHN0cnVjdHVyYWwgbW91bnQgY2FzZSBpcyBhIHZhcmlhdGlv biBvZiB0aGUgYWxpYXMgbW91bnQgY2FzZTsgaXQgaXMgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGhh dmUgYSBjb250aW51dW0gb2Ygc29sdXRpb25zIHRoYXQgYWxsb3dzIHRvIGluY29ycG9yYXRlIHN0 cnVjdHVyYWwgbW91bnQgYXMgd2VsbCBhcyBhbGlhcyBtb3VudCBhbmQgcGVlciBtb3VudCAodGhl IGxhdHRlciBwb3NzaWJseSBhdCBhIGxhdGVyIHBvaW50KS4gIA0KDQpBdCB0aGUgY29yZSBpbiBl YWNoIGNhc2UgaXMgdGhlIOKAnG1vdW50cG9pbnTigJ0gY29uc3RydWN0IC8gWUFORyBleHRlbnNp b24sIHdoaWNoIHdhcyBmaXJzdCBpbnRyb2R1Y2VkIGluIHRoZSBwZWVyLW1vdW50IGRyYWZ0IGFu ZCB3aGljaCBhbHNvIGFwcGVhcnMgaW4gdGhlIHN0cnVjdHVyZWQtbW91bnQgZHJhZnQuICBJbiBw ZWVyLW1vdW50LCB3ZSBhbHNvIGludHJvZHVjZWQgdHdvIGFkZGl0aW9uYWwgYXJndW1lbnRzLyBl eHRlbnNpb24gaW4gYWRkaXRpb246ICB0aGUgc3VidHJlZSAodXNlZCBmb3IgYWxpYXMgbW91bnQp LCBhbmQgdGhlIHRhcmdldCAoZm9yIHBlZXIgbW91bnQg4oCTIGJ1aWxkaW5nIG9uIHRvcCwgZm9y IHdoZW4gaXQgaXMgcmVxdWlyZWQpLiAgSW4gdGhlIGRpc2N1c3Npb25zIHNpbmNlLCBpdCBiZWNh bWUgY2xlYXIgdGhhdCB0aGVyZSBpcyBhbHNvIGEgdXNlIGNhc2Ugd2hlcmUgeW91IGRvbuKAmXQg bmVlZCBhbiBhbGlhcywgd2hlcmUgaXQgaXMgc3VmZmljaWVudCB0byBqdXN0IG1vdW50IGEgbW9k dWxlIGFuZCBpbnN0YW50aWF0ZSBpdCByaWdodCB1bmRlciB0aGUgbW91bnQgcG9pbnQuICBUaGlz IGlzIHRoZSBjYXNlIHRoYXQgTWFydGluIHB1dCBpbiBoaXMgZHJhZnQuICBTbywgdGhlcmUgaXMg cmVhbGx5IGEgY29udGludXVtOiBhIGNhc2Ugb2YgYSBtb3VudHBvaW50IHdpdGggbm8gYXJndW1l bnQgKHN0cnVjdHVyYWwgbW91bnQgLSB0aGUgbmV3IGRyYWZ0KSwgd2l0aCBvbmUgYXJndW1lbnQg KGFsaWFzKSwgIGFuZCB3aXRoIHR3byAocGVlcikgKHRoZSBlYXJsaWVyIGRyYWZ0KS4gIA0KDQot LS0gQWxleA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLZW50IFdhdHNl biBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAwMywgMjAxNiAxMToyNyBBTQ0KVG86IFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNP RlQgTElNSVRFRCBhdCBDaXNjbykgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6IExvdSBCZXJnZXIg PGxiZXJnZXJAbGFibi5uZXQ+OyBuZXRtb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz47IEFsZXhhbmRl ciBDbGVtbSAoYWxleCkgPGFsZXhAY2lzY28uY29tPjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0 QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZYW5nIG1vdW50IC8geXNkbCBleGFt cGxlIHVzZSBjYXNlDQoNCg0KSSB3YXMgbGVkIHRvIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBz ZXQgb2YgZHJhZnRzIHN1YnN1bWUgZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50LiAgSWYgdGhhdOKA mXMgbm90IHRydWUsIHRoZW4gYWJzb2x1dGVseSB0aGVyZSBzaG91bGQgYmUgYSBzbG90IGZvciB0 aGF0IGRyYWZ0IHRvIGJlIGRpc2N1c3NlZCBhcyB3ZWxsLiAgUGxlYXNlIGFkdmlzZS4NCg0KS2Vu dA0KDQoNCg0KDQoNCg0KT24gMi8zLzE2LCA5OjA3IEFNLCAiUm9iZXJ0IFdpbHRvbiIgPHJ3aWx0 b25AY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIEtlbnQsDQo+DQo+VGhlcmUgaXMgYWxzbyBhbm90 aGVyIFlhbmcgTW91bnQgcmVsYXRlZCBkcmFmdDogDQo+ZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50 LTAzDQo+DQo+Tm93LCB0aGlzIGRyYWZ0IGRvZXNuJ3QgZGlyZWN0bHkgYWRkcmVzcyB0aGUgUlRH IERUIEFyY2ggdGVhbSB1c2UtY2FzZSwgDQo+YW5kIHNlZW1zIHRvIGNvdmVyIHR3byBtb3JlIGNv bXBsZXggcHJvYmxlbSBzY2VuYXJpb3MgKHJlbW90ZSBtb3VudCBhbmQgDQo+YWxpYXMgbW91bnQp LCBidXQgdGhlc2UgZG8gYXBwZWFyIHRvIGJlIGEgdmFsaWQgbW91bnQgdXNlIGNhc2VzIChlLmcu IEkgDQo+dGhpbmsgdGhhdCBpdCBpcyB1c2VkIGJ5IE9wZW5EYXlsaWdodCBTRE4gY29udHJvbGxl ciksIGFuZCBJIGtub3cgdGhhdCANCj50aGVyZSBpcyBhdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRp b24gb2YgdGhpcyBkcmFmdC4NCj4NCj5TbywgSSB3YW50IHRvIGVjaG8gRXJpYyBWb2l0J3MgY29t bWVudHMgdGhhdCBpdCB3b3VsZCBiZSBnb29kIGlmIA0KPndoYXRldmVyIGJhc2ljIFlBTkcgbW91 bnQgZHJhZnQgd2UgY29udmVyZ2Ugb24gaXMgYWJsZSB0byBiZSBjbGVhbmx5IA0KPmV4dGVuZGVk IHRvIGNvdmVyIHRoZSBtb3JlIGNvbXBsZXggbW91bnQgc2NlbmFyaW9zLg0KPg0KPkFzIHN1Y2gs IGlmIEFsZXggQ2xlbW0gb3IgRXJpYyBWb2l0IGFyZSB3aWxsaW5nLCBJIHRoaW5rIHRoYXQgaXQg d291bGQgDQo+YmUgdXNlZnVsIGlmIG9uZSBvZiB0aGVtIGNvdWxkIGNvbW1lbnQgb24gaG93IGZl YXNpYmxlIGl0IGlzIHRvIGV4dGVuZCANCj5laXRoZXIgbmV0bW9kLXN0cnVjdHVhbC1tb3VudCBv ciBuZXRtb2QteXNkbCB0byBjb3ZlciB0aGUgcmVtb3RlIG1vdW50IA0KPmFuZCBhbGlhcyBtb3Vu dCBzY2VuYXJpb3MgZGVzY3JpYmVkIGluIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMy4NCj5I ZW5jZSwgaWYgdGhleSBhZ3JlZSwgZG8geW91IHRoaW5rIHRoYXQgeW91IHdvdWxkIGJlIGFibGUg dG8gYWRkIGEgMTUgDQo+bWluIHNsb3QgdG8gdGhlIGFnZW5kYSB0byBjb3ZlciB0aGlzIHBsZWFz ZT8NCj4NCj5UaGFua3MsDQo+Um9iDQo+DQo+DQo+T24gMDMvMDIvMjAxNiAwMjoyNCwgS2VudCBX YXRzZW4gd3JvdGU6DQo+PiBbQ2hhaXIgaGF0IG9uXQ0KPj4NCj4+IEdpdmVuIHRoZSBudW1iZXIg b2YgY29tcGV0aW5nL2NvbXBsZW1lbnRpbmcgZHJhZnRzIGludm9sdmVkLCBhbmQgdGhlIGdlbmVy YWwgbGFjayBvZiBkaXNjdXNzaW9uIG9uIGFueSBvZiB0aGVtLCBhIHZpcnR1YWwgaW50ZXJpbSBt ZWV0aW5nIG1pZ2h0IGJlIGFuIGV4cGVkaWVudCB3YXkgdG8gcHJvY2VlZC4gIEluIGZhaXJuZXNz LCB3ZSBrbm93IHRoYXQgdGhlcmUgaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uLCBidXQgaXQgaGFz buKAmXQgYmVlbiBwaWNrZWQgdXAgeWV0IGluIGEgYmlnIHdheSwgYW5kIG5vdyBMb3UgaGFzIGFu IHVwZGF0ZWQgZHJhZnQuDQo+Pg0KPj4gVGhlIGNoYWlycyBkaXNjdXNzZWQgbWF5YmUgc2NoZWR1 bGluZyBvbmUgZm9yIGEgY291cGxlIHdlZWtzIGZyb20gbm93LCBwZXJoYXBzIFRodXJzZGF5IEZl YiAxOCBzdGFydGluZyBhdCAxMGFtIEVTVD8gICBJJ20gdGhpbmtpbmcgYWJvdXQgdGhpcyBzbG90 IG9ubHkgc2luY2UgaXQgd29ya2VkIGZvciB1cyBmb3IgcHJldmlvdXNseS4gIElzIHRoaXMgYSBn b29kIHRpbWUgc2xvdD8gIEkgYXNzdW1lIHRvIHNjaGVkdWxlIGZvciAyIGhvdXJzLCB3aXRoIGEg cGxhbiB0byBlbmQgZWFybHkgaWYgbmVlZGVkIC0gbWFrZXMgc2Vuc2U/ICAgICBXZSBhbHNvIG5l ZWQgdG8gcHV0IHRvZ2V0aGVyIGEgcHJvcGVyIGFnZW5kYSwgcGVyaGFwcyB0aGUgZm9sbG93aW5n Pw0KPj4NCj4+ICAgIDEwIG1pbjogUlRHIERUIFlBTkcgQXJjaCB0ZWFtIHVzZS1jYXNlIHN1bW1h cnkNCj4+ICAgIDIwIG1pbjogZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbA0KPj4g ICAgMjAgbWluOiBkcmFmdC1saG90a2EtbmV0bW9kLXlzZGwNCj4+ICAgIDIwIG1pbjogZHJhZnQt YmpvcmtsdW5kLW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50DQo+PiAgICA1MCBtaW46IGdlbmVyYWwg ZGlzY3Vzc2lvbiBvciBlbmQgZWFybHkNCj4+DQo+Pg0KPj4gV2UgaG9wZSB0byBzY2hlZHVsZSB0 aGUgbWVldGluZyBpdHNlbGYgdG9tb3Jyb3cgb3IgdGhlIG5leHQgZGF5LCBzbyBwbGVhc2UgcmVz cG9uZCBxdWlja2x5IHRvIHRoaXMgZW1haWwgaWYgcG9zc2libGUuDQo+Pg0KPj4gVGhhbmtzLA0K Pj4gS2VudCBhbmQgVG9tDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT24gMi8yLzE2LCAyOjA0IFBNLCAi bmV0bW9kIG9uIGJlaGFsZiBvZiBMb3UgQmVyZ2VyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4NCj4+PiBJIHRob3VnaHQg aXQgd291bGQgYmUgd29ydGggc3VtbWFyaXppbmcgd2hhdCB3ZSdyZSBsb29raW5nIGZvciBpbiAN Cj4+PiBvdXIgZHJhZnQsIGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDIgKG5v dGUgbmV3IHZlcnNpb24gDQo+Pj4gaW4gY2FzZSB5b3UgbWlzc2VkIGl0KSB3aXRoIHJlc3BlY3Qg dG8gdGhlIGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbCANCj4+PiBhbmQgZHJhZnQtYmpvcmtsdW5k LW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50IGRyYWZ0cy4gVGhpcyBpcyBqdXN0IG15IA0KPj4+IHZp ZXcsIHNvIG15IGNvLWF1dGhvcnMgbWF5IHdpc2ggdG8gY2hpbWUgaW4gYW5kIGNvcnJlY3QgbWUu DQo+Pj4NCj4+PiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZyb20gdGhlIGF1dGhvcnMg b2YgWVNETCBhbmQgDQo+Pj4gc3RydWN0dXJhbC1tb3VudCwgb3IgYW55b25lIGVsc2UgZm9yIHRo YXQgbWF0dGVyLCBvbiBob3cgdGhleSBzZWUgdG8gDQo+Pj4gYmVzdCBtZWV0IHRoZXNlIG5lZWRz Lg0KPj4+DQo+Pj4gSGVyZSdzIHdoYXQgSSB0aGluayBvdXIgZHJhZnQgbmVlZHM6DQo+Pj4NCj4+ PiAxLiB0aGF0IHRoZXJlIGJlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHRoZSBpbmNvcnBvcmF0 aW9uIChvcg0KPj4+ICAgICdtb3VudGluZycpIG9mIHRoZSBkYXRhIG1vZGVsIGRlZmluZWQgYnkg b25lIHRvcC1sZXZlbCBtb2R1bGUNCj4+PiAgICB3aXRoaW4gYW5vdGhlciBtb2R1bGUuDQo+Pj4N Cj4+PiAgICBUaGUgaW1wbGljYXRpb24gaGVyZSBpcyB0aGF0IHdoZW4gaW5mb3JtYXRpb24gaXMg aW5zdGFudGlhdGVkDQo+Pj4gICAgZm9yIHRoZSBwYXJlbnQgbW9kZWwgaXQgaXMgYWxzbyBpbnN0 YW50aWF0ZWQgZm9yIHRoZQ0KPj4+ICAgIGluY29ycG9yYXRlZC9tb3VudGVkIG1vZGVsLiBJbiBv dXIgY2FzZSB3ZSBleHBlY3QgdG8gZG8gdGhpcyBvbg0KPj4+ICAgIGxpc3QgZWxlbWVudCBjcmVh dGlvbi4gQm90aCBzb2x1dGlvbnMgZHJhZnRzIGNvdmVyIHRoZSBwYXRoDQo+Pj4gICAgaW1wbGlj YXRpb25zLCBzbyB0aGVzZSBhcmUgbm90IHJlcGVhdGVkIGhlcmUuDQo+Pj4NCj4+PiAyLiB0aGF0 IHRoaXMgbWVjaGFuaXNtIGFsbG93IGlkZW50aWZpY2F0aW9uIG9mIHNwZWNpZmljIG1vZHVsZXMg dG8NCj4+PiAgICBiZSBpbmNvcnBvcmF0ZWQvbW91bnRlZCBhdCB0aW1lIG9mIG1vZHVsZSBkZWZp bml0aW9uLCBpLmUuIHRoYXQNCj4+PiAgICBubyBhZGRpdGlvbmFsIG1vZHVsZSBpcyBuZWVkZWQg dG8gc3VwcG9ydCAxLiBUaGlzIGRvZXNuJ3QNCj4+PiAgICBwcmVjbHVkZSBkZWZpbml0aW9uIG9m IHN1Y2ggYSBtb2R1bGUuDQo+Pj4NCj4+PiAzLiB0aGF0IHRoaXMgbWVjaGFuaXNtIGFsbG93IGZv ciBhIHNlcnZlciB0byBjb250cm9sIChhbmQNCj4+PiAgICBpZGVudGlmeSkgd2hpY2ggbW9kdWxl cyBhcmUgaW5jb3Jwb3JhdGVkL21vdW50ZWQuIChzZWUgU2VjdGlvbg0KPj4+ICAgIDMgTE5FIGlu IG91ciBkcmFmdCBmb3IgYW4gZW52aXNpb25lZCB1c2FnZS4pDQo+Pj4NCj4+PiA0LiB0aGF0IGFs bCBjYXBhYmlsaXRpZXMgdGhhdCBleGlzdCB3aXRoIHRoZSBtb3VudGVkIG1vZHVsZSBhcmUNCj4+ PiAgICBhdmFpbGFibGUgZS5nLiBSUEMgb3BlcmF0aW9ucyBhbmQgbm90aWZpY2F0aW9ucy4NCj4+ Pg0KPj4+IDUuIHdoaWxlIG91ciBwcmltYXJ5IHJlcXVpcmVtZW50IGlzIGZvciAnbW91bnRpbmcn IG9mIHRvcCBsZXZlbA0KPj4+ICAgIG1vZHVsZXMsIG1vdW50aW5nIG9mIHN1Ym1vZHVsZXMgbWF5 IGFsc28gYmUgdXNlZnVsLiAoRFQgbm90IGRyYWZ0DQo+Pj4gICAgZHJpdmVuLikNCj4+Pg0KPj4+ IFdlIG1ha2UgdXNlIG9mIHRoZSBhYm92ZSBpbiBzZWN0aW9ucyAzIGFuZCA0IG9mIHJ0Z3dnLWRl dmljZS1tb2RlbC4gIA0KPj4+IFdlIHNlZSBoYXZpbmcgYSBzb2x1dGlvbiBhcyBjcml0aWNhbCBm b3IgdGhlIA0KPj4+IHNpbXBsaWZpY2F0aW9ucy9mbGV4aWJpbGl0eSByZXByZXNlbnRlZCBpbiB0 aGUgLTAyIHZlcnNpb24gb2Ygb3VyIA0KPj4+IGRyYWZ0IHZzIHRoZSAtMDMgcmV2LiAgV2UgZG9u J3Qgc2VlIHdpdGhlciBzb2x1dGlvbiBkcmFmdCBhcyANCj4+PiBzaWduaWZpY2FudGx5IGRpZmZl cmVudCBhbmQganVzdCBob3BlIGZvciBhIHN0YW5kYXJkIHNvbHV0aW9uIGFzIA0KPj4+IHNvb24g YXMgcG9zc2libGUuICAoYSBkcmFmdC1pZXRmLW5ldG1vZCBzb2x1dGlvbnMgZHJhZnQgb24gdGhl IHRvcGljIA0KPj4+IGJ5IEJBIHdvdWxkIGJlIGZhbnRhc3RpYyBnaXZlbiB0aGUgaW1wYWN0IG9u IHJvdXRpbmcgYXJlYSAtLSBldmVuIGlmIA0KPj4+IGl0IGhhZCB0byBkb2N1bWVudCB0d28gdmFy aWF0aW9ucyAvIGFsdGVybmF0aXZlIHNvbHV0aW9ucy4pDQo+Pj4NCj4+PiBBZ2FpbiwgdGhpcyBp cyBqdXN0IG15IG9waW5pb24gYW5kIG15IGNvYXV0aG9ycyBvciBvdGhlcnMgb24gdGhlIHJ0ZyAN Cj4+PiBhcmVhIHlhbmcgRFQgbWF5IGNob29zZSB0byBjaGltZSBpbi4NCj4+Pg0KPj4+IExvdQ0K Pj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K From nobody Wed Feb 3 20:26:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A081A0093 for ; Wed, 3 Feb 2016 20:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 SDRZg4YDJKgw for ; Wed, 3 Feb 2016 20:26:48 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id B050D1A0092 for ; Wed, 3 Feb 2016 20:26:48 -0800 (PST) Received: (qmail 18431 invoked by uid 0); 4 Feb 2016 04:26:47 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 4 Feb 2016 04:26:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id EBSg1s00T2SSUrH01BSjQE; Thu, 04 Feb 2016 04:26:45 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=AUd_NHdVAAAA:8 a=OUXY8nFuAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=JJr7pLZuWwH69Of6x7AA:9 a=QYkNyypIoegIVOXg:21 a=SAYfQv1DKsrhDNpx:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=OimQq+TwtXRxLC12ysvyw5kP1Sb48Kle25qco/AMJEg=; b=PoEU67zji/VPH/iIe8V8tOuyFSSlLeX2UvQu9s5e/y7FESGgvZViGLqThfRP3CgTDvOiWENQBCyVN9N8MPb2/RT1LUpaZTJqh+aRr8PAeM3b+SlouYUx4HsL3LoMOEVZ; Received: from [100.15.91.238] (port=52696 helo=[192.168.1.224]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aRBVC-0006St-P2; Wed, 03 Feb 2016 21:26:42 -0700 From: Lou Berger To: "Alexander Clemm (alex)" , Kent Watsen , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Date: Wed, 03 Feb 2016 23:26:39 -0500 Message-ID: <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 04:26:51 -0000 Alex, On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" wrote: > Hi Kent, > > I do think that we should have a slot for that draft as well. The > structural mount case is a variation of the alias mount case; Insofar as much that Structural mount and YSDL both have a model that is used to control their mount functions there is similarity, but there is a fundamental difference that the other documents cover a schema being mounted not a datastore. Scheme mount is really a better term than structural mount... Also for our use case we don't want to use a different/ additional model. That said covering alias and remote mount if there is time in the interim would be fine with me, but not at the expense of identifying a preferred approach of enabling the same amount that we are making use of in our draft. Lou > it is certainly possible to have a continuum of solutions that allows to > incorporate structural mount as well as alias mount and peer mount (the > latter possibly at a later point). > > At the core in each case is the “mountpoint” construct / YANG extension, > which was first introduced in the peer-mount draft and which also appears > in the structured-mount draft. In peer-mount, we also introduced two > additional arguments/ extension in addition: the subtree (used for alias > mount), and the target (for peer mount – building on top, for when it is > required). In the discussions since, it became clear that there is also a > use case where you don’t need an alias, where it is sufficient to just > mount a module and instantiate it right under the mount point. This is the > case that Martin put in his draft. So, there is really a continuum: a case > of a mountpoint with no argument (structural mount - the new draft), with > one argument (alias), and with two (peer) (the earlier draft). > > --- Alex > > > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Wednesday, February 03, 2016 11:27 AM > To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) > Cc: Lou Berger ; netmod WG ; Alexander > Clemm (alex) ; Eric Voit (evoit) > Subject: Re: [netmod] Yang mount / ysdl example use case > > > I was led to believe that the current set of drafts subsume > draft-clemm-netmod-mount. If that’s not true, then absolutely there should > be a slot for that draft to be discussed as well. Please advise. > > Kent > > > > > > > On 2/3/16, 9:07 AM, "Robert Wilton" wrote: > >>Hi Kent, >> >>There is also another Yang Mount related draft: >>draft-clemm-netmod-mount-03 >> >>Now, this draft doesn't directly address the RTG DT Arch team use-case, >>and seems to cover two more complex problem scenarios (remote mount and >>alias mount), but these do appear to be a valid mount use cases (e.g. I >>think that it is used by OpenDaylight SDN controller), and I know that >>there is at least one implementation of this draft. >> >>So, I want to echo Eric Voit's comments that it would be good if >>whatever basic YANG mount draft we converge on is able to be cleanly >>extended to cover the more complex mount scenarios. >> >>As such, if Alex Clemm or Eric Voit are willing, I think that it would >>be useful if one of them could comment on how feasible it is to extend >>either netmod-structual-mount or netmod-ysdl to cover the remote mount >>and alias mount scenarios described in draft-clemm-netmod-mount-03. >>Hence, if they agree, do you think that you would be able to add a 15 >>min slot to the agenda to cover this please? >> >>Thanks, >>Rob >> >> >>On 03/02/2016 02:24, Kent Watsen wrote: >>> [Chair hat on] >>> >>> Given the number of competing/complementing drafts involved, and the >>> general lack of discussion on any of them, a virtual interim meeting might >>> be an expedient way to proceed. In fairness, we know that there has been >>> some discussion, but it hasn’t been picked up yet in a big way, and now Lou >>> has an updated draft. >>> >>> The chairs discussed maybe scheduling one for a couple weeks from now, >>> perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this >>> slot only since it worked for us for previously. Is this a good time slot? >>> I assume to schedule for 2 hours, with a plan to end early if needed - >>> makes sense? We also need to put together a proper agenda, perhaps the >>> following? >>> >>> 10 min: RTG DT YANG Arch team use-case summary >>> 20 min: draft-rtgyangdt-rtgwg-device-model >>> 20 min: draft-lhotka-netmod-ysdl >>> 20 min: draft-bjorklund-netmod-structural-mount >>> 50 min: general discussion or end early >>> >>> >>> We hope to schedule the meeting itself tomorrow or the next day, so please >>> respond quickly to this email if possible. >>> >>> Thanks, >>> Kent and Tom >>> >>> >>> >>> >>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>> wrote: >>> >>>> I thought it would be worth summarizing what we're looking for in >>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version >>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl >>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my >>>> view, so my co-authors may wish to chime in and correct me. >>>> >>>> I'd be interested in hearing from the authors of YSDL and >>>> structural-mount, or anyone else for that matter, on how they see to >>>> best meet these needs. >>>> >>>> Here's what I think our draft needs: >>>> >>>> 1. that there be a mechanism that allows the incorporation (or >>>> 'mounting') of the data model defined by one top-level module >>>> within another module. >>>> >>>> The implication here is that when information is instantiated >>>> for the parent model it is also instantiated for the >>>> incorporated/mounted model. In our case we expect to do this on >>>> list element creation. Both solutions drafts cover the path >>>> implications, so these are not repeated here. >>>> >>>> 2. that this mechanism allow identification of specific modules to >>>> be incorporated/mounted at time of module definition, i.e. that >>>> no additional module is needed to support 1. This doesn't >>>> preclude definition of such a module. >>>> >>>> 3. that this mechanism allow for a server to control (and >>>> identify) which modules are incorporated/mounted. (see Section >>>> 3 LNE in our draft for an envisioned usage.) >>>> >>>> 4. that all capabilities that exist with the mounted module are >>>> available e.g. RPC operations and notifications. >>>> >>>> 5. while our primary requirement is for 'mounting' of top level >>>> modules, mounting of submodules may also be useful. (DT not draft >>>> driven.) >>>> >>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>> We see having a solution as critical for the >>>> simplifications/flexibility represented in the -02 version of our >>>> draft vs the -03 rev. We don't see wither solution draft as >>>> significantly different and just hope for a standard solution as >>>> soon as possible. (a draft-ietf-netmod solutions draft on the topic >>>> by BA would be fantastic given the impact on routing area -- even if >>>> it had to document two variations / alternative solutions.) >>>> >>>> Again, this is just my opinion and my coauthors or others on the rtg >>>> area yang DT may choose to chime in. >>>> >>>> Lou >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Feb 3 23:42:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088C21A0271 for ; Wed, 3 Feb 2016 23:42: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 cAZ-YKibVMMg for ; Wed, 3 Feb 2016 23:42:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA11A0233 for ; Wed, 3 Feb 2016 23:42:13 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EC9BC1CC02CA; Thu, 4 Feb 2016 08:42:12 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Mahesh Jethanandani In-Reply-To: References: <56B0DD74.4060309@cisco.com> <56B1D435.7030506@cisco.com> <20160203104946.GB19098@elstar.local> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 04 Feb 2016 08:42:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-yang-json-07 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, 04 Feb 2016 07:42:17 -0000 Andy Bierman writes: > Hi, > > I entered a new 6087bis issue: > https://github.com/netmod-wg/rfc6087bis/issues/27 > > I agree the conventions need to be spelled out. > IMO there are many problematic examples in 6020bis. > The convention "..." is used and some newbie could think > it was some valid YANG syntax. There are also example > modules that use prefixes although no prefix-stmt or import-stmt > is shown to match up the prefix. > > This is a bigger problem than automated tools extracting modules. > People learn from examples (more than we would like) so it needs > to be clear in every YANG draft whether a YANG example > is complete vs. trimmed for readability and not meant to be compiled. > > Let's not use 'example' as a hack to indicate 1 or the other. > Compiler writers want deterministic syntax, not ad-hoc conventions. > > There are 3 scenarios: > > 1) normative: has and complete YANG module > > > 2) example: no but complete YANG module, > intended to be compiled > > 3) snippet: no and not complete, not intended to be compiled > > > So we cannot tell the difference between (2) and (3). I think the "example-" prefix could be such a discriminator, to be used at I-D author's discretion. It's better than nothing. Lada > > IMO we should have for (2) so it can be > extracted automatically and distinguished from (3). > > > Andy > > > On Wed, Feb 3, 2016 at 1:38 PM, Mahesh Jethanandani > wrote: > >> >> On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >> On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote: >> >> module foomod { >> >> namespace"http://example.com/foomod"; >> >> prefix "foo"; >> >> container top { >> leaf foo { >> type uint8; >> } >> } >> } >> >> Use "example-" in the module name, as mentioned >> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: >> >> Example modules are non-normative, and SHOULD be named with the >> prefix "example-". >> >> Same remark for module barmod (and btw, pay attention to the "import >> foomod") and module exmod >> >> >> I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs >> fixing to distinguish between examples that should be subject to >> validation and examples that are just there for documentation purposes >> and which are typically designed to be incomplete in order to aid the >> reader. >> >> >> I agree. Currently there is no way to distinguish between models that are >> examples, meant to be extracted and validated, and what I call snippets of >> an example that are designed to incomplete and for demonstrating a point. >> >> Should there be a stipulation in 6087bis that incomplete examples should >> NOT use the prefix example-? >> >> >> /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 >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> >> >> _______________________________________________ >> 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 Thu Feb 4 00:53:47 2016 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 323501A1BD9; Thu, 4 Feb 2016 00:53:45 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204085345.19678.14689.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 00:53:45 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-10.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: Thu, 04 Feb 2016 08:53:45 -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-10.txt Pages : 206 Date : 2016-02-04 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 4 01:24:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51B01A21AA for ; Thu, 4 Feb 2016 01:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 LDj09a6z4dRS for ; Thu, 4 Feb 2016 01:24:15 -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 34D781A21A5 for ; Thu, 4 Feb 2016 01:24: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 59FEB8F9 for ; Thu, 4 Feb 2016 10:24: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 2cubUX3J8yNx for ; Thu, 4 Feb 2016 10:24: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 ; Thu, 4 Feb 2016 10:24:08 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AE3320013 for ; Thu, 4 Feb 2016 10:24:08 +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 i3s69PnVhxoT; Thu, 4 Feb 2016 10:24: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 C954D2002B; Thu, 4 Feb 2016 10:24:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0EE7D39DEC2C; Thu, 4 Feb 2016 10:24:05 +0100 (CET) Date: Thu, 4 Feb 2016 10:24:05 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160204092405.GA21276@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] YANG 1.1 final check of WG last call edits [until 2016-02-15] 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, 04 Feb 2016 09:24:18 -0000 Hi, the YANG 1.1 definition has gone through two WG last calls, the first WG last call did end on 2015-10-12 and the second WG last call did end on 2016-01-06. Martin has just posted https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-10 which we believe incorporates all changes that were discussed after the second WG last call. I believe the document is ready to be sent to our AD Benoit Claise. However, before doing so, I plan to give the WG a chance to review the changes. Note that this is not the time to suggest new language features or to request changes of existing language behavior. All I am looking for is to make sure that (a) we did not forget any agreed upon edits and (b) that edits did not introduce any bugs or fatal errors. The deadline for sending in comments is Monday 2016-02-15. /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 Feb 4 01:57:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83C71A6EF4 for ; Thu, 4 Feb 2016 01:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 fPND6NFRlTqZ for ; Thu, 4 Feb 2016 01:57:02 -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 43DD81A6F13 for ; Thu, 4 Feb 2016 01:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9464; q=dns/txt; s=iport; t=1454579822; x=1455789422; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6yd1GMiPDA1bPO+Sb6fklW6slvOPmrWROCLSBjFMwHM=; b=i0Xklo4FGPj16HAB4vYhiWxR43czAOE1G8L2vs+Pjdhd8C24YECo/s+r iP8USIQE5uv2gfg7YXWoHywueJIG0V2zHXbIUT8gBdkkLnVPmLpZ0ONPb xnlm5mRP6B611B+XlffrRna9EHDb9+dX5IqH7oMnMCrOhwJbeLBfOblEv s=; X-IronPort-AV: E=Sophos;i="5.22,395,1449532800"; d="scan'208";a="632160334" 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; 04 Feb 2016 09:57:00 +0000 Received: from [10.63.23.97] (dhcp-ensft1-uk-vla370-10-63-23-97.cisco.com [10.63.23.97]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u149uxY0004934; Thu, 4 Feb 2016 09:56:59 GMT To: Lou Berger , "Alexander Clemm (alex)" , Kent Watsen , "Eric Voit (evoit)" References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Wilton Message-ID: <56B3206B.7070000@cisco.com> Date: Thu, 4 Feb 2016 09:56:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 09:57:06 -0000 Hi, I wasn't actually suggesting that Alex's YANG mount draft be considered as a solution here. I think that this draft is probably sufficiently complex that it would require a lot WG discussion and hence take too long to standardize to meet the RTG DT requirements. Hence, I envisage that we'll end up with two drafts: 1) A basic mount draft - based on either Martin's Structural Mount or Lada's Ysdl drafts. 2) A revision of Alex's YANG mount draft that extends from the base mount draft (1) above to cover alias and peer mount. The meeting should focus on (1). But what I am suggesting is for either Alex or Eric to evaluate both Martin's Structural Mount and Lada's Ysdl to determine whether either of the drafts are particularly better/easier/cleaner to extend to cover the Alias and Peer mount use cases covered in Alex's YANG mount draft, since that might be useful to help identify which of (Martin's Structural Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution. I hope this clarifies my previous request. Rob On 04/02/2016 04:26, Lou Berger wrote: > Alex, > > > On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" > wrote: > >> Hi Kent, >> >> I do think that we should have a slot for that draft as well. The >> structural mount case is a variation of the alias mount case; > > Insofar as much that Structural mount and YSDL both have a model that > is used to control their mount functions there is similarity, but > there is a fundamental difference that the other documents cover a > schema being mounted not a datastore. Scheme mount is really a better > term than structural mount... > > Also for our use case we don't want to use a different/ additional model. > > That said covering alias and remote mount if there is time in the > interim would be fine with me, but not at the expense of identifying a > preferred approach of enabling the same amount that we are making use > of in our draft. > > Lou > >> it is certainly possible to have a continuum of solutions that allows >> to incorporate structural mount as well as alias mount and peer mount >> (the latter possibly at a later point). >> >> At the core in each case is the “mountpoint” construct / YANG >> extension, which was first introduced in the peer-mount draft and >> which also appears in the structured-mount draft. In peer-mount, we >> also introduced two additional arguments/ extension in addition: the >> subtree (used for alias mount), and the target (for peer mount – >> building on top, for when it is required). In the discussions since, >> it became clear that there is also a use case where you don’t need an >> alias, where it is sufficient to just mount a module and instantiate >> it right under the mount point. This is the case that Martin put in >> his draft. So, there is really a continuum: a case of a mountpoint >> with no argument (structural mount - the new draft), with one >> argument (alias), and with two (peer) (the earlier draft). >> >> --- Alex >> >> >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Wednesday, February 03, 2016 11:27 AM >> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) >> >> Cc: Lou Berger ; netmod WG ; >> Alexander Clemm (alex) ; Eric Voit (evoit) >> >> Subject: Re: [netmod] Yang mount / ysdl example use case >> >> >> I was led to believe that the current set of drafts subsume >> draft-clemm-netmod-mount. If that’s not true, then absolutely there >> should be a slot for that draft to be discussed as well. Please advise. >> >> Kent >> >> >> >> >> >> >> On 2/3/16, 9:07 AM, "Robert Wilton" wrote: >> >>> Hi Kent, >>> >>> There is also another Yang Mount related draft: >>> draft-clemm-netmod-mount-03 >>> >>> Now, this draft doesn't directly address the RTG DT Arch team use-case, >>> and seems to cover two more complex problem scenarios (remote mount and >>> alias mount), but these do appear to be a valid mount use cases (e.g. I >>> think that it is used by OpenDaylight SDN controller), and I know that >>> there is at least one implementation of this draft. >>> >>> So, I want to echo Eric Voit's comments that it would be good if >>> whatever basic YANG mount draft we converge on is able to be cleanly >>> extended to cover the more complex mount scenarios. >>> >>> As such, if Alex Clemm or Eric Voit are willing, I think that it would >>> be useful if one of them could comment on how feasible it is to extend >>> either netmod-structual-mount or netmod-ysdl to cover the remote mount >>> and alias mount scenarios described in draft-clemm-netmod-mount-03. >>> Hence, if they agree, do you think that you would be able to add a 15 >>> min slot to the agenda to cover this please? >>> >>> Thanks, >>> Rob >>> >>> >>> On 03/02/2016 02:24, Kent Watsen wrote: >>>> [Chair hat on] >>>> >>>> Given the number of competing/complementing drafts involved, and >>>> the general lack of discussion on any of them, a virtual interim >>>> meeting might be an expedient way to proceed. In fairness, we know >>>> that there has been some discussion, but it hasn’t been picked up >>>> yet in a big way, and now Lou has an updated draft. >>>> >>>> The chairs discussed maybe scheduling one for a couple weeks from >>>> now, perhaps Thursday Feb 18 starting at 10am EST? I'm thinking >>>> about this slot only since it worked for us for previously. Is >>>> this a good time slot? I assume to schedule for 2 hours, with a >>>> plan to end early if needed - makes sense? We also need to put >>>> together a proper agenda, perhaps the following? >>>> >>>> 10 min: RTG DT YANG Arch team use-case summary >>>> 20 min: draft-rtgyangdt-rtgwg-device-model >>>> 20 min: draft-lhotka-netmod-ysdl >>>> 20 min: draft-bjorklund-netmod-structural-mount >>>> 50 min: general discussion or end early >>>> >>>> >>>> We hope to schedule the meeting itself tomorrow or the next day, so >>>> please respond quickly to this email if possible. >>>> >>>> Thanks, >>>> Kent and Tom >>>> >>>> >>>> >>>> >>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>>> wrote: >>>> >>>>> I thought it would be worth summarizing what we're looking for in >>>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version >>>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl >>>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my >>>>> view, so my co-authors may wish to chime in and correct me. >>>>> >>>>> I'd be interested in hearing from the authors of YSDL and >>>>> structural-mount, or anyone else for that matter, on how they see to >>>>> best meet these needs. >>>>> >>>>> Here's what I think our draft needs: >>>>> >>>>> 1. that there be a mechanism that allows the incorporation (or >>>>> 'mounting') of the data model defined by one top-level module >>>>> within another module. >>>>> >>>>> The implication here is that when information is instantiated >>>>> for the parent model it is also instantiated for the >>>>> incorporated/mounted model. In our case we expect to do this on >>>>> list element creation. Both solutions drafts cover the path >>>>> implications, so these are not repeated here. >>>>> >>>>> 2. that this mechanism allow identification of specific modules to >>>>> be incorporated/mounted at time of module definition, i.e. that >>>>> no additional module is needed to support 1. This doesn't >>>>> preclude definition of such a module. >>>>> >>>>> 3. that this mechanism allow for a server to control (and >>>>> identify) which modules are incorporated/mounted. (see Section >>>>> 3 LNE in our draft for an envisioned usage.) >>>>> >>>>> 4. that all capabilities that exist with the mounted module are >>>>> available e.g. RPC operations and notifications. >>>>> >>>>> 5. while our primary requirement is for 'mounting' of top level >>>>> modules, mounting of submodules may also be useful. (DT not draft >>>>> driven.) >>>>> >>>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>>> We see having a solution as critical for the >>>>> simplifications/flexibility represented in the -02 version of our >>>>> draft vs the -03 rev. We don't see wither solution draft as >>>>> significantly different and just hope for a standard solution as >>>>> soon as possible. (a draft-ietf-netmod solutions draft on the topic >>>>> by BA would be fantastic given the impact on routing area -- even if >>>>> it had to document two variations / alternative solutions.) >>>>> >>>>> Again, this is just my opinion and my coauthors or others on the rtg >>>>> area yang DT may choose to chime in. >>>>> >>>>> Lou >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Feb 4 03:38:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A271A0098; Thu, 4 Feb 2016 03:38:45 -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 OXFOaDLyY7AR; Thu, 4 Feb 2016 03:38:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D5D631ACF57; Thu, 4 Feb 2016 03:38:43 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 54D6A1CC0BCA; Thu, 4 Feb 2016 12:38:41 +0100 (CET) From: Ladislav Lhotka To: Lou Berger , netmod WG In-Reply-To: <56B0FDAC.3090100@labn.net> References: <56B0FDAC.3090100@labn.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 04 Feb 2016 12:38:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 11:38:45 -0000 Hi Lou, Lou Berger writes: > I thought it would be worth summarizing what we're looking for in our > draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case > you missed it) with respect to the draft-lhotka-netmod-ysdl and > draft-bjorklund-netmod-structural-mount drafts. This is just my view, so > my co-authors may wish to chime in and correct me. > > I'd be interested in hearing from the authors of YSDL and > structural-mount, or anyone else for that matter, on how they see to > best meet these needs. > > Here's what I think our draft needs: > > 1. that there be a mechanism that allows the incorporation (or > 'mounting') of the data model defined by one top-level module > within another module. > > The implication here is that when information is instantiated > for the parent model it is also instantiated for the > incorporated/mounted model. In our case we expect to do this on > list element creation. Both solutions drafts cover the path > implications, so these are not repeated here. Both structural-mount and YSDL satisfy this. > > 2. that this mechanism allow identification of specific modules to > be incorporated/mounted at time of module definition, i.e. that > no additional module is needed to support 1. This doesn't > preclude definition of such a module. If I understand this correctly, then I believe that neither structural-mount nor YSDL support it. This would require new built-in statements in YANG, extensions aren't applicable here. > > 3. that this mechanism allow for a server to control (and > identify) which modules are incorporated/mounted. (see Section > 3 LNE in our draft for an envisioned usage.) Both structural-mount and YSDL satisfy this. > > 4. that all capabilities that exist with the mounted module are > available e.g. RPC operations and notifications. Currently only structural-mount addresses this, YSDL can be extended along the same lines. > > 5. while our primary requirement is for 'mounting' of top level > modules, mounting of submodules may also be useful. (DT not draft > driven.) I don't think this is possible as long as both structural-mount and YSDL take the information about available modules from yang-library. A solution to this could be to allow the "include" statement to appear anywhere in the schema tree, but this is again YANG 2 stuff. Lada > > We make use of the above in sections 3 and 4 of rtgwg-device-model. We > see having a solution as critical for the simplifications/flexibility > represented in the -02 version of our draft vs the -03 rev. We don't > see wither solution draft as significantly different and just hope for a > standard solution as soon as possible. (a draft-ietf-netmod solutions > draft on the topic by BA would be fantastic given the impact on routing > area -- even if it had to document two variations / alternative solutions.) > > Again, this is just my opinion and my coauthors or others on the rtg > area yang DT may choose to chime in. > > Lou > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 4 03:51:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3F1AD0B8 for ; Thu, 4 Feb 2016 03:51:32 -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 QBBsFIMqy7Vu for ; Thu, 4 Feb 2016 03:51:30 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 941D61AD0B7 for ; Thu, 4 Feb 2016 03:51:29 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CF6DA1CC0BCA; Thu, 4 Feb 2016 12:51:27 +0100 (CET) From: Ladislav Lhotka To: Lou Berger , "Alexander Clemm \(alex\)" , Kent Watsen , "Robert Wilton -X \(rwilton - ENSOFT LIMITED at Cisco\)" In-Reply-To: <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 04 Feb 2016 12:51:31 +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] Yang mount / ysdl example use case 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, 04 Feb 2016 11:51:32 -0000 Lou Berger writes: > Alex, > > > On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" = wrote: > >> Hi Kent, >> >> I do think that we should have a slot for that draft as well. The=20 >> structural mount case is a variation of the alias mount case; > > Insofar as much that Structural mount and YSDL both have a model that is= =20 > used to control their mount functions there is similarity, but there is a= =20 > fundamental difference that the other documents cover a schema being=20 > mounted not a datastore. Scheme mount is really a better term than=20 > structural mount... This is correct, both structural-mount and YSDL just define a compound schema/data model. The term "mount" is IMO more connected to combining data trees (as in NFS mount). YSDL also requires that all YANG modules be known/advertised locally through the local server's yang-library, so there are no extra security implications compared to the current situation where all modules are combined side-by-side. Lada > > Also for our use case we don't want to use a different/ additional model. > > That said covering alias and remote mount if there is time in the interim= =20 > would be fine with me, but not at the expense of identifying a preferred= =20 > approach of enabling the same amount that we are making use of in our dra= ft. > > Lou > >> it is certainly possible to have a continuum of solutions that allows to= =20 >> incorporate structural mount as well as alias mount and peer mount (the= =20 >> latter possibly at a later point). >> >> At the core in each case is the =E2=80=9Cmountpoint=E2=80=9D construct /= YANG extension,=20 >> which was first introduced in the peer-mount draft and which also appear= s=20 >> in the structured-mount draft. In peer-mount, we also introduced two=20 >> additional arguments/ extension in addition: the subtree (used for alia= s=20 >> mount), and the target (for peer mount =E2=80=93 building on top, for wh= en it is=20 >> required). In the discussions since, it became clear that there is also= a=20 >> use case where you don=E2=80=99t need an alias, where it is sufficient t= o just=20 >> mount a module and instantiate it right under the mount point. This is = the=20 >> case that Martin put in his draft. So, there is really a continuum: a c= ase=20 >> of a mountpoint with no argument (structural mount - the new draft), wit= h=20 >> one argument (alias), and with two (peer) (the earlier draft). >> >> --- Alex >> >> >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Wednesday, February 03, 2016 11:27 AM >> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) >> Cc: Lou Berger ; netmod WG ; Alexande= r=20 >> Clemm (alex) ; Eric Voit (evoit) >> Subject: Re: [netmod] Yang mount / ysdl example use case >> >> >> I was led to believe that the current set of drafts subsume=20 >> draft-clemm-netmod-mount. If that=E2=80=99s not true, then absolutely t= here should=20 >> be a slot for that draft to be discussed as well. Please advise. >> >> Kent >> >> >> >> >> >> >> On 2/3/16, 9:07 AM, "Robert Wilton" wrote: >> >>>Hi Kent, >>> >>>There is also another Yang Mount related draft: >>>draft-clemm-netmod-mount-03 >>> >>>Now, this draft doesn't directly address the RTG DT Arch team use-case, >>>and seems to cover two more complex problem scenarios (remote mount and >>>alias mount), but these do appear to be a valid mount use cases (e.g. I >>>think that it is used by OpenDaylight SDN controller), and I know that >>>there is at least one implementation of this draft. >>> >>>So, I want to echo Eric Voit's comments that it would be good if >>>whatever basic YANG mount draft we converge on is able to be cleanly >>>extended to cover the more complex mount scenarios. >>> >>>As such, if Alex Clemm or Eric Voit are willing, I think that it would >>>be useful if one of them could comment on how feasible it is to extend >>>either netmod-structual-mount or netmod-ysdl to cover the remote mount >>>and alias mount scenarios described in draft-clemm-netmod-mount-03. >>>Hence, if they agree, do you think that you would be able to add a 15 >>>min slot to the agenda to cover this please? >>> >>>Thanks, >>>Rob >>> >>> >>>On 03/02/2016 02:24, Kent Watsen wrote: >>>> [Chair hat on] >>>> >>>> Given the number of competing/complementing drafts involved, and the=20 >>>> general lack of discussion on any of them, a virtual interim meeting m= ight=20 >>>> be an expedient way to proceed. In fairness, we know that there has b= een=20 >>>> some discussion, but it hasn=E2=80=99t been picked up yet in a big way= , and now Lou=20 >>>> has an updated draft. >>>> >>>> The chairs discussed maybe scheduling one for a couple weeks from now,= =20 >>>> perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about thi= s=20 >>>> slot only since it worked for us for previously. Is this a good time = slot?=20 >>>> I assume to schedule for 2 hours, with a plan to end early if needed = -=20 >>>> makes sense? We also need to put together a proper agenda, perhaps= the=20 >>>> following? >>>> >>>> 10 min: RTG DT YANG Arch team use-case summary >>>> 20 min: draft-rtgyangdt-rtgwg-device-model >>>> 20 min: draft-lhotka-netmod-ysdl >>>> 20 min: draft-bjorklund-netmod-structural-mount >>>> 50 min: general discussion or end early >>>> >>>> >>>> We hope to schedule the meeting itself tomorrow or the next day, so pl= ease=20 >>>> respond quickly to this email if possible. >>>> >>>> Thanks, >>>> Kent and Tom >>>> >>>> >>>> >>>> >>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"=20 >>>> wrote: >>>> >>>>> I thought it would be worth summarizing what we're looking for in >>>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version >>>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl >>>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my >>>>> view, so my co-authors may wish to chime in and correct me. >>>>> >>>>> I'd be interested in hearing from the authors of YSDL and >>>>> structural-mount, or anyone else for that matter, on how they see to >>>>> best meet these needs. >>>>> >>>>> Here's what I think our draft needs: >>>>> >>>>> 1. that there be a mechanism that allows the incorporation (or >>>>> 'mounting') of the data model defined by one top-level module >>>>> within another module. >>>>> >>>>> The implication here is that when information is instantiated >>>>> for the parent model it is also instantiated for the >>>>> incorporated/mounted model. In our case we expect to do this on >>>>> list element creation. Both solutions drafts cover the path >>>>> implications, so these are not repeated here. >>>>> >>>>> 2. that this mechanism allow identification of specific modules to >>>>> be incorporated/mounted at time of module definition, i.e. that >>>>> no additional module is needed to support 1. This doesn't >>>>> preclude definition of such a module. >>>>> >>>>> 3. that this mechanism allow for a server to control (and >>>>> identify) which modules are incorporated/mounted. (see Section >>>>> 3 LNE in our draft for an envisioned usage.) >>>>> >>>>> 4. that all capabilities that exist with the mounted module are >>>>> available e.g. RPC operations and notifications. >>>>> >>>>> 5. while our primary requirement is for 'mounting' of top level >>>>> modules, mounting of submodules may also be useful. (DT not draft >>>>> driven.) >>>>> >>>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>>> We see having a solution as critical for the >>>>> simplifications/flexibility represented in the -02 version of our >>>>> draft vs the -03 rev. We don't see wither solution draft as >>>>> significantly different and just hope for a standard solution as >>>>> soon as possible. (a draft-ietf-netmod solutions draft on the topic >>>>> by BA would be fantastic given the impact on routing area -- even if >>>>> it had to document two variations / alternative solutions.) >>>>> >>>>> Again, this is just my opinion and my coauthors or others on the rtg >>>>> area yang DT may choose to chime in. >>>>> >>>>> Lou >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 4 03:53:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06011AD0BB for ; Thu, 4 Feb 2016 03:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 rbY0nrG84Q6k for ; Thu, 4 Feb 2016 03:53:35 -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 518761AD0B7 for ; Thu, 4 Feb 2016 03:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1256; q=dns/txt; s=iport; t=1454586814; x=1455796414; h=to:from:subject:message-id:date:mime-version; bh=2mtj5Z/ToGhOiiihGQJpSPL4nSr6QuWCz1kfms37Ino=; b=TqhEXQKJD4S0BWpJOFYTol4UsrbaMfiy6IWGozX7FvFCUXfBu91sWrmr W0fJFAVEyRhCGn4x6CBDBbMLN4HCvyY1TWhGd6AU9p88GTMK4k9VFQtTv Wi3Y/CnwJU6qB1YI5mdsn5LfzLwhApdY74UaoXdAvIe+KQ9U7qJTNkPMH s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBgDBOrNW/xbLJq1ejVSpYIkSiB4BA?= =?us-ascii?q?QEBAQGBC4RrgRIhAhECTA0IAQGIF6Fmj1uPHgEBAQcCARUIkXuBOgWWcYJ8gWO?= =?us-ascii?q?IbokghVGOQGKDZTuIWAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,395,1449532800"; d="asc'?scan'208";a="624018056" 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; 04 Feb 2016 11:53:28 +0000 Received: from [10.61.108.44] (dhcp-10-61-108-44.cisco.com [10.61.108.44]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u14BrR3E018863 for ; Thu, 4 Feb 2016 11:53:28 GMT To: netmod WG From: Eliot Lear Message-ID: <56B33BB6.10400@cisco.com> Date: Thu, 4 Feb 2016 12:53:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VsnwLaJEDGpKroeLNam0rE7PJdJb8RU6M" Archived-At: Subject: [netmod] draft-lear-ietf-netmod-acl-dnsname 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, 04 Feb 2016 11:53:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VsnwLaJEDGpKroeLNam0rE7PJdJb8RU6M Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, Based on our earlier discussions, I've written a small extension to the ACL model. This is a -00. Suggestions welcome. If people like I can introduce it at a meeting or interim, but if it's small enough and simple enough, perhaps this list would be able to make any necessary improvements? Eliot --VsnwLaJEDGpKroeLNam0rE7PJdJb8RU6M 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 iQEcBAEBCAAGBQJWszu3AAoJEIe2a0bZ0nozrv0H/11IKKF2rGTTSNS9pc1bG1v3 wK4lXNCaHcxSt2z/ZiPPUvN7IVrVll7+JbwXV9CrCcE6H6DVp9Jk5zRHGoESjN07 y4F2QWPUyArnB+8f1GgNpbT4tuFTmt2Bgl1h+GMdbIjtdKPBIenidDA7TZjl/8QU TL9MKNJt/Q4CpHVUU0ITlZM9sGQTsQJofVDoK1RgM3a0oUIKEJ+2JBhRNKRrclTw p+xZEuN10WChYeowSYBSg5cBqwELN+vRbRa0dC94fAaBAsf5z83uI6LJAhw40YaB i1kB/otRbtlGY0OF9kVKYGpkzvQ4saL5ynVIWAqMDendlQJAJezzQFu4HeitaLQ= =+dxN -----END PGP SIGNATURE----- --VsnwLaJEDGpKroeLNam0rE7PJdJb8RU6M-- From nobody Thu Feb 4 03:55:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C697A1B2A02 for ; Thu, 4 Feb 2016 03:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 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_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ID7hQL2yDx0W for ; Thu, 4 Feb 2016 03:54:59 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 165671B29FA for ; Thu, 4 Feb 2016 03:54:59 -0800 (PST) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 7790B24439D; Thu, 4 Feb 2016 12:54:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1454586897; bh=m08hLpJkTedOsS5KUtiXCDzWlTuAOkH6jOU1zn9jmQ0=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=tRZhCGNScsXMhTlAXdBdpPIIcfur73RZ4nsbdhDebFkVtY+tDmKyD+j/9CYqhAsH7 koinufOx/UBqsmuBYOMzpN3NCvQY01Ay3b5YgKeDqDZWzmtKCEGh/3qBZKrWRc6ie0 Q6vcNpb/oWjfnqFSo5/fInkA7AoaahXxkx/h3ojE= To: Robert Wilton , Kent Watsen References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> From: Robert Varga Message-ID: <56B33C11.5020906@hq.sk> Date: Thu, 4 Feb 2016 12:54:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B209B9.2050504@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 11:55:01 -0000 On 02/03/2016 03:07 PM, Robert Wilton wrote: > Hi Kent, > > There is also another Yang Mount related draft: > draft-clemm-netmod-mount-03 > > Now, this draft doesn't directly address the RTG DT Arch team > use-case, and seems to cover two more complex problem scenarios > (remote mount and alias mount), but these do appear to be a valid > mount use cases (e.g. I think that it is used by OpenDaylight SDN > controller), and I know that there is at least one implementation of > this draft. I would like to clarify here. OpenDaylight has the equivalent of draft-bjorklund-netmod-structural-mount as its core concept, somewhat described in https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems. The term 'mount' originates from there and deals exclusively with the problem of nesting/rehoming YANG models. draft-clemm-netmod-mount describes particular use cases of how such a nested subsystem may be realized and deals with actual data movement. As such, these are considered non-core plugins in OpenDaylight. Bye, Robert From nobody Thu Feb 4 04:00:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BAE1AD0A2; Thu, 4 Feb 2016 04:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 x_e9K2H0tVxB; Thu, 4 Feb 2016 04:00:31 -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 795B71A6F82; Thu, 4 Feb 2016 04:00: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 405461468; Thu, 4 Feb 2016 13:00: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 5SL5BirqH0-v; Thu, 4 Feb 2016 13:00: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; Thu, 4 Feb 2016 13:00:29 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6102F20031; Thu, 4 Feb 2016 13:00: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 snUXlBxupZMb; Thu, 4 Feb 2016 13:00: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 DC23F20035; Thu, 4 Feb 2016 13:00:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4BFBA39DEEAC; Thu, 4 Feb 2016 13:00:28 +0100 (CET) Date: Thu, 4 Feb 2016 13:00:28 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160204120028.GC21573@elstar.local> Mail-Followup-To: Lou Berger , netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B0FDAC.3090100@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 12:00:34 -0000 On Tue, Feb 02, 2016 at 02:04:12PM -0500, Lou Berger wrote: > > 5. while our primary requirement is for 'mounting' of top level > modules, mounting of submodules may also be useful. (DT not draft > driven.) > A YANG submodule is by definition incomplete. For example, a submodule does not have a defined namespace. I think we should not waste effort to expose submodules beyond what they were designed to be used for - to break a really large module into pieces that can be edited more easily independently. If more granular mounts are needed, then we should IMHO _not_ bundle this with the notion of YANG submodules. Perhaps you meant submodules in a more generic way, but then perhaps: s/of submodules/of parts of modules/ Reading the other text again, I am not sure what is meant by the phrase "incorporation of the data model defined by one top-level module". What exactly is a 'top-level module' (and does it matter, why can I not mount a non-top-level module)? And does 'incorporation of the data model' imply 'incorporation of the complete data model'? /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 Feb 4 04:06:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABA81B2C67 for ; Thu, 4 Feb 2016 04:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 BUXe2_71oMcW for ; Thu, 4 Feb 2016 04:06:13 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id BD26C1B2CA9 for ; Thu, 4 Feb 2016 04:06:12 -0800 (PST) Received: (qmail 28860 invoked by uid 0); 4 Feb 2016 12:06:09 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 4 Feb 2016 12:06:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id EC631s00X2SSUrH01C66Rr; Thu, 04 Feb 2016 05:06:07 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=OUixTkr4AAAA:8 a=48vgC7mUAAAA:8 a=-e5_gkha-N7qOSsnslMA:9 a=AYM2tnN0_yh2RoIO:21 a=w5bzNec9QvTy34Um:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=fUDg/+3JxqV3odcWN+i6Vg9jjAVv/a+lvM7+w99RiOw=; b=1goSFIDuZxas7LoZqRR6Qr2KHGggMCAo0RXTtnid4a2Xqh/X6kTUB9MLwRO0EPPXvGWJ319nHysOdvkl98TgNWGhcsLwG/eY8t7mInN1nfMAe07HJRPLYEQm5jFAfs8h; Received: from [100.15.91.238] (port=57680 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aRIfk-0003Vj-VM; Thu, 04 Feb 2016 05:06:05 -0700 From: Lou Berger To: Robert Varga , Robert Wilton , Kent Watsen Date: Thu, 04 Feb 2016 07:06:01 -0500 Message-ID: <152ac2b9f30.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <56B33C11.5020906@hq.sk> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <56B33C11.5020906@hq.sk> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 12:06:16 -0000 Robert, Thanks for pointer, nested subsystems look really close to what we're looking for and we could make do with a standardized form of it. (We were thinking nested modules, but given the definition of the server chooses we could make due.) Now we just need someone to write it up and submit as an ID.) Lou On February 4, 2016 6:55:30 AM Robert Varga wrote: > On 02/03/2016 03:07 PM, Robert Wilton wrote: >> Hi Kent, >> >> There is also another Yang Mount related draft: >> draft-clemm-netmod-mount-03 >> >> Now, this draft doesn't directly address the RTG DT Arch team >> use-case, and seems to cover two more complex problem scenarios >> (remote mount and alias mount), but these do appear to be a valid >> mount use cases (e.g. I think that it is used by OpenDaylight SDN >> controller), and I know that there is at least one implementation of >> this draft. > > I would like to clarify here. OpenDaylight has the equivalent of > draft-bjorklund-netmod-structural-mount as its core concept, somewhat > described in > https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems. > The term 'mount' originates from there and deals exclusively with the > problem of nesting/rehoming YANG models. > > draft-clemm-netmod-mount describes particular use cases of how such a > nested subsystem may be realized and deals with actual data movement. As > such, these are considered non-core plugins in OpenDaylight. > > Bye, > Robert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Feb 4 04:06:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D3A1B2C67 for ; Thu, 4 Feb 2016 04:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 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_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 NK1oeI5r5za9 for ; Thu, 4 Feb 2016 04:06:22 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 600211B2CC6 for ; Thu, 4 Feb 2016 04:06:22 -0800 (PST) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 8BB5D24025E; Thu, 4 Feb 2016 13:06:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1454587581; bh=wpWQOuEBRHSuvMCJHjecxb6Gy9OqhjMKQdQBfQN5X10=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=PwHB8I0lDD/K0dGUtummvr216AFka/tzzccm76ec4KscRJZmuZjScKngEVmbogfPZ t1Bxah/b11qNrWG6/HpG9ICzQH9EMRSO0dlq4rICI5EDEDWJej6ChOAUD4YDzBWVgX ptJvyZIkE7Xoa7y0tGLFcXuXOPSQ1L4sX65KXq5U= To: Ladislav Lhotka , Lou Berger , "Alexander Clemm (alex)" , Kent Watsen , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Varga Message-ID: <56B33EBD.7030107@hq.sk> Date: Thu, 4 Feb 2016 13:06:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 12:06:23 -0000 On 02/04/2016 12:51 PM, Ladislav Lhotka wrote: > This is correct, both structural-mount and YSDL just define a compound > schema/data model. The term "mount" is IMO more connected to combining data > trees (as in NFS mount). There are actually two aspects to this, which are related. Sorry to dump a bunch of UNIX specifics on you, but that was the best analogy I could find and that's how the term 'mount' got used for this area. The central idea is that a file system implementation living under a particular mount point not only abstracts where the data actually lives (as is the case for NFS mount and draft-clemm-netmod-mount), but it also allows for different types of objects and operations on them: VFAT does not support device special files and Ext4 supports a host of ext4-specific ioctl(2)s on its files. This difference in capabilities maps to the problem being solved by draft-bjorklund-netmod-structural-mount (and ysdl, but I have not read that yet). Bye, Robert From nobody Thu Feb 4 04:08:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BC91B2CC8 for ; Thu, 4 Feb 2016 04:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 FTqn8eNKC3vb for ; Thu, 4 Feb 2016 04:08:00 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 71B641B2CCB for ; Thu, 4 Feb 2016 04:08:00 -0800 (PST) Received: (qmail 18150 invoked by uid 0); 4 Feb 2016 12:07:59 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Feb 2016 12:07:59 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EC7t1s00i2SSUrH01C7wW1; Thu, 04 Feb 2016 05:07:59 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=AUd_NHdVAAAA:8 a=OUXY8nFuAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=eKuuEYs3ppqkrHsFZscA:9 a=XBj1Aonavjc4WFY8:21 a=tLnpYe997Jxuriz7:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=vZ+alNAK9TuCVhKitPCHFxOG9xO0st67wKQSwmwkqHQ=; b=G4iPDMXjaw6jEQSTqkq7/5w6P+awyAHIhlmgjFzjo0TsYGztNGx3uQqaMldQ6Wx1Tk/kekW3jhEJxSl4VPEWgq7phiipNlcIJ64lrMlRXVW1lkQ14YcbYUb3btNE5ArW; Received: from [100.15.91.238] (port=57681 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aRIhV-0003po-Ip; Thu, 04 Feb 2016 05:07:53 -0700 From: Lou Berger To: Robert Wilton , "Alexander Clemm (alex)" , Kent Watsen , "Eric Voit (evoit)" Date: Thu, 04 Feb 2016 07:07:50 -0500 Message-ID: <152ac2e6df0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <56B3206B.7070000@cisco.com> References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <56B3206B.7070000@cisco.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 12:08:02 -0000 Rob, On February 4, 2016 4:57:24 AM Robert Wilton wrote: > Hi, > > I wasn't actually suggesting that Alex's YANG mount draft be considered > as a solution here. I think that this draft is probably sufficiently > complex that it would require a lot WG discussion and hence take too > long to standardize to meet the RTG DT requirements. > > Hence, I envisage that we'll end up with two drafts: > 1) A basic mount draft - based on either Martin's Structural Mount or > Lada's Ysdl drafts. > 2) A revision of Alex's YANG mount draft that extends from the base > mount draft (1) above to cover alias and peer mount. > > The meeting should focus on (1). > > But what I am suggesting is for either Alex or Eric to evaluate both > Martin's Structural Mount and Lada's Ysdl to determine whether either of > the drafts are particularly better/easier/cleaner to extend to cover the > Alias and Peer mount use cases covered in Alex's YANG mount draft, since > that might be useful to help identify which of (Martin's Structural > Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution. > > I hope this clarifies my previous request. > Yes. Although to me a merging may be more appropriate/likely then picking one. Lou > Rob > > > On 04/02/2016 04:26, Lou Berger wrote: >> Alex, >> >> >> On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" >> wrote: >> >>> Hi Kent, >>> >>> I do think that we should have a slot for that draft as well. The >>> structural mount case is a variation of the alias mount case; >> >> Insofar as much that Structural mount and YSDL both have a model that >> is used to control their mount functions there is similarity, but >> there is a fundamental difference that the other documents cover a >> schema being mounted not a datastore. Scheme mount is really a better >> term than structural mount... >> >> Also for our use case we don't want to use a different/ additional model. >> >> That said covering alias and remote mount if there is time in the >> interim would be fine with me, but not at the expense of identifying a >> preferred approach of enabling the same amount that we are making use >> of in our draft. >> >> Lou >> >>> it is certainly possible to have a continuum of solutions that allows >>> to incorporate structural mount as well as alias mount and peer mount >>> (the latter possibly at a later point). >>> >>> At the core in each case is the “mountpoint” construct / YANG >>> extension, which was first introduced in the peer-mount draft and >>> which also appears in the structured-mount draft. In peer-mount, we >>> also introduced two additional arguments/ extension in addition: the >>> subtree (used for alias mount), and the target (for peer mount – >>> building on top, for when it is required). In the discussions since, >>> it became clear that there is also a use case where you don’t need an >>> alias, where it is sufficient to just mount a module and instantiate >>> it right under the mount point. This is the case that Martin put in >>> his draft. So, there is really a continuum: a case of a mountpoint >>> with no argument (structural mount - the new draft), with one >>> argument (alias), and with two (peer) (the earlier draft). >>> >>> --- Alex >>> >>> >>> -----Original Message----- >>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>> Sent: Wednesday, February 03, 2016 11:27 AM >>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) >>> >>> Cc: Lou Berger ; netmod WG ; >>> Alexander Clemm (alex) ; Eric Voit (evoit) >>> >>> Subject: Re: [netmod] Yang mount / ysdl example use case >>> >>> >>> I was led to believe that the current set of drafts subsume >>> draft-clemm-netmod-mount. If that’s not true, then absolutely there >>> should be a slot for that draft to be discussed as well. Please advise. >>> >>> Kent >>> >>> >>> >>> >>> >>> >>> On 2/3/16, 9:07 AM, "Robert Wilton" wrote: >>> >>>> Hi Kent, >>>> >>>> There is also another Yang Mount related draft: >>>> draft-clemm-netmod-mount-03 >>>> >>>> Now, this draft doesn't directly address the RTG DT Arch team use-case, >>>> and seems to cover two more complex problem scenarios (remote mount and >>>> alias mount), but these do appear to be a valid mount use cases (e.g. I >>>> think that it is used by OpenDaylight SDN controller), and I know that >>>> there is at least one implementation of this draft. >>>> >>>> So, I want to echo Eric Voit's comments that it would be good if >>>> whatever basic YANG mount draft we converge on is able to be cleanly >>>> extended to cover the more complex mount scenarios. >>>> >>>> As such, if Alex Clemm or Eric Voit are willing, I think that it would >>>> be useful if one of them could comment on how feasible it is to extend >>>> either netmod-structual-mount or netmod-ysdl to cover the remote mount >>>> and alias mount scenarios described in draft-clemm-netmod-mount-03. >>>> Hence, if they agree, do you think that you would be able to add a 15 >>>> min slot to the agenda to cover this please? >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>> On 03/02/2016 02:24, Kent Watsen wrote: >>>>> [Chair hat on] >>>>> >>>>> Given the number of competing/complementing drafts involved, and >>>>> the general lack of discussion on any of them, a virtual interim >>>>> meeting might be an expedient way to proceed. In fairness, we know >>>>> that there has been some discussion, but it hasn’t been picked up >>>>> yet in a big way, and now Lou has an updated draft. >>>>> >>>>> The chairs discussed maybe scheduling one for a couple weeks from >>>>> now, perhaps Thursday Feb 18 starting at 10am EST? I'm thinking >>>>> about this slot only since it worked for us for previously. Is >>>>> this a good time slot? I assume to schedule for 2 hours, with a >>>>> plan to end early if needed - makes sense? We also need to put >>>>> together a proper agenda, perhaps the following? >>>>> >>>>> 10 min: RTG DT YANG Arch team use-case summary >>>>> 20 min: draft-rtgyangdt-rtgwg-device-model >>>>> 20 min: draft-lhotka-netmod-ysdl >>>>> 20 min: draft-bjorklund-netmod-structural-mount >>>>> 50 min: general discussion or end early >>>>> >>>>> >>>>> We hope to schedule the meeting itself tomorrow or the next day, so >>>>> please respond quickly to this email if possible. >>>>> >>>>> Thanks, >>>>> Kent and Tom >>>>> >>>>> >>>>> >>>>> >>>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>>>> wrote: >>>>> >>>>>> I thought it would be worth summarizing what we're looking for in >>>>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version >>>>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl >>>>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my >>>>>> view, so my co-authors may wish to chime in and correct me. >>>>>> >>>>>> I'd be interested in hearing from the authors of YSDL and >>>>>> structural-mount, or anyone else for that matter, on how they see to >>>>>> best meet these needs. >>>>>> >>>>>> Here's what I think our draft needs: >>>>>> >>>>>> 1. that there be a mechanism that allows the incorporation (or >>>>>> 'mounting') of the data model defined by one top-level module >>>>>> within another module. >>>>>> >>>>>> The implication here is that when information is instantiated >>>>>> for the parent model it is also instantiated for the >>>>>> incorporated/mounted model. In our case we expect to do this on >>>>>> list element creation. Both solutions drafts cover the path >>>>>> implications, so these are not repeated here. >>>>>> >>>>>> 2. that this mechanism allow identification of specific modules to >>>>>> be incorporated/mounted at time of module definition, i.e. that >>>>>> no additional module is needed to support 1. This doesn't >>>>>> preclude definition of such a module. >>>>>> >>>>>> 3. that this mechanism allow for a server to control (and >>>>>> identify) which modules are incorporated/mounted. (see Section >>>>>> 3 LNE in our draft for an envisioned usage.) >>>>>> >>>>>> 4. that all capabilities that exist with the mounted module are >>>>>> available e.g. RPC operations and notifications. >>>>>> >>>>>> 5. while our primary requirement is for 'mounting' of top level >>>>>> modules, mounting of submodules may also be useful. (DT not draft >>>>>> driven.) >>>>>> >>>>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>>>> We see having a solution as critical for the >>>>>> simplifications/flexibility represented in the -02 version of our >>>>>> draft vs the -03 rev. We don't see wither solution draft as >>>>>> significantly different and just hope for a standard solution as >>>>>> soon as possible. (a draft-ietf-netmod solutions draft on the topic >>>>>> by BA would be fantastic given the impact on routing area -- even if >>>>>> it had to document two variations / alternative solutions.) >>>>>> >>>>>> Again, this is just my opinion and my coauthors or others on the rtg >>>>>> area yang DT may choose to chime in. >>>>>> >>>>>> Lou >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Feb 4 04:11:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB431B2CDB for ; Thu, 4 Feb 2016 04:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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, RP_MATCHES_RCVD=-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 nFXZYU1twJ5p for ; Thu, 4 Feb 2016 04:11:28 -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 765AA1B2C3B for ; Thu, 4 Feb 2016 04:11:28 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:9c05:40bf:2df4:8757] (unknown [IPv6:2001:718:1a02:1:9c05:40bf:2df4:8757]) by mail.nic.cz (Postfix) with ESMTPSA id 37905180C46; Thu, 4 Feb 2016 13:11:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454587886; bh=hCzTA68Q/ImQCcdkcrvyk1Rzdvu3A4xgL6UHNnm5P2A=; h=From:Date:To; b=FTBEOziYQ9KhJ7R7y8+bh0t4VcOOznedYM6Ud4mMIbXGt/f4bI3Hn2ncdxwuRE0lG NMSPk5zgAW2Ra7ZNOiiJPAWX6xCcZX+CKjz8vaD0yH+egBZIICT2zzYxogR8sRm2X1 SYo+ozkcIBkkr+olXJthsWMmDtZ+fcGdJiq4Dd7I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <152ac2e6df0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Thu, 4 Feb 2016 13:11:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152aa883418.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <56B3206B.7070000@cisco.com> <152ac2e6df0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Lou Berger 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] Yang mount / ysdl example use case 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, 04 Feb 2016 12:11:31 -0000 > On 04 Feb 2016, at 13:07, Lou Berger wrote: >=20 > Rob, >=20 >=20 > On February 4, 2016 4:57:24 AM Robert Wilton = wrote: >=20 >> Hi, >>=20 >> I wasn't actually suggesting that Alex's YANG mount draft be = considered >> as a solution here. I think that this draft is probably sufficiently >> complex that it would require a lot WG discussion and hence take too >> long to standardize to meet the RTG DT requirements. >>=20 >> Hence, I envisage that we'll end up with two drafts: >> 1) A basic mount draft - based on either Martin's Structural Mount = or >> Lada's Ysdl drafts. >> 2) A revision of Alex's YANG mount draft that extends from the base >> mount draft (1) above to cover alias and peer mount. >>=20 >> The meeting should focus on (1). >>=20 >> But what I am suggesting is for either Alex or Eric to evaluate both >> Martin's Structural Mount and Lada's Ysdl to determine whether either = of >> the drafts are particularly better/easier/cleaner to extend to cover = the >> Alias and Peer mount use cases covered in Alex's YANG mount draft, = since >> that might be useful to help identify which of (Martin's Structural >> Mount of Lada's Ysdl) should be chosen as a starting point as a WG = solution. >>=20 >> I hope this clarifies my previous request. >>=20 >=20 > Yes. Although to me a merging may be more appropriate/likely then = picking one. I agree. Lada >=20 > Lou >=20 >> Rob >>=20 >>=20 >> On 04/02/2016 04:26, Lou Berger wrote: >>> Alex, >>>=20 >>>=20 >>> On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" >>> wrote: >>>=20 >>>> Hi Kent, >>>>=20 >>>> I do think that we should have a slot for that draft as well. The >>>> structural mount case is a variation of the alias mount case; >>>=20 >>> Insofar as much that Structural mount and YSDL both have a model = that >>> is used to control their mount functions there is similarity, but >>> there is a fundamental difference that the other documents cover a >>> schema being mounted not a datastore. Scheme mount is really a = better >>> term than structural mount... >>>=20 >>> Also for our use case we don't want to use a different/ additional = model. >>>=20 >>> That said covering alias and remote mount if there is time in the >>> interim would be fine with me, but not at the expense of identifying = a >>> preferred approach of enabling the same amount that we are making = use >>> of in our draft. >>>=20 >>> Lou >>>=20 >>>> it is certainly possible to have a continuum of solutions that = allows >>>> to incorporate structural mount as well as alias mount and peer = mount >>>> (the latter possibly at a later point). >>>>=20 >>>> At the core in each case is the =E2=80=9Cmountpoint=E2=80=9D = construct / YANG >>>> extension, which was first introduced in the peer-mount draft and >>>> which also appears in the structured-mount draft. In peer-mount, = we >>>> also introduced two additional arguments/ extension in addition: = the >>>> subtree (used for alias mount), and the target (for peer mount =E2=80= =93 >>>> building on top, for when it is required). In the discussions = since, >>>> it became clear that there is also a use case where you don=E2=80=99t= need an >>>> alias, where it is sufficient to just mount a module and = instantiate >>>> it right under the mount point. This is the case that Martin put = in >>>> his draft. So, there is really a continuum: a case of a mountpoint >>>> with no argument (structural mount - the new draft), with one >>>> argument (alias), and with two (peer) (the earlier draft). >>>>=20 >>>> --- Alex >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>>> Sent: Wednesday, February 03, 2016 11:27 AM >>>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) >>>> >>>> Cc: Lou Berger ; netmod WG ; >>>> Alexander Clemm (alex) ; Eric Voit (evoit) >>>> >>>> Subject: Re: [netmod] Yang mount / ysdl example use case >>>>=20 >>>>=20 >>>> I was led to believe that the current set of drafts subsume >>>> draft-clemm-netmod-mount. If that=E2=80=99s not true, then = absolutely there >>>> should be a slot for that draft to be discussed as well. Please = advise. >>>>=20 >>>> Kent >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2/3/16, 9:07 AM, "Robert Wilton" wrote: >>>>=20 >>>>> Hi Kent, >>>>>=20 >>>>> There is also another Yang Mount related draft: >>>>> draft-clemm-netmod-mount-03 >>>>>=20 >>>>> Now, this draft doesn't directly address the RTG DT Arch team = use-case, >>>>> and seems to cover two more complex problem scenarios (remote = mount and >>>>> alias mount), but these do appear to be a valid mount use cases = (e.g. I >>>>> think that it is used by OpenDaylight SDN controller), and I know = that >>>>> there is at least one implementation of this draft. >>>>>=20 >>>>> So, I want to echo Eric Voit's comments that it would be good if >>>>> whatever basic YANG mount draft we converge on is able to be = cleanly >>>>> extended to cover the more complex mount scenarios. >>>>>=20 >>>>> As such, if Alex Clemm or Eric Voit are willing, I think that it = would >>>>> be useful if one of them could comment on how feasible it is to = extend >>>>> either netmod-structual-mount or netmod-ysdl to cover the remote = mount >>>>> and alias mount scenarios described in = draft-clemm-netmod-mount-03. >>>>> Hence, if they agree, do you think that you would be able to add a = 15 >>>>> min slot to the agenda to cover this please? >>>>>=20 >>>>> Thanks, >>>>> Rob >>>>>=20 >>>>>=20 >>>>> On 03/02/2016 02:24, Kent Watsen wrote: >>>>>> [Chair hat on] >>>>>>=20 >>>>>> Given the number of competing/complementing drafts involved, and >>>>>> the general lack of discussion on any of them, a virtual interim >>>>>> meeting might be an expedient way to proceed. In fairness, we = know >>>>>> that there has been some discussion, but it hasn=E2=80=99t been = picked up >>>>>> yet in a big way, and now Lou has an updated draft. >>>>>>=20 >>>>>> The chairs discussed maybe scheduling one for a couple weeks from >>>>>> now, perhaps Thursday Feb 18 starting at 10am EST? I'm thinking >>>>>> about this slot only since it worked for us for previously. Is >>>>>> this a good time slot? I assume to schedule for 2 hours, with a >>>>>> plan to end early if needed - makes sense? We also need to = put >>>>>> together a proper agenda, perhaps the following? >>>>>>=20 >>>>>> 10 min: RTG DT YANG Arch team use-case summary >>>>>> 20 min: draft-rtgyangdt-rtgwg-device-model >>>>>> 20 min: draft-lhotka-netmod-ysdl >>>>>> 20 min: draft-bjorklund-netmod-structural-mount >>>>>> 50 min: general discussion or end early >>>>>>=20 >>>>>>=20 >>>>>> We hope to schedule the meeting itself tomorrow or the next day, = so >>>>>> please respond quickly to this email if possible. >>>>>>=20 >>>>>> Thanks, >>>>>> Kent and Tom >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>>>>> wrote: >>>>>>=20 >>>>>>> I thought it would be worth summarizing what we're looking for = in >>>>>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new = version >>>>>>> in case you missed it) with respect to the = draft-lhotka-netmod-ysdl >>>>>>> and draft-bjorklund-netmod-structural-mount drafts. This is just = my >>>>>>> view, so my co-authors may wish to chime in and correct me. >>>>>>>=20 >>>>>>> I'd be interested in hearing from the authors of YSDL and >>>>>>> structural-mount, or anyone else for that matter, on how they = see to >>>>>>> best meet these needs. >>>>>>>=20 >>>>>>> Here's what I think our draft needs: >>>>>>>=20 >>>>>>> 1. that there be a mechanism that allows the incorporation (or >>>>>>> 'mounting') of the data model defined by one top-level module >>>>>>> within another module. >>>>>>>=20 >>>>>>> The implication here is that when information is instantiated >>>>>>> for the parent model it is also instantiated for the >>>>>>> incorporated/mounted model. In our case we expect to do this = on >>>>>>> list element creation. Both solutions drafts cover the path >>>>>>> implications, so these are not repeated here. >>>>>>>=20 >>>>>>> 2. that this mechanism allow identification of specific modules = to >>>>>>> be incorporated/mounted at time of module definition, i.e. = that >>>>>>> no additional module is needed to support 1. This doesn't >>>>>>> preclude definition of such a module. >>>>>>>=20 >>>>>>> 3. that this mechanism allow for a server to control (and >>>>>>> identify) which modules are incorporated/mounted. (see Section >>>>>>> 3 LNE in our draft for an envisioned usage.) >>>>>>>=20 >>>>>>> 4. that all capabilities that exist with the mounted module are >>>>>>> available e.g. RPC operations and notifications. >>>>>>>=20 >>>>>>> 5. while our primary requirement is for 'mounting' of top level >>>>>>> modules, mounting of submodules may also be useful. (DT not = draft >>>>>>> driven.) >>>>>>>=20 >>>>>>> We make use of the above in sections 3 and 4 of = rtgwg-device-model. >>>>>>> We see having a solution as critical for the >>>>>>> simplifications/flexibility represented in the -02 version of = our >>>>>>> draft vs the -03 rev. We don't see wither solution draft as >>>>>>> significantly different and just hope for a standard solution as >>>>>>> soon as possible. (a draft-ietf-netmod solutions draft on the = topic >>>>>>> by BA would be fantastic given the impact on routing area -- = even if >>>>>>> it had to document two variations / alternative solutions.) >>>>>>>=20 >>>>>>> Again, this is just my opinion and my coauthors or others on the = rtg >>>>>>> area yang DT may choose to chime in. >>>>>>>=20 >>>>>>> Lou >>>>>>>=20 >>>>>>>=20 >>>>>>>=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 >>>=20 >>>=20 >>> . >>>=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 Thu Feb 4 04:53:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960F1B2E6B for ; Thu, 4 Feb 2016 04:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 Oae7f-7uEj7u for ; Thu, 4 Feb 2016 04:53:31 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 5193B1B2E68 for ; Thu, 4 Feb 2016 04:53:31 -0800 (PST) Received: (qmail 29607 invoked by uid 0); 4 Feb 2016 12:46:51 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Feb 2016 12:46:51 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ECmj1s0092SSUrH01CmmF9; Thu, 04 Feb 2016 05:46:49 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=ufFehVJd_GgA:10 a=jFJIQSaiL_oA:10 a=wU2YTnxGAAAA:8 a=CsXaF2beQ9IgcOYZ6fQA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=i0ZmWqOdLqyH76shMHSuz/QIlCQL+/TU0wJV90qmtWE=; b=XCChue+cdPe2GcFGDwK6lCtF5RmKib/KIdYAUnr9WjCcve0Tp0StaI1pYCiivC1pQOZVfQQVO/3t5452jztkAgSwKhuXlgfLWL8RbVe4QLn4EzX4LILSpvPTsahtHuys; Received: from [172.58.185.33] (port=61991 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aRJJ6-0001fw-GA; Thu, 04 Feb 2016 05:46:44 -0700 From: Lou Berger To: Ladislav Lhotka , netmod WG Date: Thu, 04 Feb 2016 07:46:39 -0500 Message-ID: <152ac51f798.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <56B0FDAC.3090100@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.58.185.33 authed with lberger@labn.net} Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 12:53:32 -0000 Lada, Thank you for the response. See below. On February 4, 2016 6:39:11 AM Ladislav Lhotka wrote: > Hi Lou, > > Lou Berger writes: > >> I thought it would be worth summarizing what we're looking for in our >> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case >> you missed it) with respect to the draft-lhotka-netmod-ysdl and >> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so >> my co-authors may wish to chime in and correct me. >> >> I'd be interested in hearing from the authors of YSDL and >> structural-mount, or anyone else for that matter, on how they see to >> best meet these needs. >> >> Here's what I think our draft needs: >> >> 1. that there be a mechanism that allows the incorporation (or >> 'mounting') of the data model defined by one top-level module >> within another module. >> >> The implication here is that when information is instantiated >> for the parent model it is also instantiated for the >> incorporated/mounted model. In our case we expect to do this on >> list element creation. Both solutions drafts cover the path >> implications, so these are not repeated here. > > Both structural-mount and YSDL satisfy this. > Agree on the 1st paragraph but not the second. I think that like 2, neither support the second paragraph. >> >> 2. that this mechanism allow identification of specific modules to >> be incorporated/mounted at time of module definition, i.e. that >> no additional module is needed to support 1. This doesn't >> preclude definition of such a module. > > If I understand this correctly, then I believe that neither > structural-mount nor YSDL support it. This would require new built-in > statements in YANG, extensions aren't applicable here. > Agreed. >> >> 3. that this mechanism allow for a server to control (and >> identify) which modules are incorporated/mounted. (see Section >> 3 LNE in our draft for an envisioned usage.) > > Both structural-mount and YSDL satisfy this. > Great. >> >> 4. that all capabilities that exist with the mounted module are >> available e.g. RPC operations and notifications. > > Currently only structural-mount addresses this, YSDL can be extended > along the same lines. > Makes sense. >> >> 5. while our primary requirement is for 'mounting' of top level >> modules, mounting of submodules may also be useful. (DT not draft >> driven.) > > I don't think this is possible as long as both structural-mount and YSDL > take the information about available modules from yang-library. > > A solution to this could be to allow the "include" statement to appear > anywhere in the schema tree, but this is again YANG 2 stuff. Fair enough. This a longer term item and not critical for our draft. Thanks again, Lou > > Lada > >> >> We make use of the above in sections 3 and 4 of rtgwg-device-model. We >> see having a solution as critical for the simplifications/flexibility >> represented in the -02 version of our draft vs the -03 rev. We don't >> see wither solution draft as significantly different and just hope for a >> standard solution as soon as possible. (a draft-ietf-netmod solutions >> draft on the topic by BA would be fantastic given the impact on routing >> area -- even if it had to document two variations / alternative solutions.) >> >> Again, this is just my opinion and my coauthors or others on the rtg >> area yang DT may choose to chime in. >> >> Lou >> >> >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > From nobody Thu Feb 4 05:03:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B724F1B2E97; Thu, 4 Feb 2016 05:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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, RP_MATCHES_RCVD=-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 fWMVuFT5LXKS; Thu, 4 Feb 2016 05:02:57 -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 BCF4C1B2E96; Thu, 4 Feb 2016 05:02:56 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:9c05:40bf:2df4:8757] (unknown [IPv6:2001:718:1a02:1:9c05:40bf:2df4:8757]) by mail.nic.cz (Postfix) with ESMTPSA id 70E6D181437; Thu, 4 Feb 2016 14:02:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454590975; bh=gc2K7YB6Ket14T5gaPNQ4VRp5X7jSJWnhOEjVxp4KkM=; h=From:Date:To; b=xbTxJRI5orGbmdwfhz1HvuShXplL1l0CQ61gjt3eUT9VqrqBjxCFw+Fz1jjPcIe39 yLHecZVV486ZUhcJShLx3S8aCWIxhciTS3Mhbrs187wj2+6HeG/0djRuJGpLMssflx JklsJyUi+nB9qYNnbEsqiFcbECFj49owjF7x01Go= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <152ac51f798.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Thu, 4 Feb 2016 14:02:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C3C367F-91CF-4D62-AD66-F75A4DCA744D@nic.cz> References: <56B0FDAC.3090100@labn.net> <152ac51f798.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod WG , draft-lhotka-netmod-ysdl@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 13:02:59 -0000 > On 04 Feb 2016, at 13:46, Lou Berger wrote: >=20 > Lada, > Thank you for the response. See below. >=20 >=20 > On February 4, 2016 6:39:11 AM Ladislav Lhotka wrote: >=20 >> Hi Lou, >>=20 >> Lou Berger writes: >>=20 >>> I thought it would be worth summarizing what we're looking for in = our >>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in = case >>> you missed it) with respect to the draft-lhotka-netmod-ysdl and >>> draft-bjorklund-netmod-structural-mount drafts. This is just my = view, so >>> my co-authors may wish to chime in and correct me. >>>=20 >>> I'd be interested in hearing from the authors of YSDL and >>> structural-mount, or anyone else for that matter, on how they see to >>> best meet these needs. >>>=20 >>> Here's what I think our draft needs: >>>=20 >>> 1. that there be a mechanism that allows the incorporation (or >>> 'mounting') of the data model defined by one top-level module >>> within another module. >>>=20 >>> The implication here is that when information is instantiated >>> for the parent model it is also instantiated for the >>> incorporated/mounted model. In our case we expect to do this on >>> list element creation. Both solutions drafts cover the path >>> implications, so these are not repeated here. >>=20 >> Both structural-mount and YSDL satisfy this. >>=20 >=20 > Agree on the 1st paragraph but not the second. I think that like 2, = neither support the second paragraph. It depends on what you mean by instantiating. In YSDL, the schema is = known in advance and doesn't depend on any instances (except for "when" = statements, but this is no different from the current situation). Lada >=20 >>>=20 >>> 2. that this mechanism allow identification of specific modules to >>> be incorporated/mounted at time of module definition, i.e. that >>> no additional module is needed to support 1. This doesn't >>> preclude definition of such a module. >>=20 >> If I understand this correctly, then I believe that neither >> structural-mount nor YSDL support it. This would require new built-in >> statements in YANG, extensions aren't applicable here. >>=20 >=20 > Agreed. >=20 >>>=20 >>> 3. that this mechanism allow for a server to control (and >>> identify) which modules are incorporated/mounted. (see Section >>> 3 LNE in our draft for an envisioned usage.) >>=20 >> Both structural-mount and YSDL satisfy this. >>=20 >=20 > Great. >=20 >>>=20 >>> 4. that all capabilities that exist with the mounted module are >>> available e.g. RPC operations and notifications. >>=20 >> Currently only structural-mount addresses this, YSDL can be extended >> along the same lines. >>=20 >=20 > Makes sense. >=20 >>>=20 >>> 5. while our primary requirement is for 'mounting' of top level >>> modules, mounting of submodules may also be useful. (DT not draft >>> driven.) >>=20 >> I don't think this is possible as long as both structural-mount and = YSDL >> take the information about available modules from yang-library. >>=20 >> A solution to this could be to allow the "include" statement to = appear >> anywhere in the schema tree, but this is again YANG 2 stuff. >=20 > Fair enough. This a longer term item and not critical for our draft. >=20 > Thanks again, > Lou >=20 >>=20 >> Lada >>=20 >>>=20 >>> We make use of the above in sections 3 and 4 of rtgwg-device-model. = We >>> see having a solution as critical for the = simplifications/flexibility >>> represented in the -02 version of our draft vs the -03 rev. We = don't >>> see wither solution draft as significantly different and just hope = for a >>> standard solution as soon as possible. (a draft-ietf-netmod = solutions >>> draft on the topic by BA would be fantastic given the impact on = routing >>> area -- even if it had to document two variations / alternative = solutions.) >>>=20 >>> Again, this is just my opinion and my coauthors or others on the rtg >>> area yang DT may choose to chime in. >>>=20 >>> Lou >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 4 05:07:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFC1B2EA7 for ; Thu, 4 Feb 2016 05:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 xB_a2kFR4bDL for ; Thu, 4 Feb 2016 05:07:34 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 486611A89B0 for ; Thu, 4 Feb 2016 05:07:34 -0800 (PST) Received: (qmail 4494 invoked by uid 0); 4 Feb 2016 13:02:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 4 Feb 2016 13:02:44 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ED2b1s00T2SSUrH01D2eR0; Thu, 04 Feb 2016 06:02:44 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=s_MIiaj69Wwc1qehogIA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=cgNC3+F04QFrLvSFgw3O/2k3DjZIn17KtR6J2O8ftr0=; b=Wh465Cliu3awU9g6BfkyVach1TOSytRO7z4ASY4TmIj1ECokG3J+Es0KRnsuSfHqlGPyzfxNAOheHPxsJCGKaeq7s0wtvkDhzNXgeOzAvnS4AiguVBMUjDaVQxklyTip; Received: from box313.bluehost.com ([69.89.31.113]:59182 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRJYR-0004Mj-7N; Thu, 04 Feb 2016 06:02:35 -0700 To: netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> From: Lou Berger Message-ID: <56B34BE2.6090205@labn.net> Date: Thu, 4 Feb 2016 08:02:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204120028.GC21573@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 13:07:36 -0000 Juergen, See below. On 2/4/2016 7:00 AM, Juergen Schoenwaelder wrote: > On Tue, Feb 02, 2016 at 02:04:12PM -0500, Lou Berger wrote: >> 5. while our primary requirement is for 'mounting' of top level >> modules, mounting of submodules may also be useful. (DT not draft >> driven.) >> > A YANG submodule is by definition incomplete. For example, a submodule > does not have a defined namespace. I think we should not waste effort > to expose submodules beyond what they were designed to be used for - > to break a really large module into pieces that can be edited more > easily independently. > > If more granular mounts are needed, then we should IMHO _not_ bundle > this with the notion of YANG submodules. Perhaps you meant submodules > in a more generic way, but then perhaps: > > s/of submodules/of parts of modules/ yes. > > Reading the other text again, I am not sure what is meant by the > phrase "incorporation of the data model defined by one top-level > module". What exactly is a 'top-level module' (and does it matter, interfaces. > why > can I not mount a non-top-level module)? Good question. This should be added to 5, i.e., a good capability, but not used by our draft. > And does 'incorporation of > the data model' imply 'incorporation of the complete data model'? to me these two are the same, so yes -- unless you are implying something I'm missing ;-) Cheers, Lou > /js > From nobody Thu Feb 4 06:12:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E859B1B2FEB; Thu, 4 Feb 2016 06:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HyMG3K29Iv1A; Thu, 4 Feb 2016 06:12:15 -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 B5B9E1B2FE7; Thu, 4 Feb 2016 06:12:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C15B1551; Thu, 4 Feb 2016 15:12:13 +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 Z-GT3aaL9KU3; Thu, 4 Feb 2016 15:12:12 +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, 4 Feb 2016 15:12:12 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 771A62003A; Thu, 4 Feb 2016 15:12:12 +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 9CFTrGHW1TRY; Thu, 4 Feb 2016 15:12:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BE320013; Thu, 4 Feb 2016 15:12:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 019EC39DEFA0; Thu, 4 Feb 2016 15:12:09 +0100 (CET) Date: Thu, 4 Feb 2016 15:12:09 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160204141209.GA21868@elstar.local> Mail-Followup-To: Lou Berger , netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B34BE2.6090205@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 14:12:17 -0000 On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: > > > > If more granular mounts are needed, then we should IMHO _not_ bundle > > this with the notion of YANG submodules. Perhaps you meant submodules > > in a more generic way, but then perhaps: > > > > s/of submodules/of parts of modules/ > yes. OK - so I will read submodules as 'parts of modules'. > > Reading the other text again, I am not sure what is meant by the > > phrase "incorporation of the data model defined by one top-level > > module". What exactly is a 'top-level module' (and does it matter, > interfaces. An example does not define the term. Please define 'top-level module' so we can actually understand what we are talking about. > > why > > can I not mount a non-top-level module)? > Good question. This should be added to 5, i.e., a good capability, but > not used by our draft. I can't tell until I am told what a 'top-level module' is and what a 'non-top-level module' is. > > And does 'incorporation of > > the data model' imply 'incorporation of the complete data model'? > to me these two are the same, so yes -- unless you are implying > something I'm missing ;-) I am trying to understand and I am trying to avoid discussions where people talk past each other because of different interpretations of the words they use. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 4 06:19:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D251B2FE8; Thu, 4 Feb 2016 06:19:52 -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, RP_MATCHES_RCVD=-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 zrVh2uYiLoLB; Thu, 4 Feb 2016 06:19:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F00581B301F; Thu, 4 Feb 2016 06:19:46 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 69D351AE030D; Thu, 4 Feb 2016 15:19:45 +0100 (CET) Date: Thu, 04 Feb 2016 15:19:48 +0100 (CET) Message-Id: <20160204.151948.2242217199733430427.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <152ac51f798.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <56B0FDAC.3090100@labn.net> <152ac51f798.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.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: draft-rtgyangdt-rtgwg-device-model@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, netmod@ietf.org, draft-lhotka-netmod-ysdl@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 14:19:52 -0000 Hi, Lou Berger wrote: > Lada, > Thank you for the response. See below. > > > On February 4, 2016 6:39:11 AM Ladislav Lhotka wrote: > > > Hi Lou, > > > > Lou Berger writes: > > > >> I thought it would be worth summarizing what we're looking for in our > >> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case > >> you missed it) with respect to the draft-lhotka-netmod-ysdl and > >> draft-bjorklund-netmod-structural-mount drafts. This is just my view, > >> so > >> my co-authors may wish to chime in and correct me. > >> > >> I'd be interested in hearing from the authors of YSDL and > >> structural-mount, or anyone else for that matter, on how they see to > >> best meet these needs. > >> > >> Here's what I think our draft needs: > >> > >> 1. that there be a mechanism that allows the incorporation (or > >> 'mounting') of the data model defined by one top-level module > >> within another module. > >> > >> The implication here is that when information is instantiated > >> for the parent model it is also instantiated for the > >> incorporated/mounted model. In our case we expect to do this on > >> list element creation. Both solutions drafts cover the path > >> implications, so these are not repeated here. > > > > Both structural-mount and YSDL satisfy this. > > > > Agree on the 1st paragraph but not the second. I think that like 2, > neither support the second paragraph. I think that both structural-mount and ysdl satistfy this, in the sense that they support the schema defintion for this use case. The instantiation is something that happens in the implementation. /martin From nobody Thu Feb 4 06:53:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9757F1B30B1 for ; Thu, 4 Feb 2016 06:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 7fM5czV-7Rci for ; Thu, 4 Feb 2016 06:53:23 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 72EE81B30B0 for ; Thu, 4 Feb 2016 06:53:23 -0800 (PST) Received: (qmail 13401 invoked by uid 0); 4 Feb 2016 14:53:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 4 Feb 2016 14:53:22 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EEtK1s0042SSUrH01EtNFr; Thu, 04 Feb 2016 07:53:22 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=WC_SL_XrABnwpT0M6rUA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=6U04BTs0ESAH3G80jsMN+8qCzft3Q4qxHI6Bo9WLJ54=; b=deSqJAaCkRy9fXDrysx/lCN5Z3YTSaEoot5iq38eeuoSCr3WhNB/p4Q+7uoXON5onyJS6Gel0REpDDrSpvummBhUgj8b31/VAVV5hTRYg+N+J8Xy39aSUWYVM628Ycyt; Received: from box313.bluehost.com ([69.89.31.113]:54818 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRLHa-0004CG-VF; Thu, 04 Feb 2016 07:53:19 -0700 To: netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56B365D7.8060501@labn.net> Date: Thu, 4 Feb 2016 09:53:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204141209.GA21868@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 14:53:24 -0000 Juergen, see below. On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: > On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: >>> If more granular mounts are needed, then we should IMHO _not_ bundle >>> this with the notion of YANG submodules. Perhaps you meant submodules >>> in a more generic way, but then perhaps: >>> >>> s/of submodules/of parts of modules/ >> yes. > OK - so I will read submodules as 'parts of modules'. > >>> Reading the other text again, I am not sure what is meant by the >>> phrase "incorporation of the data model defined by one top-level >>> module". What exactly is a 'top-level module' (and does it matter, >> interfaces. > An example does not define the term. 100% agree - at least in drafts. > Please define 'top-level module' any module that defines a top-level node, or if you prefer a module that defines nodes at the XPath root node. > so we can actually understand what we are talking about. If you don't like either formation, I suspect at this point you know what I mean, so please propose alternate language that works for you and I'll confirm that/if it works for me. Thanks, Lou > >>> why >>> can I not mount a non-top-level module)? >> Good question. This should be added to 5, i.e., a good capability, but >> not used by our draft. > I can't tell until I am told what a 'top-level module' is and what a > 'non-top-level module' is. > >>> And does 'incorporation of >>> the data model' imply 'incorporation of the complete data model'? >> to me these two are the same, so yes -- unless you are implying >> something I'm missing ;-) > I am trying to understand and I am trying to avoid discussions where > people talk past each other because of different interpretations of > the words they use. > > /js > From nobody Thu Feb 4 08:12:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B2F1ACE25; Thu, 4 Feb 2016 08:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 V1FZlCL813EY; Thu, 4 Feb 2016 08:12: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 C19571ACDDA; Thu, 4 Feb 2016 08:12:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8DC6313BF; Thu, 4 Feb 2016 17:12: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 fkgNxcdcLf2U; Thu, 4 Feb 2016 17:12: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; Thu, 4 Feb 2016 17:12:32 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A50B220031; Thu, 4 Feb 2016 17:12:32 +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 DrUQhteVrYOy; Thu, 4 Feb 2016 17:12: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 1188320013; Thu, 4 Feb 2016 17:12:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 73F4D39DF152; Thu, 4 Feb 2016 17:12:31 +0100 (CET) Date: Thu, 4 Feb 2016 17:12:31 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160204161231.GC22049@elstar.local> Mail-Followup-To: Lou Berger , netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B365D7.8060501@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 16:12:36 -0000 On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: > Juergen, > > see below. > > On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: > > On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: > >>> If more granular mounts are needed, then we should IMHO _not_ bundle > >>> this with the notion of YANG submodules. Perhaps you meant submodules > >>> in a more generic way, but then perhaps: > >>> > >>> s/of submodules/of parts of modules/ > >> yes. > > OK - so I will read submodules as 'parts of modules'. > > > >>> Reading the other text again, I am not sure what is meant by the > >>> phrase "incorporation of the data model defined by one top-level > >>> module". What exactly is a 'top-level module' (and does it matter, > >> interfaces. > > An example does not define the term. > 100% agree - at least in drafts. > > > Please define 'top-level module' > any module that defines a top-level node, or if you prefer a module that > defines nodes at the XPath root node. > > > so we can actually understand what we are talking about. > > If you don't like either formation, I suspect at this point you know > what I mean, so please propose alternate language that works for you and > I'll confirm that/if it works for me. Cool. So if I mount ietf-interfaces (a top-level module) into some other place, what happens to all the data models that augment ietf-interfaces with interface specific objects, like the ietf-ip module (a non-top-level module)? I fail to see why this distinction between top-level modules and non-top-level modules is useful. /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 Feb 4 08:40:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E926E1B32C7 for ; Thu, 4 Feb 2016 08:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 po-3P-x-m8e1 for ; Thu, 4 Feb 2016 08:40:09 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 4C43A1B32C2 for ; Thu, 4 Feb 2016 08:40:03 -0800 (PST) Received: (qmail 5090 invoked by uid 0); 4 Feb 2016 16:33:23 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 4 Feb 2016 16:33:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EGZH1s00l2SSUrH01GZLmk; Thu, 04 Feb 2016 09:33:23 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=qMtSApAM-Mwe6Z56GekA:9 a=XTbugd3-8H3Opdmf:21 a=N5lIf2MeLv6JzTBv:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=PsYbhmuKlRbxzxVu/MbHHiWw/uKr6Sm+myiosHbsb+I=; b=noF6+9WNs6logi4UZiUjJfEOYyL528OqQnzI+10uGDizXS4xf2n0nVTMvKfOMxcGuLE75jTCoi2g3EYG+XCH3ZFNy3yvrRvSj+vu8PtX+kIgOGBo+5pcD2B8qFOAv+oK; Received: from box313.bluehost.com ([69.89.31.113]:58868 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRMqL-0002HD-D1; Thu, 04 Feb 2016 09:33:17 -0700 To: netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> From: Lou Berger Message-ID: <56B37D48.10707@labn.net> Date: Thu, 4 Feb 2016 11:33:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204161231.GC22049@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 16:40:10 -0000 Juergen, see below On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: > On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: >> Juergen, >> >> see below. >> >> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: >>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: >>>>> If more granular mounts are needed, then we should IMHO _not_ bundle >>>>> this with the notion of YANG submodules. Perhaps you meant submodules >>>>> in a more generic way, but then perhaps: >>>>> >>>>> s/of submodules/of parts of modules/ >>>> yes. >>> OK - so I will read submodules as 'parts of modules'. >>> >>>>> Reading the other text again, I am not sure what is meant by the >>>>> phrase "incorporation of the data model defined by one top-level >>>>> module". What exactly is a 'top-level module' (and does it matter, >>>> interfaces. >>> An example does not define the term. >> 100% agree - at least in drafts. >> >>> Please define 'top-level module' >> any module that defines a top-level node, or if you prefer a module that >> defines nodes at the XPath root node. >> >>> so we can actually understand what we are talking about. >> If you don't like either formation, I suspect at this point you know >> what I mean, so please propose alternate language that works for you and >> I'll confirm that/if it works for me. > Cool. So if I mount ietf-interfaces (a top-level module) into some > other place, what happens to all the data models that augment > ietf-interfaces with interface specific objects, like the ietf-ip > module (a non-top-level module)? they are allowed/supported in the same way that they would be today, just with the modifications/rewrite of their base models. > > I fail to see why this distinction between top-level modules and > non-top-level modules is useful. I'm describing a single use case, which only requires top-level support, not all desirable capabilities or a solution. Lou > /js > From nobody Thu Feb 4 08:46:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BBF1B32A9; Thu, 4 Feb 2016 08:46:52 -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, RP_MATCHES_RCVD=-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 jIIV1wNEzIXc; Thu, 4 Feb 2016 08:46:50 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9A1B32B4; Thu, 4 Feb 2016 08:46:49 -0800 (PST) Received: from tops.chopps.org (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 04DFB61F70; Thu, 4 Feb 2016 16:46:48 +0000 (UTC) References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> User-agent: mu4e 0.9.17; emacs 24.5.1 From: To: Lou Berger In-reply-to: <56B37D48.10707@labn.net> Date: Thu, 04 Feb 2016 11:46:47 -0500 Message-ID: <87h9hoo22w.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 16:46:52 -0000 --=-=-= Content-Type: text/plain Lou Berger writes: > Juergen, > > see below > > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: >> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: >>> Juergen, >>> >>> see below. >>> >>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: >>>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: >>>>>> If more granular mounts are needed, then we should IMHO _not_ bundle >>>>>> this with the notion of YANG submodules. Perhaps you meant submodules >>>>>> in a more generic way, but then perhaps: >>>>>> >>>>>> s/of submodules/of parts of modules/ >>>>> yes. >>>> OK - so I will read submodules as 'parts of modules'. >>>> >>>>>> Reading the other text again, I am not sure what is meant by the >>>>>> phrase "incorporation of the data model defined by one top-level >>>>>> module". What exactly is a 'top-level module' (and does it matter, >>>>> interfaces. >>>> An example does not define the term. >>> 100% agree - at least in drafts. >>> >>>> Please define 'top-level module' >>> any module that defines a top-level node, or if you prefer a module that >>> defines nodes at the XPath root node. >>> >>>> so we can actually understand what we are talking about. >>> If you don't like either formation, I suspect at this point you know >>> what I mean, so please propose alternate language that works for you and >>> I'll confirm that/if it works for me. >> Cool. So if I mount ietf-interfaces (a top-level module) into some >> other place, what happens to all the data models that augment >> ietf-interfaces with interface specific objects, like the ietf-ip >> module (a non-top-level module)? > > they are allowed/supported in the same way that they would be today, > just with the modifications/rewrite of their base models. > >> >> I fail to see why this distinction between top-level modules and >> non-top-level modules is useful. > > I'm describing a single use case, which only requires top-level support, > not all desirable capabilities or a solution. Hi Juergen, The top-level modules would carry the mounts of the non-top-level modules that are attached within them. I don't see this making sense any other way. The idea here is to support a parent device being able to mount a contained child device's modules and modify them external to the child devices normal management mechanism (e.g., not having to log into the child's netconf server). Given that, what's the use of talking about mounting "inner" modules? You have to mount the "outer" (or containing) module to be able to access them, and by mounting the containing module you gain access to the contained modules. At least that's how I picture this working. Thanks, Chris. > > Lou > >> /js >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWs4B3AAoJEC4dgw7XuDAlOcAP/2NEN6ad5J+qsvIXWY3sWLCm 58qTzfXWrdSYtxRYYG3RMFsz/TNp0L9W1CkXM4XJDRE6+uHmmta5rdG5oTx19jf0 tTs4NNg3s2k9y8RBWZuEbZf0nsb96frRWKfI/T92djt+0zqkLg0DntmVETttv/h/ 08iG+uWNrYicynwthAaA6r8iZ+BHA+ZQ8YbDqLIBvvtXNyEYeCDO8LjrkXT7VTrh CR/L9pufGzkt967806df8xzEIAM+Lkv8GAetBnizTLCPkU4g5RhmSMPsYrJGF2nM k05jcwRPEqoMLFm9pF6CpppGdJbsNmEyQIKc0/VGx12Nra6BOjp2RgIK3hn7f+So LhinHxZ3UG4uGM4WBmVmDmFW0F8DaTMvx6a7i/dk1FvxC3MrmJTBip/PBTJ1SsJE iBhj4N9OyihmeqzTQrDhAUTcD0+oFBA6h+pRTBGTlrMnjAHSiJJDGIhMl/L/wmDL GKJSpLxeZzbpDyCoGzf/MqtgeGu8+ZRsZmizIKOug1zGU+j559pnQCJ1S4uPHzIB L8ySM/MMvd492BaV5pS+hYh2PKPieUxLHRJmFzmlX9jCpPNd+K7rip0U8Mb+L8CI 8qgRmmS7DVwzjp1bqa8nCLxI1ICD3cdKa2eMnnhN3X5ue0g/yKC7Voq5ZuxbDE/P u2mf0a9UxC5L25UOOah/ =QSiA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 4 08:56:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFAC1B32DA; Thu, 4 Feb 2016 08:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zaO9ot6D66j4; Thu, 4 Feb 2016 08:56: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 0D0AA1B32E0; Thu, 4 Feb 2016 08:56: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 CF2F514D4; Thu, 4 Feb 2016 17:56: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 Gcscu236xChK; Thu, 4 Feb 2016 17:56: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; Thu, 4 Feb 2016 17:56:03 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9C9F2002B; Thu, 4 Feb 2016 17:56: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 qsmjM-4iSqCE; Thu, 4 Feb 2016 17:55: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 4B0DE20013; Thu, 4 Feb 2016 17:55:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8F97939DF259; Thu, 4 Feb 2016 17:55:51 +0100 (CET) Date: Thu, 4 Feb 2016 17:55:51 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160204165551.GE22049@elstar.local> Mail-Followup-To: Lou Berger , netmod WG , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B37D48.10707@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 16:56:11 -0000 On Thu, Feb 04, 2016 at 11:33:12AM -0500, Lou Berger wrote: > Juergen, > > see below > > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: > > On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: > >> Juergen, > >> > >> see below. > >> > >> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: > >>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: > >>>>> If more granular mounts are needed, then we should IMHO _not_ bundle > >>>>> this with the notion of YANG submodules. Perhaps you meant submodules > >>>>> in a more generic way, but then perhaps: > >>>>> > >>>>> s/of submodules/of parts of modules/ > >>>> yes. > >>> OK - so I will read submodules as 'parts of modules'. > >>> > >>>>> Reading the other text again, I am not sure what is meant by the > >>>>> phrase "incorporation of the data model defined by one top-level > >>>>> module". What exactly is a 'top-level module' (and does it matter, > >>>> interfaces. > >>> An example does not define the term. > >> 100% agree - at least in drafts. > >> > >>> Please define 'top-level module' > >> any module that defines a top-level node, or if you prefer a module that > >> defines nodes at the XPath root node. > >> > >>> so we can actually understand what we are talking about. > >> If you don't like either formation, I suspect at this point you know > >> what I mean, so please propose alternate language that works for you and > >> I'll confirm that/if it works for me. > > Cool. So if I mount ietf-interfaces (a top-level module) into some > > other place, what happens to all the data models that augment > > ietf-interfaces with interface specific objects, like the ietf-ip > > module (a non-top-level module)? > > they are allowed/supported in the same way that they would be today, > just with the modifications/rewrite of their base models. I thought you answered to "can I not mount a non-top-level module?" with "a good capability, but not used by our draft". > > I fail to see why this distinction between top-level modules and > > non-top-level modules is useful. > > I'm describing a single use case, which only requires top-level support, > not all desirable capabilities or a solution. So how does ietf-ip then work? I guess you assume that a mount of ietf-ip is implicit, that is by mounting ietf-interfaces you allow (or expect?) that some (or all?) augmentations of /if:interfaces etc. are mounted as well. Again, the I fail to see the value of classifying modules into top-level modules and non-top-level modules. I also think that thinking about mounts as all or nothing (you mount a complete module or nothing) is a questionable concept since we have modules with multiple "roots" and sometimes the bundling of "trees" into modules is subject to non-technical constraints (e.g., you will have modules that augment stuff but also create new roots and even more interesting is that we will see this to change over time, a module that was a non-top-level module may become a top-level module in a revision). I think we should try to avoid solutions that work only with certain classes of modules but not for others. /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 Feb 4 09:02:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699F1B3321; Thu, 4 Feb 2016 09:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 79odKNo4I0YE; Thu, 4 Feb 2016 09:02:54 -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 B04171B3320; Thu, 4 Feb 2016 09:02:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 01B6E1588; Thu, 4 Feb 2016 18:02:52 +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 W6fvZBIOTEsz; Thu, 4 Feb 2016 18:02:50 +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, 4 Feb 2016 18:02:50 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFCF62002B; Thu, 4 Feb 2016 18:02:50 +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 7A0W3csXzUN8; Thu, 4 Feb 2016 18:02:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66C9E20013; Thu, 4 Feb 2016 18:02:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BFCFE39DF293; Thu, 4 Feb 2016 18:02:49 +0100 (CET) Date: Thu, 4 Feb 2016 18:02:49 +0100 From: Juergen Schoenwaelder To: chopps@chopps.org Message-ID: <20160204170249.GA22319@elstar.local> Mail-Followup-To: chopps@chopps.org, Lou Berger , draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> <87h9hoo22w.fsf@tops.chopps.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9hoo22w.fsf@tops.chopps.org> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod WG , draft-lhotka-netmod-ysdl@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 17:02:55 -0000 On Thu, Feb 04, 2016 at 11:46:47AM -0500, chopps@chopps.org wrote: > > Lou Berger writes: > > > Juergen, > > > > see below > > > > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: > >> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: > >>> Juergen, > >>> > >>> see below. > >>> > >>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: > >>>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: > >>>>>> If more granular mounts are needed, then we should IMHO _not_ bundle > >>>>>> this with the notion of YANG submodules. Perhaps you meant submodules > >>>>>> in a more generic way, but then perhaps: > >>>>>> > >>>>>> s/of submodules/of parts of modules/ > >>>>> yes. > >>>> OK - so I will read submodules as 'parts of modules'. > >>>> > >>>>>> Reading the other text again, I am not sure what is meant by the > >>>>>> phrase "incorporation of the data model defined by one top-level > >>>>>> module". What exactly is a 'top-level module' (and does it matter, > >>>>> interfaces. > >>>> An example does not define the term. > >>> 100% agree - at least in drafts. > >>> > >>>> Please define 'top-level module' > >>> any module that defines a top-level node, or if you prefer a module that > >>> defines nodes at the XPath root node. > >>> > >>>> so we can actually understand what we are talking about. > >>> If you don't like either formation, I suspect at this point you know > >>> what I mean, so please propose alternate language that works for you and > >>> I'll confirm that/if it works for me. > >> Cool. So if I mount ietf-interfaces (a top-level module) into some > >> other place, what happens to all the data models that augment > >> ietf-interfaces with interface specific objects, like the ietf-ip > >> module (a non-top-level module)? > > > > they are allowed/supported in the same way that they would be today, > > just with the modifications/rewrite of their base models. > > > >> > >> I fail to see why this distinction between top-level modules and > >> non-top-level modules is useful. > > > > I'm describing a single use case, which only requires top-level support, > > not all desirable capabilities or a solution. > > Hi Juergen, > > The top-level modules would carry the mounts of the non-top-level > modules that are attached within them. I don't see this making sense any > other way. The idea here is to support a parent device being able to > mount a contained child device's modules and modify them external to the > child devices normal management mechanism (e.g., not having to log into > the child's netconf server). > > Given that, what's the use of talking about mounting "inner" modules? > You have to mount the "outer" (or containing) module to be able to > access them, and by mounting the containing module you gain access to the > contained modules. > > At least that's how I picture this working. > But even then, why do we need new terms? If you mount a path, then you mount a path in a datastore. Modules that do not define paths obviously then can't be mounted. How about this: module top-level-module { container top; } module non-top-level-module { import "top-level-module" { prefix top; } augment "/top:top/" { container second; } } Can I mount /top/second? Why would a solution be simpler if I make this impossible? /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 Feb 4 09:07:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723551B3330 for ; Thu, 4 Feb 2016 09:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 bFFoYmkMNSFR for ; Thu, 4 Feb 2016 09:07:55 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id C48121B332F for ; Thu, 4 Feb 2016 09:07:54 -0800 (PST) Received: (qmail 31588 invoked by uid 0); 4 Feb 2016 17:07:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 4 Feb 2016 17:07:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id EH7g1s0112SSUrH01H7jrY; Thu, 04 Feb 2016 10:07:47 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=UhPaxHoQ6jMu8genfSsA:9 a=pILNOxqGKmIA:10 a=eMuub7TVGncA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=tBV+z9HEbchNlwCRWnXQEX+2f4SD8ftP0JLYBUCVQ2I=; b=UPBkebRDcieek/70bmudPLoUu1ojzV/hqJ/KdN+0UiXjwhH4cvTP+dY909pjoIe4tkSTsjlyxC022l2Eqeh+XMBdcKW0im9j68IYsbePmEWIUbVsxti2wJV6Kaj/FSxO; Received: from box313.bluehost.com ([69.89.31.113]:42598 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRNNe-0003nK-Cu; Thu, 04 Feb 2016 10:07:42 -0700 To: chopps@chopps.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> <87h9hoo22w.fsf@tops.chopps.org> <20160204170249.GA22319@elstar.local> From: Lou Berger Message-ID: <56B38554.2040907@labn.net> Date: Thu, 4 Feb 2016 12:07:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204170249.GA22319@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 17:07:56 -0000 On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote: > Can I mount /top/second? yes. But in our use case, we wouldn't explicitly do a mount here. but we would allow a server may choose to support it. > Why would a solution be simpler if I make > this impossible? We're not suggest this. We're stating what we require, not what we preclude. So a solution that supports non-top-level is just fine too. Lou From nobody Thu Feb 4 11:09:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F51ACDC1; Thu, 4 Feb 2016 11:09:17 -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 SpU-Qx2_dMhU; Thu, 4 Feb 2016 11:09:15 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 97A6E1ACDB1; Thu, 4 Feb 2016 11:09:15 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id o185so53986470pfb.1; Thu, 04 Feb 2016 11:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=w1oujLD1FKzx2I4W/8VG4uwsRSghKrEVhyA+kpv+UKo=; b=ZZdkRaskR4OsCL5Q3gRvtsgy6rGxqwOKEIeU4jjGRzGnsTO3ka6L4iK07s4Th1I/XT 80l/cg8gojjZhQH52fGCkcunDpq+HY8DwM3dV4sMY5V9s/MPsrYjEUtgyhRMYg0niYZu Jpcrzrba9OpATNKGDq0Z8iIe1BC9DeYu5fQwc2+uPdWe3XOmkIhSLYUOLk05z8vCl4o+ Z0AC7U/q8G3niUB2MsPJ1kCfAITjpbVI5M+k819qVcbmq0y7dQdg5gEH4tVv0odMQPQu mhKMIqWHv3ezid3c+LS/8kB92Uj4u3O56bN2kIDq38LyEdJ4axAKJJo9u9DxTGocJ4NW 0g9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=w1oujLD1FKzx2I4W/8VG4uwsRSghKrEVhyA+kpv+UKo=; b=ASgbXLTunxc9+t2NGuYpodXoGJYH9n5FhVr5KgEZFksAclYwKaE3zV6iVJzkjccBQc Y+51OuhpoaopxfSMKcAD/+ofLHlE5tCbAaynU1O7chceky5DsIs0Q7i60K4dXmIOGqRt RDXvfX2hhwegHwfpyDtSl/1zlIC83+h1T/NqS1WSY9dmAITmKUsRtcQxUE/9cvU6hrWi Ha7GNp5IP9FjGhvOvxwVAFARbypXrNbzCJ+pkPz62AAttkIDpW6jkWXet9q27GnGke2U mD5hZJHrMoCmpS5QPa7DJIZnynR2+bFmc9dR8QsBqudvy6Hmr4vpkfX37HY+k8qZtlqy 19Ig== X-Gm-Message-State: AG10YORuwKU/3p2BEM4GkWeNt81awyz6hFwtS1o7Ikxc9jG3BsJN2jbWy2UFEfqI+L70MQ== X-Received: by 10.66.227.73 with SMTP id ry9mr13411451pac.120.1454612955324; Thu, 04 Feb 2016 11:09:15 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1004::442? ([2001:420:c0c8:1004::442]) by smtp.gmail.com with ESMTPSA id ud8sm11956415pac.11.2016.02.04.11.09.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Feb 2016 11:09:14 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9" Date: Thu, 4 Feb 2016 11:09:13 -0800 Message-Id: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> To: NETCONF Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: NETMOD Working Group Subject: [netmod] YANG library draft. WG check of last call edits 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, 04 Feb 2016 19:09:17 -0000 --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The yang-library draft went through a Last Call that ended January 22. = Martin has taken the suggestions from the last call comments and posted = an updated draft. https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = Please review it for the changes made to the draft and any edits that = were either missed or are not right. This would not be a time to bring = in new changes or comments. The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. Cheers. Mahesh & Mehmet. --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The yang-library draft went through a Last Call that ended = January 22. Martin has taken the suggestions from the last call comments = and posted an updated draft.

https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04<= /a>

Please = review it for the changes made to the draft and any edits that were = either missed or are not right. This would not be a time to bring in new = changes or comments.

The comment/review period will go till Monday, February 15, = at which time it will be sent to our fearless AD, Benoit Claise for = publication.

Cheers.

Mahesh & Mehmet.



= --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9-- From nobody Thu Feb 4 11:13:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A51ACDD3; Thu, 4 Feb 2016 11:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 g_xavKQoD2bs; Thu, 4 Feb 2016 11:13:40 -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 02F541ACDD5; Thu, 4 Feb 2016 11:13:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5463148F; Thu, 4 Feb 2016 20:13:38 +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 ihZiLdc5Vq5N; Thu, 4 Feb 2016 20:13:38 +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, 4 Feb 2016 20:13:38 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11C532002B; Thu, 4 Feb 2016 20:13:38 +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 7bu7CRtmJOKv; Thu, 4 Feb 2016 20:13:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 186B020013; Thu, 4 Feb 2016 20:13:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7AFC939DF3A6; Thu, 4 Feb 2016 20:13:37 +0100 (CET) Date: Thu, 4 Feb 2016 20:13:37 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160204191337.GA22516@elstar.local> Mail-Followup-To: Lou Berger , chopps@chopps.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> <87h9hoo22w.fsf@tops.chopps.org> <20160204170249.GA22319@elstar.local> <56B38554.2040907@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B38554.2040907@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod WG , draft-lhotka-netmod-ysdl@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 19:13:42 -0000 On Thu, Feb 04, 2016 at 12:07:32PM -0500, Lou Berger wrote: > > > On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote: > > Can I mount /top/second? > yes. But in our use case, we wouldn't explicitly do a mount here. but we > would allow a server may choose to support it. > > > Why would a solution be simpler if I make > > this impossible? > > We're not suggest this. We're stating what we require, not what we > preclude. So a solution that supports non-top-level is just fine too. > So is the outcome of this discussion that you wanted to express that it is sufficient for your use case to be able to mount nodes located directly below the root? In other words, you would mount /system out of ietf-system but you would never consider to mount, say, /system/ntp or /system/radius. If this is the outcome, then the text describing your use case requirement probably can be improved (the distinction between top-level module and non-top-level module is misleading since all you require is mount of top-level nodes). /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 Feb 4 11:31:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13B51ACE05 for ; Thu, 4 Feb 2016 11:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 iTzqdf9mYHsG for ; Thu, 4 Feb 2016 11:31:02 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 0C6D91ACE0B for ; Thu, 4 Feb 2016 11:31:01 -0800 (PST) Received: (qmail 13102 invoked by uid 0); 4 Feb 2016 19:31:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 4 Feb 2016 19:31:00 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EKWu1s00d2SSUrH01KWxW1; Thu, 04 Feb 2016 12:31:00 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=cq5JNzzm-YPGGmh6bXkA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=Y8elejeq9jlPmBso/4eKhZNI1YXvstlDGKfE/QCYXJQ=; b=vYjZ3s6CO3TBHo6qIBiy5g2jODyqRmn8R6OcKFjP9oSw0FkSYDdsjp2MEh381UZt1gxtXkCWQ4tKmP8lbAmqPmVy3LvrO5unUkdjArZaTJHbx1L78OABac5OdnaAsoQ2; Received: from box313.bluehost.com ([69.89.31.113]:55759 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRPcE-0008NO-H4; Thu, 04 Feb 2016 12:30:54 -0700 To: chopps@chopps.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> <87h9hoo22w.fsf@tops.chopps.org> <20160204170249.GA22319@elstar.local> <56B38554.2040907@labn.net> <20160204191337.GA22516@elstar.local> From: Lou Berger Message-ID: <56B3A6E6.6000801@labn.net> Date: Thu, 4 Feb 2016 14:30:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204191337.GA22516@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 19:31:04 -0000 Juergen, On 2/4/2016 2:13 PM, Juergen Schoenwaelder wrote: > On Thu, Feb 04, 2016 at 12:07:32PM -0500, Lou Berger wrote: >> >> On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote: >>> Can I mount /top/second? >> yes. But in our use case, we wouldn't explicitly do a mount here. but we >> would allow a server may choose to support it. >> >>> Why would a solution be simpler if I make >>> this impossible? >> We're not suggest this. We're stating what we require, not what we >> preclude. So a solution that supports non-top-level is just fine too. >> > So is the outcome of this discussion that you wanted to express that > it is sufficient for your use case to be able to mount nodes located > directly below the root? In other words, you would mount /system out > of ietf-system but you would never consider to mount, say, /system/ntp > or /system/radius. never is a strong word. it's more accurate to say we don't currently need in draft-... > If this is the outcome, then the text describing your use case > requirement probably can be improved (the distinction between > top-level module and non-top-level module is misleading since all you > require is mount of top-level nodes). The mail said it wasn't need by the document. Lou > /js > From nobody Thu Feb 4 12:19:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E284F1AD09B; Thu, 4 Feb 2016 12:19:41 -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, RP_MATCHES_RCVD=-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 tNqBFr68WTwH; Thu, 4 Feb 2016 12:19:40 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D88D1AD05F; Thu, 4 Feb 2016 12:19:40 -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 742BC1AE030D; Thu, 4 Feb 2016 21:19:38 +0100 (CET) Date: Thu, 04 Feb 2016 21:22:51 +0100 (CET) Message-Id: <20160204.212251.327145391331700368.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160204191337.GA22516@elstar.local> References: <20160204170249.GA22319@elstar.local> <56B38554.2040907@labn.net> <20160204191337.GA22516@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: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 20:19:42 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 04, 2016 at 12:07:32PM -0500, Lou Berger wrote: > > > > > > On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote: > > > Can I mount /top/second? > > yes. But in our use case, we wouldn't explicitly do a mount here. but we > > would allow a server may choose to support it. > > > > > Why would a solution be simpler if I make > > > this impossible? > > > > We're not suggest this. We're stating what we require, not what we > > preclude. So a solution that supports non-top-level is just fine too. > > > > So is the outcome of this discussion that you wanted to express that > it is sufficient for your use case to be able to mount nodes located > directly below the root? In other words, you would mount /system out > of ietf-system but you would never consider to mount, say, /system/ntp > or /system/radius. > > If this is the outcome, then the text describing your use case > requirement probably can be improved (the distinction between > top-level module and non-top-level module is misleading since all you > require is mount of top-level nodes). The way I understand the requirement from Lou et. al, which is also what structural mount supports, is a way to mount (or "relocate") a set of modules under a certain path. Currently the complete subtrees defined by this module set is mounted. This includes any augments. So for example, if you mount ietf-interfaces and ietf-ip under /x:foo, the result would be: /x:foo/if:interfaces/if:interface/ip:ipv4/... /x:foo/if:interfaces/if:interface/ip:ipv6/... etc. Structural mount does not currently support mounting of specific subtrees. I agree with Juergen that the term "top-level module" maybe is misleading. (In fact, I thought that this term refered to something else - once you have mounted ietf-interfaces in the module "x" as above, I thought that "x" was the top-level module, and ietf-interface was the non-top-level module). /martin From nobody Thu Feb 4 12:35:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCFC1AD28D for ; Thu, 4 Feb 2016 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 i4iBL0KidQLW for ; Thu, 4 Feb 2016 12:35:35 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id B8B9E1AD1EE for ; Thu, 4 Feb 2016 12:35:05 -0800 (PST) Received: (qmail 11974 invoked by uid 0); 4 Feb 2016 20:35:03 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 4 Feb 2016 20:35:03 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id ETam1s00k2SSUrH01Tapau; Thu, 04 Feb 2016 20:35:00 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=lG-qToFOM-whWIpXoygA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=PLnY8O6OC/X7/YAAx2slYB84Mk2cyb9Rm5J0q5Txr68=; b=aVLwAEoIHyIf0i9FR02Cvy732K4/+YqHMG1V/QBRG/gWS7mZULyjP6ss4p2rSAOCKtk0w+ohqjWFwje+XXd3j/+2BkWOXbVCoELynNHY72LMQ5CaU5C60yJ82QhZEaBY; Received: from box313.bluehost.com ([69.89.31.113]:41736 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRQc5-0006Z3-6W; Thu, 04 Feb 2016 13:34:49 -0700 To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <20160204170249.GA22319@elstar.local> <56B38554.2040907@labn.net> <20160204191337.GA22516@elstar.local> <20160204.212251.327145391331700368.mbj@tail-f.com> From: Lou Berger Message-ID: <56B3B5E0.5050005@labn.net> Date: Thu, 4 Feb 2016 15:34:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204.212251.327145391331700368.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 20:35:37 -0000 Martin, On 2/4/2016 3:22 PM, Martin Bjorklund wrote: > The way I understand the requirement from Lou et. al, which is also > what structural mount supports, is a way to mount (or "relocate") a > set of modules under a certain path. Currently the complete subtrees > defined by this module set is mounted. This includes any augments. > So for example, if you mount ietf-interfaces and ietf-ip under /x:foo, > the result would be: > > /x:foo/if:interfaces/if:interface/ip:ipv4/... > /x:foo/if:interfaces/if:interface/ip:ipv6/... > > etc. > > Structural mount does not currently support mounting of specific > subtrees. > > I agree with Juergen that the term "top-level module" maybe is > misleading. (In fact, I thought that this term refered to something > else - once you have mounted ietf-interfaces in the module "x" as > above, I thought that "x" was the top-level module, and ietf-interface > was the non-top-level module). So what's a better way of referring to the type of mounted module? Lou From nobody Thu Feb 4 12:48:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA3F1AD255; Thu, 4 Feb 2016 12:48:27 -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, RP_MATCHES_RCVD=-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 lyibpuRkH51L; Thu, 4 Feb 2016 12:48: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 5E1B11AD210; Thu, 4 Feb 2016 12:48:26 -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 94FBC1AE030D; Thu, 4 Feb 2016 21:48:25 +0100 (CET) Date: Thu, 04 Feb 2016 21:51:38 +0100 (CET) Message-Id: <20160204.215138.318927659702672246.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <56B3B5E0.5050005@labn.net> References: <20160204191337.GA22516@elstar.local> <20160204.212251.327145391331700368.mbj@tail-f.com> <56B3B5E0.5050005@labn.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: draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, draft-lhotka-netmod-ysdl@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 20:48:27 -0000 Lou Berger wrote: > Martin, > > On 2/4/2016 3:22 PM, Martin Bjorklund wrote: > > The way I understand the requirement from Lou et. al, which is also > > what structural mount supports, is a way to mount (or "relocate") a > > set of modules under a certain path. Currently the complete subtrees > > defined by this module set is mounted. This includes any augments. > > So for example, if you mount ietf-interfaces and ietf-ip under /x:foo, > > the result would be: > > > > /x:foo/if:interfaces/if:interface/ip:ipv4/... > > /x:foo/if:interfaces/if:interface/ip:ipv6/... > > > > etc. > > > > Structural mount does not currently support mounting of specific > > subtrees. > > > > I agree with Juergen that the term "top-level module" maybe is > > misleading. (In fact, I thought that this term refered to something > > else - once you have mounted ietf-interfaces in the module "x" as > > above, I thought that "x" was the top-level module, and ietf-interface > > was the non-top-level module). > > So what's a better way of referring to the type of mounted module? In my view, any module can be mounted. Your original email had: 1. that there be a mechanism that allows the incorporation (or 'mounting') of the data model defined by one top-level module within another module. I think the word "top-level" can simply be removed from this sentence. /martin From nobody Thu Feb 4 14:17:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8031B2C58; Thu, 4 Feb 2016 14:17:54 -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, RP_MATCHES_RCVD=-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 Xiqz4GPmgd0V; Thu, 4 Feb 2016 14:17:52 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 320951B2C57; Thu, 4 Feb 2016 14:17:52 -0800 (PST) Received: from tops.chopps.org (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 EECB461F70; Thu, 4 Feb 2016 22:17:50 +0000 (UTC) References: <56B0FDAC.3090100@labn.net> <20160204120028.GC21573@elstar.local> <56B34BE2.6090205@labn.net> <20160204141209.GA21868@elstar.local> <56B365D7.8060501@labn.net> <20160204161231.GC22049@elstar.local> <56B37D48.10707@labn.net> <87h9hoo22w.fsf@tops.chopps.org> <20160204170249.GA22319@elstar.local> User-agent: mu4e 0.9.17; emacs 24.5.1 From: To: Juergen Schoenwaelder In-reply-to: <20160204170249.GA22319@elstar.local> Date: Thu, 04 Feb 2016 17:17:49 -0500 Message-ID: <87lh705dde.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: netmod WG , draft-lhotka-netmod-ysdl@ietf.org, draft-bjorklund-netmod-structural-mount@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] Yang mount / ysdl example use case 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, 04 Feb 2016 22:17:54 -0000 --=-=-= Content-Type: text/plain Juergen Schoenwaelder writes: > On Thu, Feb 04, 2016 at 11:46:47AM -0500, chopps@chopps.org wrote: >> >> Lou Berger writes: >> >> > Juergen, >> > >> > see below >> > >> > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: >> >> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: >> >>> Juergen, >> >>> >> >>> see below. >> >>> >> >>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: >> >>>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: >> >>>>>> If more granular mounts are needed, then we should IMHO _not_ bundle >> >>>>>> this with the notion of YANG submodules. Perhaps you meant submodules >> >>>>>> in a more generic way, but then perhaps: >> >>>>>> >> >>>>>> s/of submodules/of parts of modules/ >> >>>>> yes. >> >>>> OK - so I will read submodules as 'parts of modules'. >> >>>> >> >>>>>> Reading the other text again, I am not sure what is meant by the >> >>>>>> phrase "incorporation of the data model defined by one top-level >> >>>>>> module". What exactly is a 'top-level module' (and does it matter, >> >>>>> interfaces. >> >>>> An example does not define the term. >> >>> 100% agree - at least in drafts. >> >>> >> >>>> Please define 'top-level module' >> >>> any module that defines a top-level node, or if you prefer a module that >> >>> defines nodes at the XPath root node. >> >>> >> >>>> so we can actually understand what we are talking about. >> >>> If you don't like either formation, I suspect at this point you know >> >>> what I mean, so please propose alternate language that works for you and >> >>> I'll confirm that/if it works for me. >> >> Cool. So if I mount ietf-interfaces (a top-level module) into some >> >> other place, what happens to all the data models that augment >> >> ietf-interfaces with interface specific objects, like the ietf-ip >> >> module (a non-top-level module)? >> > >> > they are allowed/supported in the same way that they would be today, >> > just with the modifications/rewrite of their base models. >> > >> >> >> >> I fail to see why this distinction between top-level modules and >> >> non-top-level modules is useful. >> > >> > I'm describing a single use case, which only requires top-level support, >> > not all desirable capabilities or a solution. >> >> Hi Juergen, >> >> The top-level modules would carry the mounts of the non-top-level >> modules that are attached within them. I don't see this making sense any >> other way. The idea here is to support a parent device being able to >> mount a contained child device's modules and modify them external to the >> child devices normal management mechanism (e.g., not having to log into >> the child's netconf server). >> >> Given that, what's the use of talking about mounting "inner" modules? >> You have to mount the "outer" (or containing) module to be able to >> access them, and by mounting the containing module you gain access to the >> contained modules. >> >> At least that's how I picture this working. >> > > But even then, why do we need new terms? If you mount a path, then you > mount a path in a datastore. Modules that do not define paths obviously > then can't be mounted. How about this: > > module top-level-module { > container top; > } > > module non-top-level-module { > import "top-level-module" { prefix top; } > > augment "/top:top/" { > container second; > } > } > > Can I mount /top/second? Why would a solution be simpler if I make > this impossible? So your saying the parent can the second without the first on the /top/second path? If so then it should be the same with the "child" (or mount point) as well. The intent is not to try and add restrictions here. I think maybe the whole top-level thing is unintentionally confusing. Thanks, Chris. > > /js --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWs84NAAoJEC4dgw7XuDAlcU8P/RNkgyij4nBtfXqM2o3Yk2qn iFIBOFIWwYSjFR3jjZ2oV4/pnjn1O9sR6Rc0sV9EwxVVxqT6Aro9zy5UEgik5llO 7jWaS9IS0hKgeTuDfAAPm62lCzY0l5MN+OICmCKqHBMAHcfHgEO/VMbrvfJtu1Rc 9MDaABy3O/6PUPKBVsFe5S4a3e2qXsHSwitFmar2frd19iMhTgsUusOPR5mcmMyA wkl/0Ka/0dG7lI8k8nGdHzf2CzKwmg73sehjAqDUb4GgJJNBSAa8BN0toTXjCmaw zU2uhKgyoXwNx1oim6Brx6qOOHDaT2HJXI2HIEGDJvNCAHCBY9lYmRiYdDem8Ruf Ir1PYP9TILDXzHQ3HB+u925AwwdpiY3YWcy7fYHnogIu9Ye4tOq5b5EkJL/bz66n aDYV0UFpSHzo7NYcnA3eXwAhoC+opRSSvxFzTUiGp07MJiEKstxgoqI69DERa9He nV3+z144IhWPxqlWlLT0QMjaYuSp7r4wDNom6d9ONaDAilsJYKHb1aY8iA0VdxZY Uf2nSwvw+h2vhJaDqqmWtbgQxnHGS2805JYOCTaGt9M3dcUXsV+531AUyHil/CCC mTEtBNw75H835MswBb64B5yL5g2SERoHNp1Px+Vs6I0BIOwdUSpRB/sazPWUoPTT basNyVlUiCDglWnqlIAL =HdSq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 4 14:32:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBFA1B319C for ; Thu, 4 Feb 2016 14:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 8t32POQjlecE for ; Thu, 4 Feb 2016 14:32:05 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0583A1B31B8 for ; Thu, 4 Feb 2016 14:32:04 -0800 (PST) Received: (qmail 3416 invoked by uid 0); 4 Feb 2016 22:32:04 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 4 Feb 2016 22:32:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ENY01s0042SSUrH01NY3Gt; Thu, 04 Feb 2016 15:32:03 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=jDUdGALLp3yYCBuAIpIA:9 a=1ZolFp6QL4wfwVVM:21 a=u6U_HpzWV3O_zpZo:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=qiqooXRhpTkbyRw23i2lINe+VwLrMVcqDbBPtsH4ntY=; b=d49ufSTUsO5GCyv5h88SJsOz2n/qmbADfTAuOZA5Ob6CNfrbTx39G7zlaV9wrmmomqxzmJv7YloFZU6XsM6+fyGfY8OXkLR7IPbighZd9pAC+IE4f3H61JLJ7yOqv7Yn; Received: from box313.bluehost.com ([69.89.31.113]:42115 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aRSRV-0005Tb-2E; Thu, 04 Feb 2016 15:32:01 -0700 To: draft-wilton-netmod-opstate-yang@ietf.org From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56B3D15A.7080900@labn.net> Date: Thu, 4 Feb 2016 17:31:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: [netmod] a few comments on draft-wilton-netmod-opstate-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, 04 Feb 2016 22:32:06 -0000 Hello, A few of us in the routing area architecture yang DT discussed this draft yesterday and had a couple of comments, (note that the open config contributors who are members of the design team did not participate in this discussion): - that with tooling, it is possible for the models available using your extension have important similarities to the model conventions proposed by open config. We think it would be worth mentioning that tooling extensions could be used to auto generate both yang and tree formats that would be effectively available using the extension. - we think there is significant value in having a tools based approach which uses existing models, and which keeps config nodes in unmodified locations. Chris Hopps came up with the idea of a minor change to your extension where instead of adding 4 new config leaf values cfg-* replacing the original leaf, the three new leaf values would be added underneath a sibling node, perhaps called -cfg. The benefit of this is that user code would be the same with respect to intended config with or without your extension. This also addresses the list index problem. - also from Chris: it would be useful to have a way of retrieving intended config along with any applied config that differs from the intended config, e.g. with-config-state=intended+diff-cfg. Thoughts? Lou (with Chris) From nobody Thu Feb 4 18:43:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDBE1B2D6F for ; Thu, 4 Feb 2016 18:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 zKUYiCHA09kM for ; Thu, 4 Feb 2016 18:43:23 -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 181351B2D6B for ; Thu, 4 Feb 2016 18:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10136; q=dns/txt; s=iport; t=1454640203; x=1455849803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vk/xaZ1t3tNmJLEt9P4/SI3+JB09WnwAR/D+VDm/0Ms=; b=DB30+0BBwLWcMJifeoWV2xj9tV2IONziTotpxyvTqW6F7B0/8aDM3gFb gviN0KfDcr+Lo5XiKWcA6FYC7wWI1cpK6pUza1gbO1+rz4GCsl3MrhQsc sk+UEgd+rS05zGCrf/13xcFxGvqvmmPMtuodSD4uBVsoS4Cy8GMR2BlWW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyBQAPC7RW/xbLJq1UCoQMbQaEKYQss?= =?us-ascii?q?n8XCoUiSgIcgWwBAQEBAQGBC4RBAQEBAwEBAQEgEToLDAQCAQgOAwQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBDQUIE4d4CA6xM45tAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR7iU6EAgYEBgIBBS6CaoE6BZZxAY1IgWKEQohUim2DUQFiggMZgUhqiEM9AXs?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.22,398,1449532800"; d="scan'208";a="624128087" 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; 05 Feb 2016 02:43:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u152hJci002794 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 02:43:20 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 4 Feb 2016 21:43:18 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 4 Feb 2016 21:43:18 -0500 From: "Alexander Clemm (alex)" To: Lou Berger , Kent Watsen , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] Yang mount / ysdl example use case Thread-Index: AQHRXeyQ7D2KRUiAW0+6Gca0wXUbR58Z7BoAgADEaoCAAFlAAIAAFpQAgAFm4HA= Date: Fri, 5 Feb 2016 02:43:18 +0000 Message-ID: References: <56B0FDAC.3090100@labn.net> <80DED68C-16DB-4723-9DDC-0D84DD6DD041@juniper.net> <56B209B9.2050504@cisco.com> <287698E9-361C-44EA-A23F-AEE25CE65F76@juniper.net> <152a8e46b40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <152a8e46b40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Yang mount / ysdl example use case 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, 05 Feb 2016 02:43:26 -0000 SGkgTG91LA0KDQp0aGUgb3JpZ2luYWwgZHJhZnQgc3BlY2lmaWVkIG1vdW50aW5nIGEgbW9kZWwg dGhhdCB3YXMgYWxyZWFkeSBpbnN0YW50aWF0ZWQgb24gYSBzZXJ2ZXIuICBZb3VyIHJlcXVpcmVt ZW50ICMxIGlzIGEgbGl0dGxlIGRpZmZlcmVudCBpbiB0aGF0IHlvdSB3YW50IHRvIGluc3RhbnRp YXRlIGEgc3BlY2lmaWMgZGF0YSBtb2RlbCB1bmRlcm5lYXRoIGFub3RoZXIgbm9kZSBpbiBhbm90 aGVyIG1vZGVsICh3aXRob3V0IHRoZSBzYW1lIG1vZGVsIGFscmVhZHkgYmUgaW5zdGFudGlhdGVk IGVsc2V3aGVyZSksIGFzIG9wcG9zZWQgdG8gbW91bnRpbmcgYSBtb2RlbCB0aGF0IGlzIGFscmVh ZHkgaW5zdGFudGlhdGVkLiAgU28sIHlvdSdyZSBub3QgaW5zZXJ0aW5nIGEgcmVmZXJlbmNlIGFu ZCBjcmVhdGluZyBhbiBhbHRlcm5hdGl2ZSBwYXRoIHRvIGFuIGluc3RhbmNlLCBidXQgaW5zZXJ0 aW5nIHRoZSBtb2RlbCBkZWZpbml0aW9uIGl0c2VsZi4gIFRoaXMgaXMgbm90IHRoZSBzYW1lLCBh bmQgbm90IGFkZHJlc3NlZCBieSB0aGUgb3JpZ2luYWwgZHJhZnQuICBUaGF0IHNhaWQsIGl0IGlz IGV2aWRlbnRseSBwb3NzaWJsZSB0byBidWlsZCBvbiB0aGUgbW91bnQtbW9kZWwgYW5kIGV4dGVu ZCBvciB2YXJ5IGl0IGluIHN1Y2ggYSB3YXkgdGhhdCBzdXBwb3J0cyB5b3VyIGNhc2UsIGFuZCBN YXJ0aW4ncyBkcmFmdCBwcm9wb3NlcyBob3cgdGhpcyBjYW4gYmUgZG9uZS4gIEF0IHRoZSBzYW1l IHRpbWUsIHRoZXJlIGFyZSBvdGhlciB1c2UgY2FzZXMgKG9mIGFsaWFzLW1vdW50IGFuZCBwZWVy LW1vdW50KSB3aGljaCBjb3VsZCBiZSBhZGRyZXNzZWQgd2l0aCB2YXJpYXRpb25zIG9mIHRoZSBz b2x1dGlvbiB0aGF0IGJ1aWxkIG9uIGVhY2ggb3RoZXIuICANCg0KLS0tIEFsZXgNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxh Ym4ubmV0XSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDMsIDIwMTYgMTI6NDggUE0NClRv OiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD47IFJvYmVydCBXaWx0b24gLVggKHJ3 aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6 IG5ldG1vZCBXRyA8bmV0bW9kQGlldGYub3JnPjsgQWxleGFuZGVyIENsZW1tIChhbGV4KSA8YWxl eEBjaXNjby5jb20+OyBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPg0KU3ViamVj dDogUmU6IFtuZXRtb2RdIFlhbmcgbW91bnQgLyB5c2RsIGV4YW1wbGUgdXNlIGNhc2UNCg0KSSBk b24ndCBzZWUgaG93IGRyYWZ0IENsZW1tIGFkZHJlc3NlcyBvdXIgZHJhZnQncyB1c2UgY2FzZS4g IFRoYXQgc2FpZCwgaWYgYWxleCB0aGlua3MgaXQgZG9lcyAtIGxldCdzIGhlYXIgYWJvdXQgaXQu DQoNCkFsZXgsDQoNCkNhbiB5b3UgbG9vayBhdCB0aGUgbWFpbCBJIHNlbnQgdGhlIG90aGVyIGRh eSBhYm91dCBvdXIgcGxhbm5lZCB1c2FnZSBhbmQgc2VlIHdoYXQgeW91IHRoaW5rIC0gYW5kIGxl dCB1cyBrbm93IHdoYXQgeW91IGZpbmQ/DQoNClRoYW5rcywNCkxvdQ0KDQoNCk9uIEZlYnJ1YXJ5 IDMsIDIwMTYgMjoyNzo0NCBQTSBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQoNCj4NCj4gSSB3YXMgbGVkIHRvIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBzZXQgb2Yg ZHJhZnRzIHN1YnN1bWUgDQo+IGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC4gIElmIHRoYXTigJlz IG5vdCB0cnVlLCB0aGVuIGFic29sdXRlbHkgdGhlcmUgDQo+IHNob3VsZCBiZSBhIHNsb3QgZm9y IHRoYXQgZHJhZnQgdG8gYmUgZGlzY3Vzc2VkIGFzIHdlbGwuICBQbGVhc2UgYWR2aXNlLg0KPg0K PiBLZW50DQo+DQo+DQo+DQo+DQo+DQo+DQo+IE9uIDIvMy8xNiwgOTowNyBBTSwgIlJvYmVydCBX aWx0b24iIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PkhpIEtlbnQsDQo+Pg0KPj5U aGVyZSBpcyBhbHNvIGFub3RoZXIgWWFuZyBNb3VudCByZWxhdGVkIGRyYWZ0OiANCj4+ZHJhZnQt Y2xlbW0tbmV0bW9kLW1vdW50LTAzDQo+Pg0KPj5Ob3csIHRoaXMgZHJhZnQgZG9lc24ndCBkaXJl Y3RseSBhZGRyZXNzIHRoZSBSVEcgRFQgQXJjaCB0ZWFtIA0KPj51c2UtY2FzZSwgYW5kIHNlZW1z IHRvIGNvdmVyIHR3byBtb3JlIGNvbXBsZXggcHJvYmxlbSBzY2VuYXJpb3MgDQo+PihyZW1vdGUg bW91bnQgYW5kIGFsaWFzIG1vdW50KSwgYnV0IHRoZXNlIGRvIGFwcGVhciB0byBiZSBhIHZhbGlk IA0KPj5tb3VudCB1c2UgY2FzZXMgKGUuZy4gSSB0aGluayB0aGF0IGl0IGlzIHVzZWQgYnkgT3Bl bkRheWxpZ2h0IFNETiANCj4+Y29udHJvbGxlciksIGFuZCBJIGtub3cgdGhhdCB0aGVyZSBpcyBh dCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBkcmFmdC4NCj4+DQo+PlNvLCBJIHdh bnQgdG8gZWNobyBFcmljIFZvaXQncyBjb21tZW50cyB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgaWYg DQo+PndoYXRldmVyIGJhc2ljIFlBTkcgbW91bnQgZHJhZnQgd2UgY29udmVyZ2Ugb24gaXMgYWJs ZSB0byBiZSBjbGVhbmx5IA0KPj5leHRlbmRlZCB0byBjb3ZlciB0aGUgbW9yZSBjb21wbGV4IG1v dW50IHNjZW5hcmlvcy4NCj4+DQo+PkFzIHN1Y2gsIGlmIEFsZXggQ2xlbW0gb3IgRXJpYyBWb2l0 IGFyZSB3aWxsaW5nLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgDQo+PmJlIHVzZWZ1bCBpZiBvbmUg b2YgdGhlbSBjb3VsZCBjb21tZW50IG9uIGhvdyBmZWFzaWJsZSBpdCBpcyB0byBleHRlbmQgDQo+ PmVpdGhlciBuZXRtb2Qtc3RydWN0dWFsLW1vdW50IG9yIG5ldG1vZC15c2RsIHRvIGNvdmVyIHRo ZSByZW1vdGUgbW91bnQgDQo+PmFuZCBhbGlhcyBtb3VudCBzY2VuYXJpb3MgZGVzY3JpYmVkIGlu IGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMy4NCj4+SGVuY2UsIGlmIHRoZXkgYWdyZWUsIGRv IHlvdSB0aGluayB0aGF0IHlvdSB3b3VsZCBiZSBhYmxlIHRvIGFkZCBhIDE1IA0KPj5taW4gc2xv dCB0byB0aGUgYWdlbmRhIHRvIGNvdmVyIHRoaXMgcGxlYXNlPw0KPj4NCj4+VGhhbmtzLA0KPj5S b2INCj4+DQo+Pg0KPj5PbiAwMy8wMi8yMDE2IDAyOjI0LCBLZW50IFdhdHNlbiB3cm90ZToNCj4+ PiBbQ2hhaXIgaGF0IG9uXQ0KPj4+DQo+Pj4gR2l2ZW4gdGhlIG51bWJlciBvZiBjb21wZXRpbmcv Y29tcGxlbWVudGluZyBkcmFmdHMgaW52b2x2ZWQsIGFuZCB0aGUgDQo+Pj4gZ2VuZXJhbCBsYWNr IG9mIGRpc2N1c3Npb24gb24gYW55IG9mIHRoZW0sIGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcg DQo+Pj4gbWlnaHQgYmUgYW4gZXhwZWRpZW50IHdheSB0byBwcm9jZWVkLiAgSW4gZmFpcm5lc3Ms IHdlIGtub3cgdGhhdCANCj4+PiB0aGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24sIGJ1dCBp dCBoYXNu4oCZdCBiZWVuIHBpY2tlZCB1cCB5ZXQgaW4gDQo+Pj4gYSBiaWcgd2F5LCBhbmQgbm93 IExvdSBoYXMgYW4gdXBkYXRlZCBkcmFmdC4NCj4+Pg0KPj4+IFRoZSBjaGFpcnMgZGlzY3Vzc2Vk IG1heWJlIHNjaGVkdWxpbmcgb25lIGZvciBhIGNvdXBsZSB3ZWVrcyBmcm9tIG5vdywgDQo+Pj4g cGVyaGFwcyBUaHVyc2RheSBGZWIgMTggc3RhcnRpbmcgYXQgMTBhbSBFU1Q/ICAgSSdtIHRoaW5r aW5nIGFib3V0IHRoaXMgDQo+Pj4gc2xvdCBvbmx5IHNpbmNlIGl0IHdvcmtlZCBmb3IgdXMgZm9y IHByZXZpb3VzbHkuICBJcyB0aGlzIGEgZ29vZCB0aW1lIHNsb3Q/IA0KPj4+ICBJIGFzc3VtZSB0 byBzY2hlZHVsZSBmb3IgMiBob3Vycywgd2l0aCBhIHBsYW4gdG8gZW5kIGVhcmx5IGlmIG5lZWRl ZCAtIA0KPj4+IG1ha2VzIHNlbnNlPyAgICAgV2UgYWxzbyBuZWVkIHRvIHB1dCB0b2dldGhlciBh IHByb3BlciBhZ2VuZGEsIHBlcmhhcHMgdGhlIA0KPj4+IGZvbGxvd2luZz8NCj4+Pg0KPj4+ICAg IDEwIG1pbjogUlRHIERUIFlBTkcgQXJjaCB0ZWFtIHVzZS1jYXNlIHN1bW1hcnkNCj4+PiAgICAy MCBtaW46IGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwNCj4+PiAgICAyMCBtaW46 IGRyYWZ0LWxob3RrYS1uZXRtb2QteXNkbA0KPj4+ICAgIDIwIG1pbjogZHJhZnQtYmpvcmtsdW5k LW5ldG1vZC1zdHJ1Y3R1cmFsLW1vdW50DQo+Pj4gICAgNTAgbWluOiBnZW5lcmFsIGRpc2N1c3Np b24gb3IgZW5kIGVhcmx5DQo+Pj4NCj4+Pg0KPj4+IFdlIGhvcGUgdG8gc2NoZWR1bGUgdGhlIG1l ZXRpbmcgaXRzZWxmIHRvbW9ycm93IG9yIHRoZSBuZXh0IGRheSwgc28gDQo+Pj4gcGxlYXNlIHJl c3BvbmQgcXVpY2tseSB0byB0aGlzIGVtYWlsIGlmIHBvc3NpYmxlLg0KPj4+DQo+Pj4gVGhhbmtz LA0KPj4+IEtlbnQgYW5kIFRvbQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gMi8yLzE2LCAy OjA0IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMb3UgQmVyZ2VyIiANCj4+PiA8bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+ DQo+Pj4+IEkgdGhvdWdodCBpdCB3b3VsZCBiZSB3b3J0aCBzdW1tYXJpemluZyB3aGF0IHdlJ3Jl IGxvb2tpbmcgZm9yIGluIA0KPj4+PiBvdXIgZHJhZnQsIGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1k ZXZpY2UtbW9kZWwtMDIgKG5vdGUgbmV3IHZlcnNpb24gDQo+Pj4+IGluIGNhc2UgeW91IG1pc3Nl ZCBpdCkgd2l0aCByZXNwZWN0IHRvIHRoZSBkcmFmdC1saG90a2EtbmV0bW9kLXlzZGwgDQo+Pj4+ IGFuZCBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQgZHJhZnRzLiBUaGlz IGlzIGp1c3QgbXkgDQo+Pj4+IHZpZXcsIHNvIG15IGNvLWF1dGhvcnMgbWF5IHdpc2ggdG8gY2hp bWUgaW4gYW5kIGNvcnJlY3QgbWUuDQo+Pj4+DQo+Pj4+IEknZCBiZSBpbnRlcmVzdGVkIGluIGhl YXJpbmcgZnJvbSB0aGUgYXV0aG9ycyBvZiBZU0RMIGFuZCANCj4+Pj4gc3RydWN0dXJhbC1tb3Vu dCwgb3IgYW55b25lIGVsc2UgZm9yIHRoYXQgbWF0dGVyLCBvbiBob3cgdGhleSBzZWUgDQo+Pj4+ IHRvIGJlc3QgbWVldCB0aGVzZSBuZWVkcy4NCj4+Pj4NCj4+Pj4gSGVyZSdzIHdoYXQgSSB0aGlu ayBvdXIgZHJhZnQgbmVlZHM6DQo+Pj4+DQo+Pj4+IDEuIHRoYXQgdGhlcmUgYmUgYSBtZWNoYW5p c20gdGhhdCBhbGxvd3MgdGhlIGluY29ycG9yYXRpb24gKG9yDQo+Pj4+ICAgICdtb3VudGluZycp IG9mIHRoZSBkYXRhIG1vZGVsIGRlZmluZWQgYnkgb25lIHRvcC1sZXZlbCBtb2R1bGUNCj4+Pj4g ICAgd2l0aGluIGFub3RoZXIgbW9kdWxlLg0KPj4+Pg0KPj4+PiAgICBUaGUgaW1wbGljYXRpb24g aGVyZSBpcyB0aGF0IHdoZW4gaW5mb3JtYXRpb24gaXMgaW5zdGFudGlhdGVkDQo+Pj4+ICAgIGZv ciB0aGUgcGFyZW50IG1vZGVsIGl0IGlzIGFsc28gaW5zdGFudGlhdGVkIGZvciB0aGUNCj4+Pj4g ICAgaW5jb3Jwb3JhdGVkL21vdW50ZWQgbW9kZWwuIEluIG91ciBjYXNlIHdlIGV4cGVjdCB0byBk byB0aGlzIG9uDQo+Pj4+ICAgIGxpc3QgZWxlbWVudCBjcmVhdGlvbi4gQm90aCBzb2x1dGlvbnMg ZHJhZnRzIGNvdmVyIHRoZSBwYXRoDQo+Pj4+ICAgIGltcGxpY2F0aW9ucywgc28gdGhlc2UgYXJl IG5vdCByZXBlYXRlZCBoZXJlLg0KPj4+Pg0KPj4+PiAyLiB0aGF0IHRoaXMgbWVjaGFuaXNtIGFs bG93IGlkZW50aWZpY2F0aW9uIG9mIHNwZWNpZmljIG1vZHVsZXMgdG8NCj4+Pj4gICAgYmUgaW5j b3Jwb3JhdGVkL21vdW50ZWQgYXQgdGltZSBvZiBtb2R1bGUgZGVmaW5pdGlvbiwgaS5lLiB0aGF0 DQo+Pj4+ICAgIG5vIGFkZGl0aW9uYWwgbW9kdWxlIGlzIG5lZWRlZCB0byBzdXBwb3J0IDEuIFRo aXMgZG9lc24ndA0KPj4+PiAgICBwcmVjbHVkZSBkZWZpbml0aW9uIG9mIHN1Y2ggYSBtb2R1bGUu DQo+Pj4+DQo+Pj4+IDMuIHRoYXQgdGhpcyBtZWNoYW5pc20gYWxsb3cgZm9yIGEgc2VydmVyIHRv IGNvbnRyb2wgKGFuZA0KPj4+PiAgICBpZGVudGlmeSkgd2hpY2ggbW9kdWxlcyBhcmUgaW5jb3Jw b3JhdGVkL21vdW50ZWQuIChzZWUgU2VjdGlvbg0KPj4+PiAgICAzIExORSBpbiBvdXIgZHJhZnQg Zm9yIGFuIGVudmlzaW9uZWQgdXNhZ2UuKQ0KPj4+Pg0KPj4+PiA0LiB0aGF0IGFsbCBjYXBhYmls aXRpZXMgdGhhdCBleGlzdCB3aXRoIHRoZSBtb3VudGVkIG1vZHVsZSBhcmUNCj4+Pj4gICAgYXZh aWxhYmxlIGUuZy4gUlBDIG9wZXJhdGlvbnMgYW5kIG5vdGlmaWNhdGlvbnMuDQo+Pj4+DQo+Pj4+ IDUuIHdoaWxlIG91ciBwcmltYXJ5IHJlcXVpcmVtZW50IGlzIGZvciAnbW91bnRpbmcnIG9mIHRv cCBsZXZlbA0KPj4+PiAgICBtb2R1bGVzLCBtb3VudGluZyBvZiBzdWJtb2R1bGVzIG1heSBhbHNv IGJlIHVzZWZ1bC4gKERUIG5vdCBkcmFmdA0KPj4+PiAgICBkcml2ZW4uKQ0KPj4+Pg0KPj4+PiBX ZSBtYWtlIHVzZSBvZiB0aGUgYWJvdmUgaW4gc2VjdGlvbnMgMyBhbmQgNCBvZiBydGd3Zy1kZXZp Y2UtbW9kZWwuICANCj4+Pj4gV2Ugc2VlIGhhdmluZyBhIHNvbHV0aW9uIGFzIGNyaXRpY2FsIGZv ciB0aGUgDQo+Pj4+IHNpbXBsaWZpY2F0aW9ucy9mbGV4aWJpbGl0eSByZXByZXNlbnRlZCBpbiB0 aGUgLTAyIHZlcnNpb24gb2Ygb3VyIA0KPj4+PiBkcmFmdCB2cyB0aGUgLTAzIHJldi4gIFdlIGRv bid0IHNlZSB3aXRoZXIgc29sdXRpb24gZHJhZnQgYXMgDQo+Pj4+IHNpZ25pZmljYW50bHkgZGlm ZmVyZW50IGFuZCBqdXN0IGhvcGUgZm9yIGEgc3RhbmRhcmQgc29sdXRpb24gYXMgDQo+Pj4+IHNv b24gYXMgcG9zc2libGUuICAoYSBkcmFmdC1pZXRmLW5ldG1vZCBzb2x1dGlvbnMgZHJhZnQgb24g dGhlIA0KPj4+PiB0b3BpYyBieSBCQSB3b3VsZCBiZSBmYW50YXN0aWMgZ2l2ZW4gdGhlIGltcGFj dCBvbiByb3V0aW5nIGFyZWEgLS0gDQo+Pj4+IGV2ZW4gaWYgaXQgaGFkIHRvIGRvY3VtZW50IHR3 byB2YXJpYXRpb25zIC8gYWx0ZXJuYXRpdmUgc29sdXRpb25zLikNCj4+Pj4NCj4+Pj4gQWdhaW4s IHRoaXMgaXMganVzdCBteSBvcGluaW9uIGFuZCBteSBjb2F1dGhvcnMgb3Igb3RoZXJzIG9uIHRo ZSANCj4+Pj4gcnRnIGFyZWEgeWFuZyBEVCBtYXkgY2hvb3NlIHRvIGNoaW1lIGluLg0KPj4+Pg0K Pj4+PiBMb3UNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBu ZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCg0KDQo= From nobody Fri Feb 5 01:50:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524391ACD9B; Fri, 5 Feb 2016 01:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DWeVNE1v8Mza; Fri, 5 Feb 2016 01:50: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 E10291ACD98; Fri, 5 Feb 2016 01:50: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 BF84C12C3; Fri, 5 Feb 2016 10:50: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 NACopFAfnRKe; Fri, 5 Feb 2016 10:50:21 +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, 5 Feb 2016 10:50:21 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D53EA2002B; Fri, 5 Feb 2016 10:50:20 +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 gLKtak6jjvDi; Fri, 5 Feb 2016 10:50: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 D831C20013; Fri, 5 Feb 2016 10:50:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 47C0E39DF7F5; Fri, 5 Feb 2016 10:50:19 +0100 (CET) Date: Fri, 5 Feb 2016 10:50:19 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160205095019.GA23583@elstar.local> Mail-Followup-To: Lou Berger , draft-wilton-netmod-opstate-yang@ietf.org, netmod@ietf.org References: <56B3D15A.7080900@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B3D15A.7080900@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-wilton-netmod-opstate-yang@ietf.org, netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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, 05 Feb 2016 09:50:26 -0000 This I-D seems to break core design assumptions of YANG data encoding works and hence it seems to break all existing implementations. If you define leaf mtu { type uint32; } then this is encoded as 9000 and there is not room for mixed content. I am stictly against any solution that is not backwards compatible. /js On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote: > Hello, > > A few of us in the routing area architecture yang DT discussed > this draft yesterday and had a couple of comments, (note that the > open config contributors who are members of the design team did > not participate in this discussion): > > - that with tooling, it is possible for the models available > using your extension have important similarities to the model > conventions proposed by open config. We think it would be worth > mentioning that tooling extensions could be used to auto generate > both yang and tree formats that would be effectively available > using the extension. > > - we think there is significant value in having a tools based > approach which uses existing models, and which keeps config nodes > in unmodified locations. Chris Hopps came up with the idea of a > minor change to your extension where instead of adding 4 new > config leaf values cfg-* replacing the original leaf, the three > new leaf values would be added underneath a sibling node, perhaps > called -cfg. The benefit of this is that user code would be > the same with respect to intended config with or without your > extension. This also addresses the list index problem. > > - also from Chris: it would be useful to have a way of retrieving > intended config along with any applied config that differs from > the intended config, e.g. with-config-state=intended+diff-cfg. > > Thoughts? > > Lou (with Chris) > > _______________________________________________ > 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 Fri Feb 5 02:09:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF41B318A for ; Fri, 5 Feb 2016 02:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 VbCC63nWEPm0 for ; Fri, 5 Feb 2016 02:09: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 951221B3178 for ; Fri, 5 Feb 2016 02:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2495; q=dns/txt; s=iport; t=1454666985; x=1455876585; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=w6ORehP30YHlzsYq0TF8Zo7kyS7vPgJF9UnD2YxvWLg=; b=nIUWaNZA7681bfYLAmcRO1uvScLN9uu84Eyech/wWQtWIsJFQBonWGO0 uysynZVdhBnRH3EnJK/fyUnYk4pi2pIV0Dd+W9YhlpxyBL99ZcawtQBtE ELsQUeePZtUOCYLPw0+tFEl6yP1babdY0V/JWilIHE6nowA41pr3BbWWp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACPdLRW/xbLJq1ehAxtiFuzABcKh?= =?us-ascii?q?SJKAoIEAQEBAQEBgQuEQgEBBAEBATU2ChELEgYJFg8JAwIBAgEVIg4TBgIBARe?= =?us-ascii?q?IAA6/VgEBAQEBBQEBAQEBFwSGEoQ3hBpkg24FlnONUIFbh0aFUoptg1JiggMZg?= =?us-ascii?q?Ug8Lol8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,399,1449532800"; d="scan'208";a="630249932" 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; 05 Feb 2016 10:09:40 +0000 Received: from [10.63.23.97] (dhcp-ensft1-uk-vla370-10-63-23-97.cisco.com [10.63.23.97]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u15A9eFI025025 for ; Fri, 5 Feb 2016 10:09:40 GMT To: netmod@ietf.org References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> From: Robert Wilton Message-ID: <56B474E1.8000901@cisco.com> Date: Fri, 5 Feb 2016 10:09:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160205095019.GA23583@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Fri, 05 Feb 2016 10:09:47 -0000 Hi Juergen, I don't really follow your point. The solution is fully backward compatible - in that only clients that make use of the protocol extension would see the new encoding. Existing clients would continue to see the encoding as directly defined in the YANG schema, and a server would be able to support old and new clients concurrently. Rob On 05/02/2016 09:50, Juergen Schoenwaelder wrote: > This I-D seems to break core design assumptions of YANG data encoding > works and hence it seems to break all existing implementations. If you > define > > leaf mtu { type uint32; } > > then this is encoded as > > 9000 > > and there is not room for mixed content. I am stictly against any > solution that is not backwards compatible. > > /js > > On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote: >> Hello, >> >> A few of us in the routing area architecture yang DT discussed >> this draft yesterday and had a couple of comments, (note that the >> open config contributors who are members of the design team did >> not participate in this discussion): >> >> - that with tooling, it is possible for the models available >> using your extension have important similarities to the model >> conventions proposed by open config. We think it would be worth >> mentioning that tooling extensions could be used to auto generate >> both yang and tree formats that would be effectively available >> using the extension. >> >> - we think there is significant value in having a tools based >> approach which uses existing models, and which keeps config nodes >> in unmodified locations. Chris Hopps came up with the idea of a >> minor change to your extension where instead of adding 4 new >> config leaf values cfg-* replacing the original leaf, the three >> new leaf values would be added underneath a sibling node, perhaps >> called -cfg. The benefit of this is that user code would be >> the same with respect to intended config with or without your >> extension. This also addresses the list index problem. >> >> - also from Chris: it would be useful to have a way of retrieving >> intended config along with any applied config that differs from >> the intended config, e.g. with-config-state=intended+diff-cfg. >> >> Thoughts? >> >> Lou (with Chris) >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 5 02:11:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3461B31A0; Fri, 5 Feb 2016 02:11:37 -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, RP_MATCHES_RCVD=-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 npJr2vRZES-t; Fri, 5 Feb 2016 02:11:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 993701B319A; Fri, 5 Feb 2016 02:11:35 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 290E21AE0285; Fri, 5 Feb 2016 11:11:34 +0100 (CET) Date: Fri, 05 Feb 2016 11:11:37 +0100 (CET) Message-Id: <20160205.111137.1629659928811810683.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160205095019.GA23583@elstar.local> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@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: draft-wilton-netmod-opstate-yang@ietf.org, netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Fri, 05 Feb 2016 10:11:37 -0000 Juergen Schoenwaelder wrote: > This I-D seems to break core design assumptions of YANG data encoding > works and hence it seems to break all existing implementations. If you > define > > leaf mtu { type uint32; } > > then this is encoded as > > 9000 > > and there is not room for mixed content. I am stictly against any > solution that is not backwards compatible. It is backwards compatible in the sense that the client has to explicitly ask for this new encoding from the server. However, the solution requires new code paths for encoding/decoding the data. Interactions with subfiltering is also a bit unclear. But I have another observation. Just like draft-kwatsen-netmod-opstate, this solution makes the assumption that the server internally has knowledge of "applied" vs. "intended" values for data modelled as config true. The two solutions differ in the way this data is requested and encoded. I would argue (no surprise here) that the encoding proposed in draft-kwatsen-netmod-opstate is much simpler. /martin > > /js > > On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote: > > Hello, > > > > A few of us in the routing area architecture yang DT discussed > > this draft yesterday and had a couple of comments, (note that the > > open config contributors who are members of the design team did > > not participate in this discussion): > > > > - that with tooling, it is possible for the models available > > using your extension have important similarities to the model > > conventions proposed by open config. We think it would be worth > > mentioning that tooling extensions could be used to auto generate > > both yang and tree formats that would be effectively available > > using the extension. > > > > - we think there is significant value in having a tools based > > approach which uses existing models, and which keeps config nodes > > in unmodified locations. Chris Hopps came up with the idea of a > > minor change to your extension where instead of adding 4 new > > config leaf values cfg-* replacing the original leaf, the three > > new leaf values would be added underneath a sibling node, perhaps > > called -cfg. The benefit of this is that user code would be > > the same with respect to intended config with or without your > > extension. This also addresses the list index problem. > > > > - also from Chris: it would be useful to have a way of retrieving > > intended config along with any applied config that differs from > > the intended config, e.g. with-config-state=intended+diff-cfg. > > > > Thoughts? > > > > Lou (with Chris) > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Feb 5 03:36:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AECB1A6F34; Fri, 5 Feb 2016 03:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 f_HR0ASKvjaF; Fri, 5 Feb 2016 03:36:29 -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 51AF31A6F2A; Fri, 5 Feb 2016 03:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2910; q=dns/txt; s=iport; t=1454672188; x=1455881788; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ixk/1E7gnoEDidYErWFLvDW0V4l4QY986c9X2c6KZUM=; b=WCJscdRy5VBAii5SKQMT4Sp5yH4pweA79lX0tJYnxlXd5WkQOXCoDkUN CpORpr4t5scztv7pxLu76KTP2HZ9Sxun2TKOZ+1iaL5z9BTvIMdFKuZbF 9sQXFoDpv2pf3SrnKct16suaL1oyKUAO/RoEKhtkXKdVskNR9zpW/i2S6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBAC8iLRW/xbLJq1ejVSzAYYNAoFzE?= =?us-ascii?q?QEBAQEBAQGBCoRBAQEBAwEjFUABEAsOBAYCAgUWCwICCQMCAQIBNw4GAQwIAQG?= =?us-ascii?q?IDwiwao5sAQEBAQEBAQEBAQEBAQEBAQEBARd7hReEN4QagxiBOgEEkm6EB41Qg?= =?us-ascii?q?VuHRoVSimyDUjYsggMZgUg8iioBAQE?= X-IronPort-AV: E=Sophos;i="5.22,400,1449532800"; d="scan'208";a="649066293" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 11:36:24 +0000 Received: from [10.63.23.97] (dhcp-ensft1-uk-vla370-10-63-23-97.cisco.com [10.63.23.97]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u15BaOOh026663; Fri, 5 Feb 2016 11:36:24 GMT To: Lou Berger , draft-wilton-netmod-opstate-yang@ietf.org References: <56B3D15A.7080900@labn.net> From: Robert Wilton Message-ID: <56B48938.4000603@cisco.com> Date: Fri, 5 Feb 2016 11:36:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B3D15A.7080900@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Fri, 05 Feb 2016 11:36:30 -0000 Hi Lou (& Chris), Thanks for the comments. On 04/02/2016 22:31, Lou Berger wrote: > Hello, > > A few of us in the routing area architecture yang DT discussed > this draft yesterday and had a couple of comments, (note that the > open config contributors who are members of the design team did > not participate in this discussion): > > - that with tooling, it is possible for the models available > using your extension have important similarities to the model > conventions proposed by open config. We think it would be worth > mentioning that tooling extensions could be used to auto generate > both yang and tree formats that would be effectively available > using the extension. Yes. I've not considered it in detail, but using tooling extensions it may be possible to get even closer to the OpenConfig structure/conventions if required. E.g. something roughly along the lines of every "config true" leaf gets put into a config container and state container, state leaves just go in a state container, interfaces & interfaces-state could be merged similarly, etc. Of course this would be more complex that the approach proposed in the draft. > > - we think there is significant value in having a tools based > approach which uses existing models, and which keeps config nodes > in unmodified locations. Chris Hopps came up with the idea of a > minor change to your extension where instead of adding 4 new > config leaf values cfg-* replacing the original leaf, the three > new leaf values would be added underneath a sibling node, perhaps > called -cfg. The benefit of this is that user code would be > the same with respect to intended config with or without your > extension. This also addresses the list index problem. Yes, there is still a possible naming clash if a model already had a config leaf called "-cfg". Possibly this could be mitigated by putting the additional meta data leaves in a separate namespace, or perhaps the pragmatic approach would be to say don't allow leaves to be called "-cfg"! The reasoning for the approach documented in the draft is that I perceive that it is cleaner for client that want the intended vs applied split, but agree that the approach that Chris suggests could make backwards compatibility easier for clients. > > - also from Chris: it would be useful to have a way of retrieving > intended config along with any applied config that differs from > the intended config, e.g. with-config-state=intended+diff-cfg. Yes, I think that such filters should be fairly easy to define and implement. I.e. if there is a scheme in place for returning the intended and applied values it should be quite straight forward on the server side to filter which elements are returned for a particular request. Thanks, Rob > > Thoughts? > > Lou (with Chris) > > . > From nobody Fri Feb 5 03:55:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8381B3753 for ; Fri, 5 Feb 2016 03:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 zJmPZ7nDz1Tf for ; Fri, 5 Feb 2016 03:55:31 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 714521B3752 for ; Fri, 5 Feb 2016 03:55:31 -0800 (PST) Received: (qmail 5045 invoked by uid 0); 5 Feb 2016 11:55:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 5 Feb 2016 11:55:22 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EbvH1s00R2SSUrH01bvL2K; Fri, 05 Feb 2016 04:55:22 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=AUd_NHdVAAAA:8 a=g_xh0jJrndHMWRa92CMA:9 a=dniNZ6AQ0UyPTQmw:21 a=nnJhokAWZ2Hxukxz:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=dsYunlTGYtp76YPVwWq7Buu0C548MLQHJBYi0SXA1ak=; b=KPsGgQtmfWU+vfPNV35rjgd+qVYClvuydcSzclv3+ERLB+Yw9oBieDkV6zlfhnxvSjQKbVQu+0l2PriWR0PPTFnjpADrUAN0kakhpD92h/uy9IhfslV244mCPdR12JLt; Received: from [100.15.91.238] (port=35532 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aReyr-0000Qe-4n; Fri, 05 Feb 2016 04:55:17 -0700 From: Lou Berger To: Robert Wilton , Date: Fri, 05 Feb 2016 06:55:14 -0500 Message-ID: <152b14940d0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <56B48938.4000603@cisco.com> References: <56B3D15A.7080900@labn.net> <56B48938.4000603@cisco.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Fri, 05 Feb 2016 11:55:36 -0000 Rob, Thanks for the response, see below. On February 5, 2016 6:36:47 AM Robert Wilton wrote: > Hi Lou (& Chris), > > Thanks for the comments. > > On 04/02/2016 22:31, Lou Berger wrote: >> Hello, >> >> A few of us in the routing area architecture yang DT discussed >> this draft yesterday and had a couple of comments, (note that the >> open config contributors who are members of the design team did >> not participate in this discussion): >> >> - that with tooling, it is possible for the models available >> using your extension have important similarities to the model >> conventions proposed by open config. We think it would be worth >> mentioning that tooling extensions could be used to auto generate >> both yang and tree formats that would be effectively available >> using the extension. > Yes. > > I've not considered it in detail, but using tooling extensions it may be > possible to get even closer to the OpenConfig structure/conventions if > required. E.g. something roughly along the lines of every "config true" > leaf gets put into a config container and state container, state leaves > just go in a state container, interfaces & interfaces-state could be > merged similarly, etc. Of course this would be more complex that the > approach proposed in the draft. > While achieving closer alignment with the layout proposed in the open config draft is certainly possible, that is not where we were headed. Our point was that with a modification to pyang it would be trivial to show the tree that would result with your proposal as well as, with a little more tooling work, auto generate additional leaves / information. -- and that would be generally helpful. I can see how this would be useful during model discussion and development, as well as facilitate certain implementation approaches. I was not proposing any meaningful change to the Yang that would be provided by the server running your extension in this bullet. >> >> - we think there is significant value in having a tools based >> approach which uses existing models, and which keeps config nodes >> in unmodified locations. Chris Hopps came up with the idea of a >> minor change to your extension where instead of adding 4 new >> config leaf values cfg-* replacing the original leaf, the three >> new leaf values would be added underneath a sibling node, perhaps >> called -cfg. The benefit of this is that user code would be >> the same with respect to intended config with or without your >> extension. This also addresses the list index problem. > Yes, there is still a possible naming clash if a model already had a > config leaf called "-cfg". > > Possibly this could be mitigated by putting the additional meta data > leaves in a separate namespace, or perhaps the pragmatic approach would > be to say don't allow leaves to be called "-cfg"! > I think keeping things as simple as possible is a good idea. Perhaps to even further reduce the possibility of naming conflict use something like -metadata rather than -cfg. > The reasoning for the approach documented in the draft is that I > perceive that it is cleaner for client that want the intended vs applied > split, but agree that the approach that Chris suggests could make > backwards compatibility easier for clients. > Keep in mind that this is a user in this case. His argument for minimizing deltas/ maximizing similarity resonates with me. I can also see how this change would make things a bit easier on the server side. >> >> - also from Chris: it would be useful to have a way of retrieving >> intended config along with any applied config that differs from >> the intended config, e.g. with-config-state=intended+diff-cfg. > Yes, I think that such filters should be fairly easy to define and > implement. I.e. if there is a scheme in place for returning the > intended and applied values it should be quite straight forward on the > server side to filter which elements are returned for a particular request. > Excellent. Thanks for the response, Lou > Thanks, > Rob > > >> >> Thoughts? >> >> Lou (with Chris) >> >> . >> > > From nobody Fri Feb 5 04:20:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561DB1B37A9 for ; Fri, 5 Feb 2016 04:20:30 -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 KmJGM6qXQVQ9 for ; Fri, 5 Feb 2016 04:20:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339041B37A3 for ; Fri, 5 Feb 2016 04:20:24 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.403.16; Fri, 5 Feb 2016 12:20:07 +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.0403.016; Fri, 5 Feb 2016 12:20:07 +0000 From: Gert Grammel To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRYA+MeBaeCYgZZkKsVQbb+hjjPA== Date: Fri, 5 Feb 2016 12:20:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 5:5wXsczgn7e0nl1T5CVYGLg7Gcf29hEH2iEussak5fagZyT46ce9mU/ULWNZME5EaTplJJJ4vFHA0d7ni8fEO3Pgc2vdU5ouK5vUcWwU3efK/POui42Ug9QLgGg7vPMMo/GZTYxiasVfnx3J3R0Yk2Q==; 24:ao2pC5r6K/H4VkqZUpHSNhuijzKDJDO863+vJwtC5sTx+7fvW2ZAeucqw1bl1uXhk8XVdu+EPDMxnYJz3PQ3GM5CAppdn2XrRav/jieRbKE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-ms-office365-filtering-correlation-id: ad40a123-7557-46dd-7549-08d32e26af8d x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(53754006)(52314003)(377454003)(377424004)(24454002)(92566002)(106116001)(5008740100001)(5004730100002)(87936001)(66066001)(5002640100001)(122556002)(86362001)(1220700001)(3846002)(19580405001)(19580395003)(83506001)(1096002)(102836003)(6116002)(40100003)(15975445007)(77096005)(189998001)(50986999)(2900100001)(54356999)(2501003)(36756003)(5001770100001)(586003)(3280700002)(11100500001)(3660700001)(99286002)(107886002)(5001960100002)(10400500002)(4001350100001)(450100001)(230783001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2016 12:20:07.7040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Fri, 05 Feb 2016 12:20:30 -0000 Hi Kent, On P.7 the current draft says: "Any rollback that may occur will restore both the intended and the applied configurations to their previous states." It is not clear to me to which phase of the configuration this statement refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous operation is defined as=20 Asynchronous Configuration Operation: A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration before replying to the client indicating whether the request will be processed. This reply to the client only indicates whether there are any errors in the original request. The server's applied configuration state is updated after the configuration change has been fully effected to all impacted components in the server. The statement "The server MUST update its intended configuration before replying to the client indicating whether the request will be processed=B2, doesn=B9t define what to do after responding. I suggest to add the followin= g clarification: 1) in case of a negative response from the Server, the server shall roll back the intended config and the applied config shall not be affected. 2) in case of a positive response from the server, the intended config shall remain. Upon failure in applying intended config, only applied config is affected according to the error-option (rollback-on-error, stop-on-error and continue-on-error) Rationale for 1: since the server didn=B9t accept a new intended config (e.g. due to a syntax error), the original intended config should remain untouched. Rationale for 2: The intended state is logically owned by the client and a server is supposed to align with it. Once a server accepted the intended config with a positive response, a failure in the server execution doesn=B9= t affect the intention. It would be the client to modify the intended state if the intention changes. The difference between intended and applied state is an important source of information for a client. Removing the intended state after rollback would nullify the intention rather than documenting which applied state differs from its intended state. This is also in line with =8Ccontinue-on-error=B9 and =8Cstop-on-error=B9. In both = cases the difference between intended and applied state is important as changes have only partially be applied. Hence the error-option should apply to applied-config. - Gert On 2016-02-02 18:54, "netmod on behalf of Kent Watsen" wrote: > >Hi All, > >I didn=B9t receive the usual announcement CC-ed to the netmod list, so I= =B9m >replying to this one sent to the id-announce list instead. > >Anyway, this morning I posted -01 of this draft and then shortly after >-02 to fix some cleanup items I only noticed after -01 was posted :ooops: > >Either way, this update is an overhaul to the original draft posted last >September. > >Kent > > > > > >On 2/2/16, 10:30 AM, "internet-drafts@ietf.org" > wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Operational State Enhancements for YANG, >>NETCONF, and RESTCONF >> Authors : Kent Watsen >> Andy Bierman >> Martin Bjorklund >> Juergen Schoenwaelder >> Filename : draft-kwatsen-netmod-opstate-02.txt >> Pages : 27 >> Date : 2016-02-02 >> >>Abstract: >> This document presents enhancements to YANG, NETCONF, and RESTCONF >> satisfying the requirements set forth in Terminology and Requirements >> for Enhanced Handling of Operational State. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/ >> >>There's also a htmlized version available at: >>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> >>A diff from the previous version is available at: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-kwatsen-netmod-opstate-02 >> >> >>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/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 5 04:23:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920141B37BC for ; Fri, 5 Feb 2016 04:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 CV7fyqUxIk-q for ; Fri, 5 Feb 2016 04:23:57 -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 2C9EE1B37B9 for ; Fri, 5 Feb 2016 04:23:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE1E8135A; Fri, 5 Feb 2016 13:23:55 +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 y0FkyYwrRAAL; Fri, 5 Feb 2016 13:23:55 +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, 5 Feb 2016 13:23:55 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D8652002B; Fri, 5 Feb 2016 13:23:55 +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 ZqIH7-bOelDe; Fri, 5 Feb 2016 13:23:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F7320013; Fri, 5 Feb 2016 13:23:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 954AC39DF93A; Fri, 5 Feb 2016 13:23:54 +0100 (CET) Date: Fri, 5 Feb 2016 13:23:54 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160205122354.GA23770@elstar.local> Mail-Followup-To: Robert Wilton , netmod@ietf.org References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B474E1.8000901@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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, 05 Feb 2016 12:23:58 -0000 On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > Hi Juergen, > > I don't really follow your point. > > The solution is fully backward compatible - in that only clients that > make use of the protocol extension would see the new encoding. Existing > clients would continue to see the encoding as directly defined in the > YANG schema, and a server would be able to support old and new clients > concurrently. > The YANG RFC details how data is encoded in XML. People have written and deployed code against based on this RFC. I do not accept an approach where an RPC option can simply request that the encoding defined in the YANG RFC is ignored and replaced with a very different encoding. /js (stating a clear opinion as a technical contributor) -- 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 Feb 5 05:12:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8C1B386E for ; Fri, 5 Feb 2016 05:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 HIMfW89ECoiP for ; Fri, 5 Feb 2016 05:12:46 -0800 (PST) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 7CD651B386D for ; Fri, 5 Feb 2016 05:12:46 -0800 (PST) Received: (qmail 13361 invoked by uid 0); 5 Feb 2016 13:12:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 5 Feb 2016 13:12:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Ecsb1s0052SSUrH01cseHW; Fri, 05 Feb 2016 05:52:42 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=lhyZeKRtMjiAhK53NmkA:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=/XzcCzScRrAbgrrzZIkAH+puyEbEZLnpnq4WiDPycEQ=; b=g8VDgHEMZowp43woIc+NZtyMCb83SEhGl6P86S7gy8q7L4PV+eWdwAfcooTYAvz1ydX+RVYDgMkD7B74mDi3O72Z6BfTA995k8L9qxIrlzVPIc5RrZ9Zg093/kZH4i+N; Received: from [100.15.91.238] (port=35804 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aRfsK-0001a0-0R; Fri, 05 Feb 2016 05:52:36 -0700 From: Lou Berger To: Juergen Schoenwaelder , Robert Wilton Date: Fri, 05 Feb 2016 07:52:33 -0500 Message-ID: <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20160205122354.GA23770@elstar.local> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Fri, 05 Feb 2016 13:12:48 -0000 Juergen, How do you feel about the proposed modification on the table? (Leaving the model defined config leaves untouched and adding a -CFG or -metadata sibling node which would contain the additional automatically generated leaves.) Lou On February 5, 2016 7:24:29 AM Juergen Schoenwaelder wrote: > On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: >> Hi Juergen, >> >> I don't really follow your point. >> >> The solution is fully backward compatible - in that only clients that >> make use of the protocol extension would see the new encoding. Existing >> clients would continue to see the encoding as directly defined in the >> YANG schema, and a server would be able to support old and new clients >> concurrently. >> > > The YANG RFC details how data is encoded in XML. People have written > and deployed code against based on this RFC. I do not accept an > approach where an RPC option can simply request that the encoding > defined in the YANG RFC is ignored and replaced with a very different > encoding. > > /js (stating a clear opinion as a technical contributor) > > -- > 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 Fri Feb 5 09:22:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02261B3BCA for ; Fri, 5 Feb 2016 09:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 e5rRIUdyI9Nx for ; Fri, 5 Feb 2016 09:22:22 -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 7B0251B3BC5 for ; Fri, 5 Feb 2016 09:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6631; q=dns/txt; s=iport; t=1454692942; x=1455902542; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6EvNxyKSod5xsoA5rtMIx0FYKr1ZuQ3iFCfuB6zJ9zc=; b=Sn5coAoGmaSvNyFpl0SVTFcYzAPzp1WBzd+6FpR/o4hlS/tZjsGPavl/ MKDo2zlvkTaKCN66sHlrIeasaiVbTm1pj7DOgOagQOBb1/TNFnfh7QIRN hISn2k3Ezjqubn8txhClIlATGopzg8iEo816pK1kDh3HDJX6Gfrq3OWg+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDT2bRW/xbLJq1ehAxtiFuxDAENg?= =?us-ascii?q?WYXCoUiSgKBbRQBAQEBAQEBgQqEQgEBBAEBASAECwEFNgoRCw4KAgIFFgsCAgk?= =?us-ascii?q?DAgECARUwBgEMBgIBAQUSiAAOsRGOXgEBAQEBAQEBAQEBAQEBAQEBAQEBARV7h?= =?us-ascii?q?ReEN4cygToFjSeJToVMiASBW0qDeYMDhVKFboEQEIcwHgEBQoNkPC4BiXsBAQE?= X-IronPort-AV: E=Sophos;i="5.22,401,1449532800"; d="scan'208";a="649075668" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 17:22:02 +0000 Received: from [10.63.23.97] (dhcp-ensft1-uk-vla370-10-63-23-97.cisco.com [10.63.23.97]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u15HM28V027912; Fri, 5 Feb 2016 17:22:02 GMT To: Kent Watsen , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> From: Robert Wilton Message-ID: <56B4DA3B.7080504@cisco.com> Date: Fri, 5 Feb 2016 17:22:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.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] I-D Action: draft-kwatsen-netmod-opstate-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: Fri, 05 Feb 2016 17:22:25 -0000 Hi Kent, and other authors, I've taken a quick look through this draft, and hence have a few comments/questions below. Some of these comments are the same that I made in reference to the previous version of this draft. 1. Minor nit: I think that the key point of this solution is that it is introducing a new applied configuration datastore, but this draft doesn't seem to state that anywhere in the introduction or abstract. E.g. the first reference to the applied configuration datastore is in section 5.1. 2. Personally, for a datastore solution, I would prefer if the new datastore was for the intended configuration, and that the applied configuration was stored in the same datastore (running?) as all the rest of the operational state. If the logical flows of system information is as follows: [candidate] -> intended cfg -> applied cfg -> derived state Then it seems strange to bundle intended cfg & derived state together in one datastore, and to have applied-cfg separate (a bit like an unwanted step child). 3. For the related-state statement, I think that this statement would be better as related-config and expressed in the reverse direction. To give a contrived example of problems with related-state based on the example in 4.1.1: Say I defined a new module that augments the ex-interfaces module that provides some further operational state for an interface. In my specific example it wants to report the actual L2 MTU/MRU values programmed in the hardware. (This could differ from a configured MTU to take into vary 802.1Q VLAN tag overheads or perhaps other slop). module ex-controller { namespace "http://example.com/controller"; prefix ctrlr; import ex-interface { prefix ex-if; } import ietf-yang-related-state { prefix yrs; } // Standard module definition. augment "/ex-if:interfaces/ex-if:interface-state" { when "if:type = 'ianaift:ethernetCsmacd'"; leaf hardware-mru { type { uint16; } description "Actual MRU programmed in hardware"; } leaf hardware-mtu { type { uint16; } description "Actual MTU programmed in hardware"; } } // Separate augmentation required for each related-state // statement. augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" { when "if:type = 'ianaift:ethernetCsmacd'"; yrs:related-state "/interfaces-state/interface/name=current()/name/hardware-mtu"; } // Separate augmentation required for each related-state // statement. augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" { when "if:type = 'ianaift:ethernetCsmacd'"; yrs:related-state "/interfaces-state/interface/name=current()/name/hardware-mru"; } } Here you will see that I would need a separate augmentation statement to set up every related-state binding. Further, YANG would need to be modified to even allow such an augmentation of a leaf. If you reverse the sense of the binding to "related-config" then I think that these problems disappear. 4. For section 5.4, get-state operation, it might be useful to clarify that if neither of the applied/derived options are specified then the data that is returned covers both the applied configuration and derived state (i.e. the data that is returned spans two datastores). 5. Am I correct to presume that this draft doesn't provide any support to return intended config, applied config & derived state all in a single request? I appreciate that this isn't included as a formal requirement - but part of me wonders whether this might have been an oversight in the requirements. 6. I can understand the decision of get-diff to reuse edit-config or YANG patch, but I'm not sure that this makes it particularly easy for clients to then process that data. I might be wrong, but I suspect that a solution that returns the values of the intended and applied config nodes in an easier to relate way may be preferable (perhaps something along the lines of the encoding proposed in draft-wilton-netmod-opstate-yang). Thanks, Rob On 02/02/2016 17:54, Kent Watsen wrote: > Hi All, > > I didn’t receive the usual announcement CC-ed to the netmod list, so I’m replying to this one sent to the id-announce list instead. > > Anyway, this morning I posted -01 of this draft and then shortly after -02 to fix some cleanup items I only noticed after -01 was posted :ooops: > > Either way, this update is an overhaul to the original draft posted last September. > > Kent > > > > > > On 2/2/16, 10:30 AM, "internet-drafts@ietf.org" wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Operational State Enhancements for YANG, NETCONF, and RESTCONF >> Authors : Kent Watsen >> Andy Bierman >> Martin Bjorklund >> Juergen Schoenwaelder >> Filename : draft-kwatsen-netmod-opstate-02.txt >> Pages : 27 >> Date : 2016-02-02 >> >> Abstract: >> This document presents enhancements to YANG, NETCONF, and RESTCONF >> satisfying the requirements set forth in Terminology and Requirements >> for Enhanced Handling of Operational State. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 5 09:34:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6081B3BC8 for ; Fri, 5 Feb 2016 09:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 YAZW2e3FGydS for ; Fri, 5 Feb 2016 09:34:36 -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 718041B3B8C for ; Fri, 5 Feb 2016 09:34:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B75913F6; Fri, 5 Feb 2016 18:34: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 Wb9eqjDYpqV2; Fri, 5 Feb 2016 18:34: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; Fri, 5 Feb 2016 18:34:33 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE0152002B; Fri, 5 Feb 2016 18:34:33 +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 2qiF6nOe2eGw; Fri, 5 Feb 2016 18:34: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 42F3B2002C; Fri, 5 Feb 2016 18:34:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9E0AF39DFBF5; Fri, 5 Feb 2016 18:34:32 +0100 (CET) Date: Fri, 5 Feb 2016 18:34:32 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160205173432.GA24243@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B4DA3B.7080504@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 05 Feb 2016 17:34:39 -0000 On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: > > 2. Personally, for a datastore solution, I would prefer if the new > datastore was for the intended configuration, and that the applied > configuration was stored in the same datastore (running?) as all the > rest of the operational state. The running datastore is a configuration datastore, it does not hold operational state. > If the logical flows of system information is as follows: > [candidate] -> intended cfg -> applied cfg -> derived state > > Then it seems strange to bundle intended cfg & derived state together in > one datastore, and to have applied-cfg separate (a bit like an unwanted > step child). This is not what is being proposed. We always had [candidate] -> [running] -> operational state (and I mark configuration data stores in []). Both [candidate] and [running] have the same configuration data model. Now we are asked to expose that [running] may not be applied synchronously and hence [candidate] -> [running] -> [applied] -> derived state seems to make sense. > 5. Am I correct to presume that this draft doesn't provide any support > to return intended config, applied config & derived state all in a > single request? I appreciate that this isn't included as a formal > requirement - but part of me wonders whether this might have been an > oversight in the requirements. Can be defines easily as another RPC. That said, I heard that some big vendors even refuse to implement today's get operation that returns the combination of [running] and operational state. > 6. I can understand the decision of get-diff to reuse edit-config or > YANG patch, but I'm not sure that this makes it particularly easy for > clients to then process that data. I might be wrong, but I suspect that > a solution that returns the values of the intended and applied config > nodes in an easier to relate way may be preferable (perhaps something > along the lines of the encoding proposed in > draft-wilton-netmod-opstate-yang). A diff is a way to make delta's efficient. /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 Feb 5 09:40:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD731B3323 for ; Fri, 5 Feb 2016 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Yg9dYfaMwDTV for ; Fri, 5 Feb 2016 09:40:46 -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 BD3C11B32E8 for ; Fri, 5 Feb 2016 09:40:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 89D4913FB; Fri, 5 Feb 2016 18:40:44 +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 Z9-ljYw0Mvsd; Fri, 5 Feb 2016 18:40:43 +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, 5 Feb 2016 18:40:43 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8F0920031; Fri, 5 Feb 2016 18:40:43 +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 PQncNaEflSsr; Fri, 5 Feb 2016 18:40:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CC692002C; Fri, 5 Feb 2016 18:40:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F188639DFC30; Fri, 5 Feb 2016 18:40:42 +0100 (CET) Date: Fri, 5 Feb 2016 18:40:42 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20160205174042.GB24243@elstar.local> Mail-Followup-To: Lou Berger , Robert Wilton , netmod@ietf.org References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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, 05 Feb 2016 17:40:47 -0000 Lou, there are things I find fundamentally flawed and things I find somewhat flawed. I do not understand why we need to mess around with data encodings at all. I do not see what gets simpler by messing around with the data encodings. Engineering decisions are usually cost/benefit tradeoffs. I see the costs, I am unsure about the benefits. /js On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > Juergen, > > How do you feel about the proposed modification on the table? (Leaving the > model defined config leaves untouched and adding a -CFG or -metadata > sibling node which would contain the additional automatically generated > leaves.) > > Lou > > > On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > wrote: > > >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > >>Hi Juergen, > >> > >>I don't really follow your point. > >> > >>The solution is fully backward compatible - in that only clients that > >>make use of the protocol extension would see the new encoding. Existing > >>clients would continue to see the encoding as directly defined in the > >>YANG schema, and a server would be able to support old and new clients > >>concurrently. > >> > > > >The YANG RFC details how data is encoded in XML. People have written > >and deployed code against based on this RFC. I do not accept an > >approach where an RPC option can simply request that the encoding > >defined in the YANG RFC is ignored and replaced with a very different > >encoding. > > > >/js (stating a clear opinion as a technical contributor) > > > >-- > >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 > > > > -- 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 Feb 5 10:14:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D881A700C for ; Fri, 5 Feb 2016 10:14:58 -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 6CuXGih0CBnD for ; Fri, 5 Feb 2016 10:14:56 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1269E1A7005 for ; Fri, 5 Feb 2016 10:14:55 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1603.namprd05.prod.outlook.com (10.161.217.20) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 5 Feb 2016 18:14:54 +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.0396.020; Fri, 5 Feb 2016 18:14:54 +0000 From: Kent Watsen To: Gert Grammel , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRYA+MeBaeCYgZZkKsVQbb+hjjPJ8dbkYA Date: Fri, 5 Feb 2016 18:14:54 +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/0.0.0.160109 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1603; 5:09+QfTypUU7wU4CPAoP42cSEpTcx3fprOySAtX07E/w4cY/DMTMnDFoej1hWkW+qCXqM3Vhlgehw2mO2Xi5n4yrXppgT8rGQ7l2znl6NseH3vYckmvxEuzT0+n7s9q0qJQHC83uHcv+zABhadhCgOQ==; 24:LWMVRlI0Zkz3RbqNk6Ig5Xsk2qQN9/7Y0GZZp7QltI/f6X1aDQYEsp7dxUKOZ2j8CqwhMPBP2pw9EcSLju8o4emrLtYAzrg3gnY4wbWVJ5w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1603; x-ms-office365-filtering-correlation-id: 621e693c-53c9-4b0b-e354-08d32e583f3a x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1603; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1603; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(377454003)(51444003)(24454002)(53754006)(377424004)(479174004)(33656002)(2950100001)(10400500002)(40100003)(19580395003)(19580405001)(5008740100001)(5001770100001)(189998001)(54356999)(230783001)(50986999)(3280700002)(2906002)(5004730100002)(106116001)(102836003)(82746002)(76176999)(5001960100002)(99286002)(6116002)(122556002)(107886002)(5002640100001)(2900100001)(83506001)(77096005)(66066001)(15975445007)(87936001)(11100500001)(1220700001)(2501003)(3846002)(92566002)(36756003)(1096002)(3660700001)(83716003)(1941001)(4001350100001)(586003)(450100001)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1603; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 05 Feb 2016 18:14:54.1101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1603 Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Fri, 05 Feb 2016 18:14:58 -0000 DQoNCg0KDQoNCk9uIDIvNS8xNiwgNzoyMCBBTSwgIkdlcnQgR3JhbW1lbCIgPGdncmFtbWVsQGp1 bmlwZXIubmV0PiB3cm90ZToNCg0KPkhpIEtlbnQsDQo+DQo+T24gUC43IHRoZSBjdXJyZW50IGRy YWZ0IHNheXM6ICJBbnkgcm9sbGJhY2sgdGhhdCBtYXkgb2NjdXIgd2lsbCByZXN0b3JlDQo+Ym90 aCB0aGUgaW50ZW5kZWQgYW5kIHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb25zIHRvIHRoZWlyIHBy ZXZpb3VzIHN0YXRlcy4iDQo+DQo+SXQgaXMgbm90IGNsZWFyIHRvIG1lIHRvIHdoaWNoIHBoYXNl IG9mIHRoZSBjb25maWd1cmF0aW9uIHRoaXMgc3RhdGVtZW50DQo+cmVmZXJzIHRvLiBJbiBkcmFm dC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDQsIEFzeW5jaHJvbm91cyBvcGVyYXRpb24gaXMN Cj5kZWZpbmVkIGFzIA0KPkFzeW5jaHJvbm91cyBDb25maWd1cmF0aW9uIE9wZXJhdGlvbjogIEEg Y29uZmlndXJhdGlvbiByZXF1ZXN0IHRvDQo+ICB1cGRhdGUgdGhlIHJ1bm5pbmcgY29uZmlndXJh dGlvbiBvZiBhIHNlcnZlciB0aGF0IGlzIGFwcGxpZWQNCj4gIGFzeW5jaHJvbm91c2x5IHdpdGgg cmVzcGVjdCB0byB0aGUgY2xpZW50IHJlcXVlc3QuICBUaGUgc2VydmVyDQo+ICBNVVNUIHVwZGF0 ZSBpdHMgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBiZWZvcmUgcmVwbHlpbmcgdG8gdGhlDQo+ICBj bGllbnQgaW5kaWNhdGluZyB3aGV0aGVyIHRoZSByZXF1ZXN0IHdpbGwgYmUgcHJvY2Vzc2VkLiAg VGhpcw0KPiAgcmVwbHkgdG8gdGhlIGNsaWVudCBvbmx5IGluZGljYXRlcyB3aGV0aGVyIHRoZXJl IGFyZSBhbnkgZXJyb3JzDQo+ICBpbiB0aGUgb3JpZ2luYWwgcmVxdWVzdC4gIFRoZSBzZXJ2ZXIn cyBhcHBsaWVkIGNvbmZpZ3VyYXRpb24NCj4gIHN0YXRlIGlzIHVwZGF0ZWQgYWZ0ZXIgdGhlIGNv bmZpZ3VyYXRpb24gY2hhbmdlIGhhcyBiZWVuIGZ1bGx5DQo+ICBlZmZlY3RlZCB0byBhbGwgaW1w YWN0ZWQgY29tcG9uZW50cyBpbiB0aGUgc2VydmVyLg0KPg0KPg0KPlRoZSBzdGF0ZW1lbnQgIlRo ZSBzZXJ2ZXIgTVVTVCB1cGRhdGUgaXRzIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gYmVmb3JlDQo+ cmVwbHlpbmcgdG8gdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoZXRoZXIgdGhlIHJlcXVlc3Qgd2ls bCBiZSBwcm9jZXNzZWTCsiwNCg0KDQpJIHRoaW5rIHRoYXQgdGhpcyBzdGF0ZW1lbnQgaXMvd2Fz IGEgbWlzdGFrZS4gIEl0IHNob3VsZOKAmXZlIGJlZW4gbGVmdCBvcGVuIHRvIHRoZSBzZXJ2ZXIg dG8gcmV0dXJuIGltbWVkaWF0ZWx5LCBhcyBldmVuIHVwZGF0aW5nIGludGVuZGVkIGNhbiB0YWtl IDNvKyBzZWNvbmRzIG9uIHNvbWUgc3lzdGVtcy4uLg0KDQoNCg0KPmRvZXNuwrl0IGRlZmluZSB3 aGF0IHRvIGRvIGFmdGVyIHJlc3BvbmRpbmcuIEkgc3VnZ2VzdCB0byBhZGQgdGhlIGZvbGxvd2lu Zw0KPmNsYXJpZmljYXRpb246DQo+MSkgaW4gY2FzZSBvZiBhIG5lZ2F0aXZlIHJlc3BvbnNlIGZy b20gdGhlIFNlcnZlciwgdGhlIHNlcnZlciBzaGFsbCByb2xsDQo+YmFjayB0aGUgaW50ZW5kZWQg Y29uZmlnIGFuZCB0aGUgYXBwbGllZCBjb25maWcgc2hhbGwgbm90IGJlIGFmZmVjdGVkLg0KPjIp IGluIGNhc2Ugb2YgYSBwb3NpdGl2ZSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2ZXIsIHRoZSBpbnRl bmRlZCBjb25maWcNCj5zaGFsbCByZW1haW4uIFVwb24gZmFpbHVyZSBpbiBhcHBseWluZyBpbnRl bmRlZCBjb25maWcsIG9ubHkgYXBwbGllZA0KPmNvbmZpZyBpcyBhZmZlY3RlZCBhY2NvcmRpbmcg dG8gdGhlIGVycm9yLW9wdGlvbiAocm9sbGJhY2stb24tZXJyb3IsDQo+c3RvcC1vbi1lcnJvciBh bmQgY29udGludWUtb24tZXJyb3IpDQoNClRoaXMgZG9lcyBub3QgbWF0Y2ggbXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgZGVzaXJlZCBiZWhhdmlvciwgbm9yIHdvdWxkIEkga25vdyBob3cgdG8gaW1w bGVtZW50IGl0IHdpdGhvdXQgaW50cm9kdWNpbmcgYWRkaXRpb25hbCBBUEkgYW5kIG1ldGFkYXRh IHRvIHN1cHBvcnQvY29udHJvbCB0aGF0IGFwcHJvYWNoLg0KDQpLZW50DQoNCg0KPlJhdGlvbmFs ZSBmb3IgMTogc2luY2UgdGhlIHNlcnZlciBkaWRuwrl0IGFjY2VwdCBhIG5ldyBpbnRlbmRlZCBj b25maWcNCj4oZS5nLiBkdWUgdG8gYSBzeW50YXggZXJyb3IpLCB0aGUgb3JpZ2luYWwgaW50ZW5k ZWQgY29uZmlnIHNob3VsZCByZW1haW4NCj51bnRvdWNoZWQuDQo+UmF0aW9uYWxlIGZvciAyOiBU aGUgaW50ZW5kZWQgc3RhdGUgaXMgbG9naWNhbGx5IG93bmVkIGJ5IHRoZSBjbGllbnQgYW5kIGEN Cj5zZXJ2ZXIgaXMgc3VwcG9zZWQgdG8gYWxpZ24gd2l0aCBpdC4gT25jZSBhIHNlcnZlciBhY2Nl cHRlZCB0aGUgaW50ZW5kZWQNCj5jb25maWcgd2l0aCBhIHBvc2l0aXZlIHJlc3BvbnNlLCBhIGZh aWx1cmUgaW4gdGhlIHNlcnZlciBleGVjdXRpb24gZG9lc27CuXQNCj5hZmZlY3QgdGhlIGludGVu dGlvbi4gSXQgd291bGQgYmUgdGhlIGNsaWVudCB0byBtb2RpZnkgdGhlIGludGVuZGVkIHN0YXRl DQo+aWYgdGhlIGludGVudGlvbiBjaGFuZ2VzLiBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGludGVu ZGVkIGFuZCBhcHBsaWVkDQo+c3RhdGUgaXMgYW4gaW1wb3J0YW50IHNvdXJjZSBvZiBpbmZvcm1h dGlvbiBmb3IgYSBjbGllbnQuIFJlbW92aW5nIHRoZQ0KPmludGVuZGVkIHN0YXRlIGFmdGVyIHJv bGxiYWNrIHdvdWxkIG51bGxpZnkgdGhlIGludGVudGlvbiByYXRoZXIgdGhhbg0KPmRvY3VtZW50 aW5nIHdoaWNoIGFwcGxpZWQgc3RhdGUgZGlmZmVycyBmcm9tIGl0cyBpbnRlbmRlZCBzdGF0ZS4g VGhpcyBpcw0KPmFsc28gaW4gbGluZSB3aXRoIMWSY29udGludWUtb24tZXJyb3LCuSBhbmQgxZJz dG9wLW9uLWVycm9ywrkuIEluIGJvdGggY2FzZXMNCj50aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGlu dGVuZGVkIGFuZCBhcHBsaWVkIHN0YXRlIGlzIGltcG9ydGFudCBhcyBjaGFuZ2VzDQo+aGF2ZSBv bmx5IHBhcnRpYWxseSBiZSBhcHBsaWVkLiBIZW5jZSB0aGUgZXJyb3Itb3B0aW9uIHNob3VsZCBh cHBseSB0bw0KPmFwcGxpZWQtY29uZmlnLg0KPg0KPi0gR2VydA0KPg0KPg0KPg0KPg0KPk9uIDIw MTYtMDItMDIgMTg6NTQsICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIg0KPjxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+DQo+Pg0KPj5IaSBBbGwsDQo+Pg0KPj5JIGRpZG7CuXQgcmVjZWl2ZSB0aGUgdXN1YWwg YW5ub3VuY2VtZW50IENDLWVkIHRvIHRoZSBuZXRtb2QgbGlzdCwgc28gScK5bQ0KPj5yZXBseWlu ZyB0byB0aGlzIG9uZSBzZW50IHRvIHRoZSBpZC1hbm5vdW5jZSBsaXN0IGluc3RlYWQuDQo+Pg0K Pj5Bbnl3YXksIHRoaXMgbW9ybmluZyBJIHBvc3RlZCAtMDEgb2YgdGhpcyBkcmFmdCBhbmQgdGhl biBzaG9ydGx5IGFmdGVyDQo+Pi0wMiB0byBmaXggc29tZSBjbGVhbnVwIGl0ZW1zIEkgb25seSBu b3RpY2VkIGFmdGVyIC0wMSB3YXMgcG9zdGVkICA6b29vcHM6DQo+Pg0KPj5FaXRoZXIgd2F5LCB0 aGlzIHVwZGF0ZSBpcyBhbiBvdmVyaGF1bCB0byB0aGUgb3JpZ2luYWwgZHJhZnQgcG9zdGVkIGxh c3QNCj4+U2VwdGVtYmVyLg0KPj4NCj4+S2VudA0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pk9uIDIv Mi8xNiwgMTA6MzAgQU0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo+PjxpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPj4NCj4+Pg0KPj4+QSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj5kaXJlY3Rv cmllcy4NCj4+Pg0KPj4+DQo+Pj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IE9wZXJhdGlvbmFs IFN0YXRlIEVuaGFuY2VtZW50cyBmb3IgWUFORywNCj4+Pk5FVENPTkYsIGFuZCBSRVNUQ09ORg0K Pj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBLZW50IFdhdHNlbg0KPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICBBbmR5IEJpZXJtYW4NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg TWFydGluIEJqb3JrbHVuZA0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFNj aG9lbndhZWxkZXINCj4+PglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1rd2F0c2VuLW5ldG1vZC1v cHN0YXRlLTAyLnR4dA0KPj4+CVBhZ2VzICAgICAgICAgICA6IDI3DQo+Pj4JRGF0ZSAgICAgICAg ICAgIDogMjAxNi0wMi0wMg0KPj4+DQo+Pj5BYnN0cmFjdDoNCj4+PiAgIFRoaXMgZG9jdW1lbnQg cHJlc2VudHMgZW5oYW5jZW1lbnRzIHRvIFlBTkcsIE5FVENPTkYsIGFuZCBSRVNUQ09ORg0KPj4+ ICAgc2F0aXNmeWluZyB0aGUgcmVxdWlyZW1lbnRzIHNldCBmb3J0aCBpbiBUZXJtaW5vbG9neSBh bmQgUmVxdWlyZW1lbnRzDQo+Pj4gICBmb3IgRW5oYW5jZWQgSGFuZGxpbmcgb2YgT3BlcmF0aW9u YWwgU3RhdGUuDQo+Pj4NCj4+Pg0KPj4+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLw0KPj4+DQo+Pj5UaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAyDQo+Pj4NCj4+PkEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAyDQo+Pj4NCj4+ Pg0KPj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj4+PnN1Ym1pc3Npb24NCj4+PnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4NCj4+Pklu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+ PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4NCj4+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5JLUQtQW5ub3VuY2UgbWFp bGluZyBsaXN0DQo+Pj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj5JbnRlcm5ldC1EcmFmdCBkaXJl Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4+b3IgZnRwOi8vZnRw LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+Pg0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+ Pm5ldG1vZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KPg0K From nobody Fri Feb 5 16:41:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC31B3155 for ; Fri, 5 Feb 2016 16:41:38 -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 VuKy05uPI0RU for ; Fri, 5 Feb 2016 16:41:36 -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 13FA61B3154 for ; Fri, 5 Feb 2016 16:41:35 -0800 (PST) Received: by mail-lb0-x236.google.com with SMTP id cw1so58396583lbb.1 for ; Fri, 05 Feb 2016 16:41: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 :content-type; bh=N3pAMURjQWY6F3eqO8R9S6aeC+lLd5ueZw/JbemVrug=; b=nS01gYkA6h1janCXt9Hz1dHW/RnJpSaqXI5yNyfc+YNTtki2G9g367szhAiCeU6I9r pai6QoPU2EKKeb+Nb1LhGdce/MY7kRwqnE4F1EqKSyx/uyEY5Aje+xpzxH+rBJITmnyR OHbGB9qGijN4tr1nKqRuLYCWkPgZFkxJA4Y7T2zxYmENzdFNfGmkFFwtJuQbmxv/GmCq BWd1x86V1fTyGrs8+m6x5kwdl3jnq3GnCNPGCu8/kTPi+E8VGvfZQqeVRBKAMomGYDak d3YlSoMbwBsFBcgaUy9qrBW29GInHn2TqUOSgjSAkMMIe5CsRaka/na4I24cwrtAWDOK 5jyA== 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=N3pAMURjQWY6F3eqO8R9S6aeC+lLd5ueZw/JbemVrug=; b=lfknIIIVWv0NECm/yqdtY7Fxgjs0hFXzv4K4O1N5HKw+0TK0Y7CTKgUZagqhQrl4KC MTDCVoRmEH11FEP9ocDvjTlE+wPn/pwuJmeXxajadyX3x3q1g0EtKvlR7yKkAIIrgkuT vI9dG5nV4U3qny6dPzGUwwM9HuJoXv623gxFUHnu7HY1hGV27Go8wa6um8NWFmr8CobB Amht7K2eeK0n9vg8tR59mfkNkdyR6PlWe8JZbsv0T74Ak34S8p+E5p0EyrVhxt4JKa3S +Q4Ow4dPOAv7HQgZ0Sc7NRk3FieixNQdN4wVZ502LdTXZaX4egD9bofIO0F7kZdgq7wN iGrg== X-Gm-Message-State: AG10YOTsP/SZCH3zQiC7g/NR8Q3L2fThW3chIYf5epyptMQ6Y1B2rnDzu98J6VEBn88oHdGZ1NceDsAAAhajgw== MIME-Version: 1.0 X-Received: by 10.112.147.1 with SMTP id tg1mr6086229lbb.119.1454719294142; Fri, 05 Feb 2016 16:41:34 -0800 (PST) Received: by 10.112.110.68 with HTTP; Fri, 5 Feb 2016 16:41:34 -0800 (PST) In-Reply-To: <20160205122354.GA23770@elstar.local> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> Date: Fri, 5 Feb 2016 16:41:34 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Robert Wilton , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a7f5cc69329052b0f3a83 Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Sat, 06 Feb 2016 00:41:38 -0000 --047d7b3a7f5cc69329052b0f3a83 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > > Hi Juergen, > > > > I don't really follow your point. > > > > The solution is fully backward compatible - in that only clients that > > make use of the protocol extension would see the new encoding. Existing > > clients would continue to see the encoding as directly defined in the > > YANG schema, and a server would be able to support old and new clients > > concurrently. > > > > The YANG RFC details how data is encoded in XML. People have written > and deployed code against based on this RFC. I do not accept an > approach where an RPC option can simply request that the encoding > defined in the YANG RFC is ignored and replaced with a very different > encoding. > > +1 I brought this up awhile back. Not only is the YANG schema replaced by some "formula", there is no indication in the at all that this is being done. Only the sender of the knows that the special encoding rules are used instead of the YANG rules. IMO, this solution is a non-starter. > /js (stating a clear opinion as a technical contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b3a7f5cc69329052b0f3a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilt= on wrote:
> Hi Juergen,
>
> I don't really follow your point.
>
> The solution is fully backward compatible - in that only clients that<= br> > make use of the protocol extension would see the new encoding. Existin= g
> clients would continue to see the encoding as directly defined in the<= br> > YANG schema, and a server would be able to support old and new clients=
> concurrently.
>

The YANG RFC details how data is encoded in XML. People have written
and deployed code against based on this RFC. I do not accept an
approach where an RPC option can simply request that the encoding
defined in the YANG RFC is ignored and replaced with a very different
encoding.


+1

I brought = this up awhile back.

Not only is the YANG schema r= eplaced by some "formula", there is no indication
in th= e <rpc-reply> at all that this is being done.=C2=A0 Only the sender o= f the <rpc> knows
that the special encoding rules are used = instead of the YANG rules.
IMO, this solution is a non-starter.

=C2=A0
/js (stating a clear opinion as a technical contributor)

--
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/>



Andy

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

--047d7b3a7f5cc69329052b0f3a83-- From nobody Mon Feb 8 01:59:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC321ACE03; Mon, 8 Feb 2016 01:59:29 -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 sgFVn6fJ_bLB; Mon, 8 Feb 2016 01:59:27 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCEF1ACE63; Mon, 8 Feb 2016 01:59:17 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 316A71CC02FD; Mon, 8 Feb 2016 10:59:18 +0100 (CET) From: Ladislav Lhotka To: Mahesh Jethanandani , NETCONF In-Reply-To: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 08 Feb 2016 10:59:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] YANG library draft. WG check of last call edits 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, 08 Feb 2016 09:59:29 -0000 Hi, I found one thing that may need clarification: consider a module containing deviations that's present in the "module" list as required. What happens if such a module does not appear in the "deviation" list of a module to which its deviation(s) are supposed to apply? Does it mean that such deviations are ignored? This doesn't seem to be specified in the description of the "deviation" list, or elsewhere. Lada Mahesh Jethanandani writes: > The yang-library draft went through a Last Call that ended January 22. Martin has taken the suggestions from the last call comments and posted an updated draft. > > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 > > Please review it for the changes made to the draft and any edits that were either missed or are not right. This would not be a time to bring in new changes or comments. > > The comment/review period will go till Monday, February 15, at which time it will be sent to our fearless AD, Benoit Claise for publication. > > Cheers. > > Mahesh & Mehmet. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 8 02:12:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E386D1ACE6E; Mon, 8 Feb 2016 02:12:39 -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, RP_MATCHES_RCVD=-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 RiG7J6SHx26k; Mon, 8 Feb 2016 02:12: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 1F3B41ACE54; Mon, 8 Feb 2016 02:12:38 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 8504D1AE0285; Mon, 8 Feb 2016 11:12:36 +0100 (CET) Date: Mon, 08 Feb 2016 11:12:40 +0100 (CET) Message-Id: <20160208.111240.1169306129093802193.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.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: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG library draft. WG check of last call edits 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, 08 Feb 2016 10:12:40 -0000 Ladislav Lhotka wrote: > Hi, > > I found one thing that may need clarification: consider a module > containing deviations that's present in the "module" list as > required. What happens if such a module does not appear in the "deviation" > list of a module to which its deviation(s) are supposed to apply? Does > it mean that such deviations are ignored? Yes. Just as it does today with similar info in . Note that this is not an error. For example, you might have a deviation module that deviates A and B, but in one particular implemementation, only the deviation for A applies. /martin > This doesn't seem to be specified in the description of the "deviation" > list, or elsewhere. > > Lada > > Mahesh Jethanandani writes: > > > The yang-library draft went through a Last Call that ended January 22. Martin has taken the suggestions from the last call comments and posted an updated draft. > > > > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 > > > > Please review it for the changes made to the draft and any edits that were either missed or are not right. This would not be a time to bring in new changes or comments. > > > > The comment/review period will go till Monday, February 15, at which time it will be sent to our fearless AD, Benoit Claise for publication. > > > > Cheers. > > > > Mahesh & Mehmet. > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > 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 Feb 8 02:33:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D11ACE8E; Mon, 8 Feb 2016 02:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 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, RP_MATCHES_RCVD=-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 OkaODZ4KTFeL; Mon, 8 Feb 2016 02:33: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 1DC661ACE92; Mon, 8 Feb 2016 02:33:04 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33] (unknown [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33]) by mail.nic.cz (Postfix) with ESMTPSA id 267331804C6; Mon, 8 Feb 2016 11:33:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454927582; bh=FBPZULW/COkZNQsb/tjTdfPgDu6Texy8oxhlWFQPmlI=; h=From:Date:To; b=asFO5dpofye86nxzSfx+y+24riZPAZJ9m7o3x+ef5SLRdwGZvjJSzP+y4GPBbm1Dg kPW8wOr05SVV6OgCtpF+CCNQECNniL9P2yYnencTYXdjzb+s0B7HH1opi+f/HCeLzX Y6MzqlEJvMaNxjp5MEx6mB5V1MDbPt0lRuXI2cl8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160208.111240.1169306129093802193.mbj@tail-f.com> Date: Mon, 8 Feb 2016 11:33:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2AA00D5E-87E3-4797-93D9-44B0604E8883@nic.cz> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> <20160208.111240.1169306129093802193.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: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG library draft. WG check of last call edits 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, 08 Feb 2016 10:33:08 -0000 > On 08 Feb 2016, at 11:12, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I found one thing that may need clarification: consider a module >> containing deviations that's present in the "module" list as >> required. What happens if such a module does not appear in the = "deviation" >> list of a module to which its deviation(s) are supposed to apply? = Does >> it mean that such deviations are ignored? >=20 > Yes. Just as it does today with similar info in . Note that IMO this isn't sufficiently explained in RFC 6020 either. > this is not an error. For example, you might have a deviation module > that deviates A and B, but in one particular implemementation, only > the deviation for A applies. OK, although this seems over-engineered, given that deviations are = strongly discouraged and cannot be standardised. I assume deviation = modules should mostly be very device-specific. Lada >=20 >=20 > /martin >=20 >> This doesn't seem to be specified in the description of the = "deviation" >> list, or elsewhere. >>=20 >> Lada >>=20 >> Mahesh Jethanandani writes: >>=20 >>> The yang-library draft went through a Last Call that ended January = 22. Martin has taken the suggestions from the last call comments and = posted an updated draft. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = >>>=20 >>> Please review it for the changes made to the draft and any edits = that were either missed or are not right. This would not be a time to = bring in new changes or comments. >>>=20 >>> The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. >>>=20 >>> Cheers. >>>=20 >>> Mahesh & Mehmet. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=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 Mon Feb 8 03:28:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43981AD094 for ; Mon, 8 Feb 2016 03:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3] 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 fe-zX_8DfL8z for ; Mon, 8 Feb 2016 03:28:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A47A1AD0CB for ; Mon, 8 Feb 2016 03:28:23 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-31-56b87bd599d6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 01.F5.02707.5DB78B65; Mon, 8 Feb 2016 12:28:21 +0100 (CET) Received: from [159.107.197.185] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Mon, 8 Feb 2016 12:28:20 +0100 References: <56694FF2.1030108@ericsson.com> To: "netmod@ietf.org" From: Balazs Lengyel X-Forwarded-Message-Id: <56694FF2.1030108@ericsson.com> Message-ID: <56B87BD4.5060607@ericsson.com> Date: Mon, 8 Feb 2016 12:28:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56694FF2.1030108@ericsson.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM2K7uu7V6h1hBps2K1jMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI1vdzMW/BarWH9gOXMD40rBLkZODgkBE4ktK34zQdhiEhfu rWfrYuTiEBI4zChx7F0vK4SzhlFi46XTzCBVwgLWEseefWABsYUEtCV+bOwE6xYRUJeYuROk m5ODTcBIYmr/eRaIqeYS07c+AbN5geov9O0Eq2cRUJHYPbkNzBYViJG42HmECaJGUOLkTIh6 TgEdie8PL7KD2MwC+hLX79xnhbDlJba/ncMMcYOGxMMLf1knMArOQtI+C0nLLCQtCxiZVzGK FqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEBufBLb8NdjC+fO54iFGAg1GJh9dgyvYwIdbEsuLK 3EOMEhzMSiK85bk7woR4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnZeHyYkkJ5YkpqdmlqQWgST ZeLglGpgdOs9pJWq88RapPi9zTIdHsPOgwk/C58aJzJtWfmsJnElr623WFDmMbHnH6oy6h+y dh7szj3luVqP477mmTmrFNK+5jYnTWjY2nU/jvWxNatur/LGmfuMw6LmnY5weH/Abr7fio0a Uivraq5POGgqGy+htu/ilnBdTtaKLoHL584k8Medm39AiaU4I9FQi7moOBEAPNfEm0oCAAA= Archived-At: Subject: [netmod] Fwd: 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: Mon, 08 Feb 2016 11:28:25 -0000 Hello,
IMHO the case, when 2 deviation statements point at the same target should be clarified and declared as an error or implementation dependent feature. I see no good way of deciding which deviation statement has precedence.
Balazs


-------- Forwarded Message --------
Subject: [netmod] Multiple deviations with same target
Date: Thu, 10 Dec 2015 11:12:02 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
To: netmod@ietf.org <netmod@ietf.org> 


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..5 in one statement while setting it to 
2..6 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

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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Mon Feb 8 04:22:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6161B29D8 for ; Mon, 8 Feb 2016 04:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 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, RP_MATCHES_RCVD=-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 s5KA1NqqkA92 for ; Mon, 8 Feb 2016 04:22: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 73AA91B29D1 for ; Mon, 8 Feb 2016 04:22:18 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33] (unknown [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33]) by mail.nic.cz (Postfix) with ESMTPSA id 125651813B2; Mon, 8 Feb 2016 13:22:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454934137; bh=dkXSViqLjow03alqSFjiuqf1/5sSq/sGaqjFICti/wo=; h=From:Date:To; b=FJkhCSu0LR5412W1f1I/NE2nk2yafrHMPQo9gRQg/22EOoSza0tnbIl1qT5ItyHvP dk0CfIaJshMd0a2m3bN8ZSjaHRKZ3g+CM5Mf4QQa7yqEHYPoHafxQyYu7ng2DUPScr 2U0z/ZWElBGWNCtDpHnFtGg3Qf4eQusRrOWUTcFo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56B87BD4.5060607@ericsson.com> Date: Mon, 8 Feb 2016 13:22:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D449013-5550-4A03-9DF8-0CBB7CACB6CA@nic.cz> References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> To: Balazs Lengyel 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] Fwd: 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: Mon, 08 Feb 2016 12:22:20 -0000 > On 08 Feb 2016, at 12:28, Balazs Lengyel = wrote: >=20 > Hello, > IMHO the case, when 2 deviation statements point at the same target = should be clarified and declared as an error or implementation dependent = feature. I see no good way of deciding which deviation statement has = precedence. I think it should be an error. Lada > Balazs >=20 >=20 > -------- Forwarded Message -------- > Subject: [netmod] Multiple deviations with same target > Date: Thu, 10 Dec 2015 11:12:02 +0100 > From: Balazs Lengyel > To: netmod@ietf.org >=20 > Hello, > What happens if I have multiple deviation statements with the same=20 > target node, possibly in separate deviation files. > E.g it is possible to have two deviation statements setting the range=20= > for an integer type leaf to 1..5 in one statement while setting it to=20= > 2..6 in another. > What is the end result? Error? > regards Balazs >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email:=20 > Balazs.Lengyel@ericsson.com >=20 >=20 > _______________________________________________ > netmod mailing list >=20 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 >=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 =20 > Mobile: +36-70-330-7909 email:=20 > Balazs.Lengyel@ericsson.com > =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 Mon Feb 8 05:22:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5F11B2AC5 for ; Mon, 8 Feb 2016 05:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ftfykpUmWW7G for ; Mon, 8 Feb 2016 05:21: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 0B2F71B2AC6 for ; Mon, 8 Feb 2016 05:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10093; q=dns/txt; s=iport; t=1454937715; x=1456147315; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=fg2Z/v/63aHOlgmxprDWCekl9W7Sdl8i3gqU+Hq3dlc=; b=OZ9biFfWcuFoXrFCeout4IzfPFAt4abEiIAYUS/8D9N+dCBZlopdksdo mtwsqjfteE4FPCCPDKhoEK2ccPIHV166rTnK6zKzIbsVm9lC4ZExW9+wp PTZDxM/3jUshBrfmlOUwGVtcnWPikYWK12OTIVL1P83hEEyGCnBF3rKpe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQDllLhW/xbLJq1aA4QMbYhbsQoBD?= =?us-ascii?q?YFmFwEJhSJKAoFiFAEBAQEBAQGBCoRBAQEBAwEBAQEgSwoGCQIJAhAICRYIAwI?= =?us-ascii?q?CCQMCAQIBCQwfEQYBDAYCAQEVAod4CA6Qa50Tjj0BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEVBIYOhDeEGjkmgjmBOgWSboQHjVCBW4dGhVKKbINSHgEBQoNkPC6HHCW?= =?us-ascii?q?BEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208,217";a="649130508" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 13:21:52 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u18DLqBI012029; Mon, 8 Feb 2016 13:21:52 GMT To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> From: Robert Wilton Message-ID: <56B89670.9090300@cisco.com> Date: Mon, 8 Feb 2016 13:21:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060601080805030307030607" Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 13:21:57 -0000 This is a multi-part message in MIME format. --------------060601080805030307030607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/02/2016 00:41, Andy Bierman wrote: > > > On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder > > wrote: > > On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > > Hi Juergen, > > > > I don't really follow your point. > > > > The solution is fully backward compatible - in that only clients > that > > make use of the protocol extension would see the new encoding. > Existing > > clients would continue to see the encoding as directly defined > in the > > YANG schema, and a server would be able to support old and new > clients > > concurrently. > > > > The YANG RFC details how data is encoded in XML. People have written > and deployed code against based on this RFC. I do not accept an > approach where an RPC option can simply request that the encoding > defined in the YANG RFC is ignored and replaced with a very different > encoding. > > > +1 > > I brought this up awhile back. > > Not only is the YANG schema replaced by some "formula", there is no > indication > in the at all that this is being done. Only the sender of > the knows > that the special encoding rules are used instead of the YANG rules. Obviously the client knows that it is making a request using this encoding, and looking at the information contained in an RPC reply I can't see how a client can usefully process an RPC reply unless they also have the request context. So, IIRC, your concern is specifically that a generic YANG client library cannot validate that the RPC reply is well formed against the schema without knowledge about the request. Is that correct? > IMO, this solution is a non-starter. OK, and yet my understanding is that the folks requesting a solution to the opstate problem are saying that the applied datastore approach is also a non-starter, or at least very undesirable. (Note - I don't actually know whether they regard the solution in draft-wilton-netmod-opstate-yang to be any more palatable.) From a clients operational perspective I can see how the OpenConfig model, with separate intended config and applied config leaves that are co-located in the schema tree makes life easy for the client in a way that having a separate applied configuration datastore doesn't seem to. Rob > > > /js (stating a clear opinion as a technical contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------060601080805030307030607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 06/02/2016 00:41, Andy Bierman wrote:


On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote:
> Hi Juergen,
>
> I don't really follow your point.
>
> The solution is fully backward compatible - in that only clients that
> make use of the protocol extension would see the new encoding. Existing
> clients would continue to see the encoding as directly defined in the
> YANG schema, and a server would be able to support old and new clients
> concurrently.
>

The YANG RFC details how data is encoded in XML. People have written
and deployed code against based on this RFC. I do not accept an
approach where an RPC option can simply request that the encoding
defined in the YANG RFC is ignored and replaced with a very different
encoding.


+1

I brought this up awhile back.

Not only is the YANG schema replaced by some "formula", there is no indication
in the <rpc-reply> at all that this is being done.  Only the sender of the <rpc> knows
that the special encoding rules are used instead of the YANG rules.

Obviously the client knows that it is making a request using this encoding, and looking at the information contained in an RPC reply I can't see how a client can usefully process an RPC reply unless they also have the request context.

So, IIRC, your concern is specifically that a generic YANG client library cannot validate that the RPC reply is well formed against the schema without knowledge about the request.  Is that correct?


IMO, this solution is a non-starter.
OK, and yet my understanding is that the folks requesting a solution to the opstate problem are saying that the applied datastore approach is also a non-starter, or at least very undesirable.  (Note - I don't actually know whether they regard the solution in draft-wilton-netmod-opstate-yang to be any more palatable.)

From a clients operational perspective I can see how the OpenConfig model, with separate intended config and applied config leaves that are co-located in the schema tree makes life easy for the client in a way that having a separate applied configuration datastore doesn't seem to.

Rob



 
/js (stating a clear opinion as a technical contributor)

--
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/>



Andy

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


--------------060601080805030307030607-- From nobody Mon Feb 8 05:30:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B31B2AB4 for ; Mon, 8 Feb 2016 05:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 8toi69jWHy3r for ; Mon, 8 Feb 2016 05:30:05 -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 5D0BA1B2AC9 for ; Mon, 8 Feb 2016 05:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3622; q=dns/txt; s=iport; t=1454938204; x=1456147804; h=from:subject:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=kk2Jck75UVwReaEO0Wm4OGyVKoZZrNO6k3+dn4H4x7E=; b=eN8r3UHylsE5MtOdVZpkTrCYXLEOwfJA7dedBYCusm7/XSFjPeqYDCo9 1l9+9tj0tNlzHJP0TXJrG3MBUnxup4QmuuwSqJyG7OU195mWKL3tMIvE9 nZpNcHOUz2gHuxLPALIFglLRGen15RCnfGQTYzkuw2HIk6PNsJEQeM9pz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBACElbhW/xbLJq1djVSyfoYNAoF2A?= =?us-ascii?q?QEBAQEBgQALhEEBAQEDAScRQBELGAkWDwkDAgECAUUGDQgBAReHeAi8SwEBAQE?= =?us-ascii?q?BAQEDAQEBAQEbhhKEN4hsAQSWdY1QiSGFUo4+YoIDGYFIPIkBAQEB?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="630316494" 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; 08 Feb 2016 13:30:02 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u18DU23Q013593 for ; Mon, 8 Feb 2016 13:30:02 GMT From: Robert Wilton To: "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> Message-ID: <56B8985A.9060501@cisco.com> Date: Mon, 8 Feb 2016 13:30:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160205173432.GA24243@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 13:30:06 -0000 Hi, On 05/02/2016 17:34, Juergen Schoenwaelder wrote: > On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: >> 2. Personally, for a datastore solution, I would prefer if the new >> datastore was for the intended configuration, and that the applied >> configuration was stored in the same datastore (running?) as all the >> rest of the operational state. > The running datastore is a configuration datastore, it does not hold > operational state. OK. Thanks for the clarification. I hadn't realised that the definition of datastores only applies to configuration and not to state! So, am I right in saying that this draft is effectively reclassifying that definition somewhat - given that applied configuration is being defined as operational state (at least in the diagram in section 3. Conceptual model) and datastores don't store state data? >> If the logical flows of system information is as follows: >> [candidate] -> intended cfg -> applied cfg -> derived state >> >> Then it seems strange to bundle intended cfg & derived state together in >> one datastore, and to have applied-cfg separate (a bit like an unwanted >> step child). > This is not what is being proposed. We always had > > [candidate] -> [running] -> operational state > > (and I mark configuration data stores in []). Both [candidate] and > [running] have the same configuration data model. Now we are asked > to expose that [running] may not be applied synchronously and hence > > [candidate] -> [running] -> [applied] -> derived state > > seems to make sense. >> 5. Am I correct to presume that this draft doesn't provide any support >> to return intended config, applied config & derived state all in a >> single request? I appreciate that this isn't included as a formal >> requirement - but part of me wonders whether this might have been an >> oversight in the requirements. > Can be defines easily as another RPC. That said, I heard that some big > vendors even refuse to implement today's get operation that returns > the combination of [running] and operational state. OK, but the key question is what does that returned data look like: Are the intended and applied config nodes going to be co-located in the same structure or is the response going to be two separate trees and for it to be up to the client to merge them together? > >> 6. I can understand the decision of get-diff to reuse edit-config or >> YANG patch, but I'm not sure that this makes it particularly easy for >> clients to then process that data. I might be wrong, but I suspect that >> a solution that returns the values of the intended and applied config >> nodes in an easier to relate way may be preferable (perhaps something >> along the lines of the encoding proposed in >> draft-wilton-netmod-opstate-yang). > A diff is a way to make delta's efficient. Yes, but often diffs include both the old and the new values to make it easier to see what the change is (or certainly they do whenever I review code diffs). I don't think that the YANG patch/edit-config encoding is significantly more efficient that the encoding that I suggested, so I don't think that efficiency of encoding is a strong argument here. The strongest argument for edit-config and YANG patch is that it is reusing an existing solution rather than inventing a new way of doing this. But I still think that my observation that this doesn't make it particularly easy for clients is valid, and other ways of encoding the data could make it easier and more useful. Rob > /js > From nobody Mon Feb 8 05:45:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E011B2B47 for ; Mon, 8 Feb 2016 05:45:54 -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, RP_MATCHES_RCVD=-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 3IU7qVjhK_G8 for ; Mon, 8 Feb 2016 05:45:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71D1B2B37 for ; Mon, 8 Feb 2016 05:45:51 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 851EA1AE0285; Mon, 8 Feb 2016 14:45:49 +0100 (CET) Date: Mon, 08 Feb 2016 14:45:53 +0100 (CET) Message-Id: <20160208.144553.2082644981061361024.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56B89670.9090300@cisco.com> References: <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.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] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 13:45:54 -0000 Robert Wilton wrote: > > > On 06/02/2016 00:41, Andy Bierman wrote: [...] > > IMO, this solution is a non-starter. > OK, and yet my understanding is that the folks requesting a solution > to the opstate problem are saying that the applied datastore approach > is also a non-starter, or at least very undesirable. But the key to finding a solution that works for everyone is to understand *why* a datastore is a non-starter. As I noted in a previous email, both your solution and the datastore solution rely on the assumption that the server internally knows the difference between the "intended" and "applied" value for the config true nodes. > (Note - I don't > actually know whether they regard the solution in > draft-wilton-netmod-opstate-yang to be any more palatable.) Right; so if their objection is that the server cannot know the difference between "intended" and "applied" for the config true leafs, neither of our solutions work. And if their objection is that their proprietary protocol does can/does not encode the datastore in the "get" request, then I suspect that their protocol also does not know your proposed encoding. > From a clients operational perspective I can see how the OpenConfig > model, with separate intended config and applied config leaves that > are co-located in the schema tree makes life easy for the client in a > way that having a separate applied configuration datastore doesn't > seem to. I can see how the applied datastore model makes life easier for the client, e.g., a diff can be done w/o any data model knowledge at all. /martin > > Rob > > > > > > > > /js (stating a clear opinion as a technical contributor) > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > From nobody Mon Feb 8 06:38:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB81B2BE7 for ; Mon, 8 Feb 2016 06:38:19 -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, RP_MATCHES_RCVD=-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 nIQ8BGGUh6zF for ; Mon, 8 Feb 2016 06:38: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 6D5951B2C0B for ; Mon, 8 Feb 2016 06:38:17 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id CEDF41AE0285; Mon, 8 Feb 2016 15:38:15 +0100 (CET) Date: Mon, 08 Feb 2016 15:38:19 +0100 (CET) Message-Id: <20160208.153819.237705833994731271.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56B8985A.9060501@cisco.com> References: <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.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] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 14:38:19 -0000 Robert Wilton wrote: > Hi, > > On 05/02/2016 17:34, Juergen Schoenwaelder wrote: > > On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: > >> 2. Personally, for a datastore solution, I would prefer if the new > >> datastore was for the intended configuration, and that the applied > >> configuration was stored in the same datastore (running?) as all the > >> rest of the operational state. > > The running datastore is a configuration datastore, it does not hold > > operational state. > OK. Thanks for the clarification. I hadn't realised that the > definition of datastores only applies to configuration and not to > state! No, this is not correct. RFC 6241 defines both "datastore" and "configuration datastore". However, "running" is a "configuration datastore". /martin > So, am I right in saying that this draft is effectively reclassifying > that definition somewhat - given that applied configuration is being > defined as operational state (at least in the diagram in section > 3. Conceptual model) and datastores don't store state data? > > > >> If the logical flows of system information is as follows: > >> [candidate] -> intended cfg -> applied cfg -> derived state > >> > >> Then it seems strange to bundle intended cfg & derived state together > >> in > >> one datastore, and to have applied-cfg separate (a bit like an > >> unwanted > >> step child). > > This is not what is being proposed. We always had > > > > [candidate] -> [running] -> operational state > > > > (and I mark configuration data stores in []). Both [candidate] and > > [running] have the same configuration data model. Now we are asked > > to expose that [running] may not be applied synchronously and hence > > > > [candidate] -> [running] -> [applied] -> derived state > > > > seems to make sense. > >> 5. Am I correct to presume that this draft doesn't provide any support > >> to return intended config, applied config & derived state all in a > >> single request? I appreciate that this isn't included as a formal > >> requirement - but part of me wonders whether this might have been an > >> oversight in the requirements. > > Can be defines easily as another RPC. That said, I heard that some big > > vendors even refuse to implement today's get operation that returns > > the combination of [running] and operational state. > OK, but the key question is what does that returned data look like: > Are the intended and applied config nodes going to be co-located in > the same structure or is the response going to be two separate trees > and for it to be up to the client to merge them together? > > > > >> 6. I can understand the decision of get-diff to reuse edit-config or > >> YANG patch, but I'm not sure that this makes it particularly easy for > >> clients to then process that data. I might be wrong, but I suspect > >> that > >> a solution that returns the values of the intended and applied config > >> nodes in an easier to relate way may be preferable (perhaps something > >> along the lines of the encoding proposed in > >> draft-wilton-netmod-opstate-yang). > > A diff is a way to make delta's efficient. > Yes, but often diffs include both the old and the new values to make > it easier to see what the change is (or certainly they do whenever I > review code diffs). > > I don't think that the YANG patch/edit-config encoding is > significantly more efficient that the encoding that I suggested, so I > don't think that efficiency of encoding is a strong argument here. > > The strongest argument for edit-config and YANG patch is that it is > reusing an existing solution rather than inventing a new way of doing > this. But I still think that my observation that this doesn't make it > particularly easy for clients is valid, and other ways of encoding the > data could make it easier and more useful. > > Rob > > > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Feb 8 06:54:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98E51B2C88 for ; Mon, 8 Feb 2016 06:54:02 -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 QfmBvM4XLrlx for ; Mon, 8 Feb 2016 06:53:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.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 2DD231B2C40 for ; Mon, 8 Feb 2016 06:53:58 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 8 Feb 2016 14:53:57 +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.0403.017; Mon, 8 Feb 2016 14:53:57 +0000 From: Gert Grammel To: Juergen Schoenwaelder , "Robert Wilton" Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRXeLKOW+rjqCc7kiS321+Ltbrbp8dt6+AgAADfQCABJrigA== Date: Mon, 8 Feb 2016 14:53:57 +0000 Message-ID: References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> In-Reply-To: <20160205173432.GA24243@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.10] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 5:Zt6bb5p3sxoY8WU8Ud1Jd7gBpDd64la+LNfnDd0xhRHY5mLijW/oyDVpnIveY734KppEuTfauwkXRuSoWCbbuRu4BB+lgbIX2B4clsztHnElteWBBLHSAcBaRLuIdylRFThC9SHxJYhMJntYJaK3ew==; 24:b9aKW664/TCgtooAOdPos0Ruq/c+EfrdBvuQN2g3HG5BkdklCPOFj8CaS3ZEdzifG2FzetcjkJPI1JAaYrvwHDWPihPW/OUPso+A5mQ1CIk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1611; x-ms-office365-filtering-correlation-id: 17cd5e0e-c7ca-44bf-6071-08d33097ac5a 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)(3002001)(10201501046); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611; x-forefront-prvs: 084674B2CF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377424004)(2950100001)(5004730100002)(93886004)(11100500001)(5008740100001)(230783001)(87936001)(66066001)(2900100001)(99286002)(40100003)(106116001)(5001770100001)(77096005)(36756003)(4326007)(4001350100001)(19580395003)(122556002)(83506001)(10400500002)(86362001)(3660700001)(6116002)(3846002)(3280700002)(102836003)(189998001)(76176999)(54356999)(92566002)(5002640100001)(50986999)(19580405001)(5001960100002)(2906002)(1096002)(15975445007)(586003)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 14:53:57.7764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 14:54:03 -0000 On 2016-05-02 18:34, "netmod on behalf of Juergen Schoenwaelder" wrote: >On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: >>=20 >> 2. Personally, for a datastore solution, I would prefer if the new >> datastore was for the intended configuration, and that the applied >> configuration was stored in the same datastore (running?) as all the >> rest of the operational state. > >The running datastore is a configuration datastore, it does not hold >operational state. > >> If the logical flows of system information is as follows: >> [candidate] -> intended cfg -> applied cfg -> derived state >>=20 >> Then it seems strange to bundle intended cfg & derived state together >>in=20 >> one datastore, and to have applied-cfg separate (a bit like an unwanted >> step child). > >This is not what is being proposed. We always had > >[candidate] -> [running] -> operational state > >(and I mark configuration data stores in []). Both [candidate] and >[running] have the same configuration data model. Now we are asked >to expose that [running] may not be applied synchronously and hence > >[candidate] -> [running] -> [applied] -> derived state > >seems to make sense. The mapping of what is called intended-config onto data stores would deserve more detailed discussion. It seems the authors of this draft had in mind to associate intended-cfg with the [running] datastore. With that mapping, a failure in applying [running] to [applied] will update the [running] datastore to reflect which part is effectively applied. So a fair representation of that case would be: [candidate] -> [running] <--> [applied] -> derived state In the context of intended configuration however that doesn=B9t make sense to me. A failure in applying intended configuration doesn=B9t change the intention and the delta between intended and applied-config is the key value. A server that would "clean-up=B2 intended-cfg in presence of a failure to apply would look picture perfect instead of exposing the problem clearly. Hence the sequence should more look like: [candidate] -> [intended] =8B> [running=3D=3Dapplied] -> derived state Whatever we choose, I believe we need to spell out what=B9s the data in a failure case. It=B9s probably a bit late to update the requirements draft, but we can probably find a suitable place. > >> 5. Am I correct to presume that this draft doesn't provide any support >> to return intended config, applied config & derived state all in a >> single request? I appreciate that this isn't included as a formal >> requirement - but part of me wonders whether this might have been an >> oversight in the requirements. > >Can be defines easily as another RPC. That said, I heard that some big >vendors even refuse to implement today's get operation that returns >the combination of [running] and operational state. >=20 >> 6. I can understand the decision of get-diff to reuse edit-config or >> YANG patch, but I'm not sure that this makes it particularly easy for >> clients to then process that data. I might be wrong, but I suspect >>that=20 >> a solution that returns the values of the intended and applied config >> nodes in an easier to relate way may be preferable (perhaps something >> along the lines of the encoding proposed in >> draft-wilton-netmod-opstate-yang). > >A diff is a way to make delta's efficient. > >/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 From nobody Mon Feb 8 07:22:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AE01B2D0A for ; Mon, 8 Feb 2016 07:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 vNyU1rEe45Cp for ; Mon, 8 Feb 2016 07:22:40 -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 B9DFE1B2D05 for ; Mon, 8 Feb 2016 07:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5340; q=dns/txt; s=iport; t=1454944959; x=1456154559; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4q+2PVEPReSp1dRY6UG2hGq/9CFuV1cfXOyge9kQFus=; b=X76zlc1d7EI+BKqEHJ02iYzscbj00zZ6IKrjrdMrKVcBMhamuG1jGkKD rS+NL2x0IJ3mEcJi/hhCSh5zZNCtV3VCqhKQhEN4PfL+z0aLYxYR5uOu0 yrrUt7NgyTMsuOQ1fRWAieJReWZt0d7tT0auWuwMx/WKFzpOQI+FW6UDQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQC9sbhW/xbLJq1UBwOEDG2IW7ELA?= =?us-ascii?q?Q2BZhcKhSJKAoFkFAEBAQEBAQGBCoRBAQEBAwEBAQE1NgoBBQkCCw4CCAkWCAc?= =?us-ascii?q?JAwIBAgEJDB8RBg0GAgEBFQKHeAgOvQQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVB?= =?us-ascii?q?IYOhDeEAgYLAQY5JoNzBY0niU6NUIFbhEODAyOFL4psg1IeAQFCg2Q8LocjgTA?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="632425929" 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; 08 Feb 2016 15:22:36 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u18FMaKW025046; Mon, 8 Feb 2016 15:22:36 GMT To: Martin Bjorklund References: <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208.144553.2082644981061361024.mbj@tail-f.com> From: Robert Wilton Message-ID: <56B8B2BC.9050809@cisco.com> Date: Mon, 8 Feb 2016 15:22:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208.144553.2082644981061361024.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] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 15:22:42 -0000 Hi Martin, On 08/02/2016 13:45, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 06/02/2016 00:41, Andy Bierman wrote: > [...] > >>> IMO, this solution is a non-starter. >> OK, and yet my understanding is that the folks requesting a solution >> to the opstate problem are saying that the applied datastore approach >> is also a non-starter, or at least very undesirable. > But the key to finding a solution that works for everyone is to > understand *why* a datastore is a non-starter. As I noted in a [Caveat - I don't speak for the OpenConfig operators, this is just my perception from previous drafts, conversations, implementing some of the OpenConfig models] My understanding is that they want something this is very similar to how the OpenConfig models look. After all, their preferred solution to the opstate problem would be for IETF to standardize on the approach used in OpenConfig model design. E.g. all config nodes are defined in groupings, and then instantiated under both "config" and "state" containers. I believe that their concerns are primarily about how the operators systems interact with the models from a management client perspective rather than device implementation concerns. With the OpenConfig model/approach they get: - The choice of having one single tree that contains all the data (intended, applied and derived) - but can be split into multiple trees if they wish. (I.e. with their model they have no requirement to be aware of separate data stores at all.) - Every piece of data in that tree has a unique path to identify it (makes the data easy to interact with). - The intended config, applied config, and derived state can all be programmatically compared. - Related information is co-located in the tree (e.g. if you were browsing the data tree). With a datastore solution, I think that it means: - Either they have to put intended and applied config into separate trees, or they have to come up with their own scheme to combine them into a single tree (given that the cfg intended/applied names clash). - If separate trees, to ensure paths are unique they would need to prefix every path with the name of the datastore/tree (hassle). - Comparing the intended and applied trees is a bit more hassle (they would need to perform a pairwise walk across both intended and applied configuration trees). - When data is being returned from the server (if it is even allowed for two datastores to be returned in the same request) then data would not be co-located. I.e. you have to read in all the data for both intended and applied config datastores before you can start processing any of it. Whereas if the data is returned in a single tree then co-located data would be returned together and the the stream of data can be filtered/processed without building up an intermediate combined tree of all the data. > previous email, both your solution and the datastore solution rely on > the assumption that the server internally knows the difference between > the "intended" and "applied" value for the config true nodes. Please can you clarify - I don't really follow this point. For all solutions, it only makes sense if the server internally knows the difference between intended and applied values, so I assume that is just a given. > >> (Note - I don't >> actually know whether they regard the solution in >> draft-wilton-netmod-opstate-yang to be any more palatable.) > Right; so if their objection is that the server cannot know the > difference between "intended" and "applied" for the config true leafs, > neither of our solutions work. > > And if their objection is that their proprietary protocol does > can/does not encode the datastore in the "get" request, then > I suspect that their protocol also does not know your proposed > encoding. > >> From a clients operational perspective I can see how the OpenConfig >> model, with separate intended config and applied config leaves that >> are co-located in the schema tree makes life easy for the client in a >> way that having a separate applied configuration datastore doesn't >> seem to. > I can see how the applied datastore model makes life easier for the > client, e.g., a diff can be done w/o any data model knowledge at all. Possibly. But that requires that they have to manage having a separate datastore for applied config in the first place, and I'm not convinced that doing a pairwise diff across two datastores is any easier than the equivalent "diff" algorithm that they would write for checking the config state in the OpenConfig models. Rob > > > /martin > > >> Rob >> >> >>> >>> /js (stating a clear opinion as a technical contributor) >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> >>> >>> Andy >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> > . > From nobody Mon Feb 8 07:43:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D1F1B2D78 for ; Mon, 8 Feb 2016 07:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 OWeeTxhYd1Vv for ; Mon, 8 Feb 2016 07:43:14 -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 147DD1B2D73 for ; Mon, 8 Feb 2016 07:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1454946194; x=1456155794; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3CfSh24ZXGoiGWfhfvI4+VDuDgkxVm027bVQjhXGQvw=; b=nIl6ZnemBoR/CmPf2ox26WGCfqTVgA66uOL9x0bWUwl07LA+a8rS6IzQ LlsJPcs7usSXHQXhdfF+ezx+rN70e9apG/ztKkVSDgXtj3SWd0SEBENc8 vgGmVwViSTjg02JWtA1cUe4es6wzbUto1PnpeDQs6MO4WTDVXIEeXo1B9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQAft7hW/xbLJq1ehHmIW7ELAQ2BZ?= =?us-ascii?q?oYNAoFlFAEBAQEBAQGBCoRCAQEEOEABEAsOCgkWDwkDAgECAUUGDQYCAQEXiAC?= =?us-ascii?q?9EAEBAQEBAQEBAQEBAQEBAQEBGYYShDeIbAEElnWNUIFbhEODA4VSjj4eAQFCg?= =?us-ascii?q?2Q8LohTAQEB?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="649134750" 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; 08 Feb 2016 15:43:11 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u18FhBH0030146; Mon, 8 Feb 2016 15:43:11 GMT To: Martin Bjorklund References: <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208.153819.237705833994731271.mbj@tail-f.com> From: Robert Wilton Message-ID: <56B8B790.4040908@cisco.com> Date: Mon, 8 Feb 2016 15:43:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208.153819.237705833994731271.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] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 15:43:15 -0000 Hi Martin, On 08/02/2016 14:38, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi, >> >> On 05/02/2016 17:34, Juergen Schoenwaelder wrote: >>> On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: >>>> 2. Personally, for a datastore solution, I would prefer if the new >>>> datastore was for the intended configuration, and that the applied >>>> configuration was stored in the same datastore (running?) as all the >>>> rest of the operational state. >>> The running datastore is a configuration datastore, it does not hold >>> operational state. >> OK. Thanks for the clarification. I hadn't realised that the >> definition of datastores only applies to configuration and not to >> state! > No, this is not correct. RFC 6241 defines both "datastore" and > "configuration datastore". However, "running" is a "configuration > datastore". OK. RFC 6241 defines terminology for "datastore", but the body of the text only ever seems to ever use the term datastore in the context of a "configuration datastore". Hence please can you clarify, does the operational state live in a non configuration datastore, and if so which one? Otherwise, are there any other uses of non-configuration datastores by NETCONF? Thanks, Rob From nobody Mon Feb 8 08:21:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF741B2E88 for ; Mon, 8 Feb 2016 08:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DSCRdsnev0K9 for ; Mon, 8 Feb 2016 08:21:02 -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 7A21D1B2DCF for ; Mon, 8 Feb 2016 08:21:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A362B105A; Mon, 8 Feb 2016 17:21:00 +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 e77di6mgyvBj; Mon, 8 Feb 2016 17:21:00 +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, 8 Feb 2016 17:21:00 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F060520031; Mon, 8 Feb 2016 17:20:59 +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 0JZf77F_gude; Mon, 8 Feb 2016 17:20: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 12EEE2002C; Mon, 8 Feb 2016 17:20:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D9AD039E0FA0; Mon, 8 Feb 2016 17:20:59 +0100 (CET) Date: Mon, 8 Feb 2016 17:20:59 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160208162059.GA29638@elstar.local> Mail-Followup-To: Robert Wilton , Andy Bierman , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B89670.9090300@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 16:21:06 -0000 On Mon, Feb 08, 2016 at 01:21:52PM +0000, Robert Wilton wrote: > > So, IIRC, your concern is specifically that a generic YANG client > library cannot validate that the RPC reply is well formed against the > schema without knowledge about the request. Is that correct? > None of the existing tools that assume YANG defined data is XML encoded according to RFC 6020 will not be able to process data in a new encoding. /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 Feb 8 08:26:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67D1B2E9C for ; Mon, 8 Feb 2016 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 XqRIy9R2FT3Q for ; Mon, 8 Feb 2016 08:26:17 -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 1EA951B2E9E for ; Mon, 8 Feb 2016 08:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1471; q=dns/txt; s=iport; t=1454948777; x=1456158377; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=hnS8QEN5aMR7Ibz6U8IUtM+qMW4qyUqq27nltuMJurY=; b=aUepib6DZavh6HlH6GMpG1cXumlhUdXqHHuwkm7HhJB6DBWnswBmvVQ9 anQ0reaCVF7rIy/Le221bvokJ7akKzaWytXU0iXQyWydrCFPFAa1YBYC9 m+enJ07Vvc9U7oa7Z+fxXSoG1SB+rPPPJ9QxVdLdDwJ/iVZm/AuepTW98 k=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="asc'?scan'208";a="624220545" 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; 08 Feb 2016 16:26:15 +0000 Received: from [10.61.203.222] ([10.61.203.222]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u18GQEvi029388; Mon, 8 Feb 2016 16:26:15 GMT To: Robert Wilton , Andy Bierman , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> From: Eliot Lear Message-ID: <56B8C1A5.9040508@cisco.com> Date: Mon, 8 Feb 2016 17:26:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160208162059.GA29638@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eoNOKBfXhTBXb4bqig1urbhqatWgmO9dv" Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 16:26:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eoNOKBfXhTBXb4bqig1urbhqatWgmO9dv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Juergen, On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote: > None of the existing tools that assume YANG defined data is XML > encoded according to RFC 6020 will not be able to process data in a > new encoding. Reversing you're negatives you are asserting that all existing tools that assume that YANG defined data is XML encoded will be able to process data in a new encoding. Is that really what you meant to say?=20 If so, could you kindly explain what you mean by "tools"? Yours for less double negatives... Eliot --eoNOKBfXhTBXb4bqig1urbhqatWgmO9dv 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 iQEcBAEBCAAGBQJWuMGmAAoJEIe2a0bZ0nozpNAH/R0YfWfdfq9jgt6NiPy5WVFl s4VSCbJvaaFwauzKD6Em+sscgCSDbyjoi4n3gSrqk+LTrgXc0MrxKVBT45ieaSYL m0TWjRq7WdXAIgANw/6d9ioPUdQQ8iLOqTEVgbPvZ6VlXhIKUQTyNrc1/7gqUqqr zJY4Plis3i19I2YS2LHPUaWj3KuOVvuIwk6zZILcPCDrjko9jQ/2qcsqyZQHmh1A 0+T1unY3VZYRYamqNiReNK3vddYl8YSKJfFjP+q10AhItqIT2jttuuYNll+Df742 3yO5/p20q9WGjH2UK/ucT0mv/VGZkhjJzQUscdSkGjv632OvCv0fFBmHky2na/I= =zUmE -----END PGP SIGNATURE----- --eoNOKBfXhTBXb4bqig1urbhqatWgmO9dv-- From nobody Mon Feb 8 08:31:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47B31B2EAF for ; Mon, 8 Feb 2016 08:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 a_kE0Fa7l6bS for ; Mon, 8 Feb 2016 08:31:28 -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 AB8AC1B2EA0 for ; Mon, 8 Feb 2016 08:31:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 50EC91056; Mon, 8 Feb 2016 17:31:26 +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 6htZrv1hwpOz; Mon, 8 Feb 2016 17:31: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; Mon, 8 Feb 2016 17:31:24 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D130D2002C; Mon, 8 Feb 2016 17:31: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 Bfdz40skE4TK; Mon, 8 Feb 2016 17:31:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90C7B2002B; Mon, 8 Feb 2016 17:31:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 76A2939E1008; Mon, 8 Feb 2016 17:31:23 +0100 (CET) Date: Mon, 8 Feb 2016 17:31:23 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160208163123.GB29638@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B8985A.9060501@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 08 Feb 2016 16:31:30 -0000 On Mon, Feb 08, 2016 at 01:30:02PM +0000, Robert Wilton wrote: > Hi, > > On 05/02/2016 17:34, Juergen Schoenwaelder wrote: > >On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: > >>2. Personally, for a datastore solution, I would prefer if the new > >>datastore was for the intended configuration, and that the applied > >>configuration was stored in the same datastore (running?) as all the > >>rest of the operational state. > >The running datastore is a configuration datastore, it does not hold > >operational state. > OK. Thanks for the clarification. I hadn't realised that the > definition of datastores only applies to configuration and not to state! > > So, am I right in saying that this draft is effectively reclassifying > that definition somewhat - given that applied configuration is being > defined as operational state (at least in the diagram in section 3. > Conceptual model) and datastores don't store state data? Not sure what 'that definition' refers to. This WG has had lenghty discussions how we look at operational state has. Some of it is briefly mentioned in RFC 6244 and there were quite a few presentations at IETF meetings before 'the operators' started contributing ideas. > >>If the logical flows of system information is as follows: > >> [candidate] -> intended cfg -> applied cfg -> derived state > >> > >>Then it seems strange to bundle intended cfg & derived state together in > >>one datastore, and to have applied-cfg separate (a bit like an unwanted > >>step child). > >This is not what is being proposed. We always had > > > >[candidate] -> [running] -> operational state > > > >(and I mark configuration data stores in []). Both [candidate] and > >[running] have the same configuration data model. Now we are asked > >to expose that [running] may not be applied synchronously and hence > > > >[candidate] -> [running] -> [applied] -> derived state > > > >seems to make sense. > >>5. Am I correct to presume that this draft doesn't provide any support > >>to return intended config, applied config & derived state all in a > >>single request? I appreciate that this isn't included as a formal > >>requirement - but part of me wonders whether this might have been an > >>oversight in the requirements. > >Can be defines easily as another RPC. That said, I heard that some big > >vendors even refuse to implement today's get operation that returns > >the combination of [running] and operational state. > OK, but the key question is what does that returned data look like: Are > the intended and applied config nodes going to be co-located in the same > structure or is the response going to be two separate trees and for it > to be up to the client to merge them together? > > > > >>6. I can understand the decision of get-diff to reuse edit-config or > >>YANG patch, but I'm not sure that this makes it particularly easy for > >>clients to then process that data. I might be wrong, but I suspect that > >>a solution that returns the values of the intended and applied config > >>nodes in an easier to relate way may be preferable (perhaps something > >>along the lines of the encoding proposed in > >>draft-wilton-netmod-opstate-yang). > >A diff is a way to make delta's efficient. > Yes, but often diffs include both the old and the new values to make it > easier to see what the change is (or certainly they do whenever I review > code diffs). > > I don't think that the YANG patch/edit-config encoding is significantly > more efficient that the encoding that I suggested, so I don't think that > efficiency of encoding is a strong argument here. So if in my 1 million XML elements one has not been applied, how do I find out efficiently in your encoding? > The strongest argument for edit-config and YANG patch is that it is > reusing an existing solution rather than inventing a new way of doing > this. But I still think that my observation that this doesn't make it > particularly easy for clients is valid, and other ways of encoding the > data could make it easier and more useful. We are on a very slippery slope here - what may be easy for one client may not be easy for another client. Difficult for taking good engineering decisions. /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 Feb 8 08:37:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515121B2ED9 for ; Mon, 8 Feb 2016 08:37:11 -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 Y2ykTWsJyjRc for ; Mon, 8 Feb 2016 08:37:10 -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 F32991B2ED8 for ; Mon, 8 Feb 2016 08:37:09 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id 78so98950572lfy.3 for ; Mon, 08 Feb 2016 08:37:09 -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=aoDzaSSEJBWDHULObQbQEdpSZjF3pB9hNIfqHMM+ENM=; b=1rZh2q9MWrczZ4Znp22g8WDrXkQlIFyl9IBdhCO62RJglpy8gDk+nvRxrFatZOwMvc 250trCboxOqor+UhXSlZEIIteLrmjPZ/O9n6BBJpb5+iavLKMZOEZf5AxRSN+uZOTX+I 6LzIn6chH4+rweS/oi6tVco1u8B+nni3i0cVXIWCDKqVqS9xKsqgEV9BVI18Kpn5Z6EU RtMXX/qXZxO0wZeZ1EUJcKlcBIS/qkndX2xVLsAB06Mf7hW8f5fbwu+q6FVoRjSpfQ06 nscpfIVGfAiJjsahWiunmIYYCf2Mau5wMzdPep7lsS6abcBYyH00hdgFr2LpjAS98N/M sefQ== 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=aoDzaSSEJBWDHULObQbQEdpSZjF3pB9hNIfqHMM+ENM=; b=eO2y3CKDgDK0YI1Seprew93yleb/UQH6qT7LG9Ah5W7O4XLAS48H2XWooruL/58caZ oX/KCFQwoltTfJsqUGelg4QDfvdmmhU20FGc/hBbqW4zADsnVUgW35aEbciiCSvynaDS DzG7DQ9xyQ5IunV4lT1KdQf8LqA73QF7IauHvB0+4DB99/JVarWIMfwxp3TNSBWGlIyc MG2CahquDFcYsUCA7p1SoFaV1wsnMPoZZ9ZKMuVzdZfB0snhSIOR4hL41QOVdtx+Qdzp r42F+XeUFQGh5UG2HXPLHDKutX3EuAAqxYmIZbXOMinDhSc62pLM962UZgAZPa0YlWLm /8cA== X-Gm-Message-State: AG10YOTX728XaP9D5ooURU+4oH+X4P5GyHGhig42PIKameyC7DqSx60NRWytfvOcWT+S82GNq03+FT1MoT5Ong== MIME-Version: 1.0 X-Received: by 10.25.39.134 with SMTP id n128mr12757741lfn.54.1454949428130; Mon, 08 Feb 2016 08:37:08 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 8 Feb 2016 08:37:07 -0800 (PST) In-Reply-To: <56B8C1A5.9040508@cisco.com> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B8C1A5.9040508@cisco.com> Date: Mon, 8 Feb 2016 08:37:07 -0800 Message-ID: From: Andy Bierman To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11410470d48df9052b44cf8a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 16:37:11 -0000 --001a11410470d48df9052b44cf8a Content-Type: text/plain; charset=UTF-8 Hi, The XML namespace matches the YANG namespace-stmt. The JSON module name prefix matches the YANG module name. All YANG tools use these instance document mechanisms to find the correct YANG schema to apply. All YANG tools will correctly decide the opstate reporting does not match the YANG module schema, and reject the instance document. Andy On Mon, Feb 8, 2016 at 8:26 AM, Eliot Lear wrote: > Juergen, > > On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote: > > > None of the existing tools that assume YANG defined data is XML > > encoded according to RFC 6020 will not be able to process data in a > > new encoding. > > Reversing you're negatives you are asserting that all existing tools > that assume that YANG defined data is XML encoded will be able to > process data in a new encoding. Is that really what you meant to say? > If so, could you kindly explain what you mean by "tools"? > > Yours for less double negatives... > > Eliot > > > --001a11410470d48df9052b44cf8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The XML namespace matches the YANG = namespace-stmt.
The JSON module name prefix matches the YANG modu= le name.
All YANG tools use these instance document mechanisms to= find
the correct YANG schema to apply.=C2=A0 All YANG tools will= correctly
decide the opstate reporting does not match the YANG m= odule schema,
and reject the instance document.


Andy


On Mon, Feb 8, 2016 at 8:26 AM, Eliot = Lear <lear@cisco.com> wrote:
= Juergen,

On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote:

> None of the existing tools that assume YANG defined data is XML
> encoded according to RFC 6020 will not be able to process data in a > new encoding.

Reversing you're negatives you are asserting that all existing tools that assume that YANG defined data is XML encoded will be able to
process data in a new encoding.=C2=A0 Is that really what you meant to say?=
If so, could you kindly explain what you mean by "tools"?

Yours for less double negatives...

Eliot



--001a11410470d48df9052b44cf8a-- From nobody Mon Feb 8 08:38:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62811B2EE1 for ; Mon, 8 Feb 2016 08:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wN1UWb00fopt for ; Mon, 8 Feb 2016 08:38: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 5EE4D1B2EDA for ; Mon, 8 Feb 2016 08:38: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 2BC861108; Mon, 8 Feb 2016 17:38:23 +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 bReu0fYivWy2; Mon, 8 Feb 2016 17:38:22 +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, 8 Feb 2016 17:38:22 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E01A2002C; Mon, 8 Feb 2016 17:38:22 +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 AE9kYgq26Y5y; Mon, 8 Feb 2016 17:38:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B60912002B; Mon, 8 Feb 2016 17:38:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9C13939E103C; Mon, 8 Feb 2016 17:38:21 +0100 (CET) Date: Mon, 8 Feb 2016 17:38:21 +0100 From: Juergen Schoenwaelder To: Gert Grammel Message-ID: <20160208163821.GC29638@elstar.local> Mail-Followup-To: Gert Grammel , Robert Wilton , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 08 Feb 2016 16:38:27 -0000 On Mon, Feb 08, 2016 at 02:53:57PM +0000, Gert Grammel wrote: > > > >This is not what is being proposed. We always had > > > >[candidate] -> [running] -> operational state > > > >(and I mark configuration data stores in []). Both [candidate] and > >[running] have the same configuration data model. Now we are asked > >to expose that [running] may not be applied synchronously and hence > > > >[candidate] -> [running] -> [applied] -> derived state > > > >seems to make sense. Why would that be the case? If I configure an interface that is not currently present today in running this is just find and running is not expected to change arbitrarily. > The mapping of what is called intended-config onto data stores would > deserve more detailed discussion. It seems the authors of this draft had > in mind to associate intended-cfg with the [running] datastore. With that > mapping, a failure in applying [running] to [applied] will update the > [running] datastore to reflect which part is effectively applied. So a > fair representation of that case would be: > [candidate] -> [running] <--> [applied] -> derived state What is 'this draft'? I thought the whole point of having an applied config is to be able to see the difference between intended (oops running) and applied. I am confused now. > In the context of intended configuration however that doesn¹t make sense > to me. A failure in applying intended configuration doesn¹t change the > intention and the delta between intended and applied-config is the key > value. A server that would "clean-up² intended-cfg in presence of a > failure to apply would look picture perfect instead of exposing the > problem clearly. Hence the sequence should more look like: > [candidate] -> [intended] ‹> [running==applied] -> derived state > > Whatever we choose, I believe we need to spell out what¹s the data in a > failure case. It¹s probably a bit late to update the requirements draft, > but we can probably find a suitable place. There is apparently much less agreement on what the problem is, what the terms mean, and how they related to existing technology than I thought. /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 Feb 8 08:40:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA01B2EDE for ; Mon, 8 Feb 2016 08:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 mbvCuzY6v4z0 for ; Mon, 8 Feb 2016 08:40:13 -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 D93D01B2EF5 for ; Mon, 8 Feb 2016 08:40:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 997101108; Mon, 8 Feb 2016 17:40:11 +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 HgukkQobaxcP; Mon, 8 Feb 2016 17:40:11 +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, 8 Feb 2016 17:40:11 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E50882002C; Mon, 8 Feb 2016 17:40:10 +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 7LtN05c8biDv; Mon, 8 Feb 2016 17:40:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 017B22002B; Mon, 8 Feb 2016 17:40:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC27B39E1085; Mon, 8 Feb 2016 17:40:10 +0100 (CET) Date: Mon, 8 Feb 2016 17:40:10 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160208164010.GD29638@elstar.local> Mail-Followup-To: Eliot Lear , Robert Wilton , Andy Bierman , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B8C1A5.9040508@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B8C1A5.9040508@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 16:40:14 -0000 On Mon, Feb 08, 2016 at 05:26:13PM +0100, Eliot Lear wrote: > Juergen, > > On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote: > > > None of the existing tools that assume YANG defined data is XML > > encoded according to RFC 6020 will not be able to process data in a > > new encoding. > > Reversing you're negatives you are asserting that all existing tools > that assume that YANG defined data is XML encoded will be able to > process data in a new encoding. Is that really what you meant to say? > If so, could you kindly explain what you mean by "tools"? > > Yours for less double negatives... > Sorry, a non native speaker screwing this up. s/None of/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 Mon Feb 8 08:59:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2681B2F68 for ; Mon, 8 Feb 2016 08:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 CCjgWBys4UWY for ; Mon, 8 Feb 2016 08:59:45 -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 C786A1B2F65 for ; Mon, 8 Feb 2016 08:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5805; q=dns/txt; s=iport; t=1454950784; x=1456160384; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=C0NPeaQljZFeHLDPPlZVj4/ivIUAgLGdsVjl1UoyVJ8=; b=M/P+SE1j9ANmYltDmDQZ1F+g2+ZWUpMIEATfw/fji3yPUPjK2Wf6pwYM B6u/WYohRQUfod0lauvhLvXU+WfszGkRrcOrwbjU5dUd6wyqfC+KDE0JM z5jXAu6Dq8w+NhDL2vMKeF5Oc+Yea6XWW8lxavj9pa0aI+XxgygRQou9w s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQAqybhW/xbLJq1ehAyJSLEMAQ2BZ?= =?us-ascii?q?iGFbAKBZxQBAQEBAQEBfwuEQQEBAQMBJxFAEQsYCRYPCQMCAQIBRQYNCAEBF4d?= =?us-ascii?q?4CA69HwEBAQEBAQEBAQEBAQEBAQEBARQEhhKEN4hsAQSWdYVMiASBW4dGhVKKb?= =?us-ascii?q?INSHgEBQoIDGYFIPIkBAQEB?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208";a="632428815" 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; 08 Feb 2016 16:59:41 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u18GxfDP019131 for ; Mon, 8 Feb 2016 16:59:41 GMT To: "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208163123.GB29638@elstar.local> From: Robert Wilton Message-ID: <56B8C97E.7050303@cisco.com> Date: Mon, 8 Feb 2016 16:59:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208163123.GB29638@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 16:59:47 -0000 On 08/02/2016 16:31, Juergen Schoenwaelder wrote: > On Mon, Feb 08, 2016 at 01:30:02PM +0000, Robert Wilton wrote: >> Hi, >> >> On 05/02/2016 17:34, Juergen Schoenwaelder wrote: >>> On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: >>>> 2. Personally, for a datastore solution, I would prefer if the new >>>> datastore was for the intended configuration, and that the applied >>>> configuration was stored in the same datastore (running?) as all the >>>> rest of the operational state. >>> The running datastore is a configuration datastore, it does not hold >>> operational state. >> OK. Thanks for the clarification. I hadn't realised that the >> definition of datastores only applies to configuration and not to state! >> >> So, am I right in saying that this draft is effectively reclassifying >> that definition somewhat - given that applied configuration is being >> defined as operational state (at least in the diagram in section 3. >> Conceptual model) and datastores don't store state data? > Not sure what 'that definition' refers to. This WG has had lenghty > discussions how we look at operational state has. Some of it is > briefly mentioned in RFC 6244 and there were quite a few presentations > at IETF meetings before 'the operators' started contributing ideas. I was referring to the definition of Configuration Datastore in RFC-6241. I had mistakenly thought that the running datastore contained both the running configuration and operational state. You corrected me that the running datastore only contains config, although it is still slightly unclear to me whether the operational state lives in a datastore or not. > >>>> If the logical flows of system information is as follows: >>>> [candidate] -> intended cfg -> applied cfg -> derived state >>>> >>>> Then it seems strange to bundle intended cfg & derived state together in >>>> one datastore, and to have applied-cfg separate (a bit like an unwanted >>>> step child). >>> This is not what is being proposed. We always had >>> >>> [candidate] -> [running] -> operational state >>> >>> (and I mark configuration data stores in []). Both [candidate] and >>> [running] have the same configuration data model. Now we are asked >>> to expose that [running] may not be applied synchronously and hence >>> >>> [candidate] -> [running] -> [applied] -> derived state >>> >>> seems to make sense. >>>> 5. Am I correct to presume that this draft doesn't provide any support >>>> to return intended config, applied config & derived state all in a >>>> single request? I appreciate that this isn't included as a formal >>>> requirement - but part of me wonders whether this might have been an >>>> oversight in the requirements. >>> Can be defines easily as another RPC. That said, I heard that some big >>> vendors even refuse to implement today's get operation that returns >>> the combination of [running] and operational state. >> OK, but the key question is what does that returned data look like: Are >> the intended and applied config nodes going to be co-located in the same >> structure or is the response going to be two separate trees and for it >> to be up to the client to merge them together? >> >>> >>>> 6. I can understand the decision of get-diff to reuse edit-config or >>>> YANG patch, but I'm not sure that this makes it particularly easy for >>>> clients to then process that data. I might be wrong, but I suspect that >>>> a solution that returns the values of the intended and applied config >>>> nodes in an easier to relate way may be preferable (perhaps something >>>> along the lines of the encoding proposed in >>>> draft-wilton-netmod-opstate-yang). >>> A diff is a way to make delta's efficient. >> Yes, but often diffs include both the old and the new values to make it >> easier to see what the change is (or certainly they do whenever I review >> code diffs). >> >> I don't think that the YANG patch/edit-config encoding is significantly >> more efficient that the encoding that I suggested, so I don't think that >> efficiency of encoding is a strong argument here. > So if in my 1 million XML elements one has not been applied, how do I > find out efficiently in your encoding? By using 'diff-cfg-only' option of the parameter, you would get 3 or 4 leaves per mismatching node: (intended value, applied value, status, and optionally error reason). Only nodes with differences would be returned. A more complete example is in https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2. NETCONF get-config request using with-config-state with diff-cfg-only option", about page 16. Yes, this data would be larger than the patch, but it also contains more information (i.e. reason why they differ, and error string). The client is also able to process this data straight away. With the patch, they may need to generate the before and after values to make it easier to process. > >> The strongest argument for edit-config and YANG patch is that it is >> reusing an existing solution rather than inventing a new way of doing >> this. But I still think that my observation that this doesn't make it >> particularly easy for clients is valid, and other ways of encoding the >> data could make it easier and more useful. > We are on a very slippery slope here - what may be easy for one client > may not be easy for another client. Difficult for taking good > engineering decisions. Yes, but a diff that provides the old and new values can be used more flexibly then a diff that only provides the new values. I.e. the client can always ignore the extra information if they don't need it. Rob > > /js > From nobody Mon Feb 8 09:50:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17621B3016 for ; Mon, 8 Feb 2016 09:50:04 -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 JRPMgOHfd5MT for ; Mon, 8 Feb 2016 09:50:02 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9A11B3017 for ; Mon, 8 Feb 2016 09:50:02 -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.403.16; Mon, 8 Feb 2016 17:50:00 +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.0403.017; Mon, 8 Feb 2016 17:50:00 +0000 From: Gert Grammel To: Juergen Schoenwaelder Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRXeLKOW+rjqCc7kiS321+Ltbrbp8dt6+AgAADfQCABJrigIAADGqAgAAkxgA= Date: Mon, 8 Feb 2016 17:50:00 +0000 Message-ID: References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> In-Reply-To: <20160208163821.GC29638@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.10] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:jXDi3+tzlLc3t6+MOP7OXocRf1EXHgQoLyFmIG6qNuP+RVqmBiNNt7/kBfg5liAHkQ8DkdXVqQlXIjQjCrdyhav/Cd+xxG3bi188nSN0faDZ1lc/LsnN9Ex4uIT3ZKOFQkpFbhm4BU6EysD5MJmRnw==; 24:mQkf7e5NhmDxsYmE4tIalbiwcuOGa+kvVqldYdqigfeK3KXMcZh3GOEYfAHPW8gIafY8GMiZtk4VzY8psE2CC+onhp7c8O5olFpkxop65C8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612; x-ms-office365-filtering-correlation-id: 33ae37aa-683b-4a60-a809-08d330b0445e 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)(3002001)(10201501046); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 084674B2CF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(15975445007)(87936001)(110136002)(5001960100002)(230783001)(77096005)(66066001)(86362001)(54356999)(50986999)(36756003)(5002640100001)(76176999)(4001350100001)(586003)(11100500001)(5004730100002)(92566002)(99286002)(106116001)(19580405001)(19580395003)(5008740100001)(10400500002)(83506001)(6116002)(93886004)(3660700001)(3280700002)(189998001)(102836003)(2950100001)(2900100001)(122556002)(40100003)(2906002)(1220700001)(4326007)(3846002)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <30BBBE920ED4904886B0FF4D69FF23C4@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 17:50:00.8022 (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: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 17:50:05 -0000 SGkgSnVlcmdlbiwNCg0KSSB0aGluayB0aGUgaW5kZW50YXRpb24gaW4gIG91ciBlbWFpbHMgcGxh eSBoYXZvYyB3aGljaCBpcyBjb25mdXNpbmcgbWUNCnRvby4gVGhlIGtleSBwb2ludCBJIGFtIG1h a2luZyBpczoNCg0KVGhlIG1hcHBpbmcgb2Ygd2hhdCBpcyBjYWxsZWQgaW50ZW5kZWQtY29uZmln IG9udG8gZGF0YSBzdG9yZXMgd291bGQNCmRlc2VydmUgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9u LiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBvZg0KZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0w Mi50eHQgaGFkIGluIG1pbmQgdG8gYXNzb2NpYXRlIGludGVuZGVkLWNmZw0Kd2l0aCB0aGUgW3J1 bm5pbmddIGRhdGFzdG9yZS4gSW4gbXkgdW5kZXJzdGFuZGluZywgYSBmYWlsdXJlIGluIGFwcGx5 aW5nDQpbcnVubmluZ10gdG8gW2FwcGxpZWRdIHdpbGwgdXBkYXRlIHRoZSBbcnVubmluZ10gZGF0 YXN0b3JlIHRvIHJlZmxlY3QNCndoaWNoIHBhcnQgaXMgZWZmZWN0aXZlbHkgYXBwbGllZC4gU28g YSBmYWlyIHJlcHJlc2VudGF0aW9uIG9mIHRoYXQgY2FzZQ0Kd291bGQgYmU6DQpbY2FuZGlkYXRl XSAtPiBbcnVubmluZ10gPC0tPiBbYXBwbGllZF0gLT4gZGVyaXZlZCBzdGF0ZQ0KDQpJbiB0aGUg Y29udGV4dCBvZiBpbnRlbmRlZC1jb25maWd1cmF0aW9uIGhvd2V2ZXIgdGhhdCBkb2VzbuKAmXQg bWFrZSBzZW5zZQ0KdG8gbWUuIEEgZmFpbHVyZSBpbiBhcHBseWluZyBpbnRlbmRlZCBjb25maWd1 cmF0aW9uIGRvZXNuwrl0IGNoYW5nZSB0aGUNCmludGVudGlvbiBhbmQgdGhlIGRlbHRhIGJldHdl ZW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQtY29uZmlnIGlzIHRoZSBrZXkNCnZhbHVlLiBBIHNlcnZl ciB0aGF0IHdvdWxkICJjbGVhbi11cCIgaW50ZW5kZWQtY2ZnIGluIHByZXNlbmNlIG9mIGENCmZh aWx1cmUgdG8gYXBwbHkgd291bGQgbG9vayBwaWN0dXJlIHBlcmZlY3QgaW5zdGVhZCBvZiBleHBv c2luZyB0aGUNCnByb2JsZW0gY2xlYXJseS4gSGVuY2UgdGhlIHNlcXVlbmNlIHNob3VsZCBtb3Jl IGxvb2sgbGlrZToNCltjYW5kaWRhdGVdIC0+IFtpbnRlbmRlZF0g4oC5LT4gW3J1bm5pbmc9PWFw cGxpZWRdIC0+IGRlcml2ZWQgc3RhdGUNCg0KV2hhdGV2ZXIgd2UgY2hvb3NlLCBJIGJlbGlldmUg d2UgbmVlZCB0byBzcGVsbCBvdXQgd2hhdMK5cyB0aGUgZGF0YSBpbiBhDQpmYWlsdXJlIGNhc2Uu IEl0wrlzIHByb2JhYmx5IGEgYml0IGxhdGUgdG8gdXBkYXRlIHRoZSByZXF1aXJlbWVudHMgZHJh ZnQsDQpidXQgd2UgY2FuIHByb2JhYmx5IGZpbmQgYSBzdWl0YWJsZSBwbGFjZS4NCg0K4oCU4oCU 4oCUDQoNCg0KSSBhbSBhbHNvIHdvbmRyaW5nIGlmIHdlIGhhdmUgdGhlIHNhbWUgdW5kZXJzdGFu ZGluZyByZWxhdGVkIHRvIHRoZQ0KZm9sbG93aW5nIHN0YXRlbWVudDoNCglJIHRob3VnaHQgdGhl IHdob2xlIHBvaW50IG9mIGhhdmluZyBhbiBhcHBsaWVkIGNvbmZpZyBpcyB0byBiZSBhYmxlIHRv DQpzZWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBpbnRlbmRlZCAob29wcyBydW5uaW5nKSBhbmQg YXBwbGllZC4NCg0KDQpUaGUgY3VycmVudCBkcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAy LnR4dCBzYXlzOg0KIkFueSByb2xsYmFjayB0aGF0IG1heSBvY2N1ciB3aWxsIHJlc3RvcmUgYm90 aCB0aGUgaW50ZW5kZWQgYW5kIHRoZQ0KYXBwbGllZCBjb25maWd1cmF0aW9ucyB0byB0aGVpciBw cmV2aW91cyBzdGF0ZXMuIg0KDQoNClRoZSBjaGFsbGVuZ2UgSSBoYXZlIGlzIHRoZSB0ZXJtIOKA nChvb3BzIHJ1bm5pbmcp4oCdIGluIHRoZSBmaXJzdCBzZW50ZW5jZSBpbg0KY29tYmluYXRpb24g d2l0aCB0aGUgY2l0YXRpb24uIEkgcmVja29uIHRoYXQgYW55IGRpZmZlcmVuY2UgYmV0d2Vlbg0K aW50ZW5kZWQtY29uZmlnIGFuZCBhcHBsaWVkLWNvbmZpZyBzaGFsbCBiZSB2aXNpYmxlIHdoZXJl YnkgdGhlDQppbnRlbmRlZC1jb25maWcgaXMgcHJvdmlkZWQgYnkgdGhlIGNsaWVudCBhbmQgbmV2 ZXIgYWx0ZXJlZCBieSB0aGUgc2VydmVyLg0KQXBwbGllZC1jb25maWcgb24gdGhlIG90aGVyIGhh bmQgcmVwcmVzZW50cyB0aGUgc3RhdGUgb2YgdGhlIHNlcnZlci4gSWYgYQ0KZmFpbHVyZSBoYXBw ZW5zIGluIHRoZSBhcHBsaWNhdGlvbiBwaGFzZSwgaXQgc2hhbGwgYmUgdHJlYXRlZCBhY2NvcmRp bmdseQ0KKHJvbGxiYWNrLSwgc3RvcC0sIGNvbnRpbnVlLW9uLWVycm9yKS4gQXMgYSByZXN1bHQg dGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0KaW50ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlv biBzaGFsbCBiZSBtYWludGFpbmVkLg0KU28gZG9lcyB0aGlzIHNxdWFyZSB3aXRoIHRoZSBub3Rp b24gImludGVuZGVkPXJ1bm5pbmciIGFuZCDigJxhcHBsaWVk4oCdDQpjb25maWc/DQoNCi0gR2Vy dA0KDQoNCg0KDQoNCk9uIDIwMTYtMDgtMDIgMTc6MzgsICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIi DQo8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIE1v biwgRmViIDA4LCAyMDE2IGF0IDAyOjUzOjU3UE0gKzAwMDAsIEdlcnQgR3JhbW1lbCB3cm90ZToN Cj4+IA0KPj4gDQo+PiA+VGhpcyBpcyBub3Qgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gV2UgYWx3 YXlzIGhhZA0KPj4gPg0KPj4gPltjYW5kaWRhdGVdIC0+IFtydW5uaW5nXSAtPiBvcGVyYXRpb25h bCBzdGF0ZQ0KPj4gPg0KPj4gPihhbmQgSSBtYXJrIGNvbmZpZ3VyYXRpb24gZGF0YSBzdG9yZXMg aW4gW10pLiBCb3RoIFtjYW5kaWRhdGVdIGFuZA0KPj4gPltydW5uaW5nXSBoYXZlIHRoZSBzYW1l IGNvbmZpZ3VyYXRpb24gZGF0YSBtb2RlbC4gTm93IHdlIGFyZSBhc2tlZA0KPj4gPnRvIGV4cG9z ZSB0aGF0IFtydW5uaW5nXSBtYXkgbm90IGJlIGFwcGxpZWQgc3luY2hyb25vdXNseSBhbmQgaGVu Y2UNCj4+ID4NCj4+ID5bY2FuZGlkYXRlXSAtPiBbcnVubmluZ10gLT4gW2FwcGxpZWRdIC0+IGRl cml2ZWQgc3RhdGUNCj4+ID4NCj4+ID5zZWVtcyB0byBtYWtlIHNlbnNlLg0KPg0KPldoeSB3b3Vs ZCB0aGF0IGJlIHRoZSBjYXNlPyBJZiBJIGNvbmZpZ3VyZSBhbiBpbnRlcmZhY2UgdGhhdCBpcyBu b3QNCj5jdXJyZW50bHkgcHJlc2VudCB0b2RheSBpbiBydW5uaW5nIHRoaXMgaXMganVzdCBmaW5k IGFuZCBydW5uaW5nIGlzDQo+bm90IGV4cGVjdGVkIHRvIGNoYW5nZSBhcmJpdHJhcmlseS4NCj4g DQo+PiBUaGUgbWFwcGluZyBvZiB3aGF0IGlzIGNhbGxlZCBpbnRlbmRlZC1jb25maWcgb250byBk YXRhIHN0b3JlcyB3b3VsZA0KPj4gZGVzZXJ2ZSBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24uIEl0 IHNlZW1zIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgaGFkDQo+PiBpbiBtaW5kIHRvIGFzc29j aWF0ZSBpbnRlbmRlZC1jZmcgd2l0aCB0aGUgW3J1bm5pbmddIGRhdGFzdG9yZS4gV2l0aA0KPj50 aGF0DQo+PiBtYXBwaW5nLCBhIGZhaWx1cmUgaW4gYXBwbHlpbmcgW3J1bm5pbmddIHRvIFthcHBs aWVkXSB3aWxsIHVwZGF0ZSB0aGUNCj4+IFtydW5uaW5nXSBkYXRhc3RvcmUgdG8gcmVmbGVjdCB3 aGljaCBwYXJ0IGlzIGVmZmVjdGl2ZWx5IGFwcGxpZWQuIFNvIGENCj4+IGZhaXIgcmVwcmVzZW50 YXRpb24gb2YgdGhhdCBjYXNlIHdvdWxkIGJlOg0KPj4gW2NhbmRpZGF0ZV0gLT4gW3J1bm5pbmdd IDwtLT4gW2FwcGxpZWRdIC0+IGRlcml2ZWQgc3RhdGUNCj4NCj5XaGF0IGlzICd0aGlzIGRyYWZ0 Jz8gSSB0aG91Z2h0IHRoZSB3aG9sZSBwb2ludCBvZiBoYXZpbmcgYW4gYXBwbGllZA0KPmNvbmZp ZyBpcyB0byBiZSBhYmxlIHRvIHNlZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGludGVuZGVkIChv b3BzDQo+cnVubmluZykgYW5kIGFwcGxpZWQuIEkgYW0gY29uZnVzZWQgbm93Lg0KPiANCj4+IElu IHRoZSBjb250ZXh0IG9mIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gaG93ZXZlciB0aGF0IGRvZXNu wrl0IG1ha2Ugc2Vuc2UNCj4+IHRvIG1lLiBBIGZhaWx1cmUgaW4gYXBwbHlpbmcgaW50ZW5kZWQg Y29uZmlndXJhdGlvbiBkb2VzbsK5dCBjaGFuZ2UgdGhlDQo+PiBpbnRlbnRpb24gYW5kIHRoZSBk ZWx0YSBiZXR3ZWVuIGludGVuZGVkIGFuZCBhcHBsaWVkLWNvbmZpZyBpcyB0aGUga2V5DQo+PiB2 YWx1ZS4gQSBzZXJ2ZXIgdGhhdCB3b3VsZCAiY2xlYW4tdXDCsiBpbnRlbmRlZC1jZmcgaW4gcHJl c2VuY2Ugb2YgYQ0KPj4gZmFpbHVyZSB0byBhcHBseSB3b3VsZCBsb29rIHBpY3R1cmUgcGVyZmVj dCBpbnN0ZWFkIG9mIGV4cG9zaW5nIHRoZQ0KPj4gcHJvYmxlbSBjbGVhcmx5LiBIZW5jZSB0aGUg c2VxdWVuY2Ugc2hvdWxkIG1vcmUgbG9vayBsaWtlOg0KPj4gW2NhbmRpZGF0ZV0gLT4gW2ludGVu ZGVkXSDigLk+IFtydW5uaW5nPT1hcHBsaWVkXSAtPiBkZXJpdmVkIHN0YXRlDQo+PiANCj4+IFdo YXRldmVyIHdlIGNob29zZSwgSSBiZWxpZXZlIHdlIG5lZWQgdG8gc3BlbGwgb3V0IHdoYXTCuXMg dGhlIGRhdGEgaW4gYQ0KPj4gZmFpbHVyZSBjYXNlLiBJdMK5cyBwcm9iYWJseSBhIGJpdCBsYXRl IHRvIHVwZGF0ZSB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0LA0KPj4gYnV0IHdlIGNhbiBwcm9iYWJs eSBmaW5kIGEgc3VpdGFibGUgcGxhY2UuDQo+DQo+VGhlcmUgaXMgYXBwYXJlbnRseSBtdWNoIGxl c3MgYWdyZWVtZW50IG9uIHdoYXQgdGhlIHByb2JsZW0gaXMsIHdoYXQNCj50aGUgdGVybXMgbWVh biwgYW5kIGhvdyB0aGV5IHJlbGF0ZWQgdG8gZXhpc3RpbmcgdGVjaG5vbG9neSB0aGFuIEkNCj50 aG91Z2h0Lg0KPg0KPi9qcw0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KDQo= From nobody Mon Feb 8 10:16:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79811B30AF for ; Mon, 8 Feb 2016 10:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 YDV8wu3pnKfz for ; Mon, 8 Feb 2016 10:16:52 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 161C81B30AE for ; Mon, 8 Feb 2016 10:16:52 -0800 (PST) Received: (qmail 30765 invoked by uid 0); 8 Feb 2016 18:16:51 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 8 Feb 2016 18:16:51 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id G0wj1s00j2SSUrH010wmzV; Mon, 08 Feb 2016 17:56:49 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=NJIBkNI62trBb7-46uIA:9 a=lxr9At24MQ9uTZPe:21 a=iU1wahtNWR8kHpWV:21 a=pILNOxqGKmIA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:Subject:From; bh=oViZEdHGuTmoRQZbRRi6Zz5taqt1MBGUNM3/Qp0p3Y8=; b=G4PUWZWpsk9LtHJDmuxCy34m4AtIbaMe9kIsAQdHDUU53VbW/oh3UMfAetI9jvekrLWv2R0FaIiuf9M2LXztHuiEsC6KhMo6y5cmX8SccTXQqwBScfGr8tdc6IFnEb9D; Received: from box313.bluehost.com ([69.89.31.113]:57547 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aSq3K-0003KJ-A7; Mon, 08 Feb 2016 10:56:46 -0700 From: Lou Berger To: Juergen Schoenwaelder References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> X-Enigmail-Draft-Status: N1110 Message-ID: <56B8D6D5.1000100@labn.net> Date: Mon, 8 Feb 2016 12:56:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160205174042.GB24243@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, netmod@ietf.org Subject: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 18:16:53 -0000 Hi Juergen, (All) I've change the subject line as I'm really commenting on all three documented options in this message. On February 5, 2016 12:41:17 PM Juergen Schoenwaelder wrote: > Lou, > > there are things I find fundamentally flawed and things I find > somewhat flawed. I do not understand why we need to mess around with > data encodings at all. I do not see what gets simpler by messing > around with the data encodings. Engineering decisions are usually > cost/benefit tradeoffs. I completely agree with this statement, as a general statement. the motivation in this case is that users are saying that the current solution is inadequate. I think it behooves us to listen and see if a better tool can be provided that addresses the limitations raised. > I see the costs, I am unsure about the > benefits. > I think this is a question of perspective. I get that from a protocol standpoint, and possibly even language standpoint, why this discussion can be considered unneeded complexity. I wouldn't even be surprised if the open config folks agreed with you, as the core of their solution really doesn't need changes to the underlying protocol or language. As I see it, there are three options on the table to address the core issue of OpState: 1. Do nothing in Netconf / restconf or yang, and leave it to model conventions = openconfig draft 2. Extend Netconf / restconf , but not yang or models = Kent's draft 3. Use a language / tools based approach to augment models and automatically produce a form of option 1 style convention changes, without model definition restrictions. ~= Rob's draft (I'll assume changes previously discussed on list) WRT 1: We've heard from the model development community, i.e. model writers, that 1 is doable but painful and easily done incorrectly. It also impacts other SDOs, i.e. non ietf model writers. WRT 2: We heard from the user community, at least a small number of representatives, that 2 alone doesn't address their needs. But it's also clear that some in the WG would prefer Option 2 (and most/all of these are its coauthors.) WRT 3: There's some discussion on how/if Option 3 might best meet the user requirements. I think focusing on this approach on the list could be helpful. One question I have for you, Juergen, and the other authors of 2 is if there are changes/improvements to 3 that you/the can see that would make acceptable? Note I am NOT asking which the authors prefer as this is clear. For the authors of 1, I think it would be worth hearing if a language/tools based approach to populating the Applied Configuration information is workable for them. Lou > /js > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: >> Juergen, >> >> How do you feel about the proposed modification on the table? (Leaving the >> model defined config leaves untouched and adding a -CFG or -metadata >> sibling node which would contain the additional automatically generated >> leaves.) >> >> Lou >> >> >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder >> wrote: >> >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: >> >>Hi Juergen, >> >> >> >>I don't really follow your point. >> >> >> >>The solution is fully backward compatible - in that only clients that >> >>make use of the protocol extension would see the new encoding. Existing >> >>clients would continue to see the encoding as directly defined in the >> >>YANG schema, and a server would be able to support old and new clients >> >>concurrently. >> >> >> > >> >The YANG RFC details how data is encoded in XML. People have written >> >and deployed code against based on this RFC. I do not accept an >> >approach where an RPC option can simply request that the encoding >> >defined in the YANG RFC is ignored and replaced with a very different >> >encoding. >> > >> >/js (stating a clear opinion as a technical contributor) >> > >> >-- >> >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 >> > >> >> > > -- > 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 Feb 8 10:54:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA501B3188; Mon, 8 Feb 2016 10:54:09 -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, RP_MATCHES_RCVD=-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 nS5fRg_j04fa; Mon, 8 Feb 2016 10:54: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 BC7311A6F30; Mon, 8 Feb 2016 10:54:07 -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 5C09F1AE0285; Mon, 8 Feb 2016 19:54:06 +0100 (CET) Date: Mon, 08 Feb 2016 19:57:57 +0100 (CET) Message-Id: <20160208.195757.1790485716725797319.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <56B8D6D5.1000100@labn.net> References: <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.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: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, netmod@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 08 Feb 2016 18:54:10 -0000 Hi, Lou Berger wrote: > Hi Juergen, (All) > > I've change the subject line as I'm really commenting on all three > documented options in this message. > > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder > wrote: > > > Lou, > > > > there are things I find fundamentally flawed and things I find > > somewhat flawed. I do not understand why we need to mess around with > > data encodings at all. I do not see what gets simpler by messing > > around with the data encodings. Engineering decisions are usually > > cost/benefit tradeoffs. > > I completely agree with this statement, as a general statement. I agree with Juergen - I read his statement to be about Robert's proposed solution. > the > motivation in this case is that users are saying that the current > solution is inadequate. Which solution is the current solution? > I think it behooves us to listen and see if a > better tool can be provided that addresses the limitations raised. > > > I see the costs, I am unsure about the > > benefits. > > > > I think this is a question of perspective. I get that from a protocol > standpoint, and possibly even language standpoint, why this discussion > can be considered unneeded complexity. I wouldn't even be surprised if > the open config folks agreed with you, as the core of their solution > really doesn't need changes to the underlying protocol or language. > > As I see it, there are three options on the table to address the core > issue of OpState: > > 1. Do nothing in Netconf / restconf or yang, and leave it to model > conventions = openconfig draft > > 2. Extend Netconf / restconf , but not yang or models = Kent's draft > > 3. Use a language / tools based approach to augment models and > automatically produce a form of option 1 style convention changes, > without model definition restrictions. ~= Rob's draft (I'll assume > changes previously discussed on list) > > WRT 1: We've heard from the model development community, i.e. model > writers, that 1 is doable but painful and easily done incorrectly. It > also impacts other SDOs, i.e. non ietf model writers. > > WRT 2: We heard from the user community, at least a small number of > representatives, that 2 alone doesn't address their needs. We have heard from the open config people that their proprietary protocol does not support datastores, but no more details. > But it's > also clear that some in the WG would prefer Option 2 (and most/all of > these are its coauthors.) This was the preferred solution of the room in Yokohama. 2 of the 4 authors were present. > WRT 3: There's some discussion on how/if Option 3 might best meet the > user requirements. I think focusing on this approach on the list could > be helpful. > > One question I have for you, Juergen, and the other authors of 2 is if > there are changes/improvements to 3 that you/the can see that would make > acceptable? Note I am NOT asking which the authors prefer as this is clear. I think this solution is pretty messy. Also, it is unclear to me how it affects things like filtering and access control for example. Can instance-identifiers all refer to these auto-generated nodes; are these nodes really part of the model or not? How is partial locking affected? There are lots of details to work out. /martin > For the authors of 1, I think it would be worth hearing if a > language/tools based approach to populating the Applied Configuration > information is workable for them. > > Lou > > > /js > > > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > >> Juergen, > >> > >> How do you feel about the proposed modification on the table? (Leaving the > >> model defined config leaves untouched and adding a -CFG or -metadata > >> sibling node which would contain the additional automatically generated > >> leaves.) > >> > >> Lou > >> > >> > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > >> wrote: > >> > >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > >> >>Hi Juergen, > >> >> > >> >>I don't really follow your point. > >> >> > >> >>The solution is fully backward compatible - in that only clients that > >> >>make use of the protocol extension would see the new encoding. Existing > >> >>clients would continue to see the encoding as directly defined in the > >> >>YANG schema, and a server would be able to support old and new clients > >> >>concurrently. > >> >> > >> > > >> >The YANG RFC details how data is encoded in XML. People have written > >> >and deployed code against based on this RFC. I do not accept an > >> >approach where an RPC option can simply request that the encoding > >> >defined in the YANG RFC is ignored and replaced with a very different > >> >encoding. > >> > > >> >/js (stating a clear opinion as a technical contributor) > >> > > >> >-- > >> >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 > >> > > >> > >> > > > > -- > > 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 Feb 8 11:17:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4049C1B31ED for ; Mon, 8 Feb 2016 11:17:22 -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 ZU7B-uQv7yfW for ; Mon, 8 Feb 2016 11:17:19 -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 290481B31EC for ; Mon, 8 Feb 2016 11:17:19 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id x4so89812388lbm.0 for ; Mon, 08 Feb 2016 11:17: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=WXRDdLubi3SIkw6YVR7CPFP6RJ2lKGUp4MlOKrZ5O/A=; b=Q9rQ4UiOetHRUCuJ3W8URYwdPtzE+OSGXeizsPlklfoV32hMpT/rcW66aLuVEQwzHu 5Zwt0EKUBrsxMK7vGMqHTKtD33Y1vc5ExUVRhgcUwsy9IoQCoe/tiD1NYPbcyV6GEMB/ jEEWvNyjDdJx5CLzW/CebHwXoNAQooKspePZTdxvC/0Xo7U7hNb8kIPiIlH+vj2DiA4X EvIwXe9h4GY25I+yEjUXPiHB4Qlb9tLBnaeEFokrNSPO0dtt/DRZWsESgW9zwMKTVpX7 g8PWuKUYD+8LKmQm7kHoeiia3zqajxsnJp3ww+LQoh34PTfMaZ4Urx/PePU4/ybS7FXR PEFg== 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=WXRDdLubi3SIkw6YVR7CPFP6RJ2lKGUp4MlOKrZ5O/A=; b=QIVKpka8oEQ7f0DmG+48AYSXu229Kin0g0CUJfZWEjO2wNJ9ldrwnhF9nb7Ch6B0/x m6n+XRWXK3aYYRMIm+aBD/3l5EiXFR70PNnaEgqBRWox+lAArNoEHny+5yggOxThfSOx 1VXXrGLxmLu6/HrOFEjnEsWk9wEklP0Hu68IEaFLCHsfFGvGrNmlY2VbTLE/a25n2Sja uGtRYaVAIP7fXgqJhVcd4HBzGgZjjZiPSRUzCs2d8I6jQcvRmpw946RjM87boPiPReGu MUKYHHxmefiP+85G7ZCB0Gh8C3NRVpkE8iNxfkfv8IDeHZHQb8yJGRBh45F4LpOm0TfW 2eTQ== X-Gm-Message-State: AG10YORt5Qn5B8q19D0Wza4RH1ifiUH7YcIZldjAVhqQhexbzNLFUnSGA6GGAI6MRvaeA5n//rVNIfuBp9udtg== MIME-Version: 1.0 X-Received: by 10.112.147.1 with SMTP id tg1mr10052568lbb.119.1454959037387; Mon, 08 Feb 2016 11:17:17 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 8 Feb 2016 11:17:17 -0800 (PST) In-Reply-To: <56B8D6D5.1000100@labn.net> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.net> Date: Mon, 8 Feb 2016 11:17:17 -0800 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=047d7b3a7f5c9636b7052b470c96 Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 19:17:22 -0000 --047d7b3a7f5c9636b7052b470c96 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger wrote: > Hi Juergen, (All) > > I've change the subject line as I'm really commenting on all three > documented options in this message. > > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder > wrote: > > > Lou, > > > > there are things I find fundamentally flawed and things I find > > somewhat flawed. I do not understand why we need to mess around with > > data encodings at all. I do not see what gets simpler by messing > > around with the data encodings. Engineering decisions are usually > > cost/benefit tradeoffs. > > I completely agree with this statement, as a general statement. the > motivation in this case is that users are saying that the current > solution is inadequate. I think it behooves us to listen and see if a > better tool can be provided that addresses the limitations raised. > > > I see the costs, I am unsure about the > > benefits. > > > > I think this is a question of perspective. I get that from a protocol > standpoint, and possibly even language standpoint, why this discussion > can be considered unneeded complexity. I wouldn't even be surprised if > the open config folks agreed with you, as the core of their solution > really doesn't need changes to the underlying protocol or language. > > As I see it, there are three options on the table to address the core > issue of OpState: > > 1. Do nothing in Netconf / restconf or yang, and leave it to model > conventions = openconfig draft > > 2. Extend Netconf / restconf , but not yang or models = Kent's draft > > 3. Use a language / tools based approach to augment models and > automatically produce a form of option 1 style convention changes, > without model definition restrictions. ~= Rob's draft (I'll assume > changes previously discussed on list) > > WRT 1: We've heard from the model development community, i.e. model > writers, that 1 is doable but painful and easily done incorrectly. It > also impacts other SDOs, i.e. non ietf model writers. > > This solution assumes that the overhead of retrieving data (while the server is applying config) does not impact performance. IMO retrieving 2 separate data trees and comparing them on the client uses a lot of bandwidth and it makes the server even more busy, so applying the config will take even longer. The only solution possible by replicating the YANG objects would be to retrieve both trees and compare them on the client. I prefer a solution that does not involve any polling by the client, such as a notification based solution. Since operations are data-driven in YANG, implementing a new RPC is the same cost as implementing new YANG data nodes. Andy > WRT 2: We heard from the user community, at least a small number of > representatives, that 2 alone doesn't address their needs. But it's > also clear that some in the WG would prefer Option 2 (and most/all of > these are its coauthors.) > > WRT 3: There's some discussion on how/if Option 3 might best meet the > user requirements. I think focusing on this approach on the list could > be helpful. > > One question I have for you, Juergen, and the other authors of 2 is if > there are changes/improvements to 3 that you/the can see that would make > acceptable? Note I am NOT asking which the authors prefer as this is clear. > > For the authors of 1, I think it would be worth hearing if a > language/tools based approach to populating the Applied Configuration > information is workable for them. > > Lou > > > /js > > > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > >> Juergen, > >> > >> How do you feel about the proposed modification on the table? (Leaving > the > >> model defined config leaves untouched and adding a -CFG or -metadata > >> sibling node which would contain the additional automatically generated > >> leaves.) > >> > >> Lou > >> > >> > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > >> wrote: > >> > >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > >> >>Hi Juergen, > >> >> > >> >>I don't really follow your point. > >> >> > >> >>The solution is fully backward compatible - in that only clients that > >> >>make use of the protocol extension would see the new encoding. > Existing > >> >>clients would continue to see the encoding as directly defined in the > >> >>YANG schema, and a server would be able to support old and new clients > >> >>concurrently. > >> >> > >> > > >> >The YANG RFC details how data is encoded in XML. People have written > >> >and deployed code against based on this RFC. I do not accept an > >> >approach where an RPC option can simply request that the encoding > >> >defined in the YANG RFC is ignored and replaced with a very different > >> >encoding. > >> > > >> >/js (stating a clear opinion as a technical contributor) > >> > > >> >-- > >> >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 > >> > > >> > >> > > > > -- > > 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 > --047d7b3a7f5c9636b7052b470c96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger <lberger@labn.net> wrote:
Hi Juergen, (All)

I've change the subject line as I'm really commenting on all three<= br> documented options in this message.

On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
<j.schoenwaelder= @jacobs-university.de> wrote:

> Lou,
>
> there are things I find fundamentally flawed and things I find
> somewhat flawed. I do not understand why we need to mess around with > data encodings at all. I do not see what gets simpler by messing
> around with the data encodings. Engineering decisions are usually
> cost/benefit tradeoffs.

I completely agree with this statement, as a general statement. the
motivation in this case is that users are saying that the current
solution is inadequate. I think it behooves us to listen and see if a
better tool can be provided that addresses the limitations raised.

> I see the costs, I am unsure about the
> benefits.
>

I think this is a question of perspective. I get that from a protocol
standpoint, and possibly even language standpoint, why this=C2=A0 discussio= n
can=C2=A0 be considered unneeded complexity. I wouldn't even be surpris= ed if
the open config folks agreed with you, as the core of=C2=A0 their solution<= br> really doesn't need changes to the underlying protocol or language.

As I see it, there are three options on the table to address the core
issue of OpState:

1. Do nothing in Netconf / restconf or yang, and leave it to=C2=A0 model conventions =3D openconfig draft

2. Extend Netconf / restconf , but not yang or models =3D Kent's draft<= br>
3. Use a language / tools based approach to augment models and
automatically produce a form of option 1=C2=A0 style convention changes, without model definition restrictions. ~=3D Rob's draft (I'll assum= e
changes previously discussed on list)

WRT 1: We've heard from the model development community, i.e. model
writers, that 1 is doable but painful and easily done incorrectly. It
also impacts other SDOs, i.e. non ietf model writers.



This solution assumes t= hat the overhead of retrieving data (while the server
is applying= config) does not impact performance.=C2=A0 IMO retrieving 2 separate
=
data trees and comparing them on the client uses a lot of bandwidth an= d
it makes the server even more busy, so applying the config will= take
even longer.

The only solution pos= sible by replicating the YANG objects would be to
retrieve both t= rees and compare them on the client.

I prefer a so= lution that does not involve any polling by the client,
such as a= notification based solution.

Since operations are= data-driven in YANG, implementing a new RPC
is the same cost as = implementing new YANG data nodes.


A= ndy
=C2=A0
WRT 2: We heard from the user community, at least a small number of
representatives, that 2 alone doesn't address their needs.=C2=A0 But it= 's
also clear that some in the WG would prefer Option 2 (and most/all of
these are its coauthors.)

WRT 3: There's some discussion on how/if Option 3 might best meet the user requirements.=C2=A0 I think focusing on this approach on the list coul= d
be helpful.

One question I have for you, Juergen, and the other authors of 2 is if
there are changes/improvements to 3 that you/the can see that would make acceptable? Note I am NOT asking which the authors prefer as this is clear.=

For the authors of 1, I think it would be worth hearing if a
language/tools based approach to populating the Applied Configuration
information is workable for them.

Lou

> /js
>
> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
>> Juergen,
>>
>> How do you feel about the proposed modification on the table? (Lea= ving the
>> model defined config leaves untouched and adding a -CFG or -metada= ta
>> sibling node which would contain the additional automatically gene= rated
>> leaves.)
>>
>> Lou
>>
>>
>> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
>> <j.scho= enwaelder@jacobs-university.de> wrote:
>>
>> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote:=
>> >>Hi Juergen,
>> >>
>> >>I don't really follow your point.
>> >>
>> >>The solution is fully backward compatible - in that only c= lients that
>> >>make use of the protocol extension would see the new encod= ing. Existing
>> >>clients would continue to see the encoding as directly def= ined in the
>> >>YANG schema, and a server would be able to support old and= new clients
>> >>concurrently.
>> >>
>> >
>> >The YANG RFC details how data is encoded in XML. People have w= ritten
>> >and deployed code against based on this RFC. I do not accept a= n
>> >approach where an RPC option can simply request that the encod= ing
>> >defined in the YANG RFC is ignored and replaced with a very di= fferent
>> >encoding.
>> >
>> >/js (stating a clear opinion as a technical contributor)
>> >
>> >--
>> >Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Jacobs University Bremen gGmbH
>> >Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campu= s Ring 1 | 28759 Bremen | Germany
>> >Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
>> >
>> >_______________________________________________
>> >netmod mailing list
>> >netmod@ietf.org
>> >https://www.ietf.org/mailman/listinfo/net= mod
>> >
>>
>>
>
> --
> 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

--047d7b3a7f5c9636b7052b470c96-- From nobody Mon Feb 8 11:37:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12301B30DD for ; Mon, 8 Feb 2016 11:37: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, RP_MATCHES_RCVD=-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 Hw0NA4Gh7_dW for ; Mon, 8 Feb 2016 11:37: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 8405E1B2DAF for ; Mon, 8 Feb 2016 11:37:38 -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 1CB691AE0285; Mon, 8 Feb 2016 20:37:37 +0100 (CET) Date: Mon, 08 Feb 2016 20:41:28 +0100 (CET) Message-Id: <20160208.204128.275969700916546426.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56B8B2BC.9050809@cisco.com> References: <56B89670.9090300@cisco.com> <20160208.144553.2082644981061361024.mbj@tail-f.com> <56B8B2BC.9050809@cisco.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] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 19:37:40 -0000 Hi, Robert Wilton wrote: > Hi Martin, > > On 08/02/2016 13:45, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 06/02/2016 00:41, Andy Bierman wrote: > > [...] > > > >>> IMO, this solution is a non-starter. > >> OK, and yet my understanding is that the folks requesting a solution > >> to the opstate problem are saying that the applied datastore approach > >> is also a non-starter, or at least very undesirable. > > But the key to finding a solution that works for everyone is to > > understand *why* a datastore is a non-starter. As I noted in a > [Caveat - I don't speak for the OpenConfig operators, this is just > my perception from previous drafts, conversations, implementing some > of the OpenConfig models] > > My understanding is that they want something this is very similar to > how the OpenConfig models look. After all, their preferred solution > to the opstate problem would be for IETF to standardize on the > approach used in OpenConfig model design. E.g. all config nodes are > defined in groupings, and then instantiated under both "config" and > "state" containers. > > I believe that their concerns are primarily about how the operators > systems interact with the models from a management client > perspective rather than device implementation concerns. > > With the OpenConfig model/approach they get: > - The choice of having one single tree that contains all the data > (intended, applied and derived) - but can be split into multiple > trees if they wish. (I.e. with their model they have no > requirement to be aware of separate data stores at all.) > - Every piece of data in that tree has a unique path to identify it > (makes the data easy to interact with). > - The intended config, applied config, and derived state can all be > programmatically compared. > - Related information is co-located in the tree (e.g. if you were > browsing the data tree). Here's a slightly updated version of a drawing that has been used to explain how configuration data flows through the system: [candidate] -> [running/intended] -> [applied] | v [startup] We used to have three instantiations of configuration nodes, now we have four (applied). Three of these are datastores. They can be programmatically compared (even without data model knowledge). Note that a "datastore" can be viewed as a label (with associated semantics) of an instantiation of these nodes. It is unclear to me why applied must be special (modelled explicitly rather than a named instantiation of the nodes). Your list above applies only to the intended,applied subset of the instantiations. If you want to e.g. check how startup differs from running you need a different mechanism than to check how applied differs from running, which means different code paths etc. > With a datastore solution, I think that it means: > - Either they have to put intended and applied config into separate > trees, or they have to come up with their own scheme to combine > them into a single tree (given that the cfg intended/applied names > clash). Do you mean in their proprietary protocol? > - If separate trees, to ensure paths are unique they would need to > prefix every path with the name of the datastore/tree (hassle). I don't see why it would be such a hassle; compare: /intended/interfaces/interface[name='eth0']/mtu vs. /interfaces/interface[name='eth0']/config/mtu > - Comparing the intended and applied trees is a bit more hassle > (they would need to perform a pairwise walk across both intended > and applied configuration trees). > - When data is being returned from the server (if it is even > allowed for two datastores to be returned in the same request) then > data would not be co-located. I.e. you have to read in all the > data for both intended and applied config datastores before you can > start processing any of it. Whereas if the data is returned in a > single tree then co-located data would be returned together and the > the stream of data can be filtered/processed without building up an > intermediate combined tree of all the data. > > > previous email, both your solution and the datastore solution rely on > > the assumption that the server internally knows the difference between > > the "intended" and "applied" value for the config true nodes. > Please can you clarify - I don't really follow this point. In the open config solution there is just one schema and the server just calls the instrumentation to fill in the values. The server doesn't know if a node is "applied" or "derived". In our solutions, the server knows from the request what data is requested, and calls the corresponding instrumentation. /martin > For all solutions, it only makes sense if the server internally > knows the difference between intended and applied values, so I > assume that is just a given. > > > > > >> (Note - I don't > >> actually know whether they regard the solution in > >> draft-wilton-netmod-opstate-yang to be any more palatable.) > > Right; so if their objection is that the server cannot know the > > difference between "intended" and "applied" for the config true leafs, > > neither of our solutions work. > > > > And if their objection is that their proprietary protocol does > > can/does not encode the datastore in the "get" request, then > > I suspect that their protocol also does not know your proposed > > encoding. > > > >> From a clients operational perspective I can see how the OpenConfig > >> model, with separate intended config and applied config leaves that > >> are co-located in the schema tree makes life easy for the client in a > >> way that having a separate applied configuration datastore doesn't > >> seem to. > > I can see how the applied datastore model makes life easier for the > > client, e.g., a diff can be done w/o any data model knowledge at all. > Possibly. But that requires that they have to manage having a > separate datastore for applied config in the first place, and I'm > not convinced that doing a pairwise diff across two datastores is > any easier than the equivalent "diff" algorithm that they would > write for checking the config state in the OpenConfig models. > > Rob > > > > > > > > /martin > > > > > >> Rob > >> > >> > >>> > >>> /js (stating a clear opinion as a technical contributor) > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 > >>> > >>> > >>> > >>> Andy > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> > > . > > > From nobody Mon Feb 8 11:39:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E31A1A55 for ; Mon, 8 Feb 2016 11:39:27 -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, RP_MATCHES_RCVD=-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 GZhqCaGMeHm6 for ; Mon, 8 Feb 2016 11:39: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 1BC5F1A1A5A for ; Mon, 8 Feb 2016 11:39:26 -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 5AADF1AE0285; Mon, 8 Feb 2016 20:39:25 +0100 (CET) Date: Mon, 08 Feb 2016 20:43:16 +0100 (CET) Message-Id: <20160208.204316.2053152219367865972.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56B8B790.4040908@cisco.com> References: <56B8985A.9060501@cisco.com> <20160208.153819.237705833994731271.mbj@tail-f.com> <56B8B790.4040908@cisco.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] I-D Action: draft-kwatsen-netmod-opstate-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, 08 Feb 2016 19:39:27 -0000 Robert Wilton wrote: > Hi Martin, > > On 08/02/2016 14:38, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> Hi, > >> > >> On 05/02/2016 17:34, Juergen Schoenwaelder wrote: > >>> On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: > >>>> 2. Personally, for a datastore solution, I would prefer if the new > >>>> datastore was for the intended configuration, and that the applied > >>>> configuration was stored in the same datastore (running?) as all the > >>>> rest of the operational state. > >>> The running datastore is a configuration datastore, it does not hold > >>> operational state. > >> OK. Thanks for the clarification. I hadn't realised that the > >> definition of datastores only applies to configuration and not to > >> state! > > No, this is not correct. RFC 6241 defines both "datastore" and > > "configuration datastore". However, "running" is a "configuration > > datastore". > OK. RFC 6241 defines terminology for "datastore", but the body of the > text only ever seems to ever use the term datastore in the context of > a "configuration datastore". > > Hence please can you clarify, does the operational state live in a non > configuration datastore, and if so which one? Yes, but unfortunately it doesn't have a name, and the only way to get it with current NETCONF is to do a , which also returns the running configuration. > Otherwise, are there > any other uses of non-configuration datastores by NETCONF? No, not currently. /martin From nobody Mon Feb 8 12:17:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195F91B32AA for ; Mon, 8 Feb 2016 12:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 0NFjLXhJaP42 for ; Mon, 8 Feb 2016 12:17:52 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 6D7981B2DB8 for ; Mon, 8 Feb 2016 12:17:52 -0800 (PST) Received: (qmail 16562 invoked by uid 0); 8 Feb 2016 20:17:47 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 8 Feb 2016 20:17:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Fvxh1s00C2SSUrH01vxk8b; Mon, 08 Feb 2016 12:57:46 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=wU2YTnxGAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=FFXRgxiLFgvaeEYehVMA:9 a=lwcZOvIhGt_2jiZ3:21 a=AR_EUPf3crfKM0Qb:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ub89nRzpW5fRr+Dx+W/JSJcNmcNlYDIh2pZIpc3KHBI=; b=IhctxTRs3NF6AcJy548dlCIHhVE0vnKjA09yl3mjAYuXAnBugpezhFHoRDSearQSr3uql0LTFqaHuAh6r+tSYOtYSHoQwTNRAeo6FBxD7pBbCiQ2aZ2grO5E9wlTrkw7; Received: from box313.bluehost.com ([69.89.31.113]:35058 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aSrwM-0004ZU-52; Mon, 08 Feb 2016 12:57:42 -0700 To: Andy Bierman References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.net> From: Lou Berger Message-ID: <56B8F32F.30600@labn.net> Date: Mon, 8 Feb 2016 14:57:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 20:17:54 -0000 Hi Andy, Thanks for the very good comments. Which solutions(s) were you commenting on -- you say "this" so is ambiguous. Lou On 2/8/2016 2:17 PM, Andy Bierman wrote: > > > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger > wrote: > > Hi Juergen, (All) > > I've change the subject line as I'm really commenting on all three > documented options in this message. > > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder > > wrote: > > > Lou, > > > > there are things I find fundamentally flawed and things I find > > somewhat flawed. I do not understand why we need to mess around with > > data encodings at all. I do not see what gets simpler by messing > > around with the data encodings. Engineering decisions are usually > > cost/benefit tradeoffs. > > I completely agree with this statement, as a general statement. the > motivation in this case is that users are saying that the current > solution is inadequate. I think it behooves us to listen and see if a > better tool can be provided that addresses the limitations raised. > > > I see the costs, I am unsure about the > > benefits. > > > > I think this is a question of perspective. I get that from a protocol > standpoint, and possibly even language standpoint, why this > discussion > can be considered unneeded complexity. I wouldn't even be > surprised if > the open config folks agreed with you, as the core of their solution > really doesn't need changes to the underlying protocol or language. > > As I see it, there are three options on the table to address the core > issue of OpState: > > 1. Do nothing in Netconf / restconf or yang, and leave it to model > conventions = openconfig draft > > 2. Extend Netconf / restconf , but not yang or models = Kent's draft > > 3. Use a language / tools based approach to augment models and > automatically produce a form of option 1 style convention changes, > without model definition restrictions. ~= Rob's draft (I'll assume > changes previously discussed on list) > > WRT 1: We've heard from the model development community, i.e. model > writers, that 1 is doable but painful and easily done incorrectly. It > also impacts other SDOs, i.e. non ietf model writers. > > > > This solution assumes that the overhead of retrieving data (while the > server > is applying config) does not impact performance. IMO retrieving 2 > separate > data trees and comparing them on the client uses a lot of bandwidth and > it makes the server even more busy, so applying the config will take > even longer. > > The only solution possible by replicating the YANG objects would be to > retrieve both trees and compare them on the client. > > I prefer a solution that does not involve any polling by the client, > such as a notification based solution. > > Since operations are data-driven in YANG, implementing a new RPC > is the same cost as implementing new YANG data nodes. > > > Andy > > > WRT 2: We heard from the user community, at least a small number of > representatives, that 2 alone doesn't address their needs. But it's > also clear that some in the WG would prefer Option 2 (and most/all of > these are its coauthors.) > > WRT 3: There's some discussion on how/if Option 3 might best meet the > user requirements. I think focusing on this approach on the list > could > be helpful. > > One question I have for you, Juergen, and the other authors of 2 is if > there are changes/improvements to 3 that you/the can see that > would make > acceptable? Note I am NOT asking which the authors prefer as this > is clear. > > For the authors of 1, I think it would be worth hearing if a > language/tools based approach to populating the Applied Configuration > information is workable for them. > > Lou > > > /js > > > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > >> Juergen, > >> > >> How do you feel about the proposed modification on the table? > (Leaving the > >> model defined config leaves untouched and adding a -CFG or > -metadata > >> sibling node which would contain the additional automatically > generated > >> leaves.) > >> > >> Lou > >> > >> > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > >> > wrote: > >> > >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > >> >>Hi Juergen, > >> >> > >> >>I don't really follow your point. > >> >> > >> >>The solution is fully backward compatible - in that only > clients that > >> >>make use of the protocol extension would see the new > encoding. Existing > >> >>clients would continue to see the encoding as directly > defined in the > >> >>YANG schema, and a server would be able to support old and > new clients > >> >>concurrently. > >> >> > >> > > >> >The YANG RFC details how data is encoded in XML. People have > written > >> >and deployed code against based on this RFC. I do not accept an > >> >approach where an RPC option can simply request that the encoding > >> >defined in the YANG RFC is ignored and replaced with a very > different > >> >encoding. > >> > > >> >/js (stating a clear opinion as a technical contributor) > >> > > >> >-- > >> >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 > >> > > >> > >> > > > > -- > > 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 Feb 8 12:20:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9D1B32AA for ; Mon, 8 Feb 2016 12:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 iIh-mCl5WpCi for ; Mon, 8 Feb 2016 12:20:37 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 336481B3290 for ; Mon, 8 Feb 2016 12:20:37 -0800 (PST) Received: (qmail 11436 invoked by uid 0); 8 Feb 2016 20:13:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 8 Feb 2016 20:13:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Fvto1s00l2SSUrH01vtr0v; Mon, 08 Feb 2016 12:53:56 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=wU2YTnxGAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=wG46oQjdWwtm4riYUtQA:9 a=XmprcElZ39go2OcC:21 a=agv-kGpbuISvrxj5:21 a=pILNOxqGKmIA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=9/KOHx26P+QzUrkdW940WvW6HyRcKydGQqgfNbLRaTE=; b=xvgkAFAX4FcMCFUHqeE/7tPL8gbwZeAZhhrwpWPdDaUNhON0umQhOJmViMfgQ74Err2BC1Psp1As2tFZDDiMnjhwhTfyUv6S//g9Ua+xoWV/1s5RWFmpy6ikh1Du/qJP; Received: from box313.bluehost.com ([69.89.31.113]:34267 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aSrsb-0003j5-Na; Mon, 08 Feb 2016 12:53:50 -0700 To: Martin Bjorklund References: <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> From: Lou Berger Message-ID: <56B8F244.7090802@labn.net> Date: Mon, 8 Feb 2016 14:53:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160208.195757.1790485716725797319.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, netmod@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 08 Feb 2016 20:20:39 -0000 Martin, Thanks for the response. See below. On 2/8/2016 1:57 PM, Martin Bjorklund wrote: > Hi, > > Lou Berger wrote: >> Hi Juergen, (All) >> >> I've change the subject line as I'm really commenting on all three >> documented options in this message. >> >> On February 5, 2016 12:41:17 PM Juergen Schoenwaelder >> wrote: >> >>> Lou, >>> >>> there are things I find fundamentally flawed and things I find >>> somewhat flawed. I do not understand why we need to mess around with >>> data encodings at all. I do not see what gets simpler by messing >>> around with the data encodings. Engineering decisions are usually >>> cost/benefit tradeoffs. >> I completely agree with this statement, as a general statement. > I agree with Juergen - I read his statement to be about Robert's > proposed solution. > >> the >> motivation in this case is that users are saying that the current >> solution is inadequate. > Which solution is the current solution? anything in an rfc or soon to be an rfc. IMO. > >> I think it behooves us to listen and see if a >> better tool can be provided that addresses the limitations raised. >> >>> I see the costs, I am unsure about the >>> benefits. >>> >> I think this is a question of perspective. I get that from a protocol >> standpoint, and possibly even language standpoint, why this discussion >> can be considered unneeded complexity. I wouldn't even be surprised if >> the open config folks agreed with you, as the core of their solution >> really doesn't need changes to the underlying protocol or language. >> >> As I see it, there are three options on the table to address the core >> issue of OpState: >> >> 1. Do nothing in Netconf / restconf or yang, and leave it to model >> conventions = openconfig draft >> >> 2. Extend Netconf / restconf , but not yang or models = Kent's draft >> >> 3. Use a language / tools based approach to augment models and >> automatically produce a form of option 1 style convention changes, >> without model definition restrictions. ~= Rob's draft (I'll assume >> changes previously discussed on list) >> >> WRT 1: We've heard from the model development community, i.e. model >> writers, that 1 is doable but painful and easily done incorrectly. It >> also impacts other SDOs, i.e. non ietf model writers. >> >> WRT 2: We heard from the user community, at least a small number of >> representatives, that 2 alone doesn't address their needs. > We have heard from the open config people that their proprietary > protocol does not support datastores, but no more details. I think I've heard users say what they believe is true from their perspective and context. I've heard others say we disagree (or stronger statements.) >> But it's >> also clear that some in the WG would prefer Option 2 (and most/all of >> these are its coauthors.) > This was the preferred solution of the room in Yokohama. 2 of the 4 > authors were present. sure. And we know that the IETF consensus is not judged by who is in the room. It is of course useful information to the WG and the chairs. >> WRT 3: There's some discussion on how/if Option 3 might best meet the >> user requirements. I think focusing on this approach on the list could >> be helpful. >> >> One question I have for you, Juergen, and the other authors of 2 is if >> there are changes/improvements to 3 that you/the can see that would make >> acceptable? Note I am NOT asking which the authors prefer as this is clear. > I think this solution is pretty messy. Also, it is unclear to me how > it affects things like filtering and access control for example. Can > instance-identifiers all refer to these auto-generated nodes; are > these nodes really part of the model or not? How is partial locking > affected? There are lots of details to work out. This is useful comments and would like to see what the options are/should be WRT Option 3. Do you have any opinions on this? Thanks, Lou > > > /martin > > > >> For the authors of 1, I think it would be worth hearing if a >> language/tools based approach to populating the Applied Configuration >> information is workable for them. >> >> Lou >> >>> /js >>> >>> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: >>>> Juergen, >>>> >>>> How do you feel about the proposed modification on the table? (Leaving the >>>> model defined config leaves untouched and adding a -CFG or -metadata >>>> sibling node which would contain the additional automatically generated >>>> leaves.) >>>> >>>> Lou >>>> >>>> >>>> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder >>>> wrote: >>>> >>>>> On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: >>>>>> Hi Juergen, >>>>>> >>>>>> I don't really follow your point. >>>>>> >>>>>> The solution is fully backward compatible - in that only clients that >>>>>> make use of the protocol extension would see the new encoding. Existing >>>>>> clients would continue to see the encoding as directly defined in the >>>>>> YANG schema, and a server would be able to support old and new clients >>>>>> concurrently. >>>>>> >>>>> The YANG RFC details how data is encoded in XML. People have written >>>>> and deployed code against based on this RFC. I do not accept an >>>>> approach where an RPC option can simply request that the encoding >>>>> defined in the YANG RFC is ignored and replaced with a very different >>>>> encoding. >>>>> >>>>> /js (stating a clear opinion as a technical contributor) >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>> -- >>> 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 Feb 8 12:30:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954781B32E0 for ; Mon, 8 Feb 2016 12:30:06 -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 6Offpysj5m0h for ; Mon, 8 Feb 2016 12:30:03 -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 1F9351B32D2 for ; Mon, 8 Feb 2016 12:30:00 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id cw1so89534253lbb.1 for ; Mon, 08 Feb 2016 12:30:00 -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=9jaEhdT+s4mzgQqOnAWx5j1SoGF32yj6TQXl+5tlN3A=; b=fuiDQ1OdmgjM5yHSaaywx6rhSKH504AlQekvinJVA4Dkn+AmADk++JKRjwyL1JMXnM D+ldHHBojYBElPI9bFpIzZAdvHzkw8WOg2OgF6oKJ8xvUbeUqRVSKkF9nJmCRlKFH0fG sSO9Dr1/PpfVs+GOLw0sd0vIivLoiNNVxMGnOxW+pammB3LWTcpw5uEKG4tY51b3x5tk 16ZIi7dRho4HFblBPNpwF8ug9zAIqSzG3sh01Is7zyZkqU6L2VKobm1GRoPzDXVJGcHc xIM1NTyyIBgUelJ87P16VzzImOMDWD7cSUNoKPziafNiz/NYBVbFTDZnMgkXffmfmOgq CGRQ== 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=9jaEhdT+s4mzgQqOnAWx5j1SoGF32yj6TQXl+5tlN3A=; b=G16r17IJxV3Iif/7H8E1NTXldjTgHmtW44Ra3CtVcZKrPxBwnu0BWZ24VsCrQ2we1a 6pBvu9wPvM5baprHF1JYfc8bHavWh9VTy03hWvqNgwZig+YZ3JBqKTIhjz9GmXOHQG6P y80Gbht6XU3e5mNG2sqRULdTnwaEA1oCG2ulUBwb3uWmLKn+FQm4FwZAkLZImKsbQCYQ IvUPHG+ODPBhCu8iMXS+zUpOxztJQYcy1U9NQwWm3AcYfkekAGscd7Tm64WK5sOZcocq BfS6jtu7zrqYbpYIqmSY4ZqIlIbNTqbaRiIAEwcbA3L7fEcwT+rW3T7IOr5jCrHX3RB4 CiTw== X-Gm-Message-State: AG10YOTVXGUxpiuSAvrTBE0JG6+Llzo+25O2/BHEDR5z22/UyWRdOT+bnrfv0L4fxjDxlCnA00JDNR57aNl1gA== MIME-Version: 1.0 X-Received: by 10.112.161.131 with SMTP id xs3mr12122698lbb.65.1454963398237; Mon, 08 Feb 2016 12:29:58 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 8 Feb 2016 12:29:58 -0800 (PST) In-Reply-To: <56B8F32F.30600@labn.net> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.net> <56B8F32F.30600@labn.net> Date: Mon, 8 Feb 2016 12:29:58 -0800 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c31f52837cc7052b48101e Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 20:30:06 -0000 --001a11c31f52837cc7052b48101e Content-Type: text/plain; charset=UTF-8 Hi, I was commenting on solution 1. Andy On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger wrote: > Hi Andy, > > Thanks for the very good comments. > > Which solutions(s) were you commenting on -- you say "this" so is > ambiguous. > > Lou > > On 2/8/2016 2:17 PM, Andy Bierman wrote: > > > > > > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger > > wrote: > > > > Hi Juergen, (All) > > > > I've change the subject line as I'm really commenting on all three > > documented options in this message. > > > > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder > > > > wrote: > > > > > Lou, > > > > > > there are things I find fundamentally flawed and things I find > > > somewhat flawed. I do not understand why we need to mess around > with > > > data encodings at all. I do not see what gets simpler by messing > > > around with the data encodings. Engineering decisions are usually > > > cost/benefit tradeoffs. > > > > I completely agree with this statement, as a general statement. the > > motivation in this case is that users are saying that the current > > solution is inadequate. I think it behooves us to listen and see if a > > better tool can be provided that addresses the limitations raised. > > > > > I see the costs, I am unsure about the > > > benefits. > > > > > > > I think this is a question of perspective. I get that from a protocol > > standpoint, and possibly even language standpoint, why this > > discussion > > can be considered unneeded complexity. I wouldn't even be > > surprised if > > the open config folks agreed with you, as the core of their solution > > really doesn't need changes to the underlying protocol or language. > > > > As I see it, there are three options on the table to address the core > > issue of OpState: > > > > 1. Do nothing in Netconf / restconf or yang, and leave it to model > > conventions = openconfig draft > > > > 2. Extend Netconf / restconf , but not yang or models = Kent's draft > > > > 3. Use a language / tools based approach to augment models and > > automatically produce a form of option 1 style convention changes, > > without model definition restrictions. ~= Rob's draft (I'll assume > > changes previously discussed on list) > > > > WRT 1: We've heard from the model development community, i.e. model > > writers, that 1 is doable but painful and easily done incorrectly. It > > also impacts other SDOs, i.e. non ietf model writers. > > > > > > > > This solution assumes that the overhead of retrieving data (while the > > server > > is applying config) does not impact performance. IMO retrieving 2 > > separate > > data trees and comparing them on the client uses a lot of bandwidth and > > it makes the server even more busy, so applying the config will take > > even longer. > > > > > The only solution possible by replicating the YANG objects would be to > > retrieve both trees and compare them on the client. > > > > I prefer a solution that does not involve any polling by the client, > > such as a notification based solution. > > > > Since operations are data-driven in YANG, implementing a new RPC > > is the same cost as implementing new YANG data nodes. > > > > > > Andy > > > > > > WRT 2: We heard from the user community, at least a small number of > > representatives, that 2 alone doesn't address their needs. But it's > > also clear that some in the WG would prefer Option 2 (and most/all of > > these are its coauthors.) > > > > WRT 3: There's some discussion on how/if Option 3 might best meet the > > user requirements. I think focusing on this approach on the list > > could > > be helpful. > > > > One question I have for you, Juergen, and the other authors of 2 is > if > > there are changes/improvements to 3 that you/the can see that > > would make > > acceptable? Note I am NOT asking which the authors prefer as this > > is clear. > > > > For the authors of 1, I think it would be worth hearing if a > > language/tools based approach to populating the Applied Configuration > > information is workable for them. > > > > Lou > > > > > /js > > > > > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > > >> Juergen, > > >> > > >> How do you feel about the proposed modification on the table? > > (Leaving the > > >> model defined config leaves untouched and adding a -CFG or > > -metadata > > >> sibling node which would contain the additional automatically > > generated > > >> leaves.) > > >> > > >> Lou > > >> > > >> > > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > > >> > > wrote: > > >> > > >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > > >> >>Hi Juergen, > > >> >> > > >> >>I don't really follow your point. > > >> >> > > >> >>The solution is fully backward compatible - in that only > > clients that > > >> >>make use of the protocol extension would see the new > > encoding. Existing > > >> >>clients would continue to see the encoding as directly > > defined in the > > >> >>YANG schema, and a server would be able to support old and > > new clients > > >> >>concurrently. > > >> >> > > >> > > > >> >The YANG RFC details how data is encoded in XML. People have > > written > > >> >and deployed code against based on this RFC. I do not accept an > > >> >approach where an RPC option can simply request that the encoding > > >> >defined in the YANG RFC is ignored and replaced with a very > > different > > >> >encoding. > > >> > > > >> >/js (stating a clear opinion as a technical contributor) > > >> > > > >> >-- > > >> >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 > > >> > > > >> > > >> > > > > > > -- > > > 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 > > > > > > > --001a11c31f52837cc7052b48101e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


I was commenti= ng on solution 1.


Andy

On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger <= ;lberger@labn.net= > wrote:
Hi Andy,

Thanks for the very good comments.

Which solutions(s) were you commenting on -- you say "this" so is= ambiguous.

Lou

On 2/8/2016 2:17 PM, Andy Bierman wrote:
>
>
> On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Juergen, (All)
>
>=C2=A0 =C2=A0 =C2=A0I've change the subject line as I'm really = commenting on all three
>=C2=A0 =C2=A0 =C2=A0documented options in this message.
>
>=C2=A0 =C2=A0 =C2=A0On February 5, 2016 12:41:17 PM Juergen Schoenwaeld= er
>=C2=A0 =C2=A0 =C2=A0<j.schoenwaelder@jacobs-university.de
>=C2=A0 =C2=A0 =C2=A0<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> Lou,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> there are things I find fundamentally flawed a= nd things I find
>=C2=A0 =C2=A0 =C2=A0> somewhat flawed. I do not understand why we ne= ed to mess around with
>=C2=A0 =C2=A0 =C2=A0> data encodings at all. I do not see what gets = simpler by messing
>=C2=A0 =C2=A0 =C2=A0> around with the data encodings. Engineering de= cisions are usually
>=C2=A0 =C2=A0 =C2=A0> cost/benefit tradeoffs.
>
>=C2=A0 =C2=A0 =C2=A0I completely agree with this statement, as a genera= l statement. the
>=C2=A0 =C2=A0 =C2=A0motivation in this case is that users are saying th= at the current
>=C2=A0 =C2=A0 =C2=A0solution is inadequate. I think it behooves us to l= isten and see if a
>=C2=A0 =C2=A0 =C2=A0better tool can be provided that addresses the limi= tations raised.
>
>=C2=A0 =C2=A0 =C2=A0> I see the costs, I am unsure about the
>=C2=A0 =C2=A0 =C2=A0> benefits.
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0I think this is a question of perspective. I get th= at from a protocol
>=C2=A0 =C2=A0 =C2=A0standpoint, and possibly even language standpoint, = why this
>=C2=A0 =C2=A0 =C2=A0discussion
>=C2=A0 =C2=A0 =C2=A0can=C2=A0 be considered unneeded complexity. I woul= dn't even be
>=C2=A0 =C2=A0 =C2=A0surprised if
>=C2=A0 =C2=A0 =C2=A0the open config folks agreed with you, as the core = of=C2=A0 their solution
>=C2=A0 =C2=A0 =C2=A0really doesn't need changes to the underlying p= rotocol or language.
>
>=C2=A0 =C2=A0 =C2=A0As I see it, there are three options on the table t= o address the core
>=C2=A0 =C2=A0 =C2=A0issue of OpState:
>
>=C2=A0 =C2=A0 =C2=A01. Do nothing in Netconf / restconf or yang, and le= ave it to=C2=A0 model
>=C2=A0 =C2=A0 =C2=A0conventions =3D openconfig draft
>
>=C2=A0 =C2=A0 =C2=A02. Extend Netconf / restconf , but not yang or mode= ls =3D Kent's draft
>
>=C2=A0 =C2=A0 =C2=A03. Use a language / tools based approach to augment= models and
>=C2=A0 =C2=A0 =C2=A0automatically produce a form of option 1=C2=A0 styl= e convention changes,
>=C2=A0 =C2=A0 =C2=A0without model definition restrictions. ~=3D Rob'= ;s draft (I'll assume
>=C2=A0 =C2=A0 =C2=A0changes previously discussed on list)
>
>=C2=A0 =C2=A0 =C2=A0WRT 1: We've heard from the model development c= ommunity, i.e. model
>=C2=A0 =C2=A0 =C2=A0writers, that 1 is doable but painful and easily do= ne incorrectly. It
>=C2=A0 =C2=A0 =C2=A0also impacts other SDOs, i.e. non ietf model writer= s.
>
>
>
> This solution assumes that the overhead of retrieving data (while the<= br> > server
> is applying config) does not impact performance.=C2=A0 IMO retrieving = 2
> separate
> data trees and comparing them on the client uses a lot of bandwidth an= d
> it makes the server even more busy, so applying the config will take > even longer.

>
> The only solution possible by replicating the YANG objects would be to=
> retrieve both trees and compare them on the client.
>
> I prefer a solution that does not involve any polling by the client, > such as a notification based solution.
>
> Since operations are data-driven in YANG, implementing a new RPC
> is the same cost as implementing new YANG data nodes.
>
>
> Andy
>
>
>=C2=A0 =C2=A0 =C2=A0WRT 2: We heard from the user community, at least a= small number of
>=C2=A0 =C2=A0 =C2=A0representatives, that 2 alone doesn't address t= heir needs.=C2=A0 But it's
>=C2=A0 =C2=A0 =C2=A0also clear that some in the WG would prefer Option = 2 (and most/all of
>=C2=A0 =C2=A0 =C2=A0these are its coauthors.)
>
>=C2=A0 =C2=A0 =C2=A0WRT 3: There's some discussion on how/if Option= 3 might best meet the
>=C2=A0 =C2=A0 =C2=A0user requirements.=C2=A0 I think focusing on this a= pproach on the list
>=C2=A0 =C2=A0 =C2=A0could
>=C2=A0 =C2=A0 =C2=A0be helpful.
>
>=C2=A0 =C2=A0 =C2=A0One question I have for you, Juergen, and the other= authors of 2 is if
>=C2=A0 =C2=A0 =C2=A0there are changes/improvements to 3 that you/the ca= n see that
>=C2=A0 =C2=A0 =C2=A0would make
>=C2=A0 =C2=A0 =C2=A0acceptable? Note I am NOT asking which the authors = prefer as this
>=C2=A0 =C2=A0 =C2=A0is clear.
>
>=C2=A0 =C2=A0 =C2=A0For the authors of 1, I think it would be worth hea= ring if a
>=C2=A0 =C2=A0 =C2=A0language/tools based approach to populating the App= lied Configuration
>=C2=A0 =C2=A0 =C2=A0information is workable for them.
>
>=C2=A0 =C2=A0 =C2=A0Lou
>
>=C2=A0 =C2=A0 =C2=A0> /js
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou = Berger wrote:
>=C2=A0 =C2=A0 =C2=A0>> Juergen,
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> How do you feel about the proposed modific= ation on the table?
>=C2=A0 =C2=A0 =C2=A0(Leaving the
>=C2=A0 =C2=A0 =C2=A0>> model defined config leaves untouched and = adding a -CFG or
>=C2=A0 =C2=A0 =C2=A0-metadata
>=C2=A0 =C2=A0 =C2=A0>> sibling node which would contain the addit= ional automatically
>=C2=A0 =C2=A0 =C2=A0generated
>=C2=A0 =C2=A0 =C2=A0>> leaves.)
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Lou
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On February 5, 2016 7:24:29 AM Juergen Sch= oenwaelder
>=C2=A0 =C2=A0 =C2=A0>> <j.schoenwaelder@jacobs-university.de
>=C2=A0 =C2=A0 =C2=A0<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> >On Fri, Feb 05, 2016 at 10:09:37AM +00= 00, Robert Wilton wrote:
>=C2=A0 =C2=A0 =C2=A0>> >>Hi Juergen,
>=C2=A0 =C2=A0 =C2=A0>> >>
>=C2=A0 =C2=A0 =C2=A0>> >>I don't really follow your poi= nt.
>=C2=A0 =C2=A0 =C2=A0>> >>
>=C2=A0 =C2=A0 =C2=A0>> >>The solution is fully backward com= patible - in that only
>=C2=A0 =C2=A0 =C2=A0clients that
>=C2=A0 =C2=A0 =C2=A0>> >>make use of the protocol extension= would see the new
>=C2=A0 =C2=A0 =C2=A0encoding. Existing
>=C2=A0 =C2=A0 =C2=A0>> >>clients would continue to see the = encoding as directly
>=C2=A0 =C2=A0 =C2=A0defined in the
>=C2=A0 =C2=A0 =C2=A0>> >>YANG schema, and a server would be= able to support old and
>=C2=A0 =C2=A0 =C2=A0new clients
>=C2=A0 =C2=A0 =C2=A0>> >>concurrently.
>=C2=A0 =C2=A0 =C2=A0>> >>
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >The YANG RFC details how data is encod= ed in XML. People have
>=C2=A0 =C2=A0 =C2=A0written
>=C2=A0 =C2=A0 =C2=A0>> >and deployed code against based on thi= s RFC. I do not accept an
>=C2=A0 =C2=A0 =C2=A0>> >approach where an RPC option can simpl= y request that the encoding
>=C2=A0 =C2=A0 =C2=A0>> >defined in the YANG RFC is ignored and= replaced with a very
>=C2=A0 =C2=A0 =C2=A0different
>=C2=A0 =C2=A0 =C2=A0>> >encoding.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >/js (stating a clear opinion as a tech= nical contributor)
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >--
>=C2=A0 =C2=A0 =C2=A0>> >Juergen Schoenwaelder=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>=C2=A0 =C2=A0 =C2=A0>> >Phone: +49 421 200 3587=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |
>=C2=A0 =C2=A0 =C2=A0Germany
>=C2=A0 =C2=A0 =C2=A0>> >Fax:=C2=A0 =C2=A0+49 421 200 3103=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/<= /a>>
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >______________________________________= _________
>=C2=A0 =C2=A0 =C2=A0>> >netmod mailing list
>=C2=A0 =C2=A0 =C2=A0>> >net= mod@ietf.org <mailto:netmod@ietf.= org>
>=C2=A0 =C2=A0 =C2=A0>> >https://www.ietf.or= g/mailman/listinfo/netmod
>=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> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>=C2=A0 =C2=A0 =C2=A0> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |
>=C2=A0 =C2=A0 =C2=A0Germany
>=C2=A0 =C2=A0 =C2=A0> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/><= br> >=C2=A0 =C2=A0 =C2=A0>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0netmod mailing list
>=C2=A0 =C2=A0 =C2=A0netmod@ietf.org<= /a> <mailto:netmod@ietf.org> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/netmod
>
>



--001a11c31f52837cc7052b48101e-- From nobody Mon Feb 8 12:39:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575671B32E0; Mon, 8 Feb 2016 12:39:03 -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, RP_MATCHES_RCVD=-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 7Q-KJ0ZaTtVd; Mon, 8 Feb 2016 12:39:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C09A1A1BA7; Mon, 8 Feb 2016 12:39:01 -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 9E5161AE0285; Mon, 8 Feb 2016 21:39:00 +0100 (CET) Date: Mon, 08 Feb 2016 21:42:52 +0100 (CET) Message-Id: <20160208.214252.1620925752565182152.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <56B8F244.7090802@labn.net> References: <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> <56B8F244.7090802@labn.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: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, netmod@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 08 Feb 2016 20:39:03 -0000 Lou Berger wrote: > Martin, > Thanks for the response. See below. > > On 2/8/2016 1:57 PM, Martin Bjorklund wrote: > > Hi, > > > > Lou Berger wrote: [...] > >> I think this is a question of perspective. I get that from a protocol > >> standpoint, and possibly even language standpoint, why this discussion > >> can be considered unneeded complexity. I wouldn't even be surprised if > >> the open config folks agreed with you, as the core of their solution > >> really doesn't need changes to the underlying protocol or language. > >> > >> As I see it, there are three options on the table to address the core > >> issue of OpState: > >> > >> 1. Do nothing in Netconf / restconf or yang, and leave it to model > >> conventions = openconfig draft > >> > >> 2. Extend Netconf / restconf , but not yang or models = Kent's draft > >> > >> 3. Use a language / tools based approach to augment models and > >> automatically produce a form of option 1 style convention changes, > >> without model definition restrictions. ~= Rob's draft (I'll assume > >> changes previously discussed on list) > >> > >> WRT 1: We've heard from the model development community, i.e. model > >> writers, that 1 is doable but painful and easily done incorrectly. It > >> also impacts other SDOs, i.e. non ietf model writers. > >> > >> WRT 2: We heard from the user community, at least a small number of > >> representatives, that 2 alone doesn't address their needs. > > We have heard from the open config people that their proprietary > > protocol does not support datastores, but no more details. > > I think I've heard users say what they believe is true from their > perspective and context. I've heard others say we disagree (or stronger > statements.) > > >> But it's > >> also clear that some in the WG would prefer Option 2 (and most/all of > >> these are its coauthors.) > > This was the preferred solution of the room in Yokohama. 2 of the 4 > > authors were present. > > sure. And we know that the IETF consensus is not judged by who is in > the room. It is of course useful information to the WG and the chairs. You wrote "most/all of [those who prefer option 2] are its coauthors". My observation was that just 2 of the coauthors were in the room, and still this was the preferred solution; thus I think that your statement that I quoted is incorrect. /martin From nobody Mon Feb 8 12:55:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505F31B330C for ; Mon, 8 Feb 2016 12:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 HLnVHCO5f3v2 for ; Mon, 8 Feb 2016 12:55:23 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 724181B330B for ; Mon, 8 Feb 2016 12:55:23 -0800 (PST) Received: (qmail 5655 invoked by uid 0); 8 Feb 2016 20:48:41 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 8 Feb 2016 20:48:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id FwoY1s00o2SSUrH01wobMf; Mon, 08 Feb 2016 13:48:41 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=wU2YTnxGAAAA:8 a=7TsuJ21DZph7JIxWI7QA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=8pCBBPyUFbL+wUmnuuW1/by4nibyCKsl7wdb8wq6eZY=; b=GJthN9BXX+JfolELqw2S5wOLQshz38NIdl6eyjmfsZfq7mZNeXK6xR4fr7YZtcAdKMGyNPQIhaZ+Dd94PjkF0zUojNZtcVZZYqcNRNEaEm/ZeohsOICfDgIcWEb09PES; Received: from box313.bluehost.com ([69.89.31.113]:48041 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aSsjY-00081U-IZ; Mon, 08 Feb 2016 13:48:32 -0700 To: Martin Bjorklund References: <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> <56B8F244.7090802@labn.net> <20160208.214252.1620925752565182152.mbj@tail-f.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56B8FF19.4040607@labn.net> Date: Mon, 8 Feb 2016 15:48:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160208.214252.1620925752565182152.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, netmod@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 08 Feb 2016 20:55:24 -0000 [retry] Martin, On 2/8/2016 3:42 PM, Martin Bjorklund wrote: > Lou Berger wrote: >> Martin, >> Thanks for the response. See below. >> >> On 2/8/2016 1:57 PM, Martin Bjorklund wrote: >>> Hi, >>> >>> Lou Berger wrote: > [...] > >>>> But it's >>>> also clear that some in the WG would prefer Option 2 (and most/all of >>>> these are its coauthors.) >>> This was the preferred solution of the room in Yokohama. 2 of the 4 >>> authors were present. >> sure. And we know that the IETF consensus is not judged by who is in >> the room. It is of course useful information to the WG and the chairs. > You wrote "most/all of [those who prefer option 2] are its coauthors". I was referring to the on-list discussion, but fair point. But keep in mind that an in-person meeting isn't an authoritative source of WG consensus from the IETF process standpoint. > My observation was that just 2 of the coauthors were in the room, and > still this was the preferred solution; thus I think that your > statement that I quoted is incorrect. > okay, let me modify my comment: OLD and most/all of these are its coauthors NEW at very least its coauthors Lou > /martin > From nobody Mon Feb 8 12:58:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBBB1B331C for ; Mon, 8 Feb 2016 12:58:38 -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 axCK5lj13mU7 for ; Mon, 8 Feb 2016 12:58:37 -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 23F791B331B for ; Mon, 8 Feb 2016 12:58:37 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id j78so103584627lfb.1 for ; Mon, 08 Feb 2016 12:58:37 -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=hyAHhgQuz0+ds7wkBIsDYIzVKrC0eMNc8vqabnVH7jk=; b=i2J3Xhqi+nPbsulPxoYp4xOmk9jlL3K66gVHs9yK83X3qnzo0tFPCECjxqTiB5FNI9 5vto4XBFOEA25aiYjAOUoWVFHWBSfTKhtyAEcDtov+5TeTQSeZkn6stR+p0pvS9hlcjl m5+2yoMU+eO2bLD4i6Ca/WPRLKTupfoeGenG0Bc0os2qebKBOmYs9wASgUObaJDw8B1r BYEE2vofvxiYYVEEGczFotRkWtcJS6ottzJvX2CL8FtB/cLNxUdX17P2aFMJPKGSr4ew +6OGtU+BgdTCPKFAOcZKPxCH+4KwOm+WTbmPmUPwbKXxY2nRCY9Wdb+rCNMbdT/9w1KZ j4Wg== 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=hyAHhgQuz0+ds7wkBIsDYIzVKrC0eMNc8vqabnVH7jk=; b=TUSo7wTZlWE1sL6Y38kiJ0hGGIktxXYMM2LOqq5XhQLJabE8CHoeQDWyUjVt5Xy1WJ pONbFXs2ExAcpvBev5fKQ6N6iSHMAvXmaoRSpFbFCS4VU8mxlpso1qAx7B7Q//WDKUYg OkyoPzFqRczuixcz8hwiVkx7aZYgHOz2bM5mtlxqCsFkVclMAjEJ9dCSTXv1MZya+JI+ uZi4P4t6jKJPFXmNvPAdhwtKhz6BWTKhlgbHcrSndCbzZ+Mv0GsUh3WaDJ6Man5AXzBX aT3dI9YVICEMBGWoQCfC0JaJOIuSkCAXfF1ilQKfC06gAo3Yy5KYtzlAWnavlnEWnle2 jB2w== X-Gm-Message-State: AG10YOQKUE9bkrPDjFTWjM5Qkqyg3YOH89UWcphEkMW/H3YUJqgnUbkSFQno8gZDDW06iKpxr1BoqTRHdUONvQ== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr12896965lfe.8.1454965115403; Mon, 08 Feb 2016 12:58:35 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 8 Feb 2016 12:58:35 -0800 (PST) In-Reply-To: <56B8FF19.4040607@labn.net> References: <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> <56B8F244.7090802@labn.net> <20160208.214252.1620925752565182152.mbj@tail-f.com> <56B8FF19.4040607@labn.net> Date: Mon, 8 Feb 2016 12:58:35 -0800 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a113fbdd4dd5b6d052b487660 Archived-At: Cc: "netmod@ietf.org" , draft-kwatsen-netmod-opstate@ietf.org, draft-openconfig-netmod-opstate@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 08 Feb 2016 20:58:39 -0000 --001a113fbdd4dd5b6d052b487660 Content-Type: text/plain; charset=UTF-8 Hi, It should be up to the co-chairs to make consensus calls. The IETF 94 minutes indicate that "solution 2" (RPC-based) had consensus in the room. https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html I have not seen any evidence that room consensus has changed on the mailing list. Andy On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger wrote: > [retry] > > Martin, > > > On 2/8/2016 3:42 PM, Martin Bjorklund wrote: > > Lou Berger wrote: > >> Martin, > >> Thanks for the response. See below. > >> > >> On 2/8/2016 1:57 PM, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Lou Berger wrote: > > [...] > > > >>>> But it's > >>>> also clear that some in the WG would prefer Option 2 (and most/all of > >>>> these are its coauthors.) > >>> This was the preferred solution of the room in Yokohama. 2 of the 4 > >>> authors were present. > >> sure. And we know that the IETF consensus is not judged by who is in > >> the room. It is of course useful information to the WG and the chairs. > > You wrote "most/all of [those who prefer option 2] are its coauthors". > I was referring to the on-list discussion, but fair point. But keep in > mind that an in-person meeting isn't an authoritative source of WG > consensus from the IETF process standpoint. > > > My observation was that just 2 of the coauthors were in the room, and > > still this was the preferred solution; thus I think that your > > statement that I quoted is incorrect. > > > okay, let me modify my comment: > OLD > and most/all of these are its coauthors > NEW > at very least its coauthors > > Lou > > > /martin > > > > > --001a113fbdd4dd5b6d052b487660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It should be up to the co-chairs to= make consensus calls.
The IETF 94 minutes indicate that "so= lution 2" (RPC-based)
had consensus in the room.
<= br>

I have not seen any evid= ence that room consensus has changed on the mailing list.


Andy



On Mon, Feb 8, 2016 at = 12:48 PM, Lou Berger <lberger@labn.net> wrote:
[retry]

Martin,


On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
> Lou Berger <lberger@labn.net> wrote:
>> Martin,
>>=C2=A0 =C2=A0 =C2=A0Thanks for the response.=C2=A0 See below.
>>
>> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Lou Berger <lberger@lab= n.net> wrote:
> [...]
>
>>>> But it's
>>>> also clear that some in the WG would prefer Option 2 (and = most/all of
>>>> these are its coauthors.)
>>> This was the preferred solution of the room in Yokohama.=C2=A0= 2 of the 4
>>> authors were present.
>> sure.=C2=A0 And we know that the IETF consensus is not judged by w= ho is in
>> the room.=C2=A0 It is of course useful information to the WG and t= he chairs.
> You wrote "most/all of [those who prefer option 2] are its coauth= ors".
I was referring to the on-list discussion, but fair point.=C2=A0 But keep i= n
mind that an in-person meeting isn't an authoritative source of WG
consensus from the IETF process standpoint.

> My observation was that just 2 of the coauthors were in the room, and<= br> > still this was the preferred solution; thus I think that your
> statement that I quoted is incorrect.
>
okay, let me modify my comment:
OLD
and most/all of these are its coauthors
NEW
at very least its coauthors

Lou

> /martin
>



--001a113fbdd4dd5b6d052b487660-- From nobody Mon Feb 8 13:10:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230B71B3341 for ; Mon, 8 Feb 2016 13:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 2-5I_fxSJUTN for ; Mon, 8 Feb 2016 13:09:58 -0800 (PST) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 2EED81B2B42 for ; Mon, 8 Feb 2016 13:09:58 -0800 (PST) Received: (qmail 17414 invoked by uid 0); 8 Feb 2016 21:03:18 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 8 Feb 2016 21:03:18 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id G3j81s00t2SSUrH013jBbA; Mon, 08 Feb 2016 20:43:15 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=wU2YTnxGAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=J66wlDV6LYQNhDgU9G4A:9 a=JhoSo7ZlgRbbHhtE:21 a=q-viDx63X0lw92gR:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=bVcP1Dkrw6shrvcI4SP8SIQVtDHNaPAE7ccsmz431sg=; b=BQdSCHW5p8itGWh8ShwjsXwZ3s74kbmOdgFq9Y3K8WsRrs/VdDHkvnFLgydS/5HNGPVPqfp0FomUPIUJHNQxtMjY3k7WUMlOv4ThbEg61JL2AKQ5+qL4vhmz7YHeXG1c; Received: from box313.bluehost.com ([69.89.31.113]:46689 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aSseN-00071R-3I; Mon, 08 Feb 2016 13:43:11 -0700 To: Andy Bierman References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <152b17dba68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20160205174042.GB24243@elstar.local> <56B8D6D5.1000100@labn.net> <56B8F32F.30600@labn.net> From: Lou Berger Message-ID: <56B8FDD4.6080802@labn.net> Date: Mon, 8 Feb 2016 15:43:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 21:10:00 -0000 Thanks Andy -- It seems to me that there are aspects of your comments that apply to each... Lou On 2/8/2016 3:29 PM, Andy Bierman wrote: > Hi, > > > I was commenting on solution 1. > > > Andy > > On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger > wrote: > > Hi Andy, > > Thanks for the very good comments. > > Which solutions(s) were you commenting on -- you say "this" so is > ambiguous. > > Lou > > On 2/8/2016 2:17 PM, Andy Bierman wrote: > > > > > > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger > > >> wrote: > > > > Hi Juergen, (All) > > > > I've change the subject line as I'm really commenting on all > three > > documented options in this message. > > > > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder > > > > >> wrote: > > > > > Lou, > > > > > > there are things I find fundamentally flawed and things I find > > > somewhat flawed. I do not understand why we need to mess > around with > > > data encodings at all. I do not see what gets simpler by > messing > > > around with the data encodings. Engineering decisions are > usually > > > cost/benefit tradeoffs. > > > > I completely agree with this statement, as a general > statement. the > > motivation in this case is that users are saying that the > current > > solution is inadequate. I think it behooves us to listen and > see if a > > better tool can be provided that addresses the limitations > raised. > > > > > I see the costs, I am unsure about the > > > benefits. > > > > > > > I think this is a question of perspective. I get that from a > protocol > > standpoint, and possibly even language standpoint, why this > > discussion > > can be considered unneeded complexity. I wouldn't even be > > surprised if > > the open config folks agreed with you, as the core of their > solution > > really doesn't need changes to the underlying protocol or > language. > > > > As I see it, there are three options on the table to address > the core > > issue of OpState: > > > > 1. Do nothing in Netconf / restconf or yang, and leave it > to model > > conventions = openconfig draft > > > > 2. Extend Netconf / restconf , but not yang or models = > Kent's draft > > > > 3. Use a language / tools based approach to augment models and > > automatically produce a form of option 1 style convention > changes, > > without model definition restrictions. ~= Rob's draft (I'll > assume > > changes previously discussed on list) > > > > WRT 1: We've heard from the model development community, > i.e. model > > writers, that 1 is doable but painful and easily done > incorrectly. It > > also impacts other SDOs, i.e. non ietf model writers. > > > > > > > > This solution assumes that the overhead of retrieving data > (while the > > server > > is applying config) does not impact performance. IMO retrieving 2 > > separate > > data trees and comparing them on the client uses a lot of > bandwidth and > > it makes the server even more busy, so applying the config will take > > even longer. > > > > > The only solution possible by replicating the YANG objects would > be to > > retrieve both trees and compare them on the client. > > > > I prefer a solution that does not involve any polling by the client, > > such as a notification based solution. > > > > Since operations are data-driven in YANG, implementing a new RPC > > is the same cost as implementing new YANG data nodes. > > > > > > Andy > > > > > > WRT 2: We heard from the user community, at least a small > number of > > representatives, that 2 alone doesn't address their needs. > But it's > > also clear that some in the WG would prefer Option 2 (and > most/all of > > these are its coauthors.) > > > > WRT 3: There's some discussion on how/if Option 3 might best > meet the > > user requirements. I think focusing on this approach on the > list > > could > > be helpful. > > > > One question I have for you, Juergen, and the other authors > of 2 is if > > there are changes/improvements to 3 that you/the can see that > > would make > > acceptable? Note I am NOT asking which the authors prefer as > this > > is clear. > > > > For the authors of 1, I think it would be worth hearing if a > > language/tools based approach to populating the Applied > Configuration > > information is workable for them. > > > > Lou > > > > > /js > > > > > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote: > > >> Juergen, > > >> > > >> How do you feel about the proposed modification on the table? > > (Leaving the > > >> model defined config leaves untouched and adding a -CFG or > > -metadata > > >> sibling node which would contain the additional automatically > > generated > > >> leaves.) > > >> > > >> Lou > > >> > > >> > > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder > > >> > > >> wrote: > > >> > > >> >On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton > wrote: > > >> >>Hi Juergen, > > >> >> > > >> >>I don't really follow your point. > > >> >> > > >> >>The solution is fully backward compatible - in that only > > clients that > > >> >>make use of the protocol extension would see the new > > encoding. Existing > > >> >>clients would continue to see the encoding as directly > > defined in the > > >> >>YANG schema, and a server would be able to support old and > > new clients > > >> >>concurrently. > > >> >> > > >> > > > >> >The YANG RFC details how data is encoded in XML. People have > > written > > >> >and deployed code against based on this RFC. I do not > accept an > > >> >approach where an RPC option can simply request that the > encoding > > >> >defined in the YANG RFC is ignored and replaced with a very > > different > > >> >encoding. > > >> > > > >> >/js (stating a clear opinion as a technical contributor) > > >> > > > >> >-- > > >> >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 > > >> > > > >> > > >> > > > > > > -- > > > 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 Feb 8 13:20:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77211B334F for ; Mon, 8 Feb 2016 13:20: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 qDe7-RFLQcBq for ; Mon, 8 Feb 2016 13:20:49 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 2D0C81B2F61 for ; Mon, 8 Feb 2016 13:20:49 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id bc4so90234683lbc.2 for ; Mon, 08 Feb 2016 13:20:48 -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=EoCDM2ObYbS28f7/DtCkjjob5dt2ld3AgPqaOVGywBk=; b=u1V0izZwAPyh9DSg5vru5OOnpcGciJ2pGewV4E7XrIIKFM+lHFTeth7XfO9+SCkN9Y WdZaQegaGdnfDONYhrsBIjkFR/lydnCXAi3xf5dg/H/Isv3I/IQXFOkhWU4zfdLaTg6H IKfkOFw/ocukYL9r/ayGy7uALkMW4+v81mq43WyXdU2Pe79IsK+KK4IRVPTGb3DRpDAO 4KoLfEzRPoZmi9dvdum9hfh6LYHl3eITltgIrjNnR/r5LqwaKwq7/Bm42A8pNuOv5WFp blPAi2PlOSmkm71AdyufX0vHZpks3w+EGonl+B2kldPjVqltj7Poh4j/nhG//zpk6KiS 0/WA== 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=EoCDM2ObYbS28f7/DtCkjjob5dt2ld3AgPqaOVGywBk=; b=kgx/G7ADWoNOVXXIciW1Wr+QqqHd8tKInyKNOOU6Nka/elKCPi7CRRs1a+U3WJbwrC YJVagkg4tEgflGr3ILGqRr5lHVlM5X2cpxn7o7YdWhERZ16q6DIo7CQluS89L47/RCBn FlOHkl7U0FpJwhL319MZkpWww7Za1EAFSjJqPAN0MXp3vLTgujjhib67gf4nsD8VstI6 KO9qFm/xc9hhFinKgREwECcF5+ZtcPukOzp+IsliYvXaHCKitJMKdREuv3ZtgESn6W8Z Y/Ya4yp+aaEkpCQvAfbS24kzlEstOYGS46cQUxCiT4BFHvmSyh6CeAi8l+Z30770Rl4k qMbQ== X-Gm-Message-State: AG10YOQTyHYwNX1hjgYFnbSIP/CMk2uk7ioPy+c3WGyjIouDQKeikbp3s9rg6+4n8wJ5g+domeaGUpwrO76MWQ== MIME-Version: 1.0 X-Received: by 10.112.146.34 with SMTP id sz2mr12571670lbb.96.1454966447312; Mon, 08 Feb 2016 13:20:47 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 8 Feb 2016 13:20:47 -0800 (PST) In-Reply-To: <20160208.204128.275969700916546426.mbj@tail-f.com> References: <56B89670.9090300@cisco.com> <20160208.144553.2082644981061361024.mbj@tail-f.com> <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> Date: Mon, 8 Feb 2016 13:20:47 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3a85c840aaf8052b48c6cd Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 21:20:52 -0000 --047d7b3a85c840aaf8052b48c6cd Content-Type: text/plain; charset=UTF-8 On Mon, Feb 8, 2016 at 11:41 AM, Martin Bjorklund wrote: > Hi, > > Robert Wilton wrote: > > Hi Martin, > > > > On 08/02/2016 13:45, Martin Bjorklund wrote: > > > Robert Wilton wrote: > > >> > > >> On 06/02/2016 00:41, Andy Bierman wrote: > > > [...] > > > > > >>> IMO, this solution is a non-starter. > > >> OK, and yet my understanding is that the folks requesting a solution > > >> to the opstate problem are saying that the applied datastore approach > > >> is also a non-starter, or at least very undesirable. > > > But the key to finding a solution that works for everyone is to > > > understand *why* a datastore is a non-starter. As I noted in a > > [Caveat - I don't speak for the OpenConfig operators, this is just > > my perception from previous drafts, conversations, implementing some > > of the OpenConfig models] > > > > My understanding is that they want something this is very similar to > > how the OpenConfig models look. After all, their preferred solution > > to the opstate problem would be for IETF to standardize on the > > approach used in OpenConfig model design. E.g. all config nodes are > > defined in groupings, and then instantiated under both "config" and > > "state" containers. > > > > I believe that their concerns are primarily about how the operators > > systems interact with the models from a management client > > perspective rather than device implementation concerns. > > > > With the OpenConfig model/approach they get: > > - The choice of having one single tree that contains all the data > > (intended, applied and derived) - but can be split into multiple > > trees if they wish. (I.e. with their model they have no > > requirement to be aware of separate data stores at all.) > > - Every piece of data in that tree has a unique path to identify it > > (makes the data easy to interact with). > > - The intended config, applied config, and derived state can all be > > programmatically compared. > > - Related information is co-located in the tree (e.g. if you were > > browsing the data tree). > > > Here's a slightly updated version of a drawing that has been used to > explain how configuration data flows through the system: > > [candidate] -> [running/intended] -> [applied] > | > v > [startup] > A special set of RPC operations for , etc. would work just the same as reusing the NETCONF operations, except we can remove the datastore parameter (by hard-wiring it to 'applied'). So datastores are not really the issue. Many devices do not experience any significant delays when applying datastore edits, so there is no need at all on these devices to be concerned about the applied datastore. There is no need to have all the extra data nodes defined in the YANG module. IMO vendors will continue to use their own modules. It is very expensive to keep rewriting the same YANG module code over and over. An RPC or notification-based solution can work with all data models, without any YANG rewrites or any disruption to existing client code. Datastores work well in NETCONF because they scale well. They only have cost when they are implemented and used. They are also extensible - if I2RS needs special editing semantics, it is much lower cost to add a datastore rather than rewriting all the YANG modules to make an "ephemeral" container, and another copy of all the YANG data nodes. Andy > We used to have three instantiations of configuration nodes, now we > have four (applied). > > Three of these are datastores. They can be programmatically compared > (even without data model knowledge). Note that a "datastore" can be > viewed as a label (with associated semantics) of an instantiation of > these nodes. > > It is unclear to me why applied must be special (modelled explicitly > rather than a named instantiation of the nodes). > > Your list above applies only to the intended,applied subset of the > instantiations. If you want to e.g. check how startup differs from > running you need a different mechanism than to check how applied > differs from running, which means different code paths etc. > > > With a datastore solution, I think that it means: > > - Either they have to put intended and applied config into separate > > trees, or they have to come up with their own scheme to combine > > them into a single tree (given that the cfg intended/applied names > > clash). > > Do you mean in their proprietary protocol? > > > - If separate trees, to ensure paths are unique they would need to > > prefix every path with the name of the datastore/tree (hassle). > > I don't see why it would be such a hassle; compare: > > /intended/interfaces/interface[name='eth0']/mtu > > vs. > > /interfaces/interface[name='eth0']/config/mtu > > > > - Comparing the intended and applied trees is a bit more hassle > > (they would need to perform a pairwise walk across both intended > > and applied configuration trees). > > - When data is being returned from the server (if it is even > > allowed for two datastores to be returned in the same request) then > > data would not be co-located. I.e. you have to read in all the > > data for both intended and applied config datastores before you can > > start processing any of it. Whereas if the data is returned in a > > single tree then co-located data would be returned together and the > > the stream of data can be filtered/processed without building up an > > intermediate combined tree of all the data. > > > > > previous email, both your solution and the datastore solution rely on > > > the assumption that the server internally knows the difference between > > > the "intended" and "applied" value for the config true nodes. > > Please can you clarify - I don't really follow this point. > > In the open config solution there is just one schema and the server > just calls the instrumentation to fill in the values. The server > doesn't know if a node is "applied" or "derived". > > In our solutions, the server knows from the request what data is > requested, and calls the corresponding instrumentation. > > > /martin > > > > > > > For all solutions, it only makes sense if the server internally > > knows the difference between intended and applied values, so I > > assume that is just a given. > > > > > > > > > >> (Note - I don't > > >> actually know whether they regard the solution in > > >> draft-wilton-netmod-opstate-yang to be any more palatable.) > > > Right; so if their objection is that the server cannot know the > > > difference between "intended" and "applied" for the config true leafs, > > > neither of our solutions work. > > > > > > And if their objection is that their proprietary protocol does > > > can/does not encode the datastore in the "get" request, then > > > I suspect that their protocol also does not know your proposed > > > encoding. > > > > > >> From a clients operational perspective I can see how the OpenConfig > > >> model, with separate intended config and applied config leaves that > > >> are co-located in the schema tree makes life easy for the client in a > > >> way that having a separate applied configuration datastore doesn't > > >> seem to. > > > I can see how the applied datastore model makes life easier for the > > > client, e.g., a diff can be done w/o any data model knowledge at all. > > Possibly. But that requires that they have to manage having a > > separate datastore for applied config in the first place, and I'm > > not convinced that doing a pairwise diff across two datastores is > > any easier than the equivalent "diff" algorithm that they would > > write for checking the config state in the OpenConfig models. > > > > Rob > > > > > > > > > > > > > /martin > > > > > > > > >> Rob > > >> > > >> > > >>> > > >>> /js (stating a clear opinion as a technical contributor) > > >>> > > >>> -- > > >>> 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/> > > >>> > > >>> > > >>> > > >>> Andy > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > >>> > > > . > > > > > > --047d7b3a85c840aaf8052b48c6cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2016 at 11:41 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

Robert Wilton <rwilton@cisco.com> wrote:
> Hi Martin,
>
> On 08/02/2016 13:45, Martin Bjorklund wrote:
> > Robert Wilton <rwilton@ci= sco.com> wrote:
> >>
> >> On 06/02/2016 00:41, Andy Bierman wrote:
> > [...]
> >
> >>> IMO, this solution is a non-starter.
> >> OK, and yet my understanding is that the folks requesting a s= olution
> >> to the opstate problem are saying that the applied datastore = approach
> >> is also a non-starter, or at least very undesirable.
> > But the key to finding a solution that works for everyone is to > > understand *why* a datastore is a non-starter.=C2=A0 As I noted i= n a
> [Caveat - I don't speak for the OpenConfig operators, this is just=
> my perception from previous drafts, conversations, implementing some > of the OpenConfig models]
>
> My understanding is that they want something this is very similar to > how the OpenConfig models look.=C2=A0 After all, their preferred solut= ion
> to the opstate problem would be for IETF to standardize on the
> approach used in OpenConfig model design.=C2=A0 E.g. all config nodes = are
> defined in groupings, and then instantiated under both "config&qu= ot; and
> "state" containers.
>
> I believe that their concerns are primarily about how the operators > systems interact with the models from a management client
> perspective rather than device implementation concerns.
>
> With the OpenConfig model/approach they get:
>=C2=A0 - The choice of having one single tree that contains all the dat= a
>=C2=A0 =C2=A0 (intended, applied and derived) - but can be split into m= ultiple
>=C2=A0 =C2=A0 trees if they wish.=C2=A0 (I.e. with their model they hav= e no
>=C2=A0 =C2=A0 requirement to be aware of separate data stores at all.)<= br> >=C2=A0 - Every piece of data in that tree has a unique path to identify= it
>=C2=A0 =C2=A0 (makes the data easy to interact with).
>=C2=A0 - The intended config, applied config, and derived state can all= be
>=C2=A0 =C2=A0 programmatically compared.
>=C2=A0 - Related information is co-located in the tree (e.g. if you wer= e
>=C2=A0 =C2=A0 browsing the data tree).

=C2=A0
Here's a slightly updated version of a drawing that has been used to explain how configuration data flows through the system:

=C2=A0 [candidate] -> [running/intended] -> [applied]
=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 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [star= tup]



A sp= ecial set of RPC operations for <get-applied>, etc.
would w= ork just the same as reusing the NETCONF operations, except we can remove
the datastore parameter (by hard-wiring it to 'applied').= =C2=A0 So datastores
are not really the issue.

Many devices do not experience any significant delays when applying<= /div>
datastore edits, so there is no need at all on these devices to b= e concerned
about the applied datastore. There is no need to have= all the extra data nodes
defined in the YANG module.
<= br>
IMO vendors will continue to use their own modules.
It is very expensive to keep rewriting the same YANG module code over and = over.
An RPC or notification-based solution can work with all dat= a models, without
any YANG rewrites or any disruption to existing= client code.

Datastores work well in NETCONF beca= use they scale well.=C2=A0 They only have cost when
they are impl= emented and used. They are also extensible - if I2RS needs
specia= l editing semantics, it is much lower cost to add a datastore rather than
rewriting all the YANG modules to make an "ephemeral" co= ntainer, and
another copy of all the YANG data nodes.
<= br>

Andy



We used to have three instantiations of configuration nodes, now we
have four (applied).

Three of these are datastores.=C2=A0 They can be programmatically compared<= br> (even without data model knowledge).=C2=A0 Note that a "datastore"= ; can be
viewed as a label (with associated semantics) of an instantiation of
these nodes.

It is unclear to me why applied must be special (modelled explicitly
rather than a named instantiation of the nodes).

Your list above applies only to the intended,applied subset of the
instantiations.=C2=A0 If you want to e.g. check how startup differs from running you need a different mechanism than to check how applied
differs from running, which means different code paths etc.

> With a datastore solution, I think that it means:
>=C2=A0 - Either they have to put intended and applied config into separ= ate
>=C2=A0 =C2=A0 trees, or they have to come up with their own scheme to c= ombine
>=C2=A0 =C2=A0 them into a single tree (given that the cfg intended/appl= ied names
>=C2=A0 =C2=A0 clash).

Do you mean in their proprietary protocol?

>=C2=A0 - If separate trees, to ensure paths are unique they would need = to
>=C2=A0 =C2=A0 prefix every path with the name of the datastore/tree (ha= ssle).

I don't see why it would be such a hassle; compare:

=C2=A0 /intended/interfaces/interface[name=3D'eth0']/mtu

vs.

=C2=A0 /interfaces/interface[name=3D'eth0']/config/mtu


>=C2=A0 - Comparing the intended and applied trees is a bit more hassle<= br> >=C2=A0 =C2=A0 (they would need to perform a pairwise walk across both i= ntended
>=C2=A0 =C2=A0 and applied configuration trees).
>=C2=A0 - When data is being returned from the server (if it is even
>=C2=A0 =C2=A0 allowed for two datastores to be returned in the same req= uest) then
>=C2=A0 =C2=A0 data would not be co-located.=C2=A0 I.e. you have to read= in all the
>=C2=A0 =C2=A0 data for both intended and applied config datastores befo= re you can
>=C2=A0 =C2=A0 start processing any of it.=C2=A0 Whereas if the data is = returned in a
>=C2=A0 =C2=A0 single tree then co-located data would be returned togeth= er and the
>=C2=A0 =C2=A0 the stream of data can be filtered/processed without buil= ding up an
>=C2=A0 =C2=A0 intermediate combined tree of all the data.
>
> > previous email, both your solution and the datastore solution rel= y on
> > the assumption that the server internally knows the difference be= tween
> > the "intended" and "applied" value for the co= nfig true nodes.
> Please can you clarify - I don't really follow this point.

In the open config solution there is just one schema and the server
just calls the instrumentation to fill in the values.=C2=A0 The server
doesn't know if a node is "applied" or "derived".
In our solutions, the server knows from the request what data is
requested, and calls the corresponding instrumentation.


/martin





> For all solutions, it only makes sense if the server internally
> knows the difference between intended and applied values, so I
> assume that is just a given.
>
>
> >
> >> (Note - I don't
> >> actually know whether they regard the solution in
> >> draft-wilton-netmod-opstate-yang to be any more palatable.) > > Right; so if their objection is that the server cannot know the > > difference between "intended" and "applied" f= or the config true leafs,
> > neither of our solutions work.
> >
> > And if their objection is that their proprietary protocol does > > can/does not encode the datastore in the "get" request,= then
> > I suspect that their protocol also does not know your proposed > > encoding.
> >
> >>=C2=A0 From a clients operational perspective I can see how th= e OpenConfig
> >> model, with separate intended config and applied config leave= s that
> >> are co-located in the schema tree makes life easy for the cli= ent in a
> >> way that having a separate applied configuration datastore do= esn't
> >> seem to.
> > I can see how the applied datastore model makes life easier for t= he
> > client, e.g., a diff can be done w/o any data model knowledge at = all.
> Possibly.=C2=A0 But that requires that they have to manage having a > separate datastore for applied config in the first place, and I'm<= br> > not convinced that doing a pairwise diff across two datastores is
> any easier than the equivalent "diff" algorithm that they wo= uld
> write for checking the config state in the OpenConfig models.
>
> Rob
>
>
> >
> >
> > /martin
> >
> >
> >> Rob
> >>
> >>
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 /js (stating a clear opinion as a tec= hnical contributor)
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 --
> >>>=C2=A0 =C2=A0 =C2=A0 Juergen Schoenwaelder=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> >>>=C2=A0 =C2=A0 =C2=A0 Phone: +49 421 200 3587=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> >>>=C2=A0 =C2=A0 =C2=A0 Fax:=C2=A0 =C2=A0+49 421 200 3103=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/<= /a>>
> >>>
> >>>
> >>>
> >>> Andy
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 _____________________________________= __________
> >>>=C2=A0 =C2=A0 =C2=A0 netmod mailing list
> >>>=C2=A0 =C2=A0 =C2=A0 ne= tmod@ietf.org <mailto:netmod@ietf= .org>
> >>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/netmod
> >>>
> >>>
> > .
> >
>

--047d7b3a85c840aaf8052b48c6cd-- From nobody Mon Feb 8 13:21:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2292C1B335C for ; Mon, 8 Feb 2016 13:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 RjjZT2QhHhui for ; Mon, 8 Feb 2016 13:21: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 232351B3354 for ; Mon, 8 Feb 2016 13:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5656; q=dns/txt; s=iport; t=1454966471; x=1456176071; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=tGFHMovFjyk4mkfBgvbNMmxYThOB8je/+EDNT7MW5A8=; b=MiGCJ1koUJ6KdsyhEpX0pkN6FOskd6bTnWDECR2wq2YLiKR5+U/13haR Ls4Gtotia3nKF2IB85L7Qc/+dBzkCczfzscouyc+LawUqWcAJ5vn+ulco qGs0MLhMZs5EBoPxiYraxkscR1mrtPMYFXH+Db8P2f2xu/PqT2Ssw27+y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQAIBrlW/xbLJq1UCoR5iFuxDwENg?= =?us-ascii?q?WaGDQKBZxQBAQEBAQEBgQqEQQEBAQMBJxFAARALDgoJFg8JAwIBAgFFBg0GAgE?= =?us-ascii?q?BF4d4CL12AQEBAQEBAQEBAQEBAQEBAQEBGIYShDeEAQeEZAEEjSeJTo1QgVuHR?= =?us-ascii?q?oVSimyDUh4BAUKDZDwuiFMBAQE?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208";a="649143717" 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; 08 Feb 2016 21:21:08 +0000 Received: from [10.61.105.141] (dhcp-10-61-105-141.cisco.com [10.61.105.141]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u18LL8l7026514; Mon, 8 Feb 2016 21:21:08 GMT To: Martin Bjorklund References: <56B89670.9090300@cisco.com> <20160208.144553.2082644981061361024.mbj@tail-f.com> <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> From: Robert Wilton Message-ID: <56B906C4.1020307@cisco.com> Date: Mon, 8 Feb 2016 21:21:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208.204128.275969700916546426.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] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 21:21:13 -0000 On 08/02/2016 19:41, Martin Bjorklund wrote: > Hi, > > Robert Wilton wrote: >> Hi Martin, >> >> On 08/02/2016 13:45, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> On 06/02/2016 00:41, Andy Bierman wrote: >>> [...] >>> >>>>> IMO, this solution is a non-starter. >>>> OK, and yet my understanding is that the folks requesting a solution >>>> to the opstate problem are saying that the applied datastore approach >>>> is also a non-starter, or at least very undesirable. >>> But the key to finding a solution that works for everyone is to >>> understand *why* a datastore is a non-starter. As I noted in a >> [Caveat - I don't speak for the OpenConfig operators, this is just >> my perception from previous drafts, conversations, implementing some >> of the OpenConfig models] >> >> My understanding is that they want something this is very similar to >> how the OpenConfig models look. After all, their preferred solution >> to the opstate problem would be for IETF to standardize on the >> approach used in OpenConfig model design. E.g. all config nodes are >> defined in groupings, and then instantiated under both "config" and >> "state" containers. >> >> I believe that their concerns are primarily about how the operators >> systems interact with the models from a management client >> perspective rather than device implementation concerns. >> >> With the OpenConfig model/approach they get: >> - The choice of having one single tree that contains all the data >> (intended, applied and derived) - but can be split into multiple >> trees if they wish. (I.e. with their model they have no >> requirement to be aware of separate data stores at all.) >> - Every piece of data in that tree has a unique path to identify it >> (makes the data easy to interact with). >> - The intended config, applied config, and derived state can all be >> programmatically compared. >> - Related information is co-located in the tree (e.g. if you were >> browsing the data tree). > Here's a slightly updated version of a drawing that has been used to > explain how configuration data flows through the system: > > [candidate] -> [running/intended] -> [applied] > | > v > [startup] > > We used to have three instantiations of configuration nodes, now we > have four (applied). > > Three of these are datastores. They can be programmatically compared > (even without data model knowledge). Note that a "datastore" can be > viewed as a label (with associated semantics) of an instantiation of > these nodes. > > It is unclear to me why applied must be special (modelled explicitly > rather than a named instantiation of the nodes). I would say that applied configuration differs from the other three in that it isn't really configuration at all. It is a just a representation of what the system is currently doing, but to make it easy to relate back to the configuration it happens to use an equivalent schema as for the configuration (but logically with the config:true labels replaced with config:false). Given that the applied configuration is operational state, technically I think that it should just be part of the existing "operational state" datastore. But then the problem is that the nodes have the same path as the intended configuration nodes in the running configuration datastore and hence the namespace will collide during a get request ... > > Your list above applies only to the intended,applied subset of the > instantiations. If you want to e.g. check how startup differs from > running you need a different mechanism than to check how applied > differs from running, which means different code paths etc. > >> With a datastore solution, I think that it means: >> - Either they have to put intended and applied config into separate >> trees, or they have to come up with their own scheme to combine >> them into a single tree (given that the cfg intended/applied names >> clash). > Do you mean in their proprietary protocol? No, I was meaning in the proprietary management systems application code. > >> - If separate trees, to ensure paths are unique they would need to >> prefix every path with the name of the datastore/tree (hassle). > I don't see why it would be such a hassle; compare: > > /intended/interfaces/interface[name='eth0']/mtu > > vs. > > /interfaces/interface[name='eth0']/config/mtu I think that the existing protocol messages (e.g. NETCONF/etc) don't explicitly include the datastore name in the request/reply. Often the appropriate data store is inferred from the context (or the request). Hence more code is needed to add/remove the datastore name when appropriate. E.g. when I do a get request on "/intended/interfaces/interface[name='eth0']/mtu" I need to remember to strip off "/intended", and ensure that I frame the request to the right datastore. And when I get a rpc-reply from a get-config request I need to know the context of the request so that I can annotate the reply with the appropriate datastore. What if I want to get both "/intended/interfaces/interface[name='eth0']/mtu" and "/applied/interfaces/interface[name='eth0']/mtu"? Do I need to split this into two separate requests and combine the responses? So, given the choice between the two paths above, once of them seems to involve more code and work on the client side, and more chance of mistakes/confusion. Rob From nobody Mon Feb 8 13:34:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0B1B338B for ; Mon, 8 Feb 2016 13:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-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 O7UwHg3o0B1q for ; Mon, 8 Feb 2016 13:34: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 E39581B338D for ; Mon, 8 Feb 2016 13:33:59 -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 79DC21AE0285; Mon, 8 Feb 2016 22:33:58 +0100 (CET) Date: Mon, 08 Feb 2016 22:37:50 +0100 (CET) Message-Id: <20160208.223750.1590868900898520013.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56B906C4.1020307@cisco.com> References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.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] a few comments on draft-wilton-netmod-opstate-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: Mon, 08 Feb 2016 21:34:02 -0000 Robert Wilton wrote: > > > On 08/02/2016 19:41, Martin Bjorklund wrote: > > Hi, > > > > Robert Wilton wrote: > >> Hi Martin, > >> > >> On 08/02/2016 13:45, Martin Bjorklund wrote: > >>> Robert Wilton wrote: > >>>> On 06/02/2016 00:41, Andy Bierman wrote: > >>> [...] > >>> > >>>>> IMO, this solution is a non-starter. > >>>> OK, and yet my understanding is that the folks requesting a solution > >>>> to the opstate problem are saying that the applied datastore approach > >>>> is also a non-starter, or at least very undesirable. > >>> But the key to finding a solution that works for everyone is to > >>> understand *why* a datastore is a non-starter. As I noted in a > >> [Caveat - I don't speak for the OpenConfig operators, this is just > >> my perception from previous drafts, conversations, implementing some > >> of the OpenConfig models] > >> > >> My understanding is that they want something this is very similar to > >> how the OpenConfig models look. After all, their preferred solution > >> to the opstate problem would be for IETF to standardize on the > >> approach used in OpenConfig model design. E.g. all config nodes are > >> defined in groupings, and then instantiated under both "config" and > >> "state" containers. > >> > >> I believe that their concerns are primarily about how the operators > >> systems interact with the models from a management client > >> perspective rather than device implementation concerns. > >> > >> With the OpenConfig model/approach they get: > >> - The choice of having one single tree that contains all the data > >> (intended, applied and derived) - but can be split into multiple > >> trees if they wish. (I.e. with their model they have no > >> requirement to be aware of separate data stores at all.) > >> - Every piece of data in that tree has a unique path to identify it > >> (makes the data easy to interact with). > >> - The intended config, applied config, and derived state can all be > >> programmatically compared. > >> - Related information is co-located in the tree (e.g. if you were > >> browsing the data tree). > > Here's a slightly updated version of a drawing that has been used to > > explain how configuration data flows through the system: > > > > [candidate] -> [running/intended] -> [applied] > > | > > v > > [startup] > > > > We used to have three instantiations of configuration nodes, now we > > have four (applied). > > > > Three of these are datastores. They can be programmatically compared > > (even without data model knowledge). Note that a "datastore" can be > > viewed as a label (with associated semantics) of an instantiation of > > these nodes. > > > > It is unclear to me why applied must be special (modelled explicitly > > rather than a named instantiation of the nodes). > > I would say that applied configuration differs from the other three in > that it isn't really configuration at all. > > It is a just a representation of what the system is currently doing, > but to make it easy to relate back to the configuration it happens to > use an equivalent schema as for the configuration (but logically with > the config:true labels replaced with config:false). Just like "running" is not writable in a server that supports "candidate" but not :writable-running. > Given that the applied configuration is operational state, technically > I think that it should just be part of the existing "operational > state" datastore. But then the problem is that the nodes have the > same path as the intended configuration nodes in the running > configuration datastore and hence the namespace will collide during a > get request ... This is a problem/known issue with in NETCONF. There have been various proposals to fix this, e.g. Andy's "get2". I'd rather fix the problem in the protocol once, than in all data models. > > Your list above applies only to the intended,applied subset of the > > instantiations. If you want to e.g. check how startup differs from > > running you need a different mechanism than to check how applied > > differs from running, which means different code paths etc. > > > >> With a datastore solution, I think that it means: > >> - Either they have to put intended and applied config into separate > >> trees, or they have to come up with their own scheme to combine > >> them into a single tree (given that the cfg intended/applied names > >> clash). > > Do you mean in their proprietary protocol? > No, I was meaning in the proprietary management systems application > code. > > > > >> - If separate trees, to ensure paths are unique they would need to > >> prefix every path with the name of the datastore/tree (hassle). > > I don't see why it would be such a hassle; compare: > > > > /intended/interfaces/interface[name='eth0']/mtu > > > > vs. > > > > /interfaces/interface[name='eth0']/config/mtu > I think that the existing protocol messages (e.g. NETCONF/etc) don't > explicitly include the datastore name in the request/reply. Often the > appropriate data store is inferred from the context (or the request). > Hence more code is needed to add/remove the datastore name when > appropriate. > > E.g. when I do a get request on > "/intended/interfaces/interface[name='eth0']/mtu" I need to remember > to strip off "/intended", and ensure that I frame the request to the > right datastore. And when I get a rpc-reply from a get-config request > I need to know the context of the request so that I can annotate the > reply with the appropriate datastore. ... just like I have to remember to remove the last occurance of "config" and replace it with "state" to get applied. This (path handling) is trivial in both solutions. > What if I want to get both > "/intended/interfaces/interface[name='eth0']/mtu" and > "/applied/interfaces/interface[name='eth0']/mtu"? Do I need to split > this into two separate requests and combine the responses? Currently yes. Just like if you want to get both the values from startup and from running. Also in this case, I'd prefer to solve the problem generically in the protocol. /martin > So, given the choice between the two paths above, once of them seems > to involve more code and work on the client side, and more chance of > mistakes/confusion. > > Rob > > From nobody Mon Feb 8 16:34:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAB01B3E48; Mon, 8 Feb 2016 16:34:07 -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 UYJ-rWjMUB-k; Mon, 8 Feb 2016 16:34:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1: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 0597C1B3E47; Mon, 8 Feb 2016 16:34:00 -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.403.16; Tue, 9 Feb 2016 00: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.0403.017; Tue, 9 Feb 2016 00:33:42 +0000 From: Kent Watsen To: Andy Bierman , Lou Berger Thread-Topic: [netmod] OpState Solution Options Thread-Index: AQHRYqIaXIa/6CsizUmNXfq8wtBtXZ8ij4sAgAANvwCAAAGNgIAAAtiA///oR4A= Date: Tue, 9 Feb 2016 00:33:42 +0000 Message-ID: <5A364637-E520-405E-B090-E4D0847392C9@juniper.net> References: <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> <56B8F244.7090802@labn.net> <20160208.214252.1620925752565182152.mbj@tail-f.com> <56B8FF19.4040607@labn.net> 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.160109 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:cNXLvlkWRfUWVgpAsD/4DzeKDhs/cKzwZ/PReA7M4LaYk/QhZlXYtd5mjwMGNYOjH1cVitrxHrvMVNUyuXm5HpJMuB6zhKnRGPNXZM6eqVSlgXLtD7YfJHBtLSPi7pDF//2K8FEWKIhQUqyv50Remw==; 24:3RvMpk7I0FuAgePS4NqCI+HTLP3OMM7OsQB92p+3wCNKBbGFosZwEqUJtFi6CcaxJzSZOzytzD5IW7d3Y+GOK+jRl6dpBEDC/5jP+lEHiLQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: 4adb226c-305d-47e0-c791-08d330e8a988 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(54014002)(479174004)(24454002)(51444003)(51914003)(377454003)(164054003)(5004730100002)(99286002)(10400500002)(77096005)(19617315012)(93886004)(4326007)(83506001)(189998001)(5001770100001)(82746002)(4001350100001)(19580405001)(106116001)(15975445007)(5001960100002)(11100500001)(3280700002)(2950100001)(2900100001)(3660700001)(2906002)(6116002)(5002640100001)(3846002)(586003)(102836003)(1096002)(1220700001)(54356999)(36756003)(86362001)(76176999)(40100003)(122556002)(87936001)(5008740100001)(19580395003)(33656002)(16236675004)(50986999)(83716003)(92566002)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5A364637E520405EB090E4D0847392C9junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2016 00:33:42.3137 (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@ietf.org" , "draft-kwatsen-netmod-opstate@ietf.org" , "draft-openconfig-netmod-opstate@ietf.org" Subject: Re: [netmod] OpState Solution Options 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, 09 Feb 2016 00:34:07 -0000 --_000_5A364637E520405EB090E4D0847392C9junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FzIGNvLWNoYWlyXQ0KDQpBbmR5IGV0IGFsLiwNCg0KUGxlYXNlIGtlZXAgaW4gbWluZCB0aGlz IG1lc3NhZ2UgZnJvbSBCZW5vaXQ6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQ1ODUuaHRtbA0KDQpBbmQgbm90ZSB0aGF0IExvdSBp cyB0cnlpbmcgdG8gcGVyZm9ybSB0aGUgYW5hbHlzaXMgbm93Lg0KDQpUaGFua3MsDQpLZW50DQoN Cg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVt YXdvcmtzLmNvbT4+DQpEYXRlOiBNb25kYXksIEZlYnJ1YXJ5IDgsIDIwMTYgYXQgMzo1OCBQTQ0K VG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1m LmNvbT4+LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4s ICJkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1vcHN0YXRlQGlldGYub3JnPG1haWx0bzpkcmFmdC1v cGVuY29uZmlnLW5ldG1vZC1vcHN0YXRlQGlldGYub3JnPiIgPGRyYWZ0LW9wZW5jb25maWctbmV0 bW9kLW9wc3RhdGVAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3Rh dGVAaWV0Zi5vcmc+PiwgImRyYWZ0LWt3YXRzZW4tbmV0bW9kLW9wc3RhdGVAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWt3YXRzZW4tbmV0bW9kLW9wc3RhdGVAaWV0Zi5vcmc+IiA8ZHJhZnQta3dhdHNl bi1uZXRtb2Qtb3BzdGF0ZUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3Bz dGF0ZUBpZXRmLm9yZz4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtuZXRtb2RdIE9wU3RhdGUgU29sdXRpb24gT3B0aW9ucw0KDQpIaSwNCg0KSXQgc2hvdWxkIGJl IHVwIHRvIHRoZSBjby1jaGFpcnMgdG8gbWFrZSBjb25zZW5zdXMgY2FsbHMuDQpUaGUgSUVURiA5 NCBtaW51dGVzIGluZGljYXRlIHRoYXQgInNvbHV0aW9uIDIiIChSUEMtYmFzZWQpDQpoYWQgY29u c2Vuc3VzIGluIHRoZSByb29tLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL25ldG1vZC9t aW51dGVzP2l0ZW09bWludXRlcy05NC1uZXRtb2QuaHRtbA0KDQpJIGhhdmUgbm90IHNlZW4gYW55 IGV2aWRlbmNlIHRoYXQgcm9vbSBjb25zZW5zdXMgaGFzIGNoYW5nZWQgb24gdGhlIG1haWxpbmcg bGlzdC4NCg0KDQpBbmR5DQoNCg0KDQpPbiBNb24sIEZlYiA4LCAyMDE2IGF0IDEyOjQ4IFBNLCBM b3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4gd3Jv dGU6DQpbcmV0cnldDQoNCk1hcnRpbiwNCg0KDQpPbiAyLzgvMjAxNiAzOjQyIFBNLCBNYXJ0aW4g QmpvcmtsdW5kIHdyb3RlOg0KPiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzps YmVyZ2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQo+PiBNYXJ0aW4sDQo+PiAgICAgVGhhbmtzIGZvciB0 aGUgcmVzcG9uc2UuICBTZWUgYmVsb3cuDQo+Pg0KPj4gT24gMi84LzIwMTYgMTo1NyBQTSwgTWFy dGluIEJqb3JrbHVuZCB3cm90ZToNCj4+PiBIaSwNCj4+Pg0KPj4+IExvdSBCZXJnZXIgPGxiZXJn ZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCj4gWy4uLl0NCj4N Cj4+Pj4gQnV0IGl0J3MNCj4+Pj4gYWxzbyBjbGVhciB0aGF0IHNvbWUgaW4gdGhlIFdHIHdvdWxk IHByZWZlciBPcHRpb24gMiAoYW5kIG1vc3QvYWxsIG9mDQo+Pj4+IHRoZXNlIGFyZSBpdHMgY29h dXRob3JzLikNCj4+PiBUaGlzIHdhcyB0aGUgcHJlZmVycmVkIHNvbHV0aW9uIG9mIHRoZSByb29t IGluIFlva29oYW1hLiAgMiBvZiB0aGUgNA0KPj4+IGF1dGhvcnMgd2VyZSBwcmVzZW50Lg0KPj4g c3VyZS4gIEFuZCB3ZSBrbm93IHRoYXQgdGhlIElFVEYgY29uc2Vuc3VzIGlzIG5vdCBqdWRnZWQg Ynkgd2hvIGlzIGluDQo+PiB0aGUgcm9vbS4gIEl0IGlzIG9mIGNvdXJzZSB1c2VmdWwgaW5mb3Jt YXRpb24gdG8gdGhlIFdHIGFuZCB0aGUgY2hhaXJzLg0KPiBZb3Ugd3JvdGUgIm1vc3QvYWxsIG9m IFt0aG9zZSB3aG8gcHJlZmVyIG9wdGlvbiAyXSBhcmUgaXRzIGNvYXV0aG9ycyIuDQpJIHdhcyBy ZWZlcnJpbmcgdG8gdGhlIG9uLWxpc3QgZGlzY3Vzc2lvbiwgYnV0IGZhaXIgcG9pbnQuICBCdXQg a2VlcCBpbg0KbWluZCB0aGF0IGFuIGluLXBlcnNvbiBtZWV0aW5nIGlzbid0IGFuIGF1dGhvcml0 YXRpdmUgc291cmNlIG9mIFdHDQpjb25zZW5zdXMgZnJvbSB0aGUgSUVURiBwcm9jZXNzIHN0YW5k cG9pbnQuDQoNCj4gTXkgb2JzZXJ2YXRpb24gd2FzIHRoYXQganVzdCAyIG9mIHRoZSBjb2F1dGhv cnMgd2VyZSBpbiB0aGUgcm9vbSwgYW5kDQo+IHN0aWxsIHRoaXMgd2FzIHRoZSBwcmVmZXJyZWQg c29sdXRpb247IHRodXMgSSB0aGluayB0aGF0IHlvdXINCj4gc3RhdGVtZW50IHRoYXQgSSBxdW90 ZWQgaXMgaW5jb3JyZWN0Lg0KPg0Kb2theSwgbGV0IG1lIG1vZGlmeSBteSBjb21tZW50Og0KT0xE DQphbmQgbW9zdC9hbGwgb2YgdGhlc2UgYXJlIGl0cyBjb2F1dGhvcnMNCk5FVw0KYXQgdmVyeSBs ZWFzdCBpdHMgY29hdXRob3JzDQoNCkxvdQ0KDQo+IC9tYXJ0aW4NCj4NCg0KDQoNCg== --_000_5A364637E520405EB090E4D0847392C9junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <2087E83FF14C6E40BD993672B12EF492@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+W0Fz IGNvLWNoYWlyXTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5keSBldCBhbC4sPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2Uga2VlcCBpbiBtaW5kIHRoaXMgbWVz c2FnZSBmcm9tIEJlbm9pdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQ1ODUu aHRtbDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5kIG5vdGUgdGhhdCBMb3UgaXMg dHJ5aW5nIHRvIHBlcmZvcm0gdGhlIGFuYWx5c2lzIG5vdy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+S2VudDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QW5keSBCaWVybWFuICZsdDs8YSBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5 LCBGZWJydWFyeSA4LCAyMDE2IGF0IDM6NTggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+VG86IDwvc3Bhbj5Mb3UgQmVyZ2VyICZsdDs8YSBocmVmPSJtYWlsdG86bGJlcmdl ckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7LCBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZUBp ZXRmLm9yZyI+ZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZUBpZXRmLm9yZzwvYT4mcXVv dDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGVA aWV0Zi5vcmciPmRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGVAaWV0Zi5vcmc8L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWt3YXRzZW4tbmV0bW9kLW9wc3RhdGVAaWV0 Zi5vcmciPmRyYWZ0LWt3YXRzZW4tbmV0bW9kLW9wc3RhdGVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZUBpZXRmLm9yZyI+ ZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZUBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90Ozxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW25ldG1vZF0gT3BTdGF0ZSBTb2x1dGlvbiBPcHRpb25zPGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSwNCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pkl0IHNob3VsZCBiZSB1cCB0byB0aGUgY28tY2hhaXJzIHRvIG1ha2UgY29u c2Vuc3VzIGNhbGxzLjwvZGl2Pg0KPGRpdj5UaGUgSUVURiA5NCBtaW51dGVzIGluZGljYXRlIHRo YXQgJnF1b3Q7c29sdXRpb24gMiZxdW90OyAoUlBDLWJhc2VkKTwvZGl2Pg0KPGRpdj5oYWQgY29u c2Vuc3VzIGluIHRoZSByb29tLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRtb2QvbWludXRlcz9pdGVtPW1pbnV0ZXMt OTQtbmV0bW9kLmh0bWwiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0bW9kL21pbnV0ZXM/ aXRlbT1taW51dGVzLTk0LW5ldG1vZC5odG1sPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+SSBoYXZlIG5vdCBzZWVuIGFueSBldmlkZW5jZSB0aGF0IHJvb20gY29uc2Vu c3VzIGhhcyBjaGFuZ2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48 YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBGZWIgOCwgMjAxNiBhdCAxMjo0 OCBQTSwgTG91IEJlcmdlciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmxi ZXJnZXJAbGFibi5uZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDs8 L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KW3JldHJ5XTxicj4NCjxicj4NCk1hcnRpbiw8YnI+DQo8YnI+DQo8YnI+DQpPbiAy LzgvMjAxNiAzOjQyIFBNLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOjxicj4NCiZndDsgTG91IEJl cmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiPmxiZXJnZXJAbGFibi5u ZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBNYXJ0aW4sPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO1RoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiZuYnNwOyBTZWUgYmVsb3cu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAyLzgvMjAxNiAxOjU3IFBNLCBNYXJ0aW4g QmpvcmtsdW5kIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJA bGFibi5uZXQiPmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFsuLi5d PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQnV0IGl0J3M8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IGFsc28gY2xlYXIgdGhhdCBzb21lIGluIHRoZSBXRyB3b3VsZCBwcmVmZXIgT3B0aW9u IDIgKGFuZCBtb3N0L2FsbCBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhlc2UgYXJlIGl0cyBj b2F1dGhvcnMuKTxicj4NCiZndDsmZ3Q7Jmd0OyBUaGlzIHdhcyB0aGUgcHJlZmVycmVkIHNvbHV0 aW9uIG9mIHRoZSByb29tIGluIFlva29oYW1hLiZuYnNwOyAyIG9mIHRoZSA0PGJyPg0KJmd0OyZn dDsmZ3Q7IGF1dGhvcnMgd2VyZSBwcmVzZW50Ljxicj4NCiZndDsmZ3Q7IHN1cmUuJm5ic3A7IEFu ZCB3ZSBrbm93IHRoYXQgdGhlIElFVEYgY29uc2Vuc3VzIGlzIG5vdCBqdWRnZWQgYnkgd2hvIGlz IGluPGJyPg0KJmd0OyZndDsgdGhlIHJvb20uJm5ic3A7IEl0IGlzIG9mIGNvdXJzZSB1c2VmdWwg aW5mb3JtYXRpb24gdG8gdGhlIFdHIGFuZCB0aGUgY2hhaXJzLjxicj4NCiZndDsgWW91IHdyb3Rl ICZxdW90O21vc3QvYWxsIG9mIFt0aG9zZSB3aG8gcHJlZmVyIG9wdGlvbiAyXSBhcmUgaXRzIGNv YXV0aG9ycyZxdW90Oy48YnI+DQpJIHdhcyByZWZlcnJpbmcgdG8gdGhlIG9uLWxpc3QgZGlzY3Vz c2lvbiwgYnV0IGZhaXIgcG9pbnQuJm5ic3A7IEJ1dCBrZWVwIGluPGJyPg0KbWluZCB0aGF0IGFu IGluLXBlcnNvbiBtZWV0aW5nIGlzbid0IGFuIGF1dGhvcml0YXRpdmUgc291cmNlIG9mIFdHPGJy Pg0KY29uc2Vuc3VzIGZyb20gdGhlIElFVEYgcHJvY2VzcyBzdGFuZHBvaW50Ljxicj4NCjxicj4N CiZndDsgTXkgb2JzZXJ2YXRpb24gd2FzIHRoYXQganVzdCAyIG9mIHRoZSBjb2F1dGhvcnMgd2Vy ZSBpbiB0aGUgcm9vbSwgYW5kPGJyPg0KJmd0OyBzdGlsbCB0aGlzIHdhcyB0aGUgcHJlZmVycmVk IHNvbHV0aW9uOyB0aHVzIEkgdGhpbmsgdGhhdCB5b3VyPGJyPg0KJmd0OyBzdGF0ZW1lbnQgdGhh dCBJIHF1b3RlZCBpcyBpbmNvcnJlY3QuPGJyPg0KJmd0Ozxicj4NCm9rYXksIGxldCBtZSBtb2Rp ZnkgbXkgY29tbWVudDo8YnI+DQpPTEQ8YnI+DQphbmQgbW9zdC9hbGwgb2YgdGhlc2UgYXJlIGl0 cyBjb2F1dGhvcnM8YnI+DQpORVc8YnI+DQphdCB2ZXJ5IGxlYXN0IGl0cyBjb2F1dGhvcnM8YnI+ DQo8YnI+DQpMb3U8YnI+DQo8YnI+DQomZ3Q7IC9tYXJ0aW48YnI+DQomZ3Q7PGJyPg0KPGJyPg0K PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5A364637E520405EB090E4D0847392C9junipernet_-- From nobody Tue Feb 9 03:17:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24691A8928 for ; Tue, 9 Feb 2016 03:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 lgOKLLtAMLXv for ; Tue, 9 Feb 2016 03:17:17 -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 5AE0E1A8932 for ; Tue, 9 Feb 2016 03:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1102; q=dns/txt; s=iport; t=1455016636; x=1456226236; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dx3Rdn5YNs7tUU7uBFu68exmbSK1bAiSKn1g2U2lCxU=; b=F4ypSgHQOFLNnviwm2s/85/Z2xg9tYOCDfOfjCipSJ3WbYn8YwQxbdGi A7HS8DGf3GkKRNxKTj71EyQrrlVLKEbadyL6Ttb/++HOsZFchCtssz+Rt qhSrth44fFsKmBJ/55PCQ1YSVn384HlJPmHI/qdNEgOn4FyphUXjjvPAj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACRyblW/xbLJq1ejVWzCIYNAoIFA?= =?us-ascii?q?QEBAQEBgQuEQgEBBDhAEQsYCRYPCQMCAQIBRQYBDAgBAYgXvgkBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBGoYShDeEGoRSAQSWd41QgVuHRoVSim2DUmKDZDyHSiWBEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,420,1449532800"; d="scan'208";a="630351549" 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; 09 Feb 2016 11:17:14 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u19BHDNV030002; Tue, 9 Feb 2016 11:17:13 GMT To: Andy Bierman , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> From: Robert Wilton Message-ID: <56B9CAB9.5050402@cisco.com> Date: Tue, 9 Feb 2016 11:17:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208162059.GA29638@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 11:17:24 -0000 On 08/02/2016 16:20, Juergen Schoenwaelder wrote: > On Mon, Feb 08, 2016 at 01:21:52PM +0000, Robert Wilton wrote: >> So, IIRC, your concern is specifically that a generic YANG client >> library cannot validate that the RPC reply is well formed against the >> schema without knowledge about the request. Is that correct? >> > None of the existing tools that assume YANG defined data is XML > encoded according to RFC 6020 will not be able to process data in a > new encoding. OK. As Lou indicates, the proposed protocol schema encoding could also be generated by tooling (i.e. a pyang plugin). I.e. a client can take the source YANG models (e.g. as defined by IETF) and apply a transformation to them that would generate a set of YANG models that are the same except that they have the extra applied configuration nodes added to them. An opstate aware client could use the generated YANG models to both internally manage the manageability data, and also to validate that the messages sent to/from the server conform with the extended schema. Rob > > /js > From nobody Tue Feb 9 07:07:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110D41A910A for ; Tue, 9 Feb 2016 07:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 0JIt1tYzkxtt for ; Tue, 9 Feb 2016 07:06:57 -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 9123F1A9109 for ; Tue, 9 Feb 2016 07:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7442; q=dns/txt; s=iport; t=1455030416; x=1456240016; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=MBXJ3Bqu593cD50cRfNB+VhwgoXbDkF1yYyiO4aV+3g=; b=QY0370LcczsoLbvj/W4uq/Cw8qUUEMf2h19wdAaV8U7mfFD6fMIw7ieC Ty1tEQRKUzhiXJjuc3Z9d4iih9l2BARwXKPo5ODRONim+MxHI/oDqz+PL FS48UkeDuOi0Q7d0+NNTv1m+ASmNc9I86bS0vyg4iSSVeheaE/36IyR9n k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBACx/7lW/xbLJq1UCoR5iFyzD4YNA?= =?us-ascii?q?oF/AQEBAQEBgQuEQQEBAQMBJxFAARALDgoJFg8JAwIBAgFFBg0GAgEBF4d4CL5?= =?us-ascii?q?7AQEBAQEBAQEBAQEBAQEBAQEBGIYShDeEAQcShFIBBI0niVGNUIFbhEODA4VSi?= =?us-ascii?q?m2DUmKDZDwuiFMBAQE?= X-IronPort-AV: E=Sophos;i="5.22,421,1449532800"; d="scan'208";a="630357945" 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; 09 Feb 2016 15:06:54 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u19F6sH9016663; Tue, 9 Feb 2016 15:06:54 GMT To: Martin Bjorklund References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> From: Robert Wilton Message-ID: <56BA008E.5070102@cisco.com> Date: Tue, 9 Feb 2016 15:06:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208.223750.1590868900898520013.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] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 15:06:59 -0000 On 08/02/2016 21:37, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 08/02/2016 19:41, Martin Bjorklund wrote: >>> Hi, >>> >>> Robert Wilton wrote: >>>> Hi Martin, >>>> >>>> On 08/02/2016 13:45, Martin Bjorklund wrote: >>>>> Robert Wilton wrote: >>>>>> On 06/02/2016 00:41, Andy Bierman wrote: >>>>> [...] >>>>> >>>>>>> IMO, this solution is a non-starter. >>>>>> OK, and yet my understanding is that the folks requesting a solution >>>>>> to the opstate problem are saying that the applied datastore approach >>>>>> is also a non-starter, or at least very undesirable. >>>>> But the key to finding a solution that works for everyone is to >>>>> understand *why* a datastore is a non-starter. As I noted in a >>>> [Caveat - I don't speak for the OpenConfig operators, this is just >>>> my perception from previous drafts, conversations, implementing some >>>> of the OpenConfig models] >>>> >>>> My understanding is that they want something this is very similar to >>>> how the OpenConfig models look. After all, their preferred solution >>>> to the opstate problem would be for IETF to standardize on the >>>> approach used in OpenConfig model design. E.g. all config nodes are >>>> defined in groupings, and then instantiated under both "config" and >>>> "state" containers. >>>> >>>> I believe that their concerns are primarily about how the operators >>>> systems interact with the models from a management client >>>> perspective rather than device implementation concerns. >>>> >>>> With the OpenConfig model/approach they get: >>>> - The choice of having one single tree that contains all the data >>>> (intended, applied and derived) - but can be split into multiple >>>> trees if they wish. (I.e. with their model they have no >>>> requirement to be aware of separate data stores at all.) >>>> - Every piece of data in that tree has a unique path to identify it >>>> (makes the data easy to interact with). >>>> - The intended config, applied config, and derived state can all be >>>> programmatically compared. >>>> - Related information is co-located in the tree (e.g. if you were >>>> browsing the data tree). >>> Here's a slightly updated version of a drawing that has been used to >>> explain how configuration data flows through the system: >>> >>> [candidate] -> [running/intended] -> [applied] >>> | >>> v >>> [startup] >>> >>> We used to have three instantiations of configuration nodes, now we >>> have four (applied). >>> >>> Three of these are datastores. They can be programmatically compared >>> (even without data model knowledge). Note that a "datastore" can be >>> viewed as a label (with associated semantics) of an instantiation of >>> these nodes. >>> >>> It is unclear to me why applied must be special (modelled explicitly >>> rather than a named instantiation of the nodes). >> I would say that applied configuration differs from the other three in >> that it isn't really configuration at all. >> >> It is a just a representation of what the system is currently doing, >> but to make it easy to relate back to the configuration it happens to >> use an equivalent schema as for the configuration (but logically with >> the config:true labels replaced with config:false). > Just like "running" is not writable in a server that supports > "candidate" but not :writable-running. That isn't really the same. The issue isn't so much about whether this is writable or not, but whether the data is configuration or state. >> Given that the applied configuration is operational state, technically >> I think that it should just be part of the existing "operational >> state" datastore. But then the problem is that the nodes have the >> same path as the intended configuration nodes in the running >> configuration datastore and hence the namespace will collide during a >> get request ... > This is a problem/known issue with in NETCONF. There have been > various proposals to fix this, e.g. Andy's "get2". I'd rather fix the > problem in the protocol once, than in all data models. > > >>> Your list above applies only to the intended,applied subset of the >>> instantiations. If you want to e.g. check how startup differs from >>> running you need a different mechanism than to check how applied >>> differs from running, which means different code paths etc. >>> >>>> With a datastore solution, I think that it means: >>>> - Either they have to put intended and applied config into separate >>>> trees, or they have to come up with their own scheme to combine >>>> them into a single tree (given that the cfg intended/applied names >>>> clash). >>> Do you mean in their proprietary protocol? >> No, I was meaning in the proprietary management systems application >> code. >> >>>> - If separate trees, to ensure paths are unique they would need to >>>> prefix every path with the name of the datastore/tree (hassle). >>> I don't see why it would be such a hassle; compare: >>> >>> /intended/interfaces/interface[name='eth0']/mtu >>> >>> vs. >>> >>> /interfaces/interface[name='eth0']/config/mtu >> I think that the existing protocol messages (e.g. NETCONF/etc) don't >> explicitly include the datastore name in the request/reply. Often the >> appropriate data store is inferred from the context (or the request). >> Hence more code is needed to add/remove the datastore name when >> appropriate. >> >> E.g. when I do a get request on >> "/intended/interfaces/interface[name='eth0']/mtu" I need to remember >> to strip off "/intended", and ensure that I frame the request to the >> right datastore. And when I get a rpc-reply from a get-config request >> I need to know the context of the request so that I can annotate the >> reply with the appropriate datastore. > ... just like I have to remember to remove the last occurance of > "config" and replace it with "state" to get applied. This (path > handling) is trivial in both solutions. I don't agree that the complexity is the same here for both cases. In the OpenConfig models you just get and process the item that you want: - No extra path manipulation is required. - The path itself always fully resolves to an individual value. - There is never any ambiguity. > >> What if I want to get both >> "/intended/interfaces/interface[name='eth0']/mtu" and >> "/applied/interfaces/interface[name='eth0']/mtu"? Do I need to split >> this into two separate requests and combine the responses? > Currently yes. Just like if you want to get both the values from > startup and from running. Also in this case, I'd prefer to solve the > problem generically in the protocol. OK. Can you please suggest an approach of how to return a single tree that contains the data from two separate datastores (where the leaf paths may overlap)? I think that the approach would need to work both for get requests and also notification data. Rob > > > /martin > > >> So, given the choice between the two paths above, once of them seems >> to involve more code and work on the client side, and more chance of >> mistakes/confusion. >> >> Rob >> >> > . > From nobody Tue Feb 9 07:42:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F77C1A9302 for ; Tue, 9 Feb 2016 07:42:58 -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 J3NmLP7ucnKz for ; Tue, 9 Feb 2016 07:42:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A891A9300 for ; Tue, 9 Feb 2016 07:42:53 -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.403.16; Tue, 9 Feb 2016 15:42: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.0403.017; Tue, 9 Feb 2016 15:42:36 +0000 From: Kent Watsen To: Robert Wilton , Martin Bjorklund Thread-Topic: [netmod] a few comments on draft-wilton-netmod-opstate-yang Thread-Index: AQHRX5vj8n48Wc8D1kOhd6Pt2B8rSJ8dNgaAgAAFZYCAACWFAIAAzhoAgAP5FgCAAAa2gIAAGwYAgABIUwCAABvZAIAABKoAgAElGwD//7YoAA== Date: Tue, 9 Feb 2016 15:42:36 +0000 Message-ID: References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> <56BA008E.5070102@cisco.com> In-Reply-To: <56BA008E.5070102@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.160109 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:uMQSZKvxkaQbPXZ7rlWU3VfKy1oVnx8k3dV1yeQsSJhUkhizeWvggST9bZfTJDFf+ojnOn94MhwsV2QHnpj+/BizTTHf4tM7uBVwlQpG/KlgisqqIag46TqA0nXA7GSrU+qPQqK3GIzxmZix4bS/lA==; 24:jzxUenulhRfQpfEiKMc+CPD3NDNC63bBI0XBCtGI/o5cx7etdv9mLTdrPwn2/MWaea/QWo1qffW1nQBlpN0NTCx5nzEFJAyvgszVNTaQULA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: 83f6a2bb-7f84-4779-68b2-08d33167a234 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(99286002)(5004730100002)(10400500002)(77096005)(93886004)(4326007)(82746002)(83506001)(5001770100001)(189998001)(4001350100001)(106116001)(5001960100002)(2950100001)(3280700002)(3660700001)(2900100001)(11100500001)(2906002)(586003)(3846002)(6116002)(1220700001)(102836003)(1096002)(5002640100001)(230783001)(36756003)(54356999)(86362001)(76176999)(66066001)(92566002)(33656002)(122556002)(5008740100001)(87936001)(83716003)(50986999)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <74F28E6A6616884081913FE5E1783C34@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2016 15:42:36.1014 (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@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 15:42:58 -0000 DQoNCg0KDQo+Q2FuIHlvdSBwbGVhc2Ugc3VnZ2VzdCBhbiBhcHByb2FjaCBvZiBob3cgdG8gcmV0 dXJuIGEgc2luZ2xlIHRyZWUgdGhhdCANCj5jb250YWlucyB0aGUgZGF0YSBmcm9tIHR3byBzZXBh cmF0ZSBkYXRhc3RvcmVzICh3aGVyZSB0aGUgbGVhZiBwYXRocyBtYXkgDQo+b3ZlcmxhcCk/ICBJ IHRoaW5rIHRoYXQgdGhlIGFwcHJvYWNoIHdvdWxkIG5lZWQgdG8gd29yayBib3RoIGZvciBnZXQg DQo+cmVxdWVzdHMgYW5kIGFsc28gbm90aWZpY2F0aW9uIGRhdGEuDQoNCkkga25vdyB0aGF0IHRo aXMgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHNvbHV0aW9ucywgYnV0IEkgZG9u4oCZdCBz ZWUgaXQgbGlzdGVkIGFzIGEgcmVxdWlyZW1lbnQuICBUaGVyZSBpcyBhIHJlcXVpcmVtZW50IHRv IHJldHVybiB0aGUgZGlmZiwgYnV0IHRoYXTigJlzIGFsbC4gIElzIHRoZXJlIGFjdHVhbGx5IGEg bmVlZCB0byByZXR1cm4gYm90aCBzZXRzIG9mIGRhdGE/ICAtIG9yIGlzIHRoaXMganVzdCBhIGRl c2lyZSBmb3IgdGhlIGRpZmYgdG8gYmUgYWJsZSB0byByZXR1cm4gYm90aCAoYXMgb3Bwb3NlIHRv IHRoZSB0cmFuc2Zvcm0pPyAgSnVzdCB3b25kZXJpbmcgaWYgdGhpcyBpcyBhIG11c3QtaGF2ZSBv ciBhIG5pY2UtdG8taGF2ZS4NCg0KS2VudCAgDQoNCg0K From nobody Tue Feb 9 09:46:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D231ACD82 for ; Tue, 9 Feb 2016 09:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 EX1OXIYLH6m1 for ; Tue, 9 Feb 2016 09:46:10 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id D5FEB1ACD57 for ; Tue, 9 Feb 2016 09:46:09 -0800 (PST) Received: (qmail 15597 invoked by uid 0); 9 Feb 2016 17:46:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 9 Feb 2016 17:46:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id GQlt1s00m2SSUrH01QlwuN; Tue, 09 Feb 2016 17:46:06 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=2-FpkjFexY9gSDYXnxEA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=PYMHTacPZBTe9mlp2RaacqO/ZQzwT7b119gqEg2VFks=; b=Z3nkItlc+i+8ILIa5JT/syavH8oe7CQNJgjvn9aIMMRuUrQn0/Y3Sgo7r3GAPZgNKA5bLTmY9z3zEBuRyba6g2yobDpjIODENVreY8DH8jlDAdJK3ik2nou+UK1Fcmp7; Received: from box313.bluehost.com ([69.89.31.113]:47485 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aTCMN-0005SL-Ty; Tue, 09 Feb 2016 10:45:55 -0700 To: Kent Watsen , Robert Wilton , Martin Bjorklund References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> <56BA008E.5070102@cisco.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56BA25C8.4040802@labn.net> Date: Tue, 9 Feb 2016 12:45:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 17:46:11 -0000 Kent, On 2/9/2016 10:42 AM, Kent Watsen wrote: > > > >> Can you please suggest an approach of how to return a single tree that >> contains the data from two separate datastores (where the leaf paths may >> overlap)? I think that the approach would need to work both for get >> requests and also notification data. > I know that this is a difference between the solutions, but I don’t see it listed as a requirement. There is a requirement to return the diff, but that’s all. Is there actually a need to return both sets of data? - or is this just a desire for the diff to be able to return both (as oppose to the transform)? What I see is from draft-ietf-netmod-opstate-reqs C. Be able to retrieve both the applied configuration and derived state aspects of operational state together I see the original OpenConfig doc/approach as supporting this (returning both sets) but not stating this as an explicit requirement. I do think I've heard such usage in discussions too. > Just wondering if this is a must-have or a nice-to-have. I think this is one for Anees/Rob... Lou > Kent > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Feb 9 09:46:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F141C1ACD8B for ; Tue, 9 Feb 2016 09:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ixrgZOvtKulp for ; Tue, 9 Feb 2016 09:46:35 -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 955C51ACD57 for ; Tue, 9 Feb 2016 09:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1597; q=dns/txt; s=iport; t=1455039994; x=1456249594; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3lcaUNZ464ua6rfEsdu3DkIvQbdeOLWGEQ60Jvy1ntI=; b=MEqox7TgZzOTbR2y5uieIkRZSq/ajGzHCkaHuAwcXoQoyzUde3lFNys8 8vUmMgDmDlxx3mHe46/YvJ5raNzRc1qpE2IX9EMe+evtiem5bWx+UPg2H loQ5+yA2O8dRCi7Gaj0UiczB0+J+q6bXL+C+8vb1fwj+x7GdsGzONcL+0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABfJbpW/xbLJq1ejVWzEIYNAoFxE?= =?us-ascii?q?QEBAQEBAQGBCoRBAQEBAwEjDwEFQRALDgoCAgUhAgIPAkYGDQgBAReHeAiwIo5?= =?us-ascii?q?nAQEBAQEBAQEBAQEBAQEBAQEBGHuFF4Q3hzKBOgEElniNUIFbhEODAyOFL44/N?= =?us-ascii?q?iyDZDyJAQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,421,1449532800"; d="scan'208";a="632474368" 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; 09 Feb 2016 17:46:32 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u19HkWXY032330; Tue, 9 Feb 2016 17:46:32 GMT To: Kent Watsen References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> <56BA008E.5070102@cisco.com> From: Robert Wilton Message-ID: <56BA25F8.50709@cisco.com> Date: Tue, 9 Feb 2016 17:46:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.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] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 17:46:36 -0000 On 09/02/2016 15:42, Kent Watsen wrote: > > > >> Can you please suggest an approach of how to return a single tree that >> contains the data from two separate datastores (where the leaf paths may >> overlap)? I think that the approach would need to work both for get >> requests and also notification data. > I know that this is a difference between the solutions, but I don’t see it listed as a requirement. There is a requirement to return the diff, but that’s all. Is there actually a need to return both sets of data? - or is this just a desire for the diff to be able to return both (as oppose to the transform)? Just wondering if this is a must-have or a nice-to-have. My desire is to find a overall solution that from a client usability perspective is on a par with the OpenConfig models. At the moment, my understanding is that the OpenConfig operators don't have a need (or desire) to use datastores. I'm probably wrong, but personally I think that for any datastore solution to really be viable the use of those datastores needs to be made as seamless as possible for the clients. However, I still think that an encoding/protocol based solution has the opportunity to provide a solution that from a client perspective feels similar to the OpenConfig models, but has the additional benefit that it doesn't force all the YANG models to have the intended/applied config split, and arguably has the benefit that the source YANG models are easier to read than the grouping approach used in the OpenConfig models. Rob > > Kent > > From nobody Tue Feb 9 12:54:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC631AD36A for ; Tue, 9 Feb 2016 12:54: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, 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 ZNrqBJWIilOW for ; Tue, 9 Feb 2016 12:54:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6031AD364 for ; Tue, 9 Feb 2016 12:54:37 -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.403.16; Tue, 9 Feb 2016 20:54:20 +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.0403.017; Tue, 9 Feb 2016 20:54:20 +0000 From: Kent Watsen To: Lou Berger , Robert Wilton , "Martin Bjorklund" Thread-Topic: [netmod] a few comments on draft-wilton-netmod-opstate-yang Thread-Index: AQHRX5vj8n48Wc8D1kOhd6Pt2B8rSJ8dNgaAgAAFZYCAACWFAIAAzhoAgAP5FgCAAAa2gIAAGwYAgABIUwCAABvZAIAABKoAgAElGwD//7YoAIAAdjkA///g3gA= Date: Tue, 9 Feb 2016 20:54:20 +0000 Message-ID: References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> <56BA008E.5070102@cisco.com> <56BA25C8.4040802@labn.net> In-Reply-To: <56BA25C8.4040802@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:K7jtIdW1DJ2ApvvYadY32UPgfBhf0U5yjRMy0qYY6vzjeHrjmMvid9BKR5fH8bYgv2BUp3GeUTl+xXq8lrCHFdnXfh00utSLGULHJSE+2pS3TgbQcxNi3kI34EbLU7/OdKZBXkXtocJmqsl0OcBDzA==; 24:LVS7f3jK31+DRaeZVk1bnSzS796BGGEHsFSFkCgEabCO6yksxXx7h+Pg8GdpsnNtsGd1bYxROieq7fkSPQvr2NRbu7kQd6riinhNL8dzHAY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 848bc794-6944-4654-bae7-08d331932ed8 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)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54094003)(1220700001)(1096002)(11100500001)(189998001)(5004730100002)(86362001)(3846002)(102836003)(93886004)(10400500002)(99286002)(2906002)(230783001)(4326007)(33656002)(2900100001)(40100003)(5002640100001)(82746002)(4001350100001)(122556002)(87936001)(6116002)(5001770100001)(66066001)(2950100001)(3280700002)(77096005)(50986999)(92566002)(5001960100002)(3660700001)(586003)(5008740100001)(83506001)(83716003)(76176999)(54356999)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <86FCBC0CD035D741BEFF3DE568A7CA99@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2016 20:54:20.4031 (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@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Tue, 09 Feb 2016 20:54:40 -0000 DQpIaSBMb3UsIA0KDQoNCg0KDQoNCg0KPj4+SSBrbm93IHRoYXQgdGhpcyBpcyBhIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGUgc29sdXRpb25zLCBidXQgSSBkb27igJl0IHNlZSBpdCBsaXN0ZWQgYXMg YSByZXF1aXJlbWVudC4gIFRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdG8gcmV0dXJuIHRoZSBkaWZm LCBidXQgdGhhdOKAmXMgYWxsLiAgSXMgdGhlcmUgYWN0dWFsbHkgYSBuZWVkIHRvIHJldHVybiBi b3RoIHNldHMgb2YgZGF0YT8gIC0gb3IgaXMgdGhpcyBqdXN0IGEgZGVzaXJlIGZvciB0aGUgZGlm ZiB0byBiZSBhYmxlIHRvIHJldHVybiBib3RoIChhcyBvcHBvc2UgdG8gdGhlIHRyYW5zZm9ybSk/ DQo+V2hhdCBJIHNlZSBpcyBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcw0KPg0K PiAgICAgICBDLiAgQmUgYWJsZSB0byByZXRyaWV2ZSBib3RoIHRoZSBhcHBsaWVkIGNvbmZpZ3Vy YXRpb24gYW5kDQo+ICAgICAgICAgICBkZXJpdmVkIHN0YXRlIGFzcGVjdHMgb2Ygb3BlcmF0aW9u YWwgc3RhdGUgdG9nZXRoZXINCg0KTWF5YmUgSeKAmW0gdHVybmVkIGFyb3VuZCwgYnV0IEkgdGhv dWdodCB0aGlzIHdhcyBhYm91dCByZXR1cm5pbmcgYm90aCBpbnRlbmRlZCBhbmQgYXBwbGllZCBj b25maWd1cmF0aW9ucyB0b2dldGhlciBhdCB0aGUgc2FtZSB0aW1lLCB3aGljaCBJIGRpZG7igJl0 IGtub3cgd2FzIGEgcmVxdWlyZW1lbnQuICAgQ2VydGFpbmx5IHJldHVybmluZyBhcHBsaWVkIGNv bmZpZyArIGRlcml2ZWQgc3RhdGUgKGUuZy4sIGFsbCBvcCBzdGF0ZSkgaXMgYSByZXF1aXJlbWVu dCwgYXMgeW91IGNpdGUgYWJvdmUuDQoNCg0KPkkgc2VlIHRoZSBvcmlnaW5hbCBPcGVuQ29uZmln IGRvYy9hcHByb2FjaCBhcyBzdXBwb3J0aW5nIHRoaXMgKHJldHVybmluZw0KPmJvdGggc2V0cykg YnV0IG5vdCBzdGF0aW5nIHRoaXMgYXMgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQuICBJIGRvIHRo aW5rDQo+SSd2ZSBoZWFyZCBzdWNoIHVzYWdlIGluIGRpc2N1c3Npb25zIHRvby4NCg0KWWVzLCBh Y3R1YWxseSwgdGhleSByZXR1cm5lZCBhbGwgdGhyZWUgc2V0cyBvZiBkYXRhIChpbnRlbmRlZCBj b25maWcsIGFwcGxpZWQgY29uZmlnLCBhbmQgZGVyaXZlZCBzdGF0ZSkNCg0KDQo+PiAgSnVzdCB3 b25kZXJpbmcgaWYgdGhpcyBpcyBhIG11c3QtaGF2ZSBvciBhIG5pY2UtdG8taGF2ZS4NCj5JIHRo aW5rIHRoaXMgaXMgb25lIGZvciBBbmVlcy9Sb2IuLi4NCg0KSXQgd291bGQgYmUgZ29vZCB0byBn ZXQgdGhhdCBjbGFyaWZpY2F0aW9uLiAgIEkgd29uZGVyIGlmIGl0IG1pZ2h0IGJlIGNvbnNpZGVy ZWQgIGVycmF0YSAgOykNCg0KDQpLZW50DQoNCg0KDQo= From nobody Wed Feb 10 03:43:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1E91A1BCF for ; Wed, 10 Feb 2016 03:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 DlxyrkXyZsKV for ; Wed, 10 Feb 2016 03:43:46 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id DFB8E1A1BCD for ; Wed, 10 Feb 2016 03:43:45 -0800 (PST) Received: (qmail 13582 invoked by uid 0); 10 Feb 2016 11:43:42 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 10 Feb 2016 11:43:42 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id GbjS1s00V2SSUrH01bjVjM; Wed, 10 Feb 2016 04:43:42 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=OUXY8nFuAAAA:8 a=GkhI961uOO8Be3uXboQA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=QpdMsYIE3EiwybFCP2HqrfwrqKcrJ+mvowDpvjZm6EU=; b=sjv8/PRTRJIWBx2hkLeTD6yo6ORY1TyB6ne2Lx4EL2mp3nTDcHCCapw+/1Wg/bKHZfUvzVXskKGjMCD6IVrhaTLbdmgCpQtAeAp/lzUkOdQ7XrXGwqjrQadTgsS3Nqfj; Received: from [100.15.91.238] (port=59062 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aTTB8-0000o9-50; Wed, 10 Feb 2016 04:43:26 -0700 From: Lou Berger To: Kent Watsen , Robert Wilton , Martin Bjorklund Date: Wed, 10 Feb 2016 06:43:21 -0500 Message-ID: <152cafe27c0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <56B8B2BC.9050809@cisco.com> <20160208.204128.275969700916546426.mbj@tail-f.com> <56B906C4.1020307@cisco.com> <20160208.223750.1590868900898520013.mbj@tail-f.com> <56BA008E.5070102@cisco.com> <56BA25C8.4040802@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Wed, 10 Feb 2016 11:43:47 -0000 Kent, Thanks for the response see below. On February 9, 2016 3:54:41 PM Kent Watsen wrote: > > Hi Lou, > > > > > > >>>>I know that this is a difference between the solutions, but I don’t see it >>>>listed as a requirement. There is a requirement to return the diff, but >>>>that’s all. Is there actually a need to return both sets of data? - or is >>>>this just a desire for the diff to be able to return both (as oppose to the >>>>transform)? >>What I see is from draft-ietf-netmod-opstate-reqs >> >> C. Be able to retrieve both the applied configuration and >> derived state aspects of operational state together > > Maybe I’m turned around, but I thought this was about returning both > intended and applied configurations together at the same time, which I > didn’t know was a requirement. Certainly returning applied config + > derived state (e.g., all op state) is a requirement, as you cite above. > You're headed the right way. Was just pointing out what is in the requirement document. > >>I see the original OpenConfig doc/approach as supporting this (returning >>both sets) but not stating this as an explicit requirement. I do think >>I've heard such usage in discussions too. > > Yes, actually, they returned all three sets of data (intended config, > applied config, and derived state) > > >>> Just wondering if this is a must-have or a nice-to-have. >>I think this is one for Anees/Rob... > > It would be good to get that clarification. Agreed. Lou > I wonder if it might be considered errata ;) > > > Kent > > > From nobody Wed Feb 10 04:09:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B2C1A1F70 for ; Wed, 10 Feb 2016 04:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 ubp4wWeMGZZO for ; Wed, 10 Feb 2016 04:09:31 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 7300B1A1EFB for ; Wed, 10 Feb 2016 04:09:31 -0800 (PST) Received: (qmail 19175 invoked by uid 0); 10 Feb 2016 12:09:30 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 10 Feb 2016 12:09:30 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Gc9G1s0022SSUrH01c9KMC; Wed, 10 Feb 2016 05:09:29 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=tpST5vRIyVf3vv0l8nEA:9 a=CjuIK1q_8ugA:10 a=0HLvWxXWz39KVGujPMkA:9 a=OmgYTCf1Zc-5H-9K:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=xiylh4TvjALvjKwJoRlSOv3n+AnMDhp8aRA7ALMYjBc=; b=nVOtbtFsTN9rq40WLc4uwLH728SOaKIY/3jI+o5sgmNe4xO19x1aJ3V7/m3eDWiHQgOyqROgP8t51P1aWKKhgnRq4SkYenn+RdJNPyAaOr5FdMbKDJnFO07zgPsjYMJ9; Received: from [100.15.91.238] (port=59177 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aTTa8-0005U2-Vr; Wed, 10 Feb 2016 05:09:17 -0700 From: Lou Berger To: Andy Bierman Date: Wed, 10 Feb 2016 07:09:11 -0500 Message-ID: <152cb15d258.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <56B8D6D5.1000100@labn.net> <20160208.195757.1790485716725797319.mbj@tail-f.com> <56B8F244.7090802@labn.net> <20160208.214252.1620925752565182152.mbj@tail-f.com> <56B8FF19.4040607@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------152cb15d6001b97281843060250" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org, draft-kwatsen-netmod-opstate@ietf.org, draft-openconfig-netmod-opstate@ietf.org Subject: Re: [netmod] OpState Solution Options 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, 10 Feb 2016 12:09:33 -0000 This is a multi-part message in MIME format. ------------152cb15d6001b97281843060250 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On February 8, 2016 3:58:59 PM Andy Bierman wrote: > Hi, > > It should be up to the co-chairs to make consensus calls. 100% agree. > The IETF 94 minutes indicate that "solution 2" (RPC-based) > had consensus in the room. I don't see a consensus call/decision in the minutes, nor one made on the list. I suspect you (and others) might find rfc7282 a bit surprising, and certainly worth the read if trying to understand the meaning of a hum and census in the ietf context. > > https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html > > I have not seen any evidence that room consensus has changed on the mailing > list. I take both Kent's mail and Benoit's earlier mail as pretty strong indicators that we don't have a declared consensus of the Working Group. In my earlier mail I was basically suggesting that rather than taking the beauty contest approach, that we as a working group see if there is some middle ground solution that combines the best of all options being discussed. I did suggest looking at this as a modification of 3, but perhaps a better way of phrasing it would be calling it 2.5 or perhaps even 6 - -- as in the sum of all. Lou > > > Andy > > > > On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger wrote: > >> [retry] >> >> Martin, >> >> >> On 2/8/2016 3:42 PM, Martin Bjorklund wrote: >> > Lou Berger wrote: >> >> Martin, >> >> Thanks for the response. See below. >> >> >> >> On 2/8/2016 1:57 PM, Martin Bjorklund wrote: >> >>> Hi, >> >>> >> >>> Lou Berger wrote: >> > [...] >> > >> >>>> But it's >> >>>> also clear that some in the WG would prefer Option 2 (and most/all of >> >>>> these are its coauthors.) >> >>> This was the preferred solution of the room in Yokohama. 2 of the 4 >> >>> authors were present. >> >> sure. And we know that the IETF consensus is not judged by who is in >> >> the room. It is of course useful information to the WG and the chairs. >> > You wrote "most/all of [those who prefer option 2] are its coauthors". >> I was referring to the on-list discussion, but fair point. But keep in >> mind that an in-person meeting isn't an authoritative source of WG >> consensus from the IETF process standpoint. >> >> > My observation was that just 2 of the coauthors were in the room, and >> > still this was the preferred solution; thus I think that your >> > statement that I quoted is incorrect. >> > >> okay, let me modify my comment: >> OLD >> and most/all of these are its coauthors >> NEW >> at very least its coauthors >> >> Lou >> >> > /martin >> > >> >> >> ------------152cb15d6001b97281843060250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Hi Andy,

On February 8, 2016 3:58:59 PM Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>
> It should be up to the co-chairs to make consensus calls.

100% agree.

> The IETF 94 minutes indicate that "solution 2" (RPC-based)
> had consensus in the room.

I don't see a consensus call/decision in the minutes, nor one made on the list.

I suspect you (and others) might find rfc7282 a bit surprising, and certainly worth the read if trying to understand the meaning of a hum and census in the ietf context.

>
> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html
>
> I have not seen any evidence that room consensus has changed on the mailing
> list.

I take both Kent's  mail and Benoit's earlier mail as pretty strong indicators that we don't have a declared consensus of the Working Group.

In my earlier mail I was basically suggesting that rather than taking the beauty contest approach, that we as a working group see if there is some middle ground solution that combines the best of all options being discussed. I did suggest looking at this as a modification of 3, but perhaps a better way of phrasing it would be calling  it 2.5 or perhaps even 6 - -- as in the sum of all.

Lou
>
>
> Andy
>
>
>
> On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger <lberger@labn.net> wrote:
>
>> [retry]
>>
>> Martin,
>>
>>
>> On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
>> > Lou Berger <lberger@labn.net> wrote:
>> >> Martin,
>> >>     Thanks for the response.  See below.
>> >>
>> >> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
>> >>> Hi,
>> >>>
>> >>> Lou Berger <lberger@labn.net> wrote:
>> > [...]
>> >
>> >>>> But it's
>> >>>> also clear that some in the WG would prefer Option 2 (and most/all of
>> >>>> these are its coauthors.)
>> >>> This was the preferred solution of the room in Yokohama.  2 of the 4
>> >>> authors were present.
>> >> sure.  And we know that the IETF consensus is not judged by who is in
>> >> the room.  It is of course useful information to the WG and the chairs.
>> > You wrote "most/all of [those who prefer option 2] are its coauthors".
>> I was referring to the on-list discussion, but fair point.  But keep in
>> mind that an in-person meeting isn't an authoritative source of WG
>> consensus from the IETF process standpoint.
>>
>> > My observation was that just 2 of the coauthors were in the room, and
>> > still this was the preferred solution; thus I think that your
>> > statement that I quoted is incorrect.
>> >
>> okay, let me modify my comment:
>> OLD
>> and most/all of these are its coauthors
>> NEW
>> at very least its coauthors
>>
>> Lou
>>
>> > /martin
>> >
>>
>>
>>

------------152cb15d6001b97281843060250-- From nobody Wed Feb 10 04:42:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40C91A8821 for ; Wed, 10 Feb 2016 04:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pXx2KbSRZWwD for ; Wed, 10 Feb 2016 04:42:51 -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 A3BF11A8833 for ; Wed, 10 Feb 2016 04:42:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2765E11D2; Wed, 10 Feb 2016 13:42:49 +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 KLlCEsTBhXFe; Wed, 10 Feb 2016 13:42:47 +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, 10 Feb 2016 13:42:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7EE520035; Wed, 10 Feb 2016 13:42:47 +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 9oljxZeASzoq; Wed, 10 Feb 2016 13:42:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31C5C2002B; Wed, 10 Feb 2016 13:42:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4A88B39E318B; Wed, 10 Feb 2016 13:42:47 +0100 (CET) Date: Wed, 10 Feb 2016 13:42:47 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160210124247.GA52549@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208163123.GB29638@elstar.local> <56B8C97E.7050303@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B8C97E.7050303@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 10 Feb 2016 12:42:53 -0000 On Mon, Feb 08, 2016 at 04:59:42PM +0000, Robert Wilton wrote: > >So if in my 1 million XML elements one has not been applied, how do I > >find out efficiently in your encoding? > By using 'diff-cfg-only' option of the parameter, > you would get 3 or 4 leaves per mismatching node: (intended value, > applied value, status, and optionally error reason). Only nodes with > differences would be returned. > > A more complete example is in > https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2. > NETCONF get-config request using with-config-state with diff-cfg-only > option", about page 16. > > Yes, this data would be larger than the patch, but it also contains more > information (i.e. reason why they differ, and error string). > OK. Next question: How do I get the diff between and ? How do I get the diff between and ? We can try to build generic primitives or we can choose to create many point solutions. > The client is also able to process this data straight away. With the > patch, they may need to generate the before and after values to make it > easier to process. I fail to get the message, what is easier to process for a client is largely subjective or a function of the particular client environment or what I want to do with the data. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 10 04:51:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F021A8860 for ; Wed, 10 Feb 2016 04:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 J9g95FXndeeJ for ; Wed, 10 Feb 2016 04:51: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 481991A8863 for ; Wed, 10 Feb 2016 04:51: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 1589A131E; Wed, 10 Feb 2016 13:51:32 +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 fGenCV9JbZNz; Wed, 10 Feb 2016 13:51: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; Wed, 10 Feb 2016 13:51:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6BFF20031; Wed, 10 Feb 2016 13:51:30 +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 fMt9dlKAtNtK; Wed, 10 Feb 2016 13:51: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 855392002B; Wed, 10 Feb 2016 13:51:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9EAB939E31BB; Wed, 10 Feb 2016 13:51:29 +0100 (CET) Date: Wed, 10 Feb 2016 13:51:29 +0100 From: Juergen Schoenwaelder To: Gert Grammel Message-ID: <20160210125129.GB52549@elstar.local> Mail-Followup-To: Gert Grammel , Robert Wilton , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 10 Feb 2016 12:51:35 -0000 On Mon, Feb 08, 2016 at 05:50:00PM +0000, Gert Grammel wrote: > Hi Juergen, > > I think the indentation in our emails play havoc which is confusing me > too. The key point I am making is: > > The mapping of what is called intended-config onto data stores would > deserve more detailed discussion. It seems the authors of > draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg > with the [running] datastore. In my understanding, a failure in applying > [running] to [applied] will update the [running] datastore to reflect > which part is effectively applied. So a fair representation of that case > would be: > [candidate] -> [running] <--> [applied] -> derived state This is not how I understood that state of the discussions. I do not think that the NETCONF configuration datastore changes in existing implementations dynamically. Does it on Junos? > In the context of intended-configuration however that doesn’t make sense > to me. A failure in applying intended configuration doesn¹t change the > intention and the delta between intended and applied-config is the key > value. A server that would "clean-up" intended-cfg in presence of a > failure to apply would look picture perfect instead of exposing the > problem clearly. Hence the sequence should more look like: > [candidate] -> [intended] ‹-> [running==applied] -> derived state > > Whatever we choose, I believe we need to spell out what¹s the data in a > failure case. It¹s probably a bit late to update the requirements draft, > but we can probably find a suitable place. > > ——— > > > I am also wondring if we have the same understanding related to the > following statement: > I thought the whole point of having an applied config is to be able to > see the difference between intended (oops running) and applied. > > > The current draft-kwatsen-netmod-opstate-02.txt says: > "Any rollback that may occur will restore both the intended and the > applied configurations to their previous states." This rollback requirement is in my view broken (I assume people will figure this out when they try to implement solutions for it). Anyway, NETCONF today commits to and I do not think we should mess around with that. > The challenge I have is the term “(oops running)” in the first sentence in > combination with the citation. I reckon that any difference between > intended-config and applied-config shall be visible whereby the > intended-config is provided by the client and never altered by the server. > Applied-config on the other hand represents the state of the server. If a > failure happens in the application phase, it shall be treated accordingly > (rollback-, stop-, continue-on-error). As a result the difference between > intended and applied configuration shall be maintained. > So does this square with the notion "intended=running" and “applied” > config? Yes (with the caveat that the rollback requirement text is kind of broken). /js > - Gert > > > > > > On 2016-08-02 17:38, "Juergen Schoenwaelder" > wrote: > > >On Mon, Feb 08, 2016 at 02:53:57PM +0000, Gert Grammel wrote: > >> > >> > >> >This is not what is being proposed. We always had > >> > > >> >[candidate] -> [running] -> operational state > >> > > >> >(and I mark configuration data stores in []). Both [candidate] and > >> >[running] have the same configuration data model. Now we are asked > >> >to expose that [running] may not be applied synchronously and hence > >> > > >> >[candidate] -> [running] -> [applied] -> derived state > >> > > >> >seems to make sense. > > > >Why would that be the case? If I configure an interface that is not > >currently present today in running this is just find and running is > >not expected to change arbitrarily. > > > >> The mapping of what is called intended-config onto data stores would > >> deserve more detailed discussion. It seems the authors of this draft had > >> in mind to associate intended-cfg with the [running] datastore. With > >>that > >> mapping, a failure in applying [running] to [applied] will update the > >> [running] datastore to reflect which part is effectively applied. So a > >> fair representation of that case would be: > >> [candidate] -> [running] <--> [applied] -> derived state > > > >What is 'this draft'? I thought the whole point of having an applied > >config is to be able to see the difference between intended (oops > >running) and applied. I am confused now. > > > >> In the context of intended configuration however that doesn¹t make sense > >> to me. A failure in applying intended configuration doesn¹t change the > >> intention and the delta between intended and applied-config is the key > >> value. A server that would "clean-up² intended-cfg in presence of a > >> failure to apply would look picture perfect instead of exposing the > >> problem clearly. Hence the sequence should more look like: > >> [candidate] -> [intended] ‹> [running==applied] -> derived state > >> > >> Whatever we choose, I believe we need to spell out what¹s the data in a > >> failure case. It¹s probably a bit late to update the requirements draft, > >> but we can probably find a suitable place. > > > >There is apparently much less agreement on what the problem is, what > >the terms mean, and how they related to existing technology than I > >thought. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 10 05:29:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC51B2AA4 for ; Wed, 10 Feb 2016 05:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 R9CLErzndbuX for ; Wed, 10 Feb 2016 05:29:26 -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 90D321B2A9E for ; Wed, 10 Feb 2016 05:29: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 5432F1237; Wed, 10 Feb 2016 14:29: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 HUqtRmWaB7lM; Wed, 10 Feb 2016 14:29: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; Wed, 10 Feb 2016 14:29:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C3732002C; Wed, 10 Feb 2016 14:29:24 +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 vptNVUlHgvmr; Wed, 10 Feb 2016 14:29:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADF442002B; Wed, 10 Feb 2016 14:29:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C476239E32B1; Wed, 10 Feb 2016 14:29:23 +0100 (CET) Date: Wed, 10 Feb 2016 14:29:23 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160210132923.GC52549@elstar.local> Mail-Followup-To: Robert Wilton , Andy Bierman , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B9CAB9.5050402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B9CAB9.5050402@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Wed, 10 Feb 2016 13:29:28 -0000 On Tue, Feb 09, 2016 at 11:17:13AM +0000, Robert Wilton wrote: > > > On 08/02/2016 16:20, Juergen Schoenwaelder wrote: > >On Mon, Feb 08, 2016 at 01:21:52PM +0000, Robert Wilton wrote: > >>So, IIRC, your concern is specifically that a generic YANG client > >>library cannot validate that the RPC reply is well formed against the > >>schema without knowledge about the request. Is that correct? > >> > >None of the existing tools that assume YANG defined data is XML > >encoded according to RFC 6020 will not be able to process data in a > >new encoding. > OK. > > As Lou indicates, the proposed protocol schema encoding could also be > generated by tooling (i.e. a pyang plugin). > > I.e. a client can take the source YANG models (e.g. as defined by IETF) > and apply a transformation to them that would generate a set of YANG > models that are the same except that they have the extra applied > configuration nodes added to them. > > An opstate aware client could use the generated YANG models to both > internally manage the manageability data, and also to validate that the > messages sent to/from the server conform with the extended schema. > I fail to see how on the fly schema translations makes things simpler (and I am sure there are a number of little questions that pop up if you really do this). I am still waiting for the argument that convinces me that merging datastores into a single tree makes the writing of clients orders of magnitude simpler. If the only real technical argument is "I need to be able to retrieve data from multiple datastores in a single RPC operation", then lets simply define such an RPC (that works for arbitrary combinations of datastores and not just two specific ones) and move on. If the problem is in the existing RPC primitives, then lets extend them instead of building hacks around them using on the fly schema translations and what not. /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 Feb 10 05:52:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7DB1A886F for ; Wed, 10 Feb 2016 05:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 p0KT6GN71UT7 for ; Wed, 10 Feb 2016 05:51:57 -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 305B41A8A9B for ; Wed, 10 Feb 2016 05:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3761; q=dns/txt; s=iport; t=1455112317; x=1456321917; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=AbVsiZQ/E+JIt6FXKkMA4j2kZ+BLir6+oEaT5nuyXhk=; b=KR/wIrHQWuZ9B+eVJRK9FgXpk3k/L2dkIgsTi0aWCRBNRGiqbTIXsC5q 8LzjVQnDvoZgXamXmlYHPrP1pqlOaca8TeHEORVrMnVoGq9QGhatwN4rT KxYq4qc1xXjyk3EbRs0ytkSRN8ISa7owhAy3e4/XgswPlAKrf6pPy6NAO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDDP7tW/xbLJq1ehAyJSbEgAQ2BZ?= =?us-ascii?q?iGFbAKBcxQBAQEBAQEBfwuEQQEBAQMBJxFAEQsYCRYPCQMCAQIBRQYNCAEBF4d?= =?us-ascii?q?4CA7ABAEBAQEBAQEBAQEBAQEBAQEBARQEhhKEN4hsAQSWeIVMiAWBXIRDgwMjh?= =?us-ascii?q?S+KbYNSHgEBQoNkPIkBAQEB?= X-IronPort-AV: E=Sophos;i="5.22,426,1449532800"; d="scan'208";a="632524249" 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; 10 Feb 2016 13:51:54 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1ADpsaH002811 for ; Wed, 10 Feb 2016 13:51:54 GMT To: "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208163123.GB29638@elstar.local> <56B8C97E.7050303@cisco.com> <20160210124247.GA52549@elstar.local> From: Robert Wilton Message-ID: <56BB407A.1050906@cisco.com> Date: Wed, 10 Feb 2016 13:51:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210124247.GA52549@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Wed, 10 Feb 2016 13:52:00 -0000 On 10/02/2016 12:42, Juergen Schoenwaelder wrote: > On Mon, Feb 08, 2016 at 04:59:42PM +0000, Robert Wilton wrote: > >>> So if in my 1 million XML elements one has not been applied, how do I >>> find out efficiently in your encoding? >> By using 'diff-cfg-only' option of the parameter, >> you would get 3 or 4 leaves per mismatching node: (intended value, >> applied value, status, and optionally error reason). Only nodes with >> differences would be returned. >> >> A more complete example is in >> https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2. >> NETCONF get-config request using with-config-state with diff-cfg-only >> option", about page 16. >> >> Yes, this data would be larger than the patch, but it also contains more >> information (i.e. reason why they differ, and error string). >> > OK. Next question: How do I get the diff between and > ? How do I get the diff between and ? > We can try to build generic primitives or we can choose to create many > point solutions. I think that this is effectively the same question that I asked Martin, i.e. "Can you please suggest an approach of how to return a single tree that contains the data from two separate datastores (where the leaf paths may overlap)? I think that the approach would need to work both for get requests and also notification data. " > >> The client is also able to process this data straight away. With the >> patch, they may need to generate the before and after values to make it >> easier to process. > I fail to get the message, what is easier to process for a client is > largely subjective or a function of the particular client environment > or what I want to do with the data. What is easier to read: - a diff that only gives you the new value and the context, or - a diff that gives you both the old and new values? Here is a hypothetical C example: 1) A diff with just the new context: *************** *** 3112,3118 **** caps_vft->caps_unbuilder_func = dot1q_unbuilder; caps_vft->caps_control_func = dot1q_control; ! caps_vft->caps_upgrade_func = dot1q_upgrade; ! caps_vft->caps_terminate_func = dot1q_terminate; 2) The same diff with both old and new context: *************** *** 3112,3118 **** caps_vft->caps_unbuilder_func = dot1q_unbuilder; caps_vft->caps_control_func = dot1q_control; ! caps_vft->caps_upgrade_func = dot1q_terminate; ! caps_vft->caps_terminate_func = dot1q_upgrade; --- 3115,3121 ---- caps_vft->caps_unbuilder_func = dot1q_unbuilder; caps_vft->caps_control_func = dot1q_control; ! caps_vft->caps_upgrade_func = dot1q_upgrade; ! caps_vft->caps_terminate_func = dot1q_terminate; In the latter case, it is easy to see what the change is. In the former case you would need to understand what the code was previously to understand the change. In the latter case, if you don't care what the old value was, then that is fine it can just be ignored. So the point that I'm trying to make is that the YANG Patch format is broadly equivalent to the former example. Yes, it strictly meets the requirement draft to return a comparison between the two datasets, but in a way that I perceive is not as easy or flexible for the client as if both the old and new values had been provided. If there was a way that YANG patch (or equivalent) were able to return both old and new values (in the same tree) then I think that would be better. I don't think that such as solution would be specific to the opstate requirements and may be useful more generally. Rob > > /js > From nobody Wed Feb 10 07:11:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2631B2BBC for ; Wed, 10 Feb 2016 07:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 hcsZDXzPjj06 for ; Wed, 10 Feb 2016 07:11:13 -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 AE0731B2BBA for ; Wed, 10 Feb 2016 07:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3299; q=dns/txt; s=iport; t=1455117072; x=1456326672; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=5qMC+UFVuOLyU+U5iR7RjfZKn+dGnTGC08lxCkZkOW4=; b=K57VuiyCkt4Q5evzUkACz7L7o81bmGi49wChe/mlc4e5C5BFObixt9Fn 091qmpn4P4juMpznH1blIcLGGbUSu83hBDkhCqKg67CrBWJ9hiDkfqWui GThjIxWC2SrSMz1H0Pg+XG2LnputUOluFzWrkub0kIhLyIP8osk6O1cpL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCLUrtW/xbLJq1ejVWxIAENgWaGD?= =?us-ascii?q?QKBchQBAQEBAQEBfwuEQQEBAQMBOEAGCwsYCRYPCQMCAQIBRQYNCAEBF4d4CMA?= =?us-ascii?q?wAQEBAQEBBAEBAQEBG4YSgzx7hBqEUgEElniNUYFch0aFUoptg1IeAQFCg2Q8h?= =?us-ascii?q?0olgRIBAQE?= X-IronPort-AV: E=Sophos;i="5.22,426,1449532800"; d="scan'208";a="632528350" 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; 10 Feb 2016 15:11:09 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1AFB9vd007219 for ; Wed, 10 Feb 2016 15:11:09 GMT To: "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B9CAB9.5050402@cisco.com> <20160210132923.GC52549@elstar.local> From: Robert Wilton Message-ID: <56BB530C.4060603@cisco.com> Date: Wed, 10 Feb 2016 15:11:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210132923.GC52549@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Wed, 10 Feb 2016 15:11:15 -0000 On 10/02/2016 13:29, Juergen Schoenwaelder wrote: > On Tue, Feb 09, 2016 at 11:17:13AM +0000, Robert Wilton wrote: >> >> On 08/02/2016 16:20, Juergen Schoenwaelder wrote: >>> On Mon, Feb 08, 2016 at 01:21:52PM +0000, Robert Wilton wrote: >>>> So, IIRC, your concern is specifically that a generic YANG client >>>> library cannot validate that the RPC reply is well formed against the >>>> schema without knowledge about the request. Is that correct? >>>> >>> None of the existing tools that assume YANG defined data is XML >>> encoded according to RFC 6020 will not be able to process data in a >>> new encoding. >> OK. >> >> As Lou indicates, the proposed protocol schema encoding could also be >> generated by tooling (i.e. a pyang plugin). >> >> I.e. a client can take the source YANG models (e.g. as defined by IETF) >> and apply a transformation to them that would generate a set of YANG >> models that are the same except that they have the extra applied >> configuration nodes added to them. >> >> An opstate aware client could use the generated YANG models to both >> internally manage the manageability data, and also to validate that the >> messages sent to/from the server conform with the extended schema. >> > I fail to see how on the fly schema translations makes things simpler > (and I am sure there are a number of little questions that pop up if > you really do this). > > I am still waiting for the argument that convinces me that merging > datastores into a single tree makes the writing of clients orders of > magnitude simpler. I cannot present such an argument that a protocol based solution is orders of magnitude better than using multiple datastores. But I wonder whether the OpenConfig operators might also ask the WG the same question of whether a datastore solution is orders of magnitude better than the OpenConfig solution? My best guess is that at the moment they would regard a datastore solution as being inferior to their current working solution (for which they have models that are further ahead than IETF, running code, some major vendors committed to implementing those models, and seeming more interest from the large network operators in using those models). Will vendors actually implement a datastore based solution if the OpenConfig operators (who are raising the requirement) don't actually want/need to use it? Then I guess the final question I have is whether SDO produced models will still be relevant if they lag 2 years behind the OpenConfig models, and those models have become a defacto standard? > If the only real technical argument is "I need to > be able to retrieve data from multiple datastores in a single RPC > operation", then lets simply define such an RPC (that works for > arbitrary combinations of datastores and not just two specific ones) > and move on. If the problem is in the existing RPC primitives, then > lets extend them instead of building hacks around them using on the > fly schema translations and what not. I've already stated what I perceive are the client warts with data stores. Martin has commented on some of those. Alas, I doubt that you would find them any more compelling if I restate them again. Rob > > /js > From nobody Wed Feb 10 07:46:26 2016 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 7D5801B2C0E; Wed, 10 Feb 2016 07:46:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> Date: Wed, 10 Feb 2016 07:46:24 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 15:46:24 -0000 The NETCONF Data Modeling Language (NETMOD) WG will have a virtual interim meeting on 22 February 2016 at 10:00 EST (15:00 UTC) to discuss use-cases and solutions for combining YANG modules into the schema defined in other YANG modules, as this is a blocking item for some other working groups currently. The agenda for the meeting is: 5 min: agenda bashing, scribes, note well, etherpad, etc. 20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02) 20 min: proposal #1 (draft-lhotka-netmod-ysdl-00) 20 min: proposal #2 (draft-bjorklund-netmod-structural-mount-00) 55 min: general discussion or end early All participants should come prepared to discuss these drafts. Note: it is understood that draft-clemm-netmod-mount is related work, but the chairs wish to only focus on the schema composition issue at this time. Etherpad: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 Regards, NETMOD Chairs -- NETMOD Virtual Interim Meeting Monday, February 22, 2016 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=me171803d3dfe83d3f0d003f8332b032f Meeting number: 646 684 956 Meeting password: Qbds3nPZ Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 684 956 Toll-free calling restrictions Add this meeting to your calendar. (Cannot add from mobile devices.) https://ietf.webex.com/ietf/j.php?MTID=mf4e7a67f2b45f6542947fa3464d35e05 Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Wed Feb 10 07:47:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFFE1B2C53 for ; Wed, 10 Feb 2016 07:47: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 VnuntxOoTjUd for ; Wed, 10 Feb 2016 07:47:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B331B2C42 for ; Wed, 10 Feb 2016 07:47:01 -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.403.16; Wed, 10 Feb 2016 15:46:39 +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.0403.017; Wed, 10 Feb 2016 15:46:39 +0000 From: Kent Watsen To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRXeLKOW+rjqCc7kiS321+Ltbrbp8dt6+AgAADfQCABHKuAIAAMqyAgAAH6QCAAtzhgIAAE1AA///MPQA= Date: Wed, 10 Feb 2016 15:46:38 +0000 Message-ID: <694E6309-813D-4DBE-A355-3004F9D45AE6@juniper.net> References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208163123.GB29638@elstar.local> <56B8C97E.7050303@cisco.com> <20160210124247.GA52549@elstar.local> <56BB407A.1050906@cisco.com> In-Reply-To: <56BB407A.1050906@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.160109 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:x8vXz5qc+FVv7FvPXHkkyMpJ8VDzotRljSEyh4D+LJ0T3cNc6/Ws2Wg5R6j3ucrC3okr2+L35PYcsdmgEc6WpSKKnIX8uNadlxpE37JPsHzqo+HYD4oFXT9e05bryEW8m9FA6YKbW1790blmpVrlfQ==; 24:ZODuyR4XvTGIZaAnWjcW3Q1orxfLzKwoE2qLpks5n9sNKz6HAcJL4DcD/ev4T9cjF7p9ZzQ3oR+vFxrruIDCkyLrjgTOA2jK2VhgjogPQ9c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: d2879ab9-cbd1-4612-8f44-08d332315d58 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)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(1220700001)(1096002)(11100500001)(86362001)(106116001)(189998001)(5004730100002)(3846002)(102836003)(36756003)(77096005)(10400500002)(2501003)(2906002)(230783001)(93886004)(33656002)(2900100001)(40100003)(99286002)(82746002)(5002640100001)(4001350100001)(6116002)(122556002)(66066001)(87936001)(5001770100001)(54356999)(2950100001)(3280700002)(50986999)(5001960100002)(3660700001)(83506001)(76176999)(107886002)(83716003)(5008740100001)(586003)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 10 Feb 2016 15:46:38.9461 (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-kwatsen-netmod-opstate-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: Wed, 10 Feb 2016 15:47:34 -0000 DQoNCg0KDQo+SWYgdGhlcmUgd2FzIGEgd2F5IHRoYXQgWUFORyBwYXRjaCAob3IgZXF1aXZhbGVu dCkgd2VyZSBhYmxlIHRvIHJldHVybiANCj5ib3RoIG9sZCBhbmQgbmV3IHZhbHVlcyAoaW4gdGhl IHNhbWUgdHJlZSkgdGhlbiBJIHRoaW5rIHRoYXQgd291bGQgYmUgDQo+YmV0dGVyLiAgSSBkb24n dCB0aGluayB0aGF0IHN1Y2ggYXMgc29sdXRpb24gd291bGQgYmUgc3BlY2lmaWMgdG8gdGhlIA0K Pm9wc3RhdGUgcmVxdWlyZW1lbnRzIGFuZCBtYXkgYmUgdXNlZnVsIG1vcmUgZ2VuZXJhbGx5Lg0K DQpBbHJlYWR5IHRoZSA8Z2V0LWRpZmY+IFJQQyBhY2NlcHRzIGFuIGVudW1lcmF0aW9uIHNwZWNp ZnlpbmcgdGhlIHJlc3BvbnNlIGZvcm1hdC4gIEl0IHNlZW1zIHRoYXQgYWxsIHRoYXQgaXMgbmVl ZGVkIGlzIHRvIGRlZmluZSBhbm90aGVyIGVudW1lcmF0aW9uIGZvciBzb21ldGhpbmcgbGlrZSDi gJx5YW5nLWRpZmbigJ0gdGhhdCBjYW4gZG8gYWxsIHlvdSBzYXkuICAgV2UgZG9u4oCZdCBoYXZl IHlhbmctZGlmZiB0b2RheSwgYnV0IHNvbWVvbmUgY2FuIHdyaXRlIGEgZHJhZnQgdG8gZGVmaW5l IGl0IGFuZCB0aGVuIGl0IGNhbiBiZSBhZGRlZCBvciB1c2VkIGluc3RlYWQuICANCg0KQWx0ZXJu YXRpdmVseSwgdGhlIDxnZXQtZGlmZj4gUlBDIGNvdWxkIGJlIG1vdmVkIGludG8gYSBkaWZmLWRy YWZ0IHRoYXQgZGVmaW5lcyBib3RoIHRoZSBSUEMgYW5kIHRoZSBmb3JtYXQgdG9nZXRoZXIuICBT b21ldGhpbmcgbGlrZSB0aGlzIG1pZ2h0IG1ha2Ugc2Vuc2UgYXMgPGdldC1kaWZmPiBpcyBnZW5l cmFsbHkgdXNlZnVsIG91dHNpZGUgb2YgdGhpcyBvcHN0YXRlIGFwcGxpY2F0aW9uLiANCg0KS2Vu dCAgLy8gY29udHJpYnV0b3IgDQoNCg== From nobody Wed Feb 10 08:16:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D601A1B2C60 for ; Wed, 10 Feb 2016 08:16:31 -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 IGKXXU-xOSLk for ; Wed, 10 Feb 2016 08:16:27 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6582F1B2C65 for ; Wed, 10 Feb 2016 08:16:26 -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.403.16; Wed, 10 Feb 2016 16:16:25 +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.0403.017; Wed, 10 Feb 2016 16:16:25 +0000 From: Kent Watsen To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] a few comments on draft-wilton-netmod-opstate-yang Thread-Index: AQHRX5vj8n48Wc8D1kOhd6Pt2B8rSJ8dNgaAgAAFZYCAACWFAIAAzhoAgAP5FgCAADIMgIABPXWAgAG3QoCAABxuAP//vmsA Date: Wed, 10 Feb 2016 16:16:25 +0000 Message-ID: <887BBD92-EE84-4879-A187-7CE677136AA4@juniper.net> References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B9CAB9.5050402@cisco.com> <20160210132923.GC52549@elstar.local> <56BB530C.4060603@cisco.com> In-Reply-To: <56BB530C.4060603@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.160109 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:rIz4q2epXDKpsDim1O+8Q3bBe+ZJc8UkrEpwLdly5LdddNP/j+5xC7bzvOaGQbsa1QlXYk5xKvj3fZ/sB6sXX6HbrjTyT3qkCfrqMEAoggD1Mcbj/9Azghcl4DtQCz1DlJH/OLdBbiRUy7mbDFLnwQ==; 24:HjRQ/PWneUTpQYQy0ojmre3eqyq+nzk0y1200k30Cl/BKfKdtm1tE7Jl7nqpLDcv3vB7rixnPeU07j0ske7zmlwceDRNBx/jcJmuDq50Ej0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-ms-office365-filtering-correlation-id: 24d50de4-9734-4b48-3189-08d33235864c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2501003)(36756003)(76176999)(54356999)(230783001)(86362001)(50986999)(83716003)(92566002)(40100003)(122556002)(66066001)(33656002)(5008740100001)(87936001)(19580395003)(4001350100001)(83506001)(5001770100001)(189998001)(5001960100002)(106116001)(15975445007)(82746002)(10400500002)(5004730100002)(99286002)(93886004)(77096005)(1220700001)(102836003)(6116002)(107886002)(1096002)(3846002)(2950100001)(3280700002)(3660700001)(586003)(2900100001)(11100500001)(5002640100001)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <84A958E2F94D6D4F8C74B8EBA1E77464@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2016 16:16:25.5917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Wed, 10 Feb 2016 16:16:32 -0000 W2NoYWlyIGhhdCBvbl0NCg0KDQoNCg0KPkJ1dCBJIHdvbmRlciB3aGV0aGVyIHRoZSBPcGVuQ29u ZmlnIG9wZXJhdG9ycyBtaWdodCBhbHNvIGFzayB0aGUgV0cgdGhlIA0KPnNhbWUgcXVlc3Rpb24g b2Ygd2hldGhlciBhIGRhdGFzdG9yZSBzb2x1dGlvbiBpcyBvcmRlcnMgb2YgbWFnbml0dWRlIA0K PmJldHRlciB0aGFuIHRoZSBPcGVuQ29uZmlnIHNvbHV0aW9uPw0KPg0KPk15IGJlc3QgZ3Vlc3Mg aXMgdGhhdCBhdCB0aGUgbW9tZW50IHRoZXkgd291bGQgcmVnYXJkIGEgZGF0YXN0b3JlIA0KPnNv bHV0aW9uIGFzIGJlaW5nIGluZmVyaW9yIHRvIHRoZWlyIGN1cnJlbnQgd29ya2luZyBzb2x1dGlv biAoZm9yIHdoaWNoIA0KPnRoZXkgaGF2ZSBtb2RlbHMgdGhhdCBhcmUgZnVydGhlciBhaGVhZCB0 aGFuIElFVEYsIHJ1bm5pbmcgY29kZSwgc29tZSANCj5tYWpvciB2ZW5kb3JzIGNvbW1pdHRlZCB0 byBpbXBsZW1lbnRpbmcgdGhvc2UgbW9kZWxzLCBhbmQgc2VlbWluZyBtb3JlIA0KPmludGVyZXN0 IGZyb20gdGhlIGxhcmdlIG5ldHdvcmsgb3BlcmF0b3JzIGluIHVzaW5nIHRob3NlIG1vZGVscyku DQo+DQo+V2lsbCB2ZW5kb3JzIGFjdHVhbGx5IGltcGxlbWVudCBhIGRhdGFzdG9yZSBiYXNlZCBz b2x1dGlvbiBpZiB0aGUgDQo+T3BlbkNvbmZpZyBvcGVyYXRvcnMgKHdobyBhcmUgcmFpc2luZyB0 aGUgcmVxdWlyZW1lbnQpIGRvbid0IGFjdHVhbGx5IA0KPndhbnQvbmVlZCB0byB1c2UgaXQ/DQo+ DQo+VGhlbiBJIGd1ZXNzIHRoZSBmaW5hbCBxdWVzdGlvbiBJIGhhdmUgaXMgd2hldGhlciBTRE8g cHJvZHVjZWQgbW9kZWxzIA0KPndpbGwgc3RpbGwgYmUgcmVsZXZhbnQgaWYgdGhleSBsYWcgMiB5 ZWFycyBiZWhpbmQgdGhlIE9wZW5Db25maWcgbW9kZWxzLCANCj5hbmQgdGhvc2UgbW9kZWxzIGhh dmUgYmVjb21lIGEgZGVmYWN0byBzdGFuZGFyZD8NCg0KTGV04oCZcyBqdXN0IGZvY3VzIG9uIHNv bHZpbmcgdGhlIGVuZ2luZWVyaW5nIHByb2JsZW0gYXQgaGFuZC4gIFRoZSBPQyBmb2xrcyBhcmUg bW9yZSB0aGFuIHdlbGNvbWVkIHRvIGFzc2lzdCAoc2VyaW91c2x5IGd1eXMsIHdoZXJlIGFyZSB5 b3U/KSwgYnV0IGxldOKAmXMgbm90IHNwZWN1bGF0ZSBvbiB0aGVpciBwb3NpdGlvbnMuDQoNCg0K DQo+PiAgIElmIHRoZSBvbmx5IHJlYWwgdGVjaG5pY2FsIGFyZ3VtZW50IGlzICJJIG5lZWQgdG8N Cj4+IGJlIGFibGUgdG8gcmV0cmlldmUgZGF0YSBmcm9tIG11bHRpcGxlIGRhdGFzdG9yZXMgaW4g YSBzaW5nbGUgUlBDDQo+PiBvcGVyYXRpb24iLi4uIDxTTklQLz4NCg0KSSB3YW50IHRvIHBvaW50 IG91dCBhZ2FpbiAoc2VlIFsxXSkgdGhhdCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBsaXN0ZWQg dG8gcmV0dXJuIHR3byBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMgaW4gb25lIFJQQyByZXNwb25z ZSAtIG9ubHkgdGhlIGRpZmYgaXMgc3BlY2lmaWVkIGFzIGJlaW5nIHJlcXVpcmVkLiAgWWVzLCBz b2x1dGlvbiAjMSBoYXMgdGhpcyBhYmlsaXR5LCBidXQgdGhhdCBkb2VzbuKAmXQgdHJhbnNsYXRl IHRvIGEgcmVxdWlyZW1lbnQuICAgVW5sZXNzIHdlIGhlYXIgZnJvbSBvcGVyYXRvcnMgdGhhdCB0 aGlzIHdhcyBhIG1pc3NlZCByZXF1aXJlbWVudCwgd2Ugc2hvdWxkIG5vdCB2aWV3IGl0IGFzIHN1 Y2guDQoNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9k L2VpX1hobnoyMk5vZU1qbHFZNDJEclVGR2FsSQ0KDQoNClRoYW5rcywNCktlbnQNCg0KDQo= From nobody Wed Feb 10 08:21:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADDC1B2C06 for ; Wed, 10 Feb 2016 08:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 MXyAINQksSd7 for ; Wed, 10 Feb 2016 08:21:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9581ACE9C for ; Wed, 10 Feb 2016 08:21:28 -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.403.16; Wed, 10 Feb 2016 16:21: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.0403.017; Wed, 10 Feb 2016 16:21:10 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: (Forward to others) WebEx meeting changed: NETMOD Virtual Interim Meeting Thread-Index: AQHRY6ouPovmNkRFIUuPWGL+qDW5hZ8lIvOA Date: Wed, 10 Feb 2016 16:21:09 +0000 Message-ID: <937835D7-4455-4381-B3AB-3F7D9236AE23@juniper.net> References: <26416270.102718.1455071069445.JavaMail.nobody@jva2tc207.webex.com> In-Reply-To: <26416270.102718.1455071069445.JavaMail.nobody@jva2tc207.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:VmgTn1e5iYfWgXBlzx9Rk5QefV+f2VNYhNBRi3hIMXI/Kq+Ik0l21HP3/zo76TTANNSNxtF55+PXANfFxTkytHpz7v3Ft4RL3EQlav628Cq8AhImZwPyH/f2UTCkiWOZc70khRMxk706OL+nml/Uow==; 24:ZUUDkB8ThOVNAnr2HMq2lExeTD7xXhUACGm3Q26txlHOcPXTeksieJr4aGo4Uv1VtAWt07BaItIn8mJ4HNVYEfNYtUIKfVG/U3NfY3dDUjw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: b1f3f68b-fd1a-498c-83ba-08d332362fc9 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(243025005)(377454003)(76176999)(99936001)(36756003)(92566002)(5002640100001)(110136002)(3280700002)(19617315012)(16236675004)(54356999)(33656002)(83506001)(19580405001)(2501003)(3660700001)(11100500001)(82746002)(19580395003)(4001350100001)(189998001)(107886002)(5001960100002)(1730700002)(5890100001)(5004730100002)(2906002)(1096002)(1220700001)(6116002)(586003)(5008740100001)(102836003)(3846002)(50986999)(2900100001)(83716003)(15975445007)(77096005)(122556002)(16799955002)(450100001)(10400500002)(40100003)(86362001)(551544002)(2950100001)(99286002)(87936001)(2351001)(106116001)(66066001)(24704002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_937835D744554381B3AB3F7D9236AE23junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2016 16:21:09.9324 (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: Subject: [netmod] FW: (Forward to others) WebEx meeting changed: NETMOD Virtual Interim Meeting 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, 10 Feb 2016 16:21:33 -0000 --_004_937835D744554381B3AB3F7D9236AE23junipernet_ Content-Type: multipart/alternative; boundary="_000_937835D744554381B3AB3F7D9236AE23junipernet_" --_000_937835D744554381B3AB3F7D9236AE23junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBdHRhY2hlZCBpcyB0aGUgY2FsZW5kYXIgaW52aXRlIGZvciB0aGUgdmlydHVhbCBpbnRlcmlt IG1lZXRpbmcsIHNvIHRoYXQgaXQgY2FuIGJlIGVhc2lseSBhZGRlZCB0byB5b3VyIGNhbGVuZGFy cy4NCg0KQ2hlZXJzLA0KS2VudA0KDQoNCkZyb206IE5FVE1PRCBXb3JraW5nIEdyb3VwIDxtZXNz ZW5nZXJAd2ViZXguY29tPG1haWx0bzptZXNzZW5nZXJAd2ViZXguY29tPj4NClJlcGx5LVRvOiAi bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4iIDxu ZXRtb2QtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnPj4NCkRh dGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDksIDIwMTYgYXQgOToyNCBQTQ0KVG86ICJuZXRtb2QtY2hh aXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnPiIgPG5ldG1vZC1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogKEZv cndhcmQgdG8gb3RoZXJzKSBXZWJFeCBtZWV0aW5nIGNoYW5nZWQ6IE5FVE1PRCBWaXJ0dWFsIElu dGVyaW0gTWVldGluZw0KDQpZb3UgY2FuIGZvcndhcmQgdGhpcyBpbnZpdGF0aW9uIHRvIG90aGVy cy4NCkhlbGxvLA0KTkVUTU9EIFdvcmtpbmcgR3JvdXAgY2hhbmdlZCB0aGUgV2ViRXggbWVldGlu ZyBpbmZvcm1hdGlvbi4NCg0KTkVUTU9EIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQpNb25kYXks IEZlYnJ1YXJ5IDIyLCAyMDE2DQoxMDowMCBhbSAgfCAgRWFzdGVybiBTdGFuZGFyZCBUaW1lIChO ZXcgWW9yaywgR01ULTA1OjAwKSAgfCAgMiBocnMNCg0KSm9pbiBXZWJFeCBtZWV0aW5nPGh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNmJmZjcxOGM4NjY5ZmNkMTBiYjA0 MDY1MmYyN2JjYT4NCk1lZXRpbmcgbnVtYmVyOiAgICAgICAgIDY0NiA2ODQgOTU2DQpNZWV0aW5n IHBhc3N3b3JkOiAgICAgICBRYmRzM25QWg0KDQpKb2luIGJ5IHBob25lDQoxLTg3Ny02NjgtNDQ5 MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCkFjY2VzcyBjb2RlOiA2NDYgNjg0IDk1Ng0K VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPGh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90 b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmPg0KDQpBZGQgdGhpcyBtZWV0aW5nPGh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0yZDczN2E5ODcxMjE3M2JhYzE2NzQ5YTRjZmNk ZGFlND4gdG8geW91ciBjYWxlbmRhci4gKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2aWNlcy4p DQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydC48aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jPg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNl bnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292 ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1 dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29u c2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhv c3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg0K --_000_937835D744554381B3AB3F7D9236AE23junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <8DFB8BBC9B14EE428C6996FB1A747F3B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkF0dGFjaGVkIGlzIHRoZSBjYWxlbmRhciBpbnZpdGUgZm9yIHRoZSB2 aXJ0dWFsIGludGVyaW0gbWVldGluZywgc28gdGhhdCBpdCBjYW4gYmUgZWFzaWx5IGFkZGVkIHRv IHlvdXIgY2FsZW5kYXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwv ZGl2Pg0KPGRpdj5LZW50PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9 Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xv cjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0g bm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklH SFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkZyb206IDwvc3Bhbj5ORVRNT0QgV29ya2luZyBHcm91cCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1lc3NlbmdlckB3ZWJleC5jb20iPm1lc3NlbmdlckB3ZWJleC5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXBseS1UbzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnIj5uZXRtb2QtY2hhaXJzQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciPm5l dG1vZC1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRmVicnVhcnkgOSwgMjAxNiBhdCA5OjI0IFBN PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciPm5ldG1vZC1jaGFpcnNAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+ bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj4oRm9yd2FyZCB0byBvdGhlcnMpIFdlYkV4IG1lZXRp bmcgY2hhbmdlZDogTkVUTU9EIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nPGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3 aWR0aD1kZXZpY2Utd2lkdGgsIGluaXRpYWwtc2NhbGU9MSI+DQo8ZGl2PjxzdHlsZSB0eXBlPSJ0 ZXh0L2NzcyI+DQpkaXYscCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVh azogbm9ybWFsO30NCg0KdGFibGUge2JvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGJvcmRlcjog MDtib3JkZXItc3BhY2luZzogMDtib3JkZXItY29sb3I6IHdoaXRlOyB3aWR0aDoxMDAlIWltcG9y dGFudDt3aWR0aDo1MjVweDsgbWF4LXdpZHRoOjUyNXB4IWltcG9ydGFudDsgbWluLXdpZHRoOiAy NzlweCFpbXBvcnRhbnQ7fQ0KdHIge2xpbmUtaGVpZ2h0OiAyMHB4O30NCg0KdGQsYSB7Zm9udC1z aXplOiAxNXB4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjtwYWRkaW5nOjA7fQ0K PC9zdHlsZT4NCjx0YWJsZSBzdHlsZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUi IGFsaWduPSJsZWZ0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZy10b3A6NXB4 OyI+DQo8dGFibGUgc3R5bGU9IndpZHRoOiA1MjVweDttYXJnaW4tbGVmdDo1cHgiIGFsaWduPSJs ZWZ0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCI+DQo8dGFibGUgd2lkdGg9IjEw MCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjAiIGFsaWduPSJsZWZ0Ij5Z b3UgY2FuIGZvcndhcmQgdGhpcyBpbnZpdGF0aW9uIHRvIG90aGVycy4gPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjx0YWJsZT4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iZm9u dC1zaXplOiAxNXB4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjojNEQ0RDREIj5IZWxsbywgPC90 ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTog QXJpYWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+TkVUTU9EIFdvcmtpbmcgR3Jv dXAgY2hhbmdlZCB0aGUgV2ViRXggbWVldGluZyBpbmZvcm1hdGlvbi4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8dGFibGU+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAyMHB4OyI+DQo8dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHRhYmxlIHdpZHRoPSIxMDAlIj4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0RDRENEQiPjxiPk5FVE1PRCBWaXJ0 dWFsIEludGVyaW0gTWVldGluZzwvYj4gPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Im1hcmdpbjow cHgiPg0KPHRkPk1vbmRheSwgRmVicnVhcnkgMjIsIDIwMTYgPC90ZD4NCjwvdHI+DQo8dHIgc3R5 bGU9Im1hcmdpbjowcHgiPg0KPHRkPjEwOjAwIGFtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0Vh c3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7MiBocnMgPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjx0YWJsZT4N Cjx0Ym9keT4NCjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij4NCjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8dGFibGUg c3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+PGEgaHJlZj0iaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWU2YmZmNzE4Yzg2NjlmY2QxMGJiMDQw NjUyZjI3YmNhIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjE2cHg7Y29s b3I6IzAwQUZGOSI+PGI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9iPjwvYT48L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWlt cG9ydGFudCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPHRkIHN0eWxlPSJw YWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIG51bWJlcjogPC90ZD4NCjx0ZD42NDYgNjg0IDk1 NiA8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVl dGluZyBwYXNzd29yZDo8L3RkPg0KPHRkPlFiZHMzblBaPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjx0YWJsZT4NCjx0Ym9keT4NCjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+ DQo8dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHRhYmxlPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJmb250LXNpemU6MTZw eCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibWFyZ2luOjBw eCI+DQo8dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVt YmVyIChVUy9DYW5hZGEpPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPHRk PjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+DQo8dGQ+QWNjZXNzIGNvZGU6 Jm5ic3A7NjQ2IDY4NCA5NTY8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+DQo8 dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtjb2xvcjoj MDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8dGFibGU+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OjIwcHgiPg0KPHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjx0YWJsZT4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iZm9u dC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW0yZDczN2E5ODcxMjE3M2JhYzE2NzQ5YTRjZmNkZGFlNCIgc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0aW5n PC9hPiB0byB5b3VyIGNhbGVuZGFyLiAoQ2Fubm90IGFkZCBmcm9tIG1vYmlsZSBkZXZpY2VzLik8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHRhYmxlPg0KPHRib2R5Pg0KPHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPg0KPHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjx0YWJsZT4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2 NjY2NjsiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNw eDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsiPg0K Q29udGFjdCBzdXBwb3J0LjwvYT4gPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjx0 YWJsZT4NCjx0Ym9keT4NCjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij4NCjx0ZCBzdHls ZT0iaGVpZ2h0OjEwcHgiPiZuYnNwOzwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 dGFibGU+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAj QTBBMEEwOyI+SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNl cnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUg c2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxl Z2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5DQog Y29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWlu ZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90 IGpvaW4gdGhlIHNlc3Npb24uPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_937835D744554381B3AB3F7D9236AE23junipernet_-- --_004_937835D744554381B3AB3F7D9236AE23junipernet_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3851; creation-date="Wed, 10 Feb 2016 16:21:09 GMT"; modification-date="Wed, 10 Feb 2016 16:21:09 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJORVRNT0QgV29ya2lu ZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzpuZXRtb2QtY2hh aXJzQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iTkVUTU9EIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpu ZXRtb2QtY2hhaXJzQGlldGYub3JnCkRUU1RBUlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE2MDIy MlQxMDAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE2MDIyMlQxMjAwMDAKTE9DQVRJ T046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ1 NTA3MTA2OQpVSUQ6NTUxNmU4NDEtNjY1Yy00N2M4LThmZGEtMTEyMDJmODYzZmE0CkRUU1RBTVA6 MjAxNjAyMjJUMTUwMDAwWgpERVNDUklQVElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNjgzZTY4YmY1NmJhZjk1N2Qw ZjQ0MDI5MjJmZGM5MVxuTWVldGluZyBudW1iZXI6IDY0NiA2ODQgOTU2XG5NZWV0aW5nIHBhc3N3 b3JkOiBRYmRzM25QWlxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4g dG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBjb2RlOiA2NDYgNjg0IDk1NlxuXG5Ub2xsLWZy ZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxm cmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRh Y3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9 IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZTY4M2U2OGJmNTZi YWY5NTdkMGY0NDAyOTIyZmRjOTEiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNF PSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4J CQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj42NDYgNjg0IDk1NjwvRk9OVD4JCQkJ CTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwv dGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlFiZHMz blBaPC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9 IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJB UklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5 IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0 b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9z dHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsg PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNv ZGU6IDY0NiA2ODQgOTU2PC9GT05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9S PSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9G T05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpF PSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZP TlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQu PC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6 ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhp cyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBk dXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21h dGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50 IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBv ciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOk5FVE1PRCBW aXJ0dWFsIEludGVyaW0gTWVldGluZwpQUklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxB Uk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6 VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_004_937835D744554381B3AB3F7D9236AE23junipernet_-- From nobody Wed Feb 10 08:41:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597E71B2C6F for ; Wed, 10 Feb 2016 08:41:51 -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 ZxhpsO3rmxeE for ; Wed, 10 Feb 2016 08:41:49 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB81ACE9D for ; Wed, 10 Feb 2016 08:41:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 71B561E5A39; Wed, 10 Feb 2016 08:41:38 -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 Xa6vv7JjrIBJ; Wed, 10 Feb 2016 08:41:38 -0800 (PST) Received: from [192.168.1.130] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id 711121E5A37; Wed, 10 Feb 2016 08:41:37 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> Date: Wed, 10 Feb 2016 16:41:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> 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> <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.2104) 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: Wed, 10 Feb 2016 16:41:51 -0000 Is there a status update on ietf-entity please? I don't see it as a = milestone in the charter but maybe I don't know where to look. Message received re YANG 1.1. All BBF YANG will use YANG 1.1. Thanks, William > On 15 Dec 2015, at 10:17, Romascanu, Dan (Dan) = wrote: >=20 > So, let's do it. Tom, or one of the other chairs - you need to run = this.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Monday, December 14, 2015 9:18 PM >> To: Nadeau Thomas; Romascanu, Dan (Dan) >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity = YANG >> module >>=20 >>=20 >>> I personally don=E2=80=99t see anything that prevents this. >> Same opinion here. >>=20 >> Regards, Benoit >>>=20 >>> =E2=80=94Tom >>>=20 >>>> 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 >>>> 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: >>>>>> 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? >>>>>> Thanks, >>>>>> William >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mail >>>=20 >> man_listinfo_netmod&d=3DBQIDaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGx >> R31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D9jKcR2EbKD3lb73tciJMJAk0J6 >> 2dQAbsU_4R85zluXs&s=3DeBlkOZe4c5IXMoz_2YJnIKglubNBDQmS0Ej03Al8meI >> &e=3D >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 10 09:31:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A331A1B2D7C for ; Wed, 10 Feb 2016 09:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 RwV9EqQMt0Bu for ; Wed, 10 Feb 2016 09:31:22 -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 B38A31B2D75 for ; Wed, 10 Feb 2016 09:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1550; q=dns/txt; s=iport; t=1455125481; x=1456335081; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=VrKFqBqVfQfhjwSVJ47B0KZ5/TZNHKiEuzqlJwq/gPs=; b=Hso7skZ234fZ0EKta02MeptW4sB1dpJoYSjnOlX9FHWDemDmA5DSmBdO AE4JiNOxsz/spueao5F1FpxCC2MGKpkI5ifMGlXlA6gVY545vTbYU4MDB AVZ4q+lYSVkKRArwR4bcMnGHSbkvljsqm+YhL+XFi2645FyNFgyFlCRsh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABMc7tW/xbLJq1ejVWzFYYNAoIIA?= =?us-ascii?q?QEBAQEBgQuEQQEBAQMBIw8BBUARCw4KAgIFFgsCAgkDAgECAUUGAQwIAQEXh3g?= =?us-ascii?q?IsXCOcgEBAQEBAQEDAQEBAQEBARl7hReEN4cygToBBJZ4jVGJIoVSjj9ig2Q8i?= =?us-ascii?q?QEBAQE?= X-IronPort-AV: E=Sophos;i="5.22,426,1449532800"; d="scan'208";a="630399007" 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; 10 Feb 2016 17:31:18 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1AHVIjH030208; Wed, 10 Feb 2016 17:31:18 GMT To: Kent Watsen , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <56B8985A.9060501@cisco.com> <20160208163123.GB29638@elstar.local> <56B8C97E.7050303@cisco.com> <20160210124247.GA52549@elstar.local> <56BB407A.1050906@cisco.com> <694E6309-813D-4DBE-A355-3004F9D45AE6@juniper.net> From: Robert Wilton Message-ID: <56BB73E6.8060906@cisco.com> Date: Wed, 10 Feb 2016 17:31:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <694E6309-813D-4DBE-A355-3004F9D45AE6@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Wed, 10 Feb 2016 17:31:23 -0000 On 10/02/2016 15:46, Kent Watsen wrote: > > > >> If there was a way that YANG patch (or equivalent) were able to return >> both old and new values (in the same tree) then I think that would be >> better. I don't think that such as solution would be specific to the >> opstate requirements and may be useful more generally. > Already the RPC accepts an enumeration specifying the response format. It seems that all that is needed is to define another enumeration for something like “yang-diff” that can do all you say. We don’t have yang-diff today, but someone can write a draft to define it and then it can be added or used instead. > > Alternatively, the RPC could be moved into a diff-draft that defines both the RPC and the format together. Something like this might make sense as is generally useful outside of this opstate application. Yes, OK. I can easily see how a RPC message could provide two separate trees, i.e. one with the values before, and a separate tree with the values after, but I'm not sure that such a message format would really be any better than the current YANG patch format. However, the bit that I'm stuck on is that I can't see how is it possible to provide the data in a single tree unless you end up with an encoding that is broadly similar to what I have suggested in my draft, and several folks have strong views against any such encoding. AFAIK, no alternatives have been proposed. Rob > > Kent // contributor > From nobody Wed Feb 10 09:45:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBF11B2D93 for ; Wed, 10 Feb 2016 09:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 sEBvE2ch3vHX for ; Wed, 10 Feb 2016 09:45:35 -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 019C61B2D8E for ; Wed, 10 Feb 2016 09:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2903; q=dns/txt; s=iport; t=1455126335; x=1456335935; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ItcnaIXTtlpVg7ai7UJ7HZEYUnUazfGT8nijDwqmvoI=; b=K6bSQnicHyyvCodZxBuCuPl0hnEni9cj9PWHlpUkF0knahX48dkfDyt/ zxIqtAlrQsB9nu4FfTBHzSorKmofkyWXmzM6LNOMgNaiCg9ChzX/lx5CD qmNlws1dEJp+NsDIGnmCzlqQjAAHT3WWudkabLZIv1phUFnK1NrGbdZfB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAD2drtW/xbLJq1ejVWzFYYNAoIIA?= =?us-ascii?q?QEBAQEBgQALhEEBAQEDASMECwEFDzERCQIYAgIFFgsCAgkDAgECAUUGDQgBARe?= =?us-ascii?q?HeAiUYJ0ThHSJfQEBAQEBAQQBAQEBARt7hReDPHuEGoMYgToBBJZ4jVGBXIRDg?= =?us-ascii?q?wOFUoVviFBig2Q8iQEBAQE?= X-IronPort-AV: E=Sophos;i="5.22,426,1449532800"; d="scan'208";a="630399369" 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; 10 Feb 2016 17:45:11 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1AHjATS001426 for ; Wed, 10 Feb 2016 17:45:10 GMT To: "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> From: Robert Wilton Message-ID: <56BB7726.3060403@cisco.com> Date: Wed, 10 Feb 2016 17:45:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210125129.GB52549@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Wed, 10 Feb 2016 17:45:37 -0000 On 10/02/2016 12:51, Juergen Schoenwaelder wrote: > On Mon, Feb 08, 2016 at 05:50:00PM +0000, Gert Grammel wrote: >> Hi Juergen, >> >> I think the indentation in our emails play havoc which is confusing me >> too. The key point I am making is: >> >> The mapping of what is called intended-config onto data stores would >> deserve more detailed discussion. It seems the authors of >> draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg >> with the [running] datastore. In my understanding, a failure in applying >> [running] to [applied] will update the [running] datastore to reflect >> which part is effectively applied. So a fair representation of that case >> would be: >> [candidate] -> [running] <--> [applied] -> derived state > This is not how I understood that state of the discussions. I do not > think that the NETCONF configuration datastore changes in > existing implementations dynamically. Does it on Junos? On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on error semantics) then if applying the configuration for any config nodes fails then the whole config commit is undone. I.e. the system ends in the same state as if the configuration commit never happened - standard transaction commit semantics. > >> In the context of intended-configuration however that doesn’t make sense >> to me. A failure in applying intended configuration doesn¹t change the >> intention and the delta between intended and applied-config is the key >> value. A server that would "clean-up" intended-cfg in presence of a >> failure to apply would look picture perfect instead of exposing the >> problem clearly. Hence the sequence should more look like: >> [candidate] -> [intended] ‹-> [running==applied] -> derived state >> >> Whatever we choose, I believe we need to spell out what¹s the data in a >> failure case. It¹s probably a bit late to update the requirements draft, >> but we can probably find a suitable place. >> >> ——— >> >> >> I am also wondring if we have the same understanding related to the >> following statement: >> I thought the whole point of having an applied config is to be able to >> see the difference between intended (oops running) and applied. >> >> >> The current draft-kwatsen-netmod-opstate-02.txt says: >> "Any rollback that may occur will restore both the intended and the >> applied configurations to their previous states." > This rollback requirement is in my view broken (I assume people will > figure this out when they try to implement solutions for it). This was meant to be consistent with the existing rollback-on-error semantics supported by NETCONF (specified in rfc6241). As above, my understanding is that Cisco IOS XR already supports these semantics. Please can you clarify how/why the requirement is broken? Rob From nobody Thu Feb 11 01:04:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2355B1A01D8 for ; Thu, 11 Feb 2016 01:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HmOtzGtirsTM for ; Thu, 11 Feb 2016 01:04: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 178751AC3B0 for ; Thu, 11 Feb 2016 01:04:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1D5C71214; Thu, 11 Feb 2016 10:04:01 +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 rHoLmApNgPiA; Thu, 11 Feb 2016 10:03: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; Thu, 11 Feb 2016 10:04:00 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B66220031; Thu, 11 Feb 2016 10:04:00 +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 7yTh4GaLE2WB; Thu, 11 Feb 2016 10:03: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 7FC202002B; Thu, 11 Feb 2016 10:03:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9434339E3862; Thu, 11 Feb 2016 10:04:00 +0100 (CET) Date: Thu, 11 Feb 2016 10:04:00 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160211090400.GA54295@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <56B3D15A.7080900@labn.net> <20160205095019.GA23583@elstar.local> <56B474E1.8000901@cisco.com> <20160205122354.GA23770@elstar.local> <56B89670.9090300@cisco.com> <20160208162059.GA29638@elstar.local> <56B9CAB9.5050402@cisco.com> <20160210132923.GC52549@elstar.local> <56BB530C.4060603@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BB530C.4060603@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] a few comments on draft-wilton-netmod-opstate-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: Thu, 11 Feb 2016 09:04:05 -0000 On Wed, Feb 10, 2016 at 03:11:08PM +0000, Robert Wilton wrote: > > I cannot present such an argument that a protocol based solution is > orders of magnitude better than using multiple datastores. > > But I wonder whether the OpenConfig operators might also ask the WG the > same question of whether a datastore solution is orders of magnitude > better than the OpenConfig solution? This has been explained. I am not going to repeat the arguments. I am going to ignore any further discussion here until 'the operators' come out of their corner and start to engage in _technical_ discussion. /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 Feb 11 01:29:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEF21ACDC8 for ; Thu, 11 Feb 2016 01:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 UefG8hv1owZj for ; Thu, 11 Feb 2016 01:29: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 5154B1ACD95 for ; Thu, 11 Feb 2016 01:29: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 218A912C6; Thu, 11 Feb 2016 10:29: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 e7I7UPfjLO7P; Thu, 11 Feb 2016 10:28:59 +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, 11 Feb 2016 10:29:03 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAA7220031; Thu, 11 Feb 2016 10:29:03 +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 nCYRD8HQaes6; Thu, 11 Feb 2016 10:29: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 3DBC22002B; Thu, 11 Feb 2016 10:29:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DCD239E3904; Thu, 11 Feb 2016 10:29:03 +0100 (CET) Date: Thu, 11 Feb 2016 10:29:03 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160211092903.GB54295@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> <56BB7726.3060403@cisco.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: <56BB7726.3060403@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 11 Feb 2016 09:29:08 -0000 On Wed, Feb 10, 2016 at 05:45:10PM +0000, Robert Wilton wrote: > > > On 10/02/2016 12:51, Juergen Schoenwaelder wrote: > >On Mon, Feb 08, 2016 at 05:50:00PM +0000, Gert Grammel wrote: > >>Hi Juergen, > >> > >>I think the indentation in our emails play havoc which is confusing me > >>too. The key point I am making is: > >> > >>The mapping of what is called intended-config onto data stores would > >>deserve more detailed discussion. It seems the authors of > >>draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg > >>with the [running] datastore. In my understanding, a failure in applying > >>[running] to [applied] will update the [running] datastore to reflect > >>which part is effectively applied. So a fair representation of that case > >>would be: > >>[candidate] -> [running] <--> [applied] -> derived state > >This is not how I understood that state of the discussions. I do not > >think that the NETCONF configuration datastore changes in > >existing implementations dynamically. Does it on Junos? > On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on > error semantics) then if applying the configuration for any config nodes > fails then the whole config commit is undone. I.e. the system ends in > the same state as if the configuration commit never happened - standard > transaction commit semantics. > This is how it should be. > > > >>In the context of intended-configuration however that doesn’t make sense > >>to me. A failure in applying intended configuration doesn¹t change the > >>intention and the delta between intended and applied-config is the key > >>value. A server that would "clean-up" intended-cfg in presence of a > >>failure to apply would look picture perfect instead of exposing the > >>problem clearly. Hence the sequence should more look like: > >>[candidate] -> [intended] ‹-> [running==applied] -> derived state > >> > >>Whatever we choose, I believe we need to spell out what¹s the data in a > >>failure case. It¹s probably a bit late to update the requirements draft, > >>but we can probably find a suitable place. > >> > >>——— > >> > >> > >>I am also wondring if we have the same understanding related to the > >>following statement: > >> I thought the whole point of having an applied config is to be able > >> to > >>see the difference between intended (oops running) and applied. > >> > >> > >>The current draft-kwatsen-netmod-opstate-02.txt says: > >>"Any rollback that may occur will restore both the intended and the > >>applied configurations to their previous states." > >This rollback requirement is in my view broken (I assume people will > >figure this out when they try to implement solutions for it). > This was meant to be consistent with the existing rollback-on-error > semantics supported by NETCONF (specified in rfc6241). > > As above, my understanding is that Cisco IOS XR already supports these > semantics. > > Please can you clarify how/why the requirement is broken? We are discussing this text: D. The configuration protocol MUST specify how configuration errors are handled. Errors SHOULD be handled by semantics similar to NETCONF's error-options for the operation (stop-on-error, continue-on-error, rollback-on- error), as described in Section 7.2 in [RFC6241], but extended to incorporate both the intended and applied configurations. Support for "rollback on error" semantics SHOULD be provided. First, let me observe that it is underspecified what a 'configuration error' is in the context of this requirement statement. Is the configuration of an interface that is currently not present a configuration error? If not, does it become a configuration error if a line card is inserted to which the configuration can not be applied? Note that NETCONF together with YANG provides a rather clear definition what validation of a configuration datastore means. When we talk about applied config and the difference between intended and applied config, the notion of what is a configuration error is not clear cut anymore. Second, in order to rollback, there needs to be a configuration that can be safely rolled back into. The only robust way I can imagine to implement this rollback requirement is to use locks until the whole new config has been applied, thereby turning an asynchronous system into a synchronous system. Otherwise, I fail to see how I can ensure that I have a configuration that can be safely rolled back into. /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 Feb 11 04:22:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F111B2A25 for ; Thu, 11 Feb 2016 04:22:25 -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 d_c0HZmCTWSP for ; Thu, 11 Feb 2016 04:22:21 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E461B2A23 for ; Thu, 11 Feb 2016 04:22:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 530811E5A3E; Thu, 11 Feb 2016 04:22:07 -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 oyj6GT4Smkce; Thu, 11 Feb 2016 04:22:07 -0800 (PST) Received: from [192.168.1.100] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id C15211E5A39; Thu, 11 Feb 2016 04:22:06 -0800 (PST) From: William Lupton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2016 12:22:19 +0000 To: netmod@ietf.org Message-Id: <4BFFC9D8-55FE-4296-B929-8B85305918E8@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Restricting interface name maximum length and character set 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, 11 Feb 2016 12:22:26 -0000 All, Here in the Broadband Forum we are defining YANG modules that augment = RFC 7223 ietf-interfaces. We want to limit interface name maximum length = and character set but don't see a way of doing this in the YANG. Can/should we do do this in the YANG, or should it just be a = device-level requirement? Thanks, William ---- notes ---- We considered the "arbitrary-names" feature but reckoned that this = applies only to user-controlled interfaces and therefore doesn't apply = here. We considered requiring use of a "deviate" statement to state device = support for shorter maximum length (64) and restricted character set = (ASCII 32-126) but we don't expect NETMOD to approve of this.= From nobody Thu Feb 11 05:55:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C845A1B31C2 for ; Thu, 11 Feb 2016 05:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 8om5hhWAVXtg for ; Thu, 11 Feb 2016 05:55: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 DB23C1B31BC for ; Thu, 11 Feb 2016 05:55:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8F93726; Thu, 11 Feb 2016 14:55: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 FxPTKGRdEje2; Thu, 11 Feb 2016 14:54:58 +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, 11 Feb 2016 14:55:03 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3E3B2002C; Thu, 11 Feb 2016 14:55:03 +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 Ov5ViVbqnSK6; Thu, 11 Feb 2016 14:55: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 9691E2002B; Thu, 11 Feb 2016 14:55:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8608F39E3ADD; Thu, 11 Feb 2016 14:55:03 +0100 (CET) Date: Thu, 11 Feb 2016 14:55:03 +0100 From: Juergen Schoenwaelder To: William Lupton Message-ID: <20160211135503.GA54817@elstar.local> Mail-Followup-To: William Lupton , netmod@ietf.org References: <4BFFC9D8-55FE-4296-B929-8B85305918E8@broadband-forum.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BFFC9D8-55FE-4296-B929-8B85305918E8@broadband-forum.org> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Restricting interface name maximum length and character set 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, 11 Feb 2016 13:55:09 -0000 On Thu, Feb 11, 2016 at 12:22:19PM +0000, William Lupton wrote: > All, > > Here in the Broadband Forum we are defining YANG modules that augment RFC 7223 ietf-interfaces. We want to limit interface name maximum length and character set but don't see a way of doing this in the YANG. > > Can/should we do do this in the YANG, or should it just be a device-level requirement? > I wonder why you want to do this. Is it because other existing BBF specifications break if interfaces can have long names and use Unicode characters? Out of curiosity, what would be the length and character set restriction BBF finds a good choice? A deviation statement describes how an implementation deviates from a data model. It was not the intent that an SDO defines a 'standard' deviation for a data model (the term 'profile' might be more appropriate for this). Note that these kind of 'profiles' often do not combine well. If BBF says the max length is N and MEF says that max length is N with N != M, then an implementor has a hard time to produce a device that satisfies both requirements. (All one can do is to use min(N,M) and then annouce a deviation to the profiles affected, all getting pretty ugly soon, in particular if the common native interface names may be longer than N and M.) I understand that 'arbitrarily long' may sound ridiculous. But having an implementation announce its real limit instead of a data model or 'profile' imposed limit seems simpler and more robust to me. /js PS: On Windows, MAX_ADAPTER_NAME_LENGTH seems to be 256, on Linux IF_NAMESIZE seems to be 16, on FreeBSD and MacOS IF_NAMESIZE seems to be 16 as well (but there are likely systems derived from FreeBSD that use a different constant, may also be true for Linux - and most likely people change this constant for a reason). -- 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 Feb 11 06:52:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2D91B32D4 for ; Thu, 11 Feb 2016 06:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 mnGpnec9jOyO for ; Thu, 11 Feb 2016 06:52:31 -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 CA0E31B32DA for ; Thu, 11 Feb 2016 06:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6390; q=dns/txt; s=iport; t=1455202350; x=1456411950; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Agm9QqETXYd1Qmq/oWqGPWHyI1wzcME4IAsdGTvoxS0=; b=jDzC0lBGxGHSfh2rcIDPS7WnAQH1uTido3An/6PP2bAfGBUCWeaRyMyt ct0NhJq1rsWDYYwpGzVEoJwLJGnDtE0pNLQAUE4MrxeJtLqXkxsGg33U2 aa9h6FctellU4xq7CBDxTEDsIPWmNiZyy7FJ5yG4kW4c8735tKvlMIAzX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBnn7xW/xbLJq1ejVSxGAENgWeGD?= =?us-ascii?q?QKBaBQBAQEBAQEBfwuEQQEBAQMBIwQLAQUPMQYLCQIYAgIFFgsCAgkDAgECAUU?= =?us-ascii?q?GDQgBAReHdwiVF50ThHSJbAEBAQEBAQQBAQEBARt7hReDO3uEGoMYgToBBJJbh?= =?us-ascii?q?ByIOoUZgV2EQ4MDgRqEOIVviE8eAQFCg2U8h0olgRIBAQE?= X-IronPort-AV: E=Sophos;i="5.22,431,1449532800"; d="scan'208";a="632573003" 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; 11 Feb 2016 14:52:28 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1BEqS6s007894 for ; Thu, 11 Feb 2016 14:52:28 GMT To: "netmod@ietf.org" References: <20160202153033.9430.65698.idtracker@ietfa.amsl.com> <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> <56BB7726.3060403@cisco.com> <20160211092903.GB54295@elstar.local> From: Robert Wilton Message-ID: <56BCA02B.6080406@cisco.com> Date: Thu, 11 Feb 2016 14:52:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160211092903.GB54295@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Thu, 11 Feb 2016 14:52:33 -0000 On 11/02/2016 09:29, Juergen Schoenwaelder wrote: > On Wed, Feb 10, 2016 at 05:45:10PM +0000, Robert Wilton wrote: >> >> On 10/02/2016 12:51, Juergen Schoenwaelder wrote: >>> On Mon, Feb 08, 2016 at 05:50:00PM +0000, Gert Grammel wrote: >>>> Hi Juergen, >>>> >>>> I think the indentation in our emails play havoc which is confusing me >>>> too. The key point I am making is: >>>> >>>> The mapping of what is called intended-config onto data stores would >>>> deserve more detailed discussion. It seems the authors of >>>> draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg >>>> with the [running] datastore. In my understanding, a failure in applying >>>> [running] to [applied] will update the [running] datastore to reflect >>>> which part is effectively applied. So a fair representation of that case >>>> would be: >>>> [candidate] -> [running] <--> [applied] -> derived state >>> This is not how I understood that state of the discussions. I do not >>> think that the NETCONF configuration datastore changes in >>> existing implementations dynamically. Does it on Junos? >> On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on >> error semantics) then if applying the configuration for any config nodes >> fails then the whole config commit is undone. I.e. the system ends in >> the same state as if the configuration commit never happened - standard >> transaction commit semantics. >> > This is how it should be. > >>>> In the context of intended-configuration however that doesn’t make sense >>>> to me. A failure in applying intended configuration doesn¹t change the >>>> intention and the delta between intended and applied-config is the key >>>> value. A server that would "clean-up" intended-cfg in presence of a >>>> failure to apply would look picture perfect instead of exposing the >>>> problem clearly. Hence the sequence should more look like: >>>> [candidate] -> [intended] ‹-> [running==applied] -> derived state >>>> >>>> Whatever we choose, I believe we need to spell out what¹s the data in a >>>> failure case. It¹s probably a bit late to update the requirements draft, >>>> but we can probably find a suitable place. >>>> >>>> ——— >>>> >>>> >>>> I am also wondring if we have the same understanding related to the >>>> following statement: >>>> I thought the whole point of having an applied config is to be able >>>> to >>>> see the difference between intended (oops running) and applied. >>>> >>>> >>>> The current draft-kwatsen-netmod-opstate-02.txt says: >>>> "Any rollback that may occur will restore both the intended and the >>>> applied configurations to their previous states." >>> This rollback requirement is in my view broken (I assume people will >>> figure this out when they try to implement solutions for it). >> This was meant to be consistent with the existing rollback-on-error >> semantics supported by NETCONF (specified in rfc6241). >> >> As above, my understanding is that Cisco IOS XR already supports these >> semantics. >> >> Please can you clarify how/why the requirement is broken? > We are discussing this text: > > D. The configuration protocol MUST specify how configuration > errors are handled. Errors SHOULD be handled by semantics > similar to NETCONF's error-options for the > operation (stop-on-error, continue-on-error, rollback-on- > error), as described in Section 7.2 in [RFC6241], but > extended to incorporate both the intended and applied > configurations. Support for "rollback on error" semantics > SHOULD be provided. > > First, let me observe that it is underspecified what a 'configuration > error' is in the context of this requirement statement. Is the > configuration of an interface that is currently not present a > configuration error? My opinion is yes, this is an error and hence would cause configuration to fail and rollback if "rollback-on-error" semantics had been requested. If the request had used continue-on-error semantics then I would expect that you would see this configuration in intended, but not applied. > If not, does it become a configuration error if a > line card is inserted to which the configuration can not be applied? As above, this question doesn't directly apply. But a similar question might be: what would happen if the configuration had previously been accepted and then a linecard removed? In this case the the affected interface configuration would stay in intended but be removed from applied by the system. > Note that NETCONF together with YANG provides a rather clear > definition what validation of a configuration datastore means. When we > talk about applied config and the difference between intended and > applied config, the notion of what is a configuration error is not > clear cut anymore. Personally, I agree that having tighter semantics are a good thing here (and should be covered by the solution draft). > > Second, in order to rollback, there needs to be a configuration that > can be safely rolled back into. The only robust way I can imagine to > implement this rollback requirement is to use locks until the whole > new config has been applied, thereby turning an asynchronous system > into a synchronous system. Otherwise, I fail to see how I can ensure > that I have a configuration that can be safely rolled back into. Locks are the simplest way of implementing this, but I agree that they defeat the point of async configuration updates. I don't think that locking is the only way to solve this. I would have thought that one of the optimistic transactional locking approaches could be used to process multiple requests concurrently. Hence, I think that the decision as to whether or not to use a global lock should probably be specified during the client operation (if at all), and the solution draft shouldn't enforce always using a server side lock. Instead it should specify the exact semantics that a client can expect when interacting with the server during configuration requests. This is to allow for flexibility in server implementations - i.e. to trade off complexity for performance. Rob > > /js > From nobody Thu Feb 11 11:54:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA001B39AA for ; Thu, 11 Feb 2016 11:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuMVo9rj-fcC for ; Thu, 11 Feb 2016 11:54:16 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F5C1B39AB for ; Thu, 11 Feb 2016 11:54:16 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c11o149.mxlogic.net(mxl_mta-8.5.0-6) over TLS secured channel with ESMTP id 7e6ecb65.0.2871495.00-319.8008916.p01c11o149.mxlogic.net (envelope-from ); Thu, 11 Feb 2016 12:54:16 -0700 (MST) X-MXL-Hash: 56bce6e8778ac0d6-aad9603aed90d607e58db69f0789eac7cb6a3c1e Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0266.001; Thu, 11 Feb 2016 13:54:15 -0600 From: JOEY BOYD To: "netmod@ietf.org" Thread-Topic: Module and Submodule Revision Dates Thread-Index: AdFlBfwCjgp4QFTHTZ+L7FKfGLOE+g== Date: Thu, 11 Feb 2016 19:54:14 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654E83068CE@ex-mb1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=YN2ZvEyx c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=pgp4GKyM2coA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=jFJIQSaiL_oA:10 a=kvFZ9vk] X-AnalysisOut: [IFui3wI4zJAMA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016021105); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: Subject: [netmod] Module and Submodule Revision Dates 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, 11 Feb 2016 19:54:19 -0000 Hi all, In RFC6087, there's a statement under Lifecycle Management regarding the re= vision date of a module with respect to its submodules. "If submodules are used, then the document containing the main module MUST = be updated so that the main module revision date is equal or more recent = than the revision date of any submodule that is (directly or indirectly) in= cluded by the main module." In the Broadband Forum, we weren't aware of this statement until our models= were validated using another tool besides pyang which flagged an error as = our main modules' revision dates were older than some of their submodules. = We were wondering why pyang does not check for this when using the --lint = option as it seems to validate RFC6087 requirements. Is this just an overs= ight or are we interpreting something incorrectly? Best Regards, Joey From nobody Thu Feb 11 12:01:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB221B39E2 for ; Thu, 11 Feb 2016 12:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5kSdNy1tquo for ; Thu, 11 Feb 2016 12:01:08 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA231B39C3 for ; Thu, 11 Feb 2016 12:00:46 -0800 (PST) Received: from unknown [76.164.174.81] by p01c11o144.mxlogic.net(mxl_mta-8.5.0-6) over TLS secured channel with SMTP id d68ecb65.0.3945677.00-169.11096660.p01c11o144.mxlogic.net (envelope-from ); Thu, 11 Feb 2016 13:00:46 -0700 (MST) X-MXL-Hash: 56bce86e52d497d5-06d1ad271e427fac49465c33b08ba74fdf569781 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0266.001; Thu, 11 Feb 2016 14:00:38 -0600 From: JOEY BOYD To: "netmod@ietf.org" Thread-Topic: Case Statements in Groupings Thread-Index: AdFlBuBkykRgCjRNReq6/Ck26+X3KQ== Date: Thu, 11 Feb 2016 20:00:37 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654E8306927@ex-mb1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=C+XvvF7+ c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=pgp4GKyM2coA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=jFJIQSaiL_oA:10 a=gmypUIZ] X-AnalysisOut: [jGGDJn3xN5AQA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016021105); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: Subject: [netmod] Case Statements in Groupings 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, 11 Feb 2016 20:01:09 -0000 Hi all, Currently, it's not allowed to do the following as you cannot wrap case sta= tements in a grouping. grouping common-cases { case b { leaf b { } } case c { leaf c { } } } container alpha { choice my-first-choice { case a { leaf a { } } uses common-cases; } } container beta { choice my-second-choice { case d { leaf d { } } uses common-cases; } } I was wondering why this restriction is in place. I know you have to be ca= reful with name collisions but that's true of just a grouping of leafs. Am= I missing something? Best Regards, Joey From nobody Fri Feb 12 00:19:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8561B419D for ; Fri, 12 Feb 2016 00:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Jaw-ygzYO68m for ; Fri, 12 Feb 2016 00:19: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 9B4151ABD36 for ; Fri, 12 Feb 2016 00:19: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 A6461122D; Fri, 12 Feb 2016 09:19: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 NKBE80rUfqFx; Fri, 12 Feb 2016 09:19: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; Fri, 12 Feb 2016 09:19:29 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 682432002C; Fri, 12 Feb 2016 09:19:29 +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 eNRS3IgAgdwV; Fri, 12 Feb 2016 09:19:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AD7C2002B; Fri, 12 Feb 2016 09:19:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 875AC39E458D; Fri, 12 Feb 2016 09:19:28 +0100 (CET) Date: Fri, 12 Feb 2016 09:19:28 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160212081928.GA57886@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> <56BB7726.3060403@cisco.com> <20160211092903.GB54295@elstar.local> <56BCA02B.6080406@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BCA02B.6080406@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt 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, 12 Feb 2016 08:19:35 -0000 On Thu, Feb 11, 2016 at 02:52:27PM +0000, Robert Wilton wrote: > > On 11/02/2016 09:29, Juergen Schoenwaelder wrote: > >We are discussing this text: > > > > D. The configuration protocol MUST specify how configuration > > errors are handled. Errors SHOULD be handled by semantics > > similar to NETCONF's error-options for the > > operation (stop-on-error, continue-on-error, rollback-on- > > error), as described in Section 7.2 in [RFC6241], but > > extended to incorporate both the intended and applied > > configurations. Support for "rollback on error" semantics > > SHOULD be provided. > > > >First, let me observe that it is underspecified what a 'configuration > >error' is in the context of this requirement statement. Is the > >configuration of an interface that is currently not present a > >configuration error? > My opinion is yes, this is an error and hence would cause configuration > to fail and rollback if "rollback-on-error" semantics had been requested. > > If the request had used continue-on-error semantics then I would expect > that you would see this configuration in intended, but not applied. > > > If not, does it become a configuration error if a > >line card is inserted to which the configuration can not be applied? > As above, this question doesn't directly apply. > > But a similar question might be: what would happen if the configuration > had previously been accepted and then a linecard removed? In this case > the the affected interface configuration would stay in intended but be > removed from applied by the system. Looks like the semantics you describe are somewhat inconsistent. BTW, I have been told that 'some operators' do provision configuration for hardware not yet present. RFC 7223 has been designed to allow this to happen. Anyway, this is an example. The point is that it is not clear cut whether something that can't be immediately applied really is an error. > >Note that NETCONF together with YANG provides a rather clear > >definition what validation of a configuration datastore means. When we > >talk about applied config and the difference between intended and > >applied config, the notion of what is a configuration error is not > >clear cut anymore. > Personally, I agree that having tighter semantics are a good thing here > (and should be covered by the solution draft). Then I note that the requirement is at least not well defined. > >Second, in order to rollback, there needs to be a configuration that > >can be safely rolled back into. The only robust way I can imagine to > >implement this rollback requirement is to use locks until the whole > >new config has been applied, thereby turning an asynchronous system > >into a synchronous system. Otherwise, I fail to see how I can ensure > >that I have a configuration that can be safely rolled back into. > Locks are the simplest way of implementing this, but I agree that they > defeat the point of async configuration updates. > > I don't think that locking is the only way to solve this. I would have > thought that one of the optimistic transactional locking approaches > could be used to process multiple requests concurrently. As long as it is clear to which configuration to roll back to. Once you process multiple requests concurrently, this is not at all clear, at least not to me. > Hence, I think that the decision as to whether or not to use a global > lock should probably be specified during the client operation (if at > all), and the solution draft shouldn't enforce always using a server > side lock. Instead it should specify the exact semantics that a client > can expect when interacting with the server during configuration > requests. This is to allow for flexibility in server implementations - > i.e. to trade off complexity for performance. If it is unclear from the specification what the result of a rollback is, then I believe this serves little value. And see the previous examples; what can be applied at time t in general depends on the overall state of the system at time t. YANG does not allow config true nodes to depend on config false nodes and the reason is that configuration validity must not depend on the time varying operational state of a device. /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 Feb 12 01:41:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7866B1B426A for ; Fri, 12 Feb 2016 01:41:31 -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, RP_MATCHES_RCVD=-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 KdPvDzxWP6lG for ; Fri, 12 Feb 2016 01:41:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFAFB1B4268 for ; Fri, 12 Feb 2016 01:41:29 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id C772C1AE018C; Fri, 12 Feb 2016 10:41:27 +0100 (CET) Date: Fri, 12 Feb 2016 10:41:31 +0100 (CET) Message-Id: <20160212.104131.528970231249356594.mbj@tail-f.com> To: joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: <26CE489EF4611643B3EFE43D06E02654E83068CE@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654E83068CE@ex-mb1.corp.adtran.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] Module and Submodule Revision Dates 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, 12 Feb 2016 09:41:31 -0000 JOEY BOYD wrote: > Hi all, > > In RFC6087, there's a statement under Lifecycle Management regarding > the revision date of a module with respect to its submodules. > > "If submodules are used, then the document containing the main module > MUST be updated so that the main module revision date is equal or more > recent than the revision date of any submodule that is (directly or > indirectly) included by the main module." > > In the Broadband Forum, we weren't aware of this statement until our > models were validated using another tool besides pyang which flagged > an error as our main modules' revision dates were older than some of > their submodules. We were wondering why pyang does not check for this > when using the --lint option as it seems to validate RFC6087 > requirements. Is this just an oversight or are we interpreting > something incorrectly? An oversight in the tool. [Please report this as a bug at https://github.com/mbj4668/pyang] /martin From nobody Fri Feb 12 01:47:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7CB1B4277 for ; Fri, 12 Feb 2016 01:47:36 -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, RP_MATCHES_RCVD=-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 FXhgYwC8qNmi for ; Fri, 12 Feb 2016 01:47:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F28E01B4263 for ; Fri, 12 Feb 2016 01:47:34 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 256FB1AE018C; Fri, 12 Feb 2016 10:47:34 +0100 (CET) Date: Fri, 12 Feb 2016 10:47:38 +0100 (CET) Message-Id: <20160212.104738.158068329934459384.mbj@tail-f.com> To: joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: <26CE489EF4611643B3EFE43D06E02654E8306927@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654E8306927@ex-mb1.corp.adtran.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] Case Statements in Groupings 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, 12 Feb 2016 09:47:36 -0000 JOEY BOYD wrote: > Hi all, > > Currently, it's not allowed to do the following as you cannot wrap > case statements in a grouping. > > grouping common-cases { > case b { > leaf b { > } > } > > case c { > leaf c { > } > } > } > > container alpha { > choice my-first-choice { > case a { > leaf a { > } > } > > uses common-cases; > } > } > > container beta { > choice my-second-choice { > case d { > leaf d { > } > } > uses common-cases; > } > } > > > > I was wondering why this restriction is in place. I know you have to > be careful with name collisions but that's true of just a grouping of > leafs. Am I missing something? This could maybe have been considered. Such a grouping would of course only be allowed to be used in a choice, and it would be limited to define *only* case nodes. As such it is a bit different than other groupings. Note that you can achieve a similar effect by doing: grouping choice-with-common-cases { choice the-choice { case b { leaf b { } } case c { leaf c { } } } } container alpha { uses choice-with-common-cases { augment "the-choice" { case a { leaf a { } } } } } container beta { uses choice-with-common-cases { augment "the-choice" { case d { leaf d { } } } } } /martin From nobody Fri Feb 12 06:06:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6AE1A0178 for ; Fri, 12 Feb 2016 06:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 MvzNg6Eu9r04 for ; Fri, 12 Feb 2016 06:06: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 762D81A0171 for ; Fri, 12 Feb 2016 06:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7232; q=dns/txt; s=iport; t=1455285992; x=1456495592; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PYhZOo+hQiaqeXL5M5AY2rAgYpoUM3XfJVtgsSmQEfI=; b=ctAyMyo021czQBU7cNQUm9utTAJLYI8vhCO1lvhf7PYu1m8dMtoGE6oo CJlArqG6mMxrcGn0xaau+5C6vNIwF+uMrwIrJtdyv9pAPlC4qsPKe94tF 6KcR5IUVelBNe/XU77Y2j/ZShId6ioE//jytB2nZva7Jq1o6gBJGdAa44 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBACh5r1W/xbLJq1ejVSzJ4YNAoIDA?= =?us-ascii?q?QEBAQEBgQALhEEBAQEDAThABgsLGAkWDwkDAgECAUUGDQgBAReHdwjBTwEBAQE?= =?us-ascii?q?BAQEDAQEBAQEbhhGENoQahFIBBIdQhwaEBYQciDyFGYkkgRqEOI4+YoNkPIchJ?= =?us-ascii?q?YESAQEB?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="631418609" 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; 12 Feb 2016 14:06:15 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1CE6FCA001854 for ; Fri, 12 Feb 2016 14:06:15 GMT To: "netmod@ietf.org" References: <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> <56BB7726.3060403@cisco.com> <20160211092903.GB54295@elstar.local> <56BCA02B.6080406@cisco.com> <20160212081928.GA57886@elstar.local> From: Robert Wilton Message-ID: <56BDE6D7.5060404@cisco.com> Date: Fri, 12 Feb 2016 14:06:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160212081928.GA57886@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-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: Fri, 12 Feb 2016 14:06:39 -0000 On 12/02/2016 08:19, Juergen Schoenwaelder wrote: > On Thu, Feb 11, 2016 at 02:52:27PM +0000, Robert Wilton wrote: >> On 11/02/2016 09:29, Juergen Schoenwaelder wrote: >>> We are discussing this text: >>> >>> D. The configuration protocol MUST specify how configuration >>> errors are handled. Errors SHOULD be handled by semantics >>> similar to NETCONF's error-options for the >>> operation (stop-on-error, continue-on-error, rollback-on- >>> error), as described in Section 7.2 in [RFC6241], but >>> extended to incorporate both the intended and applied >>> configurations. Support for "rollback on error" semantics >>> SHOULD be provided. >>> >>> First, let me observe that it is underspecified what a 'configuration >>> error' is in the context of this requirement statement. Is the >>> configuration of an interface that is currently not present a >>> configuration error? >> My opinion is yes, this is an error and hence would cause configuration >> to fail and rollback if "rollback-on-error" semantics had been requested. >> >> If the request had used continue-on-error semantics then I would expect >> that you would see this configuration in intended, but not applied. >> >>> If not, does it become a configuration error if a >>> line card is inserted to which the configuration can not be applied? >> As above, this question doesn't directly apply. >> >> But a similar question might be: what would happen if the configuration >> had previously been accepted and then a linecard removed? In this case >> the the affected interface configuration would stay in intended but be >> removed from applied by the system. > Looks like the semantics you describe are somewhat inconsistent. OK, they were not meant to be inconsistent at all: - The intended configuration is what the operator wants, and can only be changed by the operator. - The applied configuration is what state the system is in, and should be continuously kept up to date with the current system state. - If a config change completes without any errors that means that for every node in the changeset, the applied config node matches the intended config node. - This is why I would say that the cleanest semantics are that attempting to configure an interface that doesn't exist should be regarded as a config apply error. (If the operator wants to push this config in then I think that they should be using the continue-on-error option - or perhaps something similar). > BTW, > I have been told that 'some operators' do provision configuration for > hardware not yet present. RFC 7223 has been designed to allow this to > happen. Anyway, this is an example. The point is that it is not clear Yes. I'm not opposed to this on principal, but if a choice of semantics are supported then it should be down the operators request to choose the semantics. Having rules that give flexibility in how a device is allowed to behave just makes them more difficult for the operator to manage. > cut whether something that can't be immediately applied really is an > error. > >>> Note that NETCONF together with YANG provides a rather clear >>> definition what validation of a configuration datastore means. When we >>> talk about applied config and the difference between intended and >>> applied config, the notion of what is a configuration error is not >>> clear cut anymore. >> Personally, I agree that having tighter semantics are a good thing here >> (and should be covered by the solution draft). > Then I note that the requirement is at least not well defined. Perhaps, but we had already spent a long time discussing the requirements draft, hence personally I think that it is OK to specify/agree the precise semantics/behaviour in a solution draft. > >>> Second, in order to rollback, there needs to be a configuration that >>> can be safely rolled back into. The only robust way I can imagine to >>> implement this rollback requirement is to use locks until the whole >>> new config has been applied, thereby turning an asynchronous system >>> into a synchronous system. Otherwise, I fail to see how I can ensure >>> that I have a configuration that can be safely rolled back into. >> Locks are the simplest way of implementing this, but I agree that they >> defeat the point of async configuration updates. >> >> I don't think that locking is the only way to solve this. I would have >> thought that one of the optimistic transactional locking approaches >> could be used to process multiple requests concurrently. > As long as it is clear to which configuration to roll back to. Once > you process multiple requests concurrently, this is not at all clear, > at least not to me. Logically, the system must revert to a state where the failed configuration request was never applied. I think this is the only guarantee that is being made to the client. One way to achieve this would be rollback the configuration (intended and applied) back to exactly the point before that failed request (or any other request) was processed. Any concurrent configuration requests that were previously in progress would then need to be re-applied one by one (in the same order). Each of these could fail in a similar way. It may be possible to optimize this behavior, but I'm not sure whether that would be particularly useful - the working assumption here is that in the mainline case you would expect that the vast majority of configuration updates shouldn't fail. > >> Hence, I think that the decision as to whether or not to use a global >> lock should probably be specified during the client operation (if at >> all), and the solution draft shouldn't enforce always using a server >> side lock. Instead it should specify the exact semantics that a client >> can expect when interacting with the server during configuration >> requests. This is to allow for flexibility in server implementations - >> i.e. to trade off complexity for performance. > If it is unclear from the specification what the result of a rollback > is, then I believe this serves little value. And see the previous The specification of the result after rollback does need to be specified and included in the solution draft. > examples; what can be applied at time t in general depends on the > overall state of the system at time t. YANG does not allow config true > nodes to depend on config false nodes and the reason is that > configuration validity must not depend on the time varying operational > state of a device. Yes, I agree with that. But I think that there is a clear separation between whether a configuration is semantically valid and whether it can be successfully applied: Whether the configuration is semantically valid must only rely on the configuration. But whether or not the configuration is able to be applied can and does depend on the operational state of the device (memory, what LCs are present, correct functioning of the code, etc). Rob > > /js > From nobody Fri Feb 12 06:53:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566561A19F7 for ; Fri, 12 Feb 2016 06:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, 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 BgVriFHDviFW for ; Fri, 12 Feb 2016 06:53:19 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A5B1A0BE8 for ; Fri, 12 Feb 2016 06:53:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5A16C1E5A36; Fri, 12 Feb 2016 06:53:00 -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 ka3Wt9TpmNjk; Fri, 12 Feb 2016 06:53:00 -0800 (PST) Received: from [192.168.1.100] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id 9B3941E5A35; Fri, 12 Feb 2016 06:52:59 -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: <20160211135503.GA54817@elstar.local> Date: Fri, 12 Feb 2016 14:53:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2868EE43-8591-4551-8CED-03198389BD0A@broadband-forum.org> References: <4BFFC9D8-55FE-4296-B929-8B85305918E8@broadband-forum.org> <20160211135503.GA54817@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Restricting interface name maximum length and character set 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, 12 Feb 2016 14:53:21 -0000 Thanks for the reply. No other BBF specs (that I am aware of) require = such restrictions. I (personally) think that handling this as a device = requirement is a fine solution, but we wanted to check what people = thought of trying to define such restrictions in the YANG. BTW, we were thinking of: maximum length (64) and restricted character = set (ASCII 32-126). William > On 11 Feb 2016, at 13:55, Juergen Schoenwaelder = wrote: >=20 > On Thu, Feb 11, 2016 at 12:22:19PM +0000, William Lupton wrote: >> All, >>=20 >> Here in the Broadband Forum we are defining YANG modules that augment = RFC 7223 ietf-interfaces. We want to limit interface name maximum length = and character set but don't see a way of doing this in the YANG. >>=20 >> Can/should we do do this in the YANG, or should it just be a = device-level requirement? >>=20 >=20 > I wonder why you want to do this. Is it because other existing BBF > specifications break if interfaces can have long names and use Unicode > characters? Out of curiosity, what would be the length and character > set restriction BBF finds a good choice? >=20 > A deviation statement describes how an implementation deviates from a > data model. It was not the intent that an SDO defines a 'standard' > deviation for a data model (the term 'profile' might be more > appropriate for this). >=20 > Note that these kind of 'profiles' often do not combine well. If BBF > says the max length is N and MEF says that max length is N with N !=3D > M, then an implementor has a hard time to produce a device that > satisfies both requirements. (All one can do is to use min(N,M) and > then annouce a deviation to the profiles affected, all getting pretty > ugly soon, in particular if the common native interface names may be > longer than N and M.) >=20 > I understand that 'arbitrarily long' may sound ridiculous. But having > an implementation announce its real limit instead of a data model or > 'profile' imposed limit seems simpler and more robust to me. >=20 > /js >=20 > PS: On Windows, MAX_ADAPTER_NAME_LENGTH seems to be 256, on Linux > IF_NAMESIZE seems to be 16, on FreeBSD and MacOS IF_NAMESIZE seems > to be 16 as well (but there are likely systems derived from > FreeBSD that use a different constant, may also be true for Linux > - and most likely people change this constant for a reason). >=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 From nobody Fri Feb 12 08:32:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D001A6F64 for ; Fri, 12 Feb 2016 08:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 CZ_2IY5jpkgl for ; Fri, 12 Feb 2016 08:32:08 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d: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 E1C911A6F5D for ; Fri, 12 Feb 2016 08:32:07 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id b67so66009325qgb.1 for ; Fri, 12 Feb 2016 08:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=/Tfu7m9CSK0rkI29ubys5uDvb7fXRryRmyZGooO5oRo=; b=XML17efqTO8FtvFmudwTw7cwBxf15b4gSHec9xIHDabFa9JFvubHj5SMNJLnW5iOgD EZCG1WT5ssiNOdK85FkM0ApNaEZRV+PDQR9/x5L/Jn9VOMJjxv3b57FD9Q3PYrkP1Lq9 GJgg5Z5QTkazhQYQxh7e9V95GrCfDXNuHiKiutGlPK+DeGEy/7mPKH1qInp+LiEHmZhd udiOQxEGXatboKQWwkB+mNFukdo4xLhmBaz8rNbbW/oxC/dgu+NEBTj2RZihI8ojNwGO gwCLQ24HeM11wyXw36hnGgP/pcJVUuPjbGz+A1cpzeiSeSRqEZJsqlxTRQbqSkn3d+1g h0Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=/Tfu7m9CSK0rkI29ubys5uDvb7fXRryRmyZGooO5oRo=; b=ZarF3LwTdOPvgJYEbAhEDGxZDnZXsLKri7hL45thMuXgt/DEoSwV74yWdla0BXMFo5 zhP+C9XhXp9GFLD86H+ytgj1XIFnb7XIv9GdhjckDB1hDNzfoEiLlsZL31szvzZBFBGd fHKd6wjuHG12O8ejujhUmbZoPqfam+/c1XZmWDhYksPICPzYJmiFeNlYfDT8UTDV7nOf XfC5+2FPmueDq3P4epXjAfyqgQUpkWa8oLTrsOpU+WF7wzNBsLuLFEWE9reinizbGgzd lY3xmcW3vAmLiH2cvRZc0ZdsLwP34/mBFPtCjvLQnZbQEJ66Y19rcuCcuVPgcGErSccU Bu6A== X-Gm-Message-State: AG10YOTCgZ5V3df9uX9ZcxcFxUyjLSfwyizx2FvInYyNia3YevNX+QIs4EifXQ5LS3I3EoB791ixyQHyMr1xGg== MIME-Version: 1.0 X-Received: by 10.140.101.108 with SMTP id t99mr3120846qge.24.1455294727123; Fri, 12 Feb 2016 08:32:07 -0800 (PST) Received: by 10.55.27.162 with HTTP; Fri, 12 Feb 2016 08:32:07 -0800 (PST) Date: Fri, 12 Feb 2016 10:32:07 -0600 Message-ID: From: Behcet Sarikaya To: NETMOD WG , Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [netmod] draft-ietf-netmod-routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:32:08 -0000 Hi Lada, When trying to validate NETCONF get reply in Appendix D, I ran into a problem: This annex introduces a namespace iana-if-types and none of the YANG modules of ietf-routing-cfg is dependent on this namespace. As a result, the NETCONF tool that I am using could not recognize ethernetCdmacd when it comes to the line ianaift:ethernetCsmacd I know that iana-if-types is defined at the beginning of the rpc reply but it seems like those declarations are simply ignored. Do you offer any solution? Regards, Behcet From nobody Fri Feb 12 08:51:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08031A6FE2 for ; Fri, 12 Feb 2016 08:51:23 -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 iIN0sVdd_CJT for ; Fri, 12 Feb 2016 08:51:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198201A6FD9 for ; Fri, 12 Feb 2016 08:51:20 -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.403.16; Fri, 12 Feb 2016 16:51:18 +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.0403.017; Fri, 12 Feb 2016 16:51:17 +0000 From: Kent Watsen To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt Thread-Index: AQHRXeLKOW+rjqCc7kiS321+Ltbrbp8dt6+AgAADfQCABJrigIAADGqAgAAkxgCAAsCBgIAAUg4AgAEHt4CAAFpcgIABJIgAgABg5ID//9pLgA== Date: Fri, 12 Feb 2016 16:51:17 +0000 Message-ID: <0003790F-237C-4366-8847-349491C38443@juniper.net> References: <56B4DA3B.7080504@cisco.com> <20160205173432.GA24243@elstar.local> <20160208163821.GC29638@elstar.local> <20160210125129.GB52549@elstar.local> <56BB7726.3060403@cisco.com> <20160211092903.GB54295@elstar.local> <56BCA02B.6080406@cisco.com> <20160212081928.GA57886@elstar.local> <56BDE6D7.5060404@cisco.com> In-Reply-To: <56BDE6D7.5060404@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.160109 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:w3OGWcPeJNL7clghZFAbLf1woXUaoRqx+TVis9nQNjxX3q0dCm4xmYTPt4HNwUxLEWkM9hTxhut8cThoy+1uXDlr0FEPve4mju6mg4r/vMRobzU8nwU5XSzaTjEilG124tUKy+IGHBntptea0GLUQA==; 24:iIJDjCJf7o3yEfdu8649Wn2UAwNPi8VqannhMuYUTJhQ5BZOaCq8qhSjZkz2PYwe38ovLLi00GADqcf6p9PIkc4oyQA6cCyaKwaGuPEgS5w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 02a47005-1229-432b-2df9-08d333ccba37 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)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(51444003)(5004730100002)(1096002)(106116001)(1220700001)(86362001)(189998001)(36756003)(102836003)(3846002)(10400500002)(93886004)(77096005)(33656002)(230783001)(2906002)(3280700002)(2501003)(99286002)(82746002)(6116002)(4001350100001)(122556002)(66066001)(87936001)(5002640100001)(5001770100001)(107886002)(5001960100002)(2900100001)(54356999)(40100003)(50986999)(76176999)(3660700001)(5008740100001)(83716003)(2950100001)(83506001)(92566002)(586003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 12 Feb 2016 16:51:17.8489 (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-kwatsen-netmod-opstate-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: Fri, 12 Feb 2016 16:51:23 -0000 W0FzIGEgY29udHJpYnV0b3JdDQoNCg0KDQoNCj4+Pj4gICBJZiBub3QsIGRvZXMgaXQgYmVjb21l IGEgY29uZmlndXJhdGlvbiBlcnJvciBpZiBhDQo+Pj4+IGxpbmUgY2FyZCBpcyBpbnNlcnRlZCB0 byB3aGljaCB0aGUgY29uZmlndXJhdGlvbiBjYW4gbm90IGJlIGFwcGxpZWQ/DQo+Pj4gQXMgYWJv dmUsIHRoaXMgcXVlc3Rpb24gZG9lc24ndCBkaXJlY3RseSBhcHBseS4NCj4+Pg0KPj4+IEJ1dCBh IHNpbWlsYXIgcXVlc3Rpb24gbWlnaHQgYmU6IHdoYXQgd291bGQgaGFwcGVuIGlmIHRoZSBjb25m aWd1cmF0aW9uDQo+Pj4gaGFkIHByZXZpb3VzbHkgYmVlbiBhY2NlcHRlZCBhbmQgdGhlbiBhIGxp bmVjYXJkIHJlbW92ZWQ/ICBJbiB0aGlzIGNhc2UNCj4+PiB0aGUgdGhlIGFmZmVjdGVkIGludGVy ZmFjZSBjb25maWd1cmF0aW9uIHdvdWxkIHN0YXkgaW4gaW50ZW5kZWQgYnV0IGJlDQo+Pj4gcmVt b3ZlZCBmcm9tIGFwcGxpZWQgYnkgdGhlIHN5c3RlbS4NCj4+IExvb2tzIGxpa2UgdGhlIHNlbWFu dGljcyB5b3UgZGVzY3JpYmUgYXJlIHNvbWV3aGF0IGluY29uc2lzdGVudC4NCj5PSywgdGhleSB3 ZXJlIG5vdCBtZWFudCB0byBiZSBpbmNvbnNpc3RlbnQgYXQgYWxsOg0KPg0KPi0gVGhlIGludGVu ZGVkIGNvbmZpZ3VyYXRpb24gaXMgd2hhdCB0aGUgb3BlcmF0b3Igd2FudHMsIGFuZCBjYW4gb25s eSBiZSANCj5jaGFuZ2VkIGJ5IHRoZSBvcGVyYXRvci4NCj4tIFRoZSBhcHBsaWVkIGNvbmZpZ3Vy YXRpb24gaXMgd2hhdCBzdGF0ZSB0aGUgc3lzdGVtIGlzIGluLCBhbmQgc2hvdWxkIA0KPmJlIGNv bnRpbnVvdXNseSBrZXB0IHVwIHRvIGRhdGUgd2l0aCB0aGUgY3VycmVudCBzeXN0ZW0gc3RhdGUu DQo+DQo+LSBJZiBhIGNvbmZpZyBjaGFuZ2UgY29tcGxldGVzIHdpdGhvdXQgYW55IGVycm9ycyB0 aGF0IG1lYW5zIHRoYXQgZm9yIA0KPmV2ZXJ5IG5vZGUgaW4gdGhlIGNoYW5nZXNldCwgdGhlIGFw cGxpZWQgY29uZmlnIG5vZGUgbWF0Y2hlcyB0aGUgDQo+aW50ZW5kZWQgY29uZmlnIG5vZGUuDQo+ LSBUaGlzIGlzIHdoeSBJIHdvdWxkIHNheSB0aGF0IHRoZSBjbGVhbmVzdCBzZW1hbnRpY3MgYXJl IHRoYXQgDQo+YXR0ZW1wdGluZyB0byBjb25maWd1cmUgYW4gaW50ZXJmYWNlIHRoYXQgZG9lc24n dCBleGlzdCBzaG91bGQgYmUgDQo+cmVnYXJkZWQgYXMgYSBjb25maWcgYXBwbHkgZXJyb3IuICAo SWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIHB1c2ggdGhpcyANCj5jb25maWcgaW4gdGhlbiBJIHRo aW5rIHRoYXQgdGhleSBzaG91bGQgYmUgdXNpbmcgdGhlIGNvbnRpbnVlLW9uLWVycm9yIA0KPm9w dGlvbiAtIG9yIHBlcmhhcHMgc29tZXRoaW5nIHNpbWlsYXIpLg0KDQpJIGRpc2FncmVlLiAgSlVO T1Mgc3BlY2lmaWNhbGx5IGFsbG93cyBmb3IgcHJlY29uZmlndXJhdGlvbiBmb3IgaGFyZHdhcmUg dGhhdCBkb2VzIG5vdCBleGlzdHMgeWV0LiAgSXTigJlzIGEgd2VsbC1yZWdhcmRlZCBmZWF0dXJl LiAgSXQgaXMgbm90IGFuIGVycm9yLCBidXQgbWF5IGJlIHJlcG9ydGVkIGFzIGEgd2FybmluZy4g IFRoaXMgaXMgd2h5IHdlIGRlZmluZWQgbGVhZiAiYXBwbHktd2FybmluZ+KAnSBpbiB0aGlzIGRy YWZ0IChzZWUgc3ViamVjdCBsaW5lKS4gIFRoYXQgc2FpZCwgSSBkbyBhZ3JlZSB0aGF0IHRoZSBh cHBsaWVkIGNvbmZpZ3VyYXRpb24gd291bGQgbm90IGhhdmUgdGhlIGNvbmZpZyBmb3IgdGhlIG1p c3NpbmcgaGFyZHdhcmUsIGFzIHdvdWxkIGJlIGV2aWRlbnQgaW4gYSBkaWZmIGJldHdlZW4gaXQg YW5kIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uLiAgDQoNCg0KDQo+PiAgIEJUVywNCj4+IEkg aGF2ZSBiZWVuIHRvbGQgdGhhdCAnc29tZSBvcGVyYXRvcnMnIGRvIHByb3Zpc2lvbiBjb25maWd1 cmF0aW9uIGZvcg0KPj4gaGFyZHdhcmUgbm90IHlldCBwcmVzZW50LiBSRkMgNzIyMyBoYXMgYmVl biBkZXNpZ25lZCB0byBhbGxvdyB0aGlzIHRvDQo+PiBoYXBwZW4uIEFueXdheSwgdGhpcyBpcyBh biBleGFtcGxlLiBUaGUgcG9pbnQgaXMgdGhhdCBpdCBpcyBub3QgY2xlYXINCj5ZZXMuICBJJ20g bm90IG9wcG9zZWQgdG8gdGhpcyBvbiBwcmluY2lwYWwsIGJ1dCBpZiBhIGNob2ljZSBvZiBzZW1h bnRpY3MgDQo+YXJlIHN1cHBvcnRlZCB0aGVuIGl0IHNob3VsZCBiZSBkb3duIHRoZSBvcGVyYXRv cnMgcmVxdWVzdCB0byBjaG9vc2UgdGhlIA0KPnNlbWFudGljcy4gIEhhdmluZyBydWxlcyB0aGF0 IGdpdmUgZmxleGliaWxpdHkgaW4gaG93IGEgZGV2aWNlIGlzIA0KPmFsbG93ZWQgdG8gYmVoYXZl IGp1c3QgbWFrZXMgdGhlbSBtb3JlIGRpZmZpY3VsdCBmb3IgdGhlIG9wZXJhdG9yIHRvIG1hbmFn ZS4NCg0KSSB0aGluayB0aGF0IHRoaXMgZG9lc27igJl0IHNjYWxlLiAgQnkgdGhpcyB0b2tlbiwg c2VydmVycyBzaG91bGQgc3VwcG9ydCBldmVyeXRoaW5nIHRoZSBJRVRGIGRlZmluZXMuICBCdXQg dGhhdOKAmXMgbm90IGhvdyBpdCB3b3JrcywgaW5zdGVhZCB3ZSBoYXZlIGZlYXR1cmVzIGFuZCBj YXBhYmlsaXRpZXMgdGhhdCBlbmFibGUgZGV2aWNlcyB0byBhZHZlcnRpc2Ugd2hhdCB0aGV5IHN1 cHBvcnQuICBUaGlzIGFiaWxpdHkgaXMgaW1wb3J0YW50IHdoZW4gYSBicm93bi1maWVsZCBkZXZp Y2UgaXMgbW92aW5nIHRvIHN1cHBvcnQgTkVUQ09ORi9SRVNUQ09ORiBidXQgY2Fu4oCZdCBicmVh ayBjb21wYXRpYmlsaXR5IHdpdGggaXRzIGxlZ2FjeSBBUElzLg0KDQoNCg0KPj4+Pk5vdGUgdGhh dCBORVRDT05GIHRvZ2V0aGVyIHdpdGggWUFORyBwcm92aWRlcyBhIHJhdGhlciBjbGVhcg0KPj4+ PiBkZWZpbml0aW9uIHdoYXQgdmFsaWRhdGlvbiBvZiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IG1lYW5zLiBXaGVuIHdlDQo+Pj4+IHRhbGsgYWJvdXQgYXBwbGllZCBjb25maWcgYW5kIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gaW50ZW5kZWQgYW5kDQo+Pj4+IGFwcGxpZWQgY29uZmlnLCB0aGUg bm90aW9uIG9mIHdoYXQgaXMgYSBjb25maWd1cmF0aW9uIGVycm9yIGlzIG5vdA0KPj4+PiBjbGVh ciBjdXQgYW55bW9yZS4NCj4+PiBQZXJzb25hbGx5LCBJIGFncmVlIHRoYXQgaGF2aW5nIHRpZ2h0 ZXIgc2VtYW50aWNzIGFyZSBhIGdvb2QgdGhpbmcgaGVyZQ0KPj4+IChhbmQgc2hvdWxkIGJlIGNv dmVyZWQgYnkgdGhlIHNvbHV0aW9uIGRyYWZ0KS4NCj4+IFRoZW4gSSBub3RlIHRoYXQgdGhlIHJl cXVpcmVtZW50IGlzIGF0IGxlYXN0IG5vdCB3ZWxsIGRlZmluZWQuDQo+UGVyaGFwcywgYnV0IHdl IGhhZCBhbHJlYWR5IHNwZW50IGEgbG9uZyB0aW1lIGRpc2N1c3NpbmcgdGhlIA0KPnJlcXVpcmVt ZW50cyBkcmFmdCwgaGVuY2UgcGVyc29uYWxseSBJIHRoaW5rIHRoYXQgaXQgaXMgT0sgdG8gDQo+ c3BlY2lmeS9hZ3JlZSB0aGUgcHJlY2lzZSBzZW1hbnRpY3MvYmVoYXZpb3VyIGluIGEgc29sdXRp b24gZHJhZnQuDQoNCk5vdCBqdXN0IHRoYXQsIGJ1dCBpdCB3YXMgdGhlIGRlY2lzaW9uIHdlIG1h ZGUgYXMgYSBXRywgYW5kIHdoeSB0aGUgcmVxdWlyZW1lbnRzIHNheSAiVGhlIGNvbmZpZ3VyYXRp b24gcHJvdG9jb2wgTVVTVCBzcGVjaWZ5IGhvdyBjb25maWd1cmF0aW9uIGVycm9ycyBhcmUgaGFu ZGxlZC7igJ0gLSByaWdodD8NCg0KDQoNCj4+Pj4gU2Vjb25kLCBpbiBvcmRlciB0byByb2xsYmFj aywgdGhlcmUgbmVlZHMgdG8gYmUgYSBjb25maWd1cmF0aW9uIHRoYXQNCj4+Pj4gY2FuIGJlIHNh ZmVseSByb2xsZWQgYmFjayBpbnRvLiBUaGUgb25seSByb2J1c3Qgd2F5IEkgY2FuIGltYWdpbmUg dG8NCj4+Pj4gaW1wbGVtZW50IHRoaXMgcm9sbGJhY2sgcmVxdWlyZW1lbnQgaXMgdG8gdXNlIGxv Y2tzIHVudGlsIHRoZSB3aG9sZQ0KPj4+PiBuZXcgY29uZmlnIGhhcyBiZWVuIGFwcGxpZWQsIHRo ZXJlYnkgdHVybmluZyBhbiBhc3luY2hyb25vdXMgc3lzdGVtDQo+Pj4+IGludG8gYSBzeW5jaHJv bm91cyBzeXN0ZW0uIE90aGVyd2lzZSwgSSBmYWlsIHRvIHNlZSBob3cgSSBjYW4gZW5zdXJlDQo+ Pj4+IHRoYXQgSSBoYXZlIGEgY29uZmlndXJhdGlvbiB0aGF0IGNhbiBiZSBzYWZlbHkgcm9sbGVk IGJhY2sgaW50by4NCj4+PiBMb2NrcyBhcmUgdGhlIHNpbXBsZXN0IHdheSBvZiBpbXBsZW1lbnRp bmcgdGhpcywgYnV0IEkgYWdyZWUgdGhhdCB0aGV5DQo+Pj4gZGVmZWF0IHRoZSBwb2ludCBvZiBh c3luYyBjb25maWd1cmF0aW9uIHVwZGF0ZXMuDQo+Pj4NCj4+PiBJIGRvbid0IHRoaW5rIHRoYXQg bG9ja2luZyBpcyB0aGUgb25seSB3YXkgdG8gc29sdmUgdGhpcy4gIEkgd291bGQgaGF2ZQ0KPj4+ IHRob3VnaHQgdGhhdCBvbmUgb2YgdGhlIG9wdGltaXN0aWMgdHJhbnNhY3Rpb25hbCBsb2NraW5n IGFwcHJvYWNoZXMNCj4+PiBjb3VsZCBiZSB1c2VkIHRvIHByb2Nlc3MgbXVsdGlwbGUgcmVxdWVz dHMgY29uY3VycmVudGx5Lg0KPj4gQXMgbG9uZyBhcyBpdCBpcyBjbGVhciB0byB3aGljaCBjb25m aWd1cmF0aW9uIHRvIHJvbGwgYmFjayB0by4gT25jZQ0KPj4geW91IHByb2Nlc3MgbXVsdGlwbGUg cmVxdWVzdHMgY29uY3VycmVudGx5LCB0aGlzIGlzIG5vdCBhdCBhbGwgY2xlYXIsDQo+PiBhdCBs ZWFzdCBub3QgdG8gbWUuDQo+TG9naWNhbGx5LCB0aGUgc3lzdGVtIG11c3QgcmV2ZXJ0IHRvIGEg c3RhdGUgd2hlcmUgdGhlIGZhaWxlZCANCj5jb25maWd1cmF0aW9uIHJlcXVlc3Qgd2FzIG5ldmVy IGFwcGxpZWQuICBJIHRoaW5rIHRoaXMgaXMgdGhlIG9ubHkgDQo+Z3VhcmFudGVlIHRoYXQgaXMg YmVpbmcgbWFkZSB0byB0aGUgY2xpZW50Lg0KPg0KPk9uZSB3YXkgdG8gYWNoaWV2ZSB0aGlzIHdv dWxkIGJlIHJvbGxiYWNrIHRoZSBjb25maWd1cmF0aW9uIChpbnRlbmRlZCANCj5hbmQgYXBwbGll ZCkgYmFjayB0byBleGFjdGx5IHRoZSBwb2ludCBiZWZvcmUgdGhhdCBmYWlsZWQgcmVxdWVzdCAo b3IgDQo+YW55IG90aGVyIHJlcXVlc3QpIHdhcyBwcm9jZXNzZWQuDQo+DQo+QW55IGNvbmN1cnJl bnQgY29uZmlndXJhdGlvbiByZXF1ZXN0cyB0aGF0IHdlcmUgcHJldmlvdXNseSBpbiBwcm9ncmVz cyANCj53b3VsZCB0aGVuIG5lZWQgdG8gYmUgcmUtYXBwbGllZCBvbmUgYnkgb25lIChpbiB0aGUg c2FtZSBvcmRlcikuICBFYWNoIA0KPm9mIHRoZXNlIGNvdWxkIGZhaWwgaW4gYSBzaW1pbGFyIHdh eS4NCj4NCj5JdCBtYXkgYmUgcG9zc2libGUgdG8gb3B0aW1pemUgdGhpcyBiZWhhdmlvciwgYnV0 IEknbSBub3Qgc3VyZSB3aGV0aGVyIA0KPnRoYXQgd291bGQgYmUgcGFydGljdWxhcmx5IHVzZWZ1 bCAtIHRoZSB3b3JraW5nIGFzc3VtcHRpb24gaGVyZSBpcyB0aGF0IA0KPmluIHRoZSBtYWlubGlu ZSBjYXNlIHlvdSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgdmFzdCBtYWpvcml0eSBvZiANCj5jb25m aWd1cmF0aW9uIHVwZGF0ZXMgc2hvdWxkbid0IGZhaWwuDQoNCkFncmVlZCwgYW5kIHRoYXQgaXMg d2h5IHRoaXMgZHJhZnQgKHNlZSBzdWJqZWN0KSBzYXlzOg0KDQogIEluIG9yZGVyIHRvIGltcGxl bWVudCB0aGUgcm9sbGJhY2sgYmVoYXZpb3IsIGZvciA8ZWRpdC1jb25maWc+IG9yDQogIDxjb21t aXQ+LCBpdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBzZXJ2ZXIgdG8gbWFpbnRhaW4gYSBnbG9iYWwg bG9jaw0KICB1bnRpbCB0aGUgcHJvY2Vzc2luZyBpcyBjb21wbGV0ZS4gIFRoYXQgaXMsIGVpdGhl ciBhICdzeW5jJyByZXF1ZXN0DQogIHJldHVybnMgb3IgYW4gJ2FzeW5jJyByZXF1ZXN0J3MgJ3N5 bmMtY29tcGxldGUnIG5vdGlmaWNhdGlvbiBoYXMgYmVlbg0KICBzZW50LiAgQW55IGF0dGVtcHRz IHRvIHJlYWQgb3Igd3JpdGUgZWl0aGVyIGludGVuZGVkIG9yIGFwcGxpZWQNCiAgY29uZmlndXJh dGlvbiB3aWxsIGJlIGJsb2NrZWQgdW50aWwgdGhlIHJlcXVlc3QgY29tcGxldGVzLg0KDQpQZXJo YXBzIOKAnGdsb2JhbCBsb2Nr4oCdIGlzIG92ZXJyZWFjaGluZywgaWYgdGhlIHN5c3RlbSBzdXBw b3J0cyBwYXJ0aWFsLWxvY2tzLCB0aGVuIGp1c3QgdGhlIGxvY2tzIG92ZXIgdGhlIGltcGFjdGVk IGNvbmZpZyB3b3VsZCBiZSBuZWVkZWQuICBBcmUgd2UgbWl4aW5nIHVwIHN1cHBvcnRpbmcgQXN5 bmNocm9ub3VzIENvbmZpZ3VyYXRpb24gT3BlcmF0aW9uIHdpdGggcGFyYWxsZWwgcHJvY2Vzc2lu Zz8NCg0KDQoNCg0KPkJ1dCBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBjbGVhciBzZXBhcmF0aW9u IGJldHdlZW4gd2hldGhlciBhDQo+Y29uZmlndXJhdGlvbiBpcyBzZW1hbnRpY2FsbHkgdmFsaWQg YW5kIHdoZXRoZXIgaXQgY2FuIGJlIHN1Y2Nlc3NmdWxseSANCj5hcHBsaWVkOg0KPg0KPldoZXRo ZXIgdGhlIGNvbmZpZ3VyYXRpb24gaXMgc2VtYW50aWNhbGx5IHZhbGlkIG11c3Qgb25seSByZWx5 IG9uIHRoZSANCj5jb25maWd1cmF0aW9uLg0KPg0KPkJ1dCB3aGV0aGVyIG9yIG5vdCB0aGUgY29u ZmlndXJhdGlvbiBpcyBhYmxlIHRvIGJlIGFwcGxpZWQgY2FuIGFuZCBkb2VzIA0KPmRlcGVuZCBv biB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIGRldmljZSAobWVtb3J5LCB3aGF0IExDcyBh cmUgDQo+cHJlc2VudCwgY29ycmVjdCBmdW5jdGlvbmluZyBvZiB0aGUgY29kZSwgZXRjKS4NCg0K RldJVywgd2hlbiB3b3JraW5nIG9uIHNvbHV0aW9uICMyLCB3ZSBvcmlnaW5hbGx5IGRlZmluZWQg YSBzZWNvbmRhcnkgZXJyb3Itb3B0aW9uIGNhbGxlZCDigJxhcHBsaWVkLWVycm9yLW9wdGlvbuKA nSB0aGF0IGNvdWxkIGNvbnRyb2wgdGhlIGJlaGF2aW9yIGZvciB0aGUg4oCcYXBwbHnigJ0gcGhh c2Ugb2YgcHJvY2Vzc2luZyBhIGNvbmZpZyByZXF1ZXN0LiAgVGhpcyBiZWNhbWUgZGlmZmljdWx0 IHRvIHNwZWNpZnksIHNvIHdlIGJhY2tlZCBvZmYgYW5kIGRlY2lkZWQgdG8gc2ltcGx5IGxldmVy YWdlIHRoZSBleGlzdGluZyBlcnJvci1vcHRpb24gcGFyYW1ldGVyLCBieSBleHRlbmRpbmcgaXQg dG8gYWxzbyBjb3ZlciB0aGUgYXBwbHkgcGhhc2UsIHdpdGggd2hhdCB3ZSBmZWx0IHdhcyBhbiBp bnR1aXRpdmUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGVycm9yLW9wdGlvbiB2YWx1ZXMuDQoNCg0K S2VudA0KDQoNCg0K From jschistos@gmail.com Mon Feb 15 00:14:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1336F1B2F30 for ; Mon, 15 Feb 2016 00:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.674 X-Spam-Level: ** X-Spam-Status: No, score=2.674 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DEAR_SOMETHING=1.973, 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=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 XY61SvwNO9eI for ; Mon, 15 Feb 2016 00:14:56 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 075E61B2F0C for ; Mon, 15 Feb 2016 00:14:56 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id c3so101417851vkb.3 for ; Mon, 15 Feb 2016 00:14:55 -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 :content-type; bh=LtNu3JEQ2ejWviddFF6nS5C0eiyABBmv2ORgOJijnAc=; b=DfsK9YIBVJ+z+CvKZqXHcrX6AWeCT2YtGYGZXjzqAFHLuzruSa2Yfu4OkQ80bYKggc 9ckZsqLe9nXw6pqFXCViRCQ0hcict91fFlI7MX+AulWCLktOxiK32RfeMPUqRIeg8kEr 81rKSvVHoYnANQwNsAVQFqC+DoybxJUJQfqa6FMqf8CyE2gU6Y+U791xvaGPTErw6nW3 gLNL2TWL3TjcurEf+XIzXMaNrdgu2gQX8wRWzyJnOjuicVtW7vzqGpQVtHwVrC7/Liza LKmbTq+NW8W60gM5mK64UHsV5JV81oi4yebqCL8NUnEUZbBoKImdtAKyH2ubau3cAHuj 9IJw== 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=LtNu3JEQ2ejWviddFF6nS5C0eiyABBmv2ORgOJijnAc=; b=GL03U19PwnAvFx16r1kzubU1X81NIqlTYbTlrygGjW5lBLb6iL7X+1MAEnNvRkhoyI Wym4JxpZ/DQyqiru4GSsXQNHpLdkvQuRnq6CTuCZ8PVzIslAajegj0VVO/UPrCi6LmCk 257ZQ7vpqRrftle2S1qYR4+9ey07+VA61+/FSL1AXTmriPLGM2BCrzrTyahn4kvZsLIY Hna3ozwJq41SxJp7Sfp72ASepmE4P4x30/GVFzGzLia9/SXDkyrwGtMi586BAVJTaakN x7p04IxonUxjDzmOWjrvOByBw1VcahZ2H6Rko9Fl0uODuxkkjsJXwYjxCN9SWl9Vv62k WhHQ== X-Gm-Message-State: AG10YOSkv2NaXvM1A1zODrautIMC8Q89CrzQlVnzw95POxLtmW5U5SQnEIZ3qLTF+weB05vSl/XAVTQGfLUuuQ== MIME-Version: 1.0 X-Received: by 10.31.148.215 with SMTP id w206mr10800514vkd.65.1455524095168; Mon, 15 Feb 2016 00:14:55 -0800 (PST) Received: by 10.31.98.129 with HTTP; Mon, 15 Feb 2016 00:14:55 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Feb 2016 10:14:55 +0200 Message-ID: From: John Schistos To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11425b64a79662052bca9c3b Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 00:46:42 -0800 Subject: [netmod] Fwd: ietf-yang-types.yang ipv6 arbitrary mask 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, 15 Feb 2016 08:16:58 -0000 --001a11425b64a79662052bca9c3b Content-Type: text/plain; charset=UTF-8 Dear Sir or Madam, I would like to know if *ietf-yang-types.yang (**revision 2013-07-15) *supports ipv6 arbitrary mask.I see that this is kind of accomplished with dotted-quad in ipv4, but I wonder if there is something for ipv6? Thank you in advance --001a11425b64a79662052bca9c3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear= Sir or Madam,

I would like to know if ietf-yang-types.yang= (revision 2013-07-15) supports ipv6 arbitrary mask.I see that this is kind of ac= complished with dotted-quad in ipv4, but I wonder if there is something for= ipv6?

Thank you in advance

--001a11425b64a79662052bca9c3b-- From nobody Mon Feb 15 02:51:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6B1AD0A5 for ; Mon, 15 Feb 2016 02:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.608 X-Spam-Level: X-Spam-Status: No, score=-12.608 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_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 19xUCrndWrmP for ; Mon, 15 Feb 2016 02:51:55 -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 D6E3D1ACDBC for ; Mon, 15 Feb 2016 02:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=681; q=dns/txt; s=iport; t=1455533515; x=1456743115; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=trgzRRoZy4RU+GITJVpXaa+mOm1MdVXC0yivLEekEuM=; b=H2zRh5UYwsb4DGfqIuK6E9UHPWVl41rGAa+Uh8XMaBv3IF8/rij8Vx/W eYxwybCMF93tuofD+oGBixXIsH9bsfuDTUC1UZE7qQlB2tNnbna6LeDer k30r5EuNFsAVWx7Gaf6fdz9ntX10hlfdTx/rO9n5HDFkGTmVgm5R5dzmO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbBgC0rMFW/xbLJq1et3KJFYYNgXsBA?= =?us-ascii?q?QEBAQGBC4REJxVAASkMAgUWCwILAwIBAgFLDQgBAYgWrgyONAEBAQEBAQQBAQE?= =?us-ascii?q?BHHuFFotngToBBJZ5jVWJIoVSjj5ig2M8iSYBAQE?= X-IronPort-AV: E=Sophos;i="5.22,449,1449532800"; d="scan'208";a="625465647" 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; 15 Feb 2016 10:51:52 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1FApqsH006674; Mon, 15 Feb 2016 10:51:52 GMT To: Martin Bjorklund From: Robert Wilton Message-ID: <56C1ADC8.3080200@cisco.com> Date: Mon, 15 Feb 2016 10:51:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] Yang 1.1 - Semantics for state data leaf 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: Mon, 15 Feb 2016 10:51:56 -0000 Hi Martin, In Yang 1.0, all values in a leaf-list must be unique (i.e. section 7.7. states "The values in a leaf-list MUST be unique.". I.e. a leaf-list actually represents an ordered set rather than a list. In 6020bis#10, section 7.7, this statement has been changed to "In configuration data, the values in a leaf-list MUST be unique." My interpretation is that this implies that elements in a config-false leaf list are no longer required to be unique, and in fact there is no clean way to specify that they have to be unique. I just wanted to check that my interpretation was correct and that this change in behaviour was intentional. Thanks, Rob From nobody Mon Feb 15 03:14:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86EE1B31B1 for ; Mon, 15 Feb 2016 03:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.006, 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 KbURsnc7A3JH for ; Mon, 15 Feb 2016 03:14:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 787731B31A6 for ; Mon, 15 Feb 2016 03:14:24 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F5251AE018C; Mon, 15 Feb 2016 12:14:22 +0100 (CET) Date: Mon, 15 Feb 2016 12:14:26 +0100 (CET) Message-Id: <20160215.121426.1049877691855748307.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56C1ADC8.3080200@cisco.com> References: <56C1ADC8.3080200@cisco.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] Yang 1.1 - Semantics for state data leaf 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: Mon, 15 Feb 2016 11:14:26 -0000 Robert Wilton wrote: > Hi Martin, > > In Yang 1.0, all values in a leaf-list must be unique (i.e. section > 7.7. states "The values in a leaf-list MUST be unique.". I.e. a > leaf-list actually represents an ordered set rather than a list. > > In 6020bis#10, section 7.7, this statement has been changed to "In > configuration data, the values in a leaf-list MUST be unique." > > My interpretation is that this implies that elements in a config-false > leaf list are no longer required to be unique, and in fact there is no > clean way to specify that they have to be unique. > > I just wanted to check that my interpretation was correct and that > this change in behaviour was intentional. Yes, this was added in -09 (see changelog) after some discussion starting with https://mailarchive.ietf.org/arch/msg/netmod/auQCnrLxrSKTTtea57SkfsHhGu4 /martin From nobody Mon Feb 15 03:29:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C71B2F24 for ; Mon, 15 Feb 2016 03:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 oxjeZiRph7dY for ; Mon, 15 Feb 2016 03:29:03 -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 3ED6A1B2F18 for ; Mon, 15 Feb 2016 03:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1501; q=dns/txt; s=iport; t=1455535743; x=1456745343; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xpuvMAWeKi/GkoY8Fc2PGTNTb61w55178spJWCHR2qk=; b=WjBQNwfw8AoSx/U418qXEUioxzgcg2XsUzxKGZUSnKRxTrFe4oBA7uWV UwDZShE+3DjlnHTAdsZpAwDrVcwlu+2ljFU/19Vfg9aKHHUZQyiQByqDN LAX0a69j/8N1zUfRLFOa4F3G9DTzLfqJtUFfzqm/YCRKQOw2VW4vFCFGa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAD+tcFW/xbLJq1ehAxtvA4jhWoCg?= =?us-ascii?q?XkBAQEBAQGBC4RCAQEEOEABEAsOCgkWDwkDAgECAUUGDQYCAQGIFg4DvCkBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARIEhhGENYIlhkcBBJZ5hU+IBokihVKOPmKDYzwui?= =?us-ascii?q?HgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,449,1449532800"; d="scan'208";a="625466484" 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; 15 Feb 2016 11:29:01 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1FBT0o7010116; Mon, 15 Feb 2016 11:29:01 GMT To: Martin Bjorklund References: <56C1ADC8.3080200@cisco.com> <20160215.121426.1049877691855748307.mbj@tail-f.com> From: Robert Wilton Message-ID: <56C1B67C.7050808@cisco.com> Date: Mon, 15 Feb 2016 11:29:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160215.121426.1049877691855748307.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] Yang 1.1 - Semantics for state data leaf 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: Mon, 15 Feb 2016 11:29:05 -0000 Hi Martin, Thanks for confirming. I had only checked section 1.1. Should this change in semantics be listed in "1.1. Summary of Changes from RFC 6020"? My concern being that this change could break existing clients if they are currently using sets as the underlying data structure to represent config-false leaf-lists. Hence, I was wondering if this change should be flagged up higher up in the document to ensure that implementors are aware of this non backwards compatible change? Thanks, Rob On 15/02/2016 11:14, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi Martin, >> >> In Yang 1.0, all values in a leaf-list must be unique (i.e. section >> 7.7. states "The values in a leaf-list MUST be unique.". I.e. a >> leaf-list actually represents an ordered set rather than a list. >> >> In 6020bis#10, section 7.7, this statement has been changed to "In >> configuration data, the values in a leaf-list MUST be unique." >> >> My interpretation is that this implies that elements in a config-false >> leaf list are no longer required to be unique, and in fact there is no >> clean way to specify that they have to be unique. >> >> I just wanted to check that my interpretation was correct and that >> this change in behaviour was intentional. > Yes, this was added in -09 (see changelog) after some discussion > starting with > https://mailarchive.ietf.org/arch/msg/netmod/auQCnrLxrSKTTtea57SkfsHhGu4 > > > /martin > . > From nobody Mon Feb 15 05:16:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DC81B2BF0 for ; Mon, 15 Feb 2016 05:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 19_R88k_mKuD for ; Mon, 15 Feb 2016 05:15:57 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 281B61A8823 for ; Mon, 15 Feb 2016 05:15:56 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 263F31CC04DF; Mon, 15 Feb 2016 14:15:55 +0100 (CET) From: Ladislav Lhotka To: sarikaya@ieee.org, NETMOD WG In-Reply-To: References: User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 15 Feb 2016 14:16:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] 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: Mon, 15 Feb 2016 13:16:00 -0000 Behcet Sarikaya writes: > Hi Lada, > > When trying to validate NETCONF get reply in Appendix D, I ran into a > problem: I assume you mean Appendix D in RFC 7223. > > This annex introduces a namespace iana-if-types and none of the YANG > modules of ietf-routing-cfg is dependent on this namespace. > As a result, the NETCONF tool that I am using could not recognize > ethernetCdmacd when it comes to the line > > ianaift:ethernetCsmacd > > I know that iana-if-types is defined at the beginning of the rpc reply > but it seems like those declarations are simply ignored. Pyang validates this. You have to include the iana-if-types module into the data model, as explained here: https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model If you use another tool than pyang, then the procedure will be different but the principle is the same - ietf-if-types needs to be a part of the data model, otherwise the interface type identities are unknown. Lada > > Do you offer any solution? > > Regards, > > Behcet -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 15 08:42:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFA1A8770 for ; Mon, 15 Feb 2016 08:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 f01lHE1oGP6J for ; Mon, 15 Feb 2016 08:42:39 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 772F51A0364 for ; Mon, 15 Feb 2016 08:42:39 -0800 (PST) Received: (qmail 19901 invoked by uid 0); 15 Feb 2016 16:42:35 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Feb 2016 16:42:35 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id JgiX1s00Z2SSUrH01gia4Q; Mon, 15 Feb 2016 09:42:34 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=vxtsQUyxHT8Nuch2A6IA:9 a=AciSOl6SFPO6MImd:21 a=1DrvtOT88FKTXq7n:21 a=pILNOxqGKmIA:10 a=jO5m9I1TzjoA:10 a=jM_x9b4JT8QA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:To:Subject:From; bh=zQj6ZhkXPqyVXYLwoqxtIhQtdzCfBD1ADpXESS+AUkE=; b=FF71min0kQVDlG7k4Tsnn0BUSV6VdgfSldy0TheTXvTUb5oLuIcM9GbZDbiWbid9zyIpWxGlxEQsvqxIOFHjooUo26Lm9yvhB/mu4n1Fv3s/v/6G+CRBRCy+sHIbdOU6; Received: from box313.bluehost.com ([69.89.31.113]:47711 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aVMEK-0005R8-Cd for netmod@ietf.org; Mon, 15 Feb 2016 09:42:32 -0700 From: Lou Berger To: netmod WG References: <20160122131607.8074.21335.idtracker@ietfa.amsl.com> X-Enigmail-Draft-Status: N1110 Message-ID: <56C1FFF2.7070905@labn.net> Date: Mon, 15 Feb 2016 11:42:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160122131607.8074.21335.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [netmod] Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-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, 15 Feb 2016 16:42:41 -0000 Hi, This draft has been out a little bit, but we haven't seen any significant comments on it. We'd definitely like to hear from the WG on this. Note, per the draft: This version is a major change from the prior version and this change was enabled by the work on the Structural Mount/YSDL. And we expect this part to be covered in the interim on the 22nd. Also of note in the document: We cover Routing protocol and IP forwarding configuration and operation information which we assume is covered in a routing model, such as the one defined in netmod-routing-cfg. Although, the defined routing module includes support for network instances NIs, which it refers to as Routing Instances, while the approach presented in unaware document presumes that the routing module is unaware of LNEs and NIs. I/we are quite interested in hearing from the WG on the implications/impact to draft-ietf-netmod-routing-cfg. Thanks Lou (co-author) -------- Forwarded Message -------- Subject: I-D Action: draft-rtgyangdt-rtgwg-device-model-02.txt Date: Fri, 22 Jan 2016 05:16:07 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Device YANG Organizational Models Authors : Acee Lindem Lou Berger Dean Bogdanovic Christan Hopps Filename : draft-rtgyangdt-rtgwg-device-model-02.txt Pages : 36 Date : 2016-01-22 Abstract: This document presents an approach for organizing YANG models in a comprehensive structure that may be used to configure and operate network devices. The structure is itself represented as a YANG model, with all of the related component models logically organized in a way that is operationally intuitive, but this model is not expected to be implemented. The identified component modules are expected to be defined and implemented on common network devices. This document also defines two modules that can be used to model the logical and virtual resource representations that may be present on a network device. Examples of common industry terms for logical resource representations are Logical Systems or Routers. Examples of of common industry terms for virtual resource representations are Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). This document is derived from work submitted to the IETF by members of the informal OpenConfig working group of network operators and is a product of the Routing Area YANG Architecture design team. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-02 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 15 09:17:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF01A1BCB for ; Mon, 15 Feb 2016 09:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 xRF6kIX2PnOJ for ; Mon, 15 Feb 2016 09:17:10 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 0F3BB1A0045 for ; Mon, 15 Feb 2016 09:17:10 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id y89so115010298qge.2 for ; Mon, 15 Feb 2016 09:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zd0c+AIDnLR279nMCqbTja/bOgkzQVzGgAtFUdSHOm0=; b=oTJ+Tl8FM4SDaQbrrFrXdmZFhotaAHAVree5pWl3q/DXKGDavhsEoxLFF+JfnZtaOC cvJrkSjnMJPfJo9SoqN56Uuld7iPJDjq7EQuNQoIIlyIiMxnoyKr6f26lBLL5XNTDk/z X5PS/9qS+M803ncdTgxffRig0se8S9IKfvYN8HQWawuML6utN8LN1J1jZ1hVsoxjxUBS VMMNF78jYNHj2MlvMaBILl6HkXpKFJl1mELHVp+V+Ww3Vu0mGPMINZJFcEc/KTcL/r0p D2wq+IydI59lB9SaNvkuHTW22pM+8u2QGMJwhk0MRh7y5p8GAvK84UsSOEM8o2SypMF2 Ui4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zd0c+AIDnLR279nMCqbTja/bOgkzQVzGgAtFUdSHOm0=; b=A/pLZT0479ir1LAZvQ6LkpwDEH92AtsjwydKhdgi4WvRvD9JWkYXzccITgAZcfjcSq LcS7W0zWjTv+GUQSnUsMgWcPrRU/Vv0DVGBDhaVtu9T2JzeT6A5+OP6h6jAFnrCXB7hD 9jqK0sCyiy0mwLrJHvYBdoU8KnN6fsmlmK+KXcwtQTTbPGV3uZj0D4ASNUR7oHHsJN1L FioNPLB6FD8MpoWARHFsRMoNtfg5/eaOOEssScaYXjOkJBLj2N681l2h4pZAXBmFBjQG iMyLVhbiss4t5ZkJ87LJs+TkO+NQPdpRLeD6sWRmVoKex2FUNokNPRb1TaruF5Vtbh0f 0ylA== X-Gm-Message-State: AG10YORDhoQs3P2t6W6M93XivEN8u2rbfzYFtQZq2BUSSZmNlbnZYwkuzYRnqTrbKYlhP5D24NXQP9vcby7VQQ== MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr22623132qge.9.1455556629222; Mon, 15 Feb 2016 09:17:09 -0800 (PST) Received: by 10.55.27.224 with HTTP; Mon, 15 Feb 2016 09:17:09 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Feb 2016 11:17:09 -0600 Message-ID: From: Behcet Sarikaya To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] draft-ietf-netmod-routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:17:11 -0000 On Mon, Feb 15, 2016 at 7:16 AM, Ladislav Lhotka wrote: > Behcet Sarikaya writes: > >> Hi Lada, >> >> When trying to validate NETCONF get reply in Appendix D, I ran into a >> problem: > > I assume you mean Appendix D in RFC 7223. > No I meant your draft. Yes, RFC 7223 also has a similar annex, thanks for pointing it out. >> >> This annex introduces a namespace iana-if-types and none of the YANG >> modules of ietf-routing-cfg is dependent on this namespace. >> As a result, the NETCONF tool that I am using could not recognize >> ethernetCdmacd when it comes to the line >> >> ianaift:ethernetCsmacd >> >> I know that iana-if-types is defined at the beginning of the rpc reply >> but it seems like those declarations are simply ignored. I noticed that in RFC 7223 iana-if-types (mainly from RFC 2863, or interfaces MIB) is imported, so I did not try it but I can say that it would work on that example. > > Pyang validates this. You have to include the iana-if-types module into > the data model, as explained here: > > https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model > > If you use another tool than pyang, then the procedure will be different > but the principle is the same - ietf-if-types needs to be a part of the > data model, otherwise the interface type identities are unknown. > This is what I was pointing to. I did check every YANG module that draft-ietf-netmod-routing-cfg uses, in no place iana-if-types modules is imported. I wonder how you got the reply in Appendix D, you must have added iana-if-types somewhere. Regards, Behcet > Lada > >> >> Do you offer any solution? >> >> Regards, >> >> Behcet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Mon Feb 15 23:43:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A301A88A4 for ; Mon, 15 Feb 2016 23:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 9jN7Zn9M0Y1K for ; Mon, 15 Feb 2016 23:43:05 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 380331A88AF for ; Mon, 15 Feb 2016 23:43:05 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id B3F371AE0144; Tue, 16 Feb 2016 08:43:03 +0100 (CET) Date: Tue, 16 Feb 2016 08:43:07 +0100 (CET) Message-Id: <20160216.084307.1459362117031355044.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56C1B67C.7050808@cisco.com> References: <56C1ADC8.3080200@cisco.com> <20160215.121426.1049877691855748307.mbj@tail-f.com> <56C1B67C.7050808@cisco.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] Yang 1.1 - Semantics for state data leaf 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, 16 Feb 2016 07:43:07 -0000 Robert Wilton wrote: > Hi Martin, > > Thanks for confirming. I had only checked section 1.1. > > Should this change in semantics be listed in "1.1. Summary of Changes > from RFC 6020"? Ok. /martin > > My concern being that this change could break existing clients if they > are currently using sets as the underlying data structure to represent > config-false leaf-lists. Hence, I was wondering if this change should > be flagged up higher up in the document to ensure that implementors > are aware of this non backwards compatible change? > > Thanks, > Rob > > > On 15/02/2016 11:14, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> Hi Martin, > >> > >> In Yang 1.0, all values in a leaf-list must be unique (i.e. section > >> 7.7. states "The values in a leaf-list MUST be unique.". I.e. a > >> leaf-list actually represents an ordered set rather than a list. > >> > >> In 6020bis#10, section 7.7, this statement has been changed to "In > >> configuration data, the values in a leaf-list MUST be unique." > >> > >> My interpretation is that this implies that elements in a config-false > >> leaf list are no longer required to be unique, and in fact there is no > >> clean way to specify that they have to be unique. > >> > >> I just wanted to check that my interpretation was correct and that > >> this change in behaviour was intentional. > > Yes, this was added in -09 (see changelog) after some discussion > > starting with > > https://mailarchive.ietf.org/arch/msg/netmod/auQCnrLxrSKTTtea57SkfsHhGu4 > > > > > > /martin > > . > > > From nobody Tue Feb 16 00:00:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6D1B29FC for ; Tue, 16 Feb 2016 00:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 vFf8FtpY1ohd for ; Tue, 16 Feb 2016 00:00:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7C1AD324 for ; Tue, 16 Feb 2016 00:00:30 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 451AF1AE0144; Tue, 16 Feb 2016 09:00:29 +0100 (CET) Date: Tue, 16 Feb 2016 09:00:33 +0100 (CET) Message-Id: <20160216.090033.283670312674076307.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <56B87BD4.5060607@ericsson.com> References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.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] Fwd: 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: Tue, 16 Feb 2016 08:00:39 -0000 Hi, Balazs Lengyel wrote: > Hello, > IMHO the case, when 2 deviation statements point at the same target should be > clarified and declared as an error or implementation dependent feature. I see no > good way of deciding which deviation statement has precedence. This was discussed back in 2009: https://mailarchive.ietf.org/arch/msg/netmod/IYW1t0PX34cf2GEGAlM98XFOfKw This thread ends w/o clear resolution, but I think that the proposal in the last email in this thread (please read the thread) would be a useful addition: After applying all deviations, in any order, the resulting data model MUST still be valid. For example, it is an error to add a default value that doesn't match the type in a deviation. /martin > Balazs > > -------- Forwarded Message -------- > Subject: [netmod] Multiple deviations with same target > Date: Thu, 10 Dec 2015 11:12:02 +0100 > From: Balazs Lengyel > To: netmod@ietf.org > > 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..5 in one statement while setting it to > 2..6 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Feb 16 00:44:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175D61B2B5B for ; Tue, 16 Feb 2016 00:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 DwU3p2wOAS6w for ; Tue, 16 Feb 2016 00:44:02 -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 218671B2B4E for ; Tue, 16 Feb 2016 00:44:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 61EF52C8F for ; Tue, 16 Feb 2016 09:43:59 +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 kKb97s8ISMtw for ; Tue, 16 Feb 2016 09:43:51 +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 ; Tue, 16 Feb 2016 09:43:58 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BE2420038 for ; Tue, 16 Feb 2016 09:43:58 +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 uKiwFLv_omAG; Tue, 16 Feb 2016 09:43:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C31DD20035; Tue, 16 Feb 2016 09:43:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8CBDC39F3297; Tue, 16 Feb 2016 09:43:58 +0100 (CET) Date: Tue, 16 Feb 2016 09:43:58 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160216084358.GA76533@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20160204092405.GA21276@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160204092405.GA21276@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] YANG 1.1 final check of WG last call edits [until 2016-02-15] 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, 16 Feb 2016 08:44:05 -0000 Hi, the final check of the YANG 1.1 WG last call edits has passed and so we are getting ready to wrap things up. While working on the document writeup that goes to the IESG, I found a quirks that I think we should fix before sending the document to Benoit: 1) ID nits identified two instances of 'MUST not' that should be 'MUST NOT'. 2) The capability URN registration requires to define a capability name. Right now we only provide a URL. The IANA considerations need to define the capability name, e.g. :yang-library. 3) I checked the ABNF against http://tools.ietf.org/tools/bap/abnf.cgi. Note that I had to replace '%s' with '' since this tool does not yet support RFC 7405 (case sensitive strings). Anyway, the tool does a good job and suggested these two changes: - yang-char = %x9 / %xA / %xD / %x20-D7FF / + yang-char = %x09 / %x0A / %x0D / %x20-D7FF / - relative-path = 1*(".." "/") descendant-path + relative-path = 1*"../" descendant-path In addition, the tool suggested to add a couple of parenthesis so that the reader does not have to remember operator precedences by heart. I think Martin should take a look at this and decide which ones to incorporate (or if there is even an error lingering somewhere). In addition, there was the suggestion on the mailing list to mention the change of the non-config leaf-lists uniqueness in the 'Summary of Changes from RFC 6020' which I think should be implemented. Martin, can you look at these issues and post a new I-D? Once available, I will check the diffs, finish my writeup and then submit the document to Benoit. /js On Thu, Feb 04, 2016 at 10:24:05AM +0100, Juergen Schoenwaelder wrote: > Hi, > > the YANG 1.1 definition has gone through two WG last calls, the first > WG last call did end on 2015-10-12 and the second WG last call did end > on 2016-01-06. Martin has just posted > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-10 > > which we believe incorporates all changes that were discussed after > the second WG last call. I believe the document is ready to be sent to > our AD Benoit Claise. However, before doing so, I plan to give the WG > a chance to review the changes. > > Note that this is not the time to suggest new language features or to > request changes of existing language behavior. All I am looking for is > to make sure that (a) we did not forget any agreed upon edits and (b) > that edits did not introduce any bugs or fatal errors. > > The deadline for sending in comments is Monday 2016-02-15. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 16 01:40:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139031B2D81 for ; Tue, 16 Feb 2016 01:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 gocxJSUwEIOY for ; Tue, 16 Feb 2016 01:40: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 88E371B2D04 for ; Tue, 16 Feb 2016 01:40:41 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DB9C1AE0144; Tue, 16 Feb 2016 10:40:39 +0100 (CET) Date: Tue, 16 Feb 2016 10:40:43 +0100 (CET) Message-Id: <20160216.104043.245169968002222361.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160216084358.GA76533@elstar.local> References: <20160204092405.GA21276@elstar.local> <20160216084358.GA76533@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] YANG 1.1 final check of WG last call edits [until 2016-02-15] 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, 16 Feb 2016 09:40:43 -0000 Juergen Schoenwaelder wrote: > Hi, > > the final check of the YANG 1.1 WG last call edits has passed and so > we are getting ready to wrap things up. While working on the document > writeup that goes to the IESG, I found a quirks that I think we should > fix before sending the document to Benoit: > > 1) ID nits identified two instances of 'MUST not' that should be > 'MUST NOT'. Fixed. > 2) The capability URN registration requires to define a capability > name. Right now we only provide a URL. The IANA considerations > need to define the capability name, e.g. :yang-library. Fixed. > 3) I checked the ABNF against http://tools.ietf.org/tools/bap/abnf.cgi. > Note that I had to replace '%s' with '' since this tool does not yet > support RFC 7405 (case sensitive strings). Anyway, the tool does a > good job and suggested these two changes: > > - yang-char = %x9 / %xA / %xD / %x20-D7FF / > + yang-char = %x09 / %x0A / %x0D / %x20-D7FF / > > - relative-path = 1*(".." "/") descendant-path > + relative-path = 1*"../" descendant-path Fixed. > In addition, the tool suggested to add a couple of parenthesis so > that the reader does not have to remember operator precedences by > heart. I think Martin should take a look at this and decide which > ones to incorporate (or if there is even an error lingering > somewhere). I checked this, but I prefer to keep the current rules. > In addition, there was the suggestion on the mailing list to mention > the change of the non-config leaf-lists uniqueness in the 'Summary of > Changes from RFC 6020' which I think should be implemented. Fixed. > Martin, can you look at these issues and post a new I-D? Once > available, I will check the diffs, finish my writeup and then submit > the document to Benoit. There is one more open issue; see the thread "Multiple deviations with same target". /martin From nobody Tue Feb 16 03:42:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4FA1A8793 for ; Tue, 16 Feb 2016 03:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 L86tUEicDTgg for ; Tue, 16 Feb 2016 03:42: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 3762A1A87C5 for ; Tue, 16 Feb 2016 03:42: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 E159A8DA; Tue, 16 Feb 2016 12:42: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 SX5OomgTXzRL; Tue, 16 Feb 2016 12:42:23 +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, 16 Feb 2016 12:42:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EE5820031; Tue, 16 Feb 2016 12:42:30 +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 5ICSAIWjq43C; Tue, 16 Feb 2016 12:42: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 3133F2002B; Tue, 16 Feb 2016 12:42:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D480439F3865; Tue, 16 Feb 2016 12:42:27 +0100 (CET) Date: Tue, 16 Feb 2016 12:42:27 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160216114227.GC281@elstar.local> Mail-Followup-To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160216.090033.283670312674076307.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: Multiple deviations with same target 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, 16 Feb 2016 11:42:34 -0000 On Tue, Feb 16, 2016 at 09:00:33AM +0100, Martin Bjorklund wrote: > Hi, > > Balazs Lengyel wrote: > > Hello, > > IMHO the case, when 2 deviation statements point at the same target should be > > clarified and declared as an error or implementation dependent feature. I see no > > good way of deciding which deviation statement has precedence. > > This was discussed back in 2009: > https://mailarchive.ietf.org/arch/msg/netmod/IYW1t0PX34cf2GEGAlM98XFOfKw > > > This thread ends w/o clear resolution, but I think that the proposal > in the last email in this thread (please read the thread) would be a > useful addition: > > After applying all deviations, in any order, the resulting data > model MUST still be valid. For example, it is an error to add a > default value that doesn't match the type in a deviation. > Speaking as technical contributor: The second sentence is not really adding value. In the first sentence, it may be not entirely clear what _all_ deviations means. I assume this is 'all deviations announced by a server. So perhaps the proposal is to add After applying all deviations announced by a server, in any order, the resulting data model MUST still be valid. just before the beginning of section 7.20.3.1? Speaking as co-chair and document shepherd: Procedurally, this comes _very_ late and I do not want to go into a loop where there is always one more thing to fix but then each fix requires several days of additional delay to determine consensus. So I rather have the next I-D without this change posted so that we can get YANG 1.1 into the hands of Benoit. If we in parallel do find consensus on this particular clarification, someone can submit e.g. an IETF last call comment to fold this in. I am sure we will get more comments and change requests from Benoit, the IESG, the various directorates etc. and I rather have this process started ASAP. /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 Feb 16 03:53:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F941B334A for ; Tue, 16 Feb 2016 03:53:31 -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 ketW1_H7-DWS for ; Tue, 16 Feb 2016 03:53:28 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F21A11B339C for ; Tue, 16 Feb 2016 03:53:27 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 57A3B1CC027E; Tue, 16 Feb 2016 12:53:27 +0100 (CET) From: Ladislav Lhotka To: sarikaya@ieee.org 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, 16 Feb 2016 12:53:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NETMOD WG Subject: Re: [netmod] 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, 16 Feb 2016 11:53:31 -0000 Hi Behcet, Behcet Sarikaya writes: > On Mon, Feb 15, 2016 at 7:16 AM, Ladislav Lhotka wrote: >> Behcet Sarikaya writes: >> >>> Hi Lada, >>> >>> When trying to validate NETCONF get reply in Appendix D, I ran into a >>> problem: >> >> I assume you mean Appendix D in RFC 7223. >> > > No I meant your draft. Yes, RFC 7223 also has a similar annex, thanks > for pointing it out. The example in "routing-cfg" can be successfully validated, too. Actually, you can try it yourself (at least on Linux or OS X) by cloning the following GitHub project and running "make validate": https://github.com/netmod-wg/routing-cfg > >>> >>> This annex introduces a namespace iana-if-types and none of the YANG >>> modules of ietf-routing-cfg is dependent on this namespace. >>> As a result, the NETCONF tool that I am using could not recognize >>> ethernetCdmacd when it comes to the line >>> >>> ianaift:ethernetCsmacd >>> >>> I know that iana-if-types is defined at the beginning of the rpc reply >>> but it seems like those declarations are simply ignored. > > I noticed that in RFC 7223 iana-if-types (mainly from RFC 2863, or > interfaces MIB) is imported, so I did not try it but I can say that it > would work on that example. > >> >> Pyang validates this. You have to include the iana-if-types module into >> the data model, as explained here: >> >> https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model >> >> If you use another tool than pyang, then the procedure will be different >> but the principle is the same - ietf-if-types needs to be a part of the >> data model, otherwise the interface type identities are unknown. >> > > This is what I was pointing to. > I did check every YANG module that draft-ietf-netmod-routing-cfg uses, > in no place iana-if-types modules is imported. > I wonder how you got the reply in Appendix D, you must have > added iana-if-types somewhere. The bullet list at the beginning of Appendix D in "routing-cfg" specifies the implemented modules, and "ietf-interfaces" imports "ietf-if-types", so that's how it becomes part of the data model. Lada > > Regards, > > Behcet >> Lada >> >>> >>> Do you offer any solution? >>> >>> Regards, >>> >>> Behcet >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 16 05:42:46 2016 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 F2CCE1ACD2A; Tue, 16 Feb 2016 05:42:44 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216134244.19935.27992.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 05:42:44 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-11.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, 16 Feb 2016 13:42:45 -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 of the IETF. Title : The YANG 1.1 Data Modeling Language Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-11.txt Pages : 206 Date : 2016-02-16 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-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-11 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 Feb 16 05:43:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506AA1B2EC8 for ; Tue, 16 Feb 2016 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 i8quCp0CGz8e for ; Tue, 16 Feb 2016 05:43:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 698FD1B2E20 for ; Tue, 16 Feb 2016 05:43:44 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id E7FE81AE0144; Tue, 16 Feb 2016 14:43:42 +0100 (CET) Date: Tue, 16 Feb 2016 14:43:46 +0100 (CET) Message-Id: <20160216.144346.1232725855278501426.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160216114227.GC281@elstar.local> References: <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@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] Fwd: 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: Tue, 16 Feb 2016 13:43:46 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 16, 2016 at 09:00:33AM +0100, Martin Bjorklund wrote: > > Hi, > > > > Balazs Lengyel wrote: > > > Hello, > > > IMHO the case, when 2 deviation statements point at the same target should be > > > clarified and declared as an error or implementation dependent feature. I see no > > > good way of deciding which deviation statement has precedence. > > > > This was discussed back in 2009: > > https://mailarchive.ietf.org/arch/msg/netmod/IYW1t0PX34cf2GEGAlM98XFOfKw > > > > > > This thread ends w/o clear resolution, but I think that the proposal > > in the last email in this thread (please read the thread) would be a > > useful addition: > > > > After applying all deviations, in any order, the resulting data > > model MUST still be valid. For example, it is an error to add a > > default value that doesn't match the type in a deviation. > > > > Speaking as technical contributor: > > The second sentence is not really adding value. In the first > sentence, it may be not entirely clear what _all_ deviations > means. I assume this is 'all deviations announced by a server. > So perhaps the proposal is to add > > After applying all deviations announced by a server, in any order, > the resulting data model MUST still be valid. > > just before the beginning of section 7.20.3.1? Ok. > Speaking as co-chair and document shepherd: > > Procedurally, this comes _very_ late and I do not want to go into a > loop where there is always one more thing to fix but then each fix > requires several days of additional delay to determine consensus. > So I rather have the next I-D without this change posted so that we > can get YANG 1.1 into the hands of Benoit. If we in parallel do find > consensus on this particular clarification, someone can submit e.g. > an IETF last call comment to fold this in. I am sure we will get > more comments and change requests from Benoit, the IESG, the various > directorates etc. and I rather have this process started ASAP. Ok. I have posted -11 w/ the agreed upon changes (not the deviation thing above). /martin From nobody Tue Feb 16 09:24:13 2016 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 5D30A1B31B3 for ; Tue, 16 Feb 2016 09:24:12 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216172412.28673.1957.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 09:24:12 -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, 16 Feb 2016 17:24:12 -0000 Changed milestone "Submit YANG 1.1 to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/netmod/charter/ From nobody Wed Feb 17 08:30:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9F1A6EE6; Wed, 17 Feb 2016 08:30: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 d4JyvTq6pypO; Wed, 17 Feb 2016 08:30:45 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 4F36C1A90AC; Wed, 17 Feb 2016 08:30:45 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id gc3so21613598obb.3; Wed, 17 Feb 2016 08:30:45 -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=ifv75VO/L3+EXwInzkoLThhx5NiFYcPgQoIjKj6lI74=; b=z7zcP0CsVF4Azm6YY6T5CxYbYt8rDw9wpBUENtc4uxcrtkDKQ7hvu9hXQf2HjkpRiJ u1fsKxSZGwarSHdNjz5WCSxZIV9I/4Z1C3feiyzD/vxtdbJybw+753+i8Nmje3y6V1Fi g1mIRGmHvEUI3jYKCjOsbVs2CLaGylwwtm3ZSYW/bJIBHWNaYF5TUwAusaOPKwqFG0Ak bjY3XSimZvI7aBotouFoU5yDgH59g3zVK4hPIlK7JIU3cU8KgW7Zl8wOjq7v40fx6cwN WggeuFDDMstRJwFVHajg8KpzjApaDIhmJRYddoeruiXQiydozbFYSBjq/1U5GqSBqcZ/ RUEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ifv75VO/L3+EXwInzkoLThhx5NiFYcPgQoIjKj6lI74=; b=OQZGUklQneRY2WfIzqFZUUiXoq43OW8hVpcL6BLAJPhKlkFRe1fabnjxQtvhMF3Icv gsvk0sv6yfhMKIaEjZOiG7UnTIb7qVlWuAy5f1MTBExGHAN3xtydVYGKI+q4Cqq15uuE iKG8QHgcLn0mwfbXxMlBEGglzRBzowpiTWiO1CSuagdEwXWkt2E6wP+6cvJ+/M8/AWtQ AwbItBGsvI6V1W25MUnIsoOjuv1VfcPRYl3Hifme6fNeQVaSmIsA4M34jmqEraVAI0NM V03jbdW4bzI9R2djQKHDFb0L0+B9PsfWYGjk1jtuQBAbidxjtODx9pBdKlhxhFjW74qf sqBQ== X-Gm-Message-State: AG10YOTqgoSyCP5zbfXGNlPseUgVi4Cnif0zDpRffwv5yEHLOcvRMUKgbc2pqdlVMWRFng== X-Received: by 10.202.195.209 with SMTP id t200mr1931887oif.26.1455726644520; Wed, 17 Feb 2016 08:30:44 -0800 (PST) Received: from ?IPv6:2602:306:cf77:df90:d0:64b8:65b8:c43d? ([2602:306:cf77:df90:d0:64b8:65b8:c43d]) by smtp.gmail.com with ESMTPSA id cc2sm1006004obb.25.2016.02.17.08.30.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 08:30:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> Date: Wed, 17 Feb 2016 08:30:41 -0800 Message-Id: <35E9544A-65E8-4D4D-8D65-942801A9F3E5@gmail.com> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> To: NETCONF X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Tom Yu , NETMOD Working Group Subject: Re: [netmod] YANG library draft. WG check of last call edits 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, 17 Feb 2016 16:30:48 -0000 --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The review period for changes made to the draft is now closed. There are two issues that are open on GitHub that need addressing. The = authors are waiting on a response on how to address the secdir review = comments, and will work on addressing the second issue raised by Lada. Other than that, idnits has revealed this issue, although it is not = clear why. I see that in terminology section (1.1), the recommended = boiler plate statements exist for RFC 2119. Miscellaneous warnings: = --------------------------------------------------------------------------= -- =3D=3D The document seems to lack the recommended RFC 2119 = boilerplate, even if it appears to use RFC 2119 keywords.=20 RFC 2119, paragraph 2: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). It also complains about this, which is not clear to me. tmp/draft-ietf-netconf-yang-library-04.txt(201): Line has weird spacing: = '...-set-id str...' tmp/draft-ietf-netconf-yang-library-04.txt(210): Line has weird spacing: = '...evision uni...' tmp/draft-ietf-netconf-yang-library-04.txt(215): Line has weird spacing: = '...evision uni...' Once the authors have received a response from secdir, and post an = updated draft (as need to address the other open issue), I will check = the diffs, finish my writeup and send the document to Benoit. Thanks > On Feb 4, 2016, at 11:09 AM, Mahesh Jethanandani = wrote: >=20 > The yang-library draft went through a Last Call that ended January 22. = Martin has taken the suggestions from the last call comments and posted = an updated draft. >=20 > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = >=20 > Please review it for the changes made to the draft and any edits that = were either missed or are not right. This would not be a time to bring = in new changes or comments. >=20 > The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. >=20 > Cheers. >=20 --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The review period for changes made to the draft is now = closed.

There are = two issues that are open on GitHub that need addressing. The authors are = waiting on a response on how to address the secdir review comments, and = will work on addressing the second issue raised by Lada.

Other than that, idnits = has revealed this issue, although it is not clear why. I see that in = terminology section (1.1), the recommended boiler plate statements exist = for RFC 2119.

Miscellaneous warnings:
  =
--------------------------------------------------------------------------=
--

  =3D=3D The document seems to lack the recommended RFC 2119 =
boilerplate, even if
     it appears to use RFC 2119 keywords.=20

     RFC 2119, paragraph 2:
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in RFC 2119.

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

It also complains about this, which is = not clear to me.
tmp/draft-ietf-netconf-yang-library-04.txt(201): Line has =
weird spacing: '...-set-id    str...'
tmp/draft-ietf-netconf-yang-library-04.txt(210): Line has weird spacing: =
'...evision    uni...'
tmp/draft-ietf-netconf-yang-library-04.txt(215): Line has weird spacing: =
'...evision    uni...'

Once the authors have received a = response from secdir, and post an updated draft (as need to address the = other open issue), I will check the diffs, finish my writeup and send = the document to Benoit.

Thanks






= --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C-- From nobody Wed Feb 17 12:02:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982C21A212A for ; Wed, 17 Feb 2016 12:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, 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 d6yGdEWhhHDJ for ; Wed, 17 Feb 2016 12:02:29 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 0D30F1A8A0C for ; Wed, 17 Feb 2016 12:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1455739321; bh=/GHDIZVr1p8u+8XpdSQjRNYWvxlMfC7KUQeG8yZOQaw=; h=From:Subject:Date:Cc:To; b=u/Ko0LJV2gwEw7ciehkw9P+d2sf3OCT7XiVN8m/ibgX+kXsqCvOPXY5ZlDXxJnUsr hQ9aOE1fTMadKFg4bI+9GhVC7y6Y7yTuW+HgukuLCPBMLY7o2sV0fY8ahtKUC+nTpH /B23SEDjMgSXTOvmKlqDFSI+A6qteciVWRfgS6lk= 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 Date: Wed, 17 Feb 2016 15:01:34 -0500 Message-Id: To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) 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 278, in=3302, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: McLachlan Andrew Subject: [netmod] secretary change 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, 17 Feb 2016 20:02:30 -0000 NETMOD WG: I regret to inform you that Andrew McLachlan has resigned as WG = Secretary. He has had a number of recent changes that make it difficult for him to = carry on in this role. The co-chairs with to thank him for his past service = to the community,=20 and wish him well going forward. Tom/Kent From nobody Thu Feb 18 08:16:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5E11A88AF for ; Thu, 18 Feb 2016 08:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 bm2fHB71xEXG for ; Thu, 18 Feb 2016 08:16:01 -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 0A90E1A6F7D for ; Thu, 18 Feb 2016 08:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9035; q=dns/txt; s=iport; t=1455812161; x=1457021761; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=fruSS5R3SK5BcBA/1RpvUJKLffQKwwm4S9u4GdTebR8=; b=Z7x7pQTzv97ag/w0tCZ9/X7EQrUlC3aCip3H2Dzt0YQKzE6bMu92Job5 uBHHujQSX7b9m3Zl7/I1mmPqn24bXP3phqsTkWJ0f1pZQ1ApwKwVQYcq9 jeM1ZvrUmurXak1nRxdSEHJCmvaUR9jXhJzWSoBTkWjAXpLpQ7afJwL7x I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACt7MVW/xbLJq1ehAxtvBQXAQmFb?= =?us-ascii?q?AKCLQEBAQEBAWUnhEEBAQEEAQEBawoBEBkDAwECChYPCQMCAQIBFSYCCAYBDAY?= =?us-ascii?q?CAQGIFg67SQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoQ7hAURAQY4hBoFlwWFV?= =?us-ascii?q?IgGgVxKg3mDAoVShXGIVmKDZDsuh2+BMAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208,217";a="625550716" 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 Feb 2016 16:15:59 +0000 Received: from [10.61.83.28] (ams3-vpn-dhcp4893.cisco.com [10.61.83.28]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1IGFwDn008356; Thu, 18 Feb 2016 16:15:58 GMT References: <4AF73AA205019A4C8A1DDD32C034631D2E26DF28B3@NJFPSRVEXG0.research.att.com> To: Thomas Nadeau , Kent Watsen From: Benoit Claise X-Forwarded-Message-Id: <4AF73AA205019A4C8A1DDD32C034631D2E26DF28B3@NJFPSRVEXG0.research.att.com> Message-ID: <56C5EE3E.4090100@cisco.com> Date: Thu, 18 Feb 2016 17:15:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF28B3@NJFPSRVEXG0.research.att.com> Content-Type: multipart/alternative; boundary="------------010802060304050206020606" Archived-At: Cc: Al Morton , NETMOD Working Group Subject: [netmod] Fwd: [OPS-DIR] OPS-DIR review of draft-ietf-netmod-opstate-reqs-04 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, 18 Feb 2016 16:16:03 -0000 This is a multi-part message in MIME format. --------------010802060304050206020606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Tom, Kent, WG, Can you please engage with Al. Here is his OPS DIR review. Regards, Benoit -------- Forwarded Message -------- Subject: [OPS-DIR] OPS-DIR review of draft-ietf-netmod-opstate-reqs-04 Date: Wed, 3 Feb 2016 16:18:28 -0500 From: MORTON, ALFRED C (AL) To: draft-ietf-netmod-opstate-reqs@ietf.org , ops-dir@ietf.org , ops-ads@tools.ietf.org CC: amclachl@cisco.com sorry, there was a stray character in 'draft-ietf-netmod-opstate-reqs@ietf.org'' all of us are on OPS-DIR list (not trying to straighten this out again). (resending because the HTML-ized version "Email to authors link" still uses @tools.ietf.org = bounce) 'Hi Kent and Tom, and ops-dir, It's time for your OPS-DIR review and I'm "it". As Warren always says, "Be not afraid...". I fully support the purpose of your draft. These are important concepts to define unambiguously and some useful requirements to see implemented. I'll make a few suggestions for clarification below, and I trust you'll develop acceptable wording where I haven't fully understood your intentions. I'm not aware of any IPR associated with the points I seek to clarify. regards, Al -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Section 2 Asynchronous Configuration Operation: A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. "running configuration" is used in this definition, and again in Synchronous Configuration Operation without being defined. Is this a subset of the "Operational State" ? Section 3 Requirements " 1. Ability to interact with both intended and applied configuration" What entity is this requirement for? Is it: 1. The Client MUST possess the ability to interact with both... or BOTH Client and Server? Later in Section 3 " 3. Separation of the applied configuration and derived state aspects of operational state; ability to retrieve them independently and together A. Be able to retrieve only the applied configuration aspects of operational state B. Be able to retrieve only the derived state aspects of operational state C. Be able to retrieve both the applied configuration and derived state aspects of operational state together" This seems to be a set of requirements for BOTH the Client and the Server, worded from the Point-of-view of the Client ("retrieve"). Can you add the Client and Server here, using RFC 2119 terms? suggest: The Client MUST: A. Be able to retrieve only the applied configuration aspects of... Later in Section 3 " 4. Ability to relate configuration with its corresponding operational state A. ... " These are Server requirements? One or both the entities gets MUST or SHOULD... (These requirements (4) were not completely clear to me.) _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir . --------------010802060304050206020606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Tom, Kent, WG,

Can you please engage with Al.
Here is his OPS DIR review.

Regards, Benoit


-------- Forwarded Message --------
Subject: [OPS-DIR] OPS-DIR review of draft-ietf-netmod-opstate-reqs-04
Date: Wed, 3 Feb 2016 16:18:28 -0500
From: MORTON, ALFRED C (AL) <acmorton@att.com>
To: draft-ietf-netmod-opstate-reqs@ietf.org <draft-ietf-netmod-opstate-reqs@ietf.org>, ops-dir@ietf.org <ops-dir@ietf.org>, ops-ads@tools.ietf.org <ops-ads@tools.ietf.org>
CC: amclachl@cisco.com <amclachl@cisco.com> 


sorry, there was a stray character in 'draft-ietf-netmod-opstate-reqs@ietf.org''
all of us are on OPS-DIR list (not trying to straighten this out again).

(resending because the HTML-ized version "Email to authors link" 
still uses @tools.ietf.org = bounce)

'Hi Kent and Tom, and ops-dir,

It's time for your OPS-DIR review and I'm "it".
As Warren always says, "Be not afraid...".

I fully support the purpose of your draft. These are
important concepts to define unambiguously and 
some useful requirements to see implemented.
I'll make a few suggestions for clarification below,
and I trust you'll develop acceptable wording
where I haven't fully understood your intentions.

I'm not aware of any IPR associated with the points
I seek to clarify.

regards,
Al
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Section 2

   Asynchronous Configuration Operation:  A configuration request to
       update the running configuration of a server that is applied
       asynchronously with respect to the client request.

"running configuration" is used in this definition, and again in 
Synchronous Configuration Operation without being defined.
Is this a subset of the "Operational State" ?


Section 3  Requirements

"   1.  Ability to interact with both intended and applied configuration "

What entity is this requirement for?  Is it:
    1. The Client MUST possess the ability to interact with both...
or BOTH Client and Server?


Later in Section 3

"   3.  Separation of the applied configuration and derived state aspects
       of operational state; ability to retrieve them independently and
       together

       A.  Be able to retrieve only the applied configuration aspects of
           operational state

       B.  Be able to retrieve only the derived state aspects of
           operational state

       C.  Be able to retrieve both the applied configuration and
           derived state aspects of operational state together"

This seems to be a set of requirements for BOTH the Client and the Server,
worded from the Point-of-view of the Client ("retrieve").
Can you add the Client and Server here, using RFC 2119 terms?

suggest:
     The Client MUST:
       A.  Be able to retrieve only the applied configuration aspects of...
 

Later in Section 3

"   4.  Ability to relate configuration with its corresponding
       operational state
      A. ... "

These are Server requirements? One or both the entities gets MUST or SHOULD...
(These requirements (4) were not completely clear to me.)

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
.


--------------010802060304050206020606-- From nobody Thu Feb 18 08:20:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0E81B2E61; Thu, 18 Feb 2016 08:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 mN5Mqg6JO0gx; Thu, 18 Feb 2016 08:20:35 -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 77D451B2E4F; Thu, 18 Feb 2016 08:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1455812434; x=1457022034; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=suvd2Yqf8UM1dJtd6c0S8DsGbRPDCcD7T/2ZWz6i9n0=; b=YN4NVPTvwV40+PzXYTaiXHPTweXqmSgFAt5ViA764u3S5hiCwhUaMAg5 OAUwprm55GyqjwtOKWabsZk3XP3TO1BqHq4OTyMU97l226pYb/mucJI+U MPc32x9+9alPhE0RvWKruMNSxOyu7Ds1iRtsN9l1nx51ViaellaM3OfSG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACz7sVW/xbLJq1ewQ2GDQKCLQEBA?= =?us-ascii?q?QEBAWUnhEIBAQQ4QBELIRYPCQMCAQIBRQYBDAgBAYgWu14BAQEBAQEBAQIBAQE?= =?us-ascii?q?BAQEahhKEO4QdhFIBBJcFjVqBXIRDgwKFUo5HYoNkO4lNAQEB?= X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208";a="635584835" 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; 18 Feb 2016 16:20:31 +0000 Received: from [10.61.83.28] (ams3-vpn-dhcp4893.cisco.com [10.61.83.28]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1IGKV7h018214; Thu, 18 Feb 2016 16:20:31 GMT To: Tero Kivinen , iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-opstate-reqs.all@tools.ietf.org, NETMOD Working Group References: <22204.24528.791620.642938@fireball.acr.fi> From: Benoit Claise Message-ID: <56C5EF4E.9080107@cisco.com> Date: Thu, 18 Feb 2016 17:20:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <22204.24528.791620.642938@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Secdir review of draft-ietf-netmod-opstate-reqs-04 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, 18 Feb 2016 16:20:37 -0000 Tom, Kent, WG, Can you please engage with Tero. I would like to put this document on the telechat in 2 weeks from now. Regards, Benoit > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is terminology and requirements document for handling operational > state. As such the security considerations section cannot have very > detailed problems, but it does properly point out that while > configuration is being applied the device might be in inconsistent > state, and that might cause security issues. > > It does not say anything about how the configuration requests needs to > be secured, but I assume that is more in to the actual protocol RFC > issue, than this document. > > It does not also comment anything about whether the different states > (intended configuration, applied configuration and derivative state) > should have different security policies to applied to them, i.e. > it does say that it should be possible to retrieve only applied > configuration or only derived state, but does not mention should there > also be different security policies to do those operations. In some > cases the derivative state might contain things like traffic keys > negotiated during the protocol runs, or traffic information aabout > flows passing the devices (privacy issues), so derivative state might > be more sensitive than the actual applied configuration. > > Outside the security considerations section the requirement which > says: > > A. A server MUST support only synchronous configuration > operations, or only asynchronous configuration operations, or > both synchronous and asynchronous configuration operations on > a client-specified per-operation basis. > > is bit funny, as it effectively says that either syncronous or > asyncronous MUST be supported and both may be supported, but I do not > understand what the "client-specified per-operation basis" is meaning > for the requirement for server. > > Client cannot really require server to change its IMPLEMENTATION on > per-operation basis (i.e., client 1 requesting that server MUST > support only asyncronous operations, and client 2 requesting that > server MUST support only syncronous operations). > > Client can use either syncronous or asyncronous if both are supported > by the server, and I assume this is trying to say that client can > select syncronous/asyncronous operation per-operation basis, but when > you are talking about that "A server MUST support ..." I do not think > it is ok to requiring that on a client-specified way. > > I.e. proper way would be to say that if server supports both, it MUST > allow client to select which method is used on per-operation basis. From nobody Thu Feb 18 08:30:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7A41A06FD for ; Thu, 18 Feb 2016 08:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 H0aX-v3EMzIl for ; Thu, 18 Feb 2016 08:30:47 -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 64F6D1A0370 for ; Thu, 18 Feb 2016 08:30:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:8c30:845f:8975:81f1] (unknown [IPv6:2001:718:1a02:1:8c30:845f:8975:81f1]) by mail.nic.cz (Postfix) with ESMTPSA id 10766180DE1 for ; Thu, 18 Feb 2016 17:30:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1455813046; bh=a02ABVyztWtOkBYO7sIyy/RuOa1hlfuP9sO+KJcG8Xc=; h=From:Date:To; b=ktPGcF3bRcRdxi6gZ3B8rXrvjZ8LPwqsmJYXpHfI/IcEUcuasZzkZebW6hbqnWe/n QPbvssNkSuXgvBZxVsB+Js9HHvZZmC6411xEhRmltrFl+g6lQDd/a8L4RzR3J7MqKW auF+FN/Q5Fa4TAWOT49xhKzf5LlAdV1NyTpebyww= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 18 Feb 2016 17:30:46 +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] ABNF production for refine-stmt 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, 18 Feb 2016 16:30:50 -0000 Hi, $SUBJ doesn't allow for multiple default statements that are possible = for leaf-lists: OLD refine-stmt =3D refine-keyword sep refine-arg-str optsep "{" stmtsep ;; these stmts can appear in any order *if-feature-stmt *must-stmt [presence-stmt] [default-stmt] [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] [description-stmt] [reference-stmt] "}" stmtsep NEW refine-stmt =3D refine-keyword sep refine-arg-str optsep "{" stmtsep ;; these stmts can appear in any order *if-feature-stmt *must-stmt [presence-stmt] *default-stmt [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] [description-stmt] [reference-stmt] "}" stmtsep Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 18 09:27:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D805A1A88EB for ; Thu, 18 Feb 2016 09:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 Ab7zfKTmvHSQ for ; Thu, 18 Feb 2016 09:27:12 -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 92A731A908A for ; Thu, 18 Feb 2016 09:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=911; q=dns/txt; s=iport; t=1455816404; x=1457026004; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=GSQxNs1ce1QXffiApSLMGPQT9AytWa5qh55mA/Em8LI=; b=D1Mzs8RQXwYQW9uun7M170bl6pRNEE6HcE99w8C7D9LKJBxc4ZCK3C6J FTNtVW56ZIFpLsw1zj4dV0ippTyqH0Knqe5H05/PLs96cy3N6h3loQMg/ u5sFknn5Bs0L3iBwe9tJ6gqXIRG/riruQjScRbKPQL0pIgtVN/2iCDWqa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQB//sVW/xbLJq1ehAxtuA2CEwENg?= =?us-ascii?q?WchhSKCZxQBAQEBAQEBZCeEaw8BBTZAAgUhAhECTA0IAQGIFg6cfY9bjwoBAQE?= =?us-ascii?q?HAQEBARgEe4UXhmOBbgEBgx2BOgWXBY1aiSGFUo5HHgEBQoNkOy4Bh26BMAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208";a="649416780" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2016 17:26:42 +0000 Received: from [10.61.83.28] (ams3-vpn-dhcp4893.cisco.com [10.61.83.28]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1IHQgao026801 for ; Thu, 18 Feb 2016 17:26:42 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: <56C5FED2.70708@cisco.com> Date: Thu, 18 Feb 2016 18:26:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [netmod] Welcome Lou Berger as NETMOD co-chair 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, 18 Feb 2016 17:27:14 -0000 Dear all, I want to be the first one to thank Lou Berger who accepted to become the NETMOD co-chair, replacing Tom Nadeau. Lou has been working on YANG for some time now, including his work on the routing YANG design team. Recently, I asked Lou and Acee to produce a comparison of the three operational state proposals (See https://www.ietf.org/mail-archive/web/netmod/current/msg14585.html). This work will be very helpful to the WG, and will be sent to the mailing list soon. We will be working on the chair transition, which might last a couple of weeks, before installing Lou on the co-chair seat in Bueno-Aires. Here is the summary of the situation: Kent Watsen, co-chair, with a primary focus on the YANG language Lou Berger, co-chair, with a primary focus on the YANG data models Jürgen Schönwälder, co-chair till YANG 1.1 is complete Regards, Benoit From nobody Fri Feb 19 03:18:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0401B2E91 for ; Fri, 19 Feb 2016 03:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 idkIb8L7-iuM for ; Fri, 19 Feb 2016 03:18:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA5AB1B2E8D for ; Fri, 19 Feb 2016 03:18:36 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D1471AE0144; Fri, 19 Feb 2016 12:18:35 +0100 (CET) Date: Fri, 19 Feb 2016 12:18:39 +0100 (CET) Message-Id: <20160219.121839.1335688325324114786.mbj@tail-f.com> To: lhotka@nic.cz 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] ABNF production for refine-stmt 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, 19 Feb 2016 11:18:39 -0000 Hi, You're right, I have applied the fix. /martin Ladislav Lhotka wrote: > Hi, > > $SUBJ doesn't allow for multiple default statements that are possible for leaf-lists: > > OLD > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > *must-stmt > [presence-stmt] > [default-stmt] > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > [description-stmt] > [reference-stmt] > "}" stmtsep > > NEW > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > *must-stmt > [presence-stmt] > *default-stmt > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > [description-stmt] > [reference-stmt] > "}" stmtsep > > 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 Fri Feb 19 03:23:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478301B2EB9 for ; Fri, 19 Feb 2016 03:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 FYbNHns_OxLn for ; Fri, 19 Feb 2016 03:23: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 D3D741B2EB3 for ; Fri, 19 Feb 2016 03:23:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 52E081474; Fri, 19 Feb 2016 12:23:51 +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 Y-em_UzJNaTp; Fri, 19 Feb 2016 12:23: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; Fri, 19 Feb 2016 12:23:50 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87BFA20035; Fri, 19 Feb 2016 12:23:50 +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 cl8s1Wud__ac; Fri, 19 Feb 2016 12:23:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87A4120031; Fri, 19 Feb 2016 12:23:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 025F939F7701; Fri, 19 Feb 2016 12:23:47 +0100 (CET) Date: Fri, 19 Feb 2016 12:23:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160219112347.GA7211@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG 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: NETMOD WG Subject: Re: [netmod] ABNF production for refine-stmt 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, 19 Feb 2016 11:23:55 -0000 Lada, this indeed looks like a bug. Martin (and others), can you confirm this? If so, we should make sure we get this bug fixed as part of the IESG review and approval. /js On Thu, Feb 18, 2016 at 05:30:46PM +0100, Ladislav Lhotka wrote: > Hi, > > $SUBJ doesn't allow for multiple default statements that are possible for leaf-lists: > > OLD > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > *must-stmt > [presence-stmt] > [default-stmt] > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > [description-stmt] > [reference-stmt] > "}" stmtsep > > NEW > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > *must-stmt > [presence-stmt] > *default-stmt > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > [description-stmt] > [reference-stmt] > "}" stmtsep > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > 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 Fri Feb 19 03:33:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B01B2D50 for ; Fri, 19 Feb 2016 03:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 kdKdXpGXmrAY for ; Fri, 19 Feb 2016 03:33: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 869421B29CD for ; Fri, 19 Feb 2016 03:33: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 557AE15D7; Fri, 19 Feb 2016 12:33: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 y3gA1aQFg3JI; Fri, 19 Feb 2016 12:33:09 +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, 19 Feb 2016 12:33:30 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6910820037; Fri, 19 Feb 2016 12:33: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 vSTdPV4dv6IT; Fri, 19 Feb 2016 12:33: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 B67BC20035; Fri, 19 Feb 2016 12:33:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A829639F7798; Fri, 19 Feb 2016 12:33:28 +0100 (CET) Date: Fri, 19 Feb 2016 12:33:28 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160219113328.GA7343@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20160219.121839.1335688325324114786.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160219.121839.1335688325324114786.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ABNF production for refine-stmt 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, 19 Feb 2016 11:33:35 -0000 I created a new file to keep track of issues during the IESG processing cycle: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/iesg-process-comments.txt /js On Fri, Feb 19, 2016 at 12:18:39PM +0100, Martin Bjorklund wrote: > Hi, > > You're right, I have applied the fix. > > > /martin > > > Ladislav Lhotka wrote: > > Hi, > > > > $SUBJ doesn't allow for multiple default statements that are possible for leaf-lists: > > > > OLD > > > > refine-stmt = refine-keyword sep refine-arg-str optsep > > "{" stmtsep > > ;; these stmts can appear in any order > > *if-feature-stmt > > *must-stmt > > [presence-stmt] > > [default-stmt] > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > [description-stmt] > > [reference-stmt] > > "}" stmtsep > > > > NEW > > > > refine-stmt = refine-keyword sep refine-arg-str optsep > > "{" stmtsep > > ;; these stmts can appear in any order > > *if-feature-stmt > > *must-stmt > > [presence-stmt] > > *default-stmt > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > [description-stmt] > > [reference-stmt] > > "}" stmtsep > > > > 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 -- 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 Feb 19 08:10:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9CC1B2A86; Fri, 19 Feb 2016 08:10:11 -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 8WDBfGtXot46; Fri, 19 Feb 2016 08:10:09 -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 8DD261B2D4E; Fri, 19 Feb 2016 08:10:08 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id l143so57009623lfe.2; Fri, 19 Feb 2016 08:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=AdxFdqCQalaFcc6ee1xuOp2f4LYLN/0xoijTuXcoq0Q=; b=v3w5w1mE6XO5su5wIv9Wjadv9veH/uMa+KkflM/Qw3dkzAV5JSd4I3ic4o+D3CBEFm szEE0XNJkL7NqDtzr+Gy/CoN8501y2ZsU36KHZlwOO8O+GBR346QDhylaM1xvZmXKo3p iG6IVa5PVUcfY2IqOHoQypc1sT5x9nqNxAbAl5xJ/U5LGDGZBrCt1/mVke/8MUYG/Dtq PapB7/lHsuzmNVDo4+iq3A2SN9HqZ1ib/F0Nc9g7P7GQChHnUN3cUSpM6vaA4UpCYGzk 3oc00Jnj5LX3t0Y4FyloUKG+3YSf/BvBn15EDQTF4A/t272U4oGHaIybMAwDn8FHsyGI 4YDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=AdxFdqCQalaFcc6ee1xuOp2f4LYLN/0xoijTuXcoq0Q=; b=Nt/yB+sikEKg0c0Zu4j04JkPtwIIm5YSTUvS1V7bOZWFsGjR5FhCrIJPIv7dY0JYNn XVNBGJy63vUZVCoXCiLVjljX4fq/no7rIGjn8Srioa65yxrQ+Wh7Fmoe/2mEdmvJTPsU hyrOWsXSiXnrjj7/fogEGgaPmq55MYVg4zCTDv2Kc9zLtAGwwTC7w6VLawjY4atjg0bR 7xcN/KKyfMp8mAUobQTgHYeTMMVfRlXoCqEkcDNxl64CWMyiGspEmnIGSYjGlN0zOTRh U5KTK2BZ6e4awJEd1byXoorKpZs6pCWYwL012kNDhu8tgqMwrtFfE1JGW/bjwbgLybGe EknQ== X-Gm-Message-State: AG10YOSgjz1VwqTPW8yR6cFA+VRewUMLrNuwON38vv6sO8WZViV3y4yxxMqRVV7OzHakqQ== X-Received: by 10.25.149.145 with SMTP id x139mr4989634lfd.141.1455898206800; Fri, 19 Feb 2016 08:10:06 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id s75sm1588405lfs.21.2016.02.19.08.10.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2016 08:10:06 -0800 (PST) From: "Xufeng Liu" To: , , Date: Fri, 19 Feb 2016 11:10:03 -0500 Message-ID: <001401d16b2f$ff3c1e60$fdb45b20$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01D16B06.16661660" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdFrLncQ8xjJWq04TueMsao6nDFj6g== Content-Language: en-us Archived-At: Subject: [netmod] Yang mount / ysdl questions 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, 19 Feb 2016 16:10:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0015_01D16B06.16661660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit While realizing that the mechanism specified in the two drafts is very useful for modeling, I have a few questions that are common to both approaches: - How to mount one tree (but not other trees) from a module? For example, I may want to mount interfaces to one mounting point, but interfaces-state to a different mounting point. - When the mounting module is augmented by another module, what will happen to these augmentations after mounting? What will be the XPath to refer a node in the mounting module (from mounting module, and from mounted module)? - When a mounting module is used to mount to a mounting-point in my-module, how can the system also expose the mounting model in the original form, i.e. at the root level? Thanks, - Xufeng ------=_NextPart_000_0015_01D16B06.16661660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While realizing that the mechanism specified in the = two drafts is very useful for modeling, I have a few questions that are = common to both approaches:

 

-        = How to mount one tree (but not other trees) from = a module? For example, I may want to mount interfaces to one mounting = point, but interfaces-state to a different mounting = point.

 

-        = When the mounting module is augmented by another = module, what will happen to these augmentations after mounting? What = will be the  XPath to refer a node in the mounting module (from = mounting module, and from mounted module)?

 

-        = When a mounting module is used to mount to a = mounting-point in my-module, how can the system also expose the mounting = model in the original form, i.e. at the root level?

 

Thanks,

 

- = Xufeng

------=_NextPart_000_0015_01D16B06.16661660-- From nobody Fri Feb 19 09:25:53 2016 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 CEC2E1B2F7A; Fri, 19 Feb 2016 09:19:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219171940.19728.76095.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 09:19:40 -0800 Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 09:25:51 -0800 Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: [netmod] netmod - New Meeting Session Request for IETF 95 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, 19 Feb 2016 17:19:41 -0000 A new meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: NETCONF Data Modeling Language Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf rtgwg Second Priority: i2rs Special Requests: --------------------------------------------------------- From nobody Mon Feb 22 00:35:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0551B2A0B; Mon, 22 Feb 2016 00:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.093 X-Spam-Level: X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_210=0.6, RP_MATCHES_RCVD=-0.006, 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 7P8J_jzzYWjX; Mon, 22 Feb 2016 00:35:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE4021A7032; Mon, 22 Feb 2016 00:35:43 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C17F1AE0144; Mon, 22 Feb 2016 09:35:42 +0100 (CET) Date: Mon, 22 Feb 2016 09:35:46 +0100 (CET) Message-Id: <20160222.093546.333236529598665891.mbj@tail-f.com> To: xufeng.liu.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <001401d16b2f$ff3c1e60$fdb45b20$@gmail.com> References: <001401d16b2f$ff3c1e60$fdb45b20$@gmail.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: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod@ietf.org Subject: Re: [netmod] Yang mount / ysdl questions 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, 22 Feb 2016 08:35:45 -0000 Hi, "Xufeng Liu" wrote: > While realizing that the mechanism specified in the two drafts is very > useful for modeling, I have a few questions that are common to both > approaches: > > > > - How to mount one tree (but not other trees) from a module? For > example, I may want to mount interfaces to one mounting point, but > interfaces-state to a different mounting point. Currently this is not possible. If you want to use such a mechanism to mount selected subtrees from a module, it is not clear that this will work - there might be references from subtree A to subtree B, so if subtree B is not mounted, it is unclear how such references should be handled. > - When the mounting module is augmented by another module, what will > happen to these augmentations after mounting? What will be the XPath to > refer a node in the mounting module (from mounting module, and from mounted > module)? If the augmenting module it not mounted, nothing happens - it is just not there. If the augmenting module is also mounted, it will be augment the mounted module. For example, suppose ietf-interfaces and ietf-ip are both mounted at /foo. The resulting tree would be: +--rw foo +--rw if:interfaces +--rw if:interface* [name] ... +--rw ip:ipv4! > - When a mounting module is used to mount to a mounting-point in > my-module, how can the system also expose the mounting model in the original > form, i.e. at the root level? The system exposes all "top-level" modules as usual - just list them in the top-level YANG library. /martin From nobody Mon Feb 22 03:57:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047371A002D; Mon, 22 Feb 2016 03:57:15 -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_00=-1.9, J_CHICKENPOX_210=0.6] 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 wP3dhzAWBPab; Mon, 22 Feb 2016 03:57:13 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0EABC1A0025; Mon, 22 Feb 2016 03:57:13 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D4DE61CC027E; Mon, 22 Feb 2016 12:57:15 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , xufeng.liu.ietf@gmail.com In-Reply-To: <20160222.093546.333236529598665891.mbj@tail-f.com> References: <001401d16b2f$ff3c1e60$fdb45b20$@gmail.com> <20160222.093546.333236529598665891.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 22 Feb 2016 12:57:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod@ietf.org Subject: Re: [netmod] Yang mount / ysdl questions 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, 22 Feb 2016 11:57:15 -0000 Martin Bjorklund writes: > Hi, > > "Xufeng Liu" wrote: >> While realizing that the mechanism specified in the two drafts is very >> useful for modeling, I have a few questions that are common to both >> approaches: >> >> >> >> - How to mount one tree (but not other trees) from a module? For >> example, I may want to mount interfaces to one mounting point, but >> interfaces-state to a different mounting point. > > Currently this is not possible. If you want to use such a mechanism > to mount selected subtrees from a module, it is not clear that this > will work - there might be references from subtree A to subtree B, so > if subtree B is not mounted, it is unclear how such references should > be handled. Same in YSDL. > >> - When the mounting module is augmented by another module, what will >> happen to these augmentations after mounting? What will be the XPath to >> refer a node in the mounting module (from mounting module, and from mounted >> module)? > > If the augmenting module it not mounted, nothing happens - it is just > not there. If the augmenting module is also mounted, it will be > augment the mounted module. For example, suppose ietf-interfaces and > ietf-ip are both mounted at /foo. The resulting tree would be: > > +--rw foo > +--rw if:interfaces > +--rw if:interface* [name] > ... > +--rw ip:ipv4! > It's also similar in YSDL. Augments apply only within a single schema, which is essentially what we have now. > >> - When a mounting module is used to mount to a mounting-point in >> my-module, how can the system also expose the mounting model in the original >> form, i.e. at the root level? > > The system exposes all "top-level" modules as usual - just list them > in the top-level YANG library. In YSDL one would need to be able to specify "/" as the root node for the "mounted" schema. It's not allowed in -00 but it might be a useful extension. I don't see any reason why it shouldn't work. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 22 05:23:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6F1A9045 for ; Mon, 22 Feb 2016 05:23:48 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 CqMBlp8xFl6B for ; Mon, 22 Feb 2016 05:23:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::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 3C8C51A9043 for ; Mon, 22 Feb 2016 05:23:45 -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.409.15; Mon, 22 Feb 2016 13:23:20 +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.0409.024; Mon, 22 Feb 2016 13:23:20 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4A Date: Mon, 22 Feb 2016 13:23:20 +0000 Message-ID: References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> In-Reply-To: <20160210154624.25146.86523.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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:c7gr1DNdamZ0Xsx+7SFSyMYftVgBqjeFI/21ysJ0PB9NR6jCe2atXqC2ojWz+xUVoaDGkdA1NTviYn+uL1eqXPkmvO+CYuZO6KD/1tyoOrsaxRGgx9OvvIsR13S3niQCISZO5nPorPKBDe8zZn8L8w==; 24:V327H2NcicmatePJciGNl+x03DZaCrahFwdf6sb64ZYaev36BGJmj7Ku9TRHTVd7qfkPH82s7MG2WFKlf5LVJYfEHmHiNs7LmS5THL+FE2k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 4d29ab66-6033-482c-2a95-08d33b8b550e x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0860FE717F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(24454002)(479174004)(377454003)(87936001)(102836003)(3846002)(50986999)(76176999)(54356999)(11100500001)(16799955002)(1730700002)(107886002)(110136002)(5001960100002)(106116001)(189998001)(36756003)(586003)(5008740100001)(5002640100001)(5004730100002)(2906002)(66066001)(551544002)(1096002)(1220700001)(3660700001)(6116002)(99286002)(3280700002)(83506001)(92566002)(2351001)(15975445007)(2950100001)(10400500002)(86362001)(575784001)(561944003)(19625305001)(40100003)(33656002)(122556002)(19580405001)(19580395003)(77096005)(4001350100001)(450100001)(2501003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2AB6C6D65DBCCE4D833BA064A998506C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2016 13:23:20.1919 (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] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 22 Feb 2016 13:23:49 -0000 DQpGcmllbmRseSByZW1pbmRlciwgdGhpcyBtZWV0aW5nIHN0YXJ0cyBpbiBhYm91dCA5MCBtaW51 dGVzLg0KDQpDaGVlcnMsDQpLZW50DQoNCg0KDQoNCk9uIDIvMTAvMTYsIDEwOjQ2IEFNLCAibmV0 bW9kIG9uIGJlaGFsZiBvZiBJRVNHIFNlY3JldGFyeSIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3JvdGU6DQoNCj5UaGUgTkVU Q09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIChORVRNT0QpIFdHIHdpbGwgaGF2ZSBhIHZpcnR1 YWwgDQo+aW50ZXJpbSBtZWV0aW5nIG9uIDIyIEZlYnJ1YXJ5IDIwMTYgYXQgMTA6MDAgRVNUICgx NTowMCBVVEMpIHRvIGRpc2N1c3MgDQo+dXNlLWNhc2VzIGFuZCBzb2x1dGlvbnMgZm9yIGNvbWJp bmluZyBZQU5HIG1vZHVsZXMgaW50byB0aGUgc2NoZW1hIA0KPmRlZmluZWQgaW4gb3RoZXIgWUFO RyBtb2R1bGVzLCBhcyB0aGlzIGlzIGEgYmxvY2tpbmcgaXRlbSBmb3Igc29tZSBvdGhlciANCj53 b3JraW5nIGdyb3VwcyBjdXJyZW50bHkuIFRoZSBhZ2VuZGEgZm9yIHRoZSBtZWV0aW5nIGlzOg0K Pg0KPjUgbWluOiBhZ2VuZGEgYmFzaGluZywgc2NyaWJlcywgbm90ZSB3ZWxsLCBldGhlcnBhZCwg ZXRjLg0KPjIwIG1pbjogdXNlLWNhc2Ugc3VtbWFyeSAoZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRl dmljZS1tb2RlbC0wMikNCj4yMCBtaW46IHByb3Bvc2FsICMxIChkcmFmdC1saG90a2EtbmV0bW9k LXlzZGwtMDApDQo+MjAgbWluOiBwcm9wb3NhbCAjMiAoZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1z dHJ1Y3R1cmFsLW1vdW50LTAwKQ0KPjU1IG1pbjogZ2VuZXJhbCBkaXNjdXNzaW9uIG9yIGVuZCBl YXJseQ0KPg0KPkFsbCBwYXJ0aWNpcGFudHMgc2hvdWxkIGNvbWUgcHJlcGFyZWQgdG8gZGlzY3Vz cyB0aGVzZSBkcmFmdHMuDQo+DQo+Tm90ZTogaXQgaXMgdW5kZXJzdG9vZCB0aGF0IGRyYWZ0LWNs ZW1tLW5ldG1vZC1tb3VudCBpcyByZWxhdGVkIHdvcmssIA0KPmJ1dCB0aGUgY2hhaXJzIHdpc2gg dG8gb25seSBmb2N1cyBvbiB0aGUgc2NoZW1hIGNvbXBvc2l0aW9uIGlzc3VlIGF0IA0KPnRoaXMg dGltZS4NCj4NCj5FdGhlcnBhZDogaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAv cC9uZXRtb2QtaW50ZXJpbS0yMDE2MDIyMg0KPg0KPlJlZ2FyZHMsDQo+DQo+TkVUTU9EIENoYWly cw0KPg0KPi0tDQo+TkVUTU9EIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQo+TW9uZGF5LCBGZWJy dWFyeSAyMiwgMjAxNg0KPjQ6MDAgcG0gfCBFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDAp IHwgMiBocnMNCj4NCj5Kb2luIFdlYkV4IG1lZXRpbmc6DQo+aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bWUxNzE4MDNkM2RmZTgzZDNmMGQwMDNmODMzMmIwMzJmDQo+TWVl dGluZyBudW1iZXI6IDY0NiA2ODQgOTU2DQo+TWVldGluZyBwYXNzd29yZDogUWJkczNuUFoNCj4N Cj5Kb2luIGJ5IHBob25lDQo+MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVy IChVUy9DYW5hZGEpDQo+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKQ0KPkFjY2VzcyBjb2RlOiA2NDYgNjg0IDk1Ng0KPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3Ry aWN0aW9ucw0KPg0KPkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhci4gKENhbm5vdCBh ZGQgZnJvbSBtb2JpbGUgZGV2aWNlcy4pDQo+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bWY0ZTdhNjdmMmI0NWY2NTQyOTQ3ZmEzNDY0ZDM1ZTA1DQo+DQo+Q2FuJ3Qgam9p biB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0Lg0KPg0KPklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgDQo+b3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSANCj5kaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcg dGhpcyBzZXNzaW9uLCB5b3UgDQo+YXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIA0KPnJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgDQo+c2Vzc2lv bi4gDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Mon Feb 22 05:43:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9831AC447 for ; Mon, 22 Feb 2016 05:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 9AAwMn-6yebn for ; Mon, 22 Feb 2016 05:43:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 508851ABD36 for ; Mon, 22 Feb 2016 05:43:24 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id CF5831AE0144 for ; Mon, 22 Feb 2016 14:43:22 +0100 (CET) Date: Mon, 22 Feb 2016 14:43:27 +0100 (CET) Message-Id: <20160222.144327.1774239018651324229.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(Mon_Feb_22_14_43_27_2016_615)--" Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-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: Mon, 22 Feb 2016 13:43:25 -0000 ----Next_Part(Mon_Feb_22_14_43_27_2016_615)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have posted a new version of the structural mount draft. It hasn't changed technically, but it uses a current version of ietf-yang-library, clarifies some things and has some expanded examples. /martin ----Next_Part(Mon_Feb_22_14_43_27_2016_615)-- 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 DB9CD1AE0144 for ; Mon, 22 Feb 2016 14:40:27 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 761C01AC437 for ; Mon, 22 Feb 2016 05:40:26 -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-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160222134026.9821.82933.idtracker@ietfa.amsl.com> Date: Mon, 22 Feb 2016 05:40:26 -0800 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 51 0.017727 0.017150 ################################################ 0.10 2 0.117655 0.021608 ## 0.20 0 0.000000 0.021608 0.30 0 0.000000 0.021608 0.40 0 0.000000 0.021608 0.50 0 0.000000 0.021608 0.60 0 0.000000 0.021608 0.70 0 0.000000 0.021608 0.80 0 0.000000 0.021608 0.90 0 0.000000 0.021608 A new version of I-D, draft-bjorklund-netmod-structural-mount-01.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-bjorklund-netmod-structural-mount Revision: 01 Title: YANG Structural Mount Document date: 2016-02-22 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-structural-mount-01.txt Status: https://datatracker.ietf.org/doc/draft-bjorklund-netmod-structural-mount/ Htmlized: https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-bjorklund-netmod-structural-mount-01 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(Mon_Feb_22_14_43_27_2016_615)---- From nobody Mon Feb 22 12:51:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59C1A1EFC for ; Mon, 22 Feb 2016 12:51:22 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 hclmaKvIrUdR for ; Mon, 22 Feb 2016 12:51:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DE11A1BB5 for ; Mon, 22 Feb 2016 12:51:18 -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.409.15; Mon, 22 Feb 2016 20:50:53 +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.0409.024; Mon, 22 Feb 2016 20:50:53 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4AgAB9CgA= Date: Mon, 22 Feb 2016 20:50:53 +0000 Message-ID: References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:mko/UPxDzfQzdZtoZYqk3gzuaDGeX5mMO/xkPRMIIHCj8PQPyhGE5NhVYp6smprrXRTy4Aq2j88xIBzxJ69a66xHVU483tOSg7LdQ8IeQQshCr2eNPdL7E8zWoQTN/5P3cKPJG/9ss1Xh2wJpfgRcQ==; 24:LY+kufHK5G+MvCJkdPwjUWt/Aay2URI5/nfAvwaaH16xnf1tw9sUeTr7HsSky90jcmQnL2woRaecK9L8p/PAQmK7xv/d6RPi/M7sqcb5kiA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 7f0e931b-4b63-46b6-ece7-08d33bc9db17 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0860FE717F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(377454003)(24454002)(43784003)(479174004)(92566002)(82746002)(2351001)(83506001)(3660700001)(6116002)(15975445007)(99286002)(3280700002)(77096005)(19580395003)(19580405001)(5890100001)(450100001)(2501003)(4001350100001)(10400500002)(2950100001)(2900100001)(33656002)(122556002)(575784001)(86362001)(19625305001)(561944003)(40100003)(16799955002)(76176999)(11100500001)(54356999)(1730700002)(189998001)(5001960100002)(106116001)(110136002)(107886002)(99936001)(87936001)(102836003)(50986999)(3846002)(1096002)(1220700001)(586003)(551544002)(83716003)(36756003)(5004730100002)(5002640100001)(2906002)(5008740100001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_D61B67E338FA4F93AB845BBADFB761BEjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2016 20:50:53.8521 (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: Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 22 Feb 2016 20:51:22 -0000 --_002_D61B67E338FA4F93AB845BBADFB761BEjunipernet_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 DQpUaGFuayB5b3UgYWxsIHdobyBqb2luZWQgdG9kYXnigJlzIHZpcnR1YWwgaW50ZXJpbSBtZWV0 aW5nLg0KDQpPdGhlciB0aGFuIG15IHN0YXJ0aW5nIHRoZSByZWNvcmRpbmcgbGF0ZSBhbmQgcmVh cnJhbmdpbmcgdGhlIHByZXNlbnRhdGlvbiBvcmRlciwgSSB0aG91Z2h0IHRoYXQgdGhlIG1lZXRp bmcgd2VudCByZWFsbHkgd2VsbCBpbiB0aGF0IHRoZXJlIHNlZW1zIHRvIGJlIGEgbG90IG9mIHN1 cHBvcnQgZm9yIHRyeWluZyB0byBzb2x2ZSB0aGlzIHByb2JsZW0sIGFuZCBiZWNhdXNlIHdlIGhh dmUgYSBwbGFuIHRvIHRyeSB0byBtb3ZlIHRvd2FyZHMgaGF2aW5nIGEgV0cgZG9jdW1lbnQgaW4g dGhlIEJBIHRpbWVmcmFtZS4gIFRoZSBwbGFuIGlzIGZvciBkcmFmdC1iam9ya2x1bmQtbmV0bW9k LXN0cnVjdHVyYWwtbW91bnQgdG8gYmUgdXBkYXRlZCBiYXNlZCBvbiB0aGUgbWVldGluZyBhbmQg Zm9yIGl0IHRvIGJlIGRpc2N1c3NlZCBvbiBsaXN0IGFzIHRoZSBiYXNpcyBmb3IgdGhlIFdHIGVm Zm9ydCBvbiB0aGUgdG9waWMuDQoNCkF0dGFjaGVkIGFyZSB0aGUgdmVyeSByb3VnaCBFdGhlcm5l dCBtaW51dGVzIGNhcHR1cmVkIGR1cmluZyB0aGUgbWVldGluZy4gIFBsZWFzZSByZXZpZXcgY2Fy ZWZ1bGx5LiAgQ29ycmVjdGlvbnMgY2FuIGJlIG1hZGUgb24gdGhlIGV0aGVycGFkIGhlcmU6IGh0 dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbmV0bW9kLWludGVyaW0tMjAxNjAy MjIgIChzbyB3ZSBjYW4gdHJhY2sgY2hhbmdlcywgdGhlIGVuZCBvZiBtZWV0aW5nIHNuYXBzaG90 IGlzIGhlcmU6IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbmV0bW9kLWlu dGVyaW0tMjAxNjAyMjIvdGltZXNsaWRlciMzOTMzKQ0KDQpUbyBsaXN0ZW4gdG8gdGhlIHJlY29y ZGluZywgcGxlYXNlIGZvbGxvdyBvbmUgb2YgdGhlc2UgdHdvIGxpbmtzOg0KDQogIFN0cmVhbWlu ZyByZWNvcmRpbmcgbGluazoNCiAgICBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBo cD9SQ0lEPTRkYzg4Mzg2ZjEzYTQ5ZmE4ZjJjOTM0ZGI5NTNmNGEyDQoNCiAgRG93bmxvYWQgcmVj b3JkaW5nIGxpbms6DQogICAgaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5waHA/UkNJ RD0xYjY0OTBmZTVjYzZmYzk1ZDRlM2M5YjkxM2RmZGMxZg0KDQoNClRoYW5rcyBhZ2FpbiwNCg0K S2VudCBhbmQgTG91DQoNCg0KDQoNCg0KT24gMi8yMi8xNiwgODoyMyBBTSwgIm5ldG1vZCBvbiBi ZWhhbGYgb2YgS2VudCBXYXRzZW4iIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4NCj5GcmllbmRseSByZW1pbmRlciwg dGhpcyBtZWV0aW5nIHN0YXJ0cyBpbiBhYm91dCA5MCBtaW51dGVzLg0KPg0KPkNoZWVycywNCj5L ZW50DQo+DQo+DQo+DQo+DQo+T24gMi8xMC8xNiwgMTA6NDYgQU0sICJuZXRtb2Qgb24gYmVoYWxm IG9mIElFU0cgU2VjcmV0YXJ5IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiB3cm90ZToNCj4NCj4+VGhlIE5FVENPTkYgRGF0YSBN b2RlbGluZyBMYW5ndWFnZSAoTkVUTU9EKSBXRyB3aWxsIGhhdmUgYSB2aXJ0dWFsIA0KPj5pbnRl cmltIG1lZXRpbmcgb24gMjIgRmVicnVhcnkgMjAxNiBhdCAxMDowMCBFU1QgKDE1OjAwIFVUQykg dG8gZGlzY3VzcyANCj4+dXNlLWNhc2VzIGFuZCBzb2x1dGlvbnMgZm9yIGNvbWJpbmluZyBZQU5H IG1vZHVsZXMgaW50byB0aGUgc2NoZW1hIA0KPj5kZWZpbmVkIGluIG90aGVyIFlBTkcgbW9kdWxl cywgYXMgdGhpcyBpcyBhIGJsb2NraW5nIGl0ZW0gZm9yIHNvbWUgb3RoZXIgDQo+Pndvcmtpbmcg Z3JvdXBzIGN1cnJlbnRseS4gVGhlIGFnZW5kYSBmb3IgdGhlIG1lZXRpbmcgaXM6DQo+Pg0KPj41 IG1pbjogYWdlbmRhIGJhc2hpbmcsIHNjcmliZXMsIG5vdGUgd2VsbCwgZXRoZXJwYWQsIGV0Yy4N Cj4+MjAgbWluOiB1c2UtY2FzZSBzdW1tYXJ5IChkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNl LW1vZGVsLTAyKQ0KPj4yMCBtaW46IHByb3Bvc2FsICMxIChkcmFmdC1saG90a2EtbmV0bW9kLXlz ZGwtMDApDQo+PjIwIG1pbjogcHJvcG9zYWwgIzIgKGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3Ry dWN0dXJhbC1tb3VudC0wMCkNCj4+NTUgbWluOiBnZW5lcmFsIGRpc2N1c3Npb24gb3IgZW5kIGVh cmx5DQo+Pg0KPj5BbGwgcGFydGljaXBhbnRzIHNob3VsZCBjb21lIHByZXBhcmVkIHRvIGRpc2N1 c3MgdGhlc2UgZHJhZnRzLg0KPj4NCj4+Tm90ZTogaXQgaXMgdW5kZXJzdG9vZCB0aGF0IGRyYWZ0 LWNsZW1tLW5ldG1vZC1tb3VudCBpcyByZWxhdGVkIHdvcmssIA0KPj5idXQgdGhlIGNoYWlycyB3 aXNoIHRvIG9ubHkgZm9jdXMgb24gdGhlIHNjaGVtYSBjb21wb3NpdGlvbiBpc3N1ZSBhdCANCj4+ dGhpcyB0aW1lLg0KPj4NCj4+RXRoZXJwYWQ6IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9y Zzo5MDAwL3AvbmV0bW9kLWludGVyaW0tMjAxNjAyMjINCj4+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5O RVRNT0QgQ2hhaXJzDQo+Pg0KPj4tLQ0KPj5ORVRNT0QgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcN Cj4+TW9uZGF5LCBGZWJydWFyeSAyMiwgMjAxNg0KPj40OjAwIHBtIHwgRXVyb3BlIFRpbWUgKEJl cmxpbiwgR01UKzAxOjAwKSB8IDIgaHJzDQo+Pg0KPj5Kb2luIFdlYkV4IG1lZXRpbmc6DQo+Pmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lMTcxODAzZDNkZmU4M2QzZjBk MDAzZjgzMzJiMDMyZg0KPj5NZWV0aW5nIG51bWJlcjogNjQ2IDY4NCA5NTYNCj4+TWVldGluZyBw YXNzd29yZDogUWJkczNuUFoNCj4+DQo+PkpvaW4gYnkgcGhvbmUNCj4+MS04NzctNjY4LTQ0OTMg Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQo+PjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCj4+QWNjZXNzIGNvZGU6IDY0NiA2ODQgOTU2 DQo+PlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9ucw0KPj4NCj4+QWRkIHRoaXMgbWVldGlu ZyB0byB5b3VyIGNhbGVuZGFyLiAoQ2Fubm90IGFkZCBmcm9tIG1vYmlsZSBkZXZpY2VzLikNCj4+ aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWY0ZTdhNjdmMmI0NWY2NTQy OTQ3ZmEzNDY0ZDM1ZTA1DQo+Pg0KPj5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1 cHBvcnQuDQo+Pg0KPj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi RXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIA0KPj5vdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1 cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIA0KPj5kaXNjb3Zl cmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgDQo+ PmF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3Qg Y29uc2VudCB0byBiZWluZyANCj4+cmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRo IHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSANCj4+c2Vzc2lvbi4gDQo+Pg0KPj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5uZXRtb2QgbWFpbGlu ZyBsaXN0DQo+Pm5ldG1vZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_002_D61B67E338FA4F93AB845BBADFB761BEjunipernet_ Content-Type: text/plain; name="netmod-interim-20160222-3.txt" Content-Description: netmod-interim-20160222-3.txt Content-Disposition: attachment; filename="netmod-interim-20160222-3.txt"; size=7581; creation-date="Mon, 22 Feb 2016 20:50:53 GMT"; modification-date="Mon, 22 Feb 2016 20:50:53 GMT" Content-ID: <8B3AB6774F8F814AA5DA43C7AEC2661E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 W1BsZWFzZSBhZGQgeW91ciBuYW1lIHRvIHRoZSB2aXJ0dWFsIGJsdWUgc2hlZXQgYXQgdGhlIGVu ZCwgYW5kIG5vdGVzIGlubGluZSBpbiB0aGUgYXBwcm9wcmlhdGUgTm90ZXMgYmxvY2suXQoKSUVU RiBORVRNT0QgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcKRmViIDIyLCAyMDE2CgpPbmxpbmUgQWdl bmRhIGFuZCBTbGlkZXMgYXQ6IApodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTYvMDIvMjIvbmV0bW9kL3Byb2NlZWRpbmdzLmh0bWwKRGF0YSB0cmFja2VyOiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbmV0bW9kLwpUb29scyBwYWdlOiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvd2cvbmV0bW9kCgpBZ2VuZGE6CiAgICAKICAgNSBtaW46IGFnZW5kYSBiYXNo aW5nLCBzY3JpYmVzLCBub3RlIHdlbGwsIGV0aGVycGFkLCBldGMuCiAgMjAgbWluOiB1c2UtY2Fz ZSBzdW1tYXJ5IChkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTAyKQogIDIwIG1p bjogcHJvcG9zYWwgIzEgICAgICAoZHJhZnQtbGhvdGthLW5ldG1vZC15c2RsLTAwKQogIDIwIG1p bjogcHJvcG9zYWwgIzIgICAgICAoZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1zdHJ1Y3R1cmFsLW1v dW50LTAwKQogIDU1IG1pbjogZ2VuZXJhbCBkaXNjdXNzaW9uIG9yIGVuZCBlYXJseQoKQXR0ZW5k ZWVzOgoKICAtIEtlbnQgV2F0c2VuCiAgTG91IEJlcmdlcgogIENocmlzdGlhbiBIb3BwcwogIEVp bmFyIE5pbHNlbi1OeWdhYXJkCiAgSnVlcmdlbiBTY2jDtm53w6RsZGVyCiAgTGFkaXNsYXYgTGhv dGthCiAgWHVmZW5nIExpdQogIE1hcnRpbiBCasO2cmtsdW5kCiAgWGlhbgogIEVyaWMgVm9sdAog IFZpc2hudSBQYXZhbiBCZWVyYW0KICBBY2VlIExpbmRlbQogIEdlcnQKICBNaWNoYWVsIFNjaGFy ZgogIEhpbWFuc2h1IFNoYWgKICBBc2hlc2ggTWlzaHJhCiAgQmVub2l0IENsYWlzZQogIFJvYmVy dCBXaWx0b24KICBUYXJlayBTYWFkCiAgRGFuIFJvbWFuc2NhbnUKICBBaWh1YQogIFN0ZXZlIEJh aWxsYXJnZW9uCiAgCiAgCgogIApOb3RlczogKHBsZWFzZSBhZGQgdG8gdGhlIGFwcHJvcHJpYXRl IHRpbWUgYmxvY2spCiAgCiBBZ2VuZGEgYmFza2luZyBieSBFcmljIFZvaXQ6IHdvdWxkIGxpa2Ug dG8gbWFrZSBzdXJlIHRoYXQgdGhlIG1vdW50IGRpc2N1c3NlZCBoZXJlIGRvZXNuJ3QgcHJlY2x1 ZGUgZXh0ZW5zaWJpbGl0eSAoc2VlIGNsZW1tLW1vdW50IGRyYWZ0ICkKPiA1IG1pbjogYWdlbmRh IGJhc2hpbmcsIHNjcmliZXMsIG5vdGUgd2VsbCwgZXRoZXJwYWQsIGV0Yy4gCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzAyLzIyL25ldG1vZC9zbGlkZXMv c2xpZGVzLWludGVyaW0tMjAxNi1uZXRtb2QtMS0yLnBwdHgKCgo+IDIwIG1pbjogdXNlLWNhc2Ug c3VtbWFyeQo+ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcnRneWFuZ2R0LXJ0 Z3dnLWRldmljZS1tb2RlbC0wMgo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2lu dGVyaW0vMjAxNi8wMi8yMi9uZXRtb2Qvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtbmV0bW9k LTEtMS5wcHR4CgogIExvdSBQcmVzZW50aW5nIGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2Ut bW9kZWwtMDI6CiAgICAtIENocmlzIEhvcHBzOiBjbGFyaWZpY2F0aW9uIG9uIHNsaWRlIDEyLCB0 aGUgTE5FIG5lZWRzIG9ubHkgYmUgbWFuYWdlZCwgZG9lcyBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0 byBiZSBpbnNpZGUgdGhlIGhvc3QgCiAgICAtIEtlbnQgV2F0c2VuOiBMTkVzIG1heSBiZSByZW1v dGUgKGluIGNsb3VkKSAtIHRoaXMgb2theSBzbyBsb25nIGFzIGl0IGNhbiBiZSBtYW5hZ2VkIGFz IGEgc2luZ2xlIG5ldHdvcmsgZGV2aWNlCiAgICAtIEtlbnQgV2F0c2VuOiBuZWVkaW5nIHRvIHN1 cHBvcnQgTE5FIGRpcmVjdGx5IGlzIG5vdCBhcyBpbXBvcnRhbnQgYXMgYmVpbmcgYWJsZSB0byBt YW5hZ2UgZXZlcnl0aGluZyBmcm9tIGhvc3QKICAgIC0gRXJpYyBWb2l0OiAgIFdoYXQgaXMgdGhl IHBlcnNwZWN0aXZlIG9mIHRoZSBZQU5HIGludGVyZmFjZSBleHBvc2VkIHRvIGFuIGV4dGVybmFs IGRldmljZT8gICBJZiBhbiBMTkUgY29udGFpbnMgbWFueSBWTkYsIHdoeSB3b3VsZG4ndCBhIG1h bmFnZW1lbnQgaW50ZXJmYWNlIGFsbG93IGFic3RyYWN0aW9uIG9mIHRoZSBpbnRlcm5hbCBWTkZz LiAgIEluIHRoaXMgY2FzZSB3aXRoaW4gdGhlIExORSwgdGhleSBtaWdodCB3YW50IHRvIG1vdW50 IGluZm9ybWF0aW9uIGZyb20gdGhlIHZhcmlvdXMgVk5GcyBpbiBhIHdheSBpbnZpc2libGUgdG8g ZXh0ZXJuYWwgZW50aXRpZXMuICAgQXMgdGhlIFZORiBtaWdodCBiZSBvbiBkaWZmZXJlbnQgZGV2 aWNlcy9WTXMsIHRoaXMgb3BlbnMgdXAgYWRkcmVzc2FiaWxpdHkvbGF0ZW5jeS9ldGMuIHF1ZXN0 aW9ucy4gICBOb3RlIHRoYXQgdGhpcyBzdHVmZiBoYXMgYmVlbiBhc2tlZCBmb3IgaW4gdGhlIEJO RyBjb250ZXh0IHRvIGluY3JlYXNlIG92ZXJhbGwgY29udHJvbCBwbGFuZSBzY2FsZSBmcm9tIHRo ZSBleHRlcm5hbCBtYW5hZ2VtZW50IHBlcnNwZWN0aXZlLgogIC0gS2VudCBXYXRzZW46IGFzc2ln bmluZyByZXNvdXJjZXMgZnJvbSBob3N0IHRvIExFTiBtYXkgcmVxdWlyZSB0cmFuc2Zvcm1hdGlv biAoZS5nLiwgZmxhZ2dpbmcgYXMgcmVhZC1vbmx5KS4gIChMb3U6IGdvb2QgZHJhZnQgY29tbWVu dCkgCiAgLSBSb2IgU2hha2lyOiA/Pz8KICAtIE1hcnRpbiBCam9ya2x1bmQ6ID8/PyAgIChMb3U6 IGxldCdzIHVzZSB5YW5nLWxpYnJhcnkpCiAgLSBMYWRhOiA/Pz8gKExvdTogd2hhdGV2ZXIgd2Ug ZG8gd2lsbCBpbXBhY3QgY2xpZW50cy9zZXJ2ZXJzLCBzbyBjbGVhbmVzdCBhbnN3ZXIgaXMgZGVz aXJlZCwgbWF5YmUgbmVlZHMgWUFORyAxLjIgd291bGQgYmUgbmVlZGVkKSAgKD8/Pzogd2h5IHdv dWxkIHdlIG5lZWQgdG8gcmV2IFlBTkc/ICBMb3U6IGEgbmV3IFlBTkcgdHlwZT8gIExhZGE6IG5v LCBob3cgdG8gZmluZCBtb3VudHMsIAogIC0gPz8/OiBpcyBpdCBzdGlsbCBuZWVkZWQgdG8gYXVn bWVudCB0aGUgaW50ZXJmYWNlIG1vZGVsPyAgTG91OiB5ZXMsIGJhc2UgbW9kZWwgaGFzIGFsbCBp bnRlcmZhY2VzLCBidXQgc29tZSBhc3NpZ25lZCB0byBhbiBMTkUsIHRoYXQncyB3aHkgYXVnbWVu dGF0aW9uIGlzIG5lZWRlZCkKICAtIFh1ZmVuZzogaXMgaXQgcG9zc2libGUgdG8gbW91bnQganVz dCBhIHBhcnQgb2YgYSBtb2R1bGU/ICBMb3U6IGlubmVyL291dGVyIGludGVyZmFjZXMgZGlzY3Vz c2lvbgoKCgoKPiAyMCBtaW46IHByb3Bvc2FsICMxIAo+ICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbGhvdGthLW5ldG1vZC15c2RsLTAwCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzAyLzIyL25ldG1vZC9zbGlkZXMvc2xpZGVzLWludGVy aW0tMjAxNi1uZXRtb2QtMS0wLnBkZgoKTGFkYSBwcmVzZW50aW5nIGRyYWZ0LWxob3RrYS1uZXRt b2QteXNkbC0wMDoKICAgIC0gS2VudCBXYXRzZW46IHN0YXRpYyBsaXN0IG9mIG1vZHVsZXMsIG5v IHJ1bnRpbWUgYWRkaXRpb25zPyAgLSBob3cgZG9lcyB0aGlzIHdvcmsgZm9yIFZORnM/ICAoTGFk YSdzIGFuc3dlciBzZWVtZWQgdG8gbWlzcyB0aGUgcG9pbnQpCiAgICAtIEp1ZXJnZW46IE15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBMYWRhIGRlZmluZXMgdGhlIG1vdW50IHBvaW50IGF0IHJ1bnRp bWUsIE1hcnRpbiByZXF1aXJlcyB0aGUgbW91bnQgcG9pbnQgdG8gYmUgZGVmaW5lZCBhdCBzY2hl bWEgZGVmaW5pdGlvbiB0aW1lLiBBbSBJIGNvcnJlY3Q/CiAgICAtID8/Pzogc2VydmVyIGNhbiBy ZXR1cm4gZGlmZmVyZW50IGFuc3dlcnMgb3ZlciB0aW1lLCBzbyBpdCdzIGFjdHVhbGx5IGR5bmFt aWMsIHJpZ2h0PyAgTGFkYTogY2xpZW50IGlzIGFibGUgdG8gbGVhcm4gdXAgZnJvbnQgYW5kIGRv ZXNuJ3QgaGF2ZSB0byByZWZyZXNoLiAgPz8/OiBidXQgd2Ugd2FudCB0aGUgY2xpZW50IHRvIHJl ZnJlc2ggb24gZGVtYW5kCiAgICAtIEp1ZXJnZW46IEkgdGhpbmsgSSBsaWtlIHRoYXQgYSBtb3Vu dCBwb2ludCBjYW4gYmUgYXVnbWVudGVkIGludG8gYSBtb2R1bGUgd2l0aG91dCBoYXZpbmcgdG8g dXBkYXRlIHRoZSBtb2R1bGUgKHRoaXMgaXMgYSBzdHJvbmcgcG9pbnQgb2YgTGFkYSdzIHByb3Bv c2FsKSwgSSB0aGluayBJIGFsc28gbGlrZSB0byBiZSBhYmxlIHRvIGRldGVybWluZSBmcm9tIGEg c2V0IG9mIFlBTkcgbW9kdWxlcyB3aGF0IEkgY2FuIGV4cGVjdCB0byBiZSBhdCB3aGljaCBsb2Nh dGlvbiwgdGhhdCBpcyB0aGUgbW91bnQgaXMgc3RpbGwgc2NoZW1hIGRlZmluZWQuIEluIG90aGVy IHdvcmRzOiBpbiBiYXIueWFuZzogYXVnbWVudCAvZm9vOmZvbyB7IG1vdW50IGlmOmlldGYtaW50 ZXJmYWNlcyB9CiAgICAKICAgIENocmlzIEhvcHBzOiBXaXRoIFlTREwgYXJlIHRoZSAibW91bnQg cG9pbnRzIiBkeW5hbWljIChpLmUuLCBjYW4gdGhleSBjaG5hZ2UgcGVyIHNlcnZlciBpbXBlbWVu dGF0aW9uKSBvciBzdGF0aWMgKGkuZS4gdGhleSB3aWxsIGFsd2F5cyBiZSB0aGUgc2FtZSByZWdh cmRsZXNzIG9mIHNlcnZlciBpbXBsZW1lbnRhdGlvbik/IElmIEkgYW0gYSBjbGllbnQgY2FuIEkg Y29kZSBhIHN0YXRpYyBwYXRoIHN0cmluZyAoZS5nLiwgIi9sbmUvMS9yb3V0aW5nL2lzaXMvbGV2 ZWwiKSBvciBkbyBJIG5lZWQgdG8gZmlyc3QgcXVlcnkgdGhlIHNlcnZlciBhbmQgY29uc3RydWN0 IHRoZSBwYXRoIGZyb20gdGhlIGFuc3dlciByZXR1cm5lZCAoaS5lLiwgY2xpZW50OiAid2hlcmUg aXMgaXNpcyIsIHNlcnZlcjogInVuZGVyIC9mb28vYmFyL2lzaXMiLCBjbGllbnQ6ICIvZm9vL2Jh ci9pc2lzL2xldmVsIik/CgoKCgoKPiAyMCBtaW46IHByb3Bvc2FsICMyCj4gICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQt MDAKPiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDIvMjIv bmV0bW9kL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LW5ldG1vZC0xLTMucGRmCgpNYXJ0aW4g cHJlc2VudGluZyBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQtMDA6CiAg ICAtIExvdTogb24gc2xpZGUgIzMsIHVuZGVyIHBvaW50IDIsIHRoZSBsaWJyYXJ5IGlzbid0IGFj dHVhbGx5IHRoZXJlLCBpdCdzIGp1c3QgYSByZWZlcmVuY2UuICAgTGFkYTogdGhpcyBjYXVzZXMg eWFuZy1saWJyYXJ5IHRvIGJlY29tZSBkaXNyaWJ1dGVkLiAgIE1hcnRpbjogZGlmZmVyZW50IExO RXMgbWF5IGhhdmUgZGlmZmVyZW5jZSBtb2R1bGVzIG1vdW50ZWQsIGFuIGFkdmFudGFnZSB0byB0 aGlzIHNvbG4gaXMgdGhhdCBpdCBzdXBwb3J0cyByZWN1cnNpdmUgbW91bnRzLgogICAgTGFkYTog ZGlzYWdyZWUgd2l0aCBsYXN0IHBvaW50IChvbiBsYXN0IHNsaWRlKSwgaW4gZWl0aGVyIGNhc2Ug dGhlIGNsaWVudCBoYXMgdG8gYmUgcHJlcGFyZWQuCiAgICBSb2IgV2lsdG9uPzogd291bGQgdGhl cmUgYmUgYW55IG1lcml0IHRvIHNwbGl0IGludG8gc2VwYXJhdGUgbW91bnRpbmcgc29sdXRpb25z ICAoaW4tdHJlZSBhbmQgb3V0c2lkZS1vZi10cmVlKT8KICAgIENocmlzIEhvcHBzOiAgM3JkIHR5 cGU6IHNjaGVtYS13cml0ZXIgY291bGQgc2F5IGEgdmVyeSBzcGVjaWZpYyBtb2RlbCBpcyBtb3Vu dGVkICAoc2V0IGluIFJGQyB0ZXh0KQoKCgo+ID8/IG1pbjogQ2xlbW0gZHJhZnQgZGlzY3Vzc2lv bgoKRXJpYzogSXQgbG9va3MgbGlrZSB3ZSBtaWdodCBydW4gb3V0IG9mIHRpbWUgdG9kYXkuICAg SSBhbSBnb2luZyB0byBwbGFjZSBzb21lIHF1ZXN0aW9ucyBiZWxvdyB0aGF0IGVpdGhlciBzaG91 bGQgYmUgYWRkcmVzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QsIG9yIHBlcmhhcHMgd2Ugc2hvdWxk IGhhdmUgYW5vdGhlciBpbnRlcmltIGNhbGwuIChUaGVzZSB3ZXJlIG5vdCBmdWxseSBkaXNjdXNz ZWQgaW4gdGhlIG1lZXRpbmcuKQooMSkgU29tZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGRlc2NyaWJl ZCBhcmUgaW4gdGhlIHBlZXItbW91bnQgZHJhZnQsIHNvbWUgYXJlIG5vdC4gICBIb3cgZG8gd2Ug ZW5zdXJlIHRoYXQgd2UgZG8gbm90IHByZWNsdWRlIGEgc3ludGF4IHdoaWNoIHN1cHBvcnRzIGFu ZCBpcyBleHRlbnNpYmxlIGZvciBtdWx0aXBsZSB1c2VzPwooMikgWUFORyAiTW91bnQiIGlzIGEg c3VjY2Vzc2Z1bCB0ZWNobm9sb2d5IGluIE9wZW5EYXlsaWdodC4gIEEgcXVpY2sgR29vZ2xlIHNl YXJjaCBzaG93cyA4MzAgcGFnZXMgdXNpbmcgdGhlIHRlcm0gb24gdGhlIE9wZW5EYXlsaWdodCBz aXRlLiAgIENyZWF0aW5nIGFuIGluY29tcGFibGUgdXNlIHdvdWxkIGJlIGNvbmZ1c2luZyB0byB0 aGUgaW5kdXN0cnksIGVzcGVjaWFsbHkgd2hlbiBjb25zaWRlcmluZyB0aGUgb3ZlcmxhcHBpbmcg Y29udGV4dHMuCigzKSBBIHJlcXVpcmVtZW50cyBwcmVzZW50YXRpb24gb24gIkFsaWFzIE1vdW50 IiB3YXMgbWFkZSBpbiBJRVRGIDk0IHdoaWNoIGNvdWxkIGJlIGFkYXB0ZWQgZm9yIHRoZXNlIHJl cXVpcmVtZW50cy4gICBDb25zaWRlcmluZyBhbGwgdGhlIGlzc3VlcyBoZXJlLCBhIHVuaWZpZWQg cmVxdWlyZW1lbnRzIGRvY3VtZW50IG1pZ2h0IGJlIHdvcnRoIGhhdmluZyBmb3IgdGhpcyBjb250 ZXh0LgoKCkxvdTogKHNvbWUgZ2VuZXJhbCB3cmFwIHVwIGRpc2N1c3Npb24pOiBOZXh0IHN0ZXAg Zm9yIE1hcnRpbiB0byB1cGRhdGUgc3RydWN0dXJhbC1tb3VudCBiYXNlZCBvbiB0b2RheSdzIGRp c2N1c3Npb24sIGluY2x1ZGluZyBlbnN1cmluZyB0aGUgdGhyZWUgZGlmZmVyZW50IG1vdW50IG1l dGhvZHMgYXJlIGRvY3VtZW50ZWQsIGNvcnJlY3Q/Ck1hcnRpbjogWWVzLCBjYW4gZG8gdGhhdApM b3U6IFF1ZXN0aW9uIHRvIExhZGEgcmUgaGlzIG5leHQgc3RlcApMYWRhOiBOb3Qgd2VkZGVkIHRv IFlTREwgYW5kIHdpbGxpbmcgdG8gd29yayB3aXRoIGF1dGhvcnMgb2Ygb3RoZXIgZG9jdW1lbnQK TG91OiBFeGNlbGxlbnQuICBUaGVuIGlzIGV2ZXJ5b25lIGNvbWZvcnRhYmxlIHdpdGggc3RhcnRp bmcgd2l0aCBhIHZlcnNpb24gb2Ygc3RydWN0dXJhbC1tb3VudCB1cGRhdGVkIGJhc2VkIG9uIHRv ZGF5J3MgZGlzY3Vzc2lvbiBhcyB0aGUgc3RhcnRpbmcgcG9pbnQsIGkuZS4sIDFzdCBXRyBkcmFm dCwgYXMgYSBzb2x1dGlvbiBzdGFydGluZyBwb2ludC4gV2l0aCBleHBlY3RhdGlvbiB0aGF0IHRo ZSBhdXRob3JzIG9mIHRoZSByZWxhdGVkIGRyYWZ0cyAoTWFydGluLCBMYWRhIGFuZCBBbGV4LCBh bmQgb3RoZXIgYXV0aG9ycykgd2lsbCB3b3JrIHRvZ2V0aGVyIGFuZCBicmluZyBhIHByb3Bvc2Vk IG1vZGlmaWVkIHNvbHV0aW9uIHRvIHRoZSBXRyBhZnRlciBXRyBhZG9wdGlvbi4KKGdlbmVyYWwg YWdyZWVtZW50LikKTG91OiB0aGVuIHdlIHdpbGwgZGlzY3VzcyBvbiBsaXN0IG9uY2UgdGhlcmUg aXMgdGhlIHZlcnNpb24gdXBkYXRlZCBiYXNlZCBvbiB0b2RheSdzIGRpc2N1c3Npb24uIAoKIAoK --_002_D61B67E338FA4F93AB845BBADFB761BEjunipernet_-- From nobody Mon Feb 22 17:22:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D61B3A6D for ; Mon, 22 Feb 2016 17:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 lMVFmF9hA2eL for ; Mon, 22 Feb 2016 17:22:44 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id CE9A11B3A77 for ; Mon, 22 Feb 2016 17:22:37 -0800 (PST) Received: (qmail 1143 invoked by uid 0); 23 Feb 2016 01:22:35 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 23 Feb 2016 01:22:35 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id MkNV1s0062SSUrH01kNYbW; Tue, 23 Feb 2016 01:22:32 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To:Cc; bh=Tsd9292PLz6joqPN8I4epp7ICGB2WEGxUC5WJfGebfs=; b=IHZ9g++uMRgRlC7IBBXADN1tf2cuFlo6KWhQ2mXVQ2wIowab8OrYrkKzSY9v2nFp3GfgZ6A95YSkFnNK3DgvzSxV4wS69Y5K0akszhyUpDiwlaP/dhOmKq1sj8Y3rAHI; Received: from box313.bluehost.com ([69.89.31.113]:45733 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aY1gN-000629-MB; Mon, 22 Feb 2016 18:22:31 -0700 To: cwildes@cisco.com, kkoushik@cisco.com From: Lou Berger Message-ID: <56CBB450.9080403@labn.net> Date: Mon, 22 Feb 2016 20:22:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod chairs , netmod WG Subject: [netmod] draft-ietf-netmod-syslog-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: Tue, 23 Feb 2016 01:22:45 -0000 Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Tue Feb 23 03:16:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7EE1B41E5 for ; Tue, 23 Feb 2016 03:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 RPpQ9AagbK4K for ; Tue, 23 Feb 2016 03:16: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 BD0A11AC3D7 for ; Tue, 23 Feb 2016 03:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2889; q=dns/txt; s=iport; t=1456226190; x=1457435790; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=izuzHYkawBicb1oBV5NYrhxp/yCBtUguaF32dL+kKVU=; b=BbwaGLjOkTK3zYKaZh2T1YnHy8qNEf9PhU9RCjVllofl1PY0Q7AwubGl KFytIMCHuKJqJKf8gJWPN0aMJHz86DZ/0NhFGZanZsGU06ce1XjYNrXE0 xPiXZdICHUdUQ0N9umq+Zcy4dQUNWzQj7pF5UKynWxzmvttCJHPZ6F++g I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAAZPsxW/xbLJq1ehAxtvFkXCoUiS?= =?us-ascii?q?gKCEQEBAQEBAWUnhEEBAQEEAQEBIA8BBTYKAQwECw4DBAEBAQICBRYIAwICCQM?= =?us-ascii?q?CAQIBFR8JCAYNBgIBAYgXDqxbjwABAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuFF?= =?us-ascii?q?4Q6hDODAoE6AQSXB4VXiAeBXIRDgwKFUIVyiFdig2U7Log5AQEB?= X-IronPort-AV: E=Sophos;i="5.22,489,1449532800"; d="scan'208";a="635672569" 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; 23 Feb 2016 11:16:28 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1NBGSR9008266; Tue, 23 Feb 2016 11:16:28 GMT To: William Lupton , "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> <566F15F3.4060408@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> From: Benoit Claise Message-ID: <56CC3F8C.2090304@cisco.com> Date: Tue, 23 Feb 2016 12:16:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> 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: Tue, 23 Feb 2016 11:16:37 -0000 Dear all, It would be great if we can receive a status update on the Entity YANG model from the design team. And a milestone on the NETMOD charter would also make sense. Regards, Benoit > Is there a status update on ietf-entity please? I don't see it as a milestone in the charter but maybe I don't know where to look. > > Message received re YANG 1.1. All BBF YANG will use YANG 1.1. > > Thanks, > William > >> On 15 Dec 2015, at 10:17, Romascanu, Dan (Dan) wrote: >> >> So, let's do it. Tom, or one of the other chairs - you need to run this. >> >> Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: Benoit Claise [mailto:bclaise@cisco.com] >>> Sent: Monday, December 14, 2015 9:18 PM >>> To: Nadeau Thomas; Romascanu, Dan (Dan) >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG >>> module >>> >>> >>>> 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://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mail >>> man_listinfo_netmod&d=BQIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGx >>> R31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=9jKcR2EbKD3lb73tciJMJAk0J6 >>> 2dQAbsU_4R85zluXs&s=eBlkOZe4c5IXMoz_2YJnIKglubNBDQmS0Ej03Al8meI >>> &e= >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Feb 23 03:30:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F91A8856 for ; Tue, 23 Feb 2016 03:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 EM6jxWiTQAC0 for ; Tue, 23 Feb 2016 03:30:48 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 565E71B29E2 for ; Tue, 23 Feb 2016 03:30:47 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 4FDBC1AE0148; Tue, 23 Feb 2016 12:30:45 +0100 (CET) Date: Tue, 23 Feb 2016 12:30:49 +0100 (CET) Message-Id: <20160223.123049.2196242596452302418.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <56CC3F8C.2090304@cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> <56CC3F8C.2090304@cisco.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] 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, 23 Feb 2016 11:30:50 -0000 QmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4g DQo+IEl0IHdvdWxkIGJlIGdyZWF0IGlmIHdlIGNhbiByZWNlaXZlIGEgc3RhdHVzIHVwZGF0ZSBv biB0aGUgRW50aXR5IFlBTkcNCj4gbW9kZWwgZnJvbSB0aGUgZGVzaWduIHRlYW0uDQoNClRoZSBk ZXNpZ24gdGVhbSBpcyB3YWl0aW5nIGZvciB0aGUgV0cgdG8gZGVjaWRlIG9uIGFkb3B0aW9uIG9m IHRoZQ0KZG9jdW1lbnQuICBMYXN0IHRpbWUgdGhpcyB3YXMgZGlzY3Vzc2VkIEkgdGhpbmsgdGhl IGNoYWlycyBzYWlkIHRoYXQNCnRoZSBXRyBkaWQgbm90IGhhdmUgYW55IGN5Y2xlcyBmb3IgbmV3 IHdvcmsgdW50aWwgY3VycmVudCB3b3JrIHdhcw0KZmluaXNoZWQsIGJ1dCBJJ2xsIGxlYXZlIHRo aXMgdG8gdGhlIGNoYWlycyB0byBhbnN3ZXIuDQoNClRoZXJlIGFyZSBhY3R1YWxseSBxdWl0ZSBh IGZldyBkcmFmdHMgdG8gY29uc2lkZXIgd2hlbiBpdCBpcyB0aW1lIHRvDQphZGQgbW9yZSB3b3Jr IHRvIHRoZSBXRzsgIm1vdW50IiwgIm9wc3RhdGUiLA0KZHJhZnQtZW50aXR5ZHQtbmV0bW9kLWVu dGl0eSwgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nLA0KZHJhZnQtd2lsdG9uLW5l dG1vZC1pbnRmLXZsYW4teWFuZywNCmRyYWZ0LWxlYXItaWV0Zi1uZXRtb2QtYWNsLWRuc25hbWUs IGRyYWZ0LXZhbGxpbi1hbGFybS15YW5nLW1vZHVsZSB0bw0KbmFtZSBhIGZldy4gIEkgZ3Vlc3Mg d2UgbmVlZCB0byBwcmlvcml0aXplLg0KDQoNCg0KL21hcnRpbg0KDQoNCj4gQW5kIGEgbWlsZXN0 b25lIG9uIHRoZSBORVRNT0QgY2hhcnRlciB3b3VsZCBhbHNvIG1ha2Ugc2Vuc2UuDQo+IA0KPiBS ZWdhcmRzLCBCZW5vaXQNCj4gPiBJcyB0aGVyZSBhIHN0YXR1cyB1cGRhdGUgb24gaWV0Zi1lbnRp dHkgcGxlYXNlPyBJIGRvbid0IHNlZSBpdCBhcyBhDQo+ID4gbWlsZXN0b25lIGluIHRoZSBjaGFy dGVyIGJ1dCBtYXliZSBJIGRvbid0IGtub3cgd2hlcmUgdG8gbG9vay4NCj4gPg0KPiA+IE1lc3Nh Z2UgcmVjZWl2ZWQgcmUgWUFORyAxLjEuIEFsbCBCQkYgWUFORyB3aWxsIHVzZSBZQU5HIDEuMS4N Cj4gPg0KPiA+IFRoYW5rcywNCj4gPiBXaWxsaWFtDQo+ID4NCj4gPj4gT24gMTUgRGVjIDIwMTUs IGF0IDEwOjE3LCBSb21hc2NhbnUsIERhbiAoRGFuKSA8ZHJvbWFzY2FAYXZheWEuY29tPg0KPiA+ PiB3cm90ZToNCj4gPj4NCj4gPj4gU28sIGxldCdzIGRvIGl0LiBUb20sIG9yIG9uZSBvZiB0aGUg b3RoZXIgY2hhaXJzIC0geW91IG5lZWQgdG8gcnVuDQo+ID4+IHRoaXMuDQo+ID4+DQo+ID4+IFJl Z2FyZHMsDQo+ID4+DQo+ID4+IERhbg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNp c2NvLmNvbV0NCj4gPj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTQsIDIwMTUgOToxOCBQTQ0K PiA+Pj4gVG86IE5hZGVhdSBUaG9tYXM7IFJvbWFzY2FudSwgRGFuIChEYW4pDQo+ID4+PiBDYzog bmV0bW9kQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gQnJvYWRiYW5kIEZv cnVtIGludGVudGlvbiBvZiB1c2luZyBpZXRmLWVudGl0eQ0KPiA+Pj4gWUFORw0KPiA+Pj4gbW9k dWxlDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAJSSBwZXJzb25hbGx5IGRvbuKAmXQgc2VlIGFueXRo aW5nIHRoYXQgcHJldmVudHMgdGhpcy4NCj4gPj4+IFNhbWUgb3BpbmlvbiBoZXJlLg0KPiA+Pj4N Cj4gPj4+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+Pj4+IAnigJRUb20NCj4gPj4+Pg0KPiA+Pj4+PiBP biBEZWMgMTMsIDIwMTU6Njo1NiBBTSwgYXQgNjo1NiBBTSwgUm9tYXNjYW51LCBEYW4gKERhbikN Cj4gPj4+IDxkcm9tYXNjYUBhdmF5YS5jb20+IHdyb3RlOg0KPiA+Pj4+PiBDb25jZXJuaW5nIHRo ZSAnZHJhZnQgc3RhdHVzJyAtIGFueXRoaW5nIHByZXZlbnRzIHRoZSB3ZyBmcm9tIHJ1bm5pbmcN Cj4gPj4+Pj4gYQ0KPiA+Pj4gc2hvcnQgY29uc2Vuc3VzIGNhbGwgYW5kIGFkZGluZyB0aGlzIGl0 ZW0gdG8gdGhlIG5ldG1vZCBtaWxlc3RvbmVzPw0KPiA+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pg0K PiA+Pj4+PiBEYW4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5hZGVhdQ0KPiA+Pj4+Pj4gVGhvbWFzDQo+ID4+Pj4+PiBT ZW50OiBGcmlkYXksIERlY2VtYmVyIDExLCAyMDE1IDQ6MjcgUE0NCj4gPj4+Pj4+IFRvOiBXaWxs aWFtIEx1cHRvbg0KPiA+Pj4+Pj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiA+Pj4+Pj4gU3ViamVj dDogUmU6IFtuZXRtb2RdIEJyb2FkYmFuZCBGb3J1bSBpbnRlbnRpb24gb2YgdXNpbmcgaWV0Zi1l bnRpdHkNCj4gPj4+Pj4+IFlBTkcgbW9kdWxlDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IAlEZXBlbmRhbmNlIG9uIDEuMSBzaG91bGQgbm90IGJlIGFuIGlzc3VlIGFzIHRoYXQgaXMgYWxt b3N0IHJlYWR5IHRvDQo+ID4+Pj4+PiBiZSBhcHByb3ZlZC4gWW91IHNob3VsZCBiZSBidWlsZGlu ZyB5b3VyIG1vZGVsIHRvIGNvbXBseSB3aXRoIHRoZSAxLjENCj4gPj4+IHJ1bGVzLg0KPiA+Pj4+ Pj4gCeKAlFRvbQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVjIDExLCAyMDE1 Ojg6MDAgQU0sIGF0IDg6MDAgQU0sIFdpbGxpYW0gTHVwdG9uDQo+ID4+Pj4+PiA8d2x1cHRvbkBi cm9hZGJhbmQtZm9ydW0ub3JnPiB3cm90ZToNCj4gPj4+Pj4+PiBBbGwsDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiBUaGUgQnJvYWRiYW5kIEZvcnVtIHdvdWxkIGxpa2UgdG8gdXNlIHRoZSBpZXRmLWVu dGl0eSBZQU5HIG1vZHVsZQ0KPiA+Pj4+Pj4gKGN1cnJlbnRseSBkcmFmdC1lbnRpdHlkdC1uZXRt b2QtZW50aXR5KSBmb3IgZXF1aXBtZW50IG1hbmFnZW1lbnQNCj4gPj4+Pj4+IGJ1dCB3ZSBhcmUg YSBiaXQgY29uY2VybmVkIGFib3V0IGl0cyBkcmFmdCBzdGF0dXMgYW5kIGl0cyBkZXBlbmRlbmNl DQo+ID4+Pj4+PiBvbg0KPiA+Pj4gWUFORyAxLjEuDQo+ID4+Pj4+PiBBbnkgYWR2aWNlIG9yIHJl YXNzdXJhbmNlPw0KPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4+PiBXaWxsaWFtDQo+ID4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+Pj4gM0FfX3d3 dy5pZXRmLm9yZ19tYWlsDQo+ID4+PiBtYW5fbGlzdGluZm9fbmV0bW9kJmQ9QlFJRGFRJmM9QkZw V1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0ZHpHeA0KPiA+Pj4gUjMxT2NOWENKZlF6dmxzaUxRZnVj QlhSdWNQdmRycGhwQnNGQSZtPTlqS2NSMkViS0QzbGI3M3RjaUpNSkFrMEo2DQo+ID4+PiAyZFFB YnNVXzRSODV6bHVYcyZzPWVCbGtPWmU0YzVJWE1vel8yWUpuSUtnbHViTkJEUW1TMEVqMDNBbDht ZUkNCj4gPj4+ICZlPQ0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9y Zw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ IC4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Tue Feb 23 03:35:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663DC1B3BB3 for ; Tue, 23 Feb 2016 03:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] 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 Zimc7fImdaLP for ; Tue, 23 Feb 2016 03:35:33 -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 6D5DA1B30EA for ; Tue, 23 Feb 2016 03:35:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D5AQB2Q8xW/xUHmMZeGQEBAQEPAQEBAYJfK1JtBrhLghMBDYFmIYVsAhyBKTgUAQEBAQEBAWQnhEEBAQEBAxIREToEBwwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgah3kBDaIWikmPAQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4UYhDmENYMAK4EPBY0qiV0BhVaJY4RDgxmFOYVyiFceAQFCggMZgUhqhzwBfAEBAQ X-IPAS-Result: A2D5AQB2Q8xW/xUHmMZeGQEBAQEPAQEBAYJfK1JtBrhLghMBDYFmIYVsAhyBKTgUAQEBAQEBAWQnhEEBAQEBAxIREToEBwwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgah3kBDaIWikmPAQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4UYhDmENYMAK4EPBY0qiV0BhVaJY4RDgxmFOYVyiFceAQFCggMZgUhqhzwBfAEBAQ X-IronPort-AV: E=Sophos;i="5.22,489,1449550800"; d="scan'208";a="162189541" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2016 06:35:32 -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; 23 Feb 2016 06:35:31 -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, 23 Feb 2016 06:35:27 -0500 From: "Romascanu, Dan (Dan)" To: Martin Bjorklund , "bclaise@cisco.com" Thread-Topic: [netmod] Broadband Forum intention of using ietf-entity YANG module Thread-Index: AQHRbi2nSle6gXS+G0C4nLRQJtKoq585fyAw Date: Tue, 23 Feb 2016 11:35:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF6A905@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> <56CC3F8C.2090304@cisco.com> <20160223.123049.2196242596452302418.mbj@tail-f.com> In-Reply-To: <20160223.123049.2196242596452302418.mbj@tail-f.com> 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="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, 23 Feb 2016 11:35:35 -0000 U3BlYWtpbmcgYWJvdXQgbW91bnQgLSB3YXMgSSB0aGUgYWxvbmUgaW4gdGhpbmtpbmcgZHVyaW5n IHRoZSB2aXJ0dWFsIGludGVyaW0geWVzdGVyZGF5IGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiB0aGUgZW50aXR5IGFuZCBtb3VudCBJLURzLiBNYXliZSB1cCB0byBtZXJnaW5nIHRoZW0/ IEFyZSBub3QgTkxFcyB0aGUgc2FtZSAob3IgYWxtb3N0KSBhcyBsb2dpY2FsIGVudGl0aWVzPyAN Cg0KUmVnYXJkcywNCg0KRGFuDQogDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXQ0KPiBTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAyMywgMjAxNiAxOjMxIFBNDQo+IFRvOiBiY2xhaXNlQGNpc2NvLmNv bQ0KPiBDYzogd2x1cHRvbkBicm9hZGJhbmQtZm9ydW0ub3JnOyBSb21hc2NhbnUsIERhbiAoRGFu KTsNCj4gbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBCcm9hZGJhbmQg Rm9ydW0gaW50ZW50aW9uIG9mIHVzaW5nIGlldGYtZW50aXR5IFlBTkcNCj4gbW9kdWxlDQo+IA0K PiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IERlYXIg YWxsLA0KPiANCj4gPg0KPiANCj4gPiBJdCB3b3VsZCBiZSBncmVhdCBpZiB3ZSBjYW4gcmVjZWl2 ZSBhIHN0YXR1cyB1cGRhdGUgb24gdGhlIEVudGl0eSBZQU5HDQo+IA0KPiA+IG1vZGVsIGZyb20g dGhlIGRlc2lnbiB0ZWFtLg0KPiANCj4gDQo+IA0KPiBUaGUgZGVzaWduIHRlYW0gaXMgd2FpdGlu ZyBmb3IgdGhlIFdHIHRvIGRlY2lkZSBvbiBhZG9wdGlvbiBvZiB0aGUNCj4gDQo+IGRvY3VtZW50 LiAgTGFzdCB0aW1lIHRoaXMgd2FzIGRpc2N1c3NlZCBJIHRoaW5rIHRoZSBjaGFpcnMgc2FpZCB0 aGF0DQo+IA0KPiB0aGUgV0cgZGlkIG5vdCBoYXZlIGFueSBjeWNsZXMgZm9yIG5ldyB3b3JrIHVu dGlsIGN1cnJlbnQgd29yayB3YXMNCj4gDQo+IGZpbmlzaGVkLCBidXQgSSdsbCBsZWF2ZSB0aGlz IHRvIHRoZSBjaGFpcnMgdG8gYW5zd2VyLg0KPiANCj4gDQo+IA0KPiBUaGVyZSBhcmUgYWN0dWFs bHkgcXVpdGUgYSBmZXcgZHJhZnRzIHRvIGNvbnNpZGVyIHdoZW4gaXQgaXMgdGltZSB0bw0KPiAN Cj4gYWRkIG1vcmUgd29yayB0byB0aGUgV0c7ICJtb3VudCIsICJvcHN0YXRlIiwNCj4gDQo+IGRy YWZ0LWVudGl0eWR0LW5ldG1vZC1lbnRpdHksIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQt eWFuZywNCj4gDQo+IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi12bGFuLXlhbmcsDQo+IA0KPiBk cmFmdC1sZWFyLWlldGYtbmV0bW9kLWFjbC1kbnNuYW1lLCBkcmFmdC12YWxsaW4tYWxhcm0teWFu Zy1tb2R1bGUgdG8NCj4gDQo+IG5hbWUgYSBmZXcuICBJIGd1ZXNzIHdlIG5lZWQgdG8gcHJpb3Jp dGl6ZS4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC9tYXJ0aW4NCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiA+IEFuZCBhIG1pbGVzdG9uZSBvbiB0aGUgTkVUTU9EIGNoYXJ0ZXIgd291bGQg YWxzbyBtYWtlIHNlbnNlLg0KPiANCj4gPg0KPiANCj4gPiBSZWdhcmRzLCBCZW5vaXQNCj4gDQo+ ID4gPiBJcyB0aGVyZSBhIHN0YXR1cyB1cGRhdGUgb24gaWV0Zi1lbnRpdHkgcGxlYXNlPyBJIGRv bid0IHNlZSBpdCBhcyBhDQo+IA0KPiA+ID4gbWlsZXN0b25lIGluIHRoZSBjaGFydGVyIGJ1dCBt YXliZSBJIGRvbid0IGtub3cgd2hlcmUgdG8gbG9vay4NCj4gDQo+ID4gPg0KPiANCj4gPiA+IE1l c3NhZ2UgcmVjZWl2ZWQgcmUgWUFORyAxLjEuIEFsbCBCQkYgWUFORyB3aWxsIHVzZSBZQU5HIDEu MS4NCj4gDQo+ID4gPg0KPiANCj4gPiA+IFRoYW5rcywNCj4gDQo+ID4gPiBXaWxsaWFtDQo+IA0K PiA+ID4NCj4gDQo+ID4gPj4gT24gMTUgRGVjIDIwMTUsIGF0IDEwOjE3LCBSb21hc2NhbnUsIERh biAoRGFuKQ0KPiA8ZHJvbWFzY2FAYXZheWEuY29tPg0KPiANCj4gPiA+PiB3cm90ZToNCj4gDQo+ ID4gPj4NCj4gDQo+ID4gPj4gU28sIGxldCdzIGRvIGl0LiBUb20sIG9yIG9uZSBvZiB0aGUgb3Ro ZXIgY2hhaXJzIC0geW91IG5lZWQgdG8gcnVuDQo+IA0KPiA+ID4+IHRoaXMuDQo+IA0KPiA+ID4+ DQo+IA0KPiA+ID4+IFJlZ2FyZHMsDQo+IA0KPiA+ID4+DQo+IA0KPiA+ID4+IERhbg0KPiANCj4g PiA+Pg0KPiANCj4gPiA+Pg0KPiANCj4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gDQo+ID4gPj4+IEZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNv bV0NCj4gDQo+ID4gPj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTQsIDIwMTUgOToxOCBQTQ0K PiANCj4gPiA+Pj4gVG86IE5hZGVhdSBUaG9tYXM7IFJvbWFzY2FudSwgRGFuIChEYW4pDQo+IA0K PiA+ID4+PiBDYzogbmV0bW9kQGlldGYub3JnDQo+IA0KPiA+ID4+PiBTdWJqZWN0OiBSZTogW25l dG1vZF0gQnJvYWRiYW5kIEZvcnVtIGludGVudGlvbiBvZiB1c2luZyBpZXRmLWVudGl0eQ0KPiAN Cj4gPiA+Pj4gWUFORw0KPiANCj4gPiA+Pj4gbW9kdWxlDQo+IA0KPiA+ID4+Pg0KPiANCj4gPiA+ Pj4NCj4gDQo+ID4gPj4+PiAJSSBwZXJzb25hbGx5IGRvbuKAmXQgc2VlIGFueXRoaW5nIHRoYXQg cHJldmVudHMgdGhpcy4NCj4gDQo+ID4gPj4+IFNhbWUgb3BpbmlvbiBoZXJlLg0KPiANCj4gPiA+ Pj4NCj4gDQo+ID4gPj4+IFJlZ2FyZHMsIEJlbm9pdA0KPiANCj4gPiA+Pj4+IAnigJRUb20NCj4g DQo+ID4gPj4+Pg0KPiANCj4gPiA+Pj4+PiBPbiBEZWMgMTMsIDIwMTU6Njo1NiBBTSwgYXQgNjo1 NiBBTSwgUm9tYXNjYW51LCBEYW4gKERhbikNCj4gDQo+ID4gPj4+IDxkcm9tYXNjYUBhdmF5YS5j b20+IHdyb3RlOg0KPiANCj4gPiA+Pj4+PiBDb25jZXJuaW5nIHRoZSAnZHJhZnQgc3RhdHVzJyAt IGFueXRoaW5nIHByZXZlbnRzIHRoZSB3ZyBmcm9tDQo+IHJ1bm5pbmcNCj4gDQo+ID4gPj4+Pj4g YQ0KPiANCj4gPiA+Pj4gc2hvcnQgY29uc2Vuc3VzIGNhbGwgYW5kIGFkZGluZyB0aGlzIGl0ZW0g dG8gdGhlIG5ldG1vZCBtaWxlc3RvbmVzPw0KPiANCj4gPiA+Pj4+PiBSZWdhcmRzLA0KPiANCj4g PiA+Pj4+Pg0KPiANCj4gPiA+Pj4+PiBEYW4NCj4gDQo+ID4gPj4+Pj4NCj4gDQo+ID4gPj4+Pj4N Cj4gDQo+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IA0KPiA+ID4+Pj4+ PiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IE5hZGVhdQ0KPiANCj4gPiA+Pj4+Pj4gVGhvbWFzDQo+IA0KPiA+ID4+Pj4+PiBTZW50 OiBGcmlkYXksIERlY2VtYmVyIDExLCAyMDE1IDQ6MjcgUE0NCj4gDQo+ID4gPj4+Pj4+IFRvOiBX aWxsaWFtIEx1cHRvbg0KPiANCj4gPiA+Pj4+Pj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4g PiA+Pj4+Pj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIEJyb2FkYmFuZCBGb3J1bSBpbnRlbnRpb24g b2YgdXNpbmcgaWV0Zi0NCj4gZW50aXR5DQo+IA0KPiA+ID4+Pj4+PiBZQU5HIG1vZHVsZQ0KPiAN Cj4gPiA+Pj4+Pj4NCj4gDQo+ID4gPj4+Pj4+DQo+IA0KPiA+ID4+Pj4+PiAJRGVwZW5kYW5jZSBv biAxLjEgc2hvdWxkIG5vdCBiZSBhbiBpc3N1ZSBhcyB0aGF0IGlzIGFsbW9zdA0KPiByZWFkeSB0 bw0KPiANCj4gPiA+Pj4+Pj4gYmUgYXBwcm92ZWQuIFlvdSBzaG91bGQgYmUgYnVpbGRpbmcgeW91 ciBtb2RlbCB0byBjb21wbHkgd2l0aA0KPiB0aGUgMS4xDQo+IA0KPiA+ID4+PiBydWxlcy4NCj4g DQo+ID4gPj4+Pj4+IAnigJRUb20NCj4gDQo+ID4gPj4+Pj4+DQo+IA0KPiA+ID4+Pj4+Pg0KPiAN Cj4gPiA+Pj4+Pj4+IE9uIERlYyAxMSwgMjAxNTo4OjAwIEFNLCBhdCA4OjAwIEFNLCBXaWxsaWFt IEx1cHRvbg0KPiANCj4gPiA+Pj4+Pj4gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3Jv dGU6DQo+IA0KPiA+ID4+Pj4+Pj4gQWxsLA0KPiANCj4gPiA+Pj4+Pj4+DQo+IA0KPiA+ID4+Pj4+ Pj4gVGhlIEJyb2FkYmFuZCBGb3J1bSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgaWV0Zi1lbnRpdHkg WUFORw0KPiBtb2R1bGUNCj4gDQo+ID4gPj4+Pj4+IChjdXJyZW50bHkgZHJhZnQtZW50aXR5ZHQt bmV0bW9kLWVudGl0eSkgZm9yIGVxdWlwbWVudA0KPiBtYW5hZ2VtZW50DQo+IA0KPiA+ID4+Pj4+ PiBidXQgd2UgYXJlIGEgYml0IGNvbmNlcm5lZCBhYm91dCBpdHMgZHJhZnQgc3RhdHVzIGFuZCBp dHMNCj4gZGVwZW5kZW5jZQ0KPiANCj4gPiA+Pj4+Pj4gb24NCj4gDQo+ID4gPj4+IFlBTkcgMS4x Lg0KPiANCj4gPiA+Pj4+Pj4gQW55IGFkdmljZSBvciByZWFzc3VyYW5jZT8NCj4gDQo+ID4gPj4+ Pj4+PiBUaGFua3MsDQo+IA0KPiA+ID4+Pj4+Pj4gV2lsbGlhbQ0KPiANCj4gPiA+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+ID4+Pj4g bmV0bW9kIG1haWxpbmcgbGlzdA0KPiANCj4gPiA+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4g PiA+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0N Cj4gDQo+ID4gPj4+IDNBX193d3cuaWV0Zi5vcmdfbWFpbA0KDQo= From nobody Tue Feb 23 04:04:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631F81B3FA1 for ; Tue, 23 Feb 2016 04:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 P4wXy8Xk2Czx for ; Tue, 23 Feb 2016 04:04:12 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 323FE1B3EE0 for ; Tue, 23 Feb 2016 04:04:12 -0800 (PST) Received: (qmail 20118 invoked by uid 0); 23 Feb 2016 12:04:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 23 Feb 2016 12:04:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Mv3y1s01V2SSUrH01v411r; Tue, 23 Feb 2016 12:04:06 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=gEsRDbIwAAAA:8 a=u07AKapRAAAA:8 a=AUd_NHdVAAAA:8 a=mYPrF8hoAAAA:8 a=48vgC7mUAAAA:8 a=RpNjiQI2AAAA:8 a=idnoowfOnlon22O8pPgA:9 a=AnDBXN63Pq5gQ1ej:21 a=ZwTuH7W07nHGvfHl:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=PngrsjhiH8z1zKbNqSWidtcTOd9r4ANmrTPfKRrCvCg=; b=V4q8RvlwEUITRUUzIKzE1SFq6gPRgR3lJnmtP4s4o9oHdPJg3Np5WpoEsCo+QBbqX12YTovr3UTnaSDg+gs1H/CisyIkzt8GNoiQz0Y+9xCamhu6XIeRo1ispQ3s1RgD; Received: from [100.15.91.238] (port=49308 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYBhB-0002tT-Go; Tue, 23 Feb 2016 05:04:01 -0700 From: Lou Berger To: "Romascanu, Dan (Dan)" , Martin Bjorklund , Date: Tue, 23 Feb 2016 07:03:57 -0500 Message-ID: <1530e03b3c8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF6A905@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> <56CC3F8C.2090304@cisco.com> <20160223.123049.2196242596452302418.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6A905@AZ-FFEXMB04.global.avaya.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} 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, 23 Feb 2016 12:04:14 -0000 Dan, I could see entity as perhaps another use case, but don't understand how it could be another possible solution. Am I missing something? Lou On February 23, 2016 6:36:01 AM "Romascanu, Dan (Dan)" wrote: > Speaking about mount - was I the alone in thinking during the virtual > interim yesterday about the relationship between the entity and mount I-Ds. > Maybe up to merging them? Are not NLEs the same (or almost) as logical > entities? > > Regards, > > Dan > > >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: Tuesday, February 23, 2016 1:31 PM >> To: bclaise@cisco.com >> Cc: wlupton@broadband-forum.org; Romascanu, Dan (Dan); >> netmod@ietf.org >> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG >> module >> >> Benoit Claise wrote: >> >> > Dear all, >> >> > >> >> > It would be great if we can receive a status update on the Entity YANG >> >> > model from the design team. >> >> >> >> The design team is waiting for the WG to decide on adoption of the >> >> document. Last time this was discussed I think the chairs said that >> >> the WG did not have any cycles for new work until current work was >> >> finished, but I'll leave this to the chairs to answer. >> >> >> >> There are actually quite a few drafts to consider when it is time to >> >> add more work to the WG; "mount", "opstate", >> >> draft-entitydt-netmod-entity, draft-wilton-netmod-intf-ext-yang, >> >> draft-wilton-netmod-intf-vlan-yang, >> >> draft-lear-ietf-netmod-acl-dnsname, draft-vallin-alarm-yang-module to >> >> name a few. I guess we need to prioritize. >> >> >> >> >> >> >> >> /martin >> >> >> >> >> >> > And a milestone on the NETMOD charter would also make sense. >> >> > >> >> > Regards, Benoit >> >> > > Is there a status update on ietf-entity please? I don't see it as a >> >> > > milestone in the charter but maybe I don't know where to look. >> >> > > >> >> > > Message received re YANG 1.1. All BBF YANG will use YANG 1.1. >> >> > > >> >> > > Thanks, >> >> > > William >> >> > > >> >> > >> On 15 Dec 2015, at 10:17, Romascanu, Dan (Dan) >> >> >> > >> wrote: >> >> > >> >> >> > >> So, let's do it. Tom, or one of the other chairs - you need to run >> >> > >> this. >> >> > >> >> >> > >> Regards, >> >> > >> >> >> > >> Dan >> >> > >> >> >> > >> >> >> > >>> -----Original Message----- >> >> > >>> From: Benoit Claise [mailto:bclaise@cisco.com] >> >> > >>> Sent: Monday, December 14, 2015 9:18 PM >> >> > >>> To: Nadeau Thomas; Romascanu, Dan (Dan) >> >> > >>> Cc: netmod@ietf.org >> >> > >>> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity >> >> > >>> YANG >> >> > >>> module >> >> > >>> >> >> > >>> >> >> > >>>> 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://urldefense.proofpoint.com/v2/url?u=https- >> >> > >>> 3A__www.ietf.org_mail > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Feb 23 04:19:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E018E1B42FA for ; Tue, 23 Feb 2016 04:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] 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 JwmQ5aZlr52C for ; Tue, 23 Feb 2016 04:19:18 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1C81B42FE for ; Tue, 23 Feb 2016 04:19:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AaAgBcTcxW/yYyC4deGQEBAQEPAQEBAYJfK4E/BrhLghMBDYFmhg0CHIEqOBQBAQEBAQEBZCeEQQEBAQEDEhERPgcMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQBDQUIEweHeQGiRopJjmcBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4UYhDmENRaCaiuBDwWXBwGXFYU5jkkeAQFCg2RqhzwBfAEBAQ X-IPAS-Result: A2AaAgBcTcxW/yYyC4deGQEBAQEPAQEBAYJfK4E/BrhLghMBDYFmhg0CHIEqOBQBAQEBAQEBZCeEQQEBAQEDEhERPgcMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQBDQUIEweHeQGiRopJjmcBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4UYhDmENRaCaiuBDwWXBwGXFYU5jkkeAQFCg2RqhzwBfAEBAQ X-IronPort-AV: E=Sophos;i="5.22,489,1449550800"; d="scan'208";a="143802872" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Feb 2016 07:19:14 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 23 Feb 2016 07:19:13 -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, 23 Feb 2016 07:19:09 -0500 From: "Romascanu, Dan (Dan)" To: Lou Berger , Martin Bjorklund , "bclaise@cisco.com" Thread-Topic: [netmod] Broadband Forum intention of using ietf-entity YANG module Thread-Index: AQHRbi2nSle6gXS+G0C4nLRQJtKoq585fyAw///4TICAABSQkA== Date: Tue, 23 Feb 2016 12:19:09 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF6AB40@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com> <3511C7D2-442E-44B6-8A0F-DE8472614CAD@broadband-forum.org> <56CC3F8C.2090304@cisco.com> <20160223.123049.2196242596452302418.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6A905@AZ-FFEXMB04.global.avaya.com> <1530e03b3c8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <1530e03b3c8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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="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, 23 Feb 2016 12:19:20 -0000 VGhhdCdzIHdoYXQgSSBtZWFudCAtIExORXMgc2VlbSB0byBiZSBhbiBpbnN0YW50aWF0aW9uIG9m IGxvZ2ljYWwgZW50aXRpZXMuIA0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAxNiAyOjA0IFBNDQo+IFRvOiBS b21hc2NhbnUsIERhbiAoRGFuKTsgTWFydGluIEJqb3JrbHVuZDsgYmNsYWlzZUBjaXNjby5jb20N Cj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gQnJvYWRiYW5k IEZvcnVtIGludGVudGlvbiBvZiB1c2luZyBpZXRmLWVudGl0eSBZQU5HDQo+IG1vZHVsZQ0KPiAN Cj4gRGFuLA0KPiBJIGNvdWxkIHNlZSBlbnRpdHkgYXMgcGVyaGFwcyBhbm90aGVyIHVzZSBjYXNl LCBidXQgZG9uJ3QgdW5kZXJzdGFuZCBob3cgaXQNCj4gY291bGQgYmUgYW5vdGhlciBwb3NzaWJs ZSBzb2x1dGlvbi4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gDQo+IExvdQ0KPiANCj4gDQo+ IE9uIEZlYnJ1YXJ5IDIzLCAyMDE2IDY6MzY6MDEgQU0gIlJvbWFzY2FudSwgRGFuIChEYW4pIg0K PiA8ZHJvbWFzY2FAYXZheWEuY29tPg0KPiB3cm90ZToNCj4gDQo+ID4gU3BlYWtpbmcgYWJvdXQg bW91bnQgLSB3YXMgSSB0aGUgYWxvbmUgaW4gdGhpbmtpbmcgZHVyaW5nIHRoZSB2aXJ0dWFsDQo+ ID4gaW50ZXJpbSB5ZXN0ZXJkYXkgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBl bnRpdHkgYW5kIG1vdW50IEktDQo+IERzLg0KPiA+IE1heWJlIHVwIHRvIG1lcmdpbmcgdGhlbT8g QXJlIG5vdCBOTEVzIHRoZSBzYW1lIChvciBhbG1vc3QpIGFzIGxvZ2ljYWwNCj4gPiBlbnRpdGll cz8NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBEYW4NCj4gPg0KPiA+DQoNCg== From nobody Tue Feb 23 07:08:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2021B315E for ; Tue, 23 Feb 2016 07:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 4TaK8Sbvmsrl for ; Tue, 23 Feb 2016 07:08:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 264551B3156 for ; Tue, 23 Feb 2016 07:08:04 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 1FE751AE035B for ; Tue, 23 Feb 2016 16:08:02 +0100 (CET) Date: Tue, 23 Feb 2016 16:08:06 +0100 (CET) Message-Id: <20160223.160806.696185201696745163.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] explicit mount 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, 23 Feb 2016 15:08:05 -0000 Hi, In yesterday's meeting, Lou (I think?) mentioned a use case for mount that is not documented in draft-rtgyangdt-rtgwg-device-model; the need for being able to specify modules to mount directly in the schema. Something like this: container root { ymnt:mount-point "lne" { ymnt:mount-module "ietf-interfaces"; } } It would be useful if the use case for this could be described in more details. Is it a requirement to be able to specify this in the schema, or could it be done (as Chris mentioned) in the RFC text? The reason I ask is that it is probably not as simple as the example above. First, you probably need to specify a revision of the module to be mounted. Or a min-revision. Then probably a set of features that must be enabled. And so on. It turns out that there is already a proposal for specifying such a "conformance profile" - YANG Packages (see draft-bierman-netmod-yang-package). Maybe it would be better to re-use packages? /martin From nobody Tue Feb 23 09:08:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321D1B369E; Tue, 23 Feb 2016 09:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 FZvM5BnYjsGV; Tue, 23 Feb 2016 09:08:05 -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 EC47C1B369F; Tue, 23 Feb 2016 09:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2506; q=dns/txt; s=iport; t=1456247284; x=1457456884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OFFrZzukDpk8UqJJKaNBNwbkcJv5zkFFP8u0afIQ0q8=; b=gxzLd6aAKCqvIerNqc+swGaZ1TJxJYaWOnfQv157dfCTfKJCDFHsPpka KNUppXJGiUBqpelIkKyHS9xYoDzfjqIlSJk71Tam6M9Tdg6wLoETrWEgF MnW7M2qjPQDEfNJtViMOAmPMilCCIbjq8vzGFSc7bQxhsyWCU07a9GyHz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHBQC2kcxW/5pdJa1egzpSbQa6cYFmI?= =?us-ascii?q?YVsAhyBLDoSAQEBAQEBAWQnhEIBAQQjEUAFEAIBCA4MAiYCAgIwFRACBA4FiB0?= =?us-ascii?q?OrgaOcwEBAQEBAQEBAQEBAQEBAQEBAQEBARV7hReBbAiCRoQFEQEcGIJqK4EPB?= =?us-ascii?q?ZcHAYVWiAeBXEqDeYhSjkgBJwM4g2RqAYcDNH0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,490,1449532800"; d="scan'208";a="241584558" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 17:08:04 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1NH833L028216 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 17:08:04 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 11:07:12 -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, 23 Feb 2016 11:07:12 -0600 From: "Clyde Wildes (cwildes)" To: Lou Berger , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" Thread-Topic: draft-ietf-netmod-syslog-model-06 Thread-Index: AQHRbdiu8RHGhLk0SUaNPvspSBufoJ85vA0A Date: Tue, 23 Feb 2016 17:07:12 +0000 Message-ID: <87BD35B5-D482-4908-8D06-7B08EE4A5991@cisco.com> References: <56CBB450.9080403@labn.net> In-Reply-To: <56CBB450.9080403@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.36.184] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod chairs , netmod WG Subject: Re: [netmod] draft-ietf-netmod-syslog-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: Tue, 23 Feb 2016 17:08:07 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQoNCkNseWRlDQoNCg0KDQoNCg0KT24gMi8yMi8xNiwgNToyMiBQTSwgIkxvdSBCZXJnZXIiIDxs YmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KPkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQo+ DQo+QXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbA0KPg0KPkFyZSB5 b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92 ZT8NCj4NCj5QbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0KPiJObywgSSdtIG5vdCBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJl IG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj4NCj5JZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KPihz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPg0K PklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQo+DQo+IlllcywgdGhl IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz Ig0KPm9yDQo+Ik5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+DQo+SWYgeW91 IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhp bmsNCj5hcHByb3ByaWF0ZS4NCj4NCj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1 dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KPmFib3ZlIGJ5IHJlc3BvbmRp bmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCj5h d2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2Ug dG8gdGhlIG5leHQNCj5zdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZy b20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KPmNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJ RVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MNCj5UTyBMSU5FUy4NCj4N Cj5JZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBi dXQgYXJlIG5vdCBsaXN0ZWQNCj5hcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWlu ZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcg0KPnRoZSBJRVRGIElQUiBydWxlcyB3aGlj aCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KPmF3YXJlIG9m IElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJv bQ0KPnBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0 ZWQgdG8geW91cg0KPnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFz ZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQo+YW5kDQo+aHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQo+DQo+VGhh bmsgeW91LA0KPk5FVE1PRCBXRyBDaGFpcnMNCj4NCj5QUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlz dGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQo+cmVzcG9uc2UuDQo+ DQo+DQo= From nobody Tue Feb 23 11:05:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D130B1A8911; Tue, 23 Feb 2016 11:05:25 -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 8o6yatl-VWxG; Tue, 23 Feb 2016 11:05:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.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 2A1C01A891A; Tue, 23 Feb 2016 11:05:16 -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.409.15; Tue, 23 Feb 2016 19:05:15 +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.0409.024; Tue, 23 Feb 2016 19:05:15 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: working group secretary position Thread-Index: AQHRbm0g5U7Ub/IQl0GVAEQpdydREg== Date: Tue, 23 Feb 2016 19:05:15 +0000 Message-ID: <02835CDF-1050-4D87-B11A-607E3D9CEC14@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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:OgelUnLdQbTG68h3SVv2ViuoDgCKC/b7nV7Sy/q2YRuhr5/R1Yh4+AeRk+Yit43+/CB+VjJfvSe3CfqQEqSEy7aSRutM+Su+NLz9MuLB9NAnj3nvQMY9GcCAcDm4R4lmx+jpnj9nQj0iAjtDOe5FrA==; 24:CvkWOzow0D6BcDx9czdU3mMmEBDLveIMCb4n1EwsQQberGNTGuRE3HfuOAd5th+s1LOVGTlpBCEfRkKHN0CWnSClUjXCKW6UU7HMSooGeqI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 9529e58b-542b-4e0c-5917-08d33c844360 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)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2900100001)(450100001)(82746002)(77096005)(122556002)(10400500002)(40100003)(99286002)(5002640100001)(102836003)(3846002)(11100500001)(6116002)(4326007)(586003)(1730700002)(1220700001)(5004730100002)(5008740100001)(2906002)(3280700002)(83506001)(3480700003)(3660700001)(87936001)(92566002)(50986999)(2501003)(36756003)(54356999)(106116001)(2351001)(229853001)(83716003)(86362001)(33656002)(189998001)(4001350100001)(66066001)(1096002)(5001960100002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8268AAB489C8584EBAE1F9428384FF81@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 19:05:15.0765 (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-chairs@ietf.org" Subject: [netmod] working group secretary position 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, 23 Feb 2016 19:05:26 -0000 QWxsLA0KDQpXZSBhcmUgY29uc2lkZXJpbmcgd2hldGhlciB0byBmaWxsIHRoZSBvcGVuIHdvcmtp bmcgZ3JvdXAgc2VjcmV0YXJ5IHBvc2l0aW9uLiBXb3JraW5nIEdyb3VwIHNlY3JldGFyaWVzIGhl bHAgd2l0aCBXb3JraW5nIEdyb3VwIGFkbWluaXN0cmF0aXZlIHRhc2tzLCBhbmQgYXJlIHR5cGlj YWxseSByZXNwb25zaWJsZSBmb3I6DQoNCiogcHJvZHVjaW5nIGRyYWZ0IG1lZXRpbmcgbm90ZXMg YmFzZWQgb24gYXR0ZW5kaW5nIHRoZSBhY3R1YWwgbWVldGluZywgb3IgbGlzdGVuaW5nIHRvIHJl Y29yZGluZ3MgKG9yIGVuc3VyaW5nIHRoYXQgdGhleSBpZGVudGlmeSBzb21lb25lIHRvIHByb2R1 Y2UgaXQgZm9yIHRoZW0pDQoNCiogZW5zdXJpbmcgZGF0YSB0cmFja2VyIG1hdGNoZXMgdGhlIGRp c2N1c3Npb24gb24gdGhlIGxpc3QgLCBlZywgYWRvcHRpb24gcG9sbHMgYW5kIElQUiBjaGVja3Mu DQoNCiogY29uc29saWRhdGluZyBtZWV0aW5nIHNsb3QgcmVxdWVzdHMgYW5kIG1lZXRpbmcgcHJl c2VudGF0aW9ucw0KDQoqIGVuc3VyaW5nICBhZ2VuZGFzLCBwcmVzZW50YXRpb25zLCBtaW51dGVz LCBhcmUgcG9zdGVkICB0byBNYXRlcmlhbHMgTWFuYWdlcg0KDQpCZWluZyBhIHdvcmtpbmcgZ3Jv dXAgc2VjcmV0YXJ5IG5vdCBvbmx5IGhlbHBzIG91dCB0aGUgY2hhaXJzIGFuZCB0aGUgd29ya2lu ZyBncm91cCwgYnV0IGl0J3MgYWxzbyBnZW5lcmFsbHkgdmlld2VkIGFzIGEgZ29vZCB3YXkgdG8g Z2V0IGV4cGVyaWVuY2UgZm9yIHRob3NlIGludGVyZXN0ZWQgaW4gYmVjb21pbmcgYSBXb3JraW5n IEdyb3VwIENoYWlyIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS4NCg0KSWYgeW91IGFyZSBp bnRlcmVzdGVkIGluIHNlcnZpbmcgdGhpcyBmdW5jdGlvbiBmb3IgbmV0bW9kLCBwbGVhc2UgbGV0 IHRoZSBjaGFpcnMga25vdyB3aXRoaW4gdGhlIG5leHQgdHdvIHdlZWtzLiAoSWYgeW91IHJlcGx5 IHRvIHRoaXMgbWFpbCB0aGVyZSBpcyBubyBuZWVkIHRvIENDIHRoZSBtYWlsaW5nIGxpc3QuKQ0K DQoNClRoYW5rIHlvdSwNCg0KTmV0bW9kIENoYWlycw0KDQoNCg== From nobody Tue Feb 23 11:53:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE421A8F48; Tue, 23 Feb 2016 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_210=0.6, 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 RZJUITQHaP-8; Tue, 23 Feb 2016 11:53:06 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B791A8A91; Tue, 23 Feb 2016 11:53:05 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c200so237937760wme.0; Tue, 23 Feb 2016 11:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=EE5Las4lWz928nTIGNeBanZqPrO8tfoKXnQN5gE9De0=; b=NrxSXK0R0p28fn+4g5ia0ZnLJ1toaxN40LpzWCB5Gfu+edFXZQI+OcE9N4+mA1O2vg zYZWM7N8HvNVYe3MHmKNS/IfkJ/JvazyyYERNS3gOQ5KALBtQiXEX5uQXS/X2ZEInmcv KIlVrCuyQdlBK+CYwvvjYUsY6VkkPvcK/Os8gkVgy7m5qYqQkdLWwzy2TQEeTgc1sPyv 8LVfJL3yYtXL6kZXLfIeFdKYUuppxlx4x9CM1CVPTMxBgm4xQUc0kbAVISCMVq35GFln N9WYkwtm8LvVLeCAxDNQP9fGzUye/9KzuKOGZYZvjr3sXGkXNgFyQLwGA58gSfpdY5jY WC/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=EE5Las4lWz928nTIGNeBanZqPrO8tfoKXnQN5gE9De0=; b=gpBa+3EVEu6okBsq5czhVu0h/Pi6gZnf49liZDeo3mnecVyixrNteaGlr0sJUaNv/B nSs2nbu1Wa7IcGFI9D2wLQ7ann6jE27WMRDBSSZCvlwSHVyN69XCL5mNC2XjaF47sA6A Jr7Nh+FVlxYpMuYdN0OX9EiltoWK2m6LnMUOE/vwaYoyOludE2nAfD4MYqxDW+Dg33TV /mUIPO6nV549MlBo/pT9pLTHwnsh8RM7/McYJ9wuCIHLkS+Psiiv/r2l2KnOmPUKaPiq k01YcGxUOitp1PqSAjZ9zCQjXTSpN1D+EfNyoTjQ/c7qePkI1juvMAtEKdUD0gvr9KbS Bd6w== X-Gm-Message-State: AG10YOQG0kpQ6ekGN+/MSL7xOHtkrIkckYL1aQExpOZUJOLeoIScvAAoNSprV8+HDU7gmA== X-Received: by 10.28.105.136 with SMTP id z8mr20574472wmh.71.1456257184233; Tue, 23 Feb 2016 11:53:04 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id gt7sm31319528wjc.1.2016.02.23.11.53.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2016 11:53:03 -0800 (PST) From: "Xufeng Liu" To: "'Ladislav Lhotka'" , "'Martin Bjorklund'" References: <001401d16b2f$ff3c1e60$fdb45b20$@gmail.com> <20160222.093546.333236529598665891.mbj@tail-f.com> In-Reply-To: Date: Tue, 23 Feb 2016 14:53:01 -0500 Message-ID: <00e001d16e73$ce8a0060$6b9e0120$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHS51Ocn+ye09zmh0RlEVeWfsZeFQE5FGigAbxD8FSfH2wPsA== Content-Language: en-us Archived-At: Cc: draft-bjorklund-netmod-structural-mount@ietf.org, draft-lhotka-netmod-ysdl@ietf.org, netmod@ietf.org Subject: Re: [netmod] Yang mount / ysdl questions 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, 23 Feb 2016 19:53:07 -0000 Thanks Martin and Lada. > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Monday, February 22, 2016 6:57 AM > To: Martin Bjorklund ; xufeng.liu.ietf@gmail.com > Cc: netmod@ietf.org; draft-lhotka-netmod-ysdl@ietf.org; draft-bjorklund- > netmod-structural-mount@ietf.org > Subject: Re: [netmod] Yang mount / ysdl questions > > Martin Bjorklund writes: > > > Hi, > > > > "Xufeng Liu" wrote: > >> While realizing that the mechanism specified in the two drafts is > >> very useful for modeling, I have a few questions that are common to > >> both > >> approaches: > >> > >> > >> > >> - How to mount one tree (but not other trees) from a module? For > >> example, I may want to mount interfaces to one mounting point, but > >> interfaces-state to a different mounting point. > > > > Currently this is not possible. If you want to use such a mechanism > > to mount selected subtrees from a module, it is not clear that this > > will work - there might be references from subtree A to subtree B, so > > if subtree B is not mounted, it is unclear how such references should > > be handled. > > Same in YSDL. [Xufeng] Understand the difficulties, but the capability could be useful. > > > > >> - When the mounting module is augmented by another module, what will > >> happen to these augmentations after mounting? What will be the XPath > >> to refer a node in the mounting module (from mounting module, and > >> from mounted module)? > > > > If the augmenting module it not mounted, nothing happens - it is just > > not there. If the augmenting module is also mounted, it will be > > augment the mounted module. For example, suppose ietf-interfaces and > > ietf-ip are both mounted at /foo. The resulting tree would be: > > > > +--rw foo > > +--rw if:interfaces > > +--rw if:interface* [name] > > ... > > +--rw ip:ipv4! > > > > It's also similar in YSDL. Augments apply only within a single schema, which is > essentially what we have now. [Xufeng] This would be good. Thanks. Can this description put into the document? > > > > >> - When a mounting module is used to mount to a mounting-point in > >> my-module, how can the system also expose the mounting model in the > >> original form, i.e. at the root level? > > > > The system exposes all "top-level" modules as usual - just list them > > in the top-level YANG library. > > In YSDL one would need to be able to specify "/" as the root node for the > "mounted" schema. It's not allowed in -00 but it might be a useful extension. I > don't see any reason why it shouldn't work. > [Xufeng] I think that it would be desirable to have the options to do either. Thanks. > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Feb 23 15:21:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325631AC42B for ; Tue, 23 Feb 2016 15:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=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 JS_gt9WD9ICd for ; Tue, 23 Feb 2016 15:21:20 -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 84A141A8912 for ; Tue, 23 Feb 2016 15:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3126; q=dns/txt; s=iport; t=1456269680; x=1457479280; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JsEKJ7+Mw5C88q5vUh0wHltfS2/SVC1dDAvq1Eu9+T4=; b=HovxoHf4/YTAeXUOyvxzmrgRf+2565HomS56idiK2MDAegeqz1HD9MWy hwsuKGlykWSQFDbUmZmJzdAkjFzVZjzWSXy8lU1ebvV8hsAcYwoBk6Bdp jSZ7h9YUHLX9+qBt4YnsPKSFYOT4sXz5JQlcFNMszjeVs/QCm+jaOiwW/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgD16MxW/5ldJa1EGoM6Um0BBbhTg?= =?us-ascii?q?R12AQ2BZiOFC18CHIEsOBQBAQEBAQEBZCeEQQEBAQMBIxFABQULAgEIDgcFAiY?= =?us-ascii?q?CAgIwFRACBAENDQwHh3sIDiyuGo5sAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFF?= =?us-ascii?q?4Q6gTaFf4E6BZcHAYVWgm6FEoFjSoN5hziBGo5IAR4BAUKCAxmBSGoBBIczfQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.22,491,1449532800"; d="scan'208";a="74333620" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 23:21:19 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1NNLJQW024468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 23:21:19 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 17:21:18 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 17:21:18 -0600 From: "Eric Voit (evoit)" To: Kent Watsen , "Martin Bjorklund (mbjorklu)" , "Alexander Clemm (alex)" , "Ladislav Lhotka" , Lou Berger Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4AgAB9CgCAAgagwA== Date: Tue, 23 Feb 2016 23:21:18 +0000 Message-ID: <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> References: <20160210154624.25146.86523.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-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 23 Feb 2016 23:21:23 -0000 SGkgS2VudCwNCg0KVGhhbmtzIGZvciBydW5uaW5nIHRoZSBpbnRlcmltLCBJIGFncmVlIGl0IHdh cyBxdWl0ZSB1c2VmdWwuICAgIA0KDQpPbmUgdGhpbmcgSSB3YW50ZWQgdG8gcHVsbCBvdXQgZnJv bSB0aGUgbWludXRlcyB3YXMgdGhlIG92ZXJhbGwgZGVmaW5pdGlvbiBvZiAiTW91bnQiLiAgICAg UmlnaHQgbm93IHRoZXJlIGFyZSA4MzAgd2ViIHBhZ2VzIG9uIHRoZSBPcGVuRGF5bGlnaHQgc2l0 ZSB3aGljaCByZWZlciB0byAiTW91bnQiIGluIHRlcm1zIG9mIFBlZXIgTW91bnQgKGkuZS4sIHNv bWV0aGluZyBtdWNoIGxpa2UgZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50KS4gICANCg0KVGhhdCBk b2VzIG5vdCBtZWFuIHRoYXQgdGhlIElFVEYgbmVlZCBkZWZpbmUgIk1vdW50IiB0aGUgc2FtZSB3 YXkgYXMgYW4gT3BlbiBTb3VyY2UgcHJvamVjdC4gIEJ1dCBpdCBpcyBwb3NzaWJsZSBhdCB0aGlz IHN0YWdlIHRvIGNyZWF0ZSBib3RoIHRlcm1pbm9sb2d5IGFuZCByZXF1aXJlbWVudHMgd2hpY2gg YnJlYWtzIGRvd24gdGhlIG92ZXJhbGwgcHJvYmxlbSBzcGFjZS4gICBJbiBvdGhlciB3b3JkcyB0 aGVyZSBpcyBub3RoaW5nIHN0b3BwaW5nIHVzIGZyb20gZGVmaW5pbmcgYSBzZXQgb2YgdGVybXMg YW5kIHRlY2hub2xvZ3kgc29sdXRpb25zIHdoaWNoIGZpdCB0b2dldGhlciBpbiBhIGNvbXBsaW1l bnRhcnkgd2F5LiAgTm90aGluZyBoZXJlIG5lZWQgY29uZmxpY3QuDQoNCklmIHRoZXJlIGlzIGNv bW11bml0eSBpbnRlcmVzdCwgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHB1bGwgdG9nZXRoZXIgYSBz dHJhd21hbiByZXF1aXJlbWVudHMvdGVybWlub2xvZ3kgZHJhZnQgZGVzY3JpYmluZyB0aGUgZGlm ZmVyZW5jZXMgYmV0d2VlbiBtb3VudGluZyBzY2hlbWFzIG9uIGEgYm94LCBtb3VudGluZyBhIHJl bW90ZSBkYXRhc3RvcmUuDQoNCkFueSBpbnRlcmVzdD8NCkVyaWMgDQoNCj4gRnJvbTogbmV0bW9k LCBGZWJydWFyeSAyMiwgMjAxNiAzOjUxIFBNDQo+IA0KPiANCj4gVGhhbmsgeW91IGFsbCB3aG8g am9pbmVkIHRvZGF54oCZcyB2aXJ0dWFsIGludGVyaW0gbWVldGluZy4NCj4gDQo+IE90aGVyIHRo YW4gbXkgc3RhcnRpbmcgdGhlIHJlY29yZGluZyBsYXRlIGFuZCByZWFycmFuZ2luZyB0aGUgcHJl c2VudGF0aW9uIG9yZGVyLA0KPiBJIHRob3VnaHQgdGhhdCB0aGUgbWVldGluZyB3ZW50IHJlYWxs eSB3ZWxsIGluIHRoYXQgdGhlcmUgc2VlbXMgdG8gYmUgYSBsb3Qgb2YNCj4gc3VwcG9ydCBmb3Ig dHJ5aW5nIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSwgYW5kIGJlY2F1c2Ugd2UgaGF2ZSBhIHBsYW4g dG8gdHJ5IHRvDQo+IG1vdmUgdG93YXJkcyBoYXZpbmcgYSBXRyBkb2N1bWVudCBpbiB0aGUgQkEg dGltZWZyYW1lLiAgVGhlIHBsYW4gaXMgZm9yDQo+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3Ry dWN0dXJhbC1tb3VudCB0byBiZSB1cGRhdGVkIGJhc2VkIG9uIHRoZSBtZWV0aW5nDQo+IGFuZCBm b3IgaXQgdG8gYmUgZGlzY3Vzc2VkIG9uIGxpc3QgYXMgdGhlIGJhc2lzIGZvciB0aGUgV0cgZWZm b3J0IG9uIHRoZSB0b3BpYy4NCj4gDQo+IEF0dGFjaGVkIGFyZSB0aGUgdmVyeSByb3VnaCBFdGhl cm5ldCBtaW51dGVzIGNhcHR1cmVkIGR1cmluZyB0aGUgbWVldGluZy4NCj4gUGxlYXNlIHJldmll dyBjYXJlZnVsbHkuICBDb3JyZWN0aW9ucyBjYW4gYmUgbWFkZSBvbiB0aGUgZXRoZXJwYWQgaGVy ZToNCj4gaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9uZXRtb2QtaW50ZXJp bS0yMDE2MDIyMiAgKHNvIHdlIGNhbg0KPiB0cmFjayBjaGFuZ2VzLCB0aGUgZW5kIG9mIG1lZXRp bmcgc25hcHNob3QgaXMgaGVyZToNCj4gaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkw MDAvcC9uZXRtb2QtaW50ZXJpbS0NCj4gMjAxNjAyMjIvdGltZXNsaWRlciMzOTMzKQ0KPiANCj4g VG8gbGlzdGVuIHRvIHRoZSByZWNvcmRpbmcsIHBsZWFzZSBmb2xsb3cgb25lIG9mIHRoZXNlIHR3 byBsaW5rczoNCj4gDQo+ICAgU3RyZWFtaW5nIHJlY29yZGluZyBsaW5rOg0KPiANCj4gaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD00ZGM4ODM4NmYxM2E0OWZhOGYyYzkz NGRiOTUzZjRhMg0KPiANCj4gICBEb3dubG9hZCByZWNvcmRpbmcgbGluazoNCj4gDQo+IGh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9MWI2NDkwZmU1Y2M2ZmM5NWQ0ZTNj OWI5MTNkZmRjMWYNCj4gDQo+IA0KPiBUaGFua3MgYWdhaW4sDQo+IA0KPiBLZW50IGFuZCBMb3UN Cg0K From nobody Tue Feb 23 16:19:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645E91B3B8D for ; Tue, 23 Feb 2016 16:19:02 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 iUku-9HPGzeS for ; Tue, 23 Feb 2016 16:19:00 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514BF1B3B88 for ; Tue, 23 Feb 2016 16:18:59 -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.409.15; Wed, 24 Feb 2016 00: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.0409.024; Wed, 24 Feb 2016 00:18:43 +0000 From: Kent Watsen To: "Eric Voit (evoit)" , "Martin Bjorklund (mbjorklu)" , "Alexander Clemm (alex)" , "Ladislav Lhotka" , Lou Berger Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4AgAB9CgCAAgagwP//xcQA Date: Wed, 24 Feb 2016 00:18:42 +0000 Message-ID: <5FACD2B1-C487-44F1-A2D8-EED924048654@juniper.net> References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> In-Reply-To: <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.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.160212 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:4inyQcBUbnbMOY9W940JAhsgW+KHqinU6d5dHaLMmQPngcBYWO7QKVFpwtsmbusvfGJNewmx2AC5MLzEIrx5Stf6lzPVw0euaANFo58Ov8FD5Re4fwZEgDt4D6G3TP2ibfPQoJnXyQba7Y3mWlsM0Q==; 24:8h5Dn4JsNZU1HMr+etbbxiNP18Kfm9HAj9QM3shp/AQi6/sS4Hm0qz4SRHKTBEpS94+tmF5xP4GNqmRJEwk6CJYjRehHQD3IvTtZVs202xI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-ms-office365-filtering-correlation-id: a2df805a-d9b3-47d4-8b6c-08d33cb00db3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 08626BE3A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(76104003)(43784003)(377454003)(479174004)(24454002)(52604005)(83716003)(15975445007)(106116001)(122556002)(77096005)(99286002)(16799955002)(93886004)(5002640100001)(10400500002)(66066001)(87936001)(2950100001)(2900100001)(1096002)(5008740100001)(82746002)(86362001)(33656002)(1220700001)(5004730100002)(5001770100001)(586003)(4001350100001)(189998001)(3280700002)(3846002)(102836003)(5001960100002)(5890100001)(6116002)(19580405001)(3660700001)(36756003)(19580395003)(40100003)(50986999)(4326007)(561944003)(19625305001)(76176999)(54356999)(2906002)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <755749D95D5DC741B1AB402DDE3BEDB7@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 00:18:42.3027 (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 Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 00:19:02 -0000 SGkgRXJpYywNCg0KSWYgeW91IGhhdmUgYSBwcm9wb3NhbCwgcGxlYXNlIHNlbmQuICBBIGRyYWZ0 IHNlZW1zIG92ZXJraWxsIHRvIG1lLCBidXQgbWF5YmUgeW91IGhhdmUgc29tZXRoaW5nIGluIG1p bmQ/DQoNCknigJltIHBlcnNvbmFsbHkgb2theSB0byBuYW1lIHRoZSBzY2hlbWEtbW91bnQgdGhp bmcgdG8gc29tZXRoaW5nIHRoYXQgZG9lc27igJl0IHVzZSB0aGUgd29yZCDigJxtb3VudOKAnSwg c28gbG9uZyBhcyBpdOKAmXMgc3RpbGwgZWFzeSB0byB1bmRlcnN0YW5kLiAgV29yc3QgY2FzZSB3 ZSBjb3VsZCBhbGwgc3dpdGNoIHRvIHVzaW5nIGxvbmcgZm9ybSAoZS5nLiwgc2NoZW1hLW1vdW50 LXBvaW50LCBpbnN0YW5jZS1tb3VudC1wb2ludCksIHdoYXQgZG8geW91IHRoaW5rPw0KDQpLZW50 DQoNCg0KDQpPbiAyLzIzLzE2LCA2OjIxIFBNLCAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBj aXNjby5jb20+IHdyb3RlOg0KDQo+SGkgS2VudCwNCj4NCj5UaGFua3MgZm9yIHJ1bm5pbmcgdGhl IGludGVyaW0sIEkgYWdyZWUgaXQgd2FzIHF1aXRlIHVzZWZ1bC4gICAgDQo+DQo+T25lIHRoaW5n IEkgd2FudGVkIHRvIHB1bGwgb3V0IGZyb20gdGhlIG1pbnV0ZXMgd2FzIHRoZSBvdmVyYWxsIGRl ZmluaXRpb24gb2YgIk1vdW50Ii4gICAgIFJpZ2h0IG5vdyB0aGVyZSBhcmUgODMwIHdlYiBwYWdl cyBvbiB0aGUgT3BlbkRheWxpZ2h0IHNpdGUgd2hpY2ggcmVmZXIgdG8gIk1vdW50IiBpbiB0ZXJt cyBvZiBQZWVyIE1vdW50IChpLmUuLCBzb21ldGhpbmcgbXVjaCBsaWtlIGRyYWZ0LWNsZW1tLW5l dG1vZC1tb3VudCkuICAgDQo+DQo+VGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlIElFVEYgbmVl ZCBkZWZpbmUgIk1vdW50IiB0aGUgc2FtZSB3YXkgYXMgYW4gT3BlbiBTb3VyY2UgcHJvamVjdC4g IEJ1dCBpdCBpcyBwb3NzaWJsZSBhdCB0aGlzIHN0YWdlIHRvIGNyZWF0ZSBib3RoIHRlcm1pbm9s b2d5IGFuZCByZXF1aXJlbWVudHMgd2hpY2ggYnJlYWtzIGRvd24gdGhlIG92ZXJhbGwgcHJvYmxl bSBzcGFjZS4gICBJbiBvdGhlciB3b3JkcyB0aGVyZSBpcyBub3RoaW5nIHN0b3BwaW5nIHVzIGZy b20gZGVmaW5pbmcgYSBzZXQgb2YgdGVybXMgYW5kIHRlY2hub2xvZ3kgc29sdXRpb25zIHdoaWNo IGZpdCB0b2dldGhlciBpbiBhIGNvbXBsaW1lbnRhcnkgd2F5LiAgTm90aGluZyBoZXJlIG5lZWQg Y29uZmxpY3QuDQo+DQo+SWYgdGhlcmUgaXMgY29tbXVuaXR5IGludGVyZXN0LCBJIHdvdWxkIGJl IHdpbGxpbmcgdG8gcHVsbCB0b2dldGhlciBhIHN0cmF3bWFuIHJlcXVpcmVtZW50cy90ZXJtaW5v bG9neSBkcmFmdCBkZXNjcmliaW5nIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIG1vdW50aW5nIHNj aGVtYXMgb24gYSBib3gsIG1vdW50aW5nIGEgcmVtb3RlIGRhdGFzdG9yZS4NCj4NCj5BbnkgaW50 ZXJlc3Q/DQo+RXJpYyANCj4NCj4+IEZyb206IG5ldG1vZCwgRmVicnVhcnkgMjIsIDIwMTYgMzo1 MSBQTQ0KPj4gDQo+PiANCj4+IFRoYW5rIHlvdSBhbGwgd2hvIGpvaW5lZCB0b2RheeKAmXMgdmly dHVhbCBpbnRlcmltIG1lZXRpbmcuDQo+PiANCj4+IE90aGVyIHRoYW4gbXkgc3RhcnRpbmcgdGhl IHJlY29yZGluZyBsYXRlIGFuZCByZWFycmFuZ2luZyB0aGUgcHJlc2VudGF0aW9uIG9yZGVyLA0K Pj4gSSB0aG91Z2h0IHRoYXQgdGhlIG1lZXRpbmcgd2VudCByZWFsbHkgd2VsbCBpbiB0aGF0IHRo ZXJlIHNlZW1zIHRvIGJlIGEgbG90IG9mDQo+PiBzdXBwb3J0IGZvciB0cnlpbmcgdG8gc29sdmUg dGhpcyBwcm9ibGVtLCBhbmQgYmVjYXVzZSB3ZSBoYXZlIGEgcGxhbiB0byB0cnkgdG8NCj4+IG1v dmUgdG93YXJkcyBoYXZpbmcgYSBXRyBkb2N1bWVudCBpbiB0aGUgQkEgdGltZWZyYW1lLiAgVGhl IHBsYW4gaXMgZm9yDQo+PiBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwtbW91bnQg dG8gYmUgdXBkYXRlZCBiYXNlZCBvbiB0aGUgbWVldGluZw0KPj4gYW5kIGZvciBpdCB0byBiZSBk aXNjdXNzZWQgb24gbGlzdCBhcyB0aGUgYmFzaXMgZm9yIHRoZSBXRyBlZmZvcnQgb24gdGhlIHRv cGljLg0KPj4gDQo+PiBBdHRhY2hlZCBhcmUgdGhlIHZlcnkgcm91Z2ggRXRoZXJuZXQgbWludXRl cyBjYXB0dXJlZCBkdXJpbmcgdGhlIG1lZXRpbmcuDQo+PiBQbGVhc2UgcmV2aWV3IGNhcmVmdWxs eS4gIENvcnJlY3Rpb25zIGNhbiBiZSBtYWRlIG9uIHRoZSBldGhlcnBhZCBoZXJlOg0KPj4gaHR0 cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9uZXRtb2QtaW50ZXJpbS0yMDE2MDIy MiAgKHNvIHdlIGNhbg0KPj4gdHJhY2sgY2hhbmdlcywgdGhlIGVuZCBvZiBtZWV0aW5nIHNuYXBz aG90IGlzIGhlcmU6DQo+PiBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25l dG1vZC1pbnRlcmltLQ0KPj4gMjAxNjAyMjIvdGltZXNsaWRlciMzOTMzKQ0KPj4gDQo+PiBUbyBs aXN0ZW4gdG8gdGhlIHJlY29yZGluZywgcGxlYXNlIGZvbGxvdyBvbmUgb2YgdGhlc2UgdHdvIGxp bmtzOg0KPj4gDQo+PiAgIFN0cmVhbWluZyByZWNvcmRpbmcgbGluazoNCj4+IA0KPj4gaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD00ZGM4ODM4NmYxM2E0OWZhOGYyYzkz NGRiOTUzZjRhMg0KPj4gDQo+PiAgIERvd25sb2FkIHJlY29yZGluZyBsaW5rOg0KPj4gDQo+PiBo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbHNyLnBocD9SQ0lEPTFiNjQ5MGZlNWNjNmZjOTVk NGUzYzliOTEzZGZkYzFmDQo+PiANCj4+IA0KPj4gVGhhbmtzIGFnYWluLA0KPj4gDQo+PiBLZW50 IGFuZCBMb3UNCj4NCg== From nobody Tue Feb 23 17:27:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E241B38D7 for ; Tue, 23 Feb 2016 17:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.906 X-Spam-Level: X-Spam-Status: No, score=-13.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=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 mT1BQ6z4j0zO for ; Tue, 23 Feb 2016 17:27:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD4E1B2B1E for ; Tue, 23 Feb 2016 17:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5420; q=dns/txt; s=iport; t=1456277247; x=1457486847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g6oOMit0LuprP8eSh/QAiQhzKGzQit4YnKSIAJ/JRtE=; b=EFkjmnw/mQ2Y8NB5XHgBQwzVO1fX9eie9IRMF3NhnYfsXpBgj3okIr8G SWaZbezU+7lv8jw/I4PXauQ5MwCHDjiJfSYy2GVlpuAoxUFo3sP96IRgE gQjQ2hlCBviYL2LyZ2OO7hTVe8ew4P0iNmX3yu8uumpeuWXCCRUwNYKaE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AgB9Bs1W/5pdJa1EGoM6Um0GuFSBH?= =?us-ascii?q?XYBDYFmIYUNXwIcgSw4FAEBAQEBAQFkJ4RBAQEBAgEBIxFABQULAgEIDgcDAgI?= =?us-ascii?q?mAgICMBUQAgQBDQUIDAeHewgOLK4yjmsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe?= =?us-ascii?q?4UXhDqBNoV/gToFjSqJXQGFV4JuhRKBZEqDeYc4gRqOSAEeAQFCggMZgUhqAYc?= =?us-ascii?q?3fQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,492,1449532800"; d="scan'208";a="79954086" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 01:27:26 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1O1RQ1O002016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 01:27:26 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 19:27:25 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 19:27:25 -0600 From: "Eric Voit (evoit)" To: Kent Watsen , "Martin Bjorklund (mbjorklu)" , "Alexander Clemm (alex)" , "Ladislav Lhotka" , Lou Berger Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4AgAB9CgCAAgagwP//xcQAgABhi3A= Date: Wed, 24 Feb 2016 01:27:25 +0000 Message-ID: <60952b94817840efb86280c6c8a393e3@XCH-ALN-013.cisco.com> References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> <5FACD2B1-C487-44F1-A2D8-EED924048654@juniper.net> In-Reply-To: <5FACD2B1-C487-44F1-A2D8-EED924048654@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 01:27:29 -0000 PiBGcm9tOiBLZW50IFdhdHNlbiwgRmVicnVhcnkgMjMsIDIwMTYgNzoxOSBQTQ0KPiANCj4gSGkg RXJpYywNCj4gDQo+IElmIHlvdSBoYXZlIGEgcHJvcG9zYWwsIHBsZWFzZSBzZW5kLiAgQSBkcmFm dCBzZWVtcyBvdmVya2lsbCB0byBtZSwgYnV0IG1heWJlIHlvdQ0KPiBoYXZlIHNvbWV0aGluZyBp biBtaW5kPw0KDQpJIGhhdmUgb25seSB0aGUgYmVnaW5uaW5ncyBvZiBhIGRpdmlzaW9uIG9mIHRl cm1pbm9sb2d5IGFuZCBmdW5jdGlvbiBpbiBtaW5kLiAgSSB3b3VsZCBwdXQgdGltZSBpbnRvIHRo aXMgc2hvdWxkIHBlb3BsZSBjYXJlLiAgTW9yZSBiZWxvdy4NCg0KPiBJ4oCZbSBwZXJzb25hbGx5 IG9rYXkgdG8gbmFtZSB0aGUgc2NoZW1hLW1vdW50IHRoaW5nIHRvIHNvbWV0aGluZyB0aGF0IGRv ZXNu4oCZdA0KPiB1c2UgdGhlIHdvcmQg4oCcbW91bnTigJ0sIHNvIGxvbmcgYXMgaXTigJlzIHN0 aWxsIGVhc3kgdG8gdW5kZXJzdGFuZC4gIFdvcnN0IGNhc2Ugd2UNCj4gY291bGQgYWxsIHN3aXRj aCB0byB1c2luZyBsb25nIGZvcm0gKGUuZy4sIHNjaGVtYS1tb3VudC1wb2ludCwgaW5zdGFuY2Ut bW91bnQtDQo+IHBvaW50KSwgd2hhdCBkbyB5b3UgdGhpbms/DQoNCkF0IElFVEYgOTQsIHRoZXJl IHdhcyBhIHByb3Bvc2FsIGZvciBzb21ldGhpbmcgY2FsbGVkIEFsaWFzIE1vdW50Lg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC1uZXRtb2QtMTku cGRmDQooc2VlIHNsaWRlIDYpDQpBbGlhcyBtb3VudCBkaWRuJ3QgYWRkIGEgcmVmZXJlbmNlIHRv IGFuIGV4dGVybmFsIGJveCAobGlrZSBwZWVyIG1vdW50KS4gIEl0IGluY2x1ZGVkIGp1c3QgdGhl IHN1YnNldCBvZiBjb25maWd1cmF0aW9uIG5lZWRlZCB0byByZWZlcmVuY2UgYSBsb2NhbGx5IHRh cmdldGVkIHN1YnRyZWUuICAgVGhlcmUgd2VyZSBub3QgcHJvdmlzaW9ucyB0byBhdWdtZW50IHRo ZSBzY2hlbWEgd2l0aCBhZGRpdGlvbmFsIGluZm8uDQoNCkkgY2FuIHNlZSBhIHJlYXNvbiBmb3Ig c2NoZW1hIG1vdW50LCBhbGlhcyBtb3VudCwgYW5kIHBlZXIgbW91bnQuICBTbyB3aXRob3V0IHRo aW5raW5nIHRvbyBkZWVwbHksIEkgYmVsaWV2ZSBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gaGF2 ZSB0aGUgbmVlZGVkIHBhcmFtZXRlcnMgZm9yIFdHIHNlbGVjdGVkIG1vdW50IHZhcmlhdGlvbnMg d2hpY2ggY291bGQgYmUgcGxhY2VkIHVuZGVyIHRoZSBnZW5lcmFsaXplZCBtb3VudCBrZXl3b3Jk LiAgDQoNClRoaXMgd291bGQgc2VlbSB0byBiZSBhbiBhcHByb2FjaCB3aGljaCBpcyBleHRlbnNp YmxlLCBhbmQgd2hpY2ggYWxsb3dzIHRoZSB0ZWNobm9sb2d5IHNvbHV0aW9ucy9yZXF1aXJlbWVu dHMgdG8gYmUgZHJpdmVuIGluIHBhcmFsbGVsLg0KDQpFcmljDQoNCg0KPiBLZW50DQo+IA0KPiAN Cj4gDQo+IE9uIDIvMjMvMTYsIDY6MjEgUE0sICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNp c2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+SGkgS2VudCwNCj4gPg0KPiA+VGhhbmtzIGZvciBydW5u aW5nIHRoZSBpbnRlcmltLCBJIGFncmVlIGl0IHdhcyBxdWl0ZSB1c2VmdWwuDQo+ID4NCj4gPk9u ZSB0aGluZyBJIHdhbnRlZCB0byBwdWxsIG91dCBmcm9tIHRoZSBtaW51dGVzIHdhcyB0aGUgb3Zl cmFsbCBkZWZpbml0aW9uIG9mDQo+ICJNb3VudCIuICAgICBSaWdodCBub3cgdGhlcmUgYXJlIDgz MCB3ZWIgcGFnZXMgb24gdGhlIE9wZW5EYXlsaWdodCBzaXRlIHdoaWNoDQo+IHJlZmVyIHRvICJN b3VudCIgaW4gdGVybXMgb2YgUGVlciBNb3VudCAoaS5lLiwgc29tZXRoaW5nIG11Y2ggbGlrZSBk cmFmdC1jbGVtbS0NCj4gbmV0bW9kLW1vdW50KS4NCj4gPg0KPiA+VGhhdCBkb2VzIG5vdCBtZWFu IHRoYXQgdGhlIElFVEYgbmVlZCBkZWZpbmUgIk1vdW50IiB0aGUgc2FtZSB3YXkgYXMgYW4NCj4g T3BlbiBTb3VyY2UgcHJvamVjdC4gIEJ1dCBpdCBpcyBwb3NzaWJsZSBhdCB0aGlzIHN0YWdlIHRv IGNyZWF0ZSBib3RoIHRlcm1pbm9sb2d5DQo+IGFuZCByZXF1aXJlbWVudHMgd2hpY2ggYnJlYWtz IGRvd24gdGhlIG92ZXJhbGwgcHJvYmxlbSBzcGFjZS4gICBJbiBvdGhlcg0KPiB3b3JkcyB0aGVy ZSBpcyBub3RoaW5nIHN0b3BwaW5nIHVzIGZyb20gZGVmaW5pbmcgYSBzZXQgb2YgdGVybXMgYW5k IHRlY2hub2xvZ3kNCj4gc29sdXRpb25zIHdoaWNoIGZpdCB0b2dldGhlciBpbiBhIGNvbXBsaW1l bnRhcnkgd2F5LiAgTm90aGluZyBoZXJlIG5lZWQNCj4gY29uZmxpY3QuDQo+ID4NCj4gPklmIHRo ZXJlIGlzIGNvbW11bml0eSBpbnRlcmVzdCwgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHB1bGwgdG9n ZXRoZXIgYSBzdHJhd21hbg0KPiByZXF1aXJlbWVudHMvdGVybWlub2xvZ3kgZHJhZnQgZGVzY3Jp YmluZyB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiBtb3VudGluZw0KPiBzY2hlbWFzIG9uIGEgYm94 LCBtb3VudGluZyBhIHJlbW90ZSBkYXRhc3RvcmUuDQo+ID4NCj4gPkFueSBpbnRlcmVzdD8NCj4g PkVyaWMNCj4gPg0KPiA+PiBGcm9tOiBuZXRtb2QsIEZlYnJ1YXJ5IDIyLCAyMDE2IDM6NTEgUE0N Cj4gPj4NCj4gPj4NCj4gPj4gVGhhbmsgeW91IGFsbCB3aG8gam9pbmVkIHRvZGF54oCZcyB2aXJ0 dWFsIGludGVyaW0gbWVldGluZy4NCj4gPj4NCj4gPj4gT3RoZXIgdGhhbiBteSBzdGFydGluZyB0 aGUgcmVjb3JkaW5nIGxhdGUgYW5kIHJlYXJyYW5naW5nIHRoZQ0KPiA+PiBwcmVzZW50YXRpb24g b3JkZXIsIEkgdGhvdWdodCB0aGF0IHRoZSBtZWV0aW5nIHdlbnQgcmVhbGx5IHdlbGwgaW4NCj4g Pj4gdGhhdCB0aGVyZSBzZWVtcyB0byBiZSBhIGxvdCBvZiBzdXBwb3J0IGZvciB0cnlpbmcgdG8g c29sdmUgdGhpcw0KPiA+PiBwcm9ibGVtLCBhbmQgYmVjYXVzZSB3ZSBoYXZlIGEgcGxhbiB0byB0 cnkgdG8gbW92ZSB0b3dhcmRzIGhhdmluZyBhDQo+ID4+IFdHIGRvY3VtZW50IGluIHRoZSBCQSB0 aW1lZnJhbWUuICBUaGUgcGxhbiBpcyBmb3INCj4gPj4gZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1z dHJ1Y3R1cmFsLW1vdW50IHRvIGJlIHVwZGF0ZWQgYmFzZWQgb24gdGhlDQo+IG1lZXRpbmcgYW5k IGZvciBpdCB0byBiZSBkaXNjdXNzZWQgb24gbGlzdCBhcyB0aGUgYmFzaXMgZm9yIHRoZSBXRyBl ZmZvcnQgb24gdGhlDQo+IHRvcGljLg0KPiA+Pg0KPiA+PiBBdHRhY2hlZCBhcmUgdGhlIHZlcnkg cm91Z2ggRXRoZXJuZXQgbWludXRlcyBjYXB0dXJlZCBkdXJpbmcgdGhlIG1lZXRpbmcuDQo+ID4+ IFBsZWFzZSByZXZpZXcgY2FyZWZ1bGx5LiAgQ29ycmVjdGlvbnMgY2FuIGJlIG1hZGUgb24gdGhl IGV0aGVycGFkIGhlcmU6DQo+ID4+IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAw L3AvbmV0bW9kLWludGVyaW0tMjAxNjAyMjIgIChzbyB3ZQ0KPiA+PiBjYW4gdHJhY2sgY2hhbmdl cywgdGhlIGVuZCBvZiBtZWV0aW5nIHNuYXBzaG90IGlzIGhlcmU6DQo+ID4+IGh0dHA6Ly9ldGhl cnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbmV0bW9kLWludGVyaW0tDQo+ID4+IDIwMTYwMjIy L3RpbWVzbGlkZXIjMzkzMykNCj4gPj4NCj4gPj4gVG8gbGlzdGVuIHRvIHRoZSByZWNvcmRpbmcs IHBsZWFzZSBmb2xsb3cgb25lIG9mIHRoZXNlIHR3byBsaW5rczoNCj4gPj4NCj4gPj4gICBTdHJl YW1pbmcgcmVjb3JkaW5nIGxpbms6DQo+ID4+DQo+ID4+IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9sZHIucGhwP1JDSUQ9NGRjODgzODZmMTNhNDlmYThmMmM5MzRkYjk1Mw0KPiA+PiBmNGEy DQo+ID4+DQo+ID4+ICAgRG93bmxvYWQgcmVjb3JkaW5nIGxpbms6DQo+ID4+DQo+ID4+IGh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9MWI2NDkwZmU1Y2M2ZmM5NWQ0ZTNj OWI5MTNkZg0KPiA+PiBkYzFmDQo+ID4+DQo+ID4+DQo+ID4+IFRoYW5rcyBhZ2FpbiwNCj4gPj4N Cj4gPj4gS2VudCBhbmQgTG91DQo+ID4NCg== From nobody Wed Feb 24 00:53:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B151B4868 for ; Wed, 24 Feb 2016 00:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.656 X-Spam-Level: X-Spam-Status: No, score=-5.656 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, RP_MATCHES_RCVD=-0.006, WEIRD_PORT=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 2IgibqBASvmg for ; Wed, 24 Feb 2016 00:53:31 -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 0A1C31B4866 for ; Wed, 24 Feb 2016 00:53:31 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id 92DFC181A71; Wed, 24 Feb 2016 09:53:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456304009; bh=7jht/tN4FZ8bclO5Qmzpy5TB3UmfCskJfXGzuW3ZcAE=; h=From:Date:To; b=OnBs8M9MgBN9AWQM++VMVSPcUvUE39SOCgGVn7ic7yrISpmlMPA7KQ8XTMXfwdmCW abQjKU8wUtITSWhNplr2jdPFGfxPQbCAKLm3OeW3WREFcHdeGvERaI17gONX56QGSt hKbzxwU4dX/3LLlNNvl+H795y/bJQNv8ZQI23ObE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> Date: Wed, 24 Feb 2016 09:53:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 08:53:33 -0000 Hi Eric, I agree with you that it is important to distinuguish the construction = of a data model schema from mechanisms for combining data trees, and I = believe the term "mount" is mostly connected to the latter (as in NFS = mount). FWIW, the YSDL draft doesn't use the term "mount" at all. I'd suggest to wait for the concrete technical solution of = structural-mount/YSDL, then it may be easier to figure out an = appropriate term. Lada > On 24 Feb 2016, at 00:21, Eric Voit (evoit) wrote: >=20 > Hi Kent, >=20 > Thanks for running the interim, I agree it was quite useful. =20 >=20 > One thing I wanted to pull out from the minutes was the overall = definition of "Mount". Right now there are 830 web pages on the = OpenDaylight site which refer to "Mount" in terms of Peer Mount (i.e., = something much like draft-clemm-netmod-mount). =20 >=20 > That does not mean that the IETF need define "Mount" the same way as = an Open Source project. But it is possible at this stage to create both = terminology and requirements which breaks down the overall problem = space. In other words there is nothing stopping us from defining a set = of terms and technology solutions which fit together in a complimentary = way. Nothing here need conflict. >=20 > If there is community interest, I would be willing to pull together a = strawman requirements/terminology draft describing the differences = between mounting schemas on a box, mounting a remote datastore. >=20 > Any interest? > Eric=20 >=20 >> From: netmod, February 22, 2016 3:51 PM >>=20 >>=20 >> Thank you all who joined today=E2=80=99s virtual interim meeting. >>=20 >> Other than my starting the recording late and rearranging the = presentation order, >> I thought that the meeting went really well in that there seems to be = a lot of >> support for trying to solve this problem, and because we have a plan = to try to >> move towards having a WG document in the BA timeframe. The plan is = for >> draft-bjorklund-netmod-structural-mount to be updated based on the = meeting >> and for it to be discussed on list as the basis for the WG effort on = the topic. >>=20 >> Attached are the very rough Ethernet minutes captured during the = meeting. >> Please review carefully. Corrections can be made on the etherpad = here: >> http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 (so we = can >> track changes, the end of meeting snapshot is here: >> http://etherpad.tools.ietf.org:9000/p/netmod-interim- >> 20160222/timeslider#3933) >>=20 >> To listen to the recording, please follow one of these two links: >>=20 >> Streaming recording link: >>=20 >> = https://ietf.webex.com/ietf/ldr.php?RCID=3D4dc88386f13a49fa8f2c934db953f4a= 2 >>=20 >> Download recording link: >>=20 >> = https://ietf.webex.com/ietf/lsr.php?RCID=3D1b6490fe5cc6fc95d4e3c9b913dfdc1= f >>=20 >>=20 >> Thanks again, >>=20 >> Kent and Lou >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 24 01:04:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265531B48B0 for ; Wed, 24 Feb 2016 01:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 9E5It4VyLHQA for ; Wed, 24 Feb 2016 01:04:43 -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 A63481B48AB for ; Wed, 24 Feb 2016 01:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1456304682; x=1457514282; h=from:subject:to:message-id:date:mime-version; bh=0vhqX4IOm+aO57GP8pyDq+RL80xc2Im6u8dLnD8rKEY=; b=eAWCZKa6Ga7tE6aynBzYOporUu4uGahE6Hrat2lpEskmZ2j5K05FiDVB A1lJYvYewhqG+H1/QZiHUwvql6KhWGTYjGo2mkjvw+YXYEd/yKn1jIo2x eokUUhyoyQSjZCkXhQNq4nJ1zeusO5zBSM9FeeyMejzYKHCt/t7Kf2D+6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDTcM1W/xbLJq1ehAxtuFqCEwENg?= =?us-ascii?q?WYhh18UAQEBAQEBAWQnhGtVIB0WBAcCCwMCAQIBSw0IAQGIGg6fII9bjmoBAQE?= =?us-ascii?q?HAQEBARgEhhKLb4E6BZcHhViIB4FehESDAoVQjkkeAQFCggMZFIE1Oy4Bh18BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.22,493,1449532800"; d="scan'208,217";a="632862522" 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; 24 Feb 2016 09:04:34 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1O94YBe027306 for ; Wed, 24 Feb 2016 09:04:34 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: <56CD7222.4020603@cisco.com> Date: Wed, 24 Feb 2016 10:04:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080306040607090205030502" Archived-At: Subject: [netmod] Terminology => YANG module versus YANG data model versus YANG model : please don't use "YANG model" any longer 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, 24 Feb 2016 09:04:45 -0000 This is a multi-part message in MIME format. --------------080306040607090205030502 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Reviewing some NETMOD documents these days, I realized that we're sometimes not consistent regarding terminology: YANG module, YANG data model, YANG model. Example: All three can be found in https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt and https://tools.ietf.org/html/rfc6244 YANG data model and YANG module can be found in https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-03 and https://www.ietf.org/id/draft-ietf-netmod-yang-json-07.txt Asking advice from the YANG doctors, here are their conclusions: RFC 6020 defines: o data model: A data model describes how data is represented and accessed. o module: A YANG module defines a hierarchy of nodes that can be used for NETCONF-based operations. With its definitions and the definitions it imports or includes from elsewhere, a module is self-contained and "compilable". Both terms 'YANG data model' and 'YANG module' mean slightly different things and both are valid. (I think a larger YANG data model can consist of multiple YANG modules and YANG submodules, RFC 7407 would be an example.) The term 'YANG models' is likely simply an abbreviation of 'YANG data models' and we could get rid of this by not using an abbreviation. Let's apply this rule from now: no more "YANG models". Regards, Benoit --------------080306040607090205030502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Reviewing some NETMOD documents these days, I realized that we're sometimes not consistent regarding terminology: YANG module, YANG data model, YANG model.

Example:
All three can be found in https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt and https://tools.ietf.org/html/rfc6244
YANG data model and YANG module can be found in https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-03 and https://www.ietf.org/id/draft-ietf-netmod-yang-json-07.txt

Asking advice from the YANG doctors, here are their conclusions:
RFC 6020 defines:

   o  data model: A data model describes how data is represented and
      accessed.

   o  module: A YANG module defines a hierarchy of nodes that can be
      used for NETCONF-based operations.  With its definitions and the
      definitions it imports or includes from elsewhere, a module is
      self-contained and "compilable".

Both terms 'YANG data model' and 'YANG module' mean slightly
different things and both are valid. (I think a larger YANG data model
can consist of multiple YANG modules and YANG submodules, RFC 7407
would be an example.)

The term 'YANG models' is likely simply an abbreviation of 'YANG data
models' and we could get rid of this by not using an abbreviation.
Let's apply this rule from now: no more "YANG models".

Regards, Benoit
--------------080306040607090205030502-- From nobody Wed Feb 24 01:34:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1FD1B48F1 for ; Wed, 24 Feb 2016 01:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.906 X-Spam-Level: X-Spam-Status: No, score=-13.906 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, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 pMHtQPzauOLo for ; Wed, 24 Feb 2016 01:34:39 -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 2FC461B48F4 for ; Wed, 24 Feb 2016 01:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5236; q=dns/txt; s=iport; t=1456306479; x=1457516079; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=IXDy6hD5wZwAtOU+Sw/OSfJeI59XyrwUfIkFfMlkhhw=; b=GAbRrwJmtaYrNY/IaSQpyalGdcGyb/klUUBVb+jmAgIVxSAoMSCmGDuR y21SeP847odRVcfWXpnEy7CWB1eZHCIIuxMG0SWtCeOlcgKfm3ah4QzFB E2ndBjrRYJxkcb73F3dYhlW6anQhXYDaQS+BUzKWXoEcej0qARmleroL8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbBADed81W/xbLJq1egm6BHm0BukErA?= =?us-ascii?q?Q2BZiOFagKBcRQBAQEBAQEBZCdBEgGDbgEBBCNVEQ8dFgsCAgkDAgECAUUGDQg?= =?us-ascii?q?BAYgaDq5+jmwBAQEBAQEBAwEBAQEBAQEZhhKJHIJTgToFlweFWIgHgimGe4VQj?= =?us-ascii?q?kkPDwEBQoNlOy+FNoIpAQEB?= X-IronPort-AV: E=Sophos;i="5.22,493,1449532800"; d="scan'208,217";a="632863135" 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; 24 Feb 2016 09:34:37 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1O9YabI002822 for ; Wed, 24 Feb 2016 09:34:36 GMT References: <56CD6BBF.5010206@cisco.com> From: Benoit Claise To: NETMOD Working Group X-Forwarded-Message-Id: <56CD6BBF.5010206@cisco.com> Message-ID: <56CD792C.2080103@cisco.com> Date: Wed, 24 Feb 2016 10:34:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CD6BBF.5010206@cisco.com> Content-Type: multipart/alternative; boundary="------------030808070701000001080800" Archived-At: Subject: [netmod] AD review draft-ietf-netmod-yang-metadata-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: Wed, 24 Feb 2016 09:34:41 -0000 This is a multi-part message in MIME format. --------------030808070701000001080800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my AD review of draft-ietf-netmod-yang-metadata-03. Only editorial comments, except potentially the last point. - "data type", to which you refer in the terminology section, is not defined in [I-D.ietf-netmod-rfc6020bis ] terminology section. - "An annotation MUST NOT change the data tree semantics defined by YANG." We should be consistent between YANG modules versus YANG models versus YANG data models versus YANG. See my previous message on the list. Here I believe we need: "An annotation MUST NOT change the data tree semantics defined by the YANG module". - OLD: Copyright (c) 2015 IETF NEW: Copyright (c) 2016 IETF - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described inRFC 2119 (http://tools.ietf.org/html/rfc2119). This language in the YANG module is certainly a left over the draft version 1. I don't see any RFC2119 in the module itself. - "The 'md:annotation' statement can appear only at the top level of a YANG module." I don't understand what the top is? You mean, after the import statements. Should pyang check this? If yes, how? From the example, The following module defines the "last-modified" annotation: module example-last-modified { namespace"http://example.org/example-last-modified"; prefix "elm"; import ietf-yang-types { prefix "yang"; } import ietf-yang-metadata { prefix "md"; } md:annotation last-modified { type yang:date-and-time; description "This annotation contains date and time when the annotated instance was last modified (or created)."; } } Regards, Benoit --------------030808070701000001080800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Here is my AD review of draft-ietf-netmod-yang-metadata-03. Only editorial comments, except potentially the last point.
- 
"data type", to which you refer in the terminology section, is not defined in 
[I-D.ietf-netmod-rfc6020bis] terminology section. 

- 
   "An annotation MUST NOT change the data tree semantics defined by
   YANG."

We should be consistent between YANG modules versus YANG models versus YANG data models versus YANG.
See my previous message on the list.
Here I believe we need:
   "An annotation MUST NOT change the data tree semantics defined by
   the YANG module".

- 
OLD: 
Copyright (c) 2015 IETF
NEW:
Copyright (c) 2016 IETF

-
       The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
        'OPTIONAL' in the module text are to be interpreted as described
        in RFC 2119 (http://tools.ietf.org/html/rfc2119).

This language in the YANG module is certainly a left over the draft version 1. I don't see any RFC2119 in the module itself.

     
-
"The 'md:annotation' statement can appear only at the top level of a YANG module."

I don't understand what the top is? You mean, after the import statements.
Should pyang check this? If yes, how?
>From the example,

   The following module defines the "last-modified" annotation:

   module example-last-modified {
     namespace "http://example.org/example-last-modified";
     prefix "elm";
     import ietf-yang-types {
       prefix "yang";
     }
     import ietf-yang-metadata {
       prefix "md";
     }
     md:annotation last-modified {
       type yang:date-and-time;
       description
         "This annotation contains date and time when the
          annotated instance was last modified (or created).";
     }
   }
Regards, Benoit

--------------030808070701000001080800-- From nobody Wed Feb 24 02:16:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE141A03AB for ; Wed, 24 Feb 2016 02:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 55kpyXNww7bc for ; Wed, 24 Feb 2016 02:16:18 -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 084111A008A for ; Wed, 24 Feb 2016 02:16:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CCE2B1451; Wed, 24 Feb 2016 11:16:16 +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 G-Yo14ZWuhfx; Wed, 24 Feb 2016 11:16: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; Wed, 24 Feb 2016 11:16:16 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C9D720033; Wed, 24 Feb 2016 11:16:16 +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 e6VUeXoHa_Vm; Wed, 24 Feb 2016 11:16:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 451112002B; Wed, 24 Feb 2016 11:16:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3992639FC5C9; Wed, 24 Feb 2016 11:16:15 +0100 (CET) Date: Wed, 24 Feb 2016 11:16:15 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20160224101615.GB17109@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group References: <56CD6BBF.5010206@cisco.com> <56CD792C.2080103@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56CD792C.2080103@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] AD review draft-ietf-netmod-yang-metadata-03 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, 24 Feb 2016 10:16:19 -0000 On Wed, Feb 24, 2016 at 10:34:36AM +0100, Benoit Claise wrote: [...] > "The 'md:annotation' statement can appear only at the top level of a YANG > module." > > I don't understand what the top is? You mean, after the import statements. > Should pyang check this? If yes, how? I think the intention was to say at the 'top-level of the schema tree'. It does not have to be right after the imports. /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 Feb 24 02:27:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD21A1AD3 for ; Wed, 24 Feb 2016 02:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 CzeuwL-YoXJs for ; Wed, 24 Feb 2016 02:27:36 -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 12AB01A1AB9 for ; Wed, 24 Feb 2016 02:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=537; q=dns/txt; s=iport; t=1456309656; x=1457519256; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6QSA/3rv+3T8O11n/PLP6vmwLjSOmmR1XW3eczSWYDc=; b=TlAm4BI3wkX7Iy6QuEjtTwfMe/Y5XIcc7onsGd22RVZC3y8E2PXCsH0n kchHmGqfMi7EdVBrlPBRVKuOP+3+z1JAxkeVJXNcPk4l+OgEooU1gFKan 1ugFtIPUPhaTMNMhEifq4/RSAo/RlTi0tNOW6o4nckr8Xie3KdcneFUDK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACWhM1W/xbLJq1ewVqGDQKCCAEBA?= =?us-ascii?q?QEBAWUnhEIBAQQ4QBELGAkWDwkDAgECAUUGDQgBAYgavXwBAQEBAQEBAwEBAQE?= =?us-ascii?q?BG4YShDqIbwEElweNX4FJh1uFUI5JYoNlO4gOAQEB?= X-IronPort-AV: E=Sophos;i="5.22,493,1449532800"; d="scan'208";a="625665395" 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; 24 Feb 2016 10:27:33 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1OARXiq030526 for ; Wed, 24 Feb 2016 10:27:33 GMT To: NETMOD Working Group References: <56CD6BBF.5010206@cisco.com> <56CD792C.2080103@cisco.com> <20160224101615.GB17109@elstar.local> From: Benoit Claise Message-ID: <56CD8595.4010204@cisco.com> Date: Wed, 24 Feb 2016 11:27:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160224101615.GB17109@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] AD review draft-ietf-netmod-yang-metadata-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: Wed, 24 Feb 2016 10:27:37 -0000 On 2/24/2016 11:16 AM, Juergen Schoenwaelder wrote: > On Wed, Feb 24, 2016 at 10:34:36AM +0100, Benoit Claise wrote: > > [...] > >> "The 'md:annotation' statement can appear only at the top level of a YANG >> module." >> >> I don't understand what the top is? You mean, after the import statements. >> Should pyang check this? If yes, how? > I think the intention was to say at the 'top-level of the schema tree'. > It does not have to be right after the imports. That would clarify. Thanks. Regards, Benoit > > /js > From nobody Wed Feb 24 02:34:05 2016 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 BF1D11A1B65; Wed, 24 Feb 2016 02:34:02 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160224103402.8342.96024.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 02:34:02 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-08.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, 24 Feb 2016 10:34:02 -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 of the IETF. Title : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-08.txt Pages : 20 Date : 2016-02-24 Abstract: This document defines encoding rules for representing configuration, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-08 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 Feb 24 03:30:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC661A89C5 for ; Wed, 24 Feb 2016 03:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 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, J_CHICKENPOX_210=0.6, RP_MATCHES_RCVD=-0.006] 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 dlS6iADEyK1q for ; Wed, 24 Feb 2016 03:30:39 -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 7D1561A89B9 for ; Wed, 24 Feb 2016 03:30:39 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id CC7C818030C; Wed, 24 Feb 2016 12:30:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456313437; bh=HeOTI29wHd3rA4Csv7vBoIxw+spDbc8RznV/W9qUxqM=; h=From:Date:To; b=PLkboKxgpznM5mSzhHoKTs+K8QmADKEhZDisoWdm1YfzUdh2r7o+NBDTCWCEX4DhY mZCZLyIWxWGho2fMnYuE4NZ8p40qMmNHa7/SuViz/wcy66IfBAyVrF1KTD4r6y+1Id ySjZx6YgdU8k8zYpU4nO4JTKBLyy2et9nImjhvh4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56CD792C.2080103@cisco.com> Date: Wed, 24 Feb 2016 12:30:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56CD6BBF.5010206@cisco.com> <56CD792C.2080103@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 Working Group Subject: Re: [netmod] AD review draft-ietf-netmod-yang-metadata-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: Wed, 24 Feb 2016 11:30:42 -0000 Hi Benoit, thanks for the review, please see my replies inline. > On 24 Feb 2016, at 10:34, Benoit Claise wrote: >=20 > Dear all, >=20 > Here is my AD review of draft-ietf-netmod-yang-metadata-03. Only = editorial comments, except potentially the last point. > -=20 > "data type", to which you refer in the terminology section, is not = defined in=20 > [ > I-D.ietf-netmod-rfc6020bis > ] terminology section. The term "data type" certainly is defined in 6020bis, albeit not in the = terminology section. > =20 >=20 > -=20 > "An annotation MUST NOT change the data tree semantics defined by > YANG." >=20 > We should be consistent between YANG modules versus YANG models versus = YANG data models versus YANG. > See my previous message on the list. > Here I believe we need: > "An annotation MUST NOT change the data tree semantics defined by > the YANG module". Actually, I think "YANG" is correct here, meaning "YANG the data = modelling language". For example, an annotation cannot mean "this = configuration list has no keys" because YANG specification doesn't allow = it. This rule is written in 6020(bis), not in any YANG module. >=20 > -=20 > OLD:=20 > Copyright (c) 2015 IETF > NEW: > Copyright (c) 2016 IETF OK, will fix, and also add Lou as the third WG chair. >=20 > - > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and > 'OPTIONAL' in the module text are to be interpreted as = described > in=20 > RFC 2119 (http://tools.ietf.org/html/rfc2119 > ). >=20 > This language in the YANG module is certainly a left over the draft = version 1. I don't see any RFC2119 in the module itself. >=20 Right, I will remove this text from the module.=20 >=20 > =20 >=20 > - > "The 'md:annotation' statement can appear only at the top level of a = YANG module." >=20 > I don't understand what the top is? You mean, after the import = statements. What is means is "not inside definition of schema nodes." I will add = such a clarification. > Should pyang check this? If yes, how? Yes, pyang could check it when parsing a module. The "dsdl" translator = ignores this annotation unless it is at the top level. Thanks, Lada > >=46rom the example, >=20 > The following module defines the "last-modified" annotation: >=20 > module example-last-modified { > namespace=20 > "http://example.org/example-last-modified" > ; > prefix "elm"; > import ietf-yang-types { > prefix "yang"; > } > import ietf-yang-metadata { > prefix "md"; > } > md:annotation last-modified { > type yang:date-and-time; > description > "This annotation contains date and time when the > annotated instance was last modified (or created)."; > } > } >=20 > Regards, Benoit >=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 Feb 24 03:34:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C830F1A8A25 for ; Wed, 24 Feb 2016 03:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 sls0TlO8XBVr for ; Wed, 24 Feb 2016 03:34: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 2DCB81A8A1F for ; Wed, 24 Feb 2016 03:34:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id C2FE41818E9; Wed, 24 Feb 2016 12:34:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456313650; bh=I5a5Wd+6UTpvkGL0kjgSkJxbiCKpWeBIeHGrDU4pwdM=; h=From:Date:To; b=xGBodyxKA0na1rndhrCeiY/YykXrt4stJgaWGg7Zkk4ulRxvH/1fMgqKB+98R9ryn YQACQiyk0fgz5b1aW6uDDb7/t69v53nh09vvjAp+6fw9Q6MKsF33bCjCvTL3sJUbao 6pqNyqYxEHusiP65+waJy/PiJ1yFBVqbMMvH0mdM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160224101615.GB17109@elstar.local> Date: Wed, 24 Feb 2016 12:34:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BE29042-A36C-4663-9607-E24FB0B1DAE9@nic.cz> References: <56CD6BBF.5010206@cisco.com> <56CD792C.2080103@cisco.com> <20160224101615.GB17109@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] AD review draft-ietf-netmod-yang-metadata-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: Wed, 24 Feb 2016 11:34:14 -0000 > On 24 Feb 2016, at 11:16, Juergen Schoenwaelder = wrote: >=20 > On Wed, Feb 24, 2016 at 10:34:36AM +0100, Benoit Claise wrote: >=20 > [...] >=20 >> "The 'md:annotation' statement can appear only at the top level of a = YANG=20 >> module." >>=20 >> I don't understand what the top is? You mean, after the import = statements. >> Should pyang check this? If yes, how? >=20 > I think the intention was to say at the 'top-level of the schema = tree'. > It does not have to be right after the imports. To my understanding, these declarations aren't part of the schema tree. 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 Wed Feb 24 03:44:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706141A901E for ; Wed, 24 Feb 2016 03:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 fFACvSLjhoeH for ; Wed, 24 Feb 2016 03:44:54 -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 CDE3B1A6FE0 for ; Wed, 24 Feb 2016 03:44:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C6FD1CC7; Wed, 24 Feb 2016 12:44:52 +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 OVeLeFa3n0lL; Wed, 24 Feb 2016 12:44:40 +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, 24 Feb 2016 12:44:52 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E99502003A; Wed, 24 Feb 2016 12:44:51 +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 jw8x_oRBN3F3; Wed, 24 Feb 2016 12:44:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63F722003D; Wed, 24 Feb 2016 12:44:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5857D39FC7C2; Wed, 24 Feb 2016 12:44:47 +0100 (CET) Date: Wed, 24 Feb 2016 12:44:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160224114447.GA17397@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG , Benoit Claise References: <56CD6BBF.5010206@cisco.com> <56CD792C.2080103@cisco.com> <20160224101615.GB17109@elstar.local> <7BE29042-A36C-4663-9607-E24FB0B1DAE9@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BE29042-A36C-4663-9607-E24FB0B1DAE9@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD WG Subject: Re: [netmod] AD review draft-ietf-netmod-yang-metadata-03 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, 24 Feb 2016 11:44:55 -0000 On Wed, Feb 24, 2016 at 12:34:19PM +0100, Ladislav Lhotka wrote: > > > On 24 Feb 2016, at 11:16, Juergen Schoenwaelder wrote: > > > > On Wed, Feb 24, 2016 at 10:34:36AM +0100, Benoit Claise wrote: > > > > [...] > > > >> "The 'md:annotation' statement can appear only at the top level of a YANG > >> module." > >> > >> I don't understand what the top is? You mean, after the import statements. > >> Should pyang check this? If yes, how? > > > > I think the intention was to say at the 'top-level of the schema tree'. > > It does not have to be right after the imports. > > To my understanding, these declarations aren't part of the schema tree. > OK. Perhaps it is most precise to refer to the ABNF productions where the annotation can appear, e.g., it is 'inside the body-stmts'. /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 Feb 24 04:31:37 2016 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 157721ACD87; Wed, 24 Feb 2016 04:31:35 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160224123135.32475.36130.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 04:31:35 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-04.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, 24 Feb 2016 12:31:35 -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 of the IETF. Title : Defining and Using Metadata with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-metadata-04.txt Pages : 20 Date : 2016-02-24 Abstract: This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 24 04:48:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F361B1AD084 for ; Wed, 24 Feb 2016 04:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 JiyeQTa_E6LD for ; Wed, 24 Feb 2016 04:48:24 -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 A339B1AD074 for ; Wed, 24 Feb 2016 04:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=117; q=dns/txt; s=iport; t=1456318103; x=1457527703; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=pF4ib5c59H3iVF22WcmquBND9uyW774Iaj1VZHF3gYs=; b=Ikvpqiv6AIkGuKydF9ANx3w/7vqPzRuUpUESLzYVBcGifX63C71oDwTk Ax+z+9ftROOGqWkhk9tf08qvT+TBvXxx2SdgexP6Z7OvTvFlkV4T9l06u YeAfvWTomEIsechV4+0WcWenB7iPq0U8Cjqd4oaE1QXHAwFanQGDMSyuL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAQAUps1W/xbLJq1evViCEwENgWaIA?= =?us-ascii?q?xQBAQEBAQEBZCeEaxVANgIFFgsCCwMCAQIBSw0IAQGIG586j1uOaAEBAQcCAR1?= =?us-ascii?q?7hReLb4E6AQSXB4EbjESBSYdbhVCOSR4BAUKCMIE1O4gOAQEB?= X-IronPort-AV: E=Sophos;i="5.22,493,1449532800"; d="scan'208";a="649532815" 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; 24 Feb 2016 12:48:19 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1OCmJfV025335 for ; Wed, 24 Feb 2016 12:48:19 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <56CDA693.3080404@cisco.com> Date: Wed, 24 Feb 2016 13:48:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Both draft-ietf-netmod-yang-metadata and draft-ietf-netmod-yang-json are now moved IETF LC ... 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, 24 Feb 2016 12:48:25 -0000 Dear all, ... thanks to the new draft versions posted today. I thought I would let you know. Regards, Benoit From nobody Wed Feb 24 05:31:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8991B2B5F for ; Wed, 24 Feb 2016 05:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 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, RP_MATCHES_RCVD=-0.006] 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 CYnPEGH8lTBl for ; Wed, 24 Feb 2016 05:31:24 -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 3B7D81B2B56 for ; Wed, 24 Feb 2016 05:31:24 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id 1FEFE180312 for ; Wed, 24 Feb 2016 14:31:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456320682; bh=BmA978o93UELGRBbizC8uuHDfP7DCO5g8JCSeMjweXM=; h=From:Date:To; b=QE/mXzJOGzJ3TwOzxLyKBY6CicND0p43jHG+7BKNtXfcfVN7khdcJMByjFONPIEwm DZ5vpiSNEC2ulBO/u0m5LGGUVKfkPA9+ev9FBNaQtsNQQP6DornVgiZx3r7sd5/7rq JEIxFMKfAVrtxZ2Fh0KgvGj/6KmrilIxEMqGJbss= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> Date: Wed, 24 Feb 2016 14:31:30 +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] 'predicate' production 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, 24 Feb 2016 13:31:26 -0000 Hi, another ABNF issue: predicate =3D "[" *WSP (predicate-expr / pos) *WSP "]" predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos =3D non-negative-integer-value non-negative-integer-value =3D "0" / positive-integer-value The value of 0 shouldn't be allowed for 'pos' because context position = in XPath is always positive, i.e. the first list entry is selected with = "[1]". Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 24 06:07:51 2016 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 505291A0113; Wed, 24 Feb 2016 06:07:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160224140746.29017.27133.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 06:07:46 -0800 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-json@ietf.org, netmod@ietf.org Subject: [netmod] Last Call: (JSON Encoding of Data Modeled with YANG) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:07:46 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'JSON Encoding of Data Modeled with YANG' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines encoding rules for representing configuration, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 06:14:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6371B2BC0 for ; Wed, 24 Feb 2016 06:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, 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 ttv_QrJ5P5jT for ; Wed, 24 Feb 2016 06:13:59 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 CDB871B2A82 for ; Wed, 24 Feb 2016 06:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1456323229; bh=b+st5ynqREaYPcIlim82NfVktthbf0ZnUf1PHH+zskI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dDxwQoteBI7yrh57NMRgh5Bhs7pXRjtjXB22kxC/mOWEVqC9zyLSrXbQFGcYTqOWY r2O0dRu9Ce9x++UpdE+avy31YDo38BR/Bi+lwMBx21Qivb+1DUvmjSrIUwyrnBwKN5 hWIGFv22faoum7sJVUHH4oEcGBKzhajrUFV2DNu4= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=72.185.194.198; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <20160223.160806.696185201696745163.mbj@tail-f.com> Date: Wed, 24 Feb 2016 09:13:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <743F628C-FDCB-4742-8322-38CEC69AC7FF@lucidvision.com> References: <20160223.160806.696185201696745163.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3112) 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=72.185.194.198 X-IP-stats: Notspam Incoming Last 0, First 1, in=6, out=0, spam=0 Known=true ip=72.185.194.198 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 14:14:01 -0000 > On Feb 23, 2016:10:08 AM, at 10:08 AM, Martin Bjorklund = wrote: >=20 > Hi, >=20 > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > for being able to specify modules to mount directly in the schema. > Something like this: >=20 > container root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } >=20 > It would be useful if the use case for this could be described in more > details. Is it a requirement to be able to specify this in the > schema, or could it be done (as Chris mentioned) in the RFC text? >=20 > The reason I ask is that it is probably not as simple as the example > above. First, you probably need to specify a revision of the module > to be mounted. Or a min-revision. Then probably a set of features > that must be enabled. And so on. It turns out that there is already > a proposal for specifying such a "conformance profile" - YANG Packages > (see draft-bierman-netmod-yang-package). Maybe it would be better to > re-use packages? A question: is the point to manually/explicitly mount a specific = container/s=20 or the root of a device? I=E2=80=99d like to understand the use case = better here too because, as you say, it can easily get complicated quickly. =E2=80=94Tom >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 24 06:17:31 2016 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 14B8A1B2E1C; Wed, 24 Feb 2016 06:17:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160224141730.8516.29327.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 06:17:30 -0800 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-metadata@ietf.org, netmod@ietf.org Subject: [netmod] Last Call: (Defining and Using Metadata with YANG) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:17:30 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Defining and Using Metadata with YANG' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 06:19:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117BD1B2F7A for ; Wed, 24 Feb 2016 06:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 IvmMTRj_CFTJ for ; Wed, 24 Feb 2016 06:19:55 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 303261B2F70 for ; Wed, 24 Feb 2016 06:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1456323585; bh=A/yZMM7q6+fGZCKRYjU8Ei174zCK9PburbbrZ0Xsmdw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nTC0xxqz8OBs3PHgVY/0kZuBc3QjNwX7AMsN4cx7wtSisDqJb8VQXf3qvP/tBvyG6 N4uFuVr4oz6gWM4dC24rYivYvmovOaAI3+UOVf99lIaTx7KyUR8lPc8cnuOF72VkQS qPPJhb0KYDD57qVBwY1T9DBp7zg3W0DHIbS6+y/4= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=72.185.194.198; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> Date: Wed, 24 Feb 2016 09:19:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <768389FE-2F7B-4E01-89AD-771C6AB6655D@lucidvision.com> References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> To: Voit Eric X-Mailer: Apple Mail (2.3112) 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=72.185.194.198 X-IP-stats: Notspam Incoming Last 0, First 1, in=8, out=0, spam=0 Known=true ip=72.185.194.198 Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 14:19:57 -0000 > On Feb 23, 2016:6:21 PM, at 6:21 PM, Eric Voit (evoit) = wrote: >=20 > Hi Kent, >=20 > Thanks for running the interim, I agree it was quite useful. =20 >=20 > One thing I wanted to pull out from the minutes was the overall = definition of "Mount". Right now there are 830 web pages on the = OpenDaylight site which refer to "Mount" in terms of Peer Mount (i.e., = something much like draft-clemm-netmod-mount). =20 >=20 > That does not mean that the IETF need define "Mount" the same way as = an Open Source project. But it is possible at this stage to create both = terminology and requirements which breaks down the overall problem = space. In other words there is nothing stopping us from defining a set = of terms and technology solutions which fit together in a complimentary = way. Nothing here need conflict. =09 I agree that normalizing the terminology is probably a good = thing. What I would caution against is a unilateral definition here as = it is likely to be IETF-centric; its a good idea to poll the other = communities that are using this technology. =E2=80=94Tom > If there is community interest, I would be willing to pull together a = strawman requirements/terminology draft describing the differences = between mounting schemas on a box, mounting a remote datastore. >=20 > Any interest? > Eric=20 >=20 >> From: netmod, February 22, 2016 3:51 PM >>=20 >>=20 >> Thank you all who joined today=E2=80=99s virtual interim meeting. >>=20 >> Other than my starting the recording late and rearranging the = presentation order, >> I thought that the meeting went really well in that there seems to be = a lot of >> support for trying to solve this problem, and because we have a plan = to try to >> move towards having a WG document in the BA timeframe. The plan is = for >> draft-bjorklund-netmod-structural-mount to be updated based on the = meeting >> and for it to be discussed on list as the basis for the WG effort on = the topic. >>=20 >> Attached are the very rough Ethernet minutes captured during the = meeting. >> Please review carefully. Corrections can be made on the etherpad = here: >> http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 (so we = can >> track changes, the end of meeting snapshot is here: >> http://etherpad.tools.ietf.org:9000/p/netmod-interim- >> 20160222/timeslider#3933) >>=20 >> To listen to the recording, please follow one of these two links: >>=20 >> Streaming recording link: >>=20 >> = https://ietf.webex.com/ietf/ldr.php?RCID=3D4dc88386f13a49fa8f2c934db953f4a= 2 >>=20 >> Download recording link: >>=20 >> = https://ietf.webex.com/ietf/lsr.php?RCID=3D1b6490fe5cc6fc95d4e3c9b913dfdc1= f >>=20 >>=20 >> Thanks again, >>=20 >> Kent and Lou >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 24 06:26:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4230E1B305D for ; Wed, 24 Feb 2016 06:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 B-HLcAjgtiI0 for ; Wed, 24 Feb 2016 06:26:49 -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 41C8D1B3058 for ; Wed, 24 Feb 2016 06:26:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id C15A1181C34; Wed, 24 Feb 2016 15:26:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456324005; bh=5k721nMlT2dqcE8mpSLiN6XVmbQVPBs+6WwHU9GkrmY=; h=From:Date:To; b=YZ7rL2nw6fQKZ8VL40nWnv+Au/1bmqi3Jh9bRVe9ymGr0eURyJcFByO1MITsWe3Hp xRekEMmXtU1Ka5Re7zowRDrgEuLcNW8nt0TjoUFICgP3ANl6YVZLujqnc4f/T0RLNx fJhZFBZvq6kqnEF2ajbeCXg9/BRS4mzd9cG2RT9o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160223.160806.696185201696745163.mbj@tail-f.com> Date: Wed, 24 Feb 2016 15:26:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4F343B-3869-41A6-9E7C-CE655917F0F1@nic.cz> References: <20160223.160806.696185201696745163.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] explicit mount 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, 24 Feb 2016 14:26:51 -0000 > On 23 Feb 2016, at 16:08, Martin Bjorklund wrote: >=20 > Hi, >=20 > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > for being able to specify modules to mount directly in the schema. > Something like this: >=20 > container root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } >=20 It is IMO impossible to use YANG extensions for similar purposes because = it fundamentally changes YANG semantics. Lada > It would be useful if the use case for this could be described in more > details. Is it a requirement to be able to specify this in the > schema, or could it be done (as Chris mentioned) in the RFC text? >=20 > The reason I ask is that it is probably not as simple as the example > above. First, you probably need to specify a revision of the module > to be mounted. Or a min-revision. Then probably a set of features > that must be enabled. And so on. It turns out that there is already > a proposal for specifying such a "conformance profile" - YANG Packages > (see draft-bierman-netmod-yang-package). Maybe it would be better to > re-use packages? >=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 Feb 24 06:41:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BBB1A893F for ; Wed, 24 Feb 2016 06:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 OQwnyADgaH4f for ; Wed, 24 Feb 2016 06:41:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 357D21A8978 for ; Wed, 24 Feb 2016 06:41:13 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C7BD1AE0336; Wed, 24 Feb 2016 15:41:11 +0100 (CET) Date: Wed, 24 Feb 2016 15:41:15 +0100 (CET) Message-Id: <20160224.154115.1596709215790076040.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> References: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@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] 'predicate' production 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, 24 Feb 2016 14:41:15 -0000 Ladislav Lhotka wrote: > Hi, > > another ABNF issue: > > predicate = "[" *WSP (predicate-expr / pos) *WSP "]" > > predicate-expr = (node-identifier / ".") *WSP "=" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) > > pos = non-negative-integer-value > > non-negative-integer-value = "0" / positive-integer-value > > The value of 0 shouldn't be allowed for 'pos' because context position > in XPath is always positive, i.e. the first list entry is selected > with "[1]". You are right - I have changed this to: pos = positive-integer-value /martin > > 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 Wed Feb 24 06:48:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7F1B3211 for ; Wed, 24 Feb 2016 06:48:50 -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 66xGl2hiVpxN for ; Wed, 24 Feb 2016 06:48:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A842E1B3205 for ; Wed, 24 Feb 2016 06:48:44 -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.409.15; Wed, 24 Feb 2016 14:48:26 +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.0409.024; Wed, 24 Feb 2016 14:48:26 +0000 From: Kent Watsen To: Ladislav Lhotka , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= Thread-Topic: [netmod] explicit mount Thread-Index: AQHRbkwCjWuFNG7t/Uau+auLejoJZp87QjkA//+yMAA= Date: Wed, 24 Feb 2016 14:48:26 +0000 Message-ID: References: <20160223.160806.696185201696745163.mbj@tail-f.com> <6F4F343B-3869-41A6-9E7C-CE655917F0F1@nic.cz> In-Reply-To: <6F4F343B-3869-41A6-9E7C-CE655917F0F1@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.160212 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:oxzSghbR5QLHstmgbI5s2yKMAhkSU05JTAyywcgC0k+tybtmMkhSyghBuCWDaR6pj7bAJIccdx2rx8pOeBiVN/+F/h6yx/9IWPyw5JUwgCK1YaqBegUjWW77YUe1YNdPbZATWsvq2UowQS03jg8JFg==; 24:IkfZ14uPXsJdXrFF7ffObjzR1ivseDENhMgK1pexCn0zezjioILXwC0o0C4prZ4yFJJz6jb4nrJ3Gl+glxt3lZIbCQfV39cEqUY8BzUKDN0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: bf111893-4a79-4e5a-8f39-08d33d298d51 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 08626BE3A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5001960100002)(4001350100001)(5002640100001)(106116001)(87936001)(189998001)(99286002)(83716003)(11100500001)(5001770100001)(92566002)(4326007)(2906002)(10400500002)(122556002)(40100003)(3660700001)(3280700002)(54356999)(50986999)(586003)(5004730100002)(36756003)(5008740100001)(1096002)(1220700001)(76176999)(3846002)(6116002)(102836003)(86362001)(33656002)(66066001)(82746002)(83506001)(2950100001)(2900100001)(77096005)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 24 Feb 2016 14:48:26.2320 (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] explicit mount 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, 24 Feb 2016 14:48:50 -0000 DQpIaSBMYWRhLA0KDQoNCg0KDQoNCg0KPj5JbiB5ZXN0ZXJkYXkncyBtZWV0aW5nLCBMb3UgKEkg dGhpbms/KSBtZW50aW9uZWQgYSB1c2UgY2FzZSBmb3IgbW91bnQNCj4+IHRoYXQgaXMgbm90IGRv Y3VtZW50ZWQgaW4gZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbDsgdGhlIG5lZWQN Cj4+IGZvciBiZWluZyBhYmxlIHRvIHNwZWNpZnkgbW9kdWxlcyB0byBtb3VudCBkaXJlY3RseSBp biB0aGUgc2NoZW1hLg0KPj4gU29tZXRoaW5nIGxpa2UgdGhpczoNCj4+IA0KPj4gIGNvbnRhaW5l ciByb290IHsNCj4+ICAgIHltbnQ6bW91bnQtcG9pbnQgImxuZSIgew0KPj4gICAgICB5bW50Om1v dW50LW1vZHVsZSAiaWV0Zi1pbnRlcmZhY2VzIjsNCj4+ICAgIH0NCj4+ICB9DQo+PiANCj4NCj5J dCBpcyBJTU8gaW1wb3NzaWJsZSB0byB1c2UgWUFORyBleHRlbnNpb25zIGZvciBzaW1pbGFyIHB1 cnBvc2VzIGJlY2F1c2UgaXQgZnVuZGFtZW50YWxseSBjaGFuZ2VzIFlBTkcgc2VtYW50aWNzLg0K DQoNClBsZWFzZSBzYXkgbW9yZS4gIEkgZG9u4oCZdCBzZWUgdGhlIGlzc3VlLiAgTmF0dXJhbGx5 IHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgYW4gUkZDIHRoYXQgZGVmaW5lcyB0aGUgc2VtYW50aWNz IG9mIHRoaXMgWUFORyBleHRlbnNpb24sIHdoYXQgZWxzZSB3b3VsZCBiZSBtaXNzaW5nPw0KDQpL Lg0KDQo= From nobody Wed Feb 24 07:08:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F91B2D3E for ; Wed, 24 Feb 2016 07:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 u33VgqOI9wZQ for ; Wed, 24 Feb 2016 07:08:32 -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 C65851B2F0D for ; Wed, 24 Feb 2016 07:08:31 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78aa:6044:e10:c902] (unknown [IPv6:2001:718:1a02:1:78aa:6044:e10:c902]) by mail.nic.cz (Postfix) with ESMTPSA id 848E01816DB for ; Wed, 24 Feb 2016 16:08:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456326510; bh=TBk+aLbQkr9onl8AECIEYkQD3rWpODVR2IUNnc8QkyM=; h=From:Date:To; b=bHkw1xrRYBRoEPeLUj18WKGlOqN/X3aZaajQ8Ltpw+9H1VT8w14QfB+1rq3LLw9+5 T++xdMooDQpfQLTEvRoLgmN97SDCs+IVWPvG0fE848u88Db4zVYRYA5R29GFIC9+YI 4mrBL6DP9fQvRnPZVU6I/h5q46FHdoFh1WzhHP9I= 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: Wed, 24 Feb 2016 16:08:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160223.160806.696185201696745163.mbj@tail-f.com> <6F4F343B-3869-41A6-9E7C-CE655917F0F1@nic.cz> 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] explicit mount 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, 24 Feb 2016 15:08:33 -0000 > On 24 Feb 2016, at 15:48, Kent Watsen wrote: >=20 >=20 > Hi Lada, >=20 >=20 >=20 >=20 >=20 >=20 >>> In yesterday's meeting, Lou (I think?) mentioned a use case for = mount >>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the = need >>> for being able to specify modules to mount directly in the schema. >>> Something like this: >>>=20 >>> container root { >>> ymnt:mount-point "lne" { >>> ymnt:mount-module "ietf-interfaces"; >>> } >>> } >>>=20 >>=20 >> It is IMO impossible to use YANG extensions for similar purposes = because it fundamentally changes YANG semantics. >=20 >=20 > Please say more. I don=E2=80=99t see the issue. Naturally there = would need to be an RFC that defines the semantics of this YANG = extension, what else would be missing? Extensions are optional to implement and "MAY be ignored in its = entirety" (sec. 6.3.1 in 6020bis). Otherwise, why have we bothered so = much with backward compatibility in YANG 1.1? Somebody might define, via = an extension, a new list with deep or optional keys, or a floating point = data type or whatever. So in the end everybody would have YANG exactly = to his or her own liking but there would be no standard at all. Lada >=20 > K. >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 24 07:25:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F891B3389 for ; Wed, 24 Feb 2016 07:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, RP_MATCHES_RCVD=-0.006, 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 GwBICx08u5Zc for ; Wed, 24 Feb 2016 07:25: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 3D6301B337F for ; Wed, 24 Feb 2016 07:25:23 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 39E081AE0336; Wed, 24 Feb 2016 16:25:22 +0100 (CET) Date: Wed, 24 Feb 2016 16:25:26 +0100 (CET) Message-Id: <20160224.162526.723711166245929722.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <6F4F343B-3869-41A6-9E7C-CE655917F0F1@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 15:25:24 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjQgRmVi IDIwMTYsIGF0IDE1OjQ4LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6 DQo+ID4gDQo+ID4gDQo+ID4gSGkgTGFkYSwNCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiAN Cj4gPiANCj4gPj4+IEluIHllc3RlcmRheSdzIG1lZXRpbmcsIExvdSAoSSB0aGluaz8pIG1lbnRp b25lZCBhIHVzZSBjYXNlIGZvciBtb3VudA0KPiA+Pj4gdGhhdCBpcyBub3QgZG9jdW1lbnRlZCBp biBkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsOyB0aGUgbmVlZA0KPiA+Pj4gZm9y IGJlaW5nIGFibGUgdG8gc3BlY2lmeSBtb2R1bGVzIHRvIG1vdW50IGRpcmVjdGx5IGluIHRoZSBz Y2hlbWEuDQo+ID4+PiBTb21ldGhpbmcgbGlrZSB0aGlzOg0KPiA+Pj4gDQo+ID4+PiBjb250YWlu ZXIgcm9vdCB7DQo+ID4+PiAgeW1udDptb3VudC1wb2ludCAibG5lIiB7DQo+ID4+PiAgICB5bW50 Om1vdW50LW1vZHVsZSAiaWV0Zi1pbnRlcmZhY2VzIjsNCj4gPj4+ICB9DQo+ID4+PiB9DQo+ID4+ PiANCj4gPj4gDQo+ID4+IEl0IGlzIElNTyBpbXBvc3NpYmxlIHRvIHVzZSBZQU5HIGV4dGVuc2lv bnMgZm9yIHNpbWlsYXIgcHVycG9zZXMNCj4gPj4gYmVjYXVzZSBpdCBmdW5kYW1lbnRhbGx5IGNo YW5nZXMgWUFORyBzZW1hbnRpY3MuDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIHNheSBtb3JlLiAg SSBkb27igJl0IHNlZSB0aGUgaXNzdWUuICBOYXR1cmFsbHkgdGhlcmUgd291bGQgbmVlZA0KPiA+ IHRvIGJlIGFuIFJGQyB0aGF0IGRlZmluZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIFlBTkcgZXh0 ZW5zaW9uLCB3aGF0DQo+ID4gZWxzZSB3b3VsZCBiZSBtaXNzaW5nPw0KPiANCj4gRXh0ZW5zaW9u cyBhcmUgb3B0aW9uYWwgdG8gaW1wbGVtZW50IGFuZCAiTUFZIGJlIGlnbm9yZWQgaW4gaXRzDQo+ IGVudGlyZXR5IiAoc2VjLiA2LjMuMSBpbiA2MDIwYmlzKS4gT3RoZXJ3aXNlLCB3aHkgaGF2ZSB3 ZSBib3RoZXJlZCBzbw0KPiBtdWNoIHdpdGggYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpbiBZQU5H IDEuMT8gU29tZWJvZHkgbWlnaHQgZGVmaW5lLA0KPiB2aWEgYW4gZXh0ZW5zaW9uLCBhIG5ldyBs aXN0IHdpdGggZGVlcCBvciBvcHRpb25hbCBrZXlzLCBvciBhIGZsb2F0aW5nDQo+IHBvaW50IGRh dGEgdHlwZSBvciB3aGF0ZXZlci4gU28gaW4gdGhlIGVuZCBldmVyeWJvZHkgd291bGQgaGF2ZSBZ QU5HDQo+IGV4YWN0bHkgdG8gaGlzIG9yIGhlciBvd24gbGlraW5nIGJ1dCB0aGVyZSB3b3VsZCBi ZSBubyBzdGFuZGFyZCBhdA0KPiBhbGwuDQoNClN1cmUsIHRoaXMgaXMgcG9zc2libGUuICBGb3Ig ZXhhbXBsZSB3ZSBoYXZlIGFuIGV4dGVuc2lvbiBmb3IgWUFORyAxLjANCmNhbGxlZCB0YWlsZjph Y3Rpb24gKGl0IGlzIG5vdCBuZWVkZWQgYW55bW9yZSBvZiBjb3Vyc2UpLiAgVGhlIHBvaW50DQpp cyB0aGF0IHdlIGNhbiBkZWZpbmUgc3RhbmRhcmQgZXh0ZW5zaW9ucyB3aXRoIGEgd2VsbC1kZWZp bmVkIG1lYW5pbmcuDQpUaGV5IHdvdWxkIGJlIG9wdGlvbmFsIHRvIGltcGxlbWVudCBpbiBnZW5l cmFsLCBidXQgd2UgY2FuIGNlcnRhaW5seQ0Kc2F5IHRoYXQgaWYgeW91IGltcGxlbWVudCBhIG1v ZHVsZSB0aGF0IHVzZXMgeW1udDptb3VudC1wb2ludCwgeW91DQpNVVNUIGFsc28gaW1wbGVtZW50 IHRoZSBtb3VudC1wb2ludCBleHRlbnNpb24uICBKdXN0IGxpa2Ugd2UgZG8gd2l0aA0KbmFjbTpk ZWZhdWx0LWRlbnktYWxsLg0KDQoNCi9tYXJ0aW4NCg== From nobody Wed Feb 24 08:09:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71CD1B37B3 for ; Wed, 24 Feb 2016 08:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 VNIBaOhTX-IY for ; Wed, 24 Feb 2016 08:09:41 -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 B16981B3810 for ; Wed, 24 Feb 2016 08:09:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 111521A5E; Wed, 24 Feb 2016 17:09:39 +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 rJsDN8pLfqj6; Wed, 24 Feb 2016 17:09:25 +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, 24 Feb 2016 17:09:38 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 378BB20033; Wed, 24 Feb 2016 17:09:38 +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 gQZMcPPZWmUC; Wed, 24 Feb 2016 17:09:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10C8E2002C; Wed, 24 Feb 2016 17:09:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81E3439FCB9B; Wed, 24 Feb 2016 17:09:34 +0100 (CET) Date: Wed, 24 Feb 2016 17:09:33 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160224160933.GA17873@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160223.160806.696185201696745163.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160223.160806.696185201696745163.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 16:09:43 -0000 On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > Hi, > > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > for being able to specify modules to mount directly in the schema. > Something like this: > > container root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } > > It would be useful if the use case for this could be described in more > details. Is it a requirement to be able to specify this in the > schema, or could it be done (as Chris mentioned) in the RFC text? > > The reason I ask is that it is probably not as simple as the example > above. First, you probably need to specify a revision of the module > to be mounted. Or a min-revision. Then probably a set of features > that must be enabled. And so on. It turns out that there is already > a proposal for specifying such a "conformance profile" - YANG Packages > (see draft-bierman-netmod-yang-package). Maybe it would be better to > re-use packages? We are talking schema mount, right? So why would features matter? Yes, there might be interesting versioning issues but how are they different from an augmentation putting data under root? I naively considered such a 'static schema defined mount' the simplest case, then the 'augmented schema defined mount' naturally following from the way augmentations work: augment /some:root { ymnt:mount-point "lne" { ymnt:mount-module "ietf-interfaces"; } } The 'dynamic runtime defined mounts' may be most flexible but then they require me to read runtime data in order to adapt to the schema structure, which has its own set of complexities. Yes, the versioning issues go away since I have to adapt to each implementation dynamically but there is surely a cost involved with that as well. Am I missing something? /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 Feb 24 10:53:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC3D1A902C for ; Wed, 24 Feb 2016 10:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 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_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 ZtkTPpdJG4JZ for ; Wed, 24 Feb 2016 10:53:06 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 59D891AD182 for ; Wed, 24 Feb 2016 10:53:02 -0800 (PST) Received: from [172.16.0.6] (chello085216168097.chello.sk [85.216.168.97]) by mail.hq.sk (Postfix) with ESMTPSA id A096C243EF0; Wed, 24 Feb 2016 19:52:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1456339979; bh=93Ia2TPVn/8r5H5hOTcFtphOwb4LUzsmo8NFZjZWt+4=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=kIHeD4Y/tO993AwZ5DNmqK7f3Ev4GZEeJdjqkHHyXwiUOPMEWFuNw9bJDN/J+SZ+n wA1dF4q//QXPLmCszTTOUlCmgrZ2CHquThl39CUiAHd63tluP+bkalCjQWoDsynswd HCN5EnxgzO43T/Mmp+NBTBwwW0Bfuph8Hvu2Eujw= To: Martin Bjorklund , lhotka@nic.cz References: <6F4F343B-3869-41A6-9E7C-CE655917F0F1@nic.cz> <20160224.162526.723711166245929722.mbj@tail-f.com> From: Robert Varga Message-ID: <56CDFC0B.9020300@hq.sk> Date: Wed, 24 Feb 2016 19:52:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160224.162526.723711166245929722.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 18:53:07 -0000 On 02/24/2016 04:25 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>> On 24 Feb 2016, at 15:48, Kent Watsen wrote: >>> >>> >>> Hi Lada, >>> >>> >>> >>> >>> >>> >>>>> In yesterday's meeting, Lou (I think?) mentioned a use case for mount >>>>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the need >>>>> for being able to specify modules to mount directly in the schema. >>>>> Something like this: >>>>> >>>>> container root { >>>>> ymnt:mount-point "lne" { >>>>> ymnt:mount-module "ietf-interfaces"; >>>>> } >>>>> } >>>>> >>>> It is IMO impossible to use YANG extensions for similar purposes >>>> because it fundamentally changes YANG semantics. >>> >>> Please say more. I don’t see the issue. Naturally there would need >>> to be an RFC that defines the semantics of this YANG extension, what >>> else would be missing? >> Extensions are optional to implement and "MAY be ignored in its >> entirety" (sec. 6.3.1 in 6020bis). Otherwise, why have we bothered so >> much with backward compatibility in YANG 1.1? Somebody might define, >> via an extension, a new list with deep or optional keys, or a floating >> point data type or whatever. So in the end everybody would have YANG >> exactly to his or her own liking but there would be no standard at >> all. > Sure, this is possible. For example we have an extension for YANG 1.0 > called tailf:action (it is not needed anymore of course). The point > is that we can define standard extensions with a well-defined meaning. > They would be optional to implement in general, but we can certainly > say that if you implement a module that uses ymnt:mount-point, you > MUST also implement the mount-point extension. Just like we do with > nacm:default-deny-all. I think we need to be very explicit about interactions with YANG-based systems which choose to ignore a particular extension. To illustrate on tailf:action, it is not clear (at least to me), if it is valid to target entities within an extension instantiation with an augment statement. If a YANG compiler decides to ignore the extension completely (which I think is valid interpretation of RFC6020), such augment targets become invalid and YANG modules containing those augment statements are not universally portable ... Bye, Robert From nobody Wed Feb 24 11:39:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB61B3DE6 for ; Wed, 24 Feb 2016 11:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.906 X-Spam-Level: X-Spam-Status: No, score=-13.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=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 QYA-6o5Q5aoc for ; Wed, 24 Feb 2016 11:39:18 -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 CC0351B3DE9 for ; Wed, 24 Feb 2016 11:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4282; q=dns/txt; s=iport; t=1456342755; x=1457552355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vpLg9NbtXL+54licdlQSUNZf2wUxSVys+5EohjaYyLU=; b=SkQdGqRhsT8H5ipxScUyTQbSbGQuKGBcSEOQ/8AY7bDqHWmRfWaN6k/6 vSylN3qQgi77z80S5RVQGTUDE+DqgAg8hFON6rFls0os/i3T59InZYpqW u13PklcehYe6/L96tMIc9GEnLDjZofchug4u+Dv3d4M9ahsbGrCouv49y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgCpBs5W/5hdJa1EGoM6Um0Gugt2A?= =?us-ascii?q?Q2BZhcKhQ4VSgIcgSs4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgEToGBQULAgEIDgc?= =?us-ascii?q?DAgImAgICJQsVEAIEDgUIDAeHfAgOLK5Rjl8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEVe4UXhDqBNoV/gToFlwcBhVeCboUSgWVLg3mHOIEajkgBHgEBQoIDGYFIagG?= =?us-ascii?q?GYn0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="80041848" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 19:39:04 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1OJd4xE010051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 19:39:04 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 13:39:03 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 13:39:03 -0600 From: "Eric Voit (evoit)" To: Nadeau Thomas Thread-Topic: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 Thread-Index: AQHRZBo2ldk6RMUP3EKey+nbiKkXx583zF4AgAB9CgCAAgagwIABaRgA///0DWA= Date: Wed, 24 Feb 2016 19:39:02 +0000 Message-ID: <15183339120e4b5b8eacf86b701e06b3@XCH-ALN-013.cisco.com> References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> <768389FE-2F7B-4E01-89AD-771C6AB6655D@lucidvision.com> In-Reply-To: <768389FE-2F7B-4E01-89AD-771C6AB6655D@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 19:39:20 -0000 PiBGcm9tOiBOYWRlYXUgVGhvbWFzLCBGZWJydWFyeSAyNCwgMjAxNiA5OjIwIEFNDQo+IA0KPiA+ IE9uIEZlYiAyMywgMjAxNjo2OjIxIFBNLCBhdCA2OjIxIFBNLCBFcmljIFZvaXQgKGV2b2l0KSA8 ZXZvaXRAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IEhpIEtlbnQsDQo+ID4NCj4gPiBU aGFua3MgZm9yIHJ1bm5pbmcgdGhlIGludGVyaW0sIEkgYWdyZWUgaXQgd2FzIHF1aXRlIHVzZWZ1 bC4NCj4gPg0KPiA+IE9uZSB0aGluZyBJIHdhbnRlZCB0byBwdWxsIG91dCBmcm9tIHRoZSBtaW51 dGVzIHdhcyB0aGUgb3ZlcmFsbCBkZWZpbml0aW9uIG9mDQo+ICJNb3VudCIuICAgICBSaWdodCBu b3cgdGhlcmUgYXJlIDgzMCB3ZWIgcGFnZXMgb24gdGhlIE9wZW5EYXlsaWdodCBzaXRlIHdoaWNo DQo+IHJlZmVyIHRvICJNb3VudCIgaW4gdGVybXMgb2YgUGVlciBNb3VudCAoaS5lLiwgc29tZXRo aW5nIG11Y2ggbGlrZSBkcmFmdC1jbGVtbS0NCj4gbmV0bW9kLW1vdW50KS4NCj4gPg0KPiA+IFRo YXQgZG9lcyBub3QgbWVhbiB0aGF0IHRoZSBJRVRGIG5lZWQgZGVmaW5lICJNb3VudCIgdGhlIHNh bWUgd2F5IGFzIGFuDQo+IE9wZW4gU291cmNlIHByb2plY3QuICBCdXQgaXQgaXMgcG9zc2libGUg YXQgdGhpcyBzdGFnZSB0byBjcmVhdGUgYm90aCB0ZXJtaW5vbG9neQ0KPiBhbmQgcmVxdWlyZW1l bnRzIHdoaWNoIGJyZWFrcyBkb3duIHRoZSBvdmVyYWxsIHByb2JsZW0gc3BhY2UuICAgSW4gb3Ro ZXINCj4gd29yZHMgdGhlcmUgaXMgbm90aGluZyBzdG9wcGluZyB1cyBmcm9tIGRlZmluaW5nIGEg c2V0IG9mIHRlcm1zIGFuZCB0ZWNobm9sb2d5DQo+IHNvbHV0aW9ucyB3aGljaCBmaXQgdG9nZXRo ZXIgaW4gYSBjb21wbGltZW50YXJ5IHdheS4gIE5vdGhpbmcgaGVyZSBuZWVkDQo+IGNvbmZsaWN0 Lg0KPiANCj4gCUkgYWdyZWUgdGhhdCBub3JtYWxpemluZyB0aGUgdGVybWlub2xvZ3kgaXMgcHJv YmFibHkgYSBnb29kIHRoaW5nLiAgV2hhdA0KPiBJIHdvdWxkIGNhdXRpb24gYWdhaW5zdCBpcyBh IHVuaWxhdGVyYWwgZGVmaW5pdGlvbiBoZXJlIGFzIGl0IGlzIGxpa2VseSB0byBiZSBJRVRGLQ0K PiBjZW50cmljOyBpdHMgYSBnb29kIGlkZWEgdG8gcG9sbCB0aGUgb3RoZXIgY29tbXVuaXRpZXMg dGhhdCBhcmUgdXNpbmcgdGhpcw0KPiB0ZWNobm9sb2d5Lg0KDQpNYWtlcyBzZW5zZS4gICBBbnkg dGhvdWdodHMgb24gd2hvIG1pZ2h0IHJlcHJlc2VudCB0aGUgbWVhbmluZyBvZiBNb3VudCBmcm9t IE9ETD8NCg0KRXJpYw0KDQo+IAnigJRUb20NCj4gDQo+IA0KPiA+IElmIHRoZXJlIGlzIGNvbW11 bml0eSBpbnRlcmVzdCwgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHB1bGwgdG9nZXRoZXIgYSBzdHJh d21hbg0KPiByZXF1aXJlbWVudHMvdGVybWlub2xvZ3kgZHJhZnQgZGVzY3JpYmluZyB0aGUgZGlm ZmVyZW5jZXMgYmV0d2VlbiBtb3VudGluZw0KPiBzY2hlbWFzIG9uIGEgYm94LCBtb3VudGluZyBh IHJlbW90ZSBkYXRhc3RvcmUuDQo+ID4NCj4gPiBBbnkgaW50ZXJlc3Q/DQo+ID4gRXJpYw0KPiA+ DQo+ID4+IEZyb206IG5ldG1vZCwgRmVicnVhcnkgMjIsIDIwMTYgMzo1MSBQTQ0KPiA+Pg0KPiA+ Pg0KPiA+PiBUaGFuayB5b3UgYWxsIHdobyBqb2luZWQgdG9kYXnigJlzIHZpcnR1YWwgaW50ZXJp bSBtZWV0aW5nLg0KPiA+Pg0KPiA+PiBPdGhlciB0aGFuIG15IHN0YXJ0aW5nIHRoZSByZWNvcmRp bmcgbGF0ZSBhbmQgcmVhcnJhbmdpbmcgdGhlDQo+ID4+IHByZXNlbnRhdGlvbiBvcmRlciwgSSB0 aG91Z2h0IHRoYXQgdGhlIG1lZXRpbmcgd2VudCByZWFsbHkgd2VsbCBpbg0KPiA+PiB0aGF0IHRo ZXJlIHNlZW1zIHRvIGJlIGEgbG90IG9mIHN1cHBvcnQgZm9yIHRyeWluZyB0byBzb2x2ZSB0aGlz DQo+ID4+IHByb2JsZW0sIGFuZCBiZWNhdXNlIHdlIGhhdmUgYSBwbGFuIHRvIHRyeSB0byBtb3Zl IHRvd2FyZHMgaGF2aW5nIGENCj4gPj4gV0cgZG9jdW1lbnQgaW4gdGhlIEJBIHRpbWVmcmFtZS4g IFRoZSBwbGFuIGlzIGZvcg0KPiA+PiBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXN0cnVjdHVyYWwt bW91bnQgdG8gYmUgdXBkYXRlZCBiYXNlZCBvbiB0aGUNCj4gbWVldGluZyBhbmQgZm9yIGl0IHRv IGJlIGRpc2N1c3NlZCBvbiBsaXN0IGFzIHRoZSBiYXNpcyBmb3IgdGhlIFdHIGVmZm9ydCBvbiB0 aGUNCj4gdG9waWMuDQo+ID4+DQo+ID4+IEF0dGFjaGVkIGFyZSB0aGUgdmVyeSByb3VnaCBFdGhl cm5ldCBtaW51dGVzIGNhcHR1cmVkIGR1cmluZyB0aGUgbWVldGluZy4NCj4gPj4gUGxlYXNlIHJl dmlldyBjYXJlZnVsbHkuICBDb3JyZWN0aW9ucyBjYW4gYmUgbWFkZSBvbiB0aGUgZXRoZXJwYWQg aGVyZToNCj4gPj4gaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9uZXRtb2Qt aW50ZXJpbS0yMDE2MDIyMiAgKHNvIHdlDQo+ID4+IGNhbiB0cmFjayBjaGFuZ2VzLCB0aGUgZW5k IG9mIG1lZXRpbmcgc25hcHNob3QgaXMgaGVyZToNCj4gPj4gaHR0cDovL2V0aGVycGFkLnRvb2xz LmlldGYub3JnOjkwMDAvcC9uZXRtb2QtaW50ZXJpbS0NCj4gPj4gMjAxNjAyMjIvdGltZXNsaWRl ciMzOTMzKQ0KPiA+Pg0KPiA+PiBUbyBsaXN0ZW4gdG8gdGhlIHJlY29yZGluZywgcGxlYXNlIGZv bGxvdyBvbmUgb2YgdGhlc2UgdHdvIGxpbmtzOg0KPiA+Pg0KPiA+PiAgU3RyZWFtaW5nIHJlY29y ZGluZyBsaW5rOg0KPiA+Pg0KPiA+PiBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBo cD9SQ0lEPTRkYzg4Mzg2ZjEzYTQ5ZmE4ZjJjOTM0ZGI5NTMNCj4gPj4gZjRhMg0KPiA+Pg0KPiA+ PiAgRG93bmxvYWQgcmVjb3JkaW5nIGxpbms6DQo+ID4+DQo+ID4+IGh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9MWI2NDkwZmU1Y2M2ZmM5NWQ0ZTNjOWI5MTNkZg0KPiA+ PiBkYzFmDQo+ID4+DQo+ID4+DQo+ID4+IFRoYW5rcyBhZ2FpbiwNCj4gPj4NCj4gPj4gS2VudCBh bmQgTG91DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Wed Feb 24 12:03:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D301AC3F8 for ; Wed, 24 Feb 2016 12:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 HlZ8TkXEee64 for ; Wed, 24 Feb 2016 12:03:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 130B91B2DE6 for ; Wed, 24 Feb 2016 12:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1456344140; bh=bs7Yv+hKVHhChDz3ywW/Z7OUPsRtyCHGAze8W+BYH54=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ILevJaDi/wokJSoYd6mRiKOOvp1+Mb+19aCLLuBZ9pVqA0G/gWZuK6yh0N9nOIt0y 1OsboTkAi9yPQ2mm0hk5zaFBirJIVVp8LSoKJUUi691a4iCuO71dGKm38tPswqQnhY IKeocB7kW1WH/4Kx1QHUFFviHmldAlCf8uc/QkPo= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=72.185.194.198; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <15183339120e4b5b8eacf86b701e06b3@XCH-ALN-013.cisco.com> Date: Wed, 24 Feb 2016 15:02:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160210154624.25146.86523.idtracker@ietfa.amsl.com> <50c2c2e7619e4b138626b714d9fa7045@XCH-ALN-013.cisco.com> <768389FE-2F7B-4E01-89AD-771C6AB6655D@lucidvision.com> <15183339120e4b5b8eacf86b701e06b3@XCH-ALN-013.cisco.com> To: Voit Eric X-Mailer: Apple Mail (2.3112) 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=72.185.194.198 X-IP-stats: Notspam Incoming Last 0, First 1, in=14, out=0, spam=0 Known=true ip=72.185.194.198 Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016 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, 24 Feb 2016 20:03:02 -0000 > On Feb 24, 2016:2:39 PM, at 2:39 PM, Eric Voit (evoit) = wrote: >=20 >> From: Nadeau Thomas, February 24, 2016 9:20 AM >>=20 >>> On Feb 23, 2016:6:21 PM, at 6:21 PM, Eric Voit (evoit) = >> wrote: >>>=20 >>> Hi Kent, >>>=20 >>> Thanks for running the interim, I agree it was quite useful. >>>=20 >>> One thing I wanted to pull out from the minutes was the overall = definition of >> "Mount". Right now there are 830 web pages on the OpenDaylight = site which >> refer to "Mount" in terms of Peer Mount (i.e., something much like = draft-clemm- >> netmod-mount). >>>=20 >>> That does not mean that the IETF need define "Mount" the same way as = an >> Open Source project. But it is possible at this stage to create both = terminology >> and requirements which breaks down the overall problem space. In = other >> words there is nothing stopping us from defining a set of terms and = technology >> solutions which fit together in a complimentary way. Nothing here = need >> conflict. >>=20 >> I agree that normalizing the terminology is probably a good = thing. What >> I would caution against is a unilateral definition here as it is = likely to be IETF- >> centric; its a good idea to poll the other communities that are using = this >> technology. >=20 > Makes sense. Any thoughts on who might represent the meaning of = Mount from ODL? I=E2=80=99d ask on the yangtools-dev or controller-dev lists. =E2=80=94Tom >=20 > Eric >=20 >> =E2=80=94Tom >>=20 >>=20 >>> If there is community interest, I would be willing to pull together = a strawman >> requirements/terminology draft describing the differences between = mounting >> schemas on a box, mounting a remote datastore. >>>=20 >>> Any interest? >>> Eric >>>=20 >>>> From: netmod, February 22, 2016 3:51 PM >>>>=20 >>>>=20 >>>> Thank you all who joined today=E2=80=99s virtual interim meeting. >>>>=20 >>>> Other than my starting the recording late and rearranging the >>>> presentation order, I thought that the meeting went really well in >>>> that there seems to be a lot of support for trying to solve this >>>> problem, and because we have a plan to try to move towards having a >>>> WG document in the BA timeframe. The plan is for >>>> draft-bjorklund-netmod-structural-mount to be updated based on the >> meeting and for it to be discussed on list as the basis for the WG = effort on the >> topic. >>>>=20 >>>> Attached are the very rough Ethernet minutes captured during the = meeting. >>>> Please review carefully. Corrections can be made on the etherpad = here: >>>> http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 (so = we >>>> can track changes, the end of meeting snapshot is here: >>>> http://etherpad.tools.ietf.org:9000/p/netmod-interim- >>>> 20160222/timeslider#3933) >>>>=20 >>>> To listen to the recording, please follow one of these two links: >>>>=20 >>>> Streaming recording link: >>>>=20 >>>> = https://ietf.webex.com/ietf/ldr.php?RCID=3D4dc88386f13a49fa8f2c934db953 >>>> f4a2 >>>>=20 >>>> Download recording link: >>>>=20 >>>> = https://ietf.webex.com/ietf/lsr.php?RCID=3D1b6490fe5cc6fc95d4e3c9b913df >>>> dc1f >>>>=20 >>>>=20 >>>> Thanks again, >>>>=20 >>>> Kent and Lou >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Wed Feb 24 13:04:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4081B3ED9 for ; Wed, 24 Feb 2016 13:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 FnjTTJJjdFBj for ; Wed, 24 Feb 2016 13:04:02 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726CF1B3E58 for ; Wed, 24 Feb 2016 13:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2890; q=dns/txt; s=iport; t=1456347842; x=1457557442; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LSKwaKnioWJyaGe03g5IHAmv5yygcirhhSMJtaAWUTc=; b=NFzbkarLwfxK9icNvg2Z5n7gd9jEjOYSMKFessUnapsUyRUE0e60iBqn DHU5Yt7WNSZJJ1DfZTEajWJ6lJ6xeS6QqkjOFjYd135NWWCMC5D+FiRIM ajAXF9Nu1amw9TiZ2DMcmiMDTZld2s0l5DOUyN4jWQhNFinoWXNkUGA+g 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgANGs5W/5tdJa1bA4M6Um0GumcBD?= =?us-ascii?q?YFmFwqFI0oCgUk4FAEBAQEBAQFkJ4RBAQEBBAEBATc0CwwCAgIBCA4CAQQBAQE?= =?us-ascii?q?eCQcbDAsUCQgCBAENBQiIFw69VgEBAQEBAQEBAQEBAQEBAQEBAQEBARUEikiEV?= =?us-ascii?q?iaDcwWXBwGIRYUSgWWHaYUtjkgBHgEBQoNkaoZjfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="74407649" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 21:04:01 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1OL41uG000985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 21:04:01 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 15:04:00 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 15:04:00 -0600 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] explicit mount Thread-Index: AQHRbkwiGi5XXHW8ekmYwsZI6JLn0p87w3yA///smqA= Date: Wed, 24 Feb 2016 21:04:00 +0000 Message-ID: <1da16bd668354ca6b874ef76012c812a@XCH-RCD-001.cisco.com> References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> In-Reply-To: <20160224160933.GA17873@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.163.28] 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] explicit mount 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, 24 Feb 2016 21:04:04 -0000 Juergen, I think you are correct. Also alias-mount and peer-mount (not jus= t schema-mount) specify mountpoints in the schema. They are not about moun= ting arbitrary data in arbitrary places, but defining a model with mountpoi= nts declared. =20 --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Wednesday, February 24, 2016 8:10 AM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > Hi, >=20 > In yesterday's meeting, Lou (I think?) mentioned a use case for mount=20 > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need=20 > for being able to specify modules to mount directly in the schema. > Something like this: >=20 > container root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } >=20 > It would be useful if the use case for this could be described in more=20 > details. Is it a requirement to be able to specify this in the=20 > schema, or could it be done (as Chris mentioned) in the RFC text? >=20 > The reason I ask is that it is probably not as simple as the example=20 > above. First, you probably need to specify a revision of the module=20 > to be mounted. Or a min-revision. Then probably a set of features=20 > that must be enabled. And so on. It turns out that there is already=20 > a proposal for specifying such a "conformance profile" - YANG Packages=20 > (see draft-bierman-netmod-yang-package). Maybe it would be better to=20 > re-use packages? We are talking schema mount, right? So why would features matter? Yes, ther= e might be interesting versioning issues but how are they different from an= augmentation putting data under root? I naively considered such a 'static = schema defined mount' the simplest case, then the 'augmented schema defined= mount' naturally following from the way augmentations work: augment /some:root { ymnt:mount-point "lne" { ymnt:mount-module "ietf-interfaces"; } } The 'dynamic runtime defined mounts' may be most flexible but then they req= uire me to read runtime data in order to adapt to the schema structure, whi= ch has its own set of complexities. Yes, the versioning issues go away sinc= e I have to adapt to each implementation dynamically but there is surely a = cost involved with that as well. Am I missing something? /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 From nobody Wed Feb 24 13:30:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5F91B40F4 for ; Wed, 24 Feb 2016 13:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 FKrU8rkhRjYS for ; Wed, 24 Feb 2016 13:30:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA581B40C7 for ; Wed, 24 Feb 2016 13:30:12 -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 2B85F1AE0336; Wed, 24 Feb 2016 22:30:10 +0100 (CET) Date: Wed, 24 Feb 2016 22:30:40 +0100 (CET) Message-Id: <20160224.223040.105115912610069020.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160224160933.GA17873@elstar.local> References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@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] explicit mount 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, 24 Feb 2016 21:30:18 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > > Hi, > > > > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > > for being able to specify modules to mount directly in the schema. > > Something like this: > > > > container root { > > ymnt:mount-point "lne" { > > ymnt:mount-module "ietf-interfaces"; > > } > > } > > > > It would be useful if the use case for this could be described in more > > details. Is it a requirement to be able to specify this in the > > schema, or could it be done (as Chris mentioned) in the RFC text? > > > > The reason I ask is that it is probably not as simple as the example > > above. First, you probably need to specify a revision of the module > > to be mounted. Or a min-revision. Then probably a set of features > > that must be enabled. And so on. It turns out that there is already > > a proposal for specifying such a "conformance profile" - YANG Packages > > (see draft-bierman-netmod-yang-package). Maybe it would be better to > > re-use packages? > > We are talking schema mount, right? Yes. > So why would features matter? If you want to mount a certain module, and that module has feature-conditional subtrees, you may want to make sure that those features are supported. If these features are not specified in the schema, we need to invent some mechanism for the server to advertise them for the mounted subtree. This is the job for the inline ietf-yang-library, or /mount-points state data in the structural-mount draft. My point is that while this idea (list the module you want to be mounted) seems simple, there are some issues to solve. Hence I would like to understand the use case before suggesting a solution. > Yes, > there might be interesting versioning issues but how are they > different from an augmentation putting data under root? I naively > considered such a 'static schema defined mount' the simplest case, > then the 'augmented schema defined mount' naturally following from the > way augmentations work: > > augment /some:root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } > > The 'dynamic runtime defined mounts' may be most flexible but then > they require me to read runtime data in order to adapt to the schema > structure, which has its own set of complexities. I agree. /martin > Yes, the versioning > issues go away since I have to adapt to each implementation > dynamically but there is surely a cost involved with that as well. > > Am I missing something? > > /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 Feb 24 14:39:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C8F1A0856 for ; Wed, 24 Feb 2016 14:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 S37190FNXtgq for ; Wed, 24 Feb 2016 14:39:18 -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 6FB051A066C for ; Wed, 24 Feb 2016 14:39:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C73FF14A3; Wed, 24 Feb 2016 23:39:16 +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 1fwJpTJzCbJR; Wed, 24 Feb 2016 23:39: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; Wed, 24 Feb 2016 23:39:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 810DB20037; Wed, 24 Feb 2016 23:39:15 +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 DG1hnCoM1-nD; Wed, 24 Feb 2016 23:39:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6C3A20036; Wed, 24 Feb 2016 23:39:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C119F39FD072; Wed, 24 Feb 2016 23:39:13 +0100 (CET) Date: Wed, 24 Feb 2016 23:39:13 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160224223913.GA18519@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160224.223040.105115912610069020.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 22:39:25 -0000 On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > > > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > > > for being able to specify modules to mount directly in the schema. > > > Something like this: > > > > > > container root { > > > ymnt:mount-point "lne" { > > > ymnt:mount-module "ietf-interfaces"; > > > } > > > } > > > > > > It would be useful if the use case for this could be described in more > > > details. Is it a requirement to be able to specify this in the > > > schema, or could it be done (as Chris mentioned) in the RFC text? > > > > > > The reason I ask is that it is probably not as simple as the example > > > above. First, you probably need to specify a revision of the module > > > to be mounted. Or a min-revision. Then probably a set of features > > > that must be enabled. And so on. It turns out that there is already > > > a proposal for specifying such a "conformance profile" - YANG Packages > > > (see draft-bierman-netmod-yang-package). Maybe it would be better to > > > re-use packages? > > > > We are talking schema mount, right? > > Yes. > > > So why would features matter? > > If you want to mount a certain module, and that module has > feature-conditional subtrees, you may want to make sure that those > features are supported. If these features are not specified in the > schema, we need to invent some mechanism for the server to advertise > them for the mounted subtree. This is the job for the inline > ietf-yang-library, or /mount-points state data in the structural-mount > draft. > > My point is that while this idea (list the module you want to be > mounted) seems simple, there are some issues to solve. Hence I would > like to understand the use case before suggesting a solution. A schema in general does not explain which features an implementation of that schema supports. A static schema mount is fully consistent with that. Yes, the current YANG library may not expose features that apply to a certain mounted schema but this I do not see this as something that makes things more complicated from the schema point of view. I think the use cases are rather obvious. I build a device and I like to rearrange existing models into a beautiful hierarchy (for some definition of beauty). Or I deal with some form of virtualization and I write a bunch of nested containers and lists that express this and then I mount existing YANG models into this hierarchy. In cases like this, I know exactly which model I want to mount where at design time. In your I-D (if I got this right), you only declare mount-points in the schema and then an implementation can mount whatever it likes on a mount-point. What is the use case for this? Why is it a feature to not express in the schema at design time what can be expected behind a mount point? BTW, in your example on page 10, should device-root be logical-device ? There are likely many other questions that are largely independent of the question whether the schema is fixed in a schema at schema design time or only discoverable at runtime. (How do protocols interpret instance-identifiers crossing mount points, how do you mix chrooted and non-chrooted behaviour, what about edit-configs crossing mount points, how does this all play with NACM, etc. Nobody expected this to be easy.) Since you and Lada thought way more about this than I ever did, there may be a reason why you both propose to make this runtime data driven instead of having a piece of YANG defining how schemas are mounted together. /js > > Yes, > > there might be interesting versioning issues but how are they > > different from an augmentation putting data under root? I naively > > considered such a 'static schema defined mount' the simplest case, > > then the 'augmented schema defined mount' naturally following from the > > way augmentations work: > > > > augment /some:root { > > ymnt:mount-point "lne" { > > ymnt:mount-module "ietf-interfaces"; > > } > > } > > > > The 'dynamic runtime defined mounts' may be most flexible but then > > they require me to read runtime data in order to adapt to the schema > > structure, which has its own set of complexities. > > I agree. > > > /martin > > > > Yes, the versioning > > issues go away since I have to adapt to each implementation > > dynamically but there is surely a cost involved with that as well. > > > > Am I missing something? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 24 15:17:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1061A8728 for ; Wed, 24 Feb 2016 15:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 oBuTIkpXVsP0 for ; Wed, 24 Feb 2016 15:17:18 -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 1404D1A8737 for ; Wed, 24 Feb 2016 15:17:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF083143C; Thu, 25 Feb 2016 00:17:16 +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 Dbc7-Hni49bN; Thu, 25 Feb 2016 00:17:00 +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, 25 Feb 2016 00:17:14 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 900E62003F; Thu, 25 Feb 2016 00:17:09 +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 wCm1vavfkr95; Thu, 25 Feb 2016 00:16: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 887BA2003A; Thu, 25 Feb 2016 00:16:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7703339FD16C; Thu, 25 Feb 2016 00:16:54 +0100 (CET) Date: Thu, 25 Feb 2016 00:16:54 +0100 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20160224231654.GA18589@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Martin Bjorklund , "netmod@ietf.org" References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <1da16bd668354ca6b874ef76012c812a@XCH-RCD-001.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1da16bd668354ca6b874ef76012c812a@XCH-RCD-001.cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] explicit mount 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, 24 Feb 2016 23:17:20 -0000 On Wed, Feb 24, 2016 at 09:04:00PM +0000, Alexander Clemm (alex) wrote: > Juergen, I think you are correct. Also alias-mount and peer-mount (not just schema-mount) specify mountpoints in the schema. They are not about mounting arbitrary data in arbitrary places, but defining a model with mountpoints declared. My reading of draft-clemm-netmod-mount-03 is that you proposed: ac:mountpoint foo { ac:target "pointer-to-place-where-remote-system-information-can-be-found"; ac:subtree "/a/b/c"; } I guess you intend to mount everything below the path /a/b/c, independent of where the path ends and how many augmentations etc. are there - you mount everything in the subtree. Lada and Martin I think do not propose to mount arbitrary paths but only complete YANG modules and everything (in particular instance identifier) is interpreted 'inside' like if you did a chroot (at least this is how I understood things so far). It is not clear yet to me how 'inside' and 'outside' translate to NETCONF and RESTCONF but that is for the protocol people to figure out I guess. My understanding is that Martin can mount several YANG modules on a single mb:mount-point, your mountpoint is restricted to a single specific path. Lada does not need mount points, the stuff goes to any place the implementations likes to put it. /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 Feb 24 16:42:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770991ACE32 for ; Wed, 24 Feb 2016 16:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.307 X-Spam-Level: X-Spam-Status: No, score=-13.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 uFU_ield7VVo for ; Wed, 24 Feb 2016 16:42:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0391ACE2C for ; Wed, 24 Feb 2016 16:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2773; q=dns/txt; s=iport; t=1456360967; x=1457570567; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZepQnIQuINZpGiaHUACMO0jSvK5IIl3KN3yt4fiKPvA=; b=aiITOwxR2bbTwDS6DrpOE/Gpc2qldkwBnjDlKS3syoGX4Mymd9kECiKS VunqES5hsn5w704eNCvFDtV5wG8L7GXBOAqdd0VBjSlknJGNJhMarYgS4 4lH5l5qurdbO7X0SCJPlmIiaLpG4EREReMisTqKlKZzAhyMQsBCDCW4dX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDDTM5W/4cNJK1bA4M6Um0Gum0BD?= =?us-ascii?q?YFmHYVxAoE/OBQBAQEBAQEBZCeEQQEBAQQ6PwwCAgIBCA4CAQQBAQEeCQcbFxQ?= =?us-ascii?q?JCAIEDgUIiBe9fwEBAQEBAQEBAQEBAQEBAQEBAQEBARUEikiEVgsbg3MFlwcBj?= =?us-ascii?q?VeOe45IAR4BAUKCAxmBSGqGY30BAQE?= X-IronPort-AV: E=Sophos;i="5.22,495,1449532800"; d="scan'208";a="80323456" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2016 00:42:46 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1P0gkxw024288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2016 00:42:46 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 18:42:45 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 18:42:45 -0600 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder Thread-Topic: [netmod] explicit mount Thread-Index: AQHRbkwiGi5XXHW8ekmYwsZI6JLn0p87w3yA///smqCAAIrMAP//sArg Date: Thu, 25 Feb 2016 00:42:45 +0000 Message-ID: <54d7790a08c546c38a40e1707540e791@XCH-RCD-001.cisco.com> References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <1da16bd668354ca6b874ef76012c812a@XCH-RCD-001.cisco.com> <20160224231654.GA18589@elstar.local> In-Reply-To: <20160224231654.GA18589@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.83.62] 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] explicit mount 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, 25 Feb 2016 00:42:49 -0000 Hi Juergen, your particular example is from peer mount (i.e. remote mount). Yes, you a= re mounting everything below /a/b/c, including augmentations etc. You moun= t indeed instance information (not just a schema to instantiate just under = that mountpoint). So, I think our understanding is consistent. However, t= he mountpoint itself (foo) is part of a model. You cannot place foo dynami= cally just anywhere, attaching data/mountpoints into random points in the t= ree "after the fact", but you need a model in which you define the mountpoi= nt, using the YANG mountpoint extension - this is what I meant with regards= to defining a model with mountpoints declared. (And, while each mountpoin= t is restricted to a single path, there is nothing that would prevent you f= rom defining multiple mountpoints (each referring to a different path).) =20 --- Alex -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, February 24, 2016 3:17 PM To: Alexander Clemm (alex) Cc: Martin Bjorklund ; netmod@ietf.org Subject: Re: [netmod] explicit mount On Wed, Feb 24, 2016 at 09:04:00PM +0000, Alexander Clemm (alex) wrote: > Juergen, I think you are correct. Also alias-mount and peer-mount (not j= ust schema-mount) specify mountpoints in the schema. They are not about mo= unting arbitrary data in arbitrary places, but defining a model with mountp= oints declared. My reading of draft-clemm-netmod-mount-03 is that you proposed: ac:mountpoint foo { ac:target "pointer-to-place-where-remote-system-information-can-be-found"= ; ac:subtree "/a/b/c"; } I guess you intend to mount everything below the path /a/b/c, independent o= f where the path ends and how many augmentations etc. are there - you mount= everything in the subtree. Lada and Martin I think do not propose to mount= arbitrary paths but only complete YANG modules and everything (in particul= ar instance identifier) is interpreted 'inside' like if you did a chroot (a= t least this is how I understood things so far). It is not clear yet to me = how 'inside' and 'outside' translate to NETCONF and RESTCONF but that is for the protocol people to fi= gure out I guess. My understanding is that Martin can mount several YANG modules on a single = mb:mount-point, your mountpoint is restricted to a single specific path. La= da does not need mount points, the stuff goes to any place the implementati= ons likes to put it. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 24 16:47:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C191A007D for ; Wed, 24 Feb 2016 16:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 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_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 Jjwv9ijfdHiX for ; Wed, 24 Feb 2016 16:47:41 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4131ACD74 for ; Wed, 24 Feb 2016 16:47:40 -0800 (PST) Received: from [172.16.0.6] (chello085216168097.chello.sk [85.216.168.97]) by mail.hq.sk (Postfix) with ESMTPSA id 2AA9A243DBA; Thu, 25 Feb 2016 01:47:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1456361259; bh=DsOG+dgkhWDbj2HgBX40p157Wia7ro0wFp4oFzX3fcU=; h=Subject:To:References:From:Date:In-Reply-To; b=faIKuKKqSOPOow6ySkUM2P6RdodGlLLGuvM1K9RGX7Oq2hbWwXy3jrRv0q5+flYPG wdMse0cQovu1PPc4Z6x8Fp+T1VFSTHtpSXJl/dXUUiYjO6wGseLPCPAnRm5JeIUoPO ebKCk6X8ipmGEXNq1+9Tn3TdlfO6Xt2OH33qmIn0= To: Martin Bjorklund , netmod@ietf.org References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> From: Robert Varga Message-ID: <56CE4F2A.2020008@hq.sk> Date: Thu, 25 Feb 2016 01:47:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160224223913.GA18519@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] explicit mount 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, 25 Feb 2016 00:47:42 -0000 On 02/24/2016 11:39 PM, Juergen Schoenwaelder wrote: > In your I-D (if I got this right), you only declare mount-points in > the schema and then an implementation can mount whatever it likes on a > mount-point. What is the use case for this? Why is it a feature to not > express in the schema at design time what can be expected behind a > mount point? The use case for this is implemented in OpenDaylight, where the RESTCONF northbound exposes an ietf-network-topology (ancient draft), where each nt:node represents a network element accessible via NETCONF. Configuration and state of that network element is exposed as a mointpoint anchored at that particular node. Data exchange is mediated (and validated) by OpenDaylight. Models available are limited by the network element, OpenDaylight only interprets them at runtime (and pulls them from network element as needed). Bye, Robert From nobody Wed Feb 24 17:55:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12031B2BED for ; Wed, 24 Feb 2016 17:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 2LcuB-SiX89t for ; Wed, 24 Feb 2016 17:55:31 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5262D1B2B39 for ; Wed, 24 Feb 2016 17:55:31 -0800 (PST) Received: from tops.chopps.org (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 F19DA60918; Thu, 25 Feb 2016 01:55:29 +0000 (UTC) References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> User-agent: mu4e 0.9.17; emacs 24.5.1 From: To: Juergen Schoenwaelder In-reply-to: <20160224223913.GA18519@elstar.local> Date: Wed, 24 Feb 2016 20:54:58 -0500 Message-ID: <87a8mpv9jh.fsf@tops.chopps.org> 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] explicit mount 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, 25 Feb 2016 01:55:32 -0000 --=-=-= Content-Type: text/plain Juergen Schoenwaelder writes: > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: > In your I-D (if I got this right), you only declare mount-points in > the schema and then an implementation can mount whatever it likes on a > mount-point. What is the use case for this? Why is it a feature to not > express in the schema at design time what can be expected behind a > mount point? B/c that schema may not be written yet, or known about by the mounting model authors, etc. Think of the case we have been driving this with (i.e., a virtual router running inside a host router), in this case we want all the modules at the mount point which the virtual router has at it's root. The schema that defines this mount point (the logical-network-element schema) wouldn't pre-specify all known models, and additionally we do not want to require model authors to augment the logical-network-element schema to add their schema to it. We just want it to work, and by not restricting what can be mounted there (other than to say it mirrors the root of the LNE), it does. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWzl7yAAoJEC4dgw7XuDAl7CcP+weejhreJhhruuOrqWS7pD8r 7NKcM+9TYYrovaprPOnmnqJ0BZhvZFhydLCaL63HUpWYHcFI6iaqaVZbDnI8eCv/ BwY6ePfSss/bMN/ZZswu5cKwAjbuv8RZbKjI6MKcWWQ0LD1QcNK529mGdHuP0Tg4 +YD7cRt9nHnNWuU1YgnBRasWb/+tKrXt2OgIILoVCspZGm2+LcbwNGjnW1seIVwf 5E5F1Q0XTRKN3BrTLHxpDBW1edskNLkno2rinGmi9Nr20hKJPuPSGXQy8QFBGjMX dmh12tOv7qrxdHsqUnVMHA215/HFcfM/I7DOGnsu6AZhzLAtrd8/PgQEFDT8cvQY GKmebt99EbSrENFPYzXPaEUCtcIiXN9sosHKExpH+Z+u9L+N+rsZtGOKaUzzmace lgJptoOo1466d/WrXSiduDZs36BPz95XKJWj7NMfMog8q4dJnJ3L4nWba6AxZ25s yhE6bfDhC3J65VtOU52Dbnsc1HVe8FpHS6qvL4GugC8x7305BacLANAjO2ez9Cyq A0gGdr/aPNLEL5Wxot4pV1jSabxOHLlxp3CfAuvwE5i+1Ms5S4NWD6PO4CQRatkH Rc+V2dU9VVInZQFJvJwCHP+C+LVOpy1+todQv3gqLIhhd8rdCO87ofzJeTru1wIY Ys5KSgSsvp+lBYzy0N0B =AIPl -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 24 23:34:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1BE1A03AA for ; Wed, 24 Feb 2016 23:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 kLOpzs8jEtm7 for ; Wed, 24 Feb 2016 23:34:03 -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 F09CC1A044F for ; Wed, 24 Feb 2016 23:34:01 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id F057718187E; Thu, 25 Feb 2016 08:33:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456385640; bh=LWjc0+SvcJ1Bvz6OrdxnnCm+toCKxXHLubeeFybJkxo=; h=From:Date:To; b=LCOeXoL319pJm4WGS4F8tT8YlyUfumNMfrsRr3IY9a6S84d+D2lwwOkkffPD2dDep aOMcgShnjTM8gx6jixd6ef9WTibWwFc7AZFBsDdV0dWKkDDNy9v/4Jh8Dg9mewRsq7 w4rbQudc3qqhT0lawtNEFoj4IguyDZ8RM9KTmIVY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160224223913.GA18519@elstar.local> Date: Thu, 25 Feb 2016 08:34:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96C185F2-2A98-4167-93E8-F090B0DA31FD@nic.cz> References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@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] explicit mount 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, 25 Feb 2016 07:34:10 -0000 > On 24 Feb 2016, at 23:39, Juergen Schoenwaelder = wrote: >=20 > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: >>>> Hi, >>>>=20 >>>> In yesterday's meeting, Lou (I think?) mentioned a use case for = mount >>>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the = need >>>> for being able to specify modules to mount directly in the schema. >>>> Something like this: >>>>=20 >>>> container root { >>>> ymnt:mount-point "lne" { >>>> ymnt:mount-module "ietf-interfaces"; >>>> } >>>> } >>>>=20 >>>> It would be useful if the use case for this could be described in = more >>>> details. Is it a requirement to be able to specify this in the >>>> schema, or could it be done (as Chris mentioned) in the RFC text? >>>>=20 >>>> The reason I ask is that it is probably not as simple as the = example >>>> above. First, you probably need to specify a revision of the = module >>>> to be mounted. Or a min-revision. Then probably a set of features >>>> that must be enabled. And so on. It turns out that there is = already >>>> a proposal for specifying such a "conformance profile" - YANG = Packages >>>> (see draft-bierman-netmod-yang-package). Maybe it would be better = to >>>> re-use packages? >>>=20 >>> We are talking schema mount, right? >>=20 >> Yes. >>=20 >>> So why would features matter? >>=20 >> If you want to mount a certain module, and that module has >> feature-conditional subtrees, you may want to make sure that those >> features are supported. If these features are not specified in the >> schema, we need to invent some mechanism for the server to advertise >> them for the mounted subtree. This is the job for the inline >> ietf-yang-library, or /mount-points state data in the = structural-mount >> draft. >>=20 >> My point is that while this idea (list the module you want to be >> mounted) seems simple, there are some issues to solve. Hence I would >> like to understand the use case before suggesting a solution. >=20 > A schema in general does not explain which features an implementation > of that schema supports. A static schema mount is fully consistent > with that. >=20 > Yes, the current YANG library may not expose features that apply to a > certain mounted schema but this I do not see this as something that > makes things more complicated from the schema point of view. >=20 > I think the use cases are rather obvious. I build a device and I like > to rearrange existing models into a beautiful hierarchy (for some > definition of beauty). Or I deal with some form of virtualization and > I write a bunch of nested containers and lists that express this and > then I mount existing YANG models into this hierarchy. In cases like > this, I know exactly which model I want to mount where at design time. >=20 > In your I-D (if I got this right), you only declare mount-points in > the schema and then an implementation can mount whatever it likes on a > mount-point. What is the use case for this? Why is it a feature to not > express in the schema at design time what can be expected behind a > mount point? >=20 > BTW, in your example on page 10, should >=20 > device-root > be > logical-device >=20 > ? >=20 > There are likely many other questions that are largely independent of > the question whether the schema is fixed in a schema at schema design > time or only discoverable at runtime. (How do protocols interpret > instance-identifiers crossing mount points, how do you mix chrooted > and non-chrooted behaviour, what about edit-configs crossing mount > points, how does this all play with NACM, etc. Nobody expected this to > be easy.) >=20 > Since you and Lada thought way more about this than I ever did, there > may be a reason why you both propose to make this runtime data driven > instead of having a piece of YANG defining how schemas are mounted > together. Three reasons: 1. I wanted a mechanism that requires no change in YANG (and, as I said, = using an extension for this is taboo for me). 2. It is more flexible: modules can be combined in different ways, and = using the same "mounting" module with different sets of mounted modules = would require different versions of the mounting module. I guess the = motivation is similar as for NVDL: = http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compou= nd.html 3. This mechanism seems incompatible with groupings, or at least I = cannot imagine how such a mount could be handled inside a grouping. BTW, the last item also applies to Martin's mount-point extension: if it = appears inside a grouping, then the same mount point may end up in = different places and the whole concept breaks down. Lada >=20 > /js >=20 >>> Yes, >>> there might be interesting versioning issues but how are they >>> different from an augmentation putting data under root? I naively >>> considered such a 'static schema defined mount' the simplest case, >>> then the 'augmented schema defined mount' naturally following from = the >>> way augmentations work: >>>=20 >>> augment /some:root { >>> ymnt:mount-point "lne" { >>> ymnt:mount-module "ietf-interfaces"; >>> } >>> } >>>=20 >>> The 'dynamic runtime defined mounts' may be most flexible but then >>> they require me to read runtime data in order to adapt to the schema >>> structure, which has its own set of complexities. >>=20 >> I agree. >>=20 >>=20 >> /martin >>=20 >>=20 >>> Yes, the versioning >>> issues go away since I have to adapt to each implementation >>> dynamically but there is surely a cost involved with that as well. >>>=20 >>> Am I missing something? >>>=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 > --=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 Feb 25 00:00:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0DF1A00A5 for ; Thu, 25 Feb 2016 00:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 A2oXiaf1e0QH for ; Thu, 25 Feb 2016 00:00:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91CD71A1BE9 for ; Thu, 25 Feb 2016 00:00:51 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id A8B001AE0335; Thu, 25 Feb 2016 09:00:49 +0100 (CET) Date: Thu, 25 Feb 2016 09:00:54 +0100 (CET) Message-Id: <20160225.090054.381856038663521339.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <96C185F2-2A98-4167-93E8-F090B0DA31FD@nic.cz> References: <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> <96C185F2-2A98-4167-93E8-F090B0DA31FD@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] explicit mount 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, 25 Feb 2016 08:00:55 -0000 Ladislav Lhotka wrote: > > > On 24 Feb 2016, at 23:39, Juergen Schoenwaelder wrote: > > > > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: > >>> On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > >>>> Hi, > >>>> > >>>> In yesterday's meeting, Lou (I think?) mentioned a use case for mount > >>>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > >>>> for being able to specify modules to mount directly in the schema. > >>>> Something like this: > >>>> > >>>> container root { > >>>> ymnt:mount-point "lne" { > >>>> ymnt:mount-module "ietf-interfaces"; > >>>> } > >>>> } > >>>> > >>>> It would be useful if the use case for this could be described in more > >>>> details. Is it a requirement to be able to specify this in the > >>>> schema, or could it be done (as Chris mentioned) in the RFC text? > >>>> > >>>> The reason I ask is that it is probably not as simple as the example > >>>> above. First, you probably need to specify a revision of the module > >>>> to be mounted. Or a min-revision. Then probably a set of features > >>>> that must be enabled. And so on. It turns out that there is already > >>>> a proposal for specifying such a "conformance profile" - YANG Packages > >>>> (see draft-bierman-netmod-yang-package). Maybe it would be better to > >>>> re-use packages? > >>> > >>> We are talking schema mount, right? > >> > >> Yes. > >> > >>> So why would features matter? > >> > >> If you want to mount a certain module, and that module has > >> feature-conditional subtrees, you may want to make sure that those > >> features are supported. If these features are not specified in the > >> schema, we need to invent some mechanism for the server to advertise > >> them for the mounted subtree. This is the job for the inline > >> ietf-yang-library, or /mount-points state data in the structural-mount > >> draft. > >> > >> My point is that while this idea (list the module you want to be > >> mounted) seems simple, there are some issues to solve. Hence I would > >> like to understand the use case before suggesting a solution. > > > > A schema in general does not explain which features an implementation > > of that schema supports. A static schema mount is fully consistent > > with that. > > > > Yes, the current YANG library may not expose features that apply to a > > certain mounted schema but this I do not see this as something that > > makes things more complicated from the schema point of view. > > > > I think the use cases are rather obvious. I build a device and I like > > to rearrange existing models into a beautiful hierarchy (for some > > definition of beauty). Or I deal with some form of virtualization and > > I write a bunch of nested containers and lists that express this and > > then I mount existing YANG models into this hierarchy. In cases like > > this, I know exactly which model I want to mount where at design time. > > > > In your I-D (if I got this right), you only declare mount-points in > > the schema and then an implementation can mount whatever it likes on a > > mount-point. What is the use case for this? Why is it a feature to not > > express in the schema at design time what can be expected behind a > > mount point? > > > > BTW, in your example on page 10, should > > > > device-root > > be > > logical-device > > > > ? > > > > There are likely many other questions that are largely independent of > > the question whether the schema is fixed in a schema at schema design > > time or only discoverable at runtime. (How do protocols interpret > > instance-identifiers crossing mount points, how do you mix chrooted > > and non-chrooted behaviour, what about edit-configs crossing mount > > points, how does this all play with NACM, etc. Nobody expected this to > > be easy.) > > > > Since you and Lada thought way more about this than I ever did, there > > may be a reason why you both propose to make this runtime data driven > > instead of having a piece of YANG defining how schemas are mounted > > together. > > Three reasons: > > 1. I wanted a mechanism that requires no change in YANG (and, as I > said, using an extension for this is taboo for me). But *not* using an extension is as bad for the poor client as having an extension it just ignores! In both cases the old client sees a normal data model, and in both cases the data model is in fact extended via mount. > 2. It is more flexible: modules can be combined in different ways, Agreed. > and using the same "mounting" module with different sets of mounted > modules would require different versions of the mounting module. I don't understand what you try to say here. > I > guess the motivation is similar as for NVDL: > > http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compound.html > > 3. This mechanism seems incompatible with groupings, or at least I > cannot imagine how such a mount could be handled inside a grouping. > > BTW, the last item also applies to Martin's mount-point extension: > if it appears inside a grouping, then the same mount point may end > up in different places and the whole concept breaks down. If a mount-point is defined in a grouping, that grouping can only be used once in a module. The mount-point name gets bound to the module that uses the grouping. I will clarify this in my draft. /martin > > Lada > > > > > /js > > > >>> Yes, > >>> there might be interesting versioning issues but how are they > >>> different from an augmentation putting data under root? I naively > >>> considered such a 'static schema defined mount' the simplest case, > >>> then the 'augmented schema defined mount' naturally following from the > >>> way augmentations work: > >>> > >>> augment /some:root { > >>> ymnt:mount-point "lne" { > >>> ymnt:mount-module "ietf-interfaces"; > >>> } > >>> } > >>> > >>> The 'dynamic runtime defined mounts' may be most flexible but then > >>> they require me to read runtime data in order to adapt to the schema > >>> structure, which has its own set of complexities. > >> > >> I agree. > >> > >> > >> /martin > >> > >> > >>> Yes, the versioning > >>> issues go away since I have to adapt to each implementation > >>> dynamically but there is surely a cost involved with that as well. > >>> > >>> Am I missing something? > >>> > >>> /js > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 > >>> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Feb 25 00:23:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7901A6EE6 for ; Thu, 25 Feb 2016 00:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 XBD-aTJjGiSS for ; Thu, 25 Feb 2016 00:23: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 E56131A01A2 for ; Thu, 25 Feb 2016 00:23:53 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A6FA1AE0335; Thu, 25 Feb 2016 09:23:52 +0100 (CET) Date: Thu, 25 Feb 2016 09:23:57 +0100 (CET) Message-Id: <20160225.092357.799424283049856775.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160224223913.GA18519@elstar.local> References: <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@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] explicit mount 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, 25 Feb 2016 08:23:57 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > > > > Hi, > > > > > > > > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > > > > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > > > > for being able to specify modules to mount directly in the schema. > > > > Something like this: > > > > > > > > container root { > > > > ymnt:mount-point "lne" { > > > > ymnt:mount-module "ietf-interfaces"; > > > > } > > > > } > > > > > > > > It would be useful if the use case for this could be described in more > > > > details. Is it a requirement to be able to specify this in the > > > > schema, or could it be done (as Chris mentioned) in the RFC text? > > > > > > > > The reason I ask is that it is probably not as simple as the example > > > > above. First, you probably need to specify a revision of the module > > > > to be mounted. Or a min-revision. Then probably a set of features > > > > that must be enabled. And so on. It turns out that there is already > > > > a proposal for specifying such a "conformance profile" - YANG Packages > > > > (see draft-bierman-netmod-yang-package). Maybe it would be better to > > > > re-use packages? > > > > > > We are talking schema mount, right? > > > > Yes. > > > > > So why would features matter? > > > > If you want to mount a certain module, and that module has > > feature-conditional subtrees, you may want to make sure that those > > features are supported. If these features are not specified in the > > schema, we need to invent some mechanism for the server to advertise > > them for the mounted subtree. This is the job for the inline > > ietf-yang-library, or /mount-points state data in the structural-mount > > draft. > > > > My point is that while this idea (list the module you want to be > > mounted) seems simple, there are some issues to solve. Hence I would > > like to understand the use case before suggesting a solution. > > A schema in general does not explain which features an implementation > of that schema supports. A static schema mount is fully consistent > with that. > > Yes, the current YANG library may not expose features that apply to a > certain mounted schema but this I do not see this as something that > makes things more complicated from the schema point of view. > > I think the use cases are rather obvious. I build a device and I like > to rearrange existing models into a beautiful hierarchy (for some > definition of beauty). This would be pretty complicated. Suppose I define my own beautiful structure like this: container my-interfaces { x:mount-point "if" { x:mount-module "ietf-interfaces"; } } container my-routing { x:mount-point "rtr" { x:mount-module "ietf-routing"; } } Note that with the mount-point defined in my draft, each mount-point becomes itw own "jailed" or "chrooted" tree. So references cannot cross mount points. In this case, we have references between ietf-routing and ietf-interfaces. How would they work? What happens with the references if I do: container my-interfaces1 { x:mount-point "if1" { x:mount-module "ietf-interfaces"; } } container my-interfaces2 { x:mount-point "if2" { x:mount-module "ietf-interfaces"; } } container my-routing { x:mount-point "rtr" { x:mount-module "ietf-routing"; } } > Or I deal with some form of virtualization and > I write a bunch of nested containers and lists that express this and > then I mount existing YANG models into this hierarchy. In cases like > this, I know exactly which model I want to mount where at design > time. This is the logical device use case - Chris replied to this. > In your I-D (if I got this right), you only declare mount-points in > the schema and then an implementation can mount whatever it likes on a > mount-point. What is the use case for this? Why is it a feature to not > express in the schema at design time what can be expected behind a > mount point? See above. Another use case is what we are using in our NCS software, and ODL is using - a manager/controller/orchestrator that mounts the data models of the devices it manages/controls/orchestrates. These models are not known at design time. > BTW, in your example on page 10, should > > device-root > be > logical-device > > ? Yes. > There are likely many other questions that are largely independent of > the question whether the schema is fixed in a schema at schema design > time or only discoverable at runtime. (How do protocols interpret > instance-identifiers crossing mount points, how do you mix chrooted > and non-chrooted behaviour, what about edit-configs crossing mount > points, how does this all play with NACM, etc. Nobody expected this to > be easy.) Well, I think that the current mount-point w/ a chrooted behaviour simplifies this a lot. > Since you and Lada thought way more about this than I ever did, there > may be a reason why you both propose to make this runtime data driven > instead of having a piece of YANG defining how schemas are mounted > together. Hopefully this is clear now from the use cases we have presented. /martin > > /js > > > > Yes, > > > there might be interesting versioning issues but how are they > > > different from an augmentation putting data under root? I naively > > > considered such a 'static schema defined mount' the simplest case, > > > then the 'augmented schema defined mount' naturally following from the > > > way augmentations work: > > > > > > augment /some:root { > > > ymnt:mount-point "lne" { > > > ymnt:mount-module "ietf-interfaces"; > > > } > > > } > > > > > > The 'dynamic runtime defined mounts' may be most flexible but then > > > they require me to read runtime data in order to adapt to the schema > > > structure, which has its own set of complexities. > > > > I agree. > > > > > > /martin > > > > > > > Yes, the versioning > > > issues go away since I have to adapt to each implementation > > > dynamically but there is surely a cost involved with that as well. > > > > > > Am I missing something? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > From nobody Thu Feb 25 00:24:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070631A1B7C for ; Thu, 25 Feb 2016 00:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 8LTzZxoWlGI5 for ; Thu, 25 Feb 2016 00:24: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 215E81A1A5A for ; Thu, 25 Feb 2016 00:24:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 71C631455; Thu, 25 Feb 2016 09:24:20 +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 csUIOngZ1a6t; Thu, 25 Feb 2016 09:24: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; Thu, 25 Feb 2016 09:24:19 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCB8120037; Thu, 25 Feb 2016 09:24:19 +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 FHTtMFuU6rtt; Thu, 25 Feb 2016 09:24: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 C446620036; Thu, 25 Feb 2016 09:24:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A7EBA39FD702; Thu, 25 Feb 2016 09:24:17 +0100 (CET) Date: Thu, 25 Feb 2016 09:24:17 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160225082417.GA19366@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> <96C185F2-2A98-4167-93E8-F090B0DA31FD@nic.cz> <20160225.090054.381856038663521339.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225.090054.381856038663521339.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 25 Feb 2016 08:24:25 -0000 On Thu, Feb 25, 2016 at 09:00:54AM +0100, Martin Bjorklund wrote: > > > > 3. This mechanism seems incompatible with groupings, or at least I > > cannot imagine how such a mount could be handled inside a grouping. > > > > BTW, the last item also applies to Martin's mount-point extension: > > if it appears inside a grouping, then the same mount point may end > > up in different places and the whole concept breaks down. > > If a mount-point is defined in a grouping, that grouping can only be > used once in a module. The mount-point name gets bound to the module > that uses the grouping. I will clarify this in my draft. > Thats odd, no? An extension statement (which may be ignored) causes a constraint on a grouping so that it can only be used once? Why not refer to the mount point by path to avoid this? /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 Feb 25 00:32:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE6E1A1AD9 for ; Thu, 25 Feb 2016 00:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 Bs1R11RYO12y for ; Thu, 25 Feb 2016 00:32: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 3E7631A19E5 for ; Thu, 25 Feb 2016 00:32: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 0DF6F18F9; Thu, 25 Feb 2016 09:32: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 ztDc7V54Lxp9; Thu, 25 Feb 2016 09:32: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; Thu, 25 Feb 2016 09:32:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 343AF20038; Thu, 25 Feb 2016 09:32:30 +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 tcrsrx4EiDy4; Thu, 25 Feb 2016 09:32: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 6C66020037; Thu, 25 Feb 2016 09:32:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 591D239FD756; Thu, 25 Feb 2016 09:32:28 +0100 (CET) Date: Thu, 25 Feb 2016 09:32:28 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160225083228.GB19366@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160224160933.GA17873@elstar.local> <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> <20160225.092357.799424283049856775.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225.092357.799424283049856775.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 25 Feb 2016 08:32:34 -0000 On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > I think the use cases are rather obvious. I build a device and I like > > to rearrange existing models into a beautiful hierarchy (for some > > definition of beauty). > > This would be pretty complicated. Suppose I define my own beautiful > structure like this: > > container my-interfaces { > x:mount-point "if" { > x:mount-module "ietf-interfaces"; > } > } > container my-routing { > x:mount-point "rtr" { > x:mount-module "ietf-routing"; > } > } > > Note that with the mount-point defined in my draft, each mount-point > becomes itw own "jailed" or "chrooted" tree. So references cannot > cross mount points. Could be the same here. > In this case, we have references between ietf-routing and > ietf-interfaces. How would they work? How do they work in your solution? If interfaces is jailed and routing is jailed, how does routing refer to the interfaces? > What happens with the references if I do: > > container my-interfaces1 { > x:mount-point "if1" { > x:mount-module "ietf-interfaces"; > } > } > container my-interfaces2 { > x:mount-point "if2" { > x:mount-module "ietf-interfaces"; > } > } > container my-routing { > x:mount-point "rtr" { > x:mount-module "ietf-routing"; > } > } Why is this any different in yours or Lada's solution? The question what is accessible to whom is I think independent from the question whether the schema mounted at a mount point is fixed in a schema or described at runtime only, no? /js PS: I am asking these maybe stupid questions just in an attempt to understand the designs on the table. I have no opinion about what the 'right' solution is yet. -- 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 Feb 25 00:34:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC23C1A19E5 for ; Thu, 25 Feb 2016 00:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 fw2SMfUz8Bge for ; Thu, 25 Feb 2016 00:34:05 -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 0DF041A01A1 for ; Thu, 25 Feb 2016 00:34:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 794C5181BF3; Thu, 25 Feb 2016 09:34:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456389243; bh=FBEoUE1QKEADZ1/4hi/tHA5NMHQRdrK56cFBpOWg9gI=; h=From:Date:To; b=s9nkeFwDcxphedRIPaVNutk7/Njmj4BdWM50smz1Vvsd14CfFb2fFq/DHMmRZHQ+U qi/red+PQ+2DvTKt8lv+Wyh7f9OJDlBVYWMKtUCD2ZiL7ZvGMmZm9JnNXHpuEO0LZL td9i+52XMibcnnwkKZQSZmKoXfHX5lqh7fwjQ53I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225.090054.381856038663521339.mbj@tail-f.com> Date: Thu, 25 Feb 2016 09:34:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E015815-33EE-4B44-A7E6-01BFEC4E7D55@nic.cz> References: <20160224.223040.105115912610069020.mbj@tail-f.com> <20160224223913.GA18519@elstar.local> <96C185F2-2A98-4167-93E8-F090B0DA31FD@nic.cz> <20160225.090054.381856038663521339.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] explicit mount 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, 25 Feb 2016 08:34:08 -0000 > On 25 Feb 2016, at 09:00, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 24 Feb 2016, at 23:39, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: >>>>>> Hi, >>>>>>=20 >>>>>> In yesterday's meeting, Lou (I think?) mentioned a use case for = mount >>>>>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the = need >>>>>> for being able to specify modules to mount directly in the = schema. >>>>>> Something like this: >>>>>>=20 >>>>>> container root { >>>>>> ymnt:mount-point "lne" { >>>>>> ymnt:mount-module "ietf-interfaces"; >>>>>> } >>>>>> } >>>>>>=20 >>>>>> It would be useful if the use case for this could be described in = more >>>>>> details. Is it a requirement to be able to specify this in the >>>>>> schema, or could it be done (as Chris mentioned) in the RFC text? >>>>>>=20 >>>>>> The reason I ask is that it is probably not as simple as the = example >>>>>> above. First, you probably need to specify a revision of the = module >>>>>> to be mounted. Or a min-revision. Then probably a set of = features >>>>>> that must be enabled. And so on. It turns out that there is = already >>>>>> a proposal for specifying such a "conformance profile" - YANG = Packages >>>>>> (see draft-bierman-netmod-yang-package). Maybe it would be = better to >>>>>> re-use packages? >>>>>=20 >>>>> We are talking schema mount, right? >>>>=20 >>>> Yes. >>>>=20 >>>>> So why would features matter? >>>>=20 >>>> If you want to mount a certain module, and that module has >>>> feature-conditional subtrees, you may want to make sure that those >>>> features are supported. If these features are not specified in the >>>> schema, we need to invent some mechanism for the server to = advertise >>>> them for the mounted subtree. This is the job for the inline >>>> ietf-yang-library, or /mount-points state data in the = structural-mount >>>> draft. >>>>=20 >>>> My point is that while this idea (list the module you want to be >>>> mounted) seems simple, there are some issues to solve. Hence I = would >>>> like to understand the use case before suggesting a solution. >>>=20 >>> A schema in general does not explain which features an = implementation >>> of that schema supports. A static schema mount is fully consistent >>> with that. >>>=20 >>> Yes, the current YANG library may not expose features that apply to = a >>> certain mounted schema but this I do not see this as something that >>> makes things more complicated from the schema point of view. >>>=20 >>> I think the use cases are rather obvious. I build a device and I = like >>> to rearrange existing models into a beautiful hierarchy (for some >>> definition of beauty). Or I deal with some form of virtualization = and >>> I write a bunch of nested containers and lists that express this and >>> then I mount existing YANG models into this hierarchy. In cases like >>> this, I know exactly which model I want to mount where at design = time. >>>=20 >>> In your I-D (if I got this right), you only declare mount-points in >>> the schema and then an implementation can mount whatever it likes on = a >>> mount-point. What is the use case for this? Why is it a feature to = not >>> express in the schema at design time what can be expected behind a >>> mount point? >>>=20 >>> BTW, in your example on page 10, should >>>=20 >>> device-root >>> be >>> logical-device >>>=20 >>> ? >>>=20 >>> There are likely many other questions that are largely independent = of >>> the question whether the schema is fixed in a schema at schema = design >>> time or only discoverable at runtime. (How do protocols interpret >>> instance-identifiers crossing mount points, how do you mix chrooted >>> and non-chrooted behaviour, what about edit-configs crossing mount >>> points, how does this all play with NACM, etc. Nobody expected this = to >>> be easy.) >>>=20 >>> Since you and Lada thought way more about this than I ever did, = there >>> may be a reason why you both propose to make this runtime data = driven >>> instead of having a piece of YANG defining how schemas are mounted >>> together. >>=20 >> Three reasons: >>=20 >> 1. I wanted a mechanism that requires no change in YANG (and, as I >> said, using an extension for this is taboo for me). >=20 > But *not* using an extension is as bad for the poor client as having > an extension it just ignores! In both cases the old client sees a > normal data model, and in both cases the data model is in fact > extended via mount. The wording in 6020bis also allows a *server* to ignore extensions. So = both the client and server could just guess what extensions the other = party supports. As you now, I have never been a friend of the excessive care of old = clients (at this stage of YANG development, at least), but it is really = funny to have sec. 11 in 6020bis and, at the same time, permit = extensions that fundamentally change how YANG works. Optional extensions are OK for a protocol but not so much for a schema = language. >=20 >> 2. It is more flexible: modules can be combined in different ways, >=20 > Agreed. >=20 >> and using the same "mounting" module with different sets of mounted >> modules would require different versions of the mounting module. >=20 > I don't understand what you try to say here. Imagine that ietf-interfaces mounts trees for different technologies = instead of waiting for augments. Then every revision would support a = fixed set of technologies, and every new technology would require = ietf-interfaces to be updated. >=20 >> I >> guess the motivation is similar as for NVDL:=20 >>=20 >> = http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compou= nd.html >>=20 >> 3. This mechanism seems incompatible with groupings, or at least I >> cannot imagine how such a mount could be handled inside a grouping. >>=20 >> BTW, the last item also applies to Martin's mount-point extension: >> if it appears inside a grouping, then the same mount point may end >> up in different places and the whole concept breaks down. >=20 > If a mount-point is defined in a grouping, that grouping can only be > used once in a module. The mount-point name gets bound to the module > that uses the grouping. I will clarify this in my draft. Well, CLRs=E2=80=A6 But there are actually use cases where you might = want to add stuff to multiple instances of a node defined in a grouping, = for example: grouping foo-common { ... } container foo { uses foo-common; ... } container foo-state { config false; uses foo-common; ... } Then somebody may want to add (different) subtrees to both instances of = a node that's defined inside foo-common. With YSDL it's trivial. Lada >=20 >=20 > /martin >=20 >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> /js >>>=20 >>>>> Yes, >>>>> there might be interesting versioning issues but how are they >>>>> different from an augmentation putting data under root? I naively >>>>> considered such a 'static schema defined mount' the simplest case, >>>>> then the 'augmented schema defined mount' naturally following from = the >>>>> way augmentations work: >>>>>=20 >>>>> augment /some:root { >>>>> ymnt:mount-point "lne" { >>>>> ymnt:mount-module "ietf-interfaces"; >>>>> } >>>>> } >>>>>=20 >>>>> The 'dynamic runtime defined mounts' may be most flexible but then >>>>> they require me to read runtime data in order to adapt to the = schema >>>>> structure, which has its own set of complexities. >>>>=20 >>>> I agree. >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>> Yes, the versioning >>>>> issues go away since I have to adapt to each implementation >>>>> dynamically but there is surely a cost involved with that as well. >>>>>=20 >>>>> Am I missing something? >>>>>=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 >>> --=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 00:43:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4D1A6F52 for ; Thu, 25 Feb 2016 00:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 HfkqZld7qcTx for ; Thu, 25 Feb 2016 00:43:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4E1A6F59 for ; Thu, 25 Feb 2016 00:43:31 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 0ECAF1AE0335; Thu, 25 Feb 2016 09:43:30 +0100 (CET) Date: Thu, 25 Feb 2016 09:43:34 +0100 (CET) Message-Id: <20160225.094334.1498092398680350689.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160225083228.GB19366@elstar.local> References: <20160224223913.GA18519@elstar.local> <20160225.092357.799424283049856775.mbj@tail-f.com> <20160225083228.GB19366@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] explicit mount 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, 25 Feb 2016 08:43:35 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > > > I think the use cases are rather obvious. I build a device and I like > > > to rearrange existing models into a beautiful hierarchy (for some > > > definition of beauty). > > > > This would be pretty complicated. Suppose I define my own beautiful > > structure like this: > > > > container my-interfaces { > > x:mount-point "if" { > > x:mount-module "ietf-interfaces"; > > } > > } > > container my-routing { > > x:mount-point "rtr" { > > x:mount-module "ietf-routing"; > > } > > } > > > > Note that with the mount-point defined in my draft, each mount-point > > becomes itw own "jailed" or "chrooted" tree. So references cannot > > cross mount points. > > Could be the same here. > > > In this case, we have references between ietf-routing and > > ietf-interfaces. How would they work? > > How do they work in your solution? If interfaces is jailed and routing > is jailed, how does routing refer to the interfaces? My solution does not support "name module mount". It only supports mouting of a "complete" set of modules (that are chrooted) - simply because this is what we understand, have implemented, and have been running for the last ~5 years. (The same goes for ODL, I believe). [Side note: we do have experience with something similar to alias mount. we called it "symlink", and it was a huge mistake; specifially related to the non-chrooted behaviour, when references in the symlink target model could point out of the symlinked subtree.] /martin > > What happens with the references if I do: > > > > container my-interfaces1 { > > x:mount-point "if1" { > > x:mount-module "ietf-interfaces"; > > } > > } > > container my-interfaces2 { > > x:mount-point "if2" { > > x:mount-module "ietf-interfaces"; > > } > > } > > container my-routing { > > x:mount-point "rtr" { > > x:mount-module "ietf-routing"; > > } > > } > > Why is this any different in yours or Lada's solution? The question > what is accessible to whom is I think independent from the question > whether the schema mounted at a mount point is fixed in a schema or > described at runtime only, no? > > /js > > PS: I am asking these maybe stupid questions just in an attempt to > understand the designs on the table. I have no opinion about what > the 'right' solution is yet. > > -- > 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 Feb 25 01:05:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EC41A8720 for ; Thu, 25 Feb 2016 01:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 EM9sfjjPez1f for ; Thu, 25 Feb 2016 01:05:50 -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 CEABF1A8547 for ; Thu, 25 Feb 2016 01:05:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9FB0D1928; Thu, 25 Feb 2016 10:05:48 +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 J4TXr_TG7FOY; Thu, 25 Feb 2016 10:05: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, 25 Feb 2016 10:05:47 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA7402002C; Thu, 25 Feb 2016 10:05:47 +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 Rr36iDAI2-I5; Thu, 25 Feb 2016 10:05:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95ACD20038; Thu, 25 Feb 2016 10:05:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F18539FD86E; Thu, 25 Feb 2016 10:05:46 +0100 (CET) Date: Thu, 25 Feb 2016 10:05:46 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160225090546.GA19551@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160224223913.GA18519@elstar.local> <20160225.092357.799424283049856775.mbj@tail-f.com> <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225.094334.1498092398680350689.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 25 Feb 2016 09:05:56 -0000 On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > > > > > I think the use cases are rather obvious. I build a device and I like > > > > to rearrange existing models into a beautiful hierarchy (for some > > > > definition of beauty). > > > > > > This would be pretty complicated. Suppose I define my own beautiful > > > structure like this: > > > > > > container my-interfaces { > > > x:mount-point "if" { > > > x:mount-module "ietf-interfaces"; > > > } > > > } > > > container my-routing { > > > x:mount-point "rtr" { > > > x:mount-module "ietf-routing"; > > > } > > > } > > > > > > Note that with the mount-point defined in my draft, each mount-point > > > becomes itw own "jailed" or "chrooted" tree. So references cannot > > > cross mount points. > > > > Could be the same here. > > > > > In this case, we have references between ietf-routing and > > > ietf-interfaces. How would they work? > > > > How do they work in your solution? If interfaces is jailed and routing > > is jailed, how does routing refer to the interfaces? > > My solution does not support "name module mount". It only supports > mouting of a "complete" set of modules (that are chrooted) - simply > because this is what we understand, have implemented, and have been > running for the last ~5 years. (The same goes for ODL, I believe). OK. I understand now that the whole set of modules on a mount point form one chroot environment. This was not clear to me yet but of course makes a lot of sense. So a static schema mount would have to define a set of modules and not just a single module to lead to the same chrooted behavior. /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 Feb 25 01:08:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0F41A8793 for ; Thu, 25 Feb 2016 01:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 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, RP_MATCHES_RCVD=-0.006] 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 hw4ZLZ2aeejC for ; Thu, 25 Feb 2016 01:08: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 7B03A1A87BA for ; Thu, 25 Feb 2016 01:07:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 1D31C181897; Thu, 25 Feb 2016 10:07:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456391266; bh=dRpjELaXkAebun78r4d9DkugY34Uji1BTSjKoM5OLIo=; h=From:Date:To; b=TNZxGl/z7GuAxphXbDlUPr6MP1+vD9KIrrmZDLJumUqVIrOOgUv6VIupIkPsOYDs4 2P0SWqP7QXCG1A2r9wWmcQXLTyKr/ra9z2FLlyjJnK9a75LFCY4B+lX7atssLtIZkt CaTBTgLdZcYfO8iURlSlq1sUbw4Qz/PHEFuNJv1o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225090546.GA19551@elstar.local> Date: Thu, 25 Feb 2016 10:07:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160224223913.GA18519@elstar.local> <20160225.092357.799424283049856775.mbj@tail-f.com> <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <20160225090546.GA19551@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] explicit mount 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, 25 Feb 2016 09:08:16 -0000 > On 25 Feb 2016, at 10:05, Juergen Schoenwaelder = wrote: >=20 > On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>=20 >>>>> I think the use cases are rather obvious. I build a device and I = like >>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>> definition of beauty). >>>>=20 >>>> This would be pretty complicated. Suppose I define my own = beautiful >>>> structure like this: >>>>=20 >>>> container my-interfaces { >>>> x:mount-point "if" { >>>> x:mount-module "ietf-interfaces"; >>>> } >>>> } >>>> container my-routing { >>>> x:mount-point "rtr" { >>>> x:mount-module "ietf-routing"; >>>> } >>>> } >>>>=20 >>>> Note that with the mount-point defined in my draft, each = mount-point >>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>> cross mount points. >>>=20 >>> Could be the same here. >>>=20 >>>> In this case, we have references between ietf-routing and >>>> ietf-interfaces. How would they work? >>>=20 >>> How do they work in your solution? If interfaces is jailed and = routing >>> is jailed, how does routing refer to the interfaces? >>=20 >> My solution does not support "name module mount". It only supports >> mouting of a "complete" set of modules (that are chrooted) - simply >> because this is what we understand, have implemented, and have been >> running for the last ~5 years. (The same goes for ODL, I believe). >=20 > OK. I understand now that the whole set of modules on a mount point > form one chroot environment. This was not clear to me yet but of > course makes a lot of sense. So a static schema mount would have to > define a set of modules and not just a single module to lead to the > same chrooted behavior. Yes, that's what called "(sub)schema" in YSDL.=20 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 Feb 25 01:14:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7651A87BB for ; Thu, 25 Feb 2016 01:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 0wBXPVDzOl3H for ; Thu, 25 Feb 2016 01:14: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 2FF551A87AF for ; Thu, 25 Feb 2016 01:14:02 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B8D01AE0335; Thu, 25 Feb 2016 10:14:01 +0100 (CET) Date: Thu, 25 Feb 2016 10:14:05 +0100 (CET) Message-Id: <20160225.101405.682746466854621071.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160225090546.GA19551@elstar.local> References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <20160225090546.GA19551@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] explicit mount 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, 25 Feb 2016 09:14:03 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > > > > > > > I think the use cases are rather obvious. I build a device and I like > > > > > to rearrange existing models into a beautiful hierarchy (for some > > > > > definition of beauty). > > > > > > > > This would be pretty complicated. Suppose I define my own beautiful > > > > structure like this: > > > > > > > > container my-interfaces { > > > > x:mount-point "if" { > > > > x:mount-module "ietf-interfaces"; > > > > } > > > > } > > > > container my-routing { > > > > x:mount-point "rtr" { > > > > x:mount-module "ietf-routing"; > > > > } > > > > } > > > > > > > > Note that with the mount-point defined in my draft, each mount-point > > > > becomes itw own "jailed" or "chrooted" tree. So references cannot > > > > cross mount points. > > > > > > Could be the same here. > > > > > > > In this case, we have references between ietf-routing and > > > > ietf-interfaces. How would they work? > > > > > > How do they work in your solution? If interfaces is jailed and routing > > > is jailed, how does routing refer to the interfaces? > > > > My solution does not support "name module mount". It only supports > > mouting of a "complete" set of modules (that are chrooted) - simply > > because this is what we understand, have implemented, and have been > > running for the last ~5 years. (The same goes for ODL, I believe). > > OK. I understand now that the whole set of modules on a mount point > form one chroot environment. This was not clear to me yet but of > course makes a lot of sense. So a static schema mount would have to > define a set of modules and not just a single module to lead to the > same chrooted behavior. Yes, but then you can't use it to define your own beautiful structure. So then the question is if there is still a use case for this? /martin From nobody Thu Feb 25 01:26:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3C1A887F for ; Thu, 25 Feb 2016 01:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 bDbQTuu4E_Qg for ; Thu, 25 Feb 2016 01:26:29 -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 3BB261A8885 for ; Thu, 25 Feb 2016 01:26:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0AD7B15F3; Thu, 25 Feb 2016 10:26:27 +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 kXz5dOXnZjk6; Thu, 25 Feb 2016 10:26:10 +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, 25 Feb 2016 10:26:26 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 118FD20036; Thu, 25 Feb 2016 10:26:26 +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 jN0eiiIIJPfP; Thu, 25 Feb 2016 10:26:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 832482002C; Thu, 25 Feb 2016 10:26:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7650F39FD8C6; Thu, 25 Feb 2016 10:26:23 +0100 (CET) Date: Thu, 25 Feb 2016 10:26:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160225092623.GA19620@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <20160225090546.GA19551@elstar.local> <20160225.101405.682746466854621071.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225.101405.682746466854621071.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 25 Feb 2016 09:26:31 -0000 On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > > > > > > > > > I think the use cases are rather obvious. I build a device and I like > > > > > > to rearrange existing models into a beautiful hierarchy (for some > > > > > > definition of beauty). > > > > > > > > > > This would be pretty complicated. Suppose I define my own beautiful > > > > > structure like this: > > > > > > > > > > container my-interfaces { > > > > > x:mount-point "if" { > > > > > x:mount-module "ietf-interfaces"; > > > > > } > > > > > } > > > > > container my-routing { > > > > > x:mount-point "rtr" { > > > > > x:mount-module "ietf-routing"; > > > > > } > > > > > } > > > > > > > > > > Note that with the mount-point defined in my draft, each mount-point > > > > > becomes itw own "jailed" or "chrooted" tree. So references cannot > > > > > cross mount points. > > > > > > > > Could be the same here. > > > > > > > > > In this case, we have references between ietf-routing and > > > > > ietf-interfaces. How would they work? > > > > > > > > How do they work in your solution? If interfaces is jailed and routing > > > > is jailed, how does routing refer to the interfaces? > > > > > > My solution does not support "name module mount". It only supports > > > mouting of a "complete" set of modules (that are chrooted) - simply > > > because this is what we understand, have implemented, and have been > > > running for the last ~5 years. (The same goes for ODL, I believe). > > > > OK. I understand now that the whole set of modules on a mount point > > form one chroot environment. This was not clear to me yet but of > > course makes a lot of sense. So a static schema mount would have to > > define a set of modules and not just a single module to lead to the > > same chrooted behavior. > > Yes, but then you can't use it to define your own beautiful > structure. I am not sure yet why this is the case. I would have to derive from the schemas the set of modules on a mount point. Yes, this would be static and not very dynamic, to add a module I would have to modify the schema. /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 Feb 25 01:31:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3601A8893 for ; Thu, 25 Feb 2016 01:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 fIsRVcu1NYtT for ; Thu, 25 Feb 2016 01:31:40 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 422FB1A8885 for ; Thu, 25 Feb 2016 01:31:40 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 08DB61AE0335; Thu, 25 Feb 2016 10:31:38 +0100 (CET) Date: Thu, 25 Feb 2016 10:31:43 +0100 (CET) Message-Id: <20160225.103143.1397687839661509108.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160225092623.GA19620@elstar.local> References: <20160225090546.GA19551@elstar.local> <20160225.101405.682746466854621071.mbj@tail-f.com> <20160225092623.GA19620@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] explicit mount 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, 25 Feb 2016 09:31:43 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > > > > > > > > > > > > I think the use cases are rather obvious. I build a device and I like > > > > > > > to rearrange existing models into a beautiful hierarchy (for some > > > > > > > definition of beauty). > > > > > > > > > > > > This would be pretty complicated. Suppose I define my own beautiful > > > > > > structure like this: > > > > > > > > > > > > container my-interfaces { > > > > > > x:mount-point "if" { > > > > > > x:mount-module "ietf-interfaces"; > > > > > > } > > > > > > } > > > > > > container my-routing { > > > > > > x:mount-point "rtr" { > > > > > > x:mount-module "ietf-routing"; > > > > > > } > > > > > > } > > > > > > > > > > > > Note that with the mount-point defined in my draft, each mount-point > > > > > > becomes itw own "jailed" or "chrooted" tree. So references cannot > > > > > > cross mount points. > > > > > > > > > > Could be the same here. > > > > > > > > > > > In this case, we have references between ietf-routing and > > > > > > ietf-interfaces. How would they work? > > > > > > > > > > How do they work in your solution? If interfaces is jailed and routing > > > > > is jailed, how does routing refer to the interfaces? > > > > > > > > My solution does not support "name module mount". It only supports > > > > mouting of a "complete" set of modules (that are chrooted) - simply > > > > because this is what we understand, have implemented, and have been > > > > running for the last ~5 years. (The same goes for ODL, I believe). > > > > > > OK. I understand now that the whole set of modules on a mount point > > > form one chroot environment. This was not clear to me yet but of > > > course makes a lot of sense. So a static schema mount would have to > > > define a set of modules and not just a single module to lead to the > > > same chrooted behavior. > > > > Yes, but then you can't use it to define your own beautiful > > structure. > > I am not sure yet why this is the case. Each such mount point is chrooted. This implies that if you want to put module A in some place, and B has a reference to A, A and B must be mounted together. Thus I cannot put them anywhere to form a beautiful hierarchy. /martin > I would have to derive from > the schemas the set of modules on a mount point. Yes, this would be > static and not very dynamic, to add a module I would have to modify > the schema. > > /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 Feb 25 02:05:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4771A8A47 for ; Thu, 25 Feb 2016 02:05:35 -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 PRWpbMGbcoUR for ; Thu, 25 Feb 2016 02:05:32 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91A1A8A41 for ; Thu, 25 Feb 2016 02:05:32 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 277E71CC01AB; Thu, 25 Feb 2016 11:05:36 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20160224.154115.1596709215790076040.mbj@tail-f.com> References: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> <20160224.154115.1596709215790076040.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 25 Feb 2016 11:05:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 'predicate' production 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, 25 Feb 2016 10:05:35 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Hi, >> >> another ABNF issue: >> >> predicate = "[" *WSP (predicate-expr / pos) *WSP "]" >> >> predicate-expr = (node-identifier / ".") *WSP "=" *WSP >> ((DQUOTE string DQUOTE) / >> (SQUOTE string SQUOTE)) >> >> pos = non-negative-integer-value >> >> non-negative-integer-value = "0" / positive-integer-value >> >> The value of 0 shouldn't be allowed for 'pos' because context position >> in XPath is always positive, i.e. the first list entry is selected >> with "[1]". > > You are right - I have changed this to: > > pos = positive-integer-value Actually, there is another problem: the ABNF allows, for example /if:interfaces/if:interface[1][2] which doesn't make sense. So a correct version could be instance-identifier = 1*("/" (node-identifier (*predicate / pos)) predicate = "[" *WSP predicate-expr *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos = "[" *WSP positive-integer-value *WSP "]" Lada > > > /martin > > > >> >> 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 Thu Feb 25 02:15:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AB1A8A45 for ; Thu, 25 Feb 2016 02:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 hfmaIauvoclZ for ; Thu, 25 Feb 2016 02:15:51 -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 D7F131A8A0C for ; Thu, 25 Feb 2016 02:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2833; q=dns/txt; s=iport; t=1456395350; x=1457604950; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=TLE6loiD9vojW95vj7lXseJpddw6Blr5DgyNkqViRJ0=; b=fw9SunAqbiFWGKnO5Oz0bcaEc5wWhQi5Ti1yEpXd5pO5uOgBZyHqn0TU Ca7uibOuJ44dXBVTdB8bEPlUBmmExuOiPuJIfqeJx0dAKHvPZ3YMiVUH0 3/XnCRUrMVK8c0vd4uT7FEn3y75FW20lwzPWXVHQcOHZvV3lygXl96PPj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABp085W/xbLJq1ehHm8LoYNAoIRA?= =?us-ascii?q?QEBAQEBZSeEQgEBBDhAARALDgIICRYPCQMCAQIBRQYNBgIBAReIBL4mAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAReGEoQ6iG8BBI0qiV6NX4kkhVCOSWKDZDwuiBgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,497,1449532800"; d="scan'208";a="635717056" 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; 25 Feb 2016 10:15:47 +0000 Received: from [10.63.23.69] (dhcp-ensft1-uk-vla370-10-63-23-69.cisco.com [10.63.23.69]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1PAFlO7022147; Thu, 25 Feb 2016 10:15:47 GMT To: Martin Bjorklund References: <20160225090546.GA19551@elstar.local> <20160225.101405.682746466854621071.mbj@tail-f.com> <20160225092623.GA19620@elstar.local> <20160225.103143.1397687839661509108.mbj@tail-f.com> From: Robert Wilton Message-ID: <56CED453.6080009@cisco.com> Date: Thu, 25 Feb 2016 10:15:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160225.103143.1397687839661509108.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] explicit mount 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, 25 Feb 2016 10:15:52 -0000 Hi Martin, On 25/02/2016 09:31, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder wrote: >>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>>>> >>>>>>>> I think the use cases are rather obvious. I build a device and I like >>>>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>>>> definition of beauty). >>>>>>> This would be pretty complicated. Suppose I define my own beautiful >>>>>>> structure like this: >>>>>>> >>>>>>> container my-interfaces { >>>>>>> x:mount-point "if" { >>>>>>> x:mount-module "ietf-interfaces"; >>>>>>> } >>>>>>> } >>>>>>> container my-routing { >>>>>>> x:mount-point "rtr" { >>>>>>> x:mount-module "ietf-routing"; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Note that with the mount-point defined in my draft, each mount-point >>>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>>>> cross mount points. >>>>>> Could be the same here. >>>>>> >>>>>>> In this case, we have references between ietf-routing and >>>>>>> ietf-interfaces. How would they work? >>>>>> How do they work in your solution? If interfaces is jailed and routing >>>>>> is jailed, how does routing refer to the interfaces? >>>>> My solution does not support "name module mount". It only supports >>>>> mouting of a "complete" set of modules (that are chrooted) - simply >>>>> because this is what we understand, have implemented, and have been >>>>> running for the last ~5 years. (The same goes for ODL, I believe). >>>> OK. I understand now that the whole set of modules on a mount point >>>> form one chroot environment. This was not clear to me yet but of >>>> course makes a lot of sense. So a static schema mount would have to >>>> define a set of modules and not just a single module to lead to the >>>> same chrooted behavior. >>> Yes, but then you can't use it to define your own beautiful >>> structure. >> I am not sure yet why this is the case. > Each such mount point is chrooted. This implies that if you want to > put module A in some place, and B has a reference to A, A and B must > be mounted together. Thus I cannot put them anywhere to form a > beautiful hierarchy. As long as B is mounted in the same datastore as A then is it possible that B could moved to be mounted on some other path? References to/from B would need to be fixed up, or are you saying that fixing the references is intractable? Rob From nobody Thu Feb 25 03:16:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465931A00E1 for ; Thu, 25 Feb 2016 03:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 QeEIIyB_ej-k for ; Thu, 25 Feb 2016 03:16:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B63111A00DA for ; Thu, 25 Feb 2016 03:16:34 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 685F71AE0335; Thu, 25 Feb 2016 12:16:32 +0100 (CET) Date: Thu, 25 Feb 2016 12:16:36 +0100 (CET) Message-Id: <20160225.121636.2137433316176193967.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56CED453.6080009@cisco.com> References: <20160225092623.GA19620@elstar.local> <20160225.103143.1397687839661509108.mbj@tail-f.com> <56CED453.6080009@cisco.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] explicit mount 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, 25 Feb 2016 11:16:36 -0000 Robert Wilton wrote: > Hi Martin, > > On 25/02/2016 09:31, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote: > >>> Juergen Schoenwaelder wrote: > >>>> On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: > >>>>> Juergen Schoenwaelder wrote: > >>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > >>>>>> > >>>>>>>> I think the use cases are rather obvious. I build a device and I like > >>>>>>>> to rearrange existing models into a beautiful hierarchy (for some > >>>>>>>> definition of beauty). > >>>>>>> This would be pretty complicated. Suppose I define my own beautiful > >>>>>>> structure like this: > >>>>>>> > >>>>>>> container my-interfaces { > >>>>>>> x:mount-point "if" { > >>>>>>> x:mount-module "ietf-interfaces"; > >>>>>>> } > >>>>>>> } > >>>>>>> container my-routing { > >>>>>>> x:mount-point "rtr" { > >>>>>>> x:mount-module "ietf-routing"; > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> Note that with the mount-point defined in my draft, each mount-point > >>>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot > >>>>>>> cross mount points. > >>>>>> Could be the same here. > >>>>>> > >>>>>>> In this case, we have references between ietf-routing and > >>>>>>> ietf-interfaces. How would they work? > >>>>>> How do they work in your solution? If interfaces is jailed and routing > >>>>>> is jailed, how does routing refer to the interfaces? > >>>>> My solution does not support "name module mount". It only supports > >>>>> mouting of a "complete" set of modules (that are chrooted) - simply > >>>>> because this is what we understand, have implemented, and have been > >>>>> running for the last ~5 years. (The same goes for ODL, I believe). > >>>> OK. I understand now that the whole set of modules on a mount point > >>>> form one chroot environment. This was not clear to me yet but of > >>>> course makes a lot of sense. So a static schema mount would have to > >>>> define a set of modules and not just a single module to lead to the > >>>> same chrooted behavior. > >>> Yes, but then you can't use it to define your own beautiful > >>> structure. > >> I am not sure yet why this is the case. > > Each such mount point is chrooted. This implies that if you want to > > put module A in some place, and B has a reference to A, A and B must > > be mounted together. Thus I cannot put them anywhere to form a > > beautiful hierarchy. > > As long as B is mounted in the same datastore as A then is it possible > that B could moved to be mounted on some other path? Yes, but then you'd need some special syntax to say that they are related. > References to/from B would need to be fixed up, or are you saying that > fixing the references is intractable? I think it would be extremely complicated, both on the server and on the client side. /martin From nobody Thu Feb 25 05:16:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F11ABD3E for ; Thu, 25 Feb 2016 05:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 UqtKi5ELK7MC for ; Thu, 25 Feb 2016 05:16:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED21AC3A2 for ; Thu, 25 Feb 2016 05:16:34 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 3147E1AE0335; Thu, 25 Feb 2016 14:16:32 +0100 (CET) Date: Thu, 25 Feb 2016 14:16:36 +0100 (CET) Message-Id: <20160225.141636.866530241120731674.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> <20160224.154115.1596709215790076040.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] 'predicate' production 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, 25 Feb 2016 13:16:38 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> another ABNF issue: > >> > >> predicate = "[" *WSP (predicate-expr / pos) *WSP "]" > >> > >> predicate-expr = (node-identifier / ".") *WSP "=" *WSP > >> ((DQUOTE string DQUOTE) / > >> (SQUOTE string SQUOTE)) > >> > >> pos = non-negative-integer-value > >> > >> non-negative-integer-value = "0" / positive-integer-value > >> > >> The value of 0 shouldn't be allowed for 'pos' because context position > >> in XPath is always positive, i.e. the first list entry is selected > >> with "[1]". > > > > You are right - I have changed this to: > > > > pos = positive-integer-value > > Actually, there is another problem: the ABNF allows, for example > > /if:interfaces/if:interface[1][2] > > which doesn't make sense. Yes, you're right. > So a correct version could be > > instance-identifier = 1*("/" (node-identifier (*predicate / pos)) this would make pos mandatory after every node-identifier. It should be: instance-identifier = 1*("/" (node-identifier (*predicate / *1pos))) or, in order to match the style in the rest of the grammar: instance-identifier = 1*("/" (node-identifier [1*predicate / pos])) > predicate = "[" *WSP predicate-expr *WSP "]" > > predicate-expr = (node-identifier / ".") *WSP "=" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) > > pos = "[" *WSP positive-integer-value *WSP "]" /martin From nobody Thu Feb 25 05:26:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BB1AC40E; Thu, 25 Feb 2016 05:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 IxX8dDVy7rFw; Thu, 25 Feb 2016 05:26:07 -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 DBF211AC409; Thu, 25 Feb 2016 05:26:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 83C9E181455; Thu, 25 Feb 2016 14:26:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456406765; bh=uIVnXyIaQ80wMsgY7h/TN9X/j+g6Pw2aUxxHCBGrQaM=; h=From:Date:To; b=KE8SitdAYK6kOaE5Mi2D9Qh7OcmGLPKujIOfL8NJkaYQPzyz27I9Tm6bSymERGItd NkjAiP1itIZd48tBMobV9pp9G6HbnHq3VLpMhE1a6Z9zJQtmzks3yJPRjyAGmwDqGm tQFmRme7vvmE0ZZfc4Z1lskAODcfd4hLTLok4sLY= Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <036401d16fca$511a2580$4001a8c0@gateway.2wire.net> Date: Thu, 25 Feb 2016 14:26:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95F286E9-700F-4408-9608-144583789097@nic.cz> References: <20160224140746.29017.27133.idtracker@ietfa.amsl.com> <036401d16fca$511a2580$4001a8c0@gateway.2wire.net> To: "tom p." X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: draft-ietf-netmod-yang-json@ietf.org, ietf@ietf.org, NETMOD WG Subject: Re: [netmod] Last Call: (JSON Encoding of Data Modeled with YANG) to Proposed Standard 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, 25 Feb 2016 13:26:08 -0000 Tom, > On 25 Feb 2016, at 13:42, tom p. wrote: >=20 > In the interests of clarity >=20 > - datastores are not mentioned. These loom large in YANG and NETCONF > and, I think, have been misunderstood by those wishing to extend YANG = in > various, new directions. Therefore I think that the I-D should say > something, even if it is that the concept of datastore is alien to the > envisaged uses of JSON (I could envisage a use where datastores do > apply, but it is probably an unrealistic use:-) I don't understand. This draft is about encoding a data tree in JSON = under the assumption that the data tree is valid with respect to a YANG = data model. How is this related to datastores? In particular, I don't = think the concept of datastores is alien to it in any way (proofs exist = to the contrary). >=20 > -YANG 1.0 ditto. I realise that this I-D normatively references YANG > 1.1 but there is a lot of YANG 1.0 about. My sense is that this I-D > cannot work with YANG 1.0, in which case, I think that that needs > stating. Right, this I-D references YANG 1.1 because, among other things, it also = defines the encoding for "anydata", which is a new YANG 1.1 feature. All = other rules are applicable to YANG 1.0. Anyway, I believe all new = implementations should use YANG 1.1. >=20 > - the examples use the exact same identifiers (foo, bar) to identify = an > object and a namespace prefix. Experts in YANG will know well the = many > namespaces in YANG and their scope and so could not posssibly be > confused; but unless the I-D wants to make the point that there are = many > namespaces in YANG with different scopes, then I think that the worked > examples should use distinct identifiers. This is a valid point. I will change the prefixes to "foomod" and = "barmod". Thanks, Lada >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "The IESG" > Sent: Wednesday, February 24, 2016 2:07 PM >=20 >>=20 >> The IESG has received a request from the NETCONF Data Modeling > Language >> WG (netmod) to consider the following document: >> - 'JSON Encoding of Data Modeled with YANG' >> as Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments = may > be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document defines encoding rules for representing > configuration, >> state data, parameters of RPC operations or actions, and >> notifications defined using YANG as JavaScript Object Notation > (JSON) >> text. >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ >>=20 >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 05:27:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D61AC424 for ; Thu, 25 Feb 2016 05:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 6_CNfeMy_O_7 for ; Thu, 25 Feb 2016 05:27: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 A0FA71AC435 for ; Thu, 25 Feb 2016 05:27:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 497EC180505; Thu, 25 Feb 2016 14:27:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456406866; bh=oMdgmbHal6Acgk7QU6o4XxTLvFCJPvdkAcKicSHy2e4=; h=From:Date:To; b=Tm89A6ahcWTN4/4IgxzoQc7kUPLA17CguiRHCTnGusj31XaOfcAZQrJKz0T4mFKvP DRXo4yuh8ucwcU0huYDm0BaVizoUBT1MQPonK7C5woHKymgIKH4k4v9FP22+fcym78 9mkVU1d5uq8Hj0OxTS0Adg4ThyOkmaLKUFsU5HuY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225.141636.866530241120731674.mbj@tail-f.com> Date: Thu, 25 Feb 2016 14:27:58 +0100 Content-Transfer-Encoding: 7bit Message-Id: <878E0FB5-3FC4-4E19-AE0E-25C5CF255D0D@nic.cz> References: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> <20160224.154115.1596709215790076040.mbj@tail-f.com> <20160225.141636.866530241120731674.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] 'predicate' production 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, 25 Feb 2016 13:27:49 -0000 > On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> another ABNF issue: >>>> >>>> predicate = "[" *WSP (predicate-expr / pos) *WSP "]" >>>> >>>> predicate-expr = (node-identifier / ".") *WSP "=" *WSP >>>> ((DQUOTE string DQUOTE) / >>>> (SQUOTE string SQUOTE)) >>>> >>>> pos = non-negative-integer-value >>>> >>>> non-negative-integer-value = "0" / positive-integer-value >>>> >>>> The value of 0 shouldn't be allowed for 'pos' because context position >>>> in XPath is always positive, i.e. the first list entry is selected >>>> with "[1]". >>> >>> You are right - I have changed this to: >>> >>> pos = positive-integer-value >> >> Actually, there is another problem: the ABNF allows, for example >> >> /if:interfaces/if:interface[1][2] >> >> which doesn't make sense. > > Yes, you're right. > >> So a correct version could be >> >> instance-identifier = 1*("/" (node-identifier (*predicate / pos)) > > this would make pos mandatory after every node-identifier. It should > be: > > instance-identifier = 1*("/" (node-identifier (*predicate / *1pos))) > > or, in order to match the style in the rest of the grammar: > > instance-identifier = 1*("/" (node-identifier [1*predicate / pos])) OK, agreed. Lada > >> predicate = "[" *WSP predicate-expr *WSP "]" >> >> predicate-expr = (node-identifier / ".") *WSP "=" *WSP >> ((DQUOTE string DQUOTE) / >> (SQUOTE string SQUOTE)) >> >> pos = "[" *WSP positive-integer-value *WSP "]" > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 05:31:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F21A930A; Thu, 25 Feb 2016 05:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 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, RP_MATCHES_RCVD=-0.006] 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 k70TvWC6vhUX; Thu, 25 Feb 2016 05:08:09 -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 5F8731A9301; Thu, 25 Feb 2016 05:08:08 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 8CFA3181672; Thu, 25 Feb 2016 14:08:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456405686; bh=5CcU6eRMfHWLpAavjvhxjT3zrEjwD8j6BRrIpgwmnyI=; h=From:Date:To; b=WjXKCalAho3WMT5MpvhretNuAu3ZGINfZG5DeHqslFo517NiJwQ94ZBCVA9rHeE/3 8V5+PgOTVcBv/SWYmtoexCgkxQ073nxYZGWVvkTOwT9NysBqHz5iRUxLzoP84UkbDo ThIakN5+Exocfniwqk2ugQ6uv/0fFZ8Wo2VaImjQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56CEF681.5040306@cisco.com> Date: Thu, 25 Feb 2016 14:08:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@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: X-Mailman-Approved-At: Thu, 25 Feb 2016 05:31:28 -0800 Cc: Santosh Esale , joel jaeggli , rtg-ads@ietf.org, Ross Callon , Adrian Farrel , "Sowmya Krishnaswamy \(sowkrish\)" , Xufeng Liu , Brian Haberman , NETMOD WG , George Swallow , jescia.chenxia@huawei.com, "Rajiv Asati \(rajiva\)" , int-ads@ietf.org, "Kamran Raza \(skraza\)" , Jeff Tantsura , "Bocci, Matthew \(Matthew\)" , Adrian Farrel , Loa Andersson , ops-ads@ietf.org Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] 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, 25 Feb 2016 13:08:13 -0000 Hi Benoit, this was discussed a while ago in this thread: https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I tl;dr: The WG decision then was to introduce a new type in = ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the = semantics of an IPv4 address - it is an uint32 number that's expressed = in the dotted quad format, which is what most router platforms accept as = routerID via CLI. Lada > On 25 Feb 2016, at 13:41, Benoit Claise wrote: >=20 > Dear all, >=20 > Sorry for the delay (mix of vacation and business travel).=20 >=20 > Let me try to summarize the situation as I see it: > - =46rom the routing RFCs, BGP Identifier, OSPF router ID, TE = identifier, and LSR identifiers are all an unsigned integers. > - We need consistency for the router ID and identifier in YANG = leaf/typedef > - The OSPF MIB module has defined > RouterID ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A OSPF Router Identifier. > Note that the Router ID, in OSPF, has the same format > as an IP address, but identifies the router independent > of its IP address." > SYNTAX IpAddress >=20 >=20 > ospfRouterId OBJECT-TYPE > SYNTAX RouterID > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 32-bit integer uniquely identifying the > router in the Autonomous System. > By convention, to ensure uniqueness, this > should default to the value of one of the > router's IP interface addresses. >=20 > As Adrian mentioned: it is NOT an IP address but the MIB module uses = the notational formatting of n IP address for display purposes. > - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 = environment >=20 > Based on this, I believe that: > - We must not associate an IP address semantic with the router ID > - Based on Brian's feedback (which I agree with) "As long as the YANG = module does not specify a format that makes the routerID display like an = IPv4 address", it was probably a mistake to have defined RouterID as = IpAdress in OSPF MIB module. > - Interestingly, = https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains: >=20 > grouping router-id { > description > "This grouping provides router ID."; > leaf router-id { > type yang:dotted-quad; > description > "A 32-bit number in the form of a dotted quad that is used = by > some routing protocols identifying a router."; > reference > " > RFC 2328 > : OSPF Version 2."; > } > } >=20 > This should be an uint32 number. > - An union-based solution is a bad compromise > =46rom draft-raza-mpls-ldp-mldp-yang-02 > leaf lsr-id { > type union { > type yang:dotted-quad; > type uint32; > } > description "LSR ID."; >=20 >=20 >=20 > Since the question was asked: as AD, I would support uint32 = everywhere. >=20 > Now, practically, how to move forward?=20 > - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with = the uint32 modification), > - Or you create a "Common Routing YANG Data Types", similarly to RFC = 6991 including the router IDs. I see already many typedef in = draft-raza-mpls-ldp-mldp-yang-02 > - Or you define you own types in your own draft >=20 > But, if we have agreement on the uint32, let's document this now = somewhere/somehow, and let's not revisit this on regular basis (yes, I = see it coming...) > A few lines of explanation in the draft would already help for = example, in an operational section, explaining to people the mapping of = the MIB OSPF RouterID to the YANG object >=20 > Regards, Benoit >> Hi Adrian, >>=20 >> On 2/16/16 7:53 AM, Adrian Farrel wrote: >>=20 >>> Hi Brian, >>>=20 >>> I said I wasn't going to participate in this discussion :-) >>>=20 >> Nice try. ;) >>=20 >>=20 >>>>> I should not respond to questions that I don't fully understand, = but: >>>>>=20 >>>>> the BGP Identifier is an unsigned integer >>>>> the OSPF router ID is an unsigned integer >>>>>=20 >>>> I assume the above is based on the YANG definition of OSPF = routerID. RFC >>>> 4750 says the routerID is an IPv4 address. Is that an issue? >>>>=20 >>> To quote from 4750... >>>=20 >>> RouterID ::=3D TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A OSPF Router Identifier. >>> Note that the Router ID, in OSPF, has the same format >>> as an IP address, but identifies the router independent >>> of its IP address." >>> SYNTAX IpAddress >>>=20 >>> So it explicitly says it is NOT an IP address but the MIB module = uses the notational formatting of n IP address for display purposes. >>>=20 >>> I think this is done because the router ID is often chosen to be an = IP address of the router, and because it is easier for humans to deal = with a.b.c.d where each element is a 3-digit number less than 256, than = it is to manage a single number in the range 0 to 2^32 -1. >>>=20 >>>=20 >> The above is the textual convention, whereas the following is the = actual >> OSPF routerID... >>=20 >> ospfRouterId OBJECT-TYPE >> SYNTAX RouterID >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A 32-bit integer uniquely identifying the >> router in the Autonomous System. >> By convention, to ensure uniqueness, this >> should default to the value of one of the >> router's IP interface addresses. >>=20 >> So the MIB actually says the default is to use an IPv4 address... >>=20 >> All that being said, my point was further along where I said: >>=20 >>=20 >>>> I am not concerned with what the operator will choose as his/her >>>> routerID value. I am concerned with what format options will be >>>> associated with the routerID in the yang module. As long as the = format >>>> options does not allow display in dotted decimal notation, I am = fine. >>>>=20 >> As long as the YANG module does not specify a format that makes the >> routerID display like an IPv4 address, I am fine. >>=20 >> Brian >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 05:45:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3213E1ACCE3 for ; Thu, 25 Feb 2016 05:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 TOez7jBx9dL3 for ; Thu, 25 Feb 2016 05:45: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 56A261ACC87 for ; Thu, 25 Feb 2016 05:45:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id EAA45181C56; Thu, 25 Feb 2016 14:45:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456407928; bh=zLypnrTSLgl6AKlHosYVsNBPgwRmAbSUVwm7CrtVvGw=; h=From:Date:To; b=dcbvb3ipYbUgoas2a1sS6ziECd+HusQALz5bFa1VtvnpxxCqj/wkov7mZq4bRymnX N8UspI7rQktfjtcdypqStHHYRl7OLzsoD+5fqcQccq+M3T9BKgZTEAbGGauLIwrGd1 ClmCPukHthzunklKPHvazdzNu8VOQjdE3HjuPW7w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225.141636.866530241120731674.mbj@tail-f.com> Date: Thu, 25 Feb 2016 14:45:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCD8E77-F906-49F6-A776-31FF2B623D8F@nic.cz> References: <63325CB9-27E6-46F9-A2C2-F0E1AF1E642C@nic.cz> <20160224.154115.1596709215790076040.mbj@tail-f.com> <20160225.141636.866530241120731674.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] 'predicate' production 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, 25 Feb 2016 13:45:32 -0000 > On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> another ABNF issue: >>>>=20 >>>> predicate =3D "[" *WSP (predicate-expr / pos) *WSP "]" >>>>=20 >>>> predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP >>>> ((DQUOTE string DQUOTE) / >>>> (SQUOTE string SQUOTE)) >>>>=20 >>>> pos =3D non-negative-integer-value >>>>=20 >>>> non-negative-integer-value =3D "0" / positive-integer-value >>>>=20 >>>> The value of 0 shouldn't be allowed for 'pos' because context = position >>>> in XPath is always positive, i.e. the first list entry is selected >>>> with "[1]". >>>=20 >>> You are right - I have changed this to: >>>=20 >>> pos =3D positive-integer-value >>=20 >> Actually, there is another problem: the ABNF allows, for example >>=20 >> /if:interfaces/if:interface[1][2] >>=20 >> which doesn't make sense. >=20 > Yes, you're right. >=20 >> So a correct version could be >>=20 >> instance-identifier =3D 1*("/" (node-identifier (*predicate / pos)) >=20 > this would make pos mandatory after every node-identifier. It should > be:=20 >=20 > instance-identifier =3D 1*("/" (node-identifier (*predicate / = *1pos))) >=20 > or, in order to match the style in the rest of the grammar: >=20 > instance-identifier =3D 1*("/" (node-identifier [1*predicate / pos])) If we want to be really precise, then the predicate for a leaf-list [ . = =3D 'foo'] can also appear no more than once. Lada >=20 >> predicate =3D "[" *WSP predicate-expr *WSP "]" >>=20 >> predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP >> ((DQUOTE string DQUOTE) / >> (SQUOTE string SQUOTE)) >>=20 >> pos =3D "[" *WSP positive-integer-value *WSP "]" >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 05:51:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EAB1ACCF4 for ; Thu, 25 Feb 2016 05:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 io15P2kTUULz for ; Thu, 25 Feb 2016 05:50:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A19D01ACD2C for ; Thu, 25 Feb 2016 05:50:58 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id A3C461AE0335; Thu, 25 Feb 2016 14:50:57 +0100 (CET) Date: Thu, 25 Feb 2016 14:51:02 +0100 (CET) Message-Id: <20160225.145102.1511894162925887050.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <8DCD8E77-F906-49F6-A776-31FF2B623D8F@nic.cz> References: <20160225.141636.866530241120731674.mbj@tail-f.com> <8DCD8E77-F906-49F6-A776-31FF2B623D8F@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] 'predicate' production 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, 25 Feb 2016 13:51:00 -0000 Ladislav Lhotka wrote: > > > On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>> Ladislav Lhotka wrote: > >>>> Hi, > >>>> > >>>> another ABNF issue: > >>>> > >>>> predicate = "[" *WSP (predicate-expr / pos) *WSP "]" > >>>> > >>>> predicate-expr = (node-identifier / ".") *WSP "=" *WSP > >>>> ((DQUOTE string DQUOTE) / > >>>> (SQUOTE string SQUOTE)) > >>>> > >>>> pos = non-negative-integer-value > >>>> > >>>> non-negative-integer-value = "0" / positive-integer-value > >>>> > >>>> The value of 0 shouldn't be allowed for 'pos' because context position > >>>> in XPath is always positive, i.e. the first list entry is selected > >>>> with "[1]". > >>> > >>> You are right - I have changed this to: > >>> > >>> pos = positive-integer-value > >> > >> Actually, there is another problem: the ABNF allows, for example > >> > >> /if:interfaces/if:interface[1][2] > >> > >> which doesn't make sense. > > > > Yes, you're right. > > > >> So a correct version could be > >> > >> instance-identifier = 1*("/" (node-identifier (*predicate / pos)) > > > > this would make pos mandatory after every node-identifier. It should > > be: > > > > instance-identifier = 1*("/" (node-identifier (*predicate / *1pos))) > > > > or, in order to match the style in the rest of the grammar: > > > > instance-identifier = 1*("/" (node-identifier [1*predicate / pos])) > > If we want to be really precise, then the predicate for a leaf-list [ > . = 'foo'] can also appear no more than once. Correct. But we can only do so much in the grammar... For example, we cannot verify that the name and number of keys are correct. It would be: instance-identifier = 1*("/" (node-identifier [1*key-predicate / leaf-list-predicate / pos])) key-predicate = "[" *WSP key-predicate-expr *WSP "]" key-predicate-expr = node-identifier *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) leaf-list-predicate = "[" *WSP leaf-list-predicate-expr *WSP "]" leaf-list-predicate-expr = "." *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos = "[" *WSP positive-integer-value *WSP "]" /martin From nobody Thu Feb 25 06:01:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233CF1ACD59 for ; Thu, 25 Feb 2016 06:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 FQKU21neO64b for ; Thu, 25 Feb 2016 06:01: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 543161ACD4D for ; Thu, 25 Feb 2016 06:01:04 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id F0E04181A66; Thu, 25 Feb 2016 15:01:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456408863; bh=cbZTrtHo1oXr/EjnUZDWIRZgnFv3DZR5gOBBn1iJdKY=; h=From:Date:To; b=xLWmluTvGiQ2auMJ/lpnwtFvqIOdbDsHoM/auCfDd6PKkX0nwdsYGl/FvNu1QCYtT /dkokOeDFt+6+aNtTUPnK0AgoUCdTx3l+MrD0lK91gdeqp9IopMT6qP+bKsJC8LWPS nkfTBRpk41pjC97CZfeIcT0GciSsCMVt7zJdCw6w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225.145102.1511894162925887050.mbj@tail-f.com> Date: Thu, 25 Feb 2016 15:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <489B46F2-CF54-4696-A4C9-BDE7295569D6@nic.cz> References: <20160225.141636.866530241120731674.mbj@tail-f.com> <8DCD8E77-F906-49F6-A776-31FF2B623D8F@nic.cz> <20160225.145102.1511894162925887050.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] 'predicate' production 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, 25 Feb 2016 14:01:09 -0000 > On 25 Feb 2016, at 14:51, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Hi, >>>>>>=20 >>>>>> another ABNF issue: >>>>>>=20 >>>>>> predicate =3D "[" *WSP (predicate-expr / pos) *WSP "]" >>>>>>=20 >>>>>> predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP >>>>>> ((DQUOTE string DQUOTE) / >>>>>> (SQUOTE string SQUOTE)) >>>>>>=20 >>>>>> pos =3D non-negative-integer-value >>>>>>=20 >>>>>> non-negative-integer-value =3D "0" / positive-integer-value >>>>>>=20 >>>>>> The value of 0 shouldn't be allowed for 'pos' because context = position >>>>>> in XPath is always positive, i.e. the first list entry is = selected >>>>>> with "[1]". >>>>>=20 >>>>> You are right - I have changed this to: >>>>>=20 >>>>> pos =3D positive-integer-value >>>>=20 >>>> Actually, there is another problem: the ABNF allows, for example >>>>=20 >>>> /if:interfaces/if:interface[1][2] >>>>=20 >>>> which doesn't make sense. >>>=20 >>> Yes, you're right. >>>=20 >>>> So a correct version could be >>>>=20 >>>> instance-identifier =3D 1*("/" (node-identifier (*predicate / = pos)) >>>=20 >>> this would make pos mandatory after every node-identifier. It = should >>> be:=20 >>>=20 >>> instance-identifier =3D 1*("/" (node-identifier (*predicate / = *1pos))) >>>=20 >>> or, in order to match the style in the rest of the grammar: >>>=20 >>> instance-identifier =3D 1*("/" (node-identifier [1*predicate / = pos])) >>=20 >> If we want to be really precise, then the predicate for a leaf-list [ >> . =3D 'foo'] can also appear no more than once. >=20 > Correct. But we can only do so much in the grammar... For example, we > cannot verify that the name and number of keys are correct. Yes, but these are already semantic constraints. I think the new = productions below are in fact easier to comprehend. Perhaps a production = like quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) would also be an improvement. Lada >=20 > It would be: >=20 > instance-identifier =3D 1*("/" (node-identifier [1*key-predicate / > leaf-list-predicate / > pos])) >=20 > key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >=20 > key-predicate-expr =3D node-identifier *WSP "=3D" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) >=20 > leaf-list-predicate =3D "[" *WSP leaf-list-predicate-expr *WSP "]" >=20 > leaf-list-predicate-expr =3D "." *WSP "=3D" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) >=20 > pos =3D "[" *WSP positive-integer-value *WSP "]" >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 07:08:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2BF1B29F2 for ; Thu, 25 Feb 2016 07:08:28 -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, 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 z57o8mumnJwf for ; Thu, 25 Feb 2016 07:08:27 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402401B29ED for ; Thu, 25 Feb 2016 07:08:27 -0800 (PST) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PF4aML020948 for ; Thu, 25 Feb 2016 07:08:27 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 216qrbqey2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 25 Feb 2016 07:08:26 -0800 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 08:08:22 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 16:08:21 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Thu, 25 Feb 2016 16:08:21 +0100 From: William Ivory To: "netmod@ietf.org" Thread-Topic: Clarification needed for YANG 1.1 XPATH context Thread-Index: AdFv3R4BwHXZzI6xSlm06BqlW0gmXg== Date: Thu, 25 Feb 2016 15:08:09 +0000 Deferred-Delivery: Thu, 25 Feb 2016 15:07:13 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.156] Content-Type: multipart/alternative; boundary="_000_f790c7e329684d78bec27a1bfe150d6cEMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250217 Archived-At: Subject: [netmod] Clarification needed for YANG 1.1 XPATH context 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, 25 Feb 2016 15:08:28 -0000 --_000_f790c7e329684d78bec27a1bfe150d6cEMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, I'm looking for clarification on the meaning of the following paragraph in section 6.4.1 (XPATH context) in RFC6020bis: 'If a node that exists in the accessible tree has a non-presence container as a child, then the non-presence container also exists in the tree.' It's unclear to me what this is trying to say, and why - for example, does this mean that I need to validate any 'must' and 'when' statements on the child container even when nothing within that child container is configured? Thanks, William --_000_f790c7e329684d78bec27a1bfe150d6cEMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I’m looking for clarification on the meaning of the following pa= ragraph in section 6.4.1 (XPATH context) in RFC6020bis:
 
   ‘If a node that exists in the accessible tree has a= non-presence
   container as a child, then the non-presence container als= o exists in
   the tree.’
 
It’s unclear to me what this is trying to say, and why – f= or example, does this mean that I need to validate any ‘must’ a= nd ‘when’ statements on the child container even when nothing w= ithin that child container is configured?
 
Thanks,
 
William
 
 --_000_f790c7e329684d78bec27a1bfe150d6cEMEAWPEXMB12corpbrocade_-- From nobody Thu Feb 25 07:10:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC01B2A0B for ; Thu, 25 Feb 2016 07:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 wbBj1evL1rT5 for ; Thu, 25 Feb 2016 07:10: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 14F1B1B2A07 for ; Thu, 25 Feb 2016 07:10:00 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 67D8D1AE0335; Thu, 25 Feb 2016 16:09:58 +0100 (CET) Date: Thu, 25 Feb 2016 16:10:02 +0100 (CET) Message-Id: <20160225.161002.1324090744270867912.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <489B46F2-CF54-4696-A4C9-BDE7295569D6@nic.cz> References: <8DCD8E77-F906-49F6-A776-31FF2B623D8F@nic.cz> <20160225.145102.1511894162925887050.mbj@tail-f.com> <489B46F2-CF54-4696-A4C9-BDE7295569D6@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] 'predicate' production 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, 25 Feb 2016 15:10:01 -0000 Hi, Here's a summary of the changes: OLD: instance-identifier = 1*("/" (node-identifier *predicate)) predicate = "[" *WSP (predicate-expr / pos) *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos = non-negative-integer-value NEW: instance-identifier = 1*("/" (node-identifier [1*key-predicate / leaf-list-predicate / pos])) key-predicate = "[" *WSP key-predicate-expr *WSP "]" key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string leaf-list-predicate = "[" *WSP leaf-list-predicate-expr *WSP "]" leaf-list-predicate-expr = "." *WSP "=" *WSP quoted-string pos = "[" *WSP positive-integer-value *WSP "]" quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) /martin Ladislav Lhotka wrote: > > > On 25 Feb 2016, at 14:51, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> Martin Bjorklund writes: > >>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> Hi, > >>>>>> > >>>>>> another ABNF issue: > >>>>>> > >>>>>> predicate = "[" *WSP (predicate-expr / pos) *WSP "]" > >>>>>> > >>>>>> predicate-expr = (node-identifier / ".") *WSP "=" *WSP > >>>>>> ((DQUOTE string DQUOTE) / > >>>>>> (SQUOTE string SQUOTE)) > >>>>>> > >>>>>> pos = non-negative-integer-value > >>>>>> > >>>>>> non-negative-integer-value = "0" / positive-integer-value > >>>>>> > >>>>>> The value of 0 shouldn't be allowed for 'pos' because context position > >>>>>> in XPath is always positive, i.e. the first list entry is selected > >>>>>> with "[1]". > >>>>> > >>>>> You are right - I have changed this to: > >>>>> > >>>>> pos = positive-integer-value > >>>> > >>>> Actually, there is another problem: the ABNF allows, for example > >>>> > >>>> /if:interfaces/if:interface[1][2] > >>>> > >>>> which doesn't make sense. > >>> > >>> Yes, you're right. > >>> > >>>> So a correct version could be > >>>> > >>>> instance-identifier = 1*("/" (node-identifier (*predicate / pos)) > >>> > >>> this would make pos mandatory after every node-identifier. It should > >>> be: > >>> > >>> instance-identifier = 1*("/" (node-identifier (*predicate / *1pos))) > >>> > >>> or, in order to match the style in the rest of the grammar: > >>> > >>> instance-identifier = 1*("/" (node-identifier [1*predicate / pos])) > >> > >> If we want to be really precise, then the predicate for a leaf-list [ > >> . = 'foo'] can also appear no more than once. > > > > Correct. But we can only do so much in the grammar... For example, we > > cannot verify that the name and number of keys are correct. > > Yes, but these are already semantic constraints. I think the new productions below are in fact easier to comprehend. Perhaps a production like > > quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > > would also be an improvement. > > Lada > > > > > It would be: > > > > instance-identifier = 1*("/" (node-identifier [1*key-predicate / > > leaf-list-predicate / > > pos])) > > > > key-predicate = "[" *WSP key-predicate-expr *WSP "]" > > > > key-predicate-expr = node-identifier *WSP "=" *WSP > > ((DQUOTE string DQUOTE) / > > (SQUOTE string SQUOTE)) > > > > leaf-list-predicate = "[" *WSP leaf-list-predicate-expr *WSP "]" > > > > leaf-list-predicate-expr = "." *WSP "=" *WSP > > ((DQUOTE string DQUOTE) / > > (SQUOTE string SQUOTE)) > > > > pos = "[" *WSP positive-integer-value *WSP "]" > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Feb 25 07:15:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482121B2A2A for ; Thu, 25 Feb 2016 07:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 qjPeAEx5Jm02 for ; Thu, 25 Feb 2016 07:15:22 -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 4D7DE1B2A2B for ; Thu, 25 Feb 2016 07:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4408; q=dns/txt; s=iport; t=1456413322; x=1457622922; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YTu6cc123L/0YcMZMUbcvS0xVl1nHD10u50Qj8+kbAI=; b=cHOA404h1KDYcDWv+rKIvb9312hSMqQE72WJpNFgu1sBzj7Epi59mMSl 7PzS8AGoIozGwG77DgIGEdiBFO2aM79DyCTKTa/O1NYaOMh233SyTie+R 031L+nuFz4/ljRKrCwmnGzhhM0clFIQn2bhupaTenBawxa04pZrj9Dhmx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCCGc9W/xbLJq1ehHm6PAENgWaGD?= =?us-ascii?q?QKBdhQBAQEBAQEBZCeEQQEBAQMBOEABEAsOAggJFg8JAwIBAgFFBg0GAgEBF4d?= =?us-ascii?q?8CL5SAQEBAQEBAQEBAQEBAQEBAQEBAReGEoQ6hB2EUgEEjSqJXo1fiSSFUI5JH?= =?us-ascii?q?gEBQoNkPC6IGAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="632887473" 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; 25 Feb 2016 15:15:19 +0000 Received: from [10.63.23.69] (dhcp-ensft1-uk-vla370-10-63-23-69.cisco.com [10.63.23.69]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1PFFJ93030417; Thu, 25 Feb 2016 15:15:19 GMT To: Martin Bjorklund References: <20160225092623.GA19620@elstar.local> <20160225.103143.1397687839661509108.mbj@tail-f.com> <56CED453.6080009@cisco.com> <20160225.121636.2137433316176193967.mbj@tail-f.com> From: Robert Wilton Message-ID: <56CF1A86.1050809@cisco.com> Date: Thu, 25 Feb 2016 15:15:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160225.121636.2137433316176193967.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] explicit mount 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, 25 Feb 2016 15:15:24 -0000 On 25/02/2016 11:16, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi Martin, >> >> On 25/02/2016 09:31, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder wrote: >>>>>> On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote: >>>>>>> Juergen Schoenwaelder wrote: >>>>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>>>>>> >>>>>>>>>> I think the use cases are rather obvious. I build a device and I like >>>>>>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>>>>>> definition of beauty). >>>>>>>>> This would be pretty complicated. Suppose I define my own beautiful >>>>>>>>> structure like this: >>>>>>>>> >>>>>>>>> container my-interfaces { >>>>>>>>> x:mount-point "if" { >>>>>>>>> x:mount-module "ietf-interfaces"; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> container my-routing { >>>>>>>>> x:mount-point "rtr" { >>>>>>>>> x:mount-module "ietf-routing"; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> Note that with the mount-point defined in my draft, each mount-point >>>>>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>>>>>> cross mount points. >>>>>>>> Could be the same here. >>>>>>>> >>>>>>>>> In this case, we have references between ietf-routing and >>>>>>>>> ietf-interfaces. How would they work? >>>>>>>> How do they work in your solution? If interfaces is jailed and routing >>>>>>>> is jailed, how does routing refer to the interfaces? >>>>>>> My solution does not support "name module mount". It only supports >>>>>>> mouting of a "complete" set of modules (that are chrooted) - simply >>>>>>> because this is what we understand, have implemented, and have been >>>>>>> running for the last ~5 years. (The same goes for ODL, I believe). >>>>>> OK. I understand now that the whole set of modules on a mount point >>>>>> form one chroot environment. This was not clear to me yet but of >>>>>> course makes a lot of sense. So a static schema mount would have to >>>>>> define a set of modules and not just a single module to lead to the >>>>>> same chrooted behavior. >>>>> Yes, but then you can't use it to define your own beautiful >>>>> structure. >>>> I am not sure yet why this is the case. >>> Each such mount point is chrooted. This implies that if you want to >>> put module A in some place, and B has a reference to A, A and B must >>> be mounted together. Thus I cannot put them anywhere to form a >>> beautiful hierarchy. >> As long as B is mounted in the same datastore as A then is it possible >> that B could moved to be mounted on some other path? > Yes, but then you'd need some special syntax to say that they are > related. Wouldn't any path references be sufficient to indicate whether the modules are related? > >> References to/from B would need to be fixed up, or are you saying that >> fixing the references is intractable? > I think it would be extremely complicated, both on the server and on > the client side. This probably feels similar (but actually simpler) than mapping between different sets of modules. E.g. mapping from OpenConfig modules to IETF modules, or from OpenConfig/IETF modules to a native device schema. I doubt whether this idea will be particularly well received, but: Would it be possible to programmatically generate a new set of YANG module definitions from the originals with updated paths/references. I.e. both sets of module definitions model exactly the same data, just the location of that data is in different places. A client could then solely interact with the new set of YANG modules if they wished. A function can be programmatically generated and used to map between the two equivalent models with different node paths. I would imagine that this mapping could be done either on the client side or server side. Even if this approach is valid, it would appear to only really solve the "can't use it to define your own beautiful structure.", and I'm not sure whether that's an actual requirement here. Rob > > > /martin > . > From nobody Thu Feb 25 07:16:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7E31B2A2C for ; Thu, 25 Feb 2016 07:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 w69P01EYKL-I for ; Thu, 25 Feb 2016 07:16: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 176FD1B2A1B for ; Thu, 25 Feb 2016 07:16:56 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 417BC1AE0335; Thu, 25 Feb 2016 16:16:55 +0100 (CET) Date: Thu, 25 Feb 2016 16:16:59 +0100 (CET) Message-Id: <20160225.161659.2204602310947308417.mbj@tail-f.com> To: wivory@Brocade.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] Clarification needed for YANG 1.1 XPATH context 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, 25 Feb 2016 15:16:57 -0000 William Ivory wrote: > Hi, > > I'm looking for clarification on the meaning of the following > paragraph in section 6.4.1 (XPATH context) in RFC6020bis: > > 'If a node that exists in the accessible tree has a non-presence > container as a child, then the non-presence container also exists in > the tree.' > > It's unclear to me what this is trying to say, and why - for example, > does this mean that I need to validate any 'must' and 'when' > statements on the child container even when nothing within that child > container is configured? must expressions are always evaluated if the node where the must expression is defined exists, regardless of the number of children this node has. /martin From nobody Thu Feb 25 07:26:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4C81B2A73 for ; Thu, 25 Feb 2016 07:25: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, 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 7g9mtfnNHY_B for ; Thu, 25 Feb 2016 07:25:58 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3EC1B2A71 for ; Thu, 25 Feb 2016 07:25:58 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PFKLkt022669; Thu, 25 Feb 2016 07:25:57 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 216pn6ywah-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 07:25:57 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 08:25:53 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 16:25:51 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Thu, 25 Feb 2016 16:25:51 +0100 From: William Ivory To: Martin Bjorklund Thread-Topic: [netmod] Clarification needed for YANG 1.1 XPATH context Thread-Index: AdFv3R4BwHXZzI6xSlm06BqlW0gmXv//9CSA///uanA= Date: Thu, 25 Feb 2016 15:25:39 +0000 Deferred-Delivery: Thu, 25 Feb 2016 15:25:17 +0000 Message-ID: References: <20160225.161659.2204602310947308417.mbj@tail-f.com> In-Reply-To: <20160225.161659.2204602310947308417.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.156] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250216 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context 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, 25 Feb 2016 15:25:59 -0000 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 25 February 2016 15:17 To: William Ivory Cc: netmod@ietf.org Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context William Ivory wrote: > Hi, > > I'm looking for clarification on the meaning of the following > paragraph in section 6.4.1 (XPATH context) in RFC6020bis: > > 'If a node that exists in the accessible tree has a non-presence > container as a child, then the non-presence container also exists in > the tree.' > > It's unclear to me what this is trying to say, and why - for example, > does this mean that I need to validate any 'must' and 'when' > statements on the child container even when nothing within that child > container is configured? must expressions are always evaluated if the node where the must expression is defined exists, regardless of the number of children this node has. [wivory] So in my example where the child container (non-presence) has NO children, then it doesn't exist, and any must statement on it should not be run. Only when a non-presence container has a non-zero number of children should any 'must' statements on that container be run. [wivory] If that's the case, then would it be correct to say that the intention of this paragraph is as a reminder that one must evaluate 'must' statements on nodes that have no inherent meaning and exist only because they contain child nodes? Thanks, William /martin From nobody Thu Feb 25 07:31:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C301A901E for ; Thu, 25 Feb 2016 07:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 gTQ-vC_Fx3eF for ; Thu, 25 Feb 2016 07:31: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 2331B1ACEF9 for ; Thu, 25 Feb 2016 07:31:02 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BEDD1AE0335; Thu, 25 Feb 2016 16:31:01 +0100 (CET) Date: Thu, 25 Feb 2016 16:31:05 +0100 (CET) Message-Id: <20160225.163105.511576225570588684.mbj@tail-f.com> To: wivory@Brocade.com From: Martin Bjorklund In-Reply-To: References: <20160225.161659.2204602310947308417.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] Clarification needed for YANG 1.1 XPATH context 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, 25 Feb 2016 15:31:08 -0000 William Ivory wrote: > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 25 February 2016 15:17 > To: William Ivory > Cc: netmod@ietf.org > Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context > > William Ivory wrote: > > Hi, > > > > I'm looking for clarification on the meaning of the following > > paragraph in section 6.4.1 (XPATH context) in RFC6020bis: > > > > 'If a node that exists in the accessible tree has a non-presence > > container as a child, then the non-presence container also exists in > > the tree.' > > > > It's unclear to me what this is trying to say, and why - for example, > > does this mean that I need to validate any 'must' and 'when' > > statements on the child container even when nothing within that child > > container is configured? > > must expressions are always evaluated if the node where the must > expression is defined exists, regardless of the number of children > this node has. > > [wivory] So in my example where the child container (non-presence) has > NO children, then it doesn't exist, and any must statement on it > should not be run. Only when a non-presence container has a non-zero > number of children should any 'must' statements on that container be > run. > > [wivory] If that's the case, then would it be correct to say that the > intention of this paragraph is as a reminder that one must evaluate > 'must' statements on nodes that have no inherent meaning and exist > only because they contain child nodes? No; section 7.5.3 says: When a datastore is validated, all "must" constraints are conceptually evaluated once for each node in the accessible tree (see Section 6.4.1). And the quoted paragraph of 6.4.1 says that the NP-container (conceptually) exists if its parent exists - regardless of number of children. So if the parent exists, any must expressions in the NP-container are evaluated. /martin From nobody Thu Feb 25 07:34:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FFA1B2AD9 for ; Thu, 25 Feb 2016 07:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 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, RP_MATCHES_RCVD=-0.006] 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 SVXSFlACP5tn for ; Thu, 25 Feb 2016 07:34: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 D33EE1B2ACD for ; Thu, 25 Feb 2016 07:34:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 6E617181AC8; Thu, 25 Feb 2016 16:34:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456414456; bh=8ox9h3ZEMABxNRPRJMZU6GKrHZHXgaf9usomB67c1XI=; h=From:Date:To; b=giD8BQQQLCxHiIfHaJCUSChyXis59Ykoc5nxXRq4aeBo2vzihyfejjbyY6jJlKp4b gczzyyljKgfU0TrR+OVoC2Ae2EqoSVUMwc+RLZ8AZtX3FcGB5kzHwc5ATuNVjkZoUv mOIVs6EVBGtHRzef9OK6yPmCBZr0Z1ZzIwICmcTE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160225.161002.1324090744270867912.mbj@tail-f.com> Date: Thu, 25 Feb 2016 16:34:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DCD8E77-F906-49F6-A776-31FF2B623D8F@nic.cz> <20160225.145102.1511894162925887050.mbj@tail-f.com> <489B46F2-CF54-4696-A4C9-BDE7295569D6@nic.cz> <20160225.161002.1324090744270867912.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] 'predicate' production 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, 25 Feb 2016 15:34:20 -0000 > On 25 Feb 2016, at 16:10, Martin Bjorklund wrote: >=20 > Hi, >=20 > Here's a summary of the changes: >=20 > OLD: >=20 > instance-identifier =3D 1*("/" (node-identifier *predicate)) >=20 > predicate =3D "[" *WSP (predicate-expr / pos) *WSP "]" >=20 > predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) >=20 > pos =3D non-negative-integer-value >=20 > NEW: >=20 > instance-identifier =3D 1*("/" (node-identifier > [1*key-predicate / > leaf-list-predicate / > pos])) >=20 > key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >=20 > key-predicate-expr =3D node-identifier *WSP "=3D" *WSP = quoted-string >=20 > leaf-list-predicate =3D "[" *WSP leaf-list-predicate-expr *WSP "]" >=20 > leaf-list-predicate-expr =3D "." *WSP "=3D" *WSP quoted-string >=20 > pos =3D "[" *WSP positive-integer-value *WSP "]" >=20 > quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string = SQUOTE) Looks great! Thanks, Lada >=20 >=20 >=20 > /martin >=20 >=20 >=20 > Ladislav Lhotka wrote: >>=20 >>> On 25 Feb 2016, at 14:51, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 25 Feb 2016, at 14:16, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Martin Bjorklund writes: >>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> another ABNF issue: >>>>>>>>=20 >>>>>>>> predicate =3D "[" *WSP (predicate-expr / pos) *WSP = "]" >>>>>>>>=20 >>>>>>>> predicate-expr =3D (node-identifier / ".") *WSP "=3D" *WSP >>>>>>>> ((DQUOTE string DQUOTE) / >>>>>>>> (SQUOTE string SQUOTE)) >>>>>>>>=20 >>>>>>>> pos =3D non-negative-integer-value >>>>>>>>=20 >>>>>>>> non-negative-integer-value =3D "0" / positive-integer-value >>>>>>>>=20 >>>>>>>> The value of 0 shouldn't be allowed for 'pos' because context = position >>>>>>>> in XPath is always positive, i.e. the first list entry is = selected >>>>>>>> with "[1]". >>>>>>>=20 >>>>>>> You are right - I have changed this to: >>>>>>>=20 >>>>>>> pos =3D positive-integer-value >>>>>>=20 >>>>>> Actually, there is another problem: the ABNF allows, for example >>>>>>=20 >>>>>> /if:interfaces/if:interface[1][2] >>>>>>=20 >>>>>> which doesn't make sense. >>>>>=20 >>>>> Yes, you're right. >>>>>=20 >>>>>> So a correct version could be >>>>>>=20 >>>>>> instance-identifier =3D 1*("/" (node-identifier (*predicate / = pos)) >>>>>=20 >>>>> this would make pos mandatory after every node-identifier. It = should >>>>> be:=20 >>>>>=20 >>>>> instance-identifier =3D 1*("/" (node-identifier (*predicate / = *1pos))) >>>>>=20 >>>>> or, in order to match the style in the rest of the grammar: >>>>>=20 >>>>> instance-identifier =3D 1*("/" (node-identifier [1*predicate / = pos])) >>>>=20 >>>> If we want to be really precise, then the predicate for a leaf-list = [ >>>> . =3D 'foo'] can also appear no more than once. >>>=20 >>> Correct. But we can only do so much in the grammar... For example, = we >>> cannot verify that the name and number of keys are correct. >>=20 >> Yes, but these are already semantic constraints. I think the new = productions below are in fact easier to comprehend. Perhaps a production = like >>=20 >> quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) >>=20 >> would also be an improvement. >>=20 >> Lada >>=20 >>>=20 >>> It would be: >>>=20 >>> instance-identifier =3D 1*("/" (node-identifier [1*key-predicate / >>> leaf-list-predicate / >>> pos])) >>>=20 >>> key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >>>=20 >>> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP >>> ((DQUOTE string DQUOTE) / >>> (SQUOTE string SQUOTE)) >>>=20 >>> leaf-list-predicate =3D "[" *WSP leaf-list-predicate-expr *WSP "]" >>>=20 >>> leaf-list-predicate-expr =3D "." *WSP "=3D" *WSP >>> ((DQUOTE string DQUOTE) / >>> (SQUOTE string SQUOTE)) >>>=20 >>> pos =3D "[" *WSP positive-integer-value *WSP "]" >>>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 25 07:51:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69B61B2B32 for ; Thu, 25 Feb 2016 07:51:05 -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 XHyapLBpVIah for ; Thu, 25 Feb 2016 07:51:04 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9A61B2B07 for ; Thu, 25 Feb 2016 07:51:03 -0800 (PST) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PFja7L004928; Thu, 25 Feb 2016 07:50:58 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 219mk4jprr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 07:50:58 -0800 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 08:50:54 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 16:50:51 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Thu, 25 Feb 2016 16:50:51 +0100 From: William Ivory To: Martin Bjorklund Thread-Topic: [netmod] Clarification needed for YANG 1.1 XPATH context Thread-Index: AdFv3R4BwHXZzI6xSlm06BqlW0gmXv//9CSA///uanCAABWHgP//6upg Date: Thu, 25 Feb 2016 15:50:23 +0000 Deferred-Delivery: Thu, 25 Feb 2016 15:50:07 +0000 Message-ID: <304314aebb204bea8aa2e99aeed10b97@EMEAWP-EXMB12.corp.brocade.com> References: <20160225.161659.2204602310947308417.mbj@tail-f.com> <20160225.163105.511576225570588684.mbj@tail-f.com> In-Reply-To: <20160225.163105.511576225570588684.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.156] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250217 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context 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, 25 Feb 2016 15:51:05 -0000 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 25 February 2016 15:31 To: William Ivory Cc: netmod@ietf.org Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context William Ivory wrote: > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 25 February 2016 15:17 > To: William Ivory > Cc: netmod@ietf.org > Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context > > William Ivory wrote: > > Hi, > > > > I'm looking for clarification on the meaning of the following > > paragraph in section 6.4.1 (XPATH context) in RFC6020bis: > > > > 'If a node that exists in the accessible tree has a non-presence > > container as a child, then the non-presence container also exists in > > the tree.' > > > > It's unclear to me what this is trying to say, and why - for > > example, does this mean that I need to validate any 'must' and 'when' > > statements on the child container even when nothing within that > > child container is configured? > > must expressions are always evaluated if the node where the must > expression is defined exists, regardless of the number of children > this node has. > > [wivory] So in my example where the child container (non-presence) has > NO children, then it doesn't exist, and any must statement on it > should not be run. Only when a non-presence container has a non-zero > number of children should any 'must' statements on that container be > run. > > [wivory] If that's the case, then would it be correct to say that the > intention of this paragraph is as a reminder that one must evaluate > 'must' statements on nodes that have no inherent meaning and exist > only because they contain child nodes? No; section 7.5.3 says: When a datastore is validated, all "must" constraints are conceptually evaluated once for each node in the accessible tree (see Section 6.4.1). And the quoted paragraph of 6.4.1 says that the NP-container (conceptually) exists if its parent exists - regardless of number of children. So if the parent exists, any must expressions in the NP-container are evaluated. [wivory] Is the intended use case top-level containers (directly under the root node) where you might wish to enforce that at least one such container existed? In that case there would be no higher level node (as you can't add when/must to root) on which you could attach the 'must'. At any other level in the tree you would always be able to attach the 'must' at a higher level. Or am I missing some use case(s)? Thanks, William /martin From nobody Thu Feb 25 08:35:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168131B2D08 for ; Thu, 25 Feb 2016 08:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 611jKiTfuE1P for ; Thu, 25 Feb 2016 08:35:48 -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 31CB11B2D04 for ; Thu, 25 Feb 2016 08:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3046; q=dns/txt; s=iport; t=1456418148; x=1457627748; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LV7ZP/NlHekyBGP0Q4EqoTyBZLHB0WIal56FQScVjTM=; b=cNOABpSzmcqJzaKOnLDE2VtB9OdUxXnAyPaUhjK8hoPG4GnzcAbEZbN0 QnEopHoUrogeKAP/l4yJu0tnQ18/7NVnLM90QgHW8vpV4QI82otB6R/qH xAomW2r68ypw6FcqcjYq4ZIVSVZjMf2SBb6vKDic69n/zNirmSR4TPKSs E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADSLM9W/xbLJq1ehHm6S4Fmhg0Cg?= =?us-ascii?q?XoTAQEBAQEBAWQnhEIBAQQ4QAEQCw4CCAkWDwkDAgECAUUGDQYCAQEXiAS+GAE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXhhKEOohvAQSNKolejV+JJIVQjkkhAUCDZDwui?= =?us-ascii?q?BgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="649554242" 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; 25 Feb 2016 16:35:46 +0000 Received: from [10.63.23.69] (dhcp-ensft1-uk-vla370-10-63-23-69.cisco.com [10.63.23.69]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1PGZjQ4015113; Thu, 25 Feb 2016 16:35:46 GMT To: Martin Bjorklund References: <20160224223913.GA18519@elstar.local> <20160225.092357.799424283049856775.mbj@tail-f.com> <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> From: Robert Wilton Message-ID: <56CF2D5F.6060009@cisco.com> Date: Thu, 25 Feb 2016 16:35:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160225.094334.1498092398680350689.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] explicit mount 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, 25 Feb 2016 16:35:50 -0000 On 25/02/2016 08:43, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >> >>>> I think the use cases are rather obvious. I build a device and I like >>>> to rearrange existing models into a beautiful hierarchy (for some >>>> definition of beauty). >>> This would be pretty complicated. Suppose I define my own beautiful >>> structure like this: >>> >>> container my-interfaces { >>> x:mount-point "if" { >>> x:mount-module "ietf-interfaces"; >>> } >>> } >>> container my-routing { >>> x:mount-point "rtr" { >>> x:mount-module "ietf-routing"; >>> } >>> } >>> >>> Note that with the mount-point defined in my draft, each mount-point >>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>> cross mount points. >> Could be the same here. >> >>> In this case, we have references between ietf-routing and >>> ietf-interfaces. How would they work? >> How do they work in your solution? If interfaces is jailed and routing >> is jailed, how does routing refer to the interfaces? > My solution does not support "name module mount". It only supports > mouting of a "complete" set of modules (that are chrooted) - simply > because this is what we understand, have implemented, and have been > running for the last ~5 years. (The same goes for ODL, I believe). I have been wondering whether "name module mount" is really about mounting only specific modules, or actually allowing the mounting schema to statically indicate which modules are guaranteed to be present. I.e. specifically it doesn't explicitly prohibit other modules/data nodes from potentially also being mounted at the same path, but in the normal case you wouldn't expect them to be present. My reasoning is that you don't want to have to statically specify in the mounting schema all augmentations, deviations and features. But I also don't think that the mounting schema can guarantee that the mounted schema will always exactly implement the module(s) specified in the schema mount and all features without any augmentations or deviations. So for this to be useful, it means that there has to be a dynamic mechanism to determine exactly what modules has been mounted (e.g. like the ietf-yang-structural-mount module or ysdl). Given this, I think that you could possibly end up with just one "schema mount" with a couple of options: The first option would be an explicit list of modules that are guaranteed to be mounted at that location (or "*" to indicate a "complete" set of modules (that are chrooted). The second option would indicate where the runtime details of the mounted modules can be found: this option might indicate whether details of the mounted modules can be found inline in the data tree at the mount point using yang-library, or separately in the ietf-yang-structural-mount module/ysdl. Rob From nobody Thu Feb 25 10:49:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC91D1B3150 for ; Thu, 25 Feb 2016 10:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nGyH72Jz8n0m for ; Thu, 25 Feb 2016 10:48:57 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3195B1B3145 for ; Thu, 25 Feb 2016 10:48:57 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-29-56cf4c7d5230 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 42.79.32102.D7C4FC65; Thu, 25 Feb 2016 19:48:29 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 13:48:55 -0500 From: Sampathkumar Santhanakrishnan To: "netmod@ietf.org" Thread-Topic: Question on "bits" in YANG Thread-Index: AdFvp4yPrlpBi+eWRxun0pzcY5uwwQ== Date: Thu, 25 Feb 2016 18:48:52 +0000 Message-ID: <5ADC40FCE0FC7140AB4B8FD107A271C4219E9580@eusaamb109.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_5ADC40FCE0FC7140AB4B8FD107A271C4219E9580eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXSPt26tz/kwgz/rzSzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvelrUwF30Qr5r49ydzAuEG4i5GDQ0LAROLq1YIuRk4gU0zi wr31bF2MXBxCAkcYJW4tOMcO4SxnlFjZ0scGUsUmECQx7+9iFhBbREBdYubO9WBxYQFliVV9 /cwQcQ2Jrt2vmSBsPYm9rYfZQWwWAVWJC98msoLYvAK+Es+uzAerYRSQlfjSuBqsl1lAXOLW E4i4hICAxJI955khbFGJl4//sULYShKTlp5jBXmAWSBf4vkcXYiRghInZz5hmcAoNAvJpFkI VbOQVEGU6Egs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKiwtyctONDDcxAoP+mASb4w7G vb2ehxgFOBiVeHg3/D0bJsSaWFZcmXuIUYKDWUmEN8zrfJgQb0piZVVqUX58UWlOavEhRmkO FiVx3rnO68OEBNITS1KzU1MLUotgskwcnFINjGrzVRVOzVz3ZtntnxMbv77eEtLadDeEdWlK aM75H5VTTt9W4J7qHCQZ9uj2hJlCTEIrPu9/r3rBP4dtSk6z1I8ZIXs7L2zjX88hPr2+b7Zx Tde+D1/ftE4VXlDxmO2X7xmNx/NeXJJb+UrB1YbL8eQClhvuLgujeXXOnf2vuXy6mvLDDzu9 LXWUWIozEg21mIuKEwGaj/sXdgIAAA== Archived-At: Subject: [netmod] Question on "bits" 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, 25 Feb 2016 18:49:00 -0000 --_000_5ADC40FCE0FC7140AB4B8FD107A271C4219E9580eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a question on "bits" type in YANG. Does it make sense to use "bits" = in "config:false" attributes ? As per my understanding in the read-only uses cases, the bits "position" is= not much useful. Please clarify. Thanks & Regards, Sampath --_000_5ADC40FCE0FC7140AB4B8FD107A271C4219E9580eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have a question on “bits” type in YANG= . Does it make sense to use “bits” in “config:false”= ; attributes ?

As per my understanding in the read-only uses cases,= the bits “position” is not much useful. Please clarify.

 

Thanks & Regards,

Sampath

--_000_5ADC40FCE0FC7140AB4B8FD107A271C4219E9580eusaamb109erics_-- From nobody Thu Feb 25 11:43:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6231B3340 for ; Thu, 25 Feb 2016 11:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 KKS8XbGPCXDy for ; Thu, 25 Feb 2016 11:43: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 1E3801B333D for ; Thu, 25 Feb 2016 11:43:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2436191F; Thu, 25 Feb 2016 20:43:37 +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 oTigPwk7r6zt; Thu, 25 Feb 2016 20:43:19 +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, 25 Feb 2016 20:43:37 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EFBC20036; Thu, 25 Feb 2016 20:43:37 +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 hnAzsdcwE8M4; Thu, 25 Feb 2016 20:43:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A57F2002C; Thu, 25 Feb 2016 20:43:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EEF3C39FE02F; Thu, 25 Feb 2016 20:43:34 +0100 (CET) Date: Thu, 25 Feb 2016 20:43:34 +0100 From: Juergen Schoenwaelder To: Sampathkumar Santhanakrishnan Message-ID: <20160225194334.GA20558@elstar.local> Mail-Followup-To: Sampathkumar Santhanakrishnan , "netmod@ietf.org" References: <5ADC40FCE0FC7140AB4B8FD107A271C4219E9580@eusaamb109.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ADC40FCE0FC7140AB4B8FD107A271C4219E9580@eusaamb109.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question on "bits" 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: Thu, 25 Feb 2016 19:43:40 -0000 On Thu, Feb 25, 2016 at 06:48:52PM +0000, Sampathkumar Santhanakrishnan wrote: > I have a question on "bits" type in YANG. Does it make sense to use > "bits" in "config:false" attributes ? Yes, why would it not make sense? > As per my understanding in the read-only uses cases, the bits > "position" is not much useful. Please clarify. Why do you think the position is meaningful for config true but not for config false leafs or date that is shipped in RPCs or actions or notifications? Here is the relevant text: The "position" statement, which is optional, takes as an argument a non-negative integer value that specifies the bit's position within a hypothetical bit field. The position value MUST be in the range 0 to 4294967295, and it MUST be unique within the bits type. The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors. The position is a 'convenience to implementors' and this convenience applies equally well to clients and servers. /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 Feb 25 23:25:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C86B1ACDC3 for ; Thu, 25 Feb 2016 23:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 xtM_4wqnmpHI for ; Thu, 25 Feb 2016 23:25: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 A58371ACDC1 for ; Thu, 25 Feb 2016 23:25:02 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id C0F951AE0148; Fri, 26 Feb 2016 08:25:00 +0100 (CET) Date: Fri, 26 Feb 2016 08:25:05 +0100 (CET) Message-Id: <20160226.082505.504004219149309283.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <56CF2D5F.6060009@cisco.com> References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <56CF2D5F.6060009@cisco.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] explicit mount 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, 26 Feb 2016 07:25:04 -0000 Robert Wilton wrote: > > > On 25/02/2016 08:43, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: > >> > >>>> I think the use cases are rather obvious. I build a device and I like > >>>> to rearrange existing models into a beautiful hierarchy (for some > >>>> definition of beauty). > >>> This would be pretty complicated. Suppose I define my own beautiful > >>> structure like this: > >>> > >>> container my-interfaces { > >>> x:mount-point "if" { > >>> x:mount-module "ietf-interfaces"; > >>> } > >>> } > >>> container my-routing { > >>> x:mount-point "rtr" { > >>> x:mount-module "ietf-routing"; > >>> } > >>> } > >>> > >>> Note that with the mount-point defined in my draft, each mount-point > >>> becomes itw own "jailed" or "chrooted" tree. So references cannot > >>> cross mount points. > >> Could be the same here. > >> > >>> In this case, we have references between ietf-routing and > >>> ietf-interfaces. How would they work? > >> How do they work in your solution? If interfaces is jailed and routing > >> is jailed, how does routing refer to the interfaces? > > My solution does not support "name module mount". It only supports > > mouting of a "complete" set of modules (that are chrooted) - simply > > because this is what we understand, have implemented, and have been > > running for the last ~5 years. (The same goes for ODL, I believe). > I have been wondering whether "name module mount" is really about > mounting only specific modules, or actually allowing the mounting > schema to statically indicate which modules are guaranteed to be > present. I.e. specifically it doesn't explicitly prohibit other > modules/data nodes from potentially also being mounted at the same > path, but in the normal case you wouldn't expect them to be present. This was my thinking as well. But then the "random rearrangemt of modules to get a more beautiful layot" use case doesn't apply. And if you start to do "ymnt:require-module" you probably also need to specify "required-feature" and "required-revision"... So, before exploring possible solutions, it would be great if we agreed on the problem to solve. Does anyone have a use case for explicit naming of modules to be mounted in the schema? /martin > > My reasoning is that you don't want to have to statically specify in > the mounting schema all augmentations, deviations and features. But I > also don't think that the mounting schema can guarantee that the > mounted schema will always exactly implement the module(s) specified > in the schema mount and all features without any augmentations or > deviations. > > So for this to be useful, it means that there has to be a dynamic > mechanism to determine exactly what modules has been mounted > (e.g. like the ietf-yang-structural-mount module or ysdl). > > Given this, I think that you could possibly end up with just one > "schema mount" with a couple of options: > > The first option would be an explicit list of modules that are > guaranteed to be mounted at that location (or "*" to indicate a > "complete" set of modules (that are chrooted). > > The second option would indicate where the runtime details of the > mounted modules can be found: this option might indicate whether > details of the mounted modules can be found inline in the data tree at > the mount point using yang-library, or separately in the > ietf-yang-structural-mount module/ysdl. > > Rob > From nobody Fri Feb 26 00:43:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD741ACE94; Fri, 26 Feb 2016 00:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 CNfE2QGu_-SX; Fri, 26 Feb 2016 00:32:51 -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 EC97B1AC399; Fri, 26 Feb 2016 00:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6759; q=dns/txt; s=iport; t=1456475571; x=1457685171; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mN2yoXuqAs/pAizmZtMM/8R8GfELrH1vFsH08fIY3dA=; b=Rz7vcHtIs7j02NRie91rTc7j7qZAL1Mjztq/dyY8IjDvKKbyMbILsh4b vaOk2nBpM8nh/9ho+ohWnpAt6dPug9eEIJ2AZhxenIdHQ87U7Z+s9cGpV zGgYsRgJAMfTmWuxhlqVOc8Jmy3fiUXpi3nA90liM5mpsNnfOdVu57Uv2 c=; X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="635733328" 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; 26 Feb 2016 08:32:49 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1Q8Wi4X019114; Fri, 26 Feb 2016 08:32:45 GMT To: Ladislav Lhotka References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com> <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> From: Benoit Claise Message-ID: <56D00DAB.7060302@cisco.com> Date: Fri, 26 Feb 2016 09:32:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 26 Feb 2016 00:43:49 -0800 Cc: Santosh Esale , joel jaeggli , rtg-ads@ietf.org, Ross Callon , Adrian Farrel , "Sowmya Krishnaswamy \(sowkrish\)" , Xufeng Liu , Brian Haberman , NETMOD WG , George Swallow , jescia.chenxia@huawei.com, "Rajiv Asati \(rajiva\)" , int-ads@ietf.org, "Kamran Raza \(skraza\)" , Jeff Tantsura , "Bocci, Matthew \(Matthew\)" , Adrian Farrel , Loa Andersson , ops-ads@ietf.org Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] 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, 26 Feb 2016 08:32:54 -0000 Hi Lada, > Hi Benoit, > > this was discussed a while ago in this thread: > > https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I > > tl;dr: The WG decision then was to introduce a new type in ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the semantics of an IPv4 address - it is an uint32 number that's expressed in the dotted quad format, which is what most router platforms accept as routerID via CLI. From what I understand below, this is not an acceptable solution. I'm sure the routing experts will confirm this. Regards, Benoit > > Lada > >> On 25 Feb 2016, at 13:41, Benoit Claise wrote: >> >> Dear all, >> >> Sorry for the delay (mix of vacation and business travel). >> >> Let me try to summarize the situation as I see it: >> - From the routing RFCs, BGP Identifier, OSPF router ID, TE identifier, and LSR identifiers are all an unsigned integers. >> - We need consistency for the router ID and identifier in YANG leaf/typedef >> - The OSPF MIB module has defined >> RouterID ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "A OSPF Router Identifier. >> Note that the Router ID, in OSPF, has the same format >> as an IP address, but identifies the router independent >> of its IP address." >> SYNTAX IpAddress >> >> >> ospfRouterId OBJECT-TYPE >> SYNTAX RouterID >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A 32-bit integer uniquely identifying the >> router in the Autonomous System. >> By convention, to ensure uniqueness, this >> should default to the value of one of the >> router's IP interface addresses. >> >> As Adrian mentioned: it is NOT an IP address but the MIB module uses the notational formatting of n IP address for display purposes. >> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 environment >> >> Based on this, I believe that: >> - We must not associate an IP address semantic with the router ID >> - Based on Brian's feedback (which I agree with) "As long as the YANG module does not specify a format that makes the routerID display like an IPv4 address", it was probably a mistake to have defined RouterID as IpAdress in OSPF MIB module. >> - Interestingly, https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains: >> >> grouping router-id { >> description >> "This grouping provides router ID."; >> leaf router-id { >> type yang:dotted-quad; >> description >> "A 32-bit number in the form of a dotted quad that is used by >> some routing protocols identifying a router."; >> reference >> " >> RFC 2328 >> : OSPF Version 2."; >> } >> } >> >> This should be an uint32 number. >> - An union-based solution is a bad compromise >> From draft-raza-mpls-ldp-mldp-yang-02 >> leaf lsr-id { >> type union { >> type yang:dotted-quad; >> type uint32; >> } >> description "LSR ID."; >> >> >> >> Since the question was asked: as AD, I would support uint32 everywhere. >> >> Now, practically, how to move forward? >> - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with the uint32 modification), >> - Or you create a "Common Routing YANG Data Types", similarly to RFC 6991 including the router IDs. I see already many typedef in draft-raza-mpls-ldp-mldp-yang-02 >> - Or you define you own types in your own draft >> >> But, if we have agreement on the uint32, let's document this now somewhere/somehow, and let's not revisit this on regular basis (yes, I see it coming...) >> A few lines of explanation in the draft would already help for example, in an operational section, explaining to people the mapping of the MIB OSPF RouterID to the YANG object >> >> Regards, Benoit >>> Hi Adrian, >>> >>> On 2/16/16 7:53 AM, Adrian Farrel wrote: >>> >>>> Hi Brian, >>>> >>>> I said I wasn't going to participate in this discussion :-) >>>> >>> Nice try. ;) >>> >>> >>>>>> I should not respond to questions that I don't fully understand, but: >>>>>> >>>>>> the BGP Identifier is an unsigned integer >>>>>> the OSPF router ID is an unsigned integer >>>>>> >>>>> I assume the above is based on the YANG definition of OSPF routerID. RFC >>>>> 4750 says the routerID is an IPv4 address. Is that an issue? >>>>> >>>> To quote from 4750... >>>> >>>> RouterID ::= TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A OSPF Router Identifier. >>>> Note that the Router ID, in OSPF, has the same format >>>> as an IP address, but identifies the router independent >>>> of its IP address." >>>> SYNTAX IpAddress >>>> >>>> So it explicitly says it is NOT an IP address but the MIB module uses the notational formatting of n IP address for display purposes. >>>> >>>> I think this is done because the router ID is often chosen to be an IP address of the router, and because it is easier for humans to deal with a.b.c.d where each element is a 3-digit number less than 256, than it is to manage a single number in the range 0 to 2^32 -1. >>>> >>>> >>> The above is the textual convention, whereas the following is the actual >>> OSPF routerID... >>> >>> ospfRouterId OBJECT-TYPE >>> SYNTAX RouterID >>> MAX-ACCESS read-write >>> STATUS current >>> DESCRIPTION >>> "A 32-bit integer uniquely identifying the >>> router in the Autonomous System. >>> By convention, to ensure uniqueness, this >>> should default to the value of one of the >>> router's IP interface addresses. >>> >>> So the MIB actually says the default is to use an IPv4 address... >>> >>> All that being said, my point was further along where I said: >>> >>> >>>>> I am not concerned with what the operator will choose as his/her >>>>> routerID value. I am concerned with what format options will be >>>>> associated with the routerID in the yang module. As long as the format >>>>> options does not allow display in dotted decimal notation, I am fine. >>>>> >>> As long as the YANG module does not specify a format that makes the >>> routerID display like an IPv4 address, I am fine. >>> >>> Brian >>> >>> >>> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > . > From nobody Fri Feb 26 03:00:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5DC1A894E for ; Fri, 26 Feb 2016 03:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.907 X-Spam-Level: X-Spam-Status: No, score=-13.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 LwdD2idiN_bJ for ; Fri, 26 Feb 2016 03:00: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 341071A87ED for ; Fri, 26 Feb 2016 03:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4874; q=dns/txt; s=iport; t=1456484454; x=1457694054; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/eI2v99y8cKSk7y2eRaDy3zcqJKdwZ23Lz4UdhOTv7I=; b=UsJfeabIyEKVdS3ehqKrPSgY3VdWpp7lhIDdPJE65Sap+pJG4qvGRrzS fyGrhGLylBBSHF1gzRnZcaHIDqi+LjW79PDKskkS29qTcu+pm1HRXfihY 0z4Y5jHlAlSOGGc9zO3mF8yL9xLAg6L6yYu8KwkvqBde5zeqLTPn91Myf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAABL9BW/xbLJq1ehHm8P4YTAoIRA?= =?us-ascii?q?QEBAQEBZSeEQQEBAQMBOEABEAsOAggJFg8JAwIBAgFFBg0GAgEBF4d8CL07AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAReGEoM9fYhvAQSNKolejWCJJIVQjklig2Q8Log1A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="625701536" 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; 26 Feb 2016 11:00:51 +0000 Received: from [10.63.23.69] (dhcp-ensft1-uk-vla370-10-63-23-69.cisco.com [10.63.23.69]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1QB0p3M030587; Fri, 26 Feb 2016 11:00:51 GMT To: Martin Bjorklund References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <56CF2D5F.6060009@cisco.com> <20160226.082505.504004219149309283.mbj@tail-f.com> From: Robert Wilton Message-ID: <56D03063.1060003@cisco.com> Date: Fri, 26 Feb 2016 11:00:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160226.082505.504004219149309283.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] explicit mount 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, 26 Feb 2016 11:00:56 -0000 On 26/02/2016 07:25, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 25/02/2016 08:43, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>> >>>>>> I think the use cases are rather obvious. I build a device and I like >>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>> definition of beauty). >>>>> This would be pretty complicated. Suppose I define my own beautiful >>>>> structure like this: >>>>> >>>>> container my-interfaces { >>>>> x:mount-point "if" { >>>>> x:mount-module "ietf-interfaces"; >>>>> } >>>>> } >>>>> container my-routing { >>>>> x:mount-point "rtr" { >>>>> x:mount-module "ietf-routing"; >>>>> } >>>>> } >>>>> >>>>> Note that with the mount-point defined in my draft, each mount-point >>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>> cross mount points. >>>> Could be the same here. >>>> >>>>> In this case, we have references between ietf-routing and >>>>> ietf-interfaces. How would they work? >>>> How do they work in your solution? If interfaces is jailed and routing >>>> is jailed, how does routing refer to the interfaces? >>> My solution does not support "name module mount". It only supports >>> mouting of a "complete" set of modules (that are chrooted) - simply >>> because this is what we understand, have implemented, and have been >>> running for the last ~5 years. (The same goes for ODL, I believe). >> I have been wondering whether "name module mount" is really about >> mounting only specific modules, or actually allowing the mounting >> schema to statically indicate which modules are guaranteed to be >> present. I.e. specifically it doesn't explicitly prohibit other >> modules/data nodes from potentially also being mounted at the same >> path, but in the normal case you wouldn't expect them to be present. > This was my thinking as well. But then the "random rearrangemt of > modules to get a more beautiful layot" use case doesn't apply. > > And if you start to do "ymnt:require-module" you probably also need to > specify "required-feature" and "required-revision"... Yes, I don't know if you would have to require those, but I can see that it would be useful to at least allow them. > > So, before exploring possible solutions, it would be great if we > agreed on the problem to solve. Does anyone have a use case for > explicit naming of modules to be mounted in the schema? I might be mistaken, but an example use case of this may have been given in the Yokohama L3SM WG meeting. That WG has a desire to build service level YANG models, and for such models I think that there are some scenarios where it may be desirable to build those service level models by reusing some of the device level YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted) rather than having to independently develop closely related copies of those YANG modules located at different schema paths which might potentially diverge over time. However, if this was the scenario considered then it is unclear to me whether you would want to mount the entirety of a QoS device level model, or would just want parts of it. Arguably groupings may be a better solution here, but their usefulness depends on whether the device level model has been constructed in a way to make reuse of parts of that model feasible. Rob > > > /martin > > >> My reasoning is that you don't want to have to statically specify in >> the mounting schema all augmentations, deviations and features. But I >> also don't think that the mounting schema can guarantee that the >> mounted schema will always exactly implement the module(s) specified >> in the schema mount and all features without any augmentations or >> deviations. >> >> So for this to be useful, it means that there has to be a dynamic >> mechanism to determine exactly what modules has been mounted >> (e.g. like the ietf-yang-structural-mount module or ysdl). >> >> Given this, I think that you could possibly end up with just one >> "schema mount" with a couple of options: >> >> The first option would be an explicit list of modules that are >> guaranteed to be mounted at that location (or "*" to indicate a >> "complete" set of modules (that are chrooted). >> >> The second option would indicate where the runtime details of the >> mounted modules can be found: this option might indicate whether >> details of the mounted modules can be found inline in the data tree at >> the mount point using yang-library, or separately in the >> ietf-yang-structural-mount module/ysdl. >> >> Rob >> > . > From nobody Fri Feb 26 03:13:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2F1AD36F for ; Fri, 26 Feb 2016 03:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 k9B6vnMA0G3C for ; Fri, 26 Feb 2016 03:13:54 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id DEE8D1AD2AF for ; Fri, 26 Feb 2016 03:13:53 -0800 (PST) Received: (qmail 2635 invoked by uid 0); 26 Feb 2016 11:13:52 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 26 Feb 2016 11:13:52 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id NzDi1s00Q2SSUrH01zDlyP; Fri, 26 Feb 2016 04:13:52 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=MeZh5z87hkCquJM1ShQA:9 a=C03CumWzXhbhgZfo:21 a=E228mg96v9UfhWEM:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=1L4lP3xa3UYk4TWgUrJMBCP3aKhVPIbDQWxBTmyIvsQ=; b=vgOq86uWqHzikIER2/cXBjKAULSN3NRTBMvxmcc7MqV7BXMNi7uJoTLsT85/X/VCEY7VwwqfwEbxBUTDBUVVkckQ++PiRd2hPsww34wgyi/IjeZGTxolf1wroPfnx+pu; Received: from [100.15.91.238] (port=57556 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aZGL8-0000v7-F0; Fri, 26 Feb 2016 04:13:42 -0700 From: Lou Berger To: Robert Wilton , Martin Bjorklund Date: Fri, 26 Feb 2016 06:13:39 -0500 Message-ID: <1531d48bab8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <56D03063.1060003@cisco.com> References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <56CF2D5F.6060009@cisco.com> <20160226.082505.504004219149309283.mbj@tail-f.com> <56D03063.1060003@cisco.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 26 Feb 2016 11:13:55 -0000 Rob/Martin, On February 26, 2016 6:01:23 AM Robert Wilton wrote: > > > On 26/02/2016 07:25, Martin Bjorklund wrote: >> Robert Wilton wrote: >>> >>> On 25/02/2016 08:43, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>>> >>>>>>> I think the use cases are rather obvious. I build a device and I like >>>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>>> definition of beauty). >>>>>> This would be pretty complicated. Suppose I define my own beautiful >>>>>> structure like this: >>>>>> >>>>>> container my-interfaces { >>>>>> x:mount-point "if" { >>>>>> x:mount-module "ietf-interfaces"; >>>>>> } >>>>>> } >>>>>> container my-routing { >>>>>> x:mount-point "rtr" { >>>>>> x:mount-module "ietf-routing"; >>>>>> } >>>>>> } >>>>>> >>>>>> Note that with the mount-point defined in my draft, each mount-point >>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>>> cross mount points. >>>>> Could be the same here. >>>>> >>>>>> In this case, we have references between ietf-routing and >>>>>> ietf-interfaces. How would they work? >>>>> How do they work in your solution? If interfaces is jailed and routing >>>>> is jailed, how does routing refer to the interfaces? >>>> My solution does not support "name module mount". It only supports >>>> mouting of a "complete" set of modules (that are chrooted) - simply >>>> because this is what we understand, have implemented, and have been >>>> running for the last ~5 years. (The same goes for ODL, I believe). >>> I have been wondering whether "name module mount" is really about >>> mounting only specific modules, or actually allowing the mounting >>> schema to statically indicate which modules are guaranteed to be >>> present. I.e. specifically it doesn't explicitly prohibit other >>> modules/data nodes from potentially also being mounted at the same >>> path, but in the normal case you wouldn't expect them to be present. >> This was my thinking as well. But then the "random rearrangemt of >> modules to get a more beautiful layot" use case doesn't apply. >> >> And if you start to do "ymnt:require-module" you probably also need to >> specify "required-feature" and "required-revision"... > Yes, I don't know if you would have to require those, but I can see that > it would be useful to at least allow them. > >> >> So, before exploring possible solutions, it would be great if we >> agreed on the problem to solve. Does anyone have a use case for >> explicit naming of modules to be mounted in the schema? > I might be mistaken, but an example use case of this may have been given > in the Yokohama L3SM WG meeting. > > That WG has a desire to build service level YANG models, and for such > models I think that there are some scenarios where it may be desirable > to build those service level models by reusing some of the device level > YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted) > rather than having to independently develop closely related copies of > those YANG modules located at different schema paths which might > potentially diverge over time. > L3SM and bgp was the case I referred to in the interim and commonly use as an example. (Although I wasn't part of the Yokohama discussion you mentioned.) > However, if this was the scenario considered then it is unclear to me > whether you would want to mount the entirety of a QoS device level > model, or would just want parts of it. Arguably groupings may be a > better solution here, but their usefulness depends on whether the device > level model has been constructed in a way to make reuse of parts of that > model feasible. > This probably would work if we had augmentable groupings or maybe "root less" containers -- need to think a bit more about the latter.... Lou > Rob > > >> >> >> /martin >> >> >>> My reasoning is that you don't want to have to statically specify in >>> the mounting schema all augmentations, deviations and features. But I >>> also don't think that the mounting schema can guarantee that the >>> mounted schema will always exactly implement the module(s) specified >>> in the schema mount and all features without any augmentations or >>> deviations. >>> >>> So for this to be useful, it means that there has to be a dynamic >>> mechanism to determine exactly what modules has been mounted >>> (e.g. like the ietf-yang-structural-mount module or ysdl). >>> >>> Given this, I think that you could possibly end up with just one >>> "schema mount" with a couple of options: >>> >>> The first option would be an explicit list of modules that are >>> guaranteed to be mounted at that location (or "*" to indicate a >>> "complete" set of modules (that are chrooted). >>> >>> The second option would indicate where the runtime details of the >>> mounted modules can be found: this option might indicate whether >>> details of the mounted modules can be found inline in the data tree at >>> the mount point using yang-library, or separately in the >>> ietf-yang-structural-mount module/ysdl. >>> >>> Rob >>> >> . >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Feb 26 03:30:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575C41A9077 for ; Fri, 26 Feb 2016 03:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 Wi_slQBFXiJq for ; Fri, 26 Feb 2016 03:30:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF81B29DF for ; Fri, 26 Feb 2016 03:30:44 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E13F1AE0311 for ; Fri, 26 Feb 2016 12:30:43 +0100 (CET) Date: Fri, 26 Feb 2016 12:30:48 +0100 (CET) Message-Id: <20160226.123048.730666206432183871.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_Feb_26_12_30_48_2016_410)--" Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-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: Fri, 26 Feb 2016 11:30:46 -0000 ----Next_Part(Fri_Feb_26_12_30_48_2016_410)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have posted a new version of the structural mount draft, based on feedback from the interim. This version adds an option to require mounting of ietf-yang-library. I also discuss two alternative solutions in an appendix. /martin ----Next_Part(Fri_Feb_26_12_30_48_2016_410)-- 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 A87561AE0311 for ; Fri, 26 Feb 2016 12:28:35 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E11B29F3 for ; Fri, 26 Feb 2016 03:28:34 -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-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226112834.1968.72436.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 03:28:34 -0800 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 51 0.017722 0.017144 ################################################ 0.10 2 0.117974 0.021616 ## 0.20 0 0.000000 0.021616 0.30 0 0.000000 0.021616 0.40 0 0.000000 0.021616 0.50 0 0.000000 0.021616 0.60 0 0.000000 0.021616 0.70 0 0.000000 0.021616 0.80 0 0.000000 0.021616 0.90 0 0.000000 0.021616 A new version of I-D, draft-bjorklund-netmod-structural-mount-02.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-bjorklund-netmod-structural-mount Revision: 02 Title: YANG Structural Mount Document date: 2016-02-26 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-structural-mount-02.txt Status: https://datatracker.ietf.org/doc/draft-bjorklund-netmod-structural-mount/ Htmlized: https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-bjorklund-netmod-structural-mount-02 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_Feb_26_12_30_48_2016_410)---- From nobody Fri Feb 26 05:36:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4540D1B2B0D for ; Fri, 26 Feb 2016 05:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 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, RP_MATCHES_RCVD=-0.006] 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 AN-iG6qIXkVD for ; Fri, 26 Feb 2016 05:36:19 -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 C531B1ACE71 for ; Fri, 26 Feb 2016 05:36:18 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1ce6:d7fe:806f:4ee1] (unknown [IPv6:2001:718:1a02:1:1ce6:d7fe:806f:4ee1]) by mail.nic.cz (Postfix) with ESMTPSA id D9C4C181BFD for ; Fri, 26 Feb 2016 14:36:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456493774; bh=5YlMjhNcEGMVHji/CmuHuGO47efBr9nvXQU1p7wRI9M=; h=From:Date:To; b=YrfqV17NYlVRGosWnj9KeK279OEn5gjcqgS93R7UL+gvj+jrp0PDUan+rOfn8mIOf /d3d1iB+0gnAq1biYYvf4SgxCC8IbDlvnH9IvFbuNkL+Ntwh74hezuDv6W9S0JqlSN yX3CLhKsgWkrTNEPUeXjok/7njp1qqxfZxCXixTk= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> Date: Fri, 26 Feb 2016 14:36:30 +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] proposed change to ietf-routing 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, 26 Feb 2016 13:36:20 -0000 Hi, as a part of synchronization of the routing data models that are being = developed by the NETMOD and RTG working groups, the authors of = draft-ietf-netmod-routing-cfg propose to remove the routing-instance = level in the data hierarchy, and leave it to structural-mount/YSDL to = provide a top level structure. Schematically, the configuration and state data subtrees of ietf-routing = would be reduced to something like this: module: ietf-routing +--ro routing-state | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | ... | +--ro ribs | +--ro rib* [name] | ... +--rw routing +--rw router-id? yang:dotted-quad +--rw description? string +--rw routing-protocols | +--rw routing-protocol* [type name] | ... +--rw ribs +--rw rib* [name] ... Are there any objections to this change? Thanks, Acee and Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 26 05:37:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F9E1A0031; Fri, 26 Feb 2016 04:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 51WBnWLsIspS; Fri, 26 Feb 2016 04:13:44 -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 49CB51A0052; Fri, 26 Feb 2016 04:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10596; q=dns/txt; s=iport; t=1456488824; x=1457698424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VobuWG61uXjUFXv8IwnD9OXz4hrrJ+UUi9p1EI6inl0=; b=FEstNs/ZLGuZFCF/gm3gyrGqHKbuvYG2jmSOl+QpwmKCpS7eR/Wg6UWA SZ2ca2GRMKRzA3Pst3Bhj2zMk31dYPjNw7O2wnbSYz3JbfQ99SZn8Dbt+ XBHeHR1wUlQca+BRmxj2NH4ZCtBfMEY6zWmDJlnMpq7RqwtMb68gRb66j Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQCZQNBW/4gNJK1egzpSbQa6RQENg?= =?us-ascii?q?WYXDIUmSgIcgSo4FAEBAQEBAQFkJ4RCAQEEAQEBIBE3AwsQAgEIGAICHwcCAgI?= =?us-ascii?q?lCxUQAgQBDQUbiAQOrjuOVgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4lRgiiFD?= =?us-ascii?q?YE6BZcIAYVXiAiBXodphS2OSAEeAQFCggMZFIE0aoc3fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="241011635" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2016 12:13:43 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1QCDg7V015894 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 12:13:42 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 06:13:42 -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; Fri, 26 Feb 2016 06:13:42 -0600 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" , Ladislav Lhotka Thread-Topic: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] Thread-Index: AQHRb9DmpmJ/M3F6OEK7UQLfQDjiaZ8+ZXmA///p5QA= Date: Fri, 26 Feb 2016 12:13:42 +0000 Message-ID: References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com> <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> <56D00DAB.7060302@cisco.com> In-Reply-To: <56D00DAB.7060302@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: <99EA34B123B09347AEF9CBE3FB243016@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 26 Feb 2016 05:37:10 -0800 Cc: "Bocci, Matthew \(Matthew\)" , Brian Haberman , "ops-ads@ietf.org" , Santosh Esale , NETMOD WG , "rtg-ads@ietf.org" , George Swallow , Adrian Farrel , "Kamran Raza \(skraza\)" , joel jaeggli , "jescia.chenxia@huawei.com" , Loa Andersson , "int-ads@ietf.org" , Jeff Tantsura , Ross Callon , Adrian Farrel , "Rajiv Asati \(rajiva\)" , "Sowmya Krishnaswamy \(sowkrish\)" , Xufeng Liu Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] 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, 26 Feb 2016 12:13:46 -0000 SGkgQmVub2l0LCBMYWRhLCANCg0KT24gMi8yNi8xNiwgMzozMiBBTSwgIm5ldG1vZCBvbiBiZWhh bGYgb2YgQmVub2l0IENsYWlzZSAoYmNsYWlzZSkiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIExhZGEsDQo+DQo+ PiBIaSBCZW5vaXQsDQo+Pg0KPj4gdGhpcyB3YXMgZGlzY3Vzc2VkIGEgd2hpbGUgYWdvIGluIHRo aXMgdGhyZWFkOg0KPj4NCj4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv bmV0bW9kL1RlaHJNQWJvWC1jTW1tWDUzN3JzODFETmwzSQ0KPj4NCj4+IHRsO2RyOiBUaGUgV0cg ZGVjaXNpb24gdGhlbiB3YXMgdG8gaW50cm9kdWNlIGEgbmV3IHR5cGUgaW4NCj4+aWV0Zi1pbmV0 LXR5cGVzLCBuYW1lbHkgImRvdHRlZC1xdWFkIiwgdGhhdCBleHBsaWNpdGx5IGRvZXMgTk9UIGhh dmUgdGhlDQo+PnNlbWFudGljcyBvZiBhbiBJUHY0IGFkZHJlc3MgLSBpdCBpcyBhbiB1aW50MzIg bnVtYmVyIHRoYXQncyBleHByZXNzZWQNCj4+aW4gdGhlIGRvdHRlZCBxdWFkIGZvcm1hdCwgd2hp Y2ggaXMgd2hhdCBtb3N0IHJvdXRlciBwbGF0Zm9ybXMgYWNjZXB0IGFzDQo+PnJvdXRlcklEIHZp YSBDTEkuDQo+DQo+IEZyb20gd2hhdCBJIHVuZGVyc3RhbmQgYmVsb3csIHRoaXMgaXMgbm90IGFu IGFjY2VwdGFibGUgc29sdXRpb24uDQo+SSdtIHN1cmUgdGhlIHJvdXRpbmcgZXhwZXJ0cyB3aWxs IGNvbmZpcm0gdGhpcy4NCg0KQXQgbGVhc3QgZm9yIHRoZSBPU1BGIFJvdXRlciBJRCAoUkZDIDIz MjgpIGFuZCB0aGUgQkdQIElkZW50aWZpZXIgKFJGQw0KNDI3MSksIHRoZSBkb3R0ZWQtcXVhZCB0 eXBlIG1hdGNoZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2xzLiBUaGUNCnZhbHVlIGlz IG5vdCBuZWNlc3NhcmlseSBhIHJvdXRhYmxlIGFkZHJlc3MgYW5kIHNvbGVseSBhIHVuaXF1ZSAz Mi1iaXQNCmlkZW50aWZpZXIgd2l0aGluIHRoZSBwcm90b2NvbCByb3V0aW5nIGRvbWFpbiB0aGF0 IGlzIGNvbW1vbmx5IGV4cHJlc3NlZA0KaW4gZG90dGVkIHF1YWQgZm9ybWF0LiBXaGF0IGlzIHRo ZSBwcm9ibGVtIHdpdGggdXNpbmcgdGhpcyBZQU5HIHR5cGU/DQoNClRoYW5rcywNCkFjZWUNCg0K Pg0KPlJlZ2FyZHMsIEJlbm9pdA0KPj4NCj4+IExhZGENCj4+DQo+Pj4gT24gMjUgRmViIDIwMTYs IGF0IDEzOjQxLCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4N Cj4+PiBEZWFyIGFsbCwNCj4+Pg0KPj4+IFNvcnJ5IGZvciB0aGUgZGVsYXkgKG1peCBvZiB2YWNh dGlvbiBhbmQgYnVzaW5lc3MgdHJhdmVsKS4NCj4+Pg0KPj4+IExldCBtZSB0cnkgdG8gc3VtbWFy aXplIHRoZSBzaXR1YXRpb24gYXMgSSBzZWUgaXQ6DQo+Pj4gLSBGcm9tIHRoZSByb3V0aW5nIFJG Q3MsIEJHUCBJZGVudGlmaWVyLCBPU1BGIHJvdXRlciBJRCwgVEUNCj4+PmlkZW50aWZpZXIsIGFu ZCBMU1IgaWRlbnRpZmllcnMgYXJlIGFsbCBhbiB1bnNpZ25lZCBpbnRlZ2Vycy4NCj4+PiAtIFdl IG5lZWQgY29uc2lzdGVuY3kgZm9yIHRoZSByb3V0ZXIgSUQgYW5kIGlkZW50aWZpZXIgaW4gWUFO Rw0KPj4+bGVhZi90eXBlZGVmDQo+Pj4gLSBUaGUgT1NQRiBNSUIgbW9kdWxlIGhhcyBkZWZpbmVk DQo+Pj4gUm91dGVySUQgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KPj4+ICAgICAgICAgU1RBVFVT ICAgICAgIGN1cnJlbnQNCj4+PiAgICAgICAgIERFU0NSSVBUSU9ODQo+Pj4gICAgICAgICAgICAi QSBPU1BGIFJvdXRlciBJZGVudGlmaWVyLg0KPj4+ICAgICAgICAgICAgIE5vdGUgdGhhdCB0aGUg Um91dGVyIElELCBpbiBPU1BGLCBoYXMgdGhlIHNhbWUgZm9ybWF0DQo+Pj4gICAgICAgICAgICAg YXMgYW4gSVAgYWRkcmVzcywgYnV0IGlkZW50aWZpZXMgdGhlIHJvdXRlciBpbmRlcGVuZGVudA0K Pj4+ICAgICAgICAgICAgIG9mIGl0cyBJUCBhZGRyZXNzLiINCj4+PiAgICAgICAgIFNZTlRBWCAg ICAgICBJcEFkZHJlc3MNCj4+Pg0KPj4+DQo+Pj4gICAgb3NwZlJvdXRlcklkIE9CSkVDVC1UWVBF DQo+Pj4gICAgICAgICBTWU5UQVggICAgICAgUm91dGVySUQNCj4+PiAgICAgICAgIE1BWC1BQ0NF U1MgICByZWFkLXdyaXRlDQo+Pj4gICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudA0KPj4+ICAg ICAgICAgREVTQ1JJUFRJT04NCj4+PiAgICAgICAgICAgICJBIDMyLWJpdCBpbnRlZ2VyIHVuaXF1 ZWx5IGlkZW50aWZ5aW5nIHRoZQ0KPj4+ICAgICAgICAgICAgcm91dGVyIGluIHRoZSBBdXRvbm9t b3VzIFN5c3RlbS4NCj4+PiAgICAgICAgICAgIEJ5IGNvbnZlbnRpb24sIHRvIGVuc3VyZSB1bmlx dWVuZXNzLCB0aGlzDQo+Pj4gICAgICAgICAgICBzaG91bGQgZGVmYXVsdCB0byB0aGUgdmFsdWUg b2Ygb25lIG9mIHRoZQ0KPj4+ICAgICAgICAgICAgcm91dGVyJ3MgSVAgaW50ZXJmYWNlIGFkZHJl c3Nlcy4NCj4+Pg0KPj4+IEFzIEFkcmlhbiBtZW50aW9uZWQ6IGl0IGlzIE5PVCBhbiBJUCBhZGRy ZXNzIGJ1dCB0aGUgTUlCIG1vZHVsZSB1c2VzDQo+Pj50aGUgbm90YXRpb25hbCBmb3JtYXR0aW5n IG9mIG4gSVAgYWRkcmVzcyBmb3IgZGlzcGxheSBwdXJwb3Nlcy4NCj4+PiAtIEFuIElQdjQgYWRk cmVzcyBhcyBPU1BGIHJvdXRlciBJRCBkb2Vzbid0IG1ha2Ugc2Vuc2UgaW4gYW4gSVB2Ng0KPj4+ ZW52aXJvbm1lbnQNCj4+Pg0KPj4+IEJhc2VkIG9uIHRoaXMsIEkgYmVsaWV2ZSB0aGF0Og0KPj4+ IC0gV2UgbXVzdCBub3QgYXNzb2NpYXRlIGFuIElQIGFkZHJlc3Mgc2VtYW50aWMgd2l0aCB0aGUg cm91dGVyIElEDQo+Pj4gLSBCYXNlZCBvbiBCcmlhbidzIGZlZWRiYWNrICh3aGljaCBJIGFncmVl IHdpdGgpICJBcyBsb25nIGFzIHRoZSBZQU5HDQo+Pj5tb2R1bGUgZG9lcyBub3Qgc3BlY2lmeSBh IGZvcm1hdCB0aGF0IG1ha2VzIHRoZSByb3V0ZXJJRCBkaXNwbGF5IGxpa2UNCj4+PmFuIElQdjQg YWRkcmVzcyIsIGl0IHdhcyBwcm9iYWJseSBhIG1pc3Rha2UgdG8gaGF2ZSBkZWZpbmVkIFJvdXRl cklEIGFzDQo+Pj5JcEFkcmVzcyBpbiBPU1BGIE1JQiBtb2R1bGUuDQo+Pj4gLSBJbnRlcmVzdGlu Z2x5LA0KPj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJv dXRpbmctY2ZnLTIwIGNvbnRhaW5zOg0KPj4+DQo+Pj4gICAgICAgZ3JvdXBpbmcgcm91dGVyLWlk IHsNCj4+PiAgICAgICAgIGRlc2NyaXB0aW9uDQo+Pj4gICAgICAgICAgICJUaGlzIGdyb3VwaW5n IHByb3ZpZGVzIHJvdXRlciBJRC4iOw0KPj4+ICAgICAgICAgbGVhZiByb3V0ZXItaWQgew0KPj4+ ICAgICAgICAgICB0eXBlIHlhbmc6ZG90dGVkLXF1YWQ7DQo+Pj4gICAgICAgICAgIGRlc2NyaXB0 aW9uDQo+Pj4gICAgICAgICAgICAgIkEgMzItYml0IG51bWJlciBpbiB0aGUgZm9ybSBvZiBhIGRv dHRlZCBxdWFkIHRoYXQgaXMgdXNlZA0KPj4+YnkNCj4+PiAgICAgICAgICAgICAgc29tZSByb3V0 aW5nIHByb3RvY29scyBpZGVudGlmeWluZyBhIHJvdXRlci4iOw0KPj4+ICAgICAgICAgICByZWZl cmVuY2UNCj4+PiAgICAgICAgICAgICAiDQo+Pj4gUkZDIDIzMjgNCj4+PiA6IE9TUEYgVmVyc2lv biAyLiI7DQo+Pj4gICAgICAgICB9DQo+Pj4gICAgICAgfQ0KPj4+DQo+Pj4gVGhpcyBzaG91bGQg YmUgYW4gdWludDMyIG51bWJlci4NCj4+PiAtIEFuIHVuaW9uLWJhc2VkIHNvbHV0aW9uIGlzIGEg YmFkIGNvbXByb21pc2UNCj4+PiAgRnJvbSBkcmFmdC1yYXphLW1wbHMtbGRwLW1sZHAteWFuZy0w Mg0KPj4+ICAgICAgICAgICAgICAgbGVhZiBsc3ItaWQgew0KPj4+ICAgICAgICAgICAgICAgICB0 eXBlIHVuaW9uIHsNCj4+PiAgICAgICAgICAgICAgICAgICB0eXBlIHlhbmc6ZG90dGVkLXF1YWQ7 DQo+Pj4gICAgICAgICAgICAgICAgICAgdHlwZSB1aW50MzI7DQo+Pj4gICAgICAgICAgICAgICAg IH0NCj4+PiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkxTUiBJRC4iOw0KPj4+DQo+Pj4N Cj4+Pg0KPj4+IFNpbmNlIHRoZSBxdWVzdGlvbiB3YXMgYXNrZWQ6IGFzIEFELCBJIHdvdWxkIHN1 cHBvcnQgdWludDMyIGV2ZXJ5d2hlcmUuDQo+Pj4NCj4+PiBOb3csIHByYWN0aWNhbGx5LCBob3cg dG8gbW92ZSBmb3J3YXJkPw0KPj4+IC0gRWl0aGVyIGFsbCBkcmFmdHMgcmVmZXJlbmNlIGRyYWZ0 LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIwICh3aXRoDQo+Pj50aGUgdWludDMyIG1vZGlmaWNh dGlvbiksDQo+Pj4gLSBPciB5b3UgY3JlYXRlIGEgIkNvbW1vbiBSb3V0aW5nIFlBTkcgRGF0YSBU eXBlcyIsIHNpbWlsYXJseSB0byBSRkMNCj4+PjY5OTEgaW5jbHVkaW5nIHRoZSByb3V0ZXIgSURz LiBJIHNlZSBhbHJlYWR5IG1hbnkgdHlwZWRlZiBpbg0KPj4+ZHJhZnQtcmF6YS1tcGxzLWxkcC1t bGRwLXlhbmctMDINCj4+PiAtIE9yIHlvdSBkZWZpbmUgeW91IG93biB0eXBlcyBpbiB5b3VyIG93 biBkcmFmdA0KPj4+DQo+Pj4gQnV0LCBpZiB3ZSBoYXZlIGFncmVlbWVudCBvbiB0aGUgdWludDMy LCBsZXQncyBkb2N1bWVudCB0aGlzIG5vdw0KPj4+c29tZXdoZXJlL3NvbWVob3csIGFuZCBsZXQn cyBub3QgcmV2aXNpdCB0aGlzIG9uIHJlZ3VsYXIgYmFzaXMgKHllcywgSQ0KPj4+c2VlIGl0IGNv bWluZy4uLikNCj4+PiBBIGZldyBsaW5lcyBvZiBleHBsYW5hdGlvbiBpbiB0aGUgZHJhZnQgd291 bGQgYWxyZWFkeSBoZWxwIGZvcg0KPj4+ZXhhbXBsZSwgaW4gYW4gb3BlcmF0aW9uYWwgc2VjdGlv biwgZXhwbGFpbmluZyB0byBwZW9wbGUgdGhlIG1hcHBpbmcgb2YNCj4+PnRoZSBNSUIgT1NQRiBS b3V0ZXJJRCB0byB0aGUgWUFORyBvYmplY3QNCj4+Pg0KPj4+IFJlZ2FyZHMsIEJlbm9pdA0KPj4+ PiBIaSBBZHJpYW4sDQo+Pj4+DQo+Pj4+IE9uIDIvMTYvMTYgNzo1MyBBTSwgQWRyaWFuIEZhcnJl bCB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIEJyaWFuLA0KPj4+Pj4NCj4+Pj4+IEkgc2FpZCBJIHdh c24ndCBnb2luZyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGlzIGRpc2N1c3Npb24gOi0pDQo+Pj4+Pg0K Pj4+PiBOaWNlIHRyeS4gOykNCj4+Pj4NCj4+Pj4NCj4+Pj4+Pj4gSSBzaG91bGQgbm90IHJlc3Bv bmQgdG8gcXVlc3Rpb25zIHRoYXQgSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kLA0KPj4+Pj4+PmJ1 dDoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gdGhlIEJHUCBJZGVudGlmaWVyIGlzIGFuIHVuc2lnbmVkIGlu dGVnZXINCj4+Pj4+Pj4gdGhlIE9TUEYgcm91dGVyIElEIGlzIGFuIHVuc2lnbmVkIGludGVnZXIN Cj4+Pj4+Pj4NCj4+Pj4+PiBJIGFzc3VtZSB0aGUgYWJvdmUgaXMgYmFzZWQgb24gdGhlIFlBTkcg ZGVmaW5pdGlvbiBvZiBPU1BGDQo+Pj4+Pj5yb3V0ZXJJRC4gUkZDDQo+Pj4+Pj4gNDc1MCBzYXlz IHRoZSByb3V0ZXJJRCBpcyBhbiBJUHY0IGFkZHJlc3MuIElzIHRoYXQgYW4gaXNzdWU/DQo+Pj4+ Pj4NCj4+Pj4+IFRvIHF1b3RlIGZyb20gNDc1MC4uLg0KPj4+Pj4NCj4+Pj4+IFJvdXRlcklEIDo6 PSBURVhUVUFMLUNPTlZFTlRJT04NCj4+Pj4+ICAgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQN Cj4+Pj4+ICAgICAgICAgREVTQ1JJUFRJT04NCj4+Pj4+ICAgICAgICAgICAgIkEgT1NQRiBSb3V0 ZXIgSWRlbnRpZmllci4NCj4+Pj4+ICAgICAgICAgICAgIE5vdGUgdGhhdCB0aGUgUm91dGVyIElE LCBpbiBPU1BGLCBoYXMgdGhlIHNhbWUgZm9ybWF0DQo+Pj4+PiAgICAgICAgICAgICBhcyBhbiBJ UCBhZGRyZXNzLCBidXQgaWRlbnRpZmllcyB0aGUgcm91dGVyIGluZGVwZW5kZW50DQo+Pj4+PiAg ICAgICAgICAgICBvZiBpdHMgSVAgYWRkcmVzcy4iDQo+Pj4+PiAgICAgICAgIFNZTlRBWCAgICAg ICBJcEFkZHJlc3MNCj4+Pj4+DQo+Pj4+PiBTbyBpdCBleHBsaWNpdGx5IHNheXMgaXQgaXMgTk9U IGFuIElQIGFkZHJlc3MgYnV0IHRoZSBNSUIgbW9kdWxlDQo+Pj4+PnVzZXMgdGhlIG5vdGF0aW9u YWwgZm9ybWF0dGluZyBvZiBuIElQIGFkZHJlc3MgZm9yIGRpc3BsYXkgcHVycG9zZXMuDQo+Pj4+ Pg0KPj4+Pj4gSSB0aGluayB0aGlzIGlzIGRvbmUgYmVjYXVzZSB0aGUgcm91dGVyIElEIGlzIG9m dGVuIGNob3NlbiB0byBiZSBhbg0KPj4+Pj5JUCBhZGRyZXNzIG9mIHRoZSByb3V0ZXIsIGFuZCBi ZWNhdXNlIGl0IGlzIGVhc2llciBmb3IgaHVtYW5zIHRvIGRlYWwNCj4+Pj4+d2l0aCBhLmIuYy5k IHdoZXJlIGVhY2ggZWxlbWVudCBpcyBhIDMtZGlnaXQgbnVtYmVyIGxlc3MgdGhhbiAyNTYsDQo+ Pj4+PnRoYW4gaXQgaXMgdG8gbWFuYWdlIGEgc2luZ2xlIG51bWJlciBpbiB0aGUgcmFuZ2UgMCB0 byAyXjMyIC0xLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+IFRoZSBhYm92ZSBpcyB0aGUgdGV4dHVhbCBj b252ZW50aW9uLCB3aGVyZWFzIHRoZSBmb2xsb3dpbmcgaXMgdGhlDQo+Pj4+YWN0dWFsDQo+Pj4+ IE9TUEYgcm91dGVySUQuLi4NCj4+Pj4NCj4+Pj4gICAgb3NwZlJvdXRlcklkIE9CSkVDVC1UWVBF DQo+Pj4+ICAgICAgICAgU1lOVEFYICAgICAgIFJvdXRlcklEDQo+Pj4+ICAgICAgICAgTUFYLUFD Q0VTUyAgIHJlYWQtd3JpdGUNCj4+Pj4gICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudA0KPj4+ PiAgICAgICAgIERFU0NSSVBUSU9ODQo+Pj4+ICAgICAgICAgICAgIkEgMzItYml0IGludGVnZXIg dW5pcXVlbHkgaWRlbnRpZnlpbmcgdGhlDQo+Pj4+ICAgICAgICAgICAgcm91dGVyIGluIHRoZSBB dXRvbm9tb3VzIFN5c3RlbS4NCj4+Pj4gICAgICAgICAgICBCeSBjb252ZW50aW9uLCB0byBlbnN1 cmUgdW5pcXVlbmVzcywgdGhpcw0KPj4+PiAgICAgICAgICAgIHNob3VsZCBkZWZhdWx0IHRvIHRo ZSB2YWx1ZSBvZiBvbmUgb2YgdGhlDQo+Pj4+ICAgICAgICAgICAgcm91dGVyJ3MgSVAgaW50ZXJm YWNlIGFkZHJlc3Nlcy4NCj4+Pj4NCj4+Pj4gU28gdGhlIE1JQiBhY3R1YWxseSBzYXlzIHRoZSBk ZWZhdWx0IGlzIHRvIHVzZSBhbiBJUHY0IGFkZHJlc3MuLi4NCj4+Pj4NCj4+Pj4gQWxsIHRoYXQg YmVpbmcgc2FpZCwgbXkgcG9pbnQgd2FzIGZ1cnRoZXIgYWxvbmcgd2hlcmUgSSBzYWlkOg0KPj4+ Pg0KPj4+Pg0KPj4+Pj4+IEkgYW0gbm90IGNvbmNlcm5lZCB3aXRoIHdoYXQgdGhlIG9wZXJhdG9y IHdpbGwgY2hvb3NlIGFzIGhpcy9oZXINCj4+Pj4+PiByb3V0ZXJJRCB2YWx1ZS4gSSBhbSBjb25j ZXJuZWQgd2l0aCB3aGF0IGZvcm1hdCBvcHRpb25zIHdpbGwgYmUNCj4+Pj4+PiBhc3NvY2lhdGVk IHdpdGggdGhlIHJvdXRlcklEIGluIHRoZSB5YW5nIG1vZHVsZS4gQXMgbG9uZyBhcyB0aGUNCj4+ Pj4+PmZvcm1hdA0KPj4+Pj4+IG9wdGlvbnMgZG9lcyBub3QgYWxsb3cgZGlzcGxheSBpbiBkb3R0 ZWQgZGVjaW1hbCBub3RhdGlvbiwgSSBhbQ0KPj4+Pj4+ZmluZS4NCj4+Pj4+Pg0KPj4+PiBBcyBs b25nIGFzIHRoZSBZQU5HIG1vZHVsZSBkb2VzIG5vdCBzcGVjaWZ5IGEgZm9ybWF0IHRoYXQgbWFr ZXMgdGhlDQo+Pj4+IHJvdXRlcklEIGRpc3BsYXkgbGlrZSBhbiBJUHY0IGFkZHJlc3MsIEkgYW0g ZmluZS4NCj4+Pj4NCj4+Pj4gQnJpYW4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+IC0tDQo+PiBMYWRp c2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4NCj4+ DQo+Pg0KPj4NCj4+IC4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Fri Feb 26 06:33:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37DE1B2CF1 for ; Fri, 26 Feb 2016 06:33:23 -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 hFYZNDg9jvjL for ; Fri, 26 Feb 2016 06:33:22 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31E91B2CF5 for ; Fri, 26 Feb 2016 06:33:21 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id c200so74910697wme.0 for ; Fri, 26 Feb 2016 06:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Q/C5HnfI8XfjY0h619nvO166t3fA3+z9Ssy/xz4rDrE=; b=GsklTRNtIiU1UyJDikF9RzYTkCKw294TWFhGhuVX8K7cKTJvrGtkEVCVZnV50t4ggE O5cJX0UnzkJa/EGmRyTChiiV2PpBrcuNpvfSaJOs6KxL+Uu/DQDHY5Y/HMU41HCqzWf2 C7TeKMBQCWkFYk9lDxtl+oiohg2D9V28pySYGb9elNxavtv6j0O6SNxxc4DSMXXjcxPw EryjNoxeJVQZju65Iv9iZxu/7S7L9TCn3q7Xj4aU4P4HKtrpmuDGWHQ/g0mj0t11ohM9 bdyTd5PIRO0ewLylnfpTwyY7g68OaL1r4v3QvMkwC5uovOSZLJoL0sa36ZdnwjpfERHO ZjDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Q/C5HnfI8XfjY0h619nvO166t3fA3+z9Ssy/xz4rDrE=; b=V3vElH8nVxQHDiyhzJ0pHLS51DXSqoqxyzilnXQbunNSyNAtIrBPc9uL7NG8e5GD2W ES7eJpksp2Cgrtl28NOK4lkeKJv+805g+wykB6Ipf+PCeUahdddMbRQXziLo6WrlBKAw cJfZpnQjdQVZN+w0azHaQ1slSbsX8KfWbsbxZiH8a+6+JhYp0l0CA9qTCTz9F+zy36hg dHWwjx7vP2B2IAMfP+b07CkOeZEqrEd2zJs3L+RUjzNeTeIxNQIVGjA04vnhTPPjR0sL leazG3LKgPfJfh4Tb4Nry4GajFn5VvWM0AuyCoiGtyBgxgA1q2MxAWGg9Ec3/3NUjDYh st+A== X-Gm-Message-State: AD7BkJJQ26NLJ78MOquw0gmItjbaD0LzL11ogWedGoSzED2e8q9eaU6/oeQzqjy1Q3+V1A== X-Received: by 10.28.14.4 with SMTP id 4mr3672697wmo.100.1456497200284; Fri, 26 Feb 2016 06:33:20 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id i12sm3135299wmf.10.2016.02.26.06.33.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2016 06:33:19 -0800 (PST) From: "Xufeng Liu" To: "'Ladislav Lhotka'" , "'NETMOD WG'" References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> Date: Fri, 26 Feb 2016 09:33:16 -0500 Message-ID: <004101d170a2$a3261590$e97240b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHigKfQG5ZVJrOoclQlBDSU3ZphwJ8cQuRw Content-Language: en-us Archived-At: Subject: Re: [netmod] proposed change to ietf-routing 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, 26 Feb 2016 14:33:23 -0000 Hi Acee and Lada, Have a question: the schema hierarchy will be different after the changes. Is the following expected? We will have ro branch and rw branch split in the middle of the tree after mounting? Before: module: ietf-routing +--ro routing-state | +--ro routing-instance* [name] | +--ro name string | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | +--ro type identityref | | +--ro name string | +--ro ribs | +--ro rib* [name] | +--ro name string +--rw routing +--rw routing-instance* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [type name] | +--rw type identityref | +--rw name string +--rw ribs +--rw rib* [name] +--rw name string Now: +--rw networking-instances +--rw networking-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw description? string +--rw networking-instance-policy +--rw root? structural-mount +--ro routing-state | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | ... | +--ro ribs | +--ro rib* [name] | ... +--rw routing +--rw router-id? yang:dotted-quad +--rw description? string +--rw routing-protocols | +--rw routing-protocol* [type name] | ... +--rw ribs +--rw rib* [name] ... Thanks, - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Friday, February 26, 2016 8:37 AM > To: NETMOD WG > Subject: [netmod] proposed change to ietf-routing > > Hi, > > as a part of synchronization of the routing data models that are being developed > by the NETMOD and RTG working groups, the authors of draft-ietf-netmod- > routing-cfg propose to remove the routing-instance level in the data hierarchy, > and leave it to structural-mount/YSDL to provide a top level structure. > > Schematically, the configuration and state data subtrees of ietf-routing would > be reduced to something like this: > > module: ietf-routing > +--ro routing-state > | +--ro router-id? yang:dotted-quad > | +--ro interfaces > | | +--ro interface* if:interface-state-ref > | +--ro routing-protocols > | | +--ro routing-protocol* [type name] > | | ... > | +--ro ribs > | +--ro rib* [name] > | ... > +--rw routing > +--rw router-id? yang:dotted-quad > +--rw description? string > +--rw routing-protocols > | +--rw routing-protocol* [type name] > | ... > +--rw ribs > +--rw rib* [name] > ... > > Are there any objections to this change? > > Thanks, > > Acee and 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 Fri Feb 26 06:40:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5931ACD88 for ; Fri, 26 Feb 2016 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.907 X-Spam-Level: X-Spam-Status: No, score=-13.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 cJqRetYYjcGm for ; Fri, 26 Feb 2016 06:40:44 -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 CE9881B2D15 for ; Fri, 26 Feb 2016 06:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6195; q=dns/txt; s=iport; t=1456497644; x=1457707244; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=39YKt3+KbCIxYdccFCkTbaercz/ygbADOTxoFL/kirc=; b=kkGQouiDg7t6S+pxbSx06MOIhdvLisdnkiCR0a4q3DTsWgF8hbzNiW17 fBMjNKm8ZJHRBqJGhkPBiZ7hiJoftPEWuEi4bKNOG/kt3YePKb8zM/01a 87PhPeKZt1Tbq7mWxbr8P6AUdXjha6KAziefh8Ou8EzjaewJ9D04NNPFe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACpYtBW/xbLJq1ehAxtvEAXCoUoS?= =?us-ascii?q?gKCDgEBAQEBAWUnhEIBAQQBAQE1NgoBEAsOAggJFg8JAwIBAgEVMAYBDAYCAQE?= =?us-ascii?q?XiAQOvTQBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYSgz19iG8BBI0qiV6NYIkkh?= =?us-ascii?q?VCOSWKDZDwuiEsBAQE?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="625704555" 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; 26 Feb 2016 14:40:41 +0000 Received: from [10.63.23.69] (dhcp-ensft1-uk-vla370-10-63-23-69.cisco.com [10.63.23.69]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1QEefRp018981; Fri, 26 Feb 2016 14:40:41 GMT To: Lou Berger , Martin Bjorklund References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <56CF2D5F.6060009@cisco.com> <20160226.082505.504004219149309283.mbj@tail-f.com> <56D03063.1060003@cisco.com> <1531d48bab8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Wilton Message-ID: <56D063E9.8010906@cisco.com> Date: Fri, 26 Feb 2016 14:40:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1531d48bab8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 26 Feb 2016 14:40:46 -0000 Lou, Martin, Is the network-instance schema-mount (from draft-rtgyangdt-rtgwg-device-model) an example of where it would be useful to indicate which modules would be expected to be mounted at that point? Certainly it would seem that there are particular modules that you would expect to be mounted at that point (e.g. routing) and other modules that you would not (e.g. interfaces/hardware/etc). Rob On 26/02/2016 11:13, Lou Berger wrote: > Rob/Martin, > > > On February 26, 2016 6:01:23 AM Robert Wilton wrote: > >> >> >> On 26/02/2016 07:25, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> >>>> On 25/02/2016 08:43, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder wrote: >>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>>>> >>>>>>>> I think the use cases are rather obvious. I build a device and >>>>>>>> I like >>>>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>>>> definition of beauty). >>>>>>> This would be pretty complicated. Suppose I define my own >>>>>>> beautiful >>>>>>> structure like this: >>>>>>> >>>>>>> container my-interfaces { >>>>>>> x:mount-point "if" { >>>>>>> x:mount-module "ietf-interfaces"; >>>>>>> } >>>>>>> } >>>>>>> container my-routing { >>>>>>> x:mount-point "rtr" { >>>>>>> x:mount-module "ietf-routing"; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Note that with the mount-point defined in my draft, each >>>>>>> mount-point >>>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>>>> cross mount points. >>>>>> Could be the same here. >>>>>> >>>>>>> In this case, we have references between ietf-routing and >>>>>>> ietf-interfaces. How would they work? >>>>>> How do they work in your solution? If interfaces is jailed and >>>>>> routing >>>>>> is jailed, how does routing refer to the interfaces? >>>>> My solution does not support "name module mount". It only supports >>>>> mouting of a "complete" set of modules (that are chrooted) - simply >>>>> because this is what we understand, have implemented, and have been >>>>> running for the last ~5 years. (The same goes for ODL, I believe). >>>> I have been wondering whether "name module mount" is really about >>>> mounting only specific modules, or actually allowing the mounting >>>> schema to statically indicate which modules are guaranteed to be >>>> present. I.e. specifically it doesn't explicitly prohibit other >>>> modules/data nodes from potentially also being mounted at the same >>>> path, but in the normal case you wouldn't expect them to be present. >>> This was my thinking as well. But then the "random rearrangemt of >>> modules to get a more beautiful layot" use case doesn't apply. >>> >>> And if you start to do "ymnt:require-module" you probably also need to >>> specify "required-feature" and "required-revision"... >> Yes, I don't know if you would have to require those, but I can see that >> it would be useful to at least allow them. >> >>> >>> So, before exploring possible solutions, it would be great if we >>> agreed on the problem to solve. Does anyone have a use case for >>> explicit naming of modules to be mounted in the schema? >> I might be mistaken, but an example use case of this may have been given >> in the Yokohama L3SM WG meeting. >> >> That WG has a desire to build service level YANG models, and for such >> models I think that there are some scenarios where it may be desirable >> to build those service level models by reusing some of the device level >> YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted) >> rather than having to independently develop closely related copies of >> those YANG modules located at different schema paths which might >> potentially diverge over time. >> > > L3SM and bgp was the case I referred to in the interim and commonly > use as an example. (Although I wasn't part of the Yokohama discussion > you mentioned.) > >> However, if this was the scenario considered then it is unclear to me >> whether you would want to mount the entirety of a QoS device level >> model, or would just want parts of it. Arguably groupings may be a >> better solution here, but their usefulness depends on whether the device >> level model has been constructed in a way to make reuse of parts of that >> model feasible. >> > > This probably would work if we had augmentable groupings or maybe > "root less" containers -- need to think a bit more about the latter.... > Lou >> Rob >> >> >>> >>> >>> /martin >>> >>> >>>> My reasoning is that you don't want to have to statically specify in >>>> the mounting schema all augmentations, deviations and features. But I >>>> also don't think that the mounting schema can guarantee that the >>>> mounted schema will always exactly implement the module(s) specified >>>> in the schema mount and all features without any augmentations or >>>> deviations. >>>> >>>> So for this to be useful, it means that there has to be a dynamic >>>> mechanism to determine exactly what modules has been mounted >>>> (e.g. like the ietf-yang-structural-mount module or ysdl). >>>> >>>> Given this, I think that you could possibly end up with just one >>>> "schema mount" with a couple of options: >>>> >>>> The first option would be an explicit list of modules that are >>>> guaranteed to be mounted at that location (or "*" to indicate a >>>> "complete" set of modules (that are chrooted). >>>> >>>> The second option would indicate where the runtime details of the >>>> mounted modules can be found: this option might indicate whether >>>> details of the mounted modules can be found inline in the data tree at >>>> the mount point using yang-library, or separately in the >>>> ietf-yang-structural-mount module/ysdl. >>>> >>>> Rob >>>> >>> . >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > . > From nobody Fri Feb 26 07:07:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D6C1B2DE9 for ; Fri, 26 Feb 2016 07:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 WoKPOXg-y-na for ; Fri, 26 Feb 2016 07:07:23 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 10F581B2DE8 for ; Fri, 26 Feb 2016 07:07:23 -0800 (PST) Received: (qmail 18325 invoked by uid 0); 26 Feb 2016 15:07:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 26 Feb 2016 15:07:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id P37E1s00g2SSUrH0137HbN; Fri, 26 Feb 2016 08:07:20 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=7JlG9jQ-dmPlZxFfmhEA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=D-8fDyCXlQdTG5uU:21 a=G34wj8v2NM4ECgQr:21 a=pILNOxqGKmIA:10 a=RnC21GNCoRoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=8+gVxBqvi3QpjTXyDXHpDk8bypraDatQVJb8OL3ZnF4=; b=IZPUfLY6i2I4ePNtnDL1kURWUrK5zhKyG+qdTBoohhcvRKQoCSMnI66MKSTF6s774+RwGi1W2T+UPhKzH126pDmCIwAcGFkkuXgtCre539dHkFN9rI+7HeIrO89a5dGu; Received: from box313.bluehost.com ([69.89.31.113]:52492 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aZJz8-0005yl-CL; Fri, 26 Feb 2016 08:07:14 -0700 To: NETMOD Working Group References: <56707D11.2050604@cisco.com> <56708676.9040501@cisco.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56D06A1B.2050907@labn.net> Date: Fri, 26 Feb 2016 10:07:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56708676.9040501@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [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: Fri, 26 Feb 2016 15:07:24 -0000 WG, An update on this topic is overdue (my fault). A large part of the delay has been figuring out how to proceed with the conclusions from the analysis. Basically the/my conclusion is that none of the solution fulfills all requirements/considerations and that having a discussion centered around picking one (or even how our analysis got it wrong) isn't the right place to focus anyone's energy. I have therefore asked the that the authors to work together to come up with and propose a unified technical solution. I'll update the WG when I have some thing to report, which might include that I don't think a unified proposal is going to happen or that a new proposal will soon be put forward. Lou PS I do expect that the analysis will be published at some point in the future for general reference. My current thinking is at the same time as the unified solution. (Although, as Benoit initiated the analysis, he's the one who really gets the final say.) The analysis has been shared with the solutions authors. If you really want to see the analysis now, send me mail and I'll send you a link. On 12/15/2015 4:30 PM, Benoit Claise wrote: > 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 > > > > > > > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 26 07:40:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893E11A9083 for ; Fri, 26 Feb 2016 07:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 gibZ_tYMNdVw for ; Fri, 26 Feb 2016 07:40: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 6E8661A902F for ; Fri, 26 Feb 2016 07:40:21 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 84FF3180317; Fri, 26 Feb 2016 16:40:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456501219; bh=1iyIR/QnhoW8nqkpLdU0yQnhTkiblCahRAour2WAU1E=; h=From:Date:To; b=i7eeIcEQ6xe9YSjV57mKGCjOKAETRiOww+5At2mvysEuHKBjxozjU8U2PzWS6ApoX 9B4YGrk8JKDMyPelZ/zcmEyfeE9clVD8xjqbCKowFqoV55JORHpEjp0swiGw5WEw2g r7pTFae5G+lOJcoji0AnxQaQXEcaWPhaTM7jTkd8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <004101d170a2$a3261590$e97240b0$@gmail.com> Date: Fri, 26 Feb 2016 16:40:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56AC8C2F-1F3A-4E31-B708-5ED2FC8C738D@nic.cz> References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> <004101d170a2$a3261590$e97240b0$@gmail.com> To: Xufeng Liu 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] proposed change to ietf-routing 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, 26 Feb 2016 15:40:24 -0000 > On 26 Feb 2016, at 15:33, Xufeng Liu = wrote: >=20 > Hi Acee and Lada, >=20 > Have a question: the schema hierarchy will be different after the = changes. > Is the following expected? We will have ro branch and rw branch split = in the > middle of the tree after mounting? Yes, unless and until we agree on a better data organization. Note that = it is exactly the same as with ietf-interfaces. Lada >=20 > Before: >=20 > module: ietf-routing > +--ro routing-state > | +--ro routing-instance* [name] > | +--ro name string > | +--ro routing-protocols > | | +--ro routing-protocol* [type name] > | | +--ro type identityref > | | +--ro name string > | +--ro ribs > | +--ro rib* [name] > | +--ro name string > +--rw routing > +--rw routing-instance* [name] > +--rw name string > +--rw routing-protocols > | +--rw routing-protocol* [type name] > | +--rw type identityref > | +--rw name string > +--rw ribs > +--rw rib* [name] > +--rw name string >=20 > Now: >=20 > +--rw networking-instances > +--rw networking-instance* [name] > +--rw name string > +--rw type? identityref > +--rw enabled? boolean > +--rw description? string > +--rw networking-instance-policy > +--rw root? structural-mount > +--ro routing-state > | +--ro router-id? yang:dotted-quad > | +--ro interfaces > | | +--ro interface* if:interface-state-ref > | +--ro routing-protocols > | | +--ro routing-protocol* [type name] > | | ... > | +--ro ribs > | +--ro rib* [name] > | ... > +--rw routing > +--rw router-id? yang:dotted-quad > +--rw description? string > +--rw routing-protocols > | +--rw routing-protocol* [type name] > | ... > +--rw ribs > +--rw rib* [name] > ... >=20 > Thanks, >=20 > - Xufeng >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav = Lhotka >> Sent: Friday, February 26, 2016 8:37 AM >> To: NETMOD WG >> Subject: [netmod] proposed change to ietf-routing >>=20 >> Hi, >>=20 >> as a part of synchronization of the routing data models that are = being > developed >> by the NETMOD and RTG working groups, the authors of = draft-ietf-netmod- >> routing-cfg propose to remove the routing-instance level in the data > hierarchy, >> and leave it to structural-mount/YSDL to provide a top level = structure. >>=20 >> Schematically, the configuration and state data subtrees of = ietf-routing > would >> be reduced to something like this: >>=20 >> module: ietf-routing >> +--ro routing-state >> | +--ro router-id? yang:dotted-quad >> | +--ro interfaces >> | | +--ro interface* if:interface-state-ref >> | +--ro routing-protocols >> | | +--ro routing-protocol* [type name] >> | | ... >> | +--ro ribs >> | +--ro rib* [name] >> | ... >> +--rw routing >> +--rw router-id? yang:dotted-quad >> +--rw description? string >> +--rw routing-protocols >> | +--rw routing-protocol* [type name] >> | ... >> +--rw ribs >> +--rw rib* [name] >> ... >>=20 >> Are there any objections to this change? >>=20 >> Thanks, >>=20 >> Acee and 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 26 07:43:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801B21A914A for ; Fri, 26 Feb 2016 07:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 GDBLzc5heVWu for ; Fri, 26 Feb 2016 07:43:09 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 487811A911B for ; Fri, 26 Feb 2016 07:43:09 -0800 (PST) Received: (qmail 22115 invoked by uid 0); 26 Feb 2016 15:43:09 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 26 Feb 2016 15:43:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id P3iz1s00M2SSUrH013j29S; Fri, 26 Feb 2016 08:43:07 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=pkOGN24kiyBW0tFtOCoA:9 a=G-rQu1zlrdzrTFfM:21 a=pabtfuzNzcOz4tsR:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=9aB6ckHE97KL74y64zsm1tr2Z7LhgHqk+FuIIqUMj7Y=; b=OdvZ9wUr8yi3UyAcM0nBw73a0ISOpES1IzUSC8/OwfQp5+Dod7gecgCJFN6d1ufS3n+bp/4ZRd/T5Abij7gqGd5IA0rMInUhrCen/5014/ROOnL8Muz+4tABFxe5EUCb; Received: from box313.bluehost.com ([69.89.31.113]:34520 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aZKXk-0006d4-VM; Fri, 26 Feb 2016 08:43:01 -0700 To: Robert Wilton , Martin Bjorklund References: <20160225083228.GB19366@elstar.local> <20160225.094334.1498092398680350689.mbj@tail-f.com> <56CF2D5F.6060009@cisco.com> <20160226.082505.504004219149309283.mbj@tail-f.com> <56D03063.1060003@cisco.com> <1531d48bab8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <56D063E9.8010906@cisco.com> From: Lou Berger Message-ID: <56D0727F.4010509@labn.net> Date: Fri, 26 Feb 2016 10:42:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D063E9.8010906@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" , netmod@ietf.org Subject: Re: [netmod] explicit mount 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, 26 Feb 2016 15:43:11 -0000 Rob, I think chris spoke to this (indirectly) in an earlier mail -- that the current approach of not specifying is most flexible from a future proof stand point, i.e., we really don't want to specify based on what exists in today's rapidly moving environment. We have also discussed the possibilities of defining 'example profiles' which would be what you'd expect to see from different classes of devices, e.g., an wrt box vs a tier 1 PE - which could be informative. Lou PS Interfaces do need to show in NIs, check out the augmentations defined as part of the model. But I think your general point is still valid. On 2/26/2016 9:40 AM, Robert Wilton wrote: > Lou, Martin, > > Is the network-instance schema-mount (from > draft-rtgyangdt-rtgwg-device-model) an example of where it would be > useful to indicate which modules would be expected to be mounted at that > point? > > Certainly it would seem that there are particular modules that you would > expect to be mounted at that point (e.g. routing) and other modules that > you would not (e.g. interfaces/hardware/etc). > > Rob > > > On 26/02/2016 11:13, Lou Berger wrote: >> Rob/Martin, >> >> >> On February 26, 2016 6:01:23 AM Robert Wilton wrote: >> >>> >>> On 26/02/2016 07:25, Martin Bjorklund wrote: >>>> Robert Wilton wrote: >>>>> On 25/02/2016 08:43, Martin Bjorklund wrote: >>>>>> Juergen Schoenwaelder wrote: >>>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote: >>>>>>> >>>>>>>>> I think the use cases are rather obvious. I build a device and >>>>>>>>> I like >>>>>>>>> to rearrange existing models into a beautiful hierarchy (for some >>>>>>>>> definition of beauty). >>>>>>>> This would be pretty complicated. Suppose I define my own >>>>>>>> beautiful >>>>>>>> structure like this: >>>>>>>> >>>>>>>> container my-interfaces { >>>>>>>> x:mount-point "if" { >>>>>>>> x:mount-module "ietf-interfaces"; >>>>>>>> } >>>>>>>> } >>>>>>>> container my-routing { >>>>>>>> x:mount-point "rtr" { >>>>>>>> x:mount-module "ietf-routing"; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Note that with the mount-point defined in my draft, each >>>>>>>> mount-point >>>>>>>> becomes itw own "jailed" or "chrooted" tree. So references cannot >>>>>>>> cross mount points. >>>>>>> Could be the same here. >>>>>>> >>>>>>>> In this case, we have references between ietf-routing and >>>>>>>> ietf-interfaces. How would they work? >>>>>>> How do they work in your solution? If interfaces is jailed and >>>>>>> routing >>>>>>> is jailed, how does routing refer to the interfaces? >>>>>> My solution does not support "name module mount". It only supports >>>>>> mouting of a "complete" set of modules (that are chrooted) - simply >>>>>> because this is what we understand, have implemented, and have been >>>>>> running for the last ~5 years. (The same goes for ODL, I believe). >>>>> I have been wondering whether "name module mount" is really about >>>>> mounting only specific modules, or actually allowing the mounting >>>>> schema to statically indicate which modules are guaranteed to be >>>>> present. I.e. specifically it doesn't explicitly prohibit other >>>>> modules/data nodes from potentially also being mounted at the same >>>>> path, but in the normal case you wouldn't expect them to be present. >>>> This was my thinking as well. But then the "random rearrangemt of >>>> modules to get a more beautiful layot" use case doesn't apply. >>>> >>>> And if you start to do "ymnt:require-module" you probably also need to >>>> specify "required-feature" and "required-revision"... >>> Yes, I don't know if you would have to require those, but I can see that >>> it would be useful to at least allow them. >>> >>>> So, before exploring possible solutions, it would be great if we >>>> agreed on the problem to solve. Does anyone have a use case for >>>> explicit naming of modules to be mounted in the schema? >>> I might be mistaken, but an example use case of this may have been given >>> in the Yokohama L3SM WG meeting. >>> >>> That WG has a desire to build service level YANG models, and for such >>> models I think that there are some scenarios where it may be desirable >>> to build those service level models by reusing some of the device level >>> YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted) >>> rather than having to independently develop closely related copies of >>> those YANG modules located at different schema paths which might >>> potentially diverge over time. >>> >> L3SM and bgp was the case I referred to in the interim and commonly >> use as an example. (Although I wasn't part of the Yokohama discussion >> you mentioned.) >> >>> However, if this was the scenario considered then it is unclear to me >>> whether you would want to mount the entirety of a QoS device level >>> model, or would just want parts of it. Arguably groupings may be a >>> better solution here, but their usefulness depends on whether the device >>> level model has been constructed in a way to make reuse of parts of that >>> model feasible. >>> >> This probably would work if we had augmentable groupings or maybe >> "root less" containers -- need to think a bit more about the latter.... >> Lou >>> Rob >>> >>> >>>> >>>> /martin >>>> >>>> >>>>> My reasoning is that you don't want to have to statically specify in >>>>> the mounting schema all augmentations, deviations and features. But I >>>>> also don't think that the mounting schema can guarantee that the >>>>> mounted schema will always exactly implement the module(s) specified >>>>> in the schema mount and all features without any augmentations or >>>>> deviations. >>>>> >>>>> So for this to be useful, it means that there has to be a dynamic >>>>> mechanism to determine exactly what modules has been mounted >>>>> (e.g. like the ietf-yang-structural-mount module or ysdl). >>>>> >>>>> Given this, I think that you could possibly end up with just one >>>>> "schema mount" with a couple of options: >>>>> >>>>> The first option would be an explicit list of modules that are >>>>> guaranteed to be mounted at that location (or "*" to indicate a >>>>> "complete" set of modules (that are chrooted). >>>>> >>>>> The second option would indicate where the runtime details of the >>>>> mounted modules can be found: this option might indicate whether >>>>> details of the mounted modules can be found inline in the data tree at >>>>> the mount point using yang-library, or separately in the >>>>> ietf-yang-structural-mount module/ysdl. >>>>> >>>>> Rob >>>>> >>>> . >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> . >> > From nobody Fri Feb 26 09:17:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F171A1BBC; Fri, 26 Feb 2016 09:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 0b6kR4nZdyXB; Fri, 26 Feb 2016 09:16:58 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F15A1A901E; Fri, 26 Feb 2016 09:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1456507017; x=1457716617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qFgloX7TEvzPm1ZClnHw+6Mu5ZUS1lUymcHkd3G6bEQ=; b=ezaY7SRYIJ7Gxu7ddhJVUjBhYWa2enyW5Rq39DZ6oSch0mA2hI/oQvKB USGnVv5YsAZnVWCc9pn33oe9sDlZBjv2i+ypkxkkGOzSqi8fYCFZTPCoi cx64Rehft/I9Wpg9VnEGPZVyPM7uMPbmixdGbfW955RiMLY8/aAPyJYT7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBjiNBW/4MNJK1egzpSbQa6RgENg?= =?us-ascii?q?WYhhXICHIEqOBQBAQEBAQEBZCeEQgEBBCMRQAUQAgEIDgwCJgICAjAVEAIEDgW?= =?us-ascii?q?IHgEOrx6OWwEBAQEBAQEBAQEBAQEBAQEBAQEBARV7hReBbAiCRoQFEQE0gmorg?= =?us-ascii?q?Q8FlwgBhVeICIFeS4N5iFKOSAEeAQFCg2RqAYcYNAF9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="75398235" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2016 17:16:42 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1QHGgUW003634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 17:16:42 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 11:16:41 -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; Fri, 26 Feb 2016 11:16:42 -0600 From: "Clyde Wildes (cwildes)" To: Lou Berger , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" Thread-Topic: draft-ietf-netmod-syslog-model-06 Thread-Index: AQHRbdiu8RHGhLk0SUaNPvspSBufoJ8+dbKA Date: Fri, 26 Feb 2016 17:16:41 +0000 Message-ID: <80495147-7C8C-4160-B400-97DF1B59BA6C@cisco.com> References: <56CBB450.9080403@labn.net> In-Reply-To: <56CBB450.9080403@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.106.23] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod chairs , netmod WG Subject: Re: [netmod] draft-ietf-netmod-syslog-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, 26 Feb 2016 17:17:02 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQoNCg0KDQoNCk9uIDIvMjIvMTYsIDU6MjIgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJu Lm5ldD4gd3JvdGU6DQoNCj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KPg0KPkFzIHBhcnQg b2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwNCj4NCj5BcmUgeW91IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/DQo+DQo+UGxl YXNlIHN0YXRlIGVpdGhlcjoNCj4NCj4iTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0 IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj5vcg0KPiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhh dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQo+DQo+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRp c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCj4oc2VlIFJGQ3MgMzk3 OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCj4NCj5JZiB5ZXMgdG8g dGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0KPiJZZXMsIHRoZSBJUFIgaGFzIGJl ZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCj5vcg0KPiJO bywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KPg0KPklmIHlvdSBhbnN3ZXIgbm8s IHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rDQo+YXBwcm9w cmlhdGUuDQo+DQo+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCj5hYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMg ZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQo+YXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0 DQo+c3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0 aG9yIGFuZCBsaXN0ZWQNCj5jb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBP RiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTDQo+VE8gTElORVMuDQo+DQo+SWYgeW91IGFy ZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3Qg bGlzdGVkDQo+YXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlv dXIgb2JsaWdhdGlvbnMgdW5kZXINCj50aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdl cyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUNCj5hd2FyZSBvZiBJUFIgb2Ygb3Ro ZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20NCj5wYXJ0aWNp cGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIN Cj51bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBS RkNzIGxpc3RlZCBhYm92ZQ0KPmFuZA0KPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3Vw L2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KPg0KPlRoYW5rIHlvdSwNCj5O RVRNT0QgV0cgQ2hhaXJzDQo+DQo+UFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUg aGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91cg0KPnJlc3BvbnNlLg0KPg0KPg0K From nobody Fri Feb 26 09:48:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF1D1B2C3F; Fri, 26 Feb 2016 09:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 A9bJLrpx_vOn; Fri, 26 Feb 2016 09:48:08 -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 524C41B2C4A; Fri, 26 Feb 2016 09:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2014; q=dns/txt; s=iport; t=1456508888; x=1457718488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UZ6Fka7bx3wR1LtW6k7MxbsVvGEwgNBtt1Nxm8Cdli4=; b=NrWzncK3znagFIC46ilEb1+O/ohFoQz0QDggeMzpFAnUCtl54motRKUP nIls9YxREvuA8N2dzzJZWw1/BbGyEYTVaEAxO4ItWPr/mAK8ET1LSZrYL qJ0hziQYxwrbTWca582zSuNOJA0WK0VyxPVgPNaHiS0MuooqXKjTayJGf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCljtBW/4cNJK1egzpSbQa6RgENg?= =?us-ascii?q?WYhhXICgUY4FAEBAQEBAQFkJ4RCAQEEdAUQAgEIGC4yJQIEAQ0FiB8OvgQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARaKTIQFEQGEWAWNYokmAYVXiAiBXkuDeYhSjkgBH?= =?us-ascii?q?gEBQoNkagGHGDR+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="242909765" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2016 17:48:07 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1QHm7Ub005465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 17:48:07 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 11:48:06 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Fri, 26 Feb 2016 11:48:06 -0600 From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" To: "Clyde Wildes (cwildes)" , Lou Berger Thread-Topic: draft-ietf-netmod-syslog-model-06 Thread-Index: AQHRbdivAlMY2urG8EibjOwuYW3a1Z8++86A//+kLoA= Date: Fri, 26 Feb 2016 17:48:06 +0000 Message-ID: References: <56CBB450.9080403@labn.net> <80495147-7C8C-4160-B400-97DF1B59BA6C@cisco.com> In-Reply-To: <80495147-7C8C-4160-B400-97DF1B59BA6C@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.82.245.238] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F52F490262476439B7F0A0C4DBE61A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: netmod chairs , netmod WG Subject: Re: [netmod] draft-ietf-netmod-syslog-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, 26 Feb 2016 17:48:10 -0000 I=B9m not aware of any IPR that applies to this draft too. On 2/26/16, 11:16 AM, "Clyde Wildes (cwildes)" wrote: >No, I'm not aware of any IPR that applies to this draft > > > > > >On 2/22/16, 5:22 PM, "Lou Berger" wrote: > >>Authors, Contributors, WG, >> >>As part of the preparation for WG Last Call >> >>Are you aware of any IPR that applies to draft identified above? >> >>Please state either: >> >>"No, I'm not aware of any IPR that applies to this draft" >>or >>"Yes, I'm aware of IPR that applies to this draft" >> >>If so, has this IPR been disclosed in compliance with IETF IPR rules >>(see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >>If yes to the above, please state either: >> >>"Yes, the IPR has been disclosed in compliance with IETF IPR rules" >>or >>"No, the IPR has not been disclosed" >> >>If you answer no, please provide any additional details you think >>appropriate. >> >>If you are listed as a document author or contributor please answer the >>above by responding to this email regardless of whether or not you are >>aware of any relevant IPR. This document will not advance to the next >>stage until a response has been received from each author and listed >>contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S >>TO LINES. >> >>If you are on the WG email list or attend WG meetings but are not listed >>as an author or contributor, we remind you of your obligations under >>the IETF IPR rules which encourages you to notify the IETF if you are >>aware of IPR of others on an IETF contribution, or to refrain from >>participating in any contribution or discussion related to your >>undisclosed IPR. For more information, please see the RFCs listed above >>and >>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >>Thank you, >>NETMOD WG Chairs >> >>PS Please include all listed in the headers of this message in your >>response. >> >> From nobody Fri Feb 26 15:20:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C91B32D5 for ; Fri, 26 Feb 2016 15:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19bwOG1aQzy6 for ; Fri, 26 Feb 2016 15:20:36 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF11D1B32CB for ; Fri, 26 Feb 2016 15:20:35 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-8e-56d0dda7d2a9 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.F9.32102.8ADD0D65; Sat, 27 Feb 2016 00:20:08 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 18:20:34 -0500 From: Sampathkumar Santhanakrishnan To: Juergen Schoenwaelder Thread-Topic: [netmod] Question on "bits" in YANG Thread-Index: AdFvp4yPrlpBi+eWRxun0pzcY5uwwQAhywgAAC8lU+A= Date: Fri, 26 Feb 2016 23:20:33 +0000 Message-ID: <5ADC40FCE0FC7140AB4B8FD107A271C4219E99FF@eusaamb109.ericsson.se> References: <5ADC40FCE0FC7140AB4B8FD107A271C4219E9580@eusaamb109.ericsson.se> <20160225194334.GA20558@elstar.local> In-Reply-To: <20160225194334.GA20558@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuO6KuxfCDD4eEbK4uvEno8X8i42s DkweS5b8ZPLYcMAzgCmKyyYlNSezLLVI3y6BK+PUlK3MBZP5Kjb0XWBpYJzG3cXIySEhYCLx u3k+I4QtJnHh3nq2LkYuDiGBI4wS9y+9AksICSxnlJh93AzEZhMIkpj3dzELiC0i4CDRv62b DcRmFlCXuHPqMZgtLGAgseL7GiaIGkOJxWc/MUPYVhJbLv9iBbFZBFQllh7ezA5i8wr4Snxu PM4OsatU4uPSr0BzODg4BYwkfvQbg4QZBWQlvjSuZoZYJS5x68l8JoibBSSW7DnPDGGLSrx8 /I8VwlaSmLT0HCtEvY7Egt2foM7Ulli28DUzxFpBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCR ZRUjR2lxQU5uupHhJkZghByTYHPcwbi31/MQowAHoxIP74cbF8KEWBPLiitzDzFKcDArifCG LAMK8aYkVlalFuXHF5XmpBYfYpTmYFES553rvD5MSCA9sSQ1OzW1ILUIJsvEwSnVwGi+7kRF p+aEouMi/NkvFx8s2HDbvHarg967LSfXLEj+L5LQJaF1yn33rf+Ffr+a7qw+sqiznfvko+9n T/mUR5yateV2MJdkYLjR+7/iW/7dutumsuZC8y2u31FzH9w/l2aveer1V546g5x1Gw5mNQr9 Y7FedMbsefyeJhndLdVcdx8t/xq+3zBXiaU4I9FQi7moOBEAl1Fmr4wCAAA= Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question on "bits" 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: Fri, 26 Feb 2016 23:20:40 -0000 My assumption was "position" will help the implementers on the server side = as they can map it directly to their bitmask implementation. When "position" is carried north bound in read-only data, the client may n= ot be using it right ? Thanks & Regards, Sampath -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 25, 2016 11:44 AM To: Sampathkumar Santhanakrishnan Cc: netmod@ietf.org Subject: Re: [netmod] Question on "bits" in YANG On Thu, Feb 25, 2016 at 06:48:52PM +0000, Sampathkumar Santhanakrishnan wro= te: > I have a question on "bits" type in YANG. Does it make sense to use=20 > "bits" in "config:false" attributes ? Yes, why would it not make sense? > As per my understanding in the read-only uses cases, the bits=20 > "position" is not much useful. Please clarify. Why do you think the position is meaningful for config true but not for con= fig false leafs or date that is shipped in RPCs or actions or notifications= ? Here is the relevant text: The "position" statement, which is optional, takes as an argument a non-negative integer value that specifies the bit's position within a hypothetical bit field. The position value MUST be in the range 0 to 4294967295, and it MUST be unique within the bits type. The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors. The position is a 'convenience to implementors' and this convenience applie= s equally well to clients and servers. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 26 15:50:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992961B33E6 for ; Fri, 26 Feb 2016 15:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 8GEtsNv5BLzU for ; Fri, 26 Feb 2016 15:49:59 -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 939C41B33CC for ; Fri, 26 Feb 2016 15:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=812; q=dns/txt; s=iport; t=1456530599; x=1457740199; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WZuwEWyG915VDJa5txO3Bzw5ZOqs5W+GNMRSDT5iSmk=; b=U2sF8WmFYMmcSWPbCTgBeKUerm7GZdY0YS02+ApfLaANQ9tzUMllp9nj Iecsc4VIZc0X/1sLnZDu8wsYp8kFS3MHaT25KdOlnSz/TPL0UjUKZ+h6Y p7UnfLR40gTo4la8zrtYXFVviSUVI8cfIu533IYWsEIO7ByhDsCFStVA4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgCN49BW/5JdJa1egzqBRbg2ghMBD?= =?us-ascii?q?YFmh1I4FAEBAQEBAQFkHAuESIELAS1TJgEEG4gXn3meRAEBCAEBAQEBG4YSjSk?= =?us-ascii?q?FjWKJJgGNWI57jkgBHgEBQoNkiDd+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,505,1449532800"; d="scan'208";a="241237536" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2016 23:49:58 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1QNnwe2006243 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 26 Feb 2016 23:49:58 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 17:49:58 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Fri, 26 Feb 2016 17:49:57 -0600 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: YANG Push (PubSub): draft-ietf-netconf-yang-push-01 new revision Thread-Index: AdFw8F2NDTUV17gzTv2c3R11VDqFZg== Date: Fri, 26 Feb 2016 23:49:57 +0000 Message-ID: <95e8a595196c4c26bc9650b82721097e@XCH-ALN-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] YANG Push (PubSub): draft-ietf-netconf-yang-push-01 new revision 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, 26 Feb 2016 23:50:00 -0000 An updated draft for YANG subscriptions was posted in NETCONF WG earlier in= the week at draft-ietf-netconf-yang-push. Enhancements include: * Refined RPC & Notification definitions * Multiple targeted YANG subtrees within a single subscription =A0=A0=A0 - includes custom filters for each target * Static YANG subscriptions: new capabilities =A0=A0=A0 - ability to push to multiple recipients =A0=A0=A0 - ability to designate egress interface/address/VRF * Preparation for integration with RFC5277-bis =A0=A0 =A0- alignment on object names in preparation for an upcoming RFC527= 7-bis draft proposal =A0=A0 =A0- inclusion of RFC5277 filters We are hoping to get NETMOD's feedback, especially since much of the techno= logy is transport agnostic, - Alex, Eric, Alberto, Ambika, Einar From nobody Sat Feb 27 00:55:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F321B382A for ; Sat, 27 Feb 2016 00:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 hlYJOt5JOhfV for ; Sat, 27 Feb 2016 00:55:09 -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 B204E1B3829 for ; Sat, 27 Feb 2016 00:55:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 627BF219F; Sat, 27 Feb 2016 09:55:07 +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 kA-J1VHlbsu8; Sat, 27 Feb 2016 09:54:40 +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; Sat, 27 Feb 2016 09:55:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9814A20037; Sat, 27 Feb 2016 09:55:05 +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 0KdSnqqvGqMt; Sat, 27 Feb 2016 09:55:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9743B20036; Sat, 27 Feb 2016 09:55:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 66E4239FF79C; Sat, 27 Feb 2016 09:55:04 +0100 (CET) Date: Sat, 27 Feb 2016 09:55:04 +0100 From: Juergen Schoenwaelder To: Sampathkumar Santhanakrishnan Message-ID: <20160227085504.GA22788@elstar.local> Mail-Followup-To: Sampathkumar Santhanakrishnan , "netmod@ietf.org" References: <5ADC40FCE0FC7140AB4B8FD107A271C4219E9580@eusaamb109.ericsson.se> <20160225194334.GA20558@elstar.local> <5ADC40FCE0FC7140AB4B8FD107A271C4219E99FF@eusaamb109.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ADC40FCE0FC7140AB4B8FD107A271C4219E99FF@eusaamb109.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question on "bits" 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: Sat, 27 Feb 2016 08:55:11 -0000 On Fri, Feb 26, 2016 at 11:20:33PM +0000, Sampathkumar Santhanakrishnan wrote: > My assumption was "position" will help the implementers on the > server side as they can map it directly to their bitmask > implementation. When "position" is carried north bound in read-only > data, the client may not be using it right ? Either side can use or ignore the bit positions. /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 Feb 29 01:28:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815991B2E73 for ; Mon, 29 Feb 2016 01:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qb9cFeJlg112 for ; Mon, 29 Feb 2016 01:09:20 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 AB5D91B2E71 for ; Mon, 29 Feb 2016 01:09:20 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id D4374F3F30D3D for ; Mon, 29 Feb 2016 09:09:16 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1T99IMA012019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Feb 2016 09:09:18 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 u1T99IYn002965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Feb 2016 10:09:18 +0100 Received: from [135.224.219.72] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Feb 2016 10:09:18 +0100 To: From: Peter Verthez Message-ID: <56D40ABD.40507@alcatel-lucent.com> Date: Mon, 29 Feb 2016 10:09:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: X-Mailman-Approved-At: Mon, 29 Feb 2016 01:28:14 -0800 Subject: [netmod] Augment issue 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, 29 Feb 2016 09:09:24 -0000 Hi all, A few weeks ago I reported a bug on the OpenDaylight YANG parser, regarding a error that was generated on a particular augment construction. The bug report is the following: https://bugs.opendaylight.org/show_bug.cgi?id=5335 We are disagreeing on the interpretation of the YANG RFC regarding to this bug, so could we get the opinion of the people on this mailing list on it? The problem originated from a proposed Broadband Forum model, but there's a dummy model that reproduces the problem attached to that bug report. Thanks, Peter. From nobody Mon Feb 29 04:03:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5071B30EE; Mon, 29 Feb 2016 04:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 95IaLxAwMimj; Mon, 29 Feb 2016 04:03:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A2B1B30EB; Mon, 29 Feb 2016 04:03:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJH94106; Mon, 29 Feb 2016 12:03:13 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Feb 2016 12:03:12 +0000 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.28]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Mon, 29 Feb 2016 20:02:43 +0800 From: Rohit pobbathi To: "netmod@ietf.org" , netconf Thread-Topic: Query regarding "list" subelement XML Mapping rule Thread-Index: AdFy6RQi2WJEZslUTw+Vm6iwhTjwdw== Importance: high X-Priority: 1 Date: Mon, 29 Feb 2016 12:02:42 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44C003F0@SZXEML561-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.210.230] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56D43382.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.28, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 33219d9447e8dc8f1c7eee6379e5fe94 Archived-At: Subject: [netmod] Query regarding "list" subelement XML Mapping rule 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, 29 Feb 2016 12:03:20 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a query regarding "list" subelement XML Mapping rules - RFC 6020 Sec= tion 7.8.5. For clarity, I am using the "example-jukebox" YANG model (from RESTCONF dra= ft). +--rw jukebox! +--rw library | +--rw artist* [name] | | +--rw name string | | +--rw album* [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song* [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 Request from Client to Server: Foo Fighters Wasting Light =3D=3D=3D=3D=3D=3D> Request select= ion node order The selection nodes in above request are not in the same order as defined i= n the YANG model for "jukebox" module's "album" list. I assume this is allowed as per the RFC 6020 section 7.8.5's below paragrap= h: The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order. Please confirm if the above request's selection nodes order is valid = ? Response from Server to Client: Foo Fighters Wasting Light example-jukebox:alternative 2011 Wasting Light MP3 286 Rope MP3 259 For the above request, is it fine for the Server to encode the response wit= h list subelement order as per the defined YANG model ? OR Should the response follow the REQUEST's list subelement order ? Regards, Rohit P --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a query regarding "list" subelement= XML Mapping rules - RFC 6020 Section 7.8.5.

 

For clarity, I am using the "example-jukebox&qu= ot; YANG model (from RESTCONF draft).

   +--rw jukebox!

      +--rw library

      |  +--rw art= ist* [name]

      |  |  += --rw name     string

      |  |  += --rw album* [name]

      |  |  =    +--rw name     string

      |  |  =    +--rw genre?   identityref

      |  |  =    +--rw year?    uint16

      |  |  =    +--rw admin

      |  |  =    |  +--rw label?      &n= bsp;       string

      |  |  =    |  +--rw catalogue-number?   string

      |  |  =    +--rw song* [name]

      |  |  =       +--rw name     =    string

      |  |  =       +--rw location    string<= o:p>

      |  |  =       +--rw format?     st= ring

      |  |  =       +--rw length?     ui= nt32

      |  +--ro art= ist-count?   uint32

      |  +--ro alb= um-count?    uint32

      |  +--ro son= g-count?     uint32

 

Request from Client to Server:

     <rpc message-id=3D"= 101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

       <get>

         <= ;filter type=3D"subtree">

        &nbs= p;  <jukebox xmlns=3D"http://example.com/ns/example-jukebox&qu= ot;>

        &nbs= p;    <library>

        &nbs= p;      <artist>

        &nbs= p;        <name>Foo Fighters</n= ame>

        &nbs= p;        <album>

        &nbs= p;          <name>Wastin= g Light</name>

    &n= bsp;            = ;  <song/>         =       =3D=3D=3D=3D=3D=3D> Request selection nod= e order

    &n= bsp;            = ;  <year/>

    &n= bsp;            = ;  <genre>

        &nbs= p;        </album>

        &nbs= p;      </artist>

        &nbs= p;    </library>

        &nbs= p;  </jukebox>

         <= ;/filter>

       </get>

     </rpc>  &nb= sp;  

 

The selection nodes in above request are not in t= he same order as defined in the YANG model for “jukebox” module= ’s “album” list.

 

I assume this is allowed as per the RFC 6020 sect= ion 7.8.5’s below paragraph:

   The rest of t= he list's child nodes are encoded as subelements to the

   list element,= after the keys.  If the list defines RPC input or

   output parameters, the subelements are = encoded in the same order as

   they are defined within the "list&= quot; statement.  Otherwise, the

   subelements a= re encoded in any order.

 

Please confirm if the above <get> request&#= 8217;s selection nodes order is valid ?

 

Response from Server to Client:

     <rpc-reply message-id=3D= "101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"= >

       <data>

         <= ;jukebox xmlns:t=3D"http://example.com/ns/example-jukebox">

        &nbs= p;  <library>

        &nbs= p;    <artist>

        &nbs= p;      <name>Foo Fighters</name>=

        &nbs= p;      <album>

        &nbs= p;        <name>Wasting Light</= name>

    &n= bsp;            <= genre>example-jukebox:alternative</genre>

    &n= bsp;            <= year>2011</year>

    &n= bsp;            <= song>

    &n= bsp;            = ;  <name>Wasting Light</name>

    &n= bsp;            = ;  <format>MP3</format>

    &n= bsp;            = ;  <length>286</length>      = ;            

    &n= bsp;            = ;</song>

    &n= bsp;            <= song>

    &n= bsp;            = ;  <name>Rope</name>

    &n= bsp;            = ;  <format>MP3</format>

    &n= bsp;            = ;  <length>259</length>      = ;            

    &n= bsp;            = ;</song>          &= nbsp;     

        &nbs= p;      </album>

        &nbs= p;    </artist>

        &nbs= p;  </library>

         <= ;/jukebox>

       </data>

     </rpc-reply> &nb= sp;  

 

For the above request, is it fine for the Server = to encode the response with list subelement order as per the defined YANG m= odel ?

OR

Should the response follow the REQUEST’s li= st subelement order ?

 

Regards,

Rohit P

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_-- From nobody Mon Feb 29 07:33:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F291B3409 for ; Mon, 29 Feb 2016 07:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 MGYgOHoY13LS for ; Mon, 29 Feb 2016 07:33:38 -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 608A81B3408 for ; Mon, 29 Feb 2016 07:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2132; q=dns/txt; s=iport; t=1456760018; x=1457969618; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=H07mKrRy0DcKKTp4zcTIlbQoQKxUzMCfpr4WzEX1jUM=; b=LEqYZzUHGaysgfsP5ZLQIwc839oTxEsb5CvPZEG1S02v0tiOuzgaqAe8 z8rzWkzfohlURG35zRvV6IsLmWBOCDeG3FnlgMO/z/UZMBk7wJyqEudnh ETewmPoNG2+qPrnCvjvraytw9YfCer2WTn3kCNsMmMTqfXTiCBYL+wFqf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQC2Y9RW/xbLJq1ehAxtumsBDYFnF?= =?us-ascii?q?wqFKEoCgWsUAQEBAQEBAWQnhEIBAQQBAQE1NgsQCxgJJQ8CFjAGDQYCAQGIGw6?= =?us-ascii?q?+dQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEOohvAQSXDIVZiAmJJIVQjkoeA?= =?us-ascii?q?QFCg2Q8LgGIQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208";a="632967567" 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; 29 Feb 2016 15:33:36 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1TFXaDi018793; Mon, 29 Feb 2016 15:33:36 GMT To: Peter Verthez References: <56D40ABD.40507@alcatel-lucent.com> From: Robert Wilton Message-ID: <56D464D0.30308@cisco.com> Date: Mon, 29 Feb 2016 15:33:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D40ABD.40507@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Augment issue 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, 29 Feb 2016 15:33:40 -0000 Hi Peter, I agree with you, i.e. I think that this is a bug in the OpenDaylight YANG parser. My interpretation is that augmentations with mandatory nodes within a module, or a sub-module on nodes in its parent module are allowed. This augmentation from the jukebox-cd module onto an external module is allowed because it is not augmenting with a mandatory node: augment "/jbox:jukebox" { container cdcapable { presence "If present, indicates that the jukebox can play CDs"; } } This augmentation is allowed because it is from a sub-module to its parent module: augment "/jbox:jukebox/jboxcd:cdcapable" { description "Extra jukebox CD data"; leaf number-of-cds { type uint16; mandatory true; description "The number of CDs in the jukebox"; } } Interestingly, this second augmentation wouldn't/shouldn't be allowed if the cdcapable container didn't have presence. Which I think means that when a sub-module augmentation is being considered, it needs to determine what the combined augmentation on the external module is to determine whether the augmentation adds any unconditional mandatory nodes on the external module - which is not allowed. Thanks, Rob On 29/02/2016 09:09, Peter Verthez wrote: > Hi all, > > A few weeks ago I reported a bug on the OpenDaylight YANG parser, > regarding a error that was generated on a particular augment > construction. The bug report is the following: > https://bugs.opendaylight.org/show_bug.cgi?id=5335 > > We are disagreeing on the interpretation of the YANG RFC regarding to > this bug, so could we get the opinion of the people on this mailing > list on it? > > The problem originated from a proposed Broadband Forum model, but > there's a dummy model that reproduces the problem attached to that bug > report. > > Thanks, > Peter. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Feb 29 08:36:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5A1B3732 for ; Mon, 29 Feb 2016 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 I3jLpssPR680 for ; Mon, 29 Feb 2016 08:36: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 203C31B3731 for ; Mon, 29 Feb 2016 08:36:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:2985:7ae7:b23b:2832] (unknown [IPv6:2001:718:1a02:1:2985:7ae7:b23b:2832]) by mail.nic.cz (Postfix) with ESMTPSA id BFADE1802BE; Mon, 29 Feb 2016 17:36:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456763775; bh=fk4lF9QmmZCNcv8wfhofAbUqzfjTtC5H5WAyf7bkGhg=; h=From:Date:To; b=bcFAqxnb/5UAPOxlmdexL6hHFEEW8PRxsyLwQf1tRCJ9VEz5ZAy00c0bVySBzG0n4 nFGBt9cY1/vBAxWoZtPIAFAHcGDMNLmqjUimV4RWQjdib7g7P206x2YGbE0Vg4PLl6 YfMXUCzP34NBRnZSljKlX8ys40DoXb7MKC7mgYmc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56D40ABD.40507@alcatel-lucent.com> Date: Mon, 29 Feb 2016 17:36:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> References: <56D40ABD.40507@alcatel-lucent.com> To: Peter Verthez 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] Augment issue 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, 29 Feb 2016 16:36:19 -0000 Hi Peter, I agree it should be OK. I tried to reproduce the situation and test it = with pyang and it led to a Python exception. So I filed an issue: https://github.com/mbj4668/pyang/issues/206 Lada > On 29 Feb 2016, at 10:09, Peter Verthez = wrote: >=20 > Hi all, >=20 > A few weeks ago I reported a bug on the OpenDaylight YANG parser, = regarding a error that was generated on a particular augment = construction. The bug report is the following: > https://bugs.opendaylight.org/show_bug.cgi?id=3D5335 >=20 > We are disagreeing on the interpretation of the YANG RFC regarding to = this bug, so could we get the opinion of the people on this mailing list = on it? >=20 > The problem originated from a proposed Broadband Forum model, but = there's a dummy model that reproduces the problem attached to that bug = report. >=20 > Thanks, > Peter. >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From pkajsa@cisco.com Mon Feb 29 07:46:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3391B3421 for ; Mon, 29 Feb 2016 07:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 N9OLIdnISiub for ; Mon, 29 Feb 2016 07:46:09 -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 E0BF31B341A for ; Mon, 29 Feb 2016 07:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19467; q=dns/txt; s=iport; t=1456760768; x=1457970368; h=from:to:cc:subject:date:message-id:mime-version; bh=qF3MXtS4tH/LtO0Y8BmPDGr4zL0QzGXAIwFSK0t43zU=; b=Ht4NZU4ppCmNj/36NJy+Grm/4M0Nk7PJXt1AmncDu85/hpVXhxCPU2ip czzJzNMM++ILAtXN4q/P2osbbOWoUDZ8L1BqDMMRkQV1tm8nLUBMOgDgS tw2djor/3n2pH6JlkKqHg1KkVPGURcJ9zUQyQtwJtDSt8TvMxWT+fgbJf U=; X-Files: image002.jpg, image004.png : 2110, 901 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AgBMZ9RW/4YNJK1egm5MUm0GumUOg?= =?us-ascii?q?WchgjyDNoE2OBQBAQEBAQEBZBwLhEQEBSAIATsBDxIBJQEBAQoeBRAIBwwmAQQ?= =?us-ascii?q?OBAEIBogRDr53AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiOUQoHAS0vg3wFknWEF?= =?us-ascii?q?wEThFkBa4gCgWVLg3kIiEqOSQEeAUODZGoBhwcJFx1+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="jpg'145?png'145,150?scan'145,150,208,217,150,145";a="243798101" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 15:46:07 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1TFk7WY004216 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 15:46:07 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 09:46:07 -0600 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.009; Mon, 29 Feb 2016 09:46:06 -0600 From: "Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco)" To: "netmod@ietf.org" Thread-Topic: Augmentation of mandatory nodes issue Thread-Index: AdFzCEvxTVWzT3HuTq2hlqzafM0NOg== Date: Mon, 29 Feb 2016 15:46:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.231.128] Content-Type: multipart/related; boundary="_005_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 29 Feb 2016 08:53:01 -0800 Cc: "Igor Foltin -X \(ifoltin - PANTHEON TECHNOLOGIES at Cisco\)" , "Robert Varga -X \(rovarga - PANTHEON TECHNOLOGIES at Cisco\)" , "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "Martin Ciglan -X \(mciglan - PANTHEON TECHNOLOGIES at Cisco\)" , "peter.verthez@nokia.com" Subject: [netmod] Augmentation of mandatory nodes issue 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, 29 Feb 2016 16:03:36 -0000 --_005_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_ Content-Type: multipart/alternative; boundary="_000_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_" --_000_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everybody, we have encountered the following issue: augment "/other:module" { container foo { presence "some reason"; leaf bar { mandatory true; } } } We assume the augment is incorrect due to mandatory leaf "bar" and target n= ode in another module. Is it right ? ... and alternative writing of the same: augment "/other:module" { container foo { presence "some reason"; } } augment "/other:module/foo" { leaf bar { mandatatory true; } } We still assume the second augment is incorrect due to mandatory leaf "bar"= and target node in another module, but there are also beliefs it should be= correct due to the target node "foo" is from the same module. Thank you for help. Best Regards Peter [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] Peter Kajsa Engineer - Software pkajsa@cisco.com Phone: Cisco Systems Limited SK Cisco.com [Think before you print.]Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everybody,

 

we have encountered the following issue:<= /p>

 

augment "/other:module" {

   container foo {

       presence "= some reason";

       leaf bar {=

        &nbs= p;  mandatory true;

       }

   }

}

 

We assume the augment is incorrect due to mandatory = leaf „bar“ and target node in another module. Is it right ?

... and alternative writing of the same:<= /p>

 

augment "/other:module" {

   container foo {

presence "some rea= son";

   }

}

 

augment "/other:module/foo" {

   leaf bar {

       mandatatory tru= e;

   }

}

 

We still assume the second augment is incorrect due = to mandatory leaf „bar“ and target node in another module, but = there are also beliefs it should be correct due to the target node „f= oo“ is from the same module.

 

Thank you for help.

 

Best Regards

Peter

 

 

 

3D"http://www.cisco.com/web/europe/images/email/signature=

Peter Kajsa
Engineer - Software
pkajsa@cisco.com
Phone:

Cisco Systems L= imited




SK
Cisco.com

 

Think before you print.

This email may con= tain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message.

For corporate lega= l information go to:
http://www.cisco.com/web/about/doing_business/l= egal/cri/index.html

 

 

--_000_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_-- --_005_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2110; creation-date="Mon, 29 Feb 2016 15:46:05 GMT"; modification-date="Mon, 29 Feb 2016 15:46:05 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABbAIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooASkdwiMzdFGTWfresxaJZC 4ljaQFgoVetTC5W80k3CAhZISwB+lVyu1yPaR5nFPVEGka9Z635v2Qv+6ODuXGfcVpVwnw3bc17+ FdBe+KLex8RWukPDI0lxjDjGFJ6Vc6dpuMTChX5qSnU6m5RSUVkdQVjap4q07SNUtrC6aTzrjG3a uQMnAyai8PeLLbxFdXkEEMkbWzYJfHzc4/pXG+Pjjx3pf+9H/wChCtYU7y5ZGFSraHNA9Qpaztd1 iLQtJmv5o2kSPHyr1NLoerxa5pMN/CjRpKM7W6is+V2ubcyvy9TQooopDCiiigAooooASuXu9Zu4 vG8Vgsg+zsq5THqM11FU30mzk1Jb9ogblRgPVwkle5jWhOaXI7Wa+4wfiCcaJGf+mgrV0w58LQn/ AKdv6Vb1DTbbVLbyLyPfHnOPenm2VLFreBQqiMoo7DinzrkUSVSaqyqd0cP8MWy19+FReIT/AMXR 0of7Uf8AWtbwL4evtE+2G+RU3nC4Oc+9b8+h2FzqkOozQBrqH7j+lazqJVGzClRk6EYvRp/qZfjr VrrR/DzT2Unlys4XfjkVe8MX82p+HrS6uCDK6fMR37Vb1LTLXVrNrW9j8yJuSKktLSGxtY7e2QJF GMKo7Vjdctup1qMvac19Dzz4XnOs6x/vf+zGq3j8/wDFeaX/AL0f/oQr0HTdB0/SJp5bG3ETznLk d65Xxd4V1HVvF2m3toitbxlTIxONuCDW0aidTmMZUpRpKPmafxGOPBl39V/nS/Dw/wDFF2Z9jW9q Gn22qWUlpeRiSGQYZTS2Fhb6ZZR2lpGI4YxhVFZcy5OU25H7Tm8jjPBXiTUdY8W6zaXkweCAExoB 93DYrvKzdP8AD+naXfXN5Z24jnuTmRh35zWlSm03dDppxVmFFFFQWFFFFABRRSUAZmueILPQLYS3 jHc3CIvJasDTfiNbajqcFmthNGZm2hy4IrB8alZvHFtFfsVtfkBOeiZ5Negw6dpccUHlQWwVCDEQ B19jW7jCMU2rtnGp1KlRqLskZ3ibxbF4ant4pLSSczjgqwGOfer+qa3baPpH9oXeVjwCFHJJPQVx HxTONQ0z6H+ddL4m0GXxF4WitLeRUmAR03dCQOlLkjaLfU055uU0umxl6d8TLfUNRgtV0y4QTPsE hYECuq1bV7TRLF7u+k2RL+ZPoBXmen+IdZ8G3VtpurWUZts4UFRuwTjIarXxbuJXXTApP2Z1Lj0L f/qq3STmktiY1moNvdF4fFyya5WNNMuSjOFD7x3OM4rtdU1a00awe8vpRHCo69z7AVmaJpOhDQLc W8NrJAyKSxAOT6k+ua5L4xSSiHTo8sLckk46bv8A9VSownNRSsW5ThByk7lhvjDYCfaum3JizjzN 46euK7XRtbstesFu7CXfGeCDwVPoRWFY6N4bPg5AY7Y2pg3PKSM5xyc+ua5X4QPKNU1KOPJtsZP1 zx+lOUIOLcVawoympJSd7nq9FFFc50BRRRQAUUUUAFJS0UAYHifwpbeJIULuYriMYSQDt6H2rn9J +H+p2GqWk8+qpLBbvu8oBv0zXf0VoqskuUylQhKXM1qcn4x8I3PiW6tJbe5ihEAOQ6k559qv+ItD vdW0SKzsb37JPGVPmgkdPpzW7RS53p5Fezjq+551Z/DK8l1GKfW9XN3HEQQo3EnHbJ7V13iDw5Z+ ItM+x3SlQvMbr1Q+1a9FDqSbuKNKMU1bc8uj+FeqwyqketILYOG2YYZAOenSu81/w/aeI9LayvAc dUdeqN6itWinKpKTTYRpRimkeVN8I9SGYY9ZjFoW+4Vbp9Oma7vwx4ZtPC+nfZrXLux3SSt1c1tU USqykrNhGlGLugooorM0CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD// 2Q== --_005_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=901; creation-date="Mon, 29 Feb 2016 15:46:05 GMT"; modification-date="Mon, 29 Feb 2016 15:46:05 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABcAAAAYCAMAAAAmopZHAAAAAXNSR0ICQMB9xQAAAbZQTFRFAZcB AIkAC5oLAJQAHp8eAIwACZkJAJYAF5wXAJIAAJoAAJMAAZUBA5kDAJcAAJkAAJUAGJ8YBpsGB5cH AJgAD5cPAI8AAJEADZkNDZ4NCp0KB5wHCJwIAZoBAI4AAJAAAI0ABpwGF6IXH6EfHaUdHqUeGaMZ FaEVIaIhI6YjNq82LqcuLKksJqkmNa41NKg0KKkoKqQqIKAgK6grUK5QRrVGWLtYTLhMULVQSLZI QbNBSbNJQLNASrdKVblVUrpSUrRSb8ZvZMFkccZxYsBicMZwech5bMVsdMd0e8t7dch1dcd1c8Zz c8dzntmejtKOkNGQmtean9afjdGNhs+Gi9GLmdaZm9ebgs2Cg86Dg8yDg8qDkM+QkNKQh8+Hic+J hMuEpNukrd6todmhpNakrt+urd2tqNyoo9qjqt2qv+a/uOK4vuW+veW9tOG0v+W/1e7VyurKxefF 0e3R2/Hb3vLe0OzQzOnMzOvMx+nHwufCwebB1u/WzevNzuvOxujG+P349Pr08fnx+f354fPh7/nv 7Pjs/f/9/v/+6/fr8vry+/37/f79+Pz49vv2+v767fjt////CZs72gAAAAlwSFlzAAASdAAAEnQB 3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAFDSURBVCjPbdBXW8Iw FIDhasUYoknECuIqTpy4N4p7r4p7r6q4tyjuvZV/bFrq87C+u74X55yG84aPC/i6bakcDOP7rVxE 3tBdiB9URfJRbfch/rCZr6t+DJ1zWBANYtqfgn2pEAI9iq05CvKt2jhMaHzHcZA/DxsoQUXbLwH+ +taZQAWCUebyu79/dCVCTAihMGslYM7OqixlG+vktRG2gJOco2PjEmtiXfa5LG9IEkeLbTnQaFKC JogwwRgDADjkPNnNTTIrJaekmtMoz1PFcYnLe3rmVjq/8Hjq03l2FCEcEUu7J6dY0zOXbLlndm7e KuqZEwDVREvD3qd62EIZUFz4z2L/8l3cAwXmWhiLjZr3+rmAjE1X6pzvvnJMVBegqDP0L7q1H7fp 1L0EZ9gdzQM/mv66KhBRHVmv/V77xgyZ/QF1ccF7z1aUEgAAAABJRU5ErkJggg== --_005_e4028631a427447cb23e18191d61e9e7XCHALN020ciscocom_-- From nobody Mon Feb 29 09:00:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D381B37AF for ; Mon, 29 Feb 2016 09:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 SgPQ3_O1Y3Il for ; Mon, 29 Feb 2016 09:00: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 3176D1B37B6 for ; Mon, 29 Feb 2016 09:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43010; q=dns/txt; s=iport; t=1456765223; x=1457974823; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=68yH1lKmpK32EoqpplYRecpMZsYFYRSw8To3Ks1sZSw=; b=kd7HxsNj2uiSmv/wt351XpbAsHBmntPgvjTIxMgKUs7tC+/kSxcmK2+4 7dsRbluqiNpEd3q+r23mzfnkssykCBVIODcaToXWZ84gsmQjWrsVpI7sq Pprk5/tIvWLJ0SYJGPtbZwufawXLi1VCPN3Jr1vJ/67iLjns5unfjvZzr Y=; X-Files: : None X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208,217,150,145";a="625769697" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Feb 2016 17:00:21 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1TH0KVt008321; Mon, 29 Feb 2016 17:00:21 GMT To: "Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco)" References: From: Robert Wilton Message-ID: <56D47924.1030302@cisco.com> Date: Mon, 29 Feb 2016 17:00:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------010303050004040201070201" Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netmod@ietf.org" , "Robert Varga -X \(rovarga - PANTHEON TECHNOLOGIES at Cisco\)" , "Igor Foltin -X \(ifoltin - PANTHEON TECHNOLOGIES at Cisco\)" , "peter.verthez@nokia.com" , "Martin Ciglan -X \(mciglan - PANTHEON TECHNOLOGIES at Cisco\)" Subject: Re: [netmod] Augmentation of mandatory nodes issue 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, 29 Feb 2016 17:00:30 -0000 This is a multi-part message in MIME format. --------------010303050004040201070201 Content-Type: multipart/alternative; boundary="------------050800020807020209040102" --------------050800020807020209040102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Peter, Peter Verthez has already asked this same question earlier today. Please see attached responses (from Lada and myself) to see if they answer your/Peter V's query. Thanks, Rob On 29/02/2016 15:46, Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco) wrote: > > Hi everybody, > > we have encountered the following issue: > > augment "/other:module" { > > container foo { > > presence "some reason"; > > leaf bar { > > mandatory true; > > } > > } > > } > > We assume the augment is incorrect due to mandatory leaf bar and > target node in another module. Is it right ? > > ... and alternative writing of the same: > > augment "/other:module" { > > container foo { > > presence "some reason"; > > } > > } > > augment "/other:module/foo" { > > leaf bar { > > mandatatory true; > > } > > } > > We still assume the second augment is incorrect due to mandatory leaf > bar and target node in another module, but there are also beliefs it > should be correct due to the target node foo is from the same module. > > Thank you for help. > > Best Regards > > Peter > > http://www.cisco.com/web/europe/images/email/signature/logo05.jpg > > *Peter Kajsa* > Engineer - Software > pkajsa@cisco.com > Phone: > > > > *Cisco Systems Limited* > > > > > SK > Cisco.com > > > > > Think before you print.Think before you print. > > This email may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the > intended recipient (or authorized to receive for the recipient), > please contact the sender by reply email and delete all copies of this > message. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------050800020807020209040102 Content-Type: multipart/related; boundary="------------010802070601010604040802" --------------010802070601010604040802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Peter,

Peter Verthez has already asked this same question earlier today. Please see attached responses (from Lada and myself) to see if they answer your/Peter V's query.

Thanks,
Rob


On 29/02/2016 15:46, Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco) wrote:

Hi everybody,

we have encountered the following issue:

augment "/other:module" {

container foo {

presence "some reason";

leaf bar {

mandatory true;

}

}

}

We assume the augment is incorrect due to mandatory leaf bar and target node in another module. Is it right ?

... and alternative writing of the same:

augment "/other:module" {

container foo {

presence "some reason";

}

}

augment "/other:module/foo" {

leaf bar {

mandatatory true;

}

}

We still assume the second augment is incorrect due to mandatory leaf bar and target node in another module, but there are also beliefs it should be correct due to the target node foo is from the same module.

Thank you for help.

Best Regards

Peter

http://www.cisco.com/web/europe/images/email/signature/logo05.jpg

Peter Kajsa
Engineer - Software
pkajsa@cisco.com
Phone:

Cisco Systems Limited




SK
Cisco.com


Think before you print.Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 



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

--------------010802070601010604040802 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAm JSMgIyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMp PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAAR CABbAIoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooASkdwiMzdFGTWfresxaJZC4ljaQFgoVetTC5W80k3CAhZI SwB+lVyu1yPaR5nFPVEGka9Z635v2Qv+6ODuXGfcVpVwnw3bc17+FdBe+KLex8RWukPDI0lx jDjGFJ6Vc6dpuMTChX5qSnU6m5RSUVkdQVjap4q07SNUtrC6aTzrjG3auQMnAyai8PeLLbxF dXkEEMkbWzYJfHzc4/pXG+Pjjx3pf+9H/wChCtYU7y5ZGFSraHNA9Qpaztd1iLQtJmv5o2kS PHyr1NLoerxa5pMN/CjRpKM7W6is+V2ubcyvy9TQooopDCiiigAooooASuXu9Zu4vG8Vgsg+ zsq5THqM11FU30mzk1Jb9ogblRgPVwkle5jWhOaXI7Wa+4wfiCcaJGf+mgrV0w58LQn/AKdv 6Vb1DTbbVLbyLyPfHnOPenm2VLFreBQqiMoo7DinzrkUSVSaqyqd0cP8MWy19+FReIT/AMXR 0of7Uf8AWtbwL4evtE+2G+RU3nC4Oc+9b8+h2FzqkOozQBrqH7j+lazqJVGzClRk6EYvRp/q ZfjrVrrR/DzT2Unlys4XfjkVe8MX82p+HrS6uCDK6fMR37Vb1LTLXVrNrW9j8yJuSKktLSGx tY7e2QJFGMKo7Vjdctup1qMvac19Dzz4XnOs6x/vf+zGq3j8/wDFeaX/AL0f/oQr0HTdB0/S Jp5bG3ETznLkd65Xxd4V1HVvF2m3toitbxlTIxONuCDW0aidTmMZUpRpKPmafxGOPBl39V/n S/Dw/wDFF2Z9jW9qGn22qWUlpeRiSGQYZTS2Fhb6ZZR2lpGI4YxhVFZcy5OU25H7Tm8jjPBX iTUdY8W6zaXkweCAExoB93DYrvKzdP8AD+naXfXN5Z24jnuTmRh35zWlSm03dDppxVmFFFFQ WFFFFABRRSUAZmueILPQLYS3jHc3CIvJasDTfiNbajqcFmthNGZm2hy4IrB8alZvHFtFfsVt fkBOeiZ5Negw6dpccUHlQWwVCDEQB19jW7jCMU2rtnGp1KlRqLskZ3ibxbF4ant4pLSSczjg qwGOfer+qa3baPpH9oXeVjwCFHJJPQVxHxTONQ0z6H+ddL4m0GXxF4WitLeRUmAR03dCQOlL kjaLfU055uU0umxl6d8TLfUNRgtV0y4QTPsEhYECuq1bV7TRLF7u+k2RL+ZPoBXmen+IdZ8G 3VtpurWUZts4UFRuwTjIarXxbuJXXTApP2Z1Lj0Lf/qq3STmktiY1moNvdF4fFyya5WNNMuS jOFD7x3OM4rtdU1a00awe8vpRHCo69z7AVmaJpOhDQLcW8NrJAyKSxAOT6k+ua5L4xSSiHTo 8sLckk46bv8A9VSownNRSsW5ThByk7lhvjDYCfaum3JizjzN46euK7XRtbstesFu7CXfGeCD wVPoRWFY6N4bPg5AY7Y2pg3PKSM5xyc+ua5X4QPKNU1KOPJtsZP1zx+lOUIOLcVawoympJSd 7nq9FFFc50BRRRQAUUUUAFJS0UAYHifwpbeJIULuYriMYSQDt6H2rn9J+H+p2GqWk8+qpLBb vu8oBv0zXf0VoqskuUylQhKXM1qcn4x8I3PiW6tJbe5ihEAOQ6k559qv+ItDvdW0SKzsb37J PGVPmgkdPpzW7RS53p5Fezjq+551Z/DK8l1GKfW9XN3HEQQo3EnHbJ7V13iDw5Z+ItM+x3Sl QvMbr1Q+1a9FDqSbuKNKMU1bc8uj+FeqwyqketILYOG2YYZAOenSu81/w/aeI9LayvAcdUde qN6itWinKpKTTYRpRimkeVN8I9SGYY9ZjFoW+4Vbp9Oma7vwx4ZtPC+nfZrXLux3SSt1c1tU USqykrNhGlGLugooorM0CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gD//2Q== --------------010802070601010604040802 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABcAAAAYCAMAAAAmopZHAAAAAXNSR0ICQMB9xQAAAbZQTFRF AZcBAIkAC5oLAJQAHp8eAIwACZkJAJYAF5wXAJIAAJoAAJMAAZUBA5kDAJcAAJkAAJUAGJ8Y BpsGB5cHAJgAD5cPAI8AAJEADZkNDZ4NCp0KB5wHCJwIAZoBAI4AAJAAAI0ABpwGF6IXH6Ef HaUdHqUeGaMZFaEVIaIhI6YjNq82LqcuLKksJqkmNa41NKg0KKkoKqQqIKAgK6grUK5QRrVG WLtYTLhMULVQSLZIQbNBSbNJQLNASrdKVblVUrpSUrRSb8ZvZMFkccZxYsBicMZwech5bMVs dMd0e8t7dch1dcd1c8Zzc8dzntmejtKOkNGQmtean9afjdGNhs+Gi9GLmdaZm9ebgs2Cg86D g8yDg8qDkM+QkNKQh8+Hic+JhMuEpNukrd6todmhpNakrt+urd2tqNyoo9qjqt2qv+a/uOK4 vuW+veW9tOG0v+W/1e7VyurKxefF0e3R2/Hb3vLe0OzQzOnMzOvMx+nHwufCwebB1u/WzevN zuvOxujG+P349Pr08fnx+f354fPh7/nv7Pjs/f/9/v/+6/fr8vry+/37/f79+Pz49vv2+v76 7fjt////CZs72gAAAAlwSFlzAAASdAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9z b2Z0IE9mZmljZX/tNXEAAAFDSURBVCjPbdBXW8IwFIDhasUYoknECuIqTpy4N4p7r4p7r6q4 tyjuvZV/bFrq87C+u74X55yG84aPC/i6bakcDOP7rVxE3tBdiB9URfJRbfch/rCZr6t+DJ1z WBANYtqfgn2pEAI9iq05CvKt2jhMaHzHcZA/DxsoQUXbLwH++taZQAWCUebyu79/dCVCTAih MGslYM7OqixlG+vktRG2gJOco2PjEmtiXfa5LG9IEkeLbTnQaFKCJogwwRgDADjkPNnNTTIr JaekmtMoz1PFcYnLe3rmVjq/8Hjq03l2FCEcEUu7J6dY0zOXbLlndm7eKuqZEwDVREvD3qd6 2EIZUFz4z2L/8l3cAwXmWhiLjZr3+rmAjE1X6pzvvnJMVBegqDP0L7q1H7fp1L0EZ9gdzQM/ mv66KhBRHVmv/V77xgyZ/QF1ccF7z1aUEgAAAABJRU5ErkJggg== --------------010802070601010604040802-- --------------050800020807020209040102-- --------------010303050004040201070201 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Received: from xch-rcd-006.cisco.com (173.37.102.16) by xch-rcd-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Mailbox Transport; Mon, 29 Feb 2016 09:33:50 -0600 Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 09:33:49 -0600 Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 09:33:49 -0600 Received: from rcdn-iport-3.cisco.com (173.37.86.74) by mail.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 29 Feb 2016 09:33:49 -0600 Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 15:33:48 +0000 Received: from alln-inbound-m.cisco.com (alln-inbound-m.cisco.com [173.37.147.243]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1TFXje0017314; Mon, 29 Feb 2016 15:33:46 GMT Received-SPF: Pass (alln-inbound-m.cisco.com: domain of netmod-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-m.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="netmod-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-m.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-m.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-m.cisco.com; spf=Pass smtp.mailfrom=netmod-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dkim=pass (partially verified [2132 bytes]) header.i=@cisco.com; dmarc=pass (p=none dis=none) d=cisco.com X-from-outside-Cisco: 4.31.198.44 IronPort-PHdr: =?us-ascii?q?9a23=3ASyzysxDivKqOzx6isPfMUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP/zosbcNUDSrc9gkEXOFd2CrakU1KyI4+u/AiQp2tWojjMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3Dwdp?= =?us-ascii?q?POO9QteU1JTokb7isMKIKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu?= =?us-ascii?q?5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ6jiB/Y?= =?us-ascii?q?UAHa5mcASn5E1V1XHBeD7RzmUNH2qCS9s+N83CyTO4rxVaw1XjK5qKFmVBrvhH?= =?us-ascii?q?Q6MSUk+jTSg810kKUJph+9ohtzhpTZeZyYL+ZWf67Bc5UdX2UWRdtbVSFKHtah?= =?us-ascii?q?aZASBfEKJ+dSotrBoA42oAezH0GSCfnzyjJazivu0LE3yaI/HBva3AEyN9QJs3?= =?us-ascii?q?Xd6t7yMfFBf/qyyfzyyj/Ode8e5jb59I/OOkQ7vvCIQbV2WcHQ0kIoUQjCiwPD?= =?us-ascii?q?+sTeIzqJ27FV4CCg5O16WLfq0jZ/pg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0FEAAALZNRWlizGHwReGQEBAQEPAQEBA?= =?us-ascii?q?QYBAQEBglV9bbprAQ2BJTkgCoUogX84FAEBAQEBAQEBAg4BAQEBBw0JCSEvgi0?= =?us-ascii?q?KIRcGBAEBBAEBAQEBAQEBASMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQYCDTESARsBAQEDAQEBNwYBAQQKHgsBAgMBAgYBAQoYCRUICAMBCwI?= =?us-ascii?q?WMAYNBgIBAQGIGgECAgmvY4UnAQSJZgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8CB?= =?us-ascii?q?IYShDqIb5cRhVmICYkkhVCGeodOIAEBhCZqAYhCAQEB?= X-IPAS-Result: =?us-ascii?q?A0FEAAALZNRWlizGHwReGQEBAQEPAQEBAQYBAQEBglV9bbp?= =?us-ascii?q?rAQ2BJTkgCoUogX84FAEBAQEBAQEBAg4BAQEBBw0JCSEvgi0KIRcGBAEBBAEBA?= =?us-ascii?q?QEBAQEBASMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQYCDTE?= =?us-ascii?q?SARsBAQEDAQEBNwYBAQQKHgsBAgMBAgYBAQoYCRUICAMBCwIWMAYNBgIBAQGIG?= =?us-ascii?q?gECAgmvY4UnAQSJZgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8CBIYShDqIb5cRhVm?= =?us-ascii?q?ICYkkhVCGeodOIAEBhCZqAYhCAQEB?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208";a="194367215" X-Amp-Result: Clean X-Amp-File-Uploaded: False X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-m.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Feb 2016 15:33:43 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CACE01B340A; Mon, 29 Feb 2016 07:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1456760023; bh=s7h/MDjJmnYhMAvq2GWGOX6jt35OkxwtVv8sRbWBfNk=; h=To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=OLyTEEv/dPUh3l+2bv1tvDZJMGOST4JxYSxnOA7YAsLQ9nTrqdOGs+djqyebbcixV NQS3r89QcNInm/Gk6HBaf8KGzt8C4HXllytb0qHuCbXRW6oGmIj6MghDccnn+Kc61y 5r1vgWO1ncgrgTB5U52hQ6YghpfzLeFJQX526+gI= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F291B3409 for ; Mon, 29 Feb 2016 07:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 MGYgOHoY13LS for ; Mon, 29 Feb 2016 07:33:38 -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 608A81B3408 for ; Mon, 29 Feb 2016 07:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2132; q=dns/txt; s=iport; t=1456760018; x=1457969618; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=H07mKrRy0DcKKTp4zcTIlbQoQKxUzMCfpr4WzEX1jUM=; b=LEqYZzUHGaysgfsP5ZLQIwc839oTxEsb5CvPZEG1S02v0tiOuzgaqAe8 z8rzWkzfohlURG35zRvV6IsLmWBOCDeG3FnlgMO/z/UZMBk7wJyqEudnh ETewmPoNG2+qPrnCvjvraytw9YfCer2WTn3kCNsMmMTqfXTiCBYL+wFqf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQC2Y9RW/xbLJq1ehAxtumsBDYFnF?= =?us-ascii?q?wqFKEoCgWsUAQEBAQEBAWQnhEIBAQQBAQE1NgsQCxgJJQ8CFjAGDQYCAQGIGw6?= =?us-ascii?q?+dQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEOohvAQSXDIVZiAmJJIVQjkoeA?= =?us-ascii?q?QFCg2Q8LgGIQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208";a="632967567" 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; 29 Feb 2016 15:33:36 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1TFXaDi018793; Mon, 29 Feb 2016 15:33:36 GMT To: Peter Verthez References: <56D40ABD.40507@alcatel-lucent.com> From: Robert Wilton Message-ID: <56D464D0.30308@cisco.com> Date: Mon, 29 Feb 2016 15:33:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <56D40ABD.40507@alcatel-lucent.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Augment issue 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: netmod-bounces@ietf.org Sender: "netmod" Return-Path: netmod-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RCD-005.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 09a8f039-e05a-4feb-3067-08d3411db85d X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-SCL: -1 MIME-Version: 1.0 Hi Peter, I agree with you, i.e. I think that this is a bug in the OpenDaylight YANG parser. My interpretation is that augmentations with mandatory nodes within a module, or a sub-module on nodes in its parent module are allowed. This augmentation from the jukebox-cd module onto an external module is allowed because it is not augmenting with a mandatory node: augment "/jbox:jukebox" { container cdcapable { presence "If present, indicates that the jukebox can play CDs"; } } This augmentation is allowed because it is from a sub-module to its parent module: augment "/jbox:jukebox/jboxcd:cdcapable" { description "Extra jukebox CD data"; leaf number-of-cds { type uint16; mandatory true; description "The number of CDs in the jukebox"; } } Interestingly, this second augmentation wouldn't/shouldn't be allowed if the cdcapable container didn't have presence. Which I think means that when a sub-module augmentation is being considered, it needs to determine what the combined augmentation on the external module is to determine whether the augmentation adds any unconditional mandatory nodes on the external module - which is not allowed. Thanks, Rob On 29/02/2016 09:09, Peter Verthez wrote: > Hi all, > > A few weeks ago I reported a bug on the OpenDaylight YANG parser, > regarding a error that was generated on a particular augment > construction. The bug report is the following: > https://bugs.opendaylight.org/show_bug.cgi?id=5335 > > We are disagreeing on the interpretation of the YANG RFC regarding to > this bug, so could we get the opinion of the people on this mailing > list on it? > > The problem originated from a proposed Broadband Forum model, but > there's a dummy model that reproduces the problem attached to that bug > report. > > Thanks, > Peter. > > _______________________________________________ > 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 . --------------010303050004040201070201 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Received: from xch-rcd-009.cisco.com (173.37.102.19) by xch-rcd-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Mailbox Transport; Mon, 29 Feb 2016 10:36:31 -0600 Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 10:36:30 -0600 Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 10:36:29 -0600 Received: from alln-iport-8.cisco.com (173.37.142.95) by mail.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 29 Feb 2016 10:36:29 -0600 Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Feb 2016 16:36:29 +0000 Received: from alln-inbound-j.cisco.com (alln-inbound-j.cisco.com [173.37.147.240]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1TGaSh5022622; Mon, 29 Feb 2016 16:36:28 GMT Received-SPF: Pass (alln-inbound-j.cisco.com: domain of netmod-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-j.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="netmod-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-j.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-j.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-j.cisco.com; spf=Pass smtp.mailfrom=netmod-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org X-from-outside-Cisco: 2001:1900:3001:11::2c IronPort-PHdr: =?us-ascii?q?9a23=3ABZnkzh8lNK8P4f9uRHKM819IXTAuvvDOBiVQ1KB8?= =?us-ascii?q?0uIcTK2v8tzYMVDF4r011RmSDdqdtaIP27ee8/i5HzdfsdDZ6DFKWacPfiFGoP?= =?us-ascii?q?1epxYnDs+BBB+zB9/RRAt+Iv5/UkR49WqwK0lfFZW2TVTTpnqv8WxaQU2nZkJd?= =?us-ascii?q?b974EY/Kjsmxy/v6u9iKO10J13KAZ6hvJkCzpATVqs5Eh4Z+L6E9jwHEu2ZFYP?= =?us-ascii?q?h+xG50KxSUhRmr/dq6/pNo73FNvek8/dVLS6TwcvcFS6dFBmEmL3wt/5+s8gbc?= =?us-ascii?q?Uk2O62cSFGIMnV1NCgnB6Rj8GZDprir9sPE63iSGOMr6HowzDAyv86pxACHlkj?= =?us-ascii?q?sHOixxpHnalsFqyrxWug6hqg5XxYnXYYjTP/17KPDzZ9QfEE5IUsdKUyVfSqe8?= =?us-ascii?q?aJcMBqJVOeZfs4r0j10Ppl21F1//V6vU1jZUiyqujuUB2OM7HFSDhVR4Eg=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8F+AACOctRWjgAZASCDgISAEQAsXhkBA?= =?us-ascii?q?QEBDwEBAQEGAQEBAYJVfW26awENgSU4IQqFKIIBOBQBAQEBAQEBAQIOAQEBAQk?= =?us-ascii?q?WB1CCLQkBIRcQAQEBAQEBAQEBIwEBAQEBAQEBAQEBAQEcAg0xLQEBAQECAQEBA?= =?us-ascii?q?TcGAQEECh4LAQICAQECBgEBChgeCAgDASMwBhMFiBIJAgIJr26FJwEEiXsBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEPAgSEEINugk6HYIEPlxGFWZZ9hnqHTiABAYQna?= =?us-ascii?q?QGIQgEBAQ?= X-IPAS-Result: =?us-ascii?q?A8F+AACOctRWjgAZASCDgISAEQAsXhkBAQEBDwEBAQEGAQE?= =?us-ascii?q?BAYJVfW26awENgSU4IQqFKIIBOBQBAQEBAQEBAQIOAQEBAQkWB1CCLQkBIRcQA?= =?us-ascii?q?QEBAQEBAQEBIwEBAQEBAQEBAQEBAQEcAg0xLQEBAQECAQEBATcGAQEECh4LAQI?= =?us-ascii?q?CAQECBgEBChgeCAgDASMwBhMFiBIJAgIJr26FJwEEiXsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEPAgSEEINugk6HYIEPlxGFWZZ9hnqHTiABAYQnaQGIQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208";a="194129363" X-Amp-Result: Clean X-Amp-File-Uploaded: False X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-j.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Feb 2016 16:36:24 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3DF1B3732; Mon, 29 Feb 2016 08:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1456763783; bh=/Em26XBOOH3/tdPHr9EEDjapOb49SzBXRPJTNKSCzGI=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ByKvxALLP7lGz2ixY5mrggkQxtTxpsWgLtnIjLt/XbNkK+up/lKEq+wXS0KKIdG7J DmXn6KEaMwAZUjB2GJ32FRdYu+yLOqD/7v8q7R3aicgj2QpHrD0SVX0MSMg7f3BHMm 5U9F7EWNsc5KyguLQ88Ohlw6BzKmgejkShyeLSYs= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5A1B3732 for ; Mon, 29 Feb 2016 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 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, RP_MATCHES_RCVD=-0.006] 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 I3jLpssPR680 for ; Mon, 29 Feb 2016 08:36: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 203C31B3731 for ; Mon, 29 Feb 2016 08:36:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:2985:7ae7:b23b:2832] (unknown [IPv6:2001:718:1a02:1:2985:7ae7:b23b:2832]) by mail.nic.cz (Postfix) with ESMTPSA id BFADE1802BE; Mon, 29 Feb 2016 17:36:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456763775; bh=fk4lF9QmmZCNcv8wfhofAbUqzfjTtC5H5WAyf7bkGhg=; h=From:Date:To; b=bcFAqxnb/5UAPOxlmdexL6hHFEEW8PRxsyLwQf1tRCJ9VEz5ZAy00c0bVySBzG0n4 nFGBt9cY1/vBAxWoZtPIAFAHcGDMNLmqjUimV4RWQjdib7g7P206x2YGbE0Vg4PLl6 YfMXUCzP34NBRnZSljKlX8ys40DoXb7MKC7mgYmc= From: Ladislav Lhotka In-Reply-To: <56D40ABD.40507@alcatel-lucent.com> Date: Mon, 29 Feb 2016 17:36:15 +0100 Message-ID: <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> References: <56D40ABD.40507@alcatel-lucent.com> To: Peter Verthez 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] Augment issue 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: netmod-bounces@ietf.org Sender: "netmod" Return-Path: netmod-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-ALN-005.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 4dddf3f6-7e0c-444d-ac37-08d3412679da X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 Hi Peter, I agree it should be OK. I tried to reproduce the situation and test it with pyang and it led to a Python exception. So I filed an issue: https://github.com/mbj4668/pyang/issues/206 Lada > On 29 Feb 2016, at 10:09, Peter Verthez wrote: > > Hi all, > > A few weeks ago I reported a bug on the OpenDaylight YANG parser, regarding a error that was generated on a particular augment construction. The bug report is the following: > https://bugs.opendaylight.org/show_bug.cgi?id=5335 > > We are disagreeing on the interpretation of the YANG RFC regarding to this bug, so could we get the opinion of the people on this mailing list on it? > > The problem originated from a proposed Broadband Forum model, but there's a dummy model that reproduces the problem attached to that bug report. > > Thanks, > Peter. > > _______________________________________________ > 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 . --------------010303050004040201070201-- From nobody Mon Feb 29 12:27:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0D1B3B8E for ; Mon, 29 Feb 2016 12:27:13 -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 BE2EQq_tnmoa for ; Mon, 29 Feb 2016 12:27:10 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6591B3B8B for ; Mon, 29 Feb 2016 12:27:10 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id l68so7590062wml.0 for ; Mon, 29 Feb 2016 12:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=NVtkaZl+libWDgM1YJBNHBwNTM/tFjXYIBYkjzyc6mI=; b=gS2nioCAZJo4QHd/fNXB4XTCJ3YihUMbmWQXlih8cryx/rrZgErczM+GX8Piy6tF0B 3VyGUSh/JKi0nnj756ePCL6kpLuMBSNxq1LsV8EI6ftwtdEG1ZaZcgaHhk3JlKmb6wNz YR6EWLvO15CWnC7YZ6fKqLY5fq2+8bRaKSlbl8LipDFoHn3Z8nBDLYGVVRLg955EgwEp OaWZlsVC5R/kOKpqp93QKt0WDvyix0CS9Qq5TbT/32RMWwJ8glP8LBS1s+8udJB7owBC RPxLJ/J9ohVsF7OApWktXT4RmomLSHwHvE/ds0p/WJfiXobxqw3bchpBST4oluMdPMCn okPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NVtkaZl+libWDgM1YJBNHBwNTM/tFjXYIBYkjzyc6mI=; b=YOPKv1eJ3vE3CBFFDvCat2U7Vdbc2amRB7iJo5SZksp0CkcS5FosvRbcf3SqgH96Nh F1ZSCA5QhB25IYscGtSB5Vl6zi7zMwnkpGPLHqzehISUDfNb9aUjlyXui6bIelT66sHc DFP1Bv1ZY69cBFI2MlpLAOKv6to7Os8DtzEJljmTyz4sPv3etqmUJ+HnY2PurYa5PRTH xletH+DKiwGFhUOlU/wffqRZ9oRj6lc0m+kbQ51A6L8xEdcvUsBQ8kGI3TAJKKfEkXu3 +Sxt3T2NB3CyM/60LPsj5B1wOEMgrrdQOvq7V4Q1p4OLuwIRozDdc2pH0+BBiB2pq05j snYg== X-Gm-Message-State: AD7BkJItx3vTtWA9zREHhccXM8+phHHVTQd6BNmcz3j36riGKcwQpvtDgcbUs60drL3HuQ== X-Received: by 10.28.129.10 with SMTP id c10mr13124773wmd.35.1456777628651; Mon, 29 Feb 2016 12:27:08 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id a128sm17968282wmh.6.2016.02.29.12.27.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Feb 2016 12:27:08 -0800 (PST) From: "Xufeng Liu" To: "'Ladislav Lhotka'" References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> <004101d170a2$a3261590$e97240b0$@gmail.com> <56AC8C2F-1F3A-4E31-B708-5ED2FC8C738D@nic.cz> In-Reply-To: <56AC8C2F-1F3A-4E31-B708-5ED2FC8C738D@nic.cz> Date: Mon, 29 Feb 2016 15:27:05 -0500 Message-ID: <010701d1732f$8f868530$ae938f90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHigKfQG5ZVJrOoclQlBDSU3ZphwAHyblRyAxMkqOie+SxZgA== Content-Language: en-us Archived-At: Cc: 'NETMOD WG' Subject: Re: [netmod] proposed change to ietf-routing 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, 29 Feb 2016 20:27:13 -0000 It'd be better to have a consistent design pattern. There are at least three more options as following. Thanks, - Xufeng Option 1: +--rw networking-instances | +--rw networking-instance* [name] | +--rw name string | +--rw type? identityref | +--rw enabled? boolean | +--rw description? string | +--rw networking-instance-policy | +--rw root? structural-mount | +--rw routing | | +--rw router-id? yang:dotted-quad | | +--rw description? string | | +--rw routing-protocols | | | +--rw routing-protocol* [type name] | | | ... | | +--rw ribs | | +--rw rib* [name] | | ... | +--ro networking-instances-state +--ro networking-instance* [name] +--ro name string +--ro type? identityref +--ro enabled? boolean +--ro description? string +--ro networking-instance-policy +--ro root? structural-mount +--ro routing | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | ... | +--ro ribs | +--ro rib* [name] | ... Option 2: +--rw networking-instances +--rw networking-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw description? string +--rw networking-instance-policy +--rw root? structural-mount +--ro routing-state | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref +--rw routing +--rw router-id? yang:dotted-quad +--rw description? string +--rw routing-protocols | +--rw routing-protocol* [type name] | ... +--ro routing-protocols-state | +--ro routing-protocol* [type name] | ... +--rw ribs | +--rw rib* [name] | ... +--ro ribs-state +--rw rib* [name] ... Option 3: +--rw networking-instances +--rw networking-instance* [name] +--rw config | +--rw name string | +--rw type? identityref | +--rw enabled? boolean | +--rw description? string | +--rw networking-instance-policy | +--rw root? structural-mount | +--rw routing | +--rw config | | +--rw router-id? yang:dotted-quad | | +--rw description? string | | +--rw routing-protocols | | | +--rw routing-protocol* [type name] | | | +--rw config | | | | ... | | | +--ro state | | | | ... | | +--rw ribs | | +--rw config | | | +--rw rib* [name] | | | ... | | +--ro state | | +--ro rib* [name] | | ... | +--ro state | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro state ... > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Friday, February 26, 2016 10:41 AM > To: Xufeng Liu > Cc: NETMOD WG > Subject: Re: [netmod] proposed change to ietf-routing > > > > On 26 Feb 2016, at 15:33, Xufeng Liu wrote: > > > > Hi Acee and Lada, > > > > Have a question: the schema hierarchy will be different after the changes. > > Is the following expected? We will have ro branch and rw branch split > > in the middle of the tree after mounting? > > Yes, unless and until we agree on a better data organization. Note that it is > exactly the same as with ietf-interfaces. > > Lada > > > > > Before: > > > > module: ietf-routing > > +--ro routing-state > > | +--ro routing-instance* [name] > > | +--ro name string > > | +--ro routing-protocols > > | | +--ro routing-protocol* [type name] > > | | +--ro type identityref > > | | +--ro name string > > | +--ro ribs > > | +--ro rib* [name] > > | +--ro name string > > +--rw routing > > +--rw routing-instance* [name] > > +--rw name string > > +--rw routing-protocols > > | +--rw routing-protocol* [type name] > > | +--rw type identityref > > | +--rw name string > > +--rw ribs > > +--rw rib* [name] > > +--rw name string > > > > Now: > > > > +--rw networking-instances > > +--rw networking-instance* [name] > > +--rw name string > > +--rw type? identityref > > +--rw enabled? boolean > > +--rw description? string > > +--rw networking-instance-policy > > +--rw root? structural-mount > > +--ro routing-state > > | +--ro router-id? yang:dotted-quad > > | +--ro interfaces > > | | +--ro interface* if:interface-state-ref > > | +--ro routing-protocols > > | | +--ro routing-protocol* [type name] > > | | ... > > | +--ro ribs > > | +--ro rib* [name] > > | ... > > +--rw routing > > +--rw router-id? yang:dotted-quad > > +--rw description? string > > +--rw routing-protocols > > | +--rw routing-protocol* [type name] > > | ... > > +--rw ribs > > +--rw rib* [name] > > ... > > > > Thanks, > > > > - Xufeng > > > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > >> Lhotka > >> Sent: Friday, February 26, 2016 8:37 AM > >> To: NETMOD WG > >> Subject: [netmod] proposed change to ietf-routing > >> > >> Hi, > >> > >> as a part of synchronization of the routing data models that are > >> being > > developed > >> by the NETMOD and RTG working groups, the authors of > >> draft-ietf-netmod- routing-cfg propose to remove the routing-instance > >> level in the data > > hierarchy, > >> and leave it to structural-mount/YSDL to provide a top level structure. > >> > >> Schematically, the configuration and state data subtrees of > >> ietf-routing > > would > >> be reduced to something like this: > >> > >> module: ietf-routing > >> +--ro routing-state > >> | +--ro router-id? yang:dotted-quad > >> | +--ro interfaces > >> | | +--ro interface* if:interface-state-ref > >> | +--ro routing-protocols > >> | | +--ro routing-protocol* [type name] > >> | | ... > >> | +--ro ribs > >> | +--ro rib* [name] > >> | ... > >> +--rw routing > >> +--rw router-id? yang:dotted-quad > >> +--rw description? string > >> +--rw routing-protocols > >> | +--rw routing-protocol* [type name] > >> | ... > >> +--rw ribs > >> +--rw rib* [name] > >> ... > >> > >> Are there any objections to this change? > >> > >> Thanks, > >> > >> Acee and 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 Mon Feb 29 12:42:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3681B3BBF for ; Mon, 29 Feb 2016 12:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 32NNA5BtiUcr for ; Mon, 29 Feb 2016 12:40:21 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 71C4B1B3B9E for ; Mon, 29 Feb 2016 12:40:21 -0800 (PST) Received: (qmail 13959 invoked by uid 0); 29 Feb 2016 20:40:20 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Feb 2016 20:40:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id QTgC1s00X2SSUrH01TgFpW; Mon, 29 Feb 2016 20:40:17 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=RmxpPxEF5InAvrPPzoIA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=njzzTNU8iaeCudPNv5dn3FDR3URzB8BHfCxsA9rTBOY=; b=0Rgw8UJl0DsaKNtd3QnXupNBZYBg6Ioj1Vsr+wu3GIXoIX5ivJXmWw9Del6SP+UtwouLeqxzFoNJlLB9HIfWrY6HmmVwywc3hcYHt1zrFkcYf+jdNKVFfXuK7Kb56r+z; Received: from box313.bluehost.com ([69.89.31.113]:44794 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aaUc3-0005Br-7A; Mon, 29 Feb 2016 13:40:15 -0700 To: netmod WG , "netmod-chairs@ietf.org" From: Lou Berger Message-ID: <56D4ACA6.40208@labn.net> Date: Mon, 29 Feb 2016 15:40:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [netmod] Moving the WG discussion on mount forward 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, 29 Feb 2016 20:40:26 -0000 All, At last week's interim, Martin committed to update his document based on the meeting and then work with the other mount document authors (i.e., Lada and Alex) on a future version. Martin has now published this version: https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 Lada also said that he was okay with using Martin's document as a starting point for the working group document on this topic. (Keep in mind a -00 WG document is a starting point, not and end point.) We'd now like to ask for additional feedback from other WG contributors on their opinions on what they would like see added to base document in order for it to be accepted as a WG document. So please review the document and send comments to the list -- again on what areas need to be covered for the document to be accepted as a -00 WG draft. We're hoping for comments within the next week or so. Thank you, Netmod chairs From nobody Mon Feb 29 12:51:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5E1B3BDF for ; Mon, 29 Feb 2016 12:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 TEC67uOe6njw for ; Mon, 29 Feb 2016 12:51:20 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 409881B3BDA for ; Mon, 29 Feb 2016 12:50:40 -0800 (PST) Received: (qmail 326 invoked by uid 0); 29 Feb 2016 20:50:40 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Feb 2016 20:50:40 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id QLqd1s0092SSUrH01Lqg3A; Mon, 29 Feb 2016 13:50:40 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 a=m_r4I-a6jvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=m9ibG56PkOFYJnD20X6mkzGRk8mA0vOUxkQhMyfmYkM=; b=USz9Wy9CB+7AtsJ7si7ZTuQlx3eDr+J3xCw9TAhoqBvZSCLHjdQCmN59UzsQx+UjaNM8T1gbEg6rEH/18qLK/jjQjYQuc9OlJADEcnE0Ap9vyojqqwKzEdt9l1Q0SBGQ; Received: from box313.bluehost.com ([69.89.31.113]:47968 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aaUm4-0007rS-T0; Mon, 29 Feb 2016 13:50:36 -0700 To: netmod WG From: Lou Berger Message-ID: <56D4AF14.3020903@labn.net> Date: Mon, 29 Feb 2016 15:50:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-syslog-model@ietf.org Subject: [netmod] WG Last Call: draft-ietf-netmod-syslog-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: Mon, 29 Feb 2016 20:51:24 -0000 All, This starts a two-week working group last call on draft-ietf-netmod-syslog-model-06. The working group last call ends on March 14. Please send your comments to the netmod mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, Netmod Chairs From nobody Mon Feb 29 15:07:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533F1A00F5 for ; Mon, 29 Feb 2016 15:07:29 -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 DKKRs543hPWt for ; Mon, 29 Feb 2016 15:07:27 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694E11A00F3 for ; Mon, 29 Feb 2016 15:07:27 -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.415.20; Mon, 29 Feb 2016 23:07:25 +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.0415.022; Mon, 29 Feb 2016 23:07:25 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2Vw== Date: Mon, 29 Feb 2016 23:07:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:jjDmSIpgZiscI5iJKTkvaZMQukLVEshwmIXMKyCKsNnOi98lWn2p7CHLL/PkZ83wPCgCj2UGO2mYXH1UJ/IEOcJmLPHXzcSR04fTi53lmlr0lgsC2FwAYY1gaI0Wbh/bWjGlpeL3C5WPEabCGnWxyg==; 24:KBRzH7vCjvrk3VNUqblV5z8TNuBfIuW21kwzbADOmIb4mMOYUiPvnRiiUVV0YkZLyZnec9Yt/4j1eU3lmJ+zwTyeGPIoY3A3F9sd6jzUq2s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 747e957c-8008-4868-ff70-08d3415d1673 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(3660700001)(11100500001)(87936001)(82746002)(86362001)(2900100001)(92566002)(3280700002)(2906002)(33656002)(54356999)(83506001)(5004730100002)(16236675004)(2501003)(4001350100001)(36756003)(5001960100003)(107886002)(81156008)(110136002)(189998001)(2351001)(10400500002)(6116002)(99286002)(66066001)(106116001)(230783001)(586003)(3846002)(102836003)(122556002)(450100001)(40100003)(1730700002)(50986999)(19580395003)(1096002)(83716003)(5002640100001)(1220700001)(5008740100001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FEF6015375D1463E82D440ECDFCF3D34junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 23:07:25.2117 (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: 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: Mon, 29 Feb 2016 23:07:29 -0000 --_000_FEF6015375D1463E82D440ECDFCF3D34junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGUgY2hhaXJzIHdlcmUganVzdCByZXZpZXdpbmcgbm90ZXMgYW5kIHJlYWxpemVkIHRoYXQg dGhpcyB0aHJlYWQgbmV2ZXIgY2xvc2VkIHByb3Blcmx5Lg0KDQpKdWVyZ2VuIGhhcyBzb21lIGNv bmNlcm5zIHJlZ2FyZGluZyByZWFsaXN0aWMgbWlsZXN0b25lcywgdGhhdCB3ZXJlIG5ldmVyIGFk ZHJlc3NlZC4gIFJvYmVydCwgY2FuIHlvdSBwbGVhc2UgdHJ5IHRvIGFkZHJlc3MgSnVlcmdlbuKA mXMgY29uY2VybnMgbm93Pw0KDQpBbHNvLCB0aGVyZSB3ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2Vz IGJlZm9yZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgYXMgaXQg cHJvZ3Jlc3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGluKS4gIENhbiBvdGhlcnMgdGhhdCBzdXBw b3J0IHRoaXMgZHJhZnQgYW5kIHdpbGxpbmcgdG8gcmV2aWV3IHRoaXMgZHJhZnQgc2F5IHNvPw0K DQpUaGFua3MsDQpOZXRtb2QgQ2hhaXJzDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5u ZXQ+Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTE6NDggQU0NClRvOiAi bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW25ldG1vZF0gY2FsbCBmb3IgY29u c2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRN T0QgV0cgZHJhZnQNCg0KDQpUaGUgbWludXRlcyBmb3IgSUVURiA5NCBzaG93IHRoYXQgdGhlcmUg d2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRm LWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAgVGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhp cyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2gg SSBhbSBkb2luZyBub3cuDQoNClNob3VsZCB3ZSBtb3ZlIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1u ZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdHIGl0ZW0gYW5kIGNvcnJlc3BvbmRpbmdseSBhZGQg dGhpcyB0byB0aGUgV0cgY2hhcnRlciBhcyBhIG1pbGVzdG9uZT8gIFBsZWFzZSBjb21tZW50IGJ5 IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUg V0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg== --_000_FEF6015375D1463E82D440ECDFCF3D34junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <6F650104A5723D488C8BAEBF97484BEE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh cywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5UaGUgY2hhaXJzIHdlcmUganVzdCByZXZp ZXdpbmcgbm90ZXMgYW5kIHJlYWxpemVkIHRoYXQgdGhpcyB0aHJlYWQgbmV2ZXIgY2xvc2VkIHBy b3Blcmx5LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3Bh Y2U7IGZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvbnNvbGFzLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPkp1ZXJnZW4gaGFzIHNv bWUgY29uY2VybnMgcmVnYXJkaW5nIHJlYWxpc3RpYyBtaWxlc3RvbmVzLCB0aGF0IHdlcmUgbmV2 ZXIgYWRkcmVzc2VkLiAmbmJzcDtSb2JlcnQsIGNhbiB5b3UgcGxlYXNlIHRyeSB0byBhZGRyZXNz IEp1ZXJnZW7igJlzIGNvbmNlcm5zIG5vdz88L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhcywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEy cHg7Ij5BbHNvLCB0aGVyZSB3ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9yZSBpbmRpY2F0 aW5nIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jlc3NlcyAodGhh bmtzIERhbiBhbmQgTWFydGluKS4gJm5ic3A7Q2FuIG90aGVycyB0aGF0IHN1cHBvcnQgdGhpcyBk cmFmdCBhbmQgd2lsbGluZyB0byByZXZpZXcgdGhpcw0KIGRyYWZ0IHNheSBzbz88L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEy cHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9u b3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5UaGFua3MsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+TmV0bW9kIENo YWlyczwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1B Q19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQi Pmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTE6NDgg QU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ W25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2Qt aW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZSBtaW51dGVzIGZvciBJRVRGIDk0IHNob3cgdGhh dCB0aGVyZSB3YXMgaW4tcm9vbSBzdXBwb3J0IGZvciBhZG9wdGluZyZuYnNwOzwvZm9udD5kcmFm dC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBkcmFmdC4gJm5ic3A7IFRoZSBt aW51dGVzIGFsc28gc2hvdyB0aGF0IHRoaXMgZGVjaXNpb24gd291bGQgYmUgY29uZmlybWVkIG9u IHRoZSBtYWlsaW5nIGxpc3QsIHdoaWNoIEkNCiBhbSBkb2luZyBub3cuICZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2hvdWxkIHdlIG1vdmUgdG8gYWRvcHQgZHJhZnQtd2ls dG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgaXRlbSBhbmQgY29ycmVzcG9uZGluZ2x5 IGFkZCB0aGlzIHRvIHRoZSBXRyBjaGFydGVyIGFzIGEgbWlsZXN0b25lPyAmbmJzcDtQbGVhc2Ug Y29tbWVudCBieSBUdWVzZGF5LCBEZWNlbWJlciAyMiwgMjAxNSBhdCA5QU0gRVNUIGF0IHdoaWNo IHRpbWUgdGhlIFdHIENoYWlycyB3aWxsIGdhdWdlIHdoZXRoZXIgb3Igbm90IHRoZXJlIGlzDQog Y29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5LZW50PC9mb250PjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FEF6015375D1463E82D440ECDFCF3D34junipernet_-- From nobody Mon Feb 29 15:14:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0881A015D; Mon, 29 Feb 2016 15:14:15 -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 AtBhLPHiziNp; Mon, 29 Feb 2016 15:14:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.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 9EEA01A0158; Mon, 29 Feb 2016 15:14:12 -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.415.20; Mon, 29 Feb 2016 23:14: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.0415.022; Mon, 29 Feb 2016 23:14:10 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: working group secretary position Thread-Index: AQHRbm0g5U7Ub/IQl0GVAEQpdydREp9DXR2A Date: Mon, 29 Feb 2016 23:14:10 +0000 Message-ID: References: <02835CDF-1050-4D87-B11A-607E3D9CEC14@juniper.net> In-Reply-To: <02835CDF-1050-4D87-B11A-607E3D9CEC14@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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:/Us/J1K3Fb2JuSvbfxKBB3qCNzRzJulk1z1M4yJu5WAvyghtRwWS6+op/j+trM3IDUD0Sefwbd6kmS27Bvijwbwms413C4JtH/dbGSvh4TI1yvASjwQVqy+FigS5I7k3U8jUsnskPFUzOAUGj5O6UQ==; 24:x65nVTbDfJXql3lGdAll+FPLlolNTP5BwFls26YSCePCDWwa2AqeKTwjE/P68U3PYcncwhwUwdaIHAH5vH6J6xWqlAKgoFI0sDhbbZebauA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-ms-office365-filtering-correlation-id: 2a7bda00-591a-4c3d-3f71-08d3415e07fc 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)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(164054003)(11100500001)(19580395003)(66066001)(33656002)(3846002)(122556002)(40100003)(83716003)(99286002)(83506001)(77096005)(2950100001)(106116001)(450100001)(102836003)(2900100001)(5008740100001)(2906002)(6116002)(3280700002)(3660700001)(4326007)(2351001)(36756003)(82746002)(110136002)(5004730100002)(3480700003)(2501003)(5002640100001)(76176999)(189998001)(1730700002)(4001350100001)(54356999)(1096002)(50986999)(586003)(1220700001)(10400500002)(87936001)(81156008)(86362001)(5001960100003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 29 Feb 2016 23:14:10.5293 (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-chairs@ietf.org" Subject: Re: [netmod] working group secretary position 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, 29 Feb 2016 23:14:15 -0000 DQpUaGFuayB5b3UgYWxsIGZvciB5b3VyIHJlc3BvbnNlcy4NCg0KUGxlYXNlIHdlbGNvbWUgQXNo ZXNoIE1pc2hyYSBhcyB0aGUgbmV3IE5FVE1PRCBXRyBTZWNyZXRhcnkhDQoNClRoYW5rIHlvdSBB c2hlc2ggYW5kIHdlIGxvb2sgZm9yd2FyZCB0byB5b3VyIGhlbHAgd2l0aCA5NSBhbmQgYmV5b25k Lg0KDQoNClRoYW5rcywNCk5ldG1vZCBDaGFpcnMNCg0KDQoNCg0KT24gMi8yMy8xNiwgMjowNSBQ TSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5BbGwsDQo+ DQo+V2UgYXJlIGNvbnNpZGVyaW5nIHdoZXRoZXIgdG8gZmlsbCB0aGUgb3BlbiB3b3JraW5nIGdy b3VwIHNlY3JldGFyeSBwb3NpdGlvbi4gV29ya2luZyBHcm91cCBzZWNyZXRhcmllcyBoZWxwIHdp dGggV29ya2luZyBHcm91cCBhZG1pbmlzdHJhdGl2ZSB0YXNrcywgYW5kIGFyZSB0eXBpY2FsbHkg cmVzcG9uc2libGUgZm9yOg0KPg0KPiogcHJvZHVjaW5nIGRyYWZ0IG1lZXRpbmcgbm90ZXMgYmFz ZWQgb24gYXR0ZW5kaW5nIHRoZSBhY3R1YWwgbWVldGluZywgb3IgbGlzdGVuaW5nIHRvIHJlY29y ZGluZ3MgKG9yIGVuc3VyaW5nIHRoYXQgdGhleSBpZGVudGlmeSBzb21lb25lIHRvIHByb2R1Y2Ug aXQgZm9yIHRoZW0pDQo+DQo+KiBlbnN1cmluZyBkYXRhIHRyYWNrZXIgbWF0Y2hlcyB0aGUgZGlz Y3Vzc2lvbiBvbiB0aGUgbGlzdCAsIGVnLCBhZG9wdGlvbiBwb2xscyBhbmQgSVBSIGNoZWNrcy4N Cj4NCj4qIGNvbnNvbGlkYXRpbmcgbWVldGluZyBzbG90IHJlcXVlc3RzIGFuZCBtZWV0aW5nIHBy ZXNlbnRhdGlvbnMNCj4NCj4qIGVuc3VyaW5nICBhZ2VuZGFzLCBwcmVzZW50YXRpb25zLCBtaW51 dGVzLCBhcmUgcG9zdGVkICB0byBNYXRlcmlhbHMgTWFuYWdlcg0KPg0KPkJlaW5nIGEgd29ya2lu ZyBncm91cCBzZWNyZXRhcnkgbm90IG9ubHkgaGVscHMgb3V0IHRoZSBjaGFpcnMgYW5kIHRoZSB3 b3JraW5nIGdyb3VwLCBidXQgaXQncyBhbHNvIGdlbmVyYWxseSB2aWV3ZWQgYXMgYSBnb29kIHdh eSB0byBnZXQgZXhwZXJpZW5jZSBmb3IgdGhvc2UgaW50ZXJlc3RlZCBpbiBiZWNvbWluZyBhIFdv cmtpbmcgR3JvdXAgQ2hhaXIgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlLg0KPg0KPklmIHlv dSBhcmUgaW50ZXJlc3RlZCBpbiBzZXJ2aW5nIHRoaXMgZnVuY3Rpb24gZm9yIG5ldG1vZCwgcGxl YXNlIGxldCB0aGUgY2hhaXJzIGtub3cgd2l0aGluIHRoZSBuZXh0IHR3byB3ZWVrcy4gKElmIHlv dSByZXBseSB0byB0aGlzIG1haWwgdGhlcmUgaXMgbm8gbmVlZCB0byBDQyB0aGUgbWFpbGluZyBs aXN0LikNCj4NCj4NCj5UaGFuayB5b3UsDQo+DQo+TmV0bW9kIENoYWlycw0KPg0KPg0K From nobody Mon Feb 29 15:24:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D644E1A01F2; Mon, 29 Feb 2016 15:24:06 -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, FREEMAIL_FROM=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 2whe220Oo7Li; Mon, 29 Feb 2016 15:24:03 -0800 (PST) Received: from BAY004-OMC3S10.hotmail.com (bay004-omc3s10.hotmail.com [65.54.190.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B1B1A01D8; Mon, 29 Feb 2016 15:24:03 -0800 (PST) Received: from BAY407-EAS356 ([65.54.190.189]) by BAY004-OMC3S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 29 Feb 2016 15:24:03 -0800 X-TMN: [8mp4d+O360dmQkgCIwTs5Wenq1QVXr96] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ashesh Mishra MIME-Version: 1.0 (1.0) Date: Mon, 29 Feb 2016 15:24:02 -0800 References: <02835CDF-1050-4D87-B11A-607E3D9CEC14@juniper.net> To: Kent Watsen In-Reply-To: X-OriginalArrivalTime: 29 Feb 2016 23:24:03.0696 (UTC) FILETIME=[47075F00:01D17348] Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] working group secretary position 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, 29 Feb 2016 23:24:07 -0000 Thanks, Kent.=20 Looking forward to helping with the work.=20 Cheers, Ashesh Excuse brevity. Sent from mobile.=20 > On Feb 29, 2016, at 3:14 PM, Kent Watsen wrote: >=20 >=20 > Thank you all for your responses. >=20 > Please welcome Ashesh Mishra as the new NETMOD WG Secretary! >=20 > Thank you Ashesh and we look forward to your help with 95 and beyond. >=20 >=20 > Thanks, > Netmod Chairs >=20 >=20 >=20 >=20 >> On 2/23/16, 2:05 PM, "Kent Watsen" wrote: >>=20 >> All, >>=20 >> We are considering whether to fill the open working group secretary posit= ion. Working Group secretaries help with Working Group administrative tasks,= and are typically responsible for: >>=20 >> * producing draft meeting notes based on attending the actual meeting, or= listening to recordings (or ensuring that they identify someone to produce i= t for them) >>=20 >> * ensuring data tracker matches the discussion on the list , eg, adoption= polls and IPR checks. >>=20 >> * consolidating meeting slot requests and meeting presentations >>=20 >> * ensuring agendas, presentations, minutes, are posted to Materials Man= ager >>=20 >> Being a working group secretary not only helps out the chairs and the wor= king group, but it's also generally viewed as a good way to get experience f= or those interested in becoming a Working Group Chair at some point in the f= uture. >>=20 >> If you are interested in serving this function for netmod, please let the= chairs know within the next two weeks. (If you reply to this mail there is n= o need to CC the mailing list.) >>=20 >>=20 >> Thank you, >>=20 >> Netmod Chairs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Feb 29 19:56:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53B51A9174 for ; Mon, 29 Feb 2016 19:56:56 -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 4uKh-EIXiJf1 for ; Mon, 29 Feb 2016 19:56:55 -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 230851A9173 for ; Mon, 29 Feb 2016 19:56:55 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id v124so11979740lff.0 for ; Mon, 29 Feb 2016 19:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=k7VOfgTcc+aLXAaQabyDh3einyQi+CkLGbOY8pMK6rU=; b=J4CEbxxGLsaduIDSpVUcKX3gorWgO9HkziDgsGMsCFBnCiJvmpg7fStDWCSAK1jYUc GJ67nEA7nITfTMdQ2jeTBIf48C+8Swqn/1/EkVDM9AK0bKg8fpaUij04gx4ZSxuiuMwg X3oQ/ID9pAhLcNOn1VQ2mbFPB8uM6Q+DJtqSXnXLfzWsYo7z34MW1y0Ah5hEUx4an/bo /qeHBr8d80y7xhgSYYWiELGFf0DtlXjzczIIPKT9bOZHzoWJDyTeUwsEC9AhYjfTzSdm D9DroDNXqW9fXFpQD/bdQlMTlk4LSv8P6N3+1X9L/DrWPsSjM1VdpYw/ZqxMbw3WH6La nnuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=k7VOfgTcc+aLXAaQabyDh3einyQi+CkLGbOY8pMK6rU=; b=hbQH/ktlrSzy5220sCgf2INMODvHxhdgoCkHioWb1Zd/Xs6fQzQmeh/3UxpEOEsI8t UQRWC3dobJkqZh0KWJfdgpmSViDqYvlWI9musUpC+pl1JGluyXKVmvLky9WTrpePb9oP l2y2hpctRG+00BWvMP2iV3l0JDSt4rZP0lnbUfkVDOOqbSj+hXV6ByP/Nu/EEVXZhVXi jRR018XQXdogUn6J1EEMzGWYy71nKg/GPicUtdjKDURpvU5uLepfsJvDmTQY9b3LZzpc YBS+m1RHzvUS42kuIqt7KZE/jQZ9E0lC13XgI90X3Yl2KoHMB6kczchufO1B207eokuW FVUw== X-Gm-Message-State: AD7BkJLvkoByKnzaB/QF2snfngiLAN0ggPHCafeouKLGHv0ppfmYcuMAww7Dckx0z9Pi8kPne+bC+Ui6F6JRuA== MIME-Version: 1.0 X-Received: by 10.25.149.68 with SMTP id x65mr7019730lfd.138.1456804613365; Mon, 29 Feb 2016 19:56:53 -0800 (PST) Received: by 10.112.110.68 with HTTP; Mon, 29 Feb 2016 19:56:53 -0800 (PST) Date: Mon, 29 Feb 2016 19:56:53 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114038827cc398052cf4c131 Archived-At: Subject: [netmod] YANG 1.1 conformance announcement 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 Mar 2016 03:56:56 -0000 --001a114038827cc398052cf4c131 Content-Type: text/plain; charset=UTF-8 Hi, Buried in the many NETCONF-specific sections is a requirement to announce the YANG library info. However this info is incomplete and sec. 5.6.5 needs to be changed because it assumes there is only 1 revision of the ietf-yang-library module possible. The client cannot read the read the library to find out which revision of the library template to use. 5.6.5. Announcing Conformance Information in NETCONF This document defines the following mechanism for announcing conformance information. Other mechanisms may be defined by future specifications. A NETCONF server announces the modules it implements by implementing the YANG module "ietf-yang-library" defined in [I-D.ietf-netconf-yang-library], and listing all implemented modules in the "/modules-state/module" list. OLD: The server also advertises the following capability in the message (line-breaks and whitespaces are used for formatting reasons only): urn:ietf:params:netconf:capability:yang-library:1.0? module-set-id= The parameter "module-set-id" has the same value as the leaf "/modules-state/module-set-id" from "ietf-yang-library". This parameter MUST be present. NEW: The server also advertises the following capability in the message (line-breaks and whitespaces are used for formatting reasons only): urn:ietf:params:netconf:capability:yang-library:1.0? revision=&module-set-id= The parameter "revision" has the same value as the revision date of the "ietf-yang-library" implemented by the server. This parameter MUST be present. The parameter "module-set-id" has the same value as the leaf "/modules-state/module-set-id" from "ietf-yang-library". This parameter MUST be present. Andy --001a114038827cc398052cf4c131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Buried in the many NETCONF-specific= sections is a requirement to
announce the YANG library info.=C2= =A0 However this info is incomplete
and sec. 5.6.5 needs to be ch= anged because it assumes there is only
1 revision of the ietf-yan= g-library module possible. =C2=A0 The client cannot
read the read= the library to find out which revision of the library template
t= o use.




5.6.5. Announcing Conformance Information in N= ETCONF This document defines the following mechanism for announcing conformance information. Other mechanisms may be defined by future specifications. A NETCONF server announces the modules it implements by implementing the YANG module "ietf-yang-library" defined in [I-D.ietf-netconf-yang-library], and listing all implemented modules in the "/modules-state/module" list. 

OLD:
   The server also adver=
tises the following capability in the <hello>
   message (line-breaks and whitespaces are used for formatting reasons
   only):

     urn:ietf:params:netconf:capability:yang-library:1.0?
       module-set-id=3D<id>

   The parameter "module-set-id" has the same value as the leaf
   "/modules-state/module-set-id" from "ietf-yang-library&qu=
ot;.  This
   parameter MUST be present.

NEW:
   The server also advertises the following capability in the=
 <hello>
   message (line-breaks and whitespaces are used for formatting reasons
   only):

     urn:ietf:params:netconf:capability:yang-library:1.0?
       revision=3D<date>&module-set-id=3D<id>

   The parameter "revision" has the same valu=
e as the revision
   date of the "ietf-yang=
-library" implemented by the server. This
      parameter MUST be=
 present.

   The parameter "module-set-id&q=
uot; has the same value as the leaf
   "/modules-state/module-set-id" from "ietf-yang-library&qu=
ot;.  This
   parameter MUST be present.



Andy

--001a114038827cc398052cf4c131--