From nobody Mon Nov 3 00:03:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42001A6FD9 for ; Mon, 3 Nov 2014 00:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.594, 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 x9XvbLAO1alk for ; Mon, 3 Nov 2014 00:03:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D0BF71A6FAC for ; Mon, 3 Nov 2014 00:03:41 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 90D591280098; Mon, 3 Nov 2014 09:03:40 +0100 (CET) Date: Mon, 03 Nov 2014 09:03:40 +0100 (CET) Message-Id: <20141103.090340.1192037256809849296.mbj@tail-f.com> To: dai.xianxian@zte.com.cn From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9VyvZS4jL9PBU4tjYianjB8xlO0 Cc: rob.enns@gmail.com, dai_sissi@126.com, netconf@ietf.org, andy.bierman@brocade.com Subject: Re: [Netconf] some issues , like subtree filtering(RFC5277 & RFC6241 ) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:03:44 -0000 dai.xianxian@zte.com.cn wrote: > RFC5277 editors: > > > On RFC5277, The fifth section does not provide definition, just provides > some simple examples to illustrate the various > methods of filtering content on an event notification subscription. > > I want to know, about subtree filtering whether there is a correlation > between RFC6241 (Chapter 6)and RFC5277 (Chapter 5). > In my opinion, the two are in conflict.And I am confused. See RFC 5277, Section 3.6: If a filter element is specified to look for data of a particular value, and the data item is not present within a particular event notification for its value to be checked against, the notification will be filtered out. The idea is that if the filter would select *any* node in an event, then the event is sent, in its entirety. Thus, the filter acts a boolean switch, whether to send the event or not. /martin > Here are some specific questions. > 1.RFC5277,Chapter 5 > notification example defines like this: > event container > |-----eventClass leaf enum > |-----reportingEntity anyxml > |-----choice > |-------severity leaf enum > |-------operState leaf enum/boolean > > The filtering criteria evaluation is as follows:( state | config | ( fault > & ( card=Ethernet0))) > subscription like this: > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > state > > > config > > > fault > > Ethernet0 > > > > > > > If some service-reported notifications like these: > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2007-07-08T00:10:00Z > > state > > Ethernet1 > > major > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2007-07-08T00:10:00Z > > fault > > Ethernet0 > > major > > > > In accordance with RFC6241 rules, the second notification > "major" should be skipped. > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2007-07-08T00:10:00Z > > state > > Ethernet1 > > major > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2007-07-08T00:10:00Z > > fault > > Ethernet0 > > > > > As previous implementations, "filter" statement is only used as judgment > to meet the requirements of the rules,it does not act on output. > > > 2.subscription like this: > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > > > > > In accordance with RFC6241 rules, the expected output like this: > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2007-07-08T00:10:00Z > > fault > > > > Is it reasonable? > > > > > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. From nobody Mon Nov 3 00:47:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC881A0010 for ; Mon, 3 Nov 2014 00:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 jUJK2_qfO8sM for ; Mon, 3 Nov 2014 00:47:18 -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 DFA611A000F for ; Mon, 3 Nov 2014 00:47:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLF47559; Mon, 03 Nov 2014 08:47:15 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Nov 2014 08:47:12 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 3 Nov 2014 16:47:06 +0800 From: Qin Wu To: "dai.xianxian@zte.com.cn" , "rob.enns@gmail.com" , "mbj@tail-f.com" , "j.schoenwaelder@jacobs-university.de" , "andy.bierman@brocade.com" Thread-Topic: [Netconf] some issues , like subtree filtering(RFC5277 & RFC6241 ) Thread-Index: AQHP9Yzh8i9g3PSgbUuV07YEngpuHZxOmSjQ Date: Mon, 3 Nov 2014 08:47:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA846265F4nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/aR9U2ZeJ1hn5FD2LO_dDoeJdkdw Cc: "netconf@ietf.org" , "dai_sissi@126.com" Subject: Re: [Netconf] some issues , like subtree filtering(RFC5277 & RFC6241 ) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:47:20 -0000 --_000_B8F9A780D330094D99AF023C5877DABA846265F4nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WW91IHNlZW1zIHRvIGdpdmUgYW4gZXhhbXBsZSBvbiBzZW5kaW5nIGV2ZW50IG5vdGlmaWNhdGlv biBpbiByZXNwb25zZSB0byBjcmVhdGUgc3Vic2NyaXB0aW9uLg0KQnV0IHRoYXQgaXMgbm90IHRo ZSBleGFtcGxlIGRlc2NyaWJlZCBpbiBSRkM1Mjc3IG9yIFJGQzYyNDEuDQpBbHNvIEkgZmFpbCB0 byB1bmRlcnN0YW5kIHlvdXIgZm9sbG93aW5nIHN0YXRlbWVudA0KobANCiJmaWx0ZXIiIHN0YXRl bWVudCBpcyBvbmx5IHVzZWQgYXMganVkZ21lbnQgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9m IHRoZSBydWxlcyxpdCBkb2VzIG5vdCBhY3Qgb24gb3V0cHV0Lg0KobENCg0KUmVnYXJkcyENCi1R aW4NCreivP7IyzogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBkYWkueGlhbnhpYW5AenRlLmNvbS5jbg0Kt6LLzcqxvOQ6IDIwMTTE6jEx1MIxyNUgMTI6MzIN CsrVvP7Iyzogcm9iLmVubnNAZ21haWwuY29tOyBtYmpAdGFpbC1mLmNvbTsgai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlOyBhbmR5LmJpZXJtYW5AYnJvY2FkZS5jb20NCrOty806 IG5ldGNvbmZAaWV0Zi5vcmc7IGRhaV9zaXNzaUAxMjYuY29tDQrW98ziOiBbTmV0Y29uZl0gc29t ZSBpc3N1ZXMgLGxpa2Ugc3VidHJlZSBmaWx0ZXJpbmcoUkZDNTI3NyAmIFJGQzYyNDEgKQ0KDQoN ClJGQzUyNzcgZWRpdG9yczoNCg0KDQpPbiBSRkM1Mjc3LCBUaGUgZmlmdGggc2VjdGlvbiBkb2Vz IG5vdCBwcm92aWRlIGRlZmluaXRpb24sIGp1c3QgcHJvdmlkZXMgc29tZSBzaW1wbGUgZXhhbXBs ZXMgdG8gaWxsdXN0cmF0ZSB0aGUgdmFyaW91cw0KICAgbWV0aG9kcyBvZiBmaWx0ZXJpbmcgY29u dGVudCBvbiBhbiBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uLg0KDQpJIHdhbnQgdG8g a25vdywgYWJvdXQgc3VidHJlZSBmaWx0ZXJpbmcgd2hldGhlciB0aGVyZSBpcyBhIGNvcnJlbGF0 aW9uIGJldHdlZW4gUkZDNjI0MSAoQ2hhcHRlciA2KWFuZCBSRkM1Mjc3IChDaGFwdGVyIDUpLg0K SW4gbXkgb3BpbmlvbiwgdGhlIHR3byBhcmUgaW4gY29uZmxpY3QuQW5kIEkgYW0gY29uZnVzZWQu DQoNCkhlcmUgYXJlIHNvbWUgc3BlY2lmaWMgcXVlc3Rpb25zLg0KMS5SRkM1Mjc3LENoYXB0ZXIg NQ0Kbm90aWZpY2F0aW9uIGV4YW1wbGUgZGVmaW5lcyBsaWtlIHRoaXM6DQpldmVudCBjb250YWlu ZXINCiAgfC0tLS0tZXZlbnRDbGFzcyAgICAgICAgIGxlYWYgZW51bQ0KICB8LS0tLS1yZXBvcnRp bmdFbnRpdHkgICAgYW55eG1sDQogIHwtLS0tLWNob2ljZQ0KICAgICAgICAgICB8LS0tLS0tLXNl dmVyaXR5ICBsZWFmIGVudW0NCiAgICAgICAgICAgfC0tLS0tLS1vcGVyU3RhdGUgbGVhZiBlbnVt L2Jvb2xlYW4NCg0KVGhlIGZpbHRlcmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxv d3M6KCBzdGF0ZSB8IGNvbmZpZyB8ICggZmF1bHQgJiAoIGNhcmQ9RXRoZXJuZXQwKSkpDQpzdWJz Y3JpcHRpb24gbGlrZSB0aGlzOg0KPG5ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAx Ig0KeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4w Ij4NCjxjcmVhdGUtc3Vic2NyaXB0aW9uDQp4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiPg0KPGZpbHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUi Pg0KICAgPGV2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIj4NCiAgICAg IDxldmVudENsYXNzPnN0YXRlPC9ldmVudENsYXNzPg0KICAgPC9ldmVudD4NCiAgIDxldmVudCB4 bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCI+DQogICAgICA8ZXZlbnRDbGFzcz5j b25maWc8L2V2ZW50Q2xhc3M+DQogICA8L2V2ZW50Pg0KICAgPGV2ZW50IHhtbG5zPSJodHRwOi8v ZXhhbXBsZS5jb20vZXZlbnQvMS4wIj4NCiAgICAgIDxldmVudENsYXNzPmZhdWx0PC9ldmVudENs YXNzPg0KICAgICAgPHJlcG9ydGluZ0VudGl0eT4NCiAgICAgICAgIDxjYXJkPkV0aGVybmV0MDwv Y2FyZD4NCiAgICAgIDwvcmVwb3J0aW5nRW50aXR5Pg0KICAgIDwvZXZlbnQ+DQo8L2ZpbHRlcj4N CjwvY3JlYXRlLXN1YnNjcmlwdGlvbj4NCjwvbmV0Y29uZjpycGM+DQoNCklmIHNvbWUgc2Vydmlj ZS1yZXBvcnRlZCBub3RpZmljYXRpb25zIGxpa2UgdGhlc2U6DQo8bm90aWZpY2F0aW9uDQp4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiPg0KICAg PGV2ZW50VGltZT4yMDA3LTA3LTA4VDAwOjEwOjAwWjwvZXZlbnRUaW1lPg0KICAgPGV2ZW50IHht bG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIj4NCiAgICAgIDxldmVudENsYXNzPnN0 YXRlPC9ldmVudENsYXNzPg0KICAgICAgPHJlcG9ydGluZ0VudGl0eT4NCiAgICAgICAgIDxjYXJk PkV0aGVybmV0MTwvY2FyZD4NCiAgICAgIDwvcmVwb3J0aW5nRW50aXR5Pg0KICAgICAgPHNldmVy aXR5Pm1ham9yPC9zZXZlcml0eT4NCjwvZXZlbnQ+DQo8L25vdGlmaWNhdGlvbj4NCg0KPG5vdGlm aWNhdGlvbg0KeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRp b246MS4wIj4NCiAgIDxldmVudFRpbWU+MjAwNy0wNy0wOFQwMDoxMDowMFo8L2V2ZW50VGltZT4N CiAgIDxldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCI+DQogICAgICA8 ZXZlbnRDbGFzcz5mYXVsdDwvZXZlbnRDbGFzcz4NCiAgICAgIDxyZXBvcnRpbmdFbnRpdHk+DQog ICAgICAgICA8Y2FyZD5FdGhlcm5ldDA8L2NhcmQ+DQogICAgICA8L3JlcG9ydGluZ0VudGl0eT4N CiAgICAgIDxzZXZlcml0eT5tYWpvcjwvc2V2ZXJpdHk+DQo8L2V2ZW50Pg0KPC9ub3RpZmljYXRp b24+DQoNCkluIGFjY29yZGFuY2Ugd2l0aCBSRkM2MjQxIHJ1bGVzLCB0aGUgc2Vjb25kIG5vdGlm aWNhdGlvbiAiPHNldmVyaXR5Pm1ham9yPC9zZXZlcml0eT4iIHNob3VsZCBiZSBza2lwcGVkLg0K PG5vdGlmaWNhdGlvbg0KeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3Rp ZmljYXRpb246MS4wIj4NCiAgIDxldmVudFRpbWU+MjAwNy0wNy0wOFQwMDoxMDowMFo8L2V2ZW50 VGltZT4NCiAgIDxldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCI+DQog ICAgICA8ZXZlbnRDbGFzcz5zdGF0ZTwvZXZlbnRDbGFzcz4NCiAgICAgIDxyZXBvcnRpbmdFbnRp dHk+DQogICAgICAgICA8Y2FyZD5FdGhlcm5ldDE8L2NhcmQ+DQogICAgICA8L3JlcG9ydGluZ0Vu dGl0eT4NCiAgICAgIDxzZXZlcml0eT5tYWpvcjwvc2V2ZXJpdHk+DQo8L2V2ZW50Pg0KPC9ub3Rp ZmljYXRpb24+DQoNCjxub3RpZmljYXRpb24NCnhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCI+DQogICA8ZXZlbnRUaW1lPjIwMDctMDctMDhUMDA6 MTA6MDBaPC9ldmVudFRpbWU+DQogICA8ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9l dmVudC8xLjAiPg0KICAgICAgPGV2ZW50Q2xhc3M+ZmF1bHQ8L2V2ZW50Q2xhc3M+DQogICAgICA8 cmVwb3J0aW5nRW50aXR5Pg0KICAgICAgICAgPGNhcmQ+RXRoZXJuZXQwPC9jYXJkPg0KICAgICAg PC9yZXBvcnRpbmdFbnRpdHk+DQo8L2V2ZW50Pg0KPC9ub3RpZmljYXRpb24+DQoNCkFzIHByZXZp b3VzIGltcGxlbWVudGF0aW9ucywgImZpbHRlciIgc3RhdGVtZW50IGlzIG9ubHkgdXNlZCBhcyBq dWRnbWVudCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHJ1bGVzLGl0IGRvZXMgbm90 IGFjdCBvbiBvdXRwdXQuDQoNCg0KMi5zdWJzY3JpcHRpb24gbGlrZSB0aGlzOg0KPG5ldGNvbmY6 cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIg0KeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCjxjcmVhdGUtc3Vic2NyaXB0aW9uDQp4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiPg0KPGZp bHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUiPg0KICAgPGV2ZW50IHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vZXZlbnQvMS4wIj4NCiAgICAgIDxldmVudENsYXNzLz4NCiAgIDwvZXZlbnQ+DQo8 L2ZpbHRlcj4NCjwvY3JlYXRlLXN1YnNjcmlwdGlvbj4NCjwvbmV0Y29uZjpycGM+DQoNCkluIGFj Y29yZGFuY2Ugd2l0aCBSRkM2MjQxIHJ1bGVzLCB0aGUgZXhwZWN0ZWQgb3V0cHV0IGxpa2UgdGhp czoNCjxub3RpZmljYXRpb24NCnhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 bm90aWZpY2F0aW9uOjEuMCI+DQogICA8ZXZlbnRUaW1lPjIwMDctMDctMDhUMDA6MTA6MDBaPC9l dmVudFRpbWU+DQogICA8ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAi Pg0KICAgICAgPGV2ZW50Q2xhc3M+ZmF1bHQ8L2V2ZW50Q2xhc3M+DQo8L2V2ZW50Pg0KPC9ub3Rp ZmljYXRpb24+DQoNCklzIGl0IHJlYXNvbmFibGU/DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRo KSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50 ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku DQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQoNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA846265F4nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

You seems = to give an example on sending event notification in response to create subs= cription.

But that i= s not the example described in RFC5277 or RFC6241.

Also I fai= l to understand your following statement

=A1=B0

"filt= er" statement is only used as judgment to meet the requirements of the= rules,it does not act on output.
=A1=B1

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: Netconf= [mailto:netconf-bounces@ietf.org] =B4=FA= =B1=ED dai.xianxian@zte.com.cn
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA11=D4=C21=C8=D5 12:32
=CA=D5=BC=FE=C8=CB: rob.enns@gmail.com; mbj@tail-f.com; j.schoenwaelder@jacobs-universi= ty.de; andy.bierman@brocade.com
=B3=AD=CB=CD: netconf@ietf.org; dai_sissi@126.com
=D6=F7=CC=E2: [Netconf] some issues ,like subtree filtering(RFC5277 & RFC6241 )

 

 
RFC5277 editors:


On RFC5277, The fifth section does not pro= vide definition, just provides some simple examples to illustrate the vario= us
   methods of filtering content = on an event notification subscription.
   
I want to know, about subtree filtering wh= ether there is a correlation between RFC6241 (Chapter 6)and RFC5277 (Chapte= r 5).
In my opinion, the two are in conflict.And= I am confused.

Here are some specific questions.
1.RFC5277,Chapter 5
notification example defines like this:
event container
  |-----eventClass     &nbs= p;   leaf enum
  |-----reportingEntity    = anyxml
  |-----choice
           |= -------severity  leaf enum
           |= -------operState leaf enum/boolean
            =        
The filtering criteria evaluation is as fo= llows:( state | config | ( fault & ( card=3DEthernet0)))     =              
subscription like this:
<netconf:rpc netconf:message-id=3D"= ;101"
xmlns:netconf=3D"urn:ietf:params:xml:= ns:netconf:base:1.0">
<create-subscription
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
<filter netconf:type=3D"subtree&qu= ot;>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>sta= te</eventClass>
   </event>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>con= fig</eventClass>
   </event>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>fau= lt</eventClass>
      <reportingEntity&g= t;
         <card= >Ethernet0</card>
      </reportingEntity&= gt;
    </event>
</filter>
</create-subscription>
</netconf:rpc>

If some service-reported notifications lik= e these:
<notification
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
   <eventTime>2007-07-08T0= 0:10:00Z</eventTime>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>sta= te</eventClass>
      <reportingEntity&g= t;
         <card= >Ethernet1</card>
      </reportingEntity&= gt;
      <severity>major= </severity>
</event>
</notification>

<notification
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
   <eventTime>2007-07-08T0= 0:10:00Z</eventTime>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>fau= lt</eventClass>
      <reportingEntity&g= t;
         <card= >Ethernet0</card>
      </reportingEntity&= gt;
      <severity>major= </severity>
</event>
</notification>

In accordance with RFC6241 rules, the seco= nd notification "<severity>major</severity>" should b= e skipped.
<notification
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
   <eventTime>2007-07-08T0= 0:10:00Z</eventTime>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>sta= te</eventClass>
      <reportingEntity&g= t;
         <card= >Ethernet1</card>
      </reportingEntity&= gt;
      <severity>major= </severity>
</event>
</notification>

<notification
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
   <eventTime>2007-07-08T0= 0:10:00Z</eventTime>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>fau= lt</eventClass>
      <reportingEntity&g= t;
         <card= >Ethernet0</card>
      </reportingEntity&= gt;
</event>
</notification>

As previous implementations, "filter&= quot; statement is only used as judgment to meet the requirements of the ru= les,it does not act on output.


2.subscription like this:
<netconf:rpc netconf:message-id=3D"= ;101"
xmlns:netconf=3D"urn:ietf:params:xml:= ns:netconf:base:1.0">
<create-subscription
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
<filter netconf:type=3D"subtree&qu= ot;>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass/>
   </event>
</filter>
</create-subscription>
</netconf:rpc>

In accordance with RFC6241 rules, the expe= cted output like this:
<notification
xmlns=3D"urn:ietf:params:xml:ns:netco= nf:notification:1.0">
   <eventTime>2007-07-08T0= 0:10:00Z</eventTime>
   <event xmlns=3D"= http://example.com/event/1.0&qu= ot;>
      <eventClass>fau= lt</eventClass>
</event>
</notification>

Is it reasonable? 









 

----------------------------=
----------------------------


ZTE Information Security Not=
ice: The information contained in this mail (and any attachment transmitted=
 herewith) is privileged and confidential and is intended for the exclusive=
 use of the addressee(s).  If you are not an intended recipient, any d=
isclosure, reproduction, distribution or other dissemination or use of the =
information contained is strictly prohibited.  If you have received th=
is mail in error, please delete it and notify us immediately.


 

=
 


 

----------------------------=
----------------------------


ZTE Information Security Not=
ice: The information contained in this mail (and any attachment transmitted=
 herewith) is privileged and confidential and is intended for the exclusive=
 use of the addressee(s).  If you are not an intended recipient, any d=
isclosure, reproduction, distribution or other dissemination or use of the =
information contained is strictly prohibited.  If you have received th=
is mail in error, please delete it and notify us immediately.


 

 
--_000_B8F9A780D330094D99AF023C5877DABA846265F4nkgeml501mbschi_-- From nobody Mon Nov 3 03:40:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB201A0092 for ; Mon, 3 Nov 2014 03:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_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 7mzmDYasQHlU for ; Mon, 3 Nov 2014 03:40:10 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2631A0076 for ; Mon, 3 Nov 2014 03:40:09 -0800 (PST) Received: from pc6 (86.184.62.161) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 3 Nov 2014 11:34:55 +0000 Message-ID: <015901cff759$d7405020$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Luchuk , References: <201410311419.s9VEJQWY009047@mainfs.snmp.com> Date: Mon, 3 Nov 2014 11:32:14 +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.184.62.161] X-ClientProxiedBy: AM3PR01CA046.eurprd01.prod.exchangelabs.com (10.141.191.36) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0384275935 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(199003)(51444003)(51704005)(107046002)(46102003)(92566001)(23756003)(19580395003)(50466002)(50226001)(89996001)(87286001)(116806002)(44716002)(44736004)(61296003)(120916001)(105586002)(77096003)(77156002)(99396003)(106356001)(101416001)(95666004)(42186005)(14496001)(88136002)(93916002)(102836001)(92726001)(104166001)(40100003)(81816999)(81686999)(76176999)(122386002)(66066001)(21056001)(86362001)(87976001)(84392001)(19580405001)(31966008)(64706001)(20776003)(50986999)(47776003)(33646002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vPod3JHT9ytHZzAjLCVHKL2tUuo Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 11:40:12 -0000 ----- Original Message ----- From: "Alan Luchuk" To: Cc: ; ; Sent: Friday, October 31, 2014 2:19 PM > Also, included below is the following new proposed text for Section 2.4.1, > and a new section 2.4.2. The new section 2.4.2 would displace the existing > section 2.4.2 to have 2.4.3, and so on. Thoughts on this? Alan I am unclear on what you are proposing For me, there is a clear split between the validation of X.509 certificates and the use then made of the contents thereof, something which I do not see in the paragraphs you propose. Thus the procedures of RFC5280 section 6 apply to all X.509 certificates and require the client to be configured with suitable trust anchors. If the client is configured with the server certificate per se, then that is a degenerate case thereof. I think that RFC5539 s.3.1 paragraph 4 gets that about right and little if anything needs changing with that (except putting it first!). Once the certificate has been validated, then it is a question of extracting the identifier of the server from it and comparing that to a reference identifier configured in the client. I think that RFC6125 does us no favours; it limits itself to "service identities associated with fully-qualified DNS domain names" preferably with SRV-IDs, which I think too restrictive - we have to reference it, but need to qualify the use thereof. So we cannot reuse the other paragraphs of RFC5539 but need to say something like 'SHOULD use RFC6125' but then go on to qualify it. Tom Petch > Regards, > --Alan > > Section 2.4.1 Verifying the NETCONF Server Identity > ---------------------------------------------------- > > The NETCONF client MUST verify the identity of the NETCONF server. > The NETCONF client MAY use the procedure documented in Section 2.4.2 > to verify the identify of the NETCONF server. The NETCONF client MAY > use an alternate procedure to verify the identity the NETCONF server. > > If the NETCONF client uses an alternate procedure to verify the identity > of the NETCONF server, then the alternate procedure must > provide a level of verification comparable to the procedure documented > in Section 2.4.2. One example of an alternate procedure for verifying > the NETCONF server's identity would be to compare the X.509 certificate > presented by the NETCONF server against a local store of > already-verified X.509 certificates and identity bindings. > > If the NETCONF client attempts to connect to a NETCONF server, and the > NETCONF server fails the identity verification step, then the NETCONF > client MUST notify the user that the NETCONF server identity > verification failed, and 1) either terminate the connection, or > 2) request user confirmation to proceed with the connection. > > > Section 2.4.2 Standard Procedure for Verifying the NETCONF Server Identity > ---------------------------------------------------------------------- ----- > > If the NETCONF client uses this documented procedure to verify the > identify of the NETCONF server, then the NETCONF client MUST follow > follow this procedure completely. > > The NETCONF client MUST verify the integrity of the X.509 certificate > presented by the NETCONF server. To do this, the NETCONF client MUST: > > - Use the certificate path validation algorithm described in > Section 6 of [RFC 5280]. > > - Validate the X.509 certificate presented by the NETCONF server > to a trust anchor configured in the NETCONF client. > > To prevent man-in-the-middle attacks, after verifying the integrity of > X.509 certificate presented by the NETCONF server, the NETCONF > client MUST verify the identity of the NETCONF server. To verify the > identity of the NETCONF server: > > - The NETCONF client MUST have information about the expected identity > of the NETCONF server to which it connected, and from which it received > a presented X.509 certificate. This NETCONF server identity information > MUST be pre-configured in the NETCONF client before it initiates the > connection to the NETCONF server. > > - The X.509 certificate presented by the NETCONF server must contain > information about the NETCONF server's identity. > > - The NETCONF client MUST extract the NETCONF server identity information > from the X.509 certificate presented by the server. The NETCONF client > MUST compare the extracted server identity to the pre-configured server > identity information according to the rules and guidelines defined in > [RFC 6125]. If the comparison succeeds, then the NETCONF server > identity is verified, and the connection can proceed. If the comparison > fails, then the NETCONF server identity verification has failed. The > NETCONF client must handle the NETCONF server identity verification > failure as documented above. > From nobody Mon Nov 3 05:20:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1306E1A01A5; Mon, 3 Nov 2014 05:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 EF8cXOw4JU8d; Mon, 3 Nov 2014 05:20:06 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19C11A0199; Mon, 3 Nov 2014 05:20:05 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id f10so1265255yha.18 for ; Mon, 03 Nov 2014 05:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=3WK49IDoLiMI/pX1s8U8ySnv5xLeIPF5NzQX7Mg+5is=; b=NXNTknKY8qNLPb6uDaQ5Irlv1AcbuewBNiqIk++apu5lXx9oah4L0sg0wpEJ2aAw/W 1SlTbjUCJBqkmSG+zlWDxU0JtkGcyx34sFikIbILNotiV/J0g12OGvtqUj/n9hv+/uXn GNBtW+ZCfHb232N4uAwfO1gVcUPAmCfyUf48aQ2IsmpLevomT0vwmmXYOFoF1DZYsALX Q61ISWIm6AJFgUVloQpliysuXGznZMv5HpeDuYrKfdRyAn4Xx6E9Ch6ZOvrTo+yLjxNi YrDLzdct8IWlnNuxJBoQc+8Rg5Aw6Ny19rGNsxxmr3ztGxtn5M44KBWqOSnYyCt0Gwqm UnYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=3WK49IDoLiMI/pX1s8U8ySnv5xLeIPF5NzQX7Mg+5is=; b=epu3mdZQsFsGdq9AqqPPqApVtfnpBhm+VOXjCFnktpfa/PFyP3gT/ta5Xj5yorskOd uHI0iM2Uu0XfX5xS+8HilG8RlGMQSlEL/qKWIx3tJ/usr8zc/EKjnKmhDqG3pgJXaEqw Sj1UszZA7oqcrP8vwyp+qRgFFTzRo97D0Lql4= X-Received: by 10.170.56.197 with SMTP id 188mr1634939yky.117.1415020805287; Mon, 03 Nov 2014 05:20:05 -0800 (PST) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.221.193 with HTTP; Mon, 3 Nov 2014 05:19:45 -0800 (PST) From: Xiao SHI Date: Mon, 3 Nov 2014 08:19:45 -0500 X-Google-Sender-Auth: tdSLgCGExLO7aEnrkGxMv6L3HYo Message-ID: To: Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11398cb072f7080506f434cf Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/f8AZAZri-AZXkTwrJvoJdRpUJIY Cc: Richard Yang Subject: [Netconf] Specification on netconf modifications to xpath filtering X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 13:20:08 -0000 --001a11398cb072f7080506f434cf Content-Type: text/plain; charset=UTF-8 Hi folks, I was looking into the xpath filtering capabilities in netconf, especially the part in Section 8.9.5.1 ( https://tools.ietf.org/html/rfc6241#section-8.9.5.1) ===Question 1=== The RFC reads: All ancestor nodes of the result node MUST be encoded first, so the element returned in the reply contains only fully specified subtrees, according to the underlying data model. How does this interact with XPATH union? For example, if we had a data model: list top { leaf server-id; leaf user-count; list user { key name; leaf name; } } If I would like to select any user whose name is Fred and include the server they are on as well as the user-count on those servers, I would use XPATH query filter such as the following: Say the node set returned by the XPATH result is the following: myServer1 99 fred myServer3 123 fred According to the NETCONF modification, the ancestor nodes of each node in this node set will be encoded first, meaning the returned XML contains only fully specified subtrees. "For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message." (Sec 8.9.1) I see two options depending on how this modification process is evaluated in netconf: Option 1: each node/subtree in the node set is evaluated individually and produced the following output: myServer1 99 fred myServer3 123 fred Option 2: each node is put into context of the data model, and yields the following output: myServer1 99 fred myServer3 123 fred Which one would NETCONF server produce? ===Question 2=== The second paragraph reads: If any sibling or ancestor nodes of the result node are needed to identify a particular instance within a conceptual data structure, then these nodes MUST also be encoded in the response. I was wondering how a server would know whether a node is needed to "identify the instance within a conceptual data structure," i.e. is there a detailed specification for that (other than the key of a list)? Thank you! Xiao --001a11398cb072f7080506f434cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I was looking into the xpath = filtering capabilities in netconf, especially the part in Section 8.9.5.1 (= https://tools.ietf.org/html/rfc6241#section-8.9.5.1)
<= br>
=3D=3D=3DQuestion 1=3D=3D=3D
The RFC reads: All anc= estor nodes of the result node MUST be encoded first, so the <data> e= lement returned in the reply contains only fully specified subtrees, accord= ing to the underlying data model.

How does this in= teract with XPATH union?

For example, if we had a = data model:
list top {
=C2=A0 leaf server-id;
=C2=A0 leaf user-count;
=C2=A0 list user {
=C2=A0 =C2= =A0 key name;
=C2=A0 =C2=A0 leaf name;
=C2=A0 }
}

If I would like to select any user whose = name is Fred and include the server they are on as well as the user-count o= n those servers, I would use XPATH query filter such as the following:

<rpc message-id=3D"101"
= =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=C2=A0 =C2=A0 <get-config>
=C2=A0 =C2=A0= =C2=A0 =C2=A0 <source>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <running/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </source&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <filter xmlns:t=3D"http://example.com/schema/1.2/con= fig"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 type=3D"xpath"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 select=3D"/t:top/t:user[t:name=3D'fred= 9;]/../server-id | /t:top/t:users/t:user[t:name=3D'fred']/../user-c= ount | /t:top/t:users/t:user[t:name=3D'fred']"/>
= =C2=A0 =C2=A0 </get-config>
</rpc>
Say the node set returned by the XPATH result is the following= :
<server-id>myServer1</server-id>
<= ;user-count>99</user-count>
<user><name>fred= </name></user>
<server-id>myServer3</server-= id>
<user-count>123</user-count>
<use= r><name>fred</name></user>

<= div>According to the NETCONF modification, the ancestor nodes of each node = in this node set will be encoded first, meaning the returned XML contains o= nly fully specified subtrees. "For each such subtree, the path from th= e data model root node down to the subtree, including any elements or attri= butes necessary to uniquely identify the subtree, are included in the respo= nse message." (Sec 8.9.1)

I see two options d= epending on how this modification process is evaluated in netconf:
Option 1: each node/subtree in the node set is evaluated individually and= produced the following output:
<top><server-id>= myServer1</server-id></top>
<top><user-count= >99</user-count></top>
<top><user><= name>fred</name></user></top>
<top><= ;server-id>myServer3</server-id></top>
<top>= <user-count>123</user-count></top>
<top>&= lt;user><name>fred</name></user></top>

Option 2: each node is put into context of the data m= odel, and yields the following output:
<top>
=C2=A0 <server-id>myServer1</server-id>
=C2=A0 <u= ser-count>99</user-count>
=C2=A0 <user><name>= ;fred</name></user>
</top>
<top>= ;
=C2=A0 <server-id>myServer3</server-id>
= =C2=A0 <user-count>123</user-count>
=C2=A0 <user&g= t;<name>fred</name></user>
</top>

Which one would NETCONF server produce?
<= br>
=3D=3D=3DQuestion 2=3D=3D=3D
The second paragraph r= eads: If any sibling or ancestor nodes of the result node are needed to ide= ntify a particular instance within a conceptual data structure, then these = nodes MUST also be encoded in the response.

I was = wondering how a server would know whether a node is needed to "identif= y the instance within a conceptual data structure," i.e. is there a de= tailed specification for that (other than the key of a list)?
Thank you!
Xiao
--001a11398cb072f7080506f434cf-- From nobody Mon Nov 3 05:35:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C21A014C for ; Mon, 3 Nov 2014 05:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 yzeDqmNvSNEU for ; Mon, 3 Nov 2014 05:35:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 690911A0070 for ; Mon, 3 Nov 2014 05:35:27 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 47DBC1280098; Mon, 3 Nov 2014 14:35:26 +0100 (CET) Date: Mon, 03 Nov 2014 14:35:26 +0100 (CET) Message-Id: <20141103.143526.286924497828608419.mbj@tail-f.com> To: xiao.shi@yale.edu From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/i0GCxrDhw2DN-za_JuzV0yTdMf0 Cc: yry@cs.yale.edu, netconf@ietf.org Subject: Re: [Netconf] Specification on netconf modifications to xpath filtering X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 13:35:29 -0000 [removing netmod cc since this is a netconf question] Xiao SHI wrote: > Hi folks, > > I was looking into the xpath filtering capabilities in netconf, especially > the part in Section 8.9.5.1 ( > https://tools.ietf.org/html/rfc6241#section-8.9.5.1) > > ===Question 1=== > The RFC reads: All ancestor nodes of the result node MUST be encoded first, > so the element returned in the reply contains only fully specified > subtrees, according to the underlying data model. > > How does this interact with XPATH union? > > For example, if we had a data model: > list top { > leaf server-id; > leaf user-count; > list user { > key name; > leaf name; > } > } I think you mean that 'server-id' is key in list 'top': list top { key server-id; ... > If I would like to select any user whose name is Fred and include the > server they are on as well as the user-count on those servers, I would use > XPATH query filter such as the following: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > type="xpath" > select="/t:top/t:user[t:name='fred']/../server-id | > /t:top/t:users/t:user[t:name='fred']/../user-count | > /t:top/t:users/t:user[t:name='fred']"/> > > > > Say the node set returned by the XPATH result is the following: > myServer1 > 99 > fred > myServer3 > 123 > fred > > According to the NETCONF modification, the ancestor nodes of each node in > this node set will be encoded first, meaning the returned XML contains only > fully specified subtrees. "For each such subtree, the path from the data > model root node down to the subtree, including any elements or attributes > necessary to uniquely identify the subtree, are included in the response > message." (Sec 8.9.1) > > I see two options depending on how this modification process is evaluated > in netconf: > Option 1: each node/subtree in the node set is evaluated individually and > produced the following output: > myServer1 > 99 > fred > myServer3 > 123 > fred > > Option 2: each node is put into context of the data model, and yields the > following output: > > myServer1 > 99 > fred > > > myServer3 > 123 > fred > > > Which one would NETCONF server produce? Option 2. Note that w/o any filter you would get option 2 (+ lots more, potentially). With the filter you get a proper subset of the whole thing. > ===Question 2=== > The second paragraph reads: If any sibling or ancestor nodes of the result > node are needed to identify a particular instance within a conceptual data > structure, then these nodes MUST also be encoded in the response. > > I was wondering how a server would know whether a node is needed to > "identify the instance within a conceptual data structure," i.e. is there a > detailed specification for that (other than the key of a list)? If the data modelling language for the server is YANG, then this is the keys in lists. But it depends on the DML. /martin From nobody Mon Nov 3 11:04:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3AA1A6F84 for ; Mon, 3 Nov 2014 11:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.704 X-Spam-Level: * X-Spam-Status: No, score=1.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.594, 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 lSQ9T9LlTP9c for ; Mon, 3 Nov 2014 11:04:07 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA91A1B99 for ; Mon, 3 Nov 2014 11:04:07 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA15372; Mon, 3 Nov 2014 14:04:00 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sA3J41Kg040214; Mon, 3 Nov 2014 14:04:01 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id sA3J400U040213; Mon, 3 Nov 2014 14:04:00 -0500 (EST) (envelope-from luchuk) Date: Mon, 3 Nov 2014 14:04:00 -0500 (EST) From: Alan Luchuk Message-Id: <201411031904.sA3J400U040213@mainfs.snmp.com> To: , X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/f0q457S-c_jqOvLFVt2zjClIGpQ Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:04:09 -0000 Hello, Kent, Tom, thanks for the helpful feedback. kw>I'm not sure if adding more sections or more words is needed - maybe this kw>is a case where less is more? Maybe we *only* need to 1) state that kw>server authentication MUST be via PKIX as defined in RFCs 5280 and 6125 kw>and 2) state anything not already covered by RFCs 5280 and 6125. I agree that less can be more, and that it is unproductive to duplicate text when a reference to existing text might be satisfactory. That said, are you suggesting: 1) Keep the existing section 2.4.1 text; 2) Replace the existing section 2.4.1 text with something much briefer that simply references RFCs 5280 and 6125; or 3) Refine the proposed text to make it briefer? The intent for the proposed replacement text for section 2.4.1 was to clarify the existing text in section 2.4.1, to address: tpetch>I think that this still needs a tweak. tpetch> tpetch>In s.2.4.1, the sentence tpetch>"If tpetch> the NETCONF client has external information as to the expected tpetch> identity of the NETCONF server, the hostname check MAY be omitted. tpetch>" tpetch>has been moved, to be immediately after the comment about performing tpetch>certificate validation as per RFC5280. Which does not make good sense tpetch>since RFC5280 is not about hostname checks. The sentence used to come tpetch>after the references to RFC6125 which is about hostnames and so made tpetch>more sense. tpetch> tpetch>But more fundamentally, I am unclear what this is saying. 'hostname tpetch>check' does not appear anywhere else. There is talk of matching but I tpetch>am unclear if that is intended. As it stands, the sentence would seem tpetch>to say, get a certificate and then ignore its contents, in which case, I tpetch>think that an example, or list, of suitable conditions needs to be there tpetch>alongside the sentence, whereever the sentence is. tpetch> To tell the truth, I find the section still confusing. There are too tpetch> many MUST and MAYs interacting here. I also see that the second tpetch> paragraph says MUST ask for user confirmation or terminate the tpetch> connection. This also seems to conflict with the notion of I think the proposed section 2.4.1 should be revised if necessary and kept because it states clearly: - that NETCONF clients using TLS must verify the server's identity; - that alternate verification mechanisms are acceptable; and - What happens if the identity verificatioN CHeck fails. The proposed new section 2.4.2 resulted from what seemed like a logical split of the replacement text for the original section 2.4.1. It attempts to clarify statements in original section 2.4.1 such as: "by the server to determine if it meets the client's expectations. If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted." I can align with any NETCONF WG consensus about the proposed replacement sections being unhelpful, too verbose, or need revision or deletion. kw>Also, I noticed that you didn't touch the original section 2.4.2. (Client kw>Identity). This is the section that is currently missing a statements kw>along the lines of: kw> - the client MUST present a X.509 certificate kw> - the client MAY also present a chain of intermediate certs to a trust kw>anchor the server is expected to trust kw> - the server MUST authenticate the client's certificate kw> - the server MAY authenticate the client's certificate using PKIX to a kw>configured trust anchor kw> - the server MAY authenticate the client's certificate if it's an exact kw>match to a previously trusted client certificate. Yes. Partly this omission was to address rfc5539bis-06 one section at a time, and partly to leave the section as-is to address the comment: kw> One last point, I'm opposed to 5539bis using kw> draft-ietf-netconf-server-model as a Normative Reference. I believe kw> that 5539bis should define the protocol on its own, and view kw> draft-ietf-netconf-server-model as just one data-model that could kw> configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home kw> have a Normative Reference draft-ietf-netconf-server-model. The idea was to have rfc5539bis simply say that the NETCONF server derives a NETCONF username from the X.509 certificate presented by the client. Draft-ietf-netconf-server-model would define one possible mechanism for deriving the NETCONF username from the X.509 certificate. If it is the WG's consensus that the existing sections 2.4.2/2.4.3 from rfc5539bis-06 need work, I can massage the bullet points you suggested into replacement text. tpetch>I am unclear on what you are proposing tpetch> tpetch>For me, there is a clear split between the validation of X.509 tpetch>certificates and the use then made of the contents thereof, tpetch>something which I do not see in the paragraphs you propose. I hope this E-mail answers these and at least explains the reason for the omission. Is understanding the mechanism for deriving NETCONF usernames from X.509 certs the primary problem you see with rfc5539bis-06? Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Wed Nov 5 02:50:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8F1A885D for ; Wed, 5 Nov 2014 02:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_61=0.6, SPF_HELO_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 13jogQ7owLTP for ; Wed, 5 Nov 2014 02:50:30 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::725]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024481A885A for ; Wed, 5 Nov 2014 02:50:29 -0800 (PST) Received: from pc6 (86.184.62.161) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 5 Nov 2014 10:37:30 +0000 Message-ID: <01ed01cff8e4$2576ac40$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Luchuk , References: <201411031904.sA3J400U040213@mainfs.snmp.com> Date: Wed, 5 Nov 2014 10:34:46 +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.184.62.161] X-ClientProxiedBy: DB4PR05CA0034.eurprd05.prod.outlook.com (25.160.40.44) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-PRVS: 0386B406AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(51704005)(33646002)(61296003)(47776003)(20776003)(87976001)(81686999)(64706001)(21056001)(95666004)(554214002)(106356001)(105586002)(14496001)(107046002)(50986999)(99396003)(102836001)(120916001)(50466002)(15202345003)(97736003)(31966008)(89996001)(62966003)(77156002)(46102003)(44716002)(62236002)(76176999)(81816999)(101416001)(116806002)(77096003)(15975445006)(40100003)(92566001)(50226001)(42186005)(1941001)(4396001)(19580405001)(66066001)(23756003)(86362001)(87286001)(88136002)(104166001)(84392001)(92726001)(122386002)(93916002)(19580395003)(44736004)(7059028)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/a0E4SXHXZph90KqOS0GTfTmf76I Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:50:32 -0000 ----- Original Message ----- From: "Alan Luchuk" To: ; Cc: ; Sent: Monday, November 03, 2014 7:04 PM > Hello, > > tpetch>I am unclear on what you are proposing > tpetch> > tpetch>For me, there is a clear split between the validation of X.509 > tpetch>certificates and the use then made of the contents thereof, > tpetch>something which I do not see in the paragraphs you propose. > > I hope this E-mail answers these and at least explains the reason for > the omission. Is understanding the mechanism for deriving NETCONF > usernames from X.509 certs the primary problem you see with > rfc5539bis-06? No. I am reasonably comfortable with that having been through it before for SNMP and RFC5539. It is what comes earlier (or should do in my model). First, being clear that we are only covering X.509 certificates. I referred to this vaguely, Kent gave chapter and verse of text in 5539bis-06 which still hints at other things, so I need to see an I-D that makes (or doesn't) those changes (and yes, I have to wait at least for the window to open). This to me has been the biggest stumbling block. Second, I want to separate the certificate validation as a distinct step. It seems wrong, perhaps a breach of security, to talk of what to do with the contents before checking that the certificate is valid and here I refer to RFC5280, not to RFC6125. As I said, RFC5539 does a good job, I would just like that paragraph first, it seems the only sequence to make sense. If validation may consist of checking against pre-stored certificates, then I would count that as part of this step as RFC5539 does. Third comes the RFC6125 step (or variants thereon since that RFC is so HTTP focussed). We have a valid certificate but is it a relevant one, does it match, for some sense of that word, the party we are trying to set up a TLS channel with? Then, at last, we can get on with determining a user id to use with NETCONF. I am looking for that sort of structure and find it hard to discern. And yes, I agree, less is often more, when we can assume a certain familiarity with existing concepts and standards in the mind of the reader. Tom Petch > > Regards, > --Alan > > --------------------------------------------------------------------- --------- > Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 > Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 > luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ > --------------------------------------------------------------------- --------- > From nobody Wed Nov 5 08:08:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2F1A87E8 for ; Wed, 5 Nov 2014 00:22:07 -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 ZC2DJbuPQvNA for ; Wed, 5 Nov 2014 00:22:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA71A8820 for ; Wed, 5 Nov 2014 00:22:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141105082201.11485.47642.idtracker@ietfa.amsl.com> Date: Wed, 05 Nov 2014 00:22:01 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hzXqhLTnCj3dXRRLtYomZhP_TyM X-Mailman-Approved-At: Wed, 05 Nov 2014 08:08:39 -0800 Subject: [Netconf] Milestones changed for netconf WG X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 08:22:07 -0000 Changed milestone "Submit initial WG draft for RFC5539bis", set state to active from review, accepting new milestone. Changed milestone "Submit initial WG draft for server configuration data model", set state to active from review, accepting new milestone. Changed milestone "Submit initial WG draft for NETCONF call home mechanism", set state to active from review, accepting new milestone. Changed milestone "WGLC for NETCONF call home mechanism", set state to active from review, accepting new milestone. Changed milestone "Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit server configuration data model to AD/IESG for consideration as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/netconf/charter/ From nobody Wed Nov 5 18:57:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F31A0210 for ; Wed, 5 Nov 2014 18:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 KbtGGVo4rxrz for ; Wed, 5 Nov 2014 18:57:12 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13A01A014A for ; Wed, 5 Nov 2014 18:57:11 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml403-hub.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYZ30252; Wed, 05 Nov 2014 20:57:11 -0600 (CST) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Nov 2014 02:57:08 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 6 Nov 2014 10:56:58 +0800 From: "Liubing (Leo)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "Bert Wijnen (IETF)" , netconf Thread-Topic: RFC5539bis Issues to decide in IETF 91 Thread-Index: Ac/zd5aR4K2jd/eAQYepD66aNjzxlwF8tuFw Date: Thu, 6 Nov 2014 02:56:57 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589E494C@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45589E494Cnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dRYKePOxkemzvCQKPjDB257UZig Cc: Zhengguangying , Yangang Subject: Re: [Netconf] RFC5539bis Issues to decide in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 02:57:15 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45589E494Cnkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dear all, Please see replies inline. From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN - DE/Munich) Sent: Wednesday, October 29, 2014 8:55 PM To: netconf Subject: [Netconf] RFC5539bis Issues to decide in IETF 91 Dear NETCONF WG, unfortunately the authors of the rfc5539bis draft will not be in IETF 91 me= eting. Below are two issues Juergen and the co-chairs would like to clarify. As a preparation for the IETF 91 meeting please answer the questions below = by November 8, 2014 EOB PT. The co-chairs will lead to a conclusion and finalize the decision taking in= IETF 91 NETCONF session. Especially, please state for a) and b) separately, which options you prefer= and why. I.e. add your motivation/reasoning for your choices/answers. a) Should the document become "NC over TLS with mutual X.509 authentication" and hence a different auth scheme requires another "NC over TLS with FOOBAR authentication" document or should the document be NC over TLS and we find some other way to say "if you do X.509 mutual authentication, then you have to do what is defined here; other forms of authentication may be defined in future documents". [Bing] We don't have a strong feeling on this issue. Ideally, we think it's good to have a generic authentication mechanism defi= ned in this document, but maybe it's unrealistic, so it's ok to explicitly = limit the draft to X.509. b) Should RFC 5539bis detail the algorithm how to extract a username from a certificate and then the server config model refers to that algorithm (this allows someone to implement RFC 5539bis without having to have the server config model implemented) or shall we leave the way a username is extract to the server config model document. [Bing] We tend to include it in 5539bis. This make 5539bis itself complete.= And it's more clear to explain the algorithm in the 5539bis context. Regards, Mehmet and Bert --_000_8AE0F17B87264D4CAC7DE0AA6C406F45589E494Cnkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dear al= l,

 = ;

Please see= replies inline.

 = ;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Wednesday, October 29, 2014 8:55 PM
To: netconf
Subject: [Netconf] RFC5539bis Issues to decide in IETF 91=

 

Dear NETCON= F WG,

 

unfortunate= ly the authors of the rfc5539bis draft will not be in IETF 91 meeting.

Below are t= wo issues Juergen and the co-chairs would like to clarify.

 

As a prepar= ation for the IETF 91 meeting please answer the questions below by November= 8, 2014 EOB PT.

The co-chai= rs will lead to a conclusion and finalize the decision taking in IETF 91 NE= TCONF session.

 

Especially,= please state for a) and b) separately, which options you prefer and why.

I.e. add yo= ur motivation/reasoning for your choices/answers.

 

a) Should t= he document become "NC over TLS with mutual X.509

  = ; authentication" and hence a different auth scheme requires another

  = ; "NC over TLS with FOOBAR authentication" document or should the=

  = ; document be NC over TLS and we find some other way to say "if you

  = ; do X.509 mutual authentication, then you have to do what is defined

  = ; here; other forms of authentication may be defined in future

  = ; documents".

[Bing] We = don’t have a strong feeling on this issue.

Ideally, w= e think it’s good to have a generic authentication mechanism defined = in this document, but maybe it’s unrealistic, so it’s ok to exp= licitly limit the draft to X.509.

 = ;

 

b) Should R= FC 5539bis detail the algorithm how to extract a username

  = ; from a certificate and then the server config model refers to that=

  = ; algorithm (this allows someone to implement RFC 5539bis without

  = ; having to have the server config model implemented) or shall we

  = ; leave the way a username is extract to the server config model

  = ; document.

[Bing] We = tend to include it in 5539bis. This make 5539bis itself complete. And it= 217;s more clear to explain the algorithm in the 5539bis context.

 

Regards,

Mehmet and = Bert

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45589E494Cnkgeml506mbxchi_-- From nobody Thu Nov 6 02:41:52 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041CD1A1AD0 for ; Thu, 6 Nov 2014 02:41:50 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amQ3Sq5_DZ4u for ; Thu, 6 Nov 2014 02:41:48 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67F01A1AB0 for ; Thu, 6 Nov 2014 02:41:47 -0800 (PST) Received: from DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) by DBXPR07MB414.eurprd07.prod.outlook.com (10.141.14.144) with Microsoft SMTP Server (TLS) id 15.1.6.9; Thu, 6 Nov 2014 10:12:09 +0000 Received: from pc6 (86.184.62.161) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.11.14; Thu, 6 Nov 2014 10:12:08 +0000 Message-ID: <00be01cff9a9$c0bdfee0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf References: Date: Thu, 6 Nov 2014 10:09:20 +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.184.62.161] X-ClientProxiedBy: DB4PR02CA0014.eurprd02.prod.outlook.com (10.242.174.142) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Forefront-PRVS: 0387D64A71 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(13464003)(377454003)(15584002)(101416001)(14496001)(120916001)(81686999)(97736003)(44736004)(42186005)(106356001)(99396003)(21056001)(95666004)(4396001)(102836001)(105586002)(87286001)(86362001)(33646002)(61296003)(107886001)(107046002)(122386002)(87976001)(23756003)(89996001)(88136002)(19580395003)(15975445006)(19580405001)(46102003)(50466002)(20776003)(81816999)(76176999)(116806002)(50226001)(77156002)(62966003)(50986999)(84392001)(44716002)(93916002)(31966008)(104166001)(62236002)(64706001)(66066001)(47776003)(92726001)(77096003)(92566001)(40100003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB414; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/C3xr82lUZ5liaD50Dkt34b-5xAk Subject: Re: [Netconf] RFC5539bis Issues to decide in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 10:41:50 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" Sent: Wednesday, October 29, 2014 12:55 PM b) Should RFC 5539bis detail the algorithm how to extract a username from a certificate and then the server config model refers to that algorithm (this allows someone to implement RFC 5539bis without having to have the server config model implemented) or shall we leave the way a username is extract to the server config model document. Re-reading this as people reply to it, I think the logic is false. Putting the algorithm into netconf-server in no way requires people to implement the whole of netconf-server. It only requires them to go off and read netconf-server in order to write the code that presents an interface to the Internet that will interwork with other boxes. Our RFC often contain words to the effect that here is how to do it but there is no need whatsoever to do it this way as long as the implementation presents the same appearance to the outside world. That is, we define protocols, whether you can peer inside a box and see a perfect replica of a data structure that appears in an RFC is irrelevant (ever seen an RMON MIB Module?). So there is a point to resolve, whether 5539bis is complete in itself and so will get updated or contradicted by other I-D as time goes by, or we take the relational database approach and put information in just the one place and have others link to it. I have been a fan of relational databases for about 40 years now. Tom Petch Regards, Mehmet and Bert ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Nov 6 14:09:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D993C1A923C for ; Thu, 6 Nov 2014 14:09:20 -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 jRQsRKO0JjnT for ; Thu, 6 Nov 2014 14:09:13 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D2B1A9138 for ; Thu, 6 Nov 2014 14:09:12 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.11.14; Thu, 6 Nov 2014 22:09:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.166]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.166]) with mapi id 15.01.0011.000; Thu, 6 Nov 2014 22:09:10 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf Thread-Topic: [Netconf] Draft Agenda for the IETF 91 NETCONF Session Thread-Index: AQHP+WhhmLI7Flw7akaGOaSh2crkCQ== Date: Thu, 6 Nov 2014 22:09:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(66066001)(106356001)(40100003)(21056001)(2656002)(31966008)(107046002)(122556002)(77156002)(105586002)(36756003)(4396001)(95666004)(99286002)(64706001)(106116001)(20776003)(107886001)(62966003)(86362001)(120916001)(87936001)(92566001)(83506001)(54356999)(77096003)(99396003)(46102003)(97736003)(16236675004)(50986999)(92726001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D08015A987D1Ckwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/re00ySAgMbvZaYodE-DMDmN0d3w Subject: Re: [Netconf] Draft Agenda for the IETF 91 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:09:21 -0000 --_000_D08015A987D1Ckwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mehmet, After reviewing my slides, it seems that the following times for my drafts = are good (saving 10 minutes): 1. NETCONF Call Home - K. Watsen (15 min.) 3. NETCONF Server Configuration Model - K. Watsen (15 min.) 6. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Wat= sen (10 min.) Thanks, Kent --_000_D08015A987D1Ckwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mehmet,

After reviewing my slides, it seems that the following times for my dr= afts are good (saving 10 minutes):

      1. NETCONF Call Home - K. Watsen (15 min.)
 
      3. NETCONF Server Configuration Model - K. Watsen= (15 min.)
  
      6. Zero Touch Provisioning for NETCONF Call Home = (ZeroTouch) - K. Watsen (10 min.)


Thanks,
Kent
--_000_D08015A987D1Ckwatsenjunipernet_-- From nobody Fri Nov 7 05:32:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E7B1ACFD6 for ; Fri, 7 Nov 2014 05:32:33 -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 j_wxP19cfbQf for ; Fri, 7 Nov 2014 05:32:31 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::711]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF201ACF79 for ; Fri, 7 Nov 2014 05:32:30 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 7 Nov 2014 13:32:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.166]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.166]) with mapi id 15.01.0011.000; Fri, 7 Nov 2014 13:32:08 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf Thread-Topic: [Netconf] RFC5539bis Issues to decide in IETF 91 Thread-Index: AQHP+o864K2jd/eAQYepD66aNjzxlw== Date: Fri, 7 Nov 2014 13:32:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(15584002)(189002)(199003)(77156002)(77096003)(62966003)(40100003)(66066001)(122556002)(64706001)(99286002)(95666004)(107886001)(107046002)(105586002)(106116001)(106356001)(99396003)(19625215002)(86362001)(92566001)(92726001)(120916001)(46102003)(101416001)(2656002)(87936001)(97736003)(54356999)(16236675004)(4396001)(31966008)(19580405001)(20776003)(83506001)(19580395003)(50986999)(36756003)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0815CE388310kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mO89VQZ5A-wnQov8y7ZXF1F7rpA Subject: Re: [Netconf] RFC5539bis Issues to decide in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:32:33 -0000 --_000_D0815CE388310kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I said all this before, but am replying again now to ensure it's in this th= read as well. (a) yes, it reflects what 5539 was before, or at least I think it intended = to be, and it seems helpful to provide that clarity. Looking at it from a= nother angle, if we extend the scope to non-X.509 mechanisms, it would be h= ard support on the server-model draft, which I'm very much hoping to wrap u= p in the near term. (b) I'm a proponent for RFC5539bis being self-contained in describing what = is required. If it requires client-certificate based auth, then it should = say so (it doesn't currently). To the specific question regarding extracti= ng a username from a client cert, I think the question is, is it something = that is specific to 5539bis or a data-model? - stated another way, is ther= e an expectation that client-certificates work across NETCONF servers, rega= rdless which config model is used? I know that it's been mentioned that th= e reference to the server-model doesn't mean the server-model has to be imp= lemented, but to me there potential for confusion. Lastly, I don't foresee= this creating overlap as, if 5539bis had these requirements explained, the= server-model would remove that text, referencing the 5539bis section(s) in= stead. Putting this into perspective, I don't think we're talking about a = lot of text that would need to go into 5539bis, just enough to declare *wha= t* needs to be supported, and then let server-model describe *how* it is su= pported. Thanks, Kent From: , "Mehmet (NSN - DE/Munich)" > Date: Wednesday, October 29, 2014 at 7:55 AM To: NetConf > Subject: [Netconf] RFC5539bis Issues to decide in IETF 91 Dear NETCONF WG, unfortunately the authors of the rfc5539bis draft will not be in IETF 91 me= eting. Below are two issues Juergen and the co-chairs would like to clarify. As a preparation for the IETF 91 meeting please answer the questions below = by November 8, 2014 EOB PT. The co-chairs will lead to a conclusion and finalize the decision taking in= IETF 91 NETCONF session. Especially, please state for a) and b) separately, which options you prefer= and why. I.e. add your motivation/reasoning for your choices/answers. a) Should the document become "NC over TLS with mutual X.509 authentication" and hence a different auth scheme requires another "NC over TLS with FOOBAR authentication" document or should the document be NC over TLS and we find some other way to say "if you do X.509 mutual authentication, then you have to do what is defined here; other forms of authentication may be defined in future documents". b) Should RFC 5539bis detail the algorithm how to extract a username from a certificate and then the server config model refers to that algorithm (this allows someone to implement RFC 5539bis without having to have the server config model implemented) or shall we leave the way a username is extract to the server config model document. Regards, Mehmet and Bert --_000_D0815CE388310kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <12BABAF73B500547962625C643E35260@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

I said all this before, but am replying again now to ensure it's in th= is thread as well.

(a) yes, it reflects what 5539 was before, or at least I think it inte= nded to be, and it seems helpful to provide that clarity.   Looking at= it from another angle, if we extend the scope to non-X.509 mechanisms, it = would be hard support on the server-model draft, which I'm very much hoping to wrap up in the near term.

(b) I'm a proponent for RFC5539bis being self-contained in describing = what is required.  If it requires client-certificate based auth, then = it should say so (it doesn't currently).  To the specific question reg= arding extracting a username from a client cert, I think the question is, is it something that is specific to 5539bis= or a data-model?  - stated another way, is there an expectation that = client-certificates work across NETCONF servers, regardless which config mo= del is used?  I know that it's been mentioned that the reference to the server-model doesn't mean the server-model has t= o be implemented, but to me there potential for confusion.  Lastly, I = don't foresee this creating overlap as, if 5539bis had these requirements e= xplained, the server-model would remove that text, referencing the 5539bis section(s) instead.  Putting this = into perspective, I don't think we're talking about a lot of text that woul= d need to go into 5539bis, just enough to declare *what* needs to be suppor= ted, and then let server-model describe *how* it is supported.

Thanks,
Kent


From: <Ersue>, "Mehmet (= NSN - DE/Munich)" <mehmet.e= rsue@nsn.com>
Date: Wednesday, October 29, 2014 a= t 7:55 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] RFC5539bis Issue= s to decide in IETF 91

Dear NETCONF WG,
 
unfortunately the authors of the rfc5539bis dr= aft will not be in IETF 91 meeting.
Below are two issues Juergen and the co-chairs= would like to clarify.
 
As a preparation for the IETF 91 meeting pleas= e answer the questions below by November 8, 2014 EOB PT.
The co-chairs will lead to a conclusion and fi= nalize the decision taking in IETF 91 NETCONF session.
 
Especially, please state for a) and b) separat= ely, which options you prefer and why.
I.e. add your motivation/reasoning for your ch= oices/answers.
 
a) Should the document become "NC over TL= S with mutual X.509
   authentication" and hence a = different auth scheme requires another
   "NC over TLS with FOOBAR aut= hentication" document or should the
   document be NC over TLS and we fi= nd some other way to say "if you
   do X.509 mutual authentication, t= hen you have to do what is defined
   here; other forms of authenticati= on may be defined in future
   documents".
 
b) Should RFC 5539bis detail the algorithm how= to extract a username
   from a certificate and then the s= erver config model refers to that
   algorithm (this allows someone to= implement RFC 5539bis without
   having to have the server config = model implemented) or shall we
   leave the way a username is extra= ct to the server config model
   document.
 
Regards,
Mehmet and Bert
&nbs= p;
 --_000_D0815CE388310kwatsenjunipernet_-- From nobody Wed Nov 12 01:14:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61B1A1B1C for ; Wed, 12 Nov 2014 01:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594, 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 YL2X8-FIii-q for ; Wed, 12 Nov 2014 01:14:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF31A883E for ; Wed, 12 Nov 2014 01:13:59 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A69731280A11 for ; Wed, 12 Nov 2014 10:13:55 +0100 (CET) Date: Wed, 12 Nov 2014 10:13:55 +0100 (CET) Message-Id: <20141112.101355.423478429.mbj@tail-f.com> To: netconf@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: http://mailarchive.ietf.org/arch/msg/netconf/nxSYx7B3_F1IaPMz7AbaPUqxZ00 Subject: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 09:14:40 -0000 Hi, At the meeting yesterday the issue of RESTCONF's usage of groupings to define data structures came up. I'd like to point out that it is perfectly legal to define groupings that are not being used. What is unorthodox is that RESTCONF ties the contents of these groupings to a YANG module name / namespace not by 'uses' but in english text in the document (this text needs to be clarified if we keep this construct). This isn't worse than defining the complete structure in plain text. The problem we're trying to solve is to have a single, formal, definition of these structures, than can be encoded in XML or JSON. If we were to use XSD it wouldn't work for JSON, and if we were to use JSON schema (or whatever) it wouldn't work for XML. One alternative to this is to define an extension statement: extension structure { argument name; description "Introduces a named data structure without any semantics attached. The data nodes in the structure are defined in the namespace of the module defining the structure." } Then we would replace the groupings with: rc:structure errors { container errors { ... } } rc:structure collection { container collection { .... } } and so on. Or even better, add such a statement to YANG 1.1. (incidentally, we have such an extension in our implementation that we use for this and similar purposes...) /martin From nobody Wed Nov 12 01:25:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A61A212D for ; Wed, 12 Nov 2014 01:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] 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 R1TXK59SwgeP for ; Wed, 12 Nov 2014 01:25: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 5043F1A873B for ; Wed, 12 Nov 2014 01:25: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 64530100E; Wed, 12 Nov 2014 10:25:47 +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 RiNdb9OCGJOq; Wed, 12 Nov 2014 10:25: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; Wed, 12 Nov 2014 10:25:46 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F08F20013; Wed, 12 Nov 2014 10:25:46 +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 sX_0tGbePX1v; Wed, 12 Nov 2014 10:25:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 711F82002C; Wed, 12 Nov 2014 10:25:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 936FA2F7CCFF; Wed, 12 Nov 2014 10:25:44 +0100 (CET) Date: Wed, 12 Nov 2014 10:25:43 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20141112092543.GA54331@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20141112.101355.423478429.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112.101355.423478429.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jzjuzPf3ClMWUlhUqQx6W2-QkQA Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 09:25:56 -0000 Martin, is what you propose generally useful or are you just trying to solve a corner problem with the definition of RESTCONF? If the later, the price of adding a new construct may be high, no? Is the idea here to provide a mechanism to define arbitrary XML/JSON protocol messages in YANG? And why would this go into YANG 1.1? If this mechanism is needed at all, would it not be possible to define it separately as a proper YANG extension? (And you know that the YANG 1.1 issue collection ended months ago and this does not seem to qualify as a bug fix.) /js On Wed, Nov 12, 2014 at 10:13:55AM +0100, Martin Bjorklund wrote: > Hi, > > At the meeting yesterday the issue of RESTCONF's usage of groupings to > define data structures came up. > > I'd like to point out that it is perfectly legal to define groupings > that are not being used. > > What is unorthodox is that RESTCONF ties the contents of these > groupings to a YANG module name / namespace not by 'uses' but in > english text in the document (this text needs to be clarified if we > keep this construct). This isn't worse than defining the complete > structure in plain text. > > The problem we're trying to solve is to have a single, formal, > definition of these structures, than can be encoded in XML or JSON. > If we were to use XSD it wouldn't work for JSON, and if we were to use > JSON schema (or whatever) it wouldn't work for XML. > > One alternative to this is to define an extension statement: > > extension structure { > argument name; > description > "Introduces a named data structure without any semantics > attached. The data nodes in the structure are defined in the > namespace of the module defining the structure." > } > > Then we would replace the groupings with: > > rc:structure errors { > container errors { > ... > } > } > > rc:structure collection { > container collection { > .... > } > } > > and so on. > > Or even better, add such a statement to YANG 1.1. > > (incidentally, we have such an extension in our implementation that we > use for this and similar purposes...) > -- 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 Nov 12 04:19:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C171A896A for ; Wed, 12 Nov 2014 04:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 RE-5Yy3Cwa_8 for ; Wed, 12 Nov 2014 04:19:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C683A1A895D for ; Wed, 12 Nov 2014 04:19:23 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A8D6E1280471; Wed, 12 Nov 2014 13:19:18 +0100 (CET) Date: Wed, 12 Nov 2014 13:19:17 +0100 (CET) Message-Id: <20141112.131917.433419253.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20140723.190110.325781546.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: http://mailarchive.ietf.org/arch/msg/netconf/XCa6jJBZlpoy4nOdHrEAI_hwrAU Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-zerotouch-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 12:19:27 -0000 Hi, Kent Watsen wrote: > > A late response, but I've been focused on call-home and server-model...and > there were very few comments on zero-touch. Anyway, here goes! -01 takes care of most of my issues, thanks! See below for some remaining questions. > >o sec 4.2 > > > > The picture says "IDevID entity". What is this entity? > > The line is intended to be expanded to read "IDevID entity *certificate* > and associated intermediate certificates". I'm trying to economize space > so it'll fit within the 72-column limit. > > Or is your question more generally what is an IDevID, as defined in the > subsequent paragraph? No, the question was really what you mean with "IDevID entity". Maybe it would be better to replace "IDevID entity & associated intermediate certificate(s)" with simply "IDevID". The text below expands on what the IDevID contains. > >o sec 4.2 > > > > Devices supporting ZeroTouch MUST be pre-provisioned with one or more > > URIs for Internet-based Configuration Servers. > > > > Why is this a MUST? (or why "one or more"?). It seems to me that > > the DHCP option could be used instead of manual pre-provisioning. > > > > Do you expect these config server URIs to be part of the normal > > config? See more below. > > The DHCP option is only effective for the "locally administered network" > use case (see section 1.3). When the network is administered remotely, > the DHCP option is very unlikely to be set and therefore the device will > have no resource but to fallback to trying URIs. Makes sense? So a vendor can never build a device that is supposed to be used only in the "locally administered network", i.e., rely on DHCP? This MUST can never really be verified - one way for a device to comply with this MUST is to put a dummy URI there that doesn't resolve to anything useful. So why do we have this as a MUST? > >o sec 4.2 > > > > confidentially and not available outside the DevID module > > > > What is "DevID module"? > > This sentence is based on Section 6.2.5 (Storage) of the 802.1AR spec, > which that sentence references just before the section you clipped out. > It refers to the cryptographic boundary defined by the specification. > > Two options: > 1. Call out more specifically section 6.2.5 > 2. Replace the term "IDevID module" with simple text meaning the same thing In general I like documents that have clear terminology, and specifically a list of the terms they import, and the new terms they define. It minimizes the risk of confusion. In this particular case, the term "DevID Module" is defined in 802.1AR (note, not IDevID Module which -01 uses). As an alternative to a terminology section, maybe you can just write "outside the DevID module (as defined in [...])" > >o sec 5.1 > > > > You have the list of expected device identifiers in immutable > > storage - that seems to indicate that it not possible to ever add a > > new device! > > I think you mean section 5.2. Nonetheless, to your point, the diagram is > trying to express storage attributes from the perspective of an entity > outside the module (the NMS in this case). An outsider cannot write the > immutable storage and cannot read or write secure storage. Anyway, > that's what I meant by this diagram and also the one in section 4.2. Is > it OK? Hmm, maybe it is just me, but if I see the term "immutable" I think it means that the info cannot be changed at all. What you are really saying is that the list of trusted certs and uids should be protected. BTW, s/// in the figure, and s/This certificates/These certificates/ in the text. Also, you have: In order to authenticate the device, the NMS MUST possess the X.509 certificate for the trust anchor leading to the device's entity certificate. what is the "device's entity certificate"? (I couldn't find this term in the IEEE spec; I assume you mean the IDevID cert). > >o sec 7.2 > > > > The term "unique-identifier" is pretty generic. Should it simply be > > "device-identifier" instead? > > True, but "unique-identifier" or "UID" is used throughout the draft, and > both the text and the YANG module state exactly what it needs to be. The doc currently has "unique identifier", "unique device identifier" and "device unique identifier". I think the unqualified "unique identifier" should be avoided, and that the XML element in the Configlet should use be named "unique-device-identifier". BTW, remove section 7.2 - the YANG model is gone. > >o sec 7.5, leaf software-version > > > > "The device MUST must be running this version of software. > > The value for this field is device-specific, but it MUST > > be an exact match (e.g., 14.1R2.5)"; > > > > Why is this MUST be exact match? It seems inflexible to me. Since > > the field is vendor specific anyway, why not let the match > > algorithm be vendor specific as well? > > > > Also, should this really be mandatory? > > This is a tough question. > > On one hand, we have cases where the Configlet is using vendor-specific > data-models (not ietf-system and ietf-netconf-server), and hence is > specific to a software release...or at least generated using a specific > revision of the vendor-specific module. It *might* work with other > versions, we only know for sure that it will work on the specific version. > If the NETCONF server is namespace-aware, it likely results in it only > supporting exact matches. Of course, SDO-defined modules are used, there > is a greater likelihood that more than one version can support it. > > Then there is the case of expectations, the NMS very likely requires the > device to be running a very specific software version, as it is what has > been qualified for production. Maybe, or a set of versions. > If the device doesn't so up with an exact > match, the NMS will have to first push the correct image to the device. > Yes, it could be done, but why should NMSs have to do this if the network > infrastructure can do it for them? > > Thoughts? The question is if it is necessary for this spec to say MUST be exact match. I think we should leave this to vendors to define. > >o sec 8.2 > > > > Remove the text about how a timestamp *could* be used? > > > But this is the Security Considerations section and clock-based attacks > are not uncommon. What is your suggestion? The text is: However, it is possible to substitute a Configlet created for a device with a different Configlet created for the same device. Generally, unless imposed by the Configuration Signers, there is no limit to the number of Configlets that may be generated for a given device. This could be resolved, in part, by placing a timestamp into the Configlet and ensuring devices do not load Configlets older than some amount, but this requires the devices have an accurate clock when validating a Configlet and for Configuration Signers to not sign a Configlet when another Configlet is still active. So are you saying that any vendor can reolve this by placing a timestamp in the Configlet? I don't think so. I think you mean that this could have been resolved by placing a timestamp..., but since this would require devices to have accurate clocks, this solution was rejected. > >o signing / encrypting configlets > > > > I think you need to specify somewhere how the signature is inserted > > into the configlet XML document. Currently the only hint the reader > > get is from an example... > > > > Same for encryption, and in this case the example is also tbd. > > > Did you see sections 7.3 (Signature) and 7.4 (Encryption)? > > Are you looking for something like a tutorial that starts with an unsigned > Configlet and then signs it with a key and then shows the resulting signed > Configlet? No, I think this just shows how little I know about XML Signatures... Particularly, can the element be placed anywhere in the XML document? Are all Transforms supported? Are all DigestMethods supported? Etc. If the answer is that this obvious from the XML Signature spec, then that is fine. /martin From nobody Wed Nov 12 09:11:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C51A8F3D for ; Wed, 12 Nov 2014 09:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 4D1wV5U0s-ZY for ; Wed, 12 Nov 2014 09:11:28 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782161A8F4B for ; Wed, 12 Nov 2014 09:08:56 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id r5so9511039qcx.19 for ; Wed, 12 Nov 2014 09:08:55 -0800 (PST) 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=fjmBmuZQF1owba8SdLOEkJHIzrZnF+CQDQB1T45Ir/8=; b=Adyn4UYQAUgjo9VOSg0n7xkJK1rk711O6p0JEi6e6kMAVU5rTZ8KRaSYJb0pLKGjC2 wxfRPh7bTLJLKRyCJKyBiN3SpqFr3GTUgg0dmotZU4vHkuu80amfk29m7EaMz1IebVK6 qzYVCvcMQ+XUcy396W/JIZrOJ2KTDllexb4rMML30VVr8UDGPTsgGweTuJ0/nFSHbgTc Dr5Rwyfi4FtUJ/t11ZhPlNy4gxFM8P6UgYvc7BLolHsC7s3JT6m9+2a4b8YPUuwdWodY IJpX29cXZM7T4254VAyC9FuIQsyy7vG37GGppais1VkpPULMsM/rYnzBFW4GFaJgK0fi xe2A== X-Gm-Message-State: ALoCoQnk5+uWIkuILY6krhOxEUoF6BBug1H65O2DSaAlwPjtCPRtoUD+e6R0B/u/8HLT2FpqH52a MIME-Version: 1.0 X-Received: by 10.229.105.196 with SMTP id u4mr62474789qco.27.1415812135421; Wed, 12 Nov 2014 09:08:55 -0800 (PST) Received: by 10.140.37.52 with HTTP; Wed, 12 Nov 2014 09:08:55 -0800 (PST) In-Reply-To: <20141112.101355.423478429.mbj@tail-f.com> References: <20141112.101355.423478429.mbj@tail-f.com> Date: Wed, 12 Nov 2014 09:08:55 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NgPKMJAc1hSbyR37D2xeNZB_c0o Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:11:31 -0000 On Wed, Nov 12, 2014 at 1:13 AM, Martin Bjorklund wrote: > Hi, > > At the meeting yesterday the issue of RESTCONF's usage of groupings to > define data structures came up. > > I'd like to point out that it is perfectly legal to define groupings > that are not being used. > > What is unorthodox is that RESTCONF ties the contents of these > groupings to a YANG module name / namespace not by 'uses' but in > english text in the document (this text needs to be clarified if we > keep this construct). This isn't worse than defining the complete > structure in plain text. +1 I would like to keep using groupings for this purpose. What if I want to use these definitions in my data models? I cannot do that unless the definitions are in groupings. For example, let's say my app has a structured log file format and I want to log the in the response? It is perfectly reasonable to use the grouping instead of cut and pasting. For this purpose, a YANG extension is worthless. Only a grouping provides the reusable definitions without hacking or copying. Andy > > The problem we're trying to solve is to have a single, formal, > definition of these structures, than can be encoded in XML or JSON. > If we were to use XSD it wouldn't work for JSON, and if we were to use > JSON schema (or whatever) it wouldn't work for XML. > > One alternative to this is to define an extension statement: > > extension structure { > argument name; > description > "Introduces a named data structure without any semantics > attached. The data nodes in the structure are defined in the > namespace of the module defining the structure." > } > > Then we would replace the groupings with: > > rc:structure errors { > container errors { > ... > } > } > > rc:structure collection { > container collection { > .... > } > } > > and so on. > > Or even better, add such a statement to YANG 1.1. > > (incidentally, we have such an extension in our implementation that we > use for this and similar purposes...) > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Nov 12 09:43:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B31A010F for ; Wed, 12 Nov 2014 09:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594, 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 ULMU0Gp_Gb4t for ; Wed, 12 Nov 2014 09:43:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 355611A0394 for ; Wed, 12 Nov 2014 09:43:34 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D7FEC1280B72; Wed, 12 Nov 2014 18:43:33 +0100 (CET) Date: Wed, 12 Nov 2014 18:43:33 +0100 (CET) Message-Id: <20141112.184333.431022222.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141112092543.GA54331@elstar.local> References: <20141112.101355.423478429.mbj@tail-f.com> <20141112092543.GA54331@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: http://mailarchive.ietf.org/arch/msg/netconf/7D465tM5ZVvcsf3pG4ih4MX2TpU Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:43:37 -0000 Juergen Schoenwaelder wrote: > Martin, > > is what you propose generally useful or are you just trying to solve a > corner problem with the definition of RESTCONF? If the later, the > price of adding a new construct may be high, no? Is the idea here to > provide a mechanism to define arbitrary XML/JSON protocol messages in > YANG? I think this could be useful in other cases than RESTCONF. The goal is not to provide a mechanism to define arbitrary XML/JSON messages, but of course this might happen if people see that it can be used in this way. > And why would this go into YANG 1.1? If this mechanism is needed at > all, would it not be possible to define it separately as a proper YANG > extension? It is unclear if such an extension can be said to define a new type of data definition statement and as such make it possible to use normal augment - e.g., would this be ok with the error structure: augment /rc:errors { ... } > (And you know that the YANG 1.1 issue collection ended > months ago and this does not seem to qualify as a bug fix.) Sure... /martin > > /js > > On Wed, Nov 12, 2014 at 10:13:55AM +0100, Martin Bjorklund wrote: > > Hi, > > > > At the meeting yesterday the issue of RESTCONF's usage of groupings to > > define data structures came up. > > > > I'd like to point out that it is perfectly legal to define groupings > > that are not being used. > > > > What is unorthodox is that RESTCONF ties the contents of these > > groupings to a YANG module name / namespace not by 'uses' but in > > english text in the document (this text needs to be clarified if we > > keep this construct). This isn't worse than defining the complete > > structure in plain text. > > > > The problem we're trying to solve is to have a single, formal, > > definition of these structures, than can be encoded in XML or JSON. > > If we were to use XSD it wouldn't work for JSON, and if we were to use > > JSON schema (or whatever) it wouldn't work for XML. > > > > One alternative to this is to define an extension statement: > > > > extension structure { > > argument name; > > description > > "Introduces a named data structure without any semantics > > attached. The data nodes in the structure are defined in the > > namespace of the module defining the structure." > > } > > > > Then we would replace the groupings with: > > > > rc:structure errors { > > container errors { > > ... > > } > > } > > > > rc:structure collection { > > container collection { > > .... > > } > > } > > > > and so on. > > > > Or even better, add such a statement to YANG 1.1. > > > > (incidentally, we have such an extension in our implementation that we > > use for this and similar purposes...) > > > > -- > 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 Nov 12 09:44:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5711A0102 for ; Wed, 12 Nov 2014 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594, 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 1s32cX_zAnh1 for ; Wed, 12 Nov 2014 09:44:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 92FCE1A002C for ; Wed, 12 Nov 2014 09:44:28 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D547C1280B72; Wed, 12 Nov 2014 18:44:27 +0100 (CET) Date: Wed, 12 Nov 2014 18:44:27 +0100 (CET) Message-Id: <20141112.184427.21336884.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20141112.101355.423478429.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: http://mailarchive.ietf.org/arch/msg/netconf/CM52n0-gKa_3ZA93ZtZkkTC7Vjg Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:44:30 -0000 Andy Bierman wrote: > On Wed, Nov 12, 2014 at 1:13 AM, Martin Bjorklund wrote: > > Hi, > > > > At the meeting yesterday the issue of RESTCONF's usage of groupings to > > define data structures came up. > > > > I'd like to point out that it is perfectly legal to define groupings > > that are not being used. > > > > What is unorthodox is that RESTCONF ties the contents of these > > groupings to a YANG module name / namespace not by 'uses' but in > > english text in the document (this text needs to be clarified if we > > keep this construct). This isn't worse than defining the complete > > structure in plain text. > > +1 > > I would like to keep using groupings for this purpose. > What if I want to use these definitions in my data models? > I cannot do that unless the definitions are in groupings. > > For example, let's say my app has a structured log file format > and I want to log the in the response? > It is perfectly reasonable to use the grouping instead of > cut and pasting. > > For this purpose, a YANG extension is worthless. > Only a grouping provides the reusable definitions without > hacking or copying. Well, you can certainly have both: grouping errors { ... } rc:structure error { uses errors; } /martin > > > Andy > > > > > The problem we're trying to solve is to have a single, formal, > > definition of these structures, than can be encoded in XML or JSON. > > If we were to use XSD it wouldn't work for JSON, and if we were to use > > JSON schema (or whatever) it wouldn't work for XML. > > > > One alternative to this is to define an extension statement: > > > > extension structure { > > argument name; > > description > > "Introduces a named data structure without any semantics > > attached. The data nodes in the structure are defined in the > > namespace of the module defining the structure." > > } > > > > Then we would replace the groupings with: > > > > rc:structure errors { > > container errors { > > ... > > } > > } > > > > rc:structure collection { > > container collection { > > .... > > } > > } > > > > and so on. > > > > Or even better, add such a statement to YANG 1.1. > > > > (incidentally, we have such an extension in our implementation that we > > use for this and similar purposes...) > > > > > > > > /martin > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Nov 12 09:47:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004091A0078 for ; Wed, 12 Nov 2014 09:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 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_29=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594] 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 Ll9XtKLzTzM4 for ; Wed, 12 Nov 2014 09:47:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C32A1A005C for ; Wed, 12 Nov 2014 09:47:12 -0800 (PST) Received: from t2001067c037001443dfe647d2c8d96bc.hotel-wired.v6.meeting.ietf.org (t2001067c037001443dfe647d2c8d96bc.hotel-wired.v6.meeting.ietf.org [IPv6:2001:67c:370:144:3dfe:647d:2c8d:96bc]) by mail.nic.cz (Postfix) with ESMTPSA id 806821400C9; Wed, 12 Nov 2014 18:47:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1415814430; bh=Ox5/hCk5yJD46yO6C3S0U1YjFV7ewfA7DVA6E1pFNiQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=M29nQQCr9bIJv41L+HBuFFIWpx4A2Ls4yuiVdoNgkgKjbW3TtiM0oGlhoeuYsUsv8 utr4OIbsCyGHsBUBzueNgZmDDXyvbAuJU5Kq++m8wq5yJCeJ4iAJU70bMbhcjRubnM ir/8qj9F4oO44xhcZfwUmqltARHmzdP1qPcqi/Co= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141112.101355.423478429.mbj@tail-f.com> Date: Wed, 12 Nov 2014 07:47:05 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <468243F2-87B2-4E0F-A6AE-E61AD4592578@nic.cz> References: <20141112.101355.423478429.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/symxokfcjj0VlaZ65stn-MDUJwE Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:47:14 -0000 On 11 Nov 2014, at 23:13, Martin Bjorklund wrote: > Hi, >=20 > At the meeting yesterday the issue of RESTCONF's usage of groupings to > define data structures came up. >=20 > I'd like to point out that it is perfectly legal to define groupings > that are not being used. This was not the point of my initial comment. >=20 > What is unorthodox is that RESTCONF ties the contents of these > groupings to a YANG module name / namespace not by 'uses' but in > english text in the document (this text needs to be clarified if we > keep this construct). This isn't worse than defining the complete > structure in plain text. I think we should think twice before doing that. The handling of = namespaces in groupings is tricky - people get often confused about the = fact that the namespace is assigned according to the module where the = grouping is used, not where it is defined. So breaking this rule and = saying that in this particular case the namespace is that of the module = where the grouping is defined is IMO very dubious.=20 >=20 > The problem we're trying to solve is to have a single, formal, > definition of these structures, than can be encoded in XML or JSON. > If we were to use XSD it wouldn't work for JSON, and if we were to use > JSON schema (or whatever) it wouldn't work for XML. I understand that. My proposal was to use augments instead with an = artificial target representing the HTTP response. Lada >=20 > One alternative to this is to define an extension statement: >=20 > extension structure { > argument name; > description > "Introduces a named data structure without any semantics > attached. The data nodes in the structure are defined in the > namespace of the module defining the structure." > } >=20 > Then we would replace the groupings with: >=20 > rc:structure errors { > container errors { > ... > } > } >=20 > rc:structure collection { > container collection { > .... > } > } >=20 > and so on. >=20 > Or even better, add such a statement to YANG 1.1. >=20 > (incidentally, we have such an extension in our implementation that we > use for this and similar purposes...) >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Nov 12 10:11:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725241A9146 for ; Wed, 12 Nov 2014 10:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 6uOdYqNKQr97 for ; Wed, 12 Nov 2014 10:10:48 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5F1A003B for ; Wed, 12 Nov 2014 10:10:46 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A568A1280471; Wed, 12 Nov 2014 19:10:45 +0100 (CET) Date: Wed, 12 Nov 2014 19:10:45 +0100 (CET) Message-Id: <20141112.191045.165848815.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <468243F2-87B2-4E0F-A6AE-E61AD4592578@nic.cz> References: <20141112.101355.423478429.mbj@tail-f.com> <468243F2-87B2-4E0F-A6AE-E61AD4592578@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: http://mailarchive.ietf.org/arch/msg/netconf/VahrnwZMSMUJgM_1ggdKAiKRCi4 Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 18:11:00 -0000 Ladislav Lhotka wrote: > > On 11 Nov 2014, at 23:13, Martin Bjorklund wrote: > > > Hi, > > > > At the meeting yesterday the issue of RESTCONF's usage of groupings to > > define data structures came up. > > > > I'd like to point out that it is perfectly legal to define groupings > > that are not being used. > > This was not the point of my initial comment. > > > > > What is unorthodox is that RESTCONF ties the contents of these > > groupings to a YANG module name / namespace not by 'uses' but in > > english text in the document (this text needs to be clarified if we > > keep this construct). This isn't worse than defining the complete > > structure in plain text. > > I think we should think twice before doing that. The handling of namespaces in > groupings is tricky - people get often confused about the fact that the > namespace is assigned according to the module where the grouping is used, not > where it is defined. So breaking this rule and saying that in this particular > case the namespace is that of the module where the grouping is defined is IMO > very dubious. The idea is not to break the rule. The idea is to express in text that we have the equivalent of "uses errors", i.e. the instantiation of the grouping that binds to the namespace. I agree that this is special and that is why I prefer to use an extension statement. > > The problem we're trying to solve is to have a single, formal, > > definition of these structures, than can be encoded in XML or JSON. > > If we were to use XSD it wouldn't work for JSON, and if we were to use > > JSON schema (or whatever) it wouldn't work for XML. > > I understand that. My proposal was to use augments instead with an artificial > target representing the HTTP response. IMO an artificial target is worse. Either you augment something that doesn't exist, or you have to define data nodes that aren't really data nodes. /martin From nobody Wed Nov 12 11:58:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5955F1A86EF for ; Wed, 12 Nov 2014 11:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 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.594] 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 Je8anUPbKwIj for ; Wed, 12 Nov 2014 11:57:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62AA1A797C for ; Wed, 12 Nov 2014 11:57:57 -0800 (PST) Received: from t2001067c03700160ecd2fdfc4a90b25a.wireless.v6.meeting.ietf.org (t2001067c03700160ecd2fdfc4a90b25a.wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:160:ecd2:fdfc:4a90:b25a]) by mail.nic.cz (Postfix) with ESMTPSA id 431D214006C; Wed, 12 Nov 2014 20:57:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1415822276; bh=71SHx5rCr/ZM0lyeuscZB2ucxXMyLYpu160hDPt8Gpg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rRIeV+eABd7uxQi84ZYpC48nWXk3fVLwRNRFvTbUnhOoWp5NKe0NAHjfAPd+ytpRz QnCLN4GSIjWS/LENs/iPDdyVD/V6FQZONMtk6tEaqIjY+kpPjzaIufjSQABGXuLfqB uT5CS/WVqcs7POvZrH2gPOqpxT+R1rDCpDhKGHL4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141112.191045.165848815.mbj@tail-f.com> Date: Wed, 12 Nov 2014 09:57:51 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3AEAF3D4-ADF8-41F0-BDE4-CE561BB0D95A@nic.cz> References: <20141112.101355.423478429.mbj@tail-f.com> <468243F2-87B2-4E0F-A6AE-E61AD4592578@nic.cz> <20141112.191045.165848815.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0W3SlC45V6jpkswYyro8dik-7ig Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:58:01 -0000 On 12 Nov 2014, at 08:10, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 11 Nov 2014, at 23:13, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> At the meeting yesterday the issue of RESTCONF's usage of groupings = to >>> define data structures came up. >>>=20 >>> I'd like to point out that it is perfectly legal to define groupings >>> that are not being used. >>=20 >> This was not the point of my initial comment. >>=20 >>>=20 >>> What is unorthodox is that RESTCONF ties the contents of these >>> groupings to a YANG module name / namespace not by 'uses' but in >>> english text in the document (this text needs to be clarified if we >>> keep this construct). This isn't worse than defining the complete >>> structure in plain text. >>=20 >> I think we should think twice before doing that. The handling of = namespaces in >> groupings is tricky - people get often confused about the fact that = the >> namespace is assigned according to the module where the grouping is = used, not >> where it is defined. So breaking this rule and saying that in this = particular >> case the namespace is that of the module where the grouping is = defined is IMO >> very dubious. >=20 > The idea is not to break the rule. The idea is to express in text For instance, an example in the text shows that the =93collection=94 = element is in the namespace of the ietf-restconf module but nothing in = that module provides any reason for this. Phil was right when he said that if this was done in another WG, we = would think they don=92t understand how namespaces work in groupings. > that we have the equivalent of "uses errors", i.e. the instantiation > of the grouping that binds to the namespace. I agree that this is > special and that is why I prefer to use an extension statement. OK. >=20 >>> The problem we're trying to solve is to have a single, formal, >>> definition of these structures, than can be encoded in XML or JSON. >>> If we were to use XSD it wouldn't work for JSON, and if we were to = use >>> JSON schema (or whatever) it wouldn't work for XML. >>=20 >> I understand that. My proposal was to use augments instead with an = artificial >> target representing the HTTP response. >=20 > IMO an artificial target is worse. Either you augment something that > doesn't exist, or you have to define data nodes that aren't really > data nodes. Well, it is clear in any case that YANG is somewhat misused here as a = general schema language. I am all for making this use of YANG more = =93official=94 in YANG 1.1. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Nov 12 13:54:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5D61ACDEE for ; Wed, 12 Nov 2014 13:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 Tng70dCLonhL for ; Wed, 12 Nov 2014 13:54:28 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276481ACD9B for ; Wed, 12 Nov 2014 13:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5631; q=dns/txt; s=iport; t=1415829268; x=1417038868; h=message-id:date:from:mime-version:to:cc:subject; bh=0iNQo11pY+aeTU8NZD0yiFKy+LNcUMTLlPMc7oTs1Ns=; b=K5lueVjGoohpmK8no+zlHRmgSKpLpvfH3mcYvTz0tJF9CyCc5SBs4wcQ VzhEYjko6Shq1EQlE7STyAT7DZE1JTa6/Vo+5a3vae694XmYcrqchSmT3 F7kD6O25Gz4Kxf4eSdqrl2FFSDibnaKlbB/NhcmOZv1j95g7ya0pAjgVX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0KANTVY1StJV2S/2dsb2JhbABbgw5UWYhhwWuBcIdNgR8WAQEBAQF9hQIfHTQCTA0BBwEBiD0N0C4BAQEBBgEBAQEBAQEbkDIRAVAQhEIFgV2VMIJIhFyBcYYMjmqEIBkwAYEOgTwBAQE X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208,217";a="371692968" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2014 21:54:27 +0000 Received: from [10.21.90.27] (sjc-vpn5-539.cisco.com [10.21.90.27]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sACLsQbl002518; Wed, 12 Nov 2014 21:54:26 GMT Message-ID: <5463D712.50802@cisco.com> Date: Wed, 12 Nov 2014 11:54:26 -1000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETCONF Content-Type: multipart/alternative; boundary="------------080206010504020406090600" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zBSWobG9SCfSiWtMSKofhdU7CWo Cc: "anima-chairs@tools.ietf.org" Subject: [Netconf] ANIMA and NETCONF zero touch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:54:30 -0000 This is a multi-part message in MIME format. --------------080206010504020406090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, As discussed today during the OPSAREA meeting, let me make the link between the NETCONF zero touch draft [1] and the individual ANIMA bootstrapping draft [2]. >From http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-00#section-4.1 Client behavior is as follows: 1. Discover a communication channel to the "closest" Registrar by trying the following steps in this order: A. Search for a Proxy on the local link using Neighbor Discovery. If multiple local proxies are discovered attempt communications with each before widening the search to other options. If this fails: B. Obtain an IP address using DHCP, and search for a local registrar using DNS service discovery. If this fails: C. Obtain an IP address using DHCP, and search for a pre-defined Factory provided global registrar using DNS. 2. Present IEEE 802.1AR credentials to the discovered Registrar (via a Proxy if necessary). Included is a generated nonce that is specific to this attempt. 3. Verify the MASA cloud service generated authorization token as provided by the contacted Registrar. The nonce information previously provided is also checked, if it was not removed by the Registrar. 4. If and only if step three is successful: Join Domain, by accepting the domain specific information from the registrar, and by enrolling a domain certificate from the registrar. 5. The New Entity is now a member of the domain and will only repeat the discovery aspects of bootstrapping if it is returned to factory default settings. [[EDNOTE: Step (1b and 1c) is similar to the vendor DNS mechanisms described indraft-kwatsen-netconf-zerotouch although the goal here is to contact a Registrar rather than a vendor supplied NMS] The goal of this email is simply to bring awareness, and to start a discussion. Note: I don't like WG cross-postings, so only the ANIMA chairs are copied. [1] tools.ietf.org/html/draft-kwatsen-netconf-zerotouch [2] http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-00 Regards, Benoit --------------080206010504020406090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

As discussed today during the OPSAREA meeting, let me make the link between the NETCONF zero touch draft [1] and the individual ANIMA bootstrapping draft [2].

From http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-00#section-4.1
  Client behavior is as follows:

   1.  Discover a communication channel to the "closest" Registrar by
       trying the following steps in this order:

       A.  Search for a Proxy on the local link using Neighbor
           Discovery.  If multiple local proxies are discovered attempt
           communications with each before widening the search to other
           options.  If this fails:

       B.  Obtain an IP address using DHCP, and search for a local
           registrar using DNS service discovery.  If this fails:

       C.  Obtain an IP address using DHCP, and search for a pre-defined
           Factory provided global registrar using DNS.

   2.  Present IEEE 802.1AR credentials to the discovered Registrar (via
       a Proxy if necessary).  Included is a generated nonce that is
       specific to this attempt.

   3.  Verify the MASA cloud service generated authorization token as
       provided by the contacted Registrar.  The nonce information
       previously provided is also checked, if it was not removed by the
       Registrar.

   4.  If and only if step three is successful: Join Domain, by
       accepting the domain specific information from the registrar, and
       by enrolling a domain certificate from the registrar.

   5.  The New Entity is now a member of the domain and will only repeat
       the discovery aspects of bootstrapping if it is returned to
       factory default settings.

   [[EDNOTE: Step (1b and 1c) is similar to the vendor DNS mechanisms
   described in draft-kwatsen-netconf-zerotouch although the goal here
   is to contact a Registrar rather than a vendor supplied NMS]

The goal of this email is simply to bring awareness, and to start a discussion.
Note: I don't like WG cross-postings, so only the ANIMA chairs are copied.

[1] tools.ietf.org/html/draft-kwatsen-netconf-zerotouch
[2] http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-00

Regards, Benoit
--------------080206010504020406090600-- From nobody Wed Nov 12 21:07:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0C1A1B81 for ; Wed, 12 Nov 2014 21:07:49 -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 SIWZ0cxPWcVl for ; Wed, 12 Nov 2014 21:07:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD551A1B7F for ; Wed, 12 Nov 2014 21:07:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAD57hcK015139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 05:07:43 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAD57gVj016431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 06:07:42 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 13 Nov 2014 06:07:42 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 06:07:42 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise , netconf Thread-Topic: Summary of and AIs from the NETCONF Session in IETF #91 Thread-Index: AQHP/v/A0RV7p1iOEE6jjsWMtI6v8g== Date: Thu, 13 Nov 2014 05:07:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3774 X-purgate-ID: 151667::1415855263-00001FC1-DE6DBED2/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WZSJ5b-4Ay6dkNfcf7Jvf0ZbM8A Subject: [Netconf] Summary of and AIs from the NETCONF Session in IETF #91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:07:50 -0000 SGkgQmVub2l0LCBORVRDT05GIFdHLA0KDQpiZWxvdyBpcyBhIHN1bW1hcnkgYW5kIGFjdGlvbiBp dGVtcyBmcm9tIHRoZSBORVRDT05GIFdHIHNlc3Npb24gb24gTm92ZW1iZXIgMTEsIDIwMTQsIEhv bm9sdWx1LCBIYXdhaWkuIA0KQSBzaG9ydCB2ZXJzaW9uIG9mIHRoaXMgc3VtbWFyeSB3aWxsIGJl IG1hZGUgYXZhaWxhYmxlIGF0IE9QUyBhcmVhIFdpa2kgc29vbiAoYXQgaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpL0lFVEY5MXN1bW1hcnkpLg0KIA0KLSBXZSBo YWQgYXBwcm94LiA4NSsgcGFydGljaXBhbnRzIGluIHRoZSAyIGhvdXIgTkVUQ09ORiBzZXNzaW9u LA0KLSBXZSByZXZpZXdlZCB0aGUgc3RhdHVzIG9mIHRoZSBXRywNCi0gV2UgaGFkIGEgZGlzY3Vz c2lvbiBvbiBhbGwgNiBjaGFydGVyZWQgZG9jdW1lbnRzLg0KLSBOb3RlIHRha2VycyB3ZXJlOiBM YWRhIExob3RrYSBhbmQgQmFsYXpzIExlbmd5ZWwuIFRoZSBKYWJiZXIgc2NyaWJlIHdhcyBSb2xm IFdpbnRlci4NCk1hbnkgdGhhbmtzIHRvIHRoZSBub3RlIHRha2VycyBhbmQgamFiYmVyIHNjcmli ZSBmb3Igdm9sdW50ZWVyaW5nLg0KIA0KVGhlIHNlc3Npb24gYWdlbmRhIGlzIGF2YWlsYWJsZSBh dDogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MS9hZ2VuZGEvYWdlbmRhLTkxLW5l dGNvbmYgIA0KTkVUQ09ORiBjby1jaGFpcnMgd2lsbCBhc2sgZm9yIGEgcm9vbSBmb3IgMTAwIGZv ciB0aGUgbmV4dCBtZWV0aW5nLg0KDQpGb2xsb3dpbmcgYXJlIHRoZSBkZWNpc2lvbnMgdGFrZW4g cGVyIGh1bW1pbmcgaW4gdGhlIE5FVENPTkYgc2Vzc2lvbi4NCklmIHRoZXJlIGlzIG5vIHN0cm9u ZyBvYmplY3Rpb24gd2Ugd2lsbCBpbXBsZW1lbnQgYXMgcHJvcG9zZWQuDQoNClJFU1RDT05GIENh bGwgaG9tZSBzdXBwb3J0Og0KICAgLSBodW1taW5nIHN1cHBvcnRlZCB0aGlzIGFwcHJvYWNoLCBh bmQgdGhlIFdHIHdhbnRzIHRvIGRvIGl0IG5vdy4NCg0KU2VwYXJhdGUgcG9ydHMgZm9yIGNhbGxo b21lIGZvciBTU0gsIFRMUywgUkVTVENPTkYNCiAgIC0gVGhlIFdHIHN1cHBvcnRzIHdpdGggYSBs YXJnZSBodW1tIG11bHRpcGxlL3NlcGFyYXRlIHBvcnRzLg0KDQpGb2N1cyBvbiB0aGUgdXNlIG9m IFguNTA5IGZvciBUTFMgKHJmYzU1MzliaXMpDQogICAtIHN1cHBvcnRlZCBieSBhIGxhcmdlIGh1 bW0NCg0KRGVzY3JpYmUgYWxnb3JpdGhtIGZvciBleHRyYWN0aW5nIGEgdXNlciBuYW1lIG91dCBv ZiB0aGUgWDUwOSBhdHRyaWJ1dGVzDQogICAtIGxvdWQgaHVtbSBpbiBmYXZvcg0KDQpVc2UgaWYt ZmVhdHVyZSBmb3Igc2VydmVyLW1vZGVsIGluc3RlYWQgb2Ygd2FpdGluZyBmb3IgYW4gWUFORyAx LjEgc29sdXRpb24NCiAgIC0gbG91ZCBodW1tIGluIGZhdm9yLCBjZXJ0YWlubHkgd2UgZG8gbm90 IHdhbnQgdG8gd2FpdA0KDQpTaG91bGQgd2UgZ2VuZXJhdGUgc3NoIGhvc3Qga2V5cy81MDktY2Vy dGlmaWNhdGVzIHZpYSBhIHlhbmcgbW9kZWwgb3IgZ2VuZXJhdGUNCnRoZW0gb3V0IG9mIGJhbmQu DQogICAtICBiaWcgaHVtbSBmb3IgeWVzLCBpLmUuIHdlIHBvc3Rwb25lIGFuZCBkbyBpdCBsYXRl ci4NCg0KUmVwb3J0IGhvc3RrZXlzL2NlcnRpZmljYXRlcyB2aWEgeWFuZyBkYXRhIG1vZGVsDQog ICAtIEh1bW0gdG8gdGFrZSB0aGVtIG91dCBhbmQgbm90IHJlcG9ydCB0aGVtIHZpYSBhIGRhdGEg bW9kZWwNCg0KUkVTVENPTkYgc3RhdGUgbW9uaXRvcmluZyB3b3VsZCByZXF1aXJlIFJFU1RDT05G IHNlc3Npb25zDQogICAtIEFDVElPTiBpdGVtOiBBbmR5IHdpbGwgdGFrZSB0aGUgaXNzdWUgdG8g bGlzdA0KDQpSRVNUQ09ORiBEZWZhdWx0IGhhbmRsaW5nOg0KICAgLSBBQ1RJT04gaXRlbTogQW5k eSB3aWxsIHRha2UgaXQgdG8gdGhlIGxpc3QNCg0KU0hPVUxEIG9yIE1VU1QgdXNlIEhUVFAgMS4x DQogICAtIGh1bW0gaW4gZmF2b3Igb2YgU0hPVUxEDQoNClRoZSBpc3N1ZSBvbiB0aGUgSTJSUyBl cGhlbWVyYWwgc3RhdGUgaGFzIGJlZW4gc3VtbWFyaXplZCBieSB0aGUgSTJSUyBjby1jaGFpciBK ZWZmIEhhYXMuDQpUaGUgZGlzY3Vzc2lvbiB3aWxsIGJlIGNvbnRpbnVlZCBpbiBORVRDT05GIHZp cnR1YWwgbWVldGluZ3MuDQoNClRoZSB0d28gZHJhZnRzIG9uIGZyYWdtZW50YXRpb24gc3VwcG9y dCB3aWxsIGJlIG1lcmdlZCBhbmQgcHJvdmlkZWQgdG8gTkVUQ09ORiBtYWlsbGlzdC4NClRoZSBh aW0gc2hvdWxkIGJlIHRvIHJhaXNlIGEgZGlzY3Vzc2lvbiBhbmQgdG8gZ2V0IHRoZSBzdXBwb3J0 IG9mIE5FVENPTkYgV0cgbWVtZWJlcnMuDQoNClZpcnR1YWwgTWVldGluZ3M6DQogICAtIFRoZSBX RyB3aWxsIGNvbnRpbnVlIHdpdGggdmlydHVhbCBtZWV0aW5ncy4NCiAgIC0gSW4gdGhlIGZpcnN0 IG1lZXRpbmcgd2Ugd2lsbCBkaXNjdXNzIEkyUlMgZXBoZW1lcmFsIHN0YXRlLg0KICAgLSBBY3Rp b24gaXRlbTogTWVobWV0IHRvIHNlbmQgb3V0IGEgbmV3IGRvb2RsZSBwb2xsIHRvIGNob3NlIHRo ZSBiZXN0IHRpbWUgZm9yIGFsbC4NCg0KUG90ZW50aWFsIHJlcXVpcmVtZW50cyBvbiB6ZXJvdG91 Y2ggZnJvbSBBTklNQSBXRzoNCiAgIC0gQWN0aW9uIGl0ZW06IFdHIGNoYWlycyB0byBjb21tdW5p Y2F0ZSB3aXRoIEFOSU1BIFdHIGNvLWNoYWlycyB0aGF0IHRoZXkgbXVzdCBhZ3JlZSBvbg0KICAg ICByZXF1aXJlbWVudHMgYW5kIHByb3ZpZGUgd2l0aCBhIGRyYWZ0IHRvIE5FVENPTkYgV0cuDQoN CkNoZWVycywNCk1laG1ldA0KDQo= From nobody Thu Nov 13 02:38:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112081A6FEE for ; Thu, 13 Nov 2014 02:38: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, 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 OzTj8LVF82yq for ; Thu, 13 Nov 2014 02:38:04 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::790]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474511A6FE0 for ; Thu, 13 Nov 2014 02:38:04 -0800 (PST) Received: from pc6 (86.184.62.161) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 10:37:40 +0000 Message-ID: <04e301cfff2d$7493fae0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Benoit Claise , netconf References: Date: Thu, 13 Nov 2014 10:31:15 +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.184.62.161] X-ClientProxiedBy: DB4PR02CA0021.eurprd02.prod.outlook.com (10.242.174.149) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Forefront-PRVS: 0394259C80 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(66654002)(13464003)(189002)(51704005)(44736004)(4396001)(31966008)(21056001)(116806002)(106356001)(46102003)(107046002)(40100003)(50226001)(102836001)(120916001)(105586002)(99396003)(61296003)(33646002)(77156002)(62966003)(101416001)(20776003)(64706001)(47776003)(95666004)(122386002)(42186005)(44716002)(107886001)(77096003)(88136002)(229853001)(62236002)(23756003)(19580405001)(66066001)(104166001)(50466002)(14496001)(87976001)(84392001)(89996001)(19580395003)(92566001)(92726001)(81686999)(86362001)(15202345003)(97736003)(87286001)(15975445006)(76176999)(81816999)(50986999)(93916002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AaeLSV4fnuyKFfUT3Ho4Ik_5-Vo Subject: [Netconf] 5539bis was Re: Summary of and AIs from the NETCONF Session in IETF #91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:38:07 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Benoit Claise" ; "netconf" Sent: Thursday, November 13, 2014 5:07 AM Subject: [Netconf] Summary of and AIs from the NETCONF Session in IETF #91 > Hi Benoit, NETCONF WG, > > below is a summary and action items from the NETCONF WG session on November 11, 2014, Honolulu, Hawaii. > A short version of this summary will be made available at OPS area Wiki soon (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF91summary). > > - We had approx. 85+ participants in the 2 hour NETCONF session, > - We reviewed the status of the WG, > - We had a discussion on all 6 chartered documents. > - Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe was Rolf Winter. > Many thanks to the note takers and jabber scribe for volunteering. > > The session agenda is available at: http://www.ietf.org/proceedings/91/agenda/agenda-91-netconf > NETCONF co-chairs will ask for a room for 100 for the next meeting. > > Following are the decisions taken per humming in the NETCONF session. > If there is no strong objection we will implement as proposed. > > > Focus on the use of X.509 for TLS (rfc5539bis) > - supported by a large humm A clarification - does this mean that we re-title rfc5539bis as being only about the use of TLS leaving those wanting other forms of security to write their own I-Ds? Tom Petch > > > Cheers, > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 13 02:38:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F0D1A6FE0 for ; Thu, 13 Nov 2014 02:38: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, 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 rmpzgn0DKtPV for ; Thu, 13 Nov 2014 02:38:05 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::790]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1C21A6FE5 for ; Thu, 13 Nov 2014 02:38:04 -0800 (PST) Received: from pc6 (86.184.62.161) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 10:37:41 +0000 Message-ID: <04e401cfff2d$74e7e740$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Benoit Claise , netconf References: Date: Thu, 13 Nov 2014 10:34:15 +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.184.62.161] X-ClientProxiedBy: DB4PR02CA0021.eurprd02.prod.outlook.com (10.242.174.149) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Forefront-PRVS: 0394259C80 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(66654002)(13464003)(189002)(51704005)(44736004)(4396001)(31966008)(21056001)(116806002)(106356001)(46102003)(107046002)(40100003)(50226001)(102836001)(120916001)(105586002)(99396003)(61296003)(33646002)(77156002)(62966003)(101416001)(20776003)(64706001)(47776003)(95666004)(122386002)(42186005)(44716002)(107886001)(77096003)(88136002)(229853001)(62236002)(23756003)(19580405001)(66066001)(104166001)(50466002)(14496001)(87976001)(84392001)(89996001)(19580395003)(92566001)(92726001)(81686999)(86362001)(15202345003)(97736003)(87286001)(15975445006)(76176999)(81816999)(50986999)(93916002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VtzZC_QhRH-09G36d83d7fzoflY Subject: [Netconf] username from X.503 was Re: Summary of and AIs from the NETCONF Session in IETF #91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:38:08 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Benoit Claise" ; "netconf" Sent: Thursday, November 13, 2014 5:07 AM > Hi Benoit, NETCONF WG, > > below is a summary and action items from the NETCONF WG session on November 11, 2014, Honolulu, Hawaii. > A short version of this summary will be made available at OPS area Wiki soon (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF91summary). > > - We had approx. 85+ participants in the 2 hour NETCONF session, > - We reviewed the status of the WG, > - We had a discussion on all 6 chartered documents. > - Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe was Rolf Winter. > Many thanks to the note takers and jabber scribe for volunteering. > > The session agenda is available at: http://www.ietf.org/proceedings/91/agenda/agenda-91-netconf > NETCONF co-chairs will ask for a room for 100 for the next meeting. > > Following are the decisions taken per humming in the NETCONF session. > If there is no strong objection we will implement as proposed. > > Describe algorithm for extracting a user name out of the X509 attributes > - loud humm in favor > A clarification - does this mean that this algorithm goes in netconf-server? Tom Petch > Cheers, > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 13 11:45:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9D1ACE5A for ; Thu, 13 Nov 2014 11:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 O15UFRoxps2y for ; Thu, 13 Nov 2014 11:45:00 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6641ACE59 for ; Thu, 13 Nov 2014 11:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2797; q=dns/txt; s=iport; t=1415907902; x=1417117502; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=2eK+hh2TwlKUyclrN5aO4QnM0cIzMGD1FDNS//cK50M=; b=jwdwsoF0kgjAx8RIfdbI1JvoniUy2mJ6onpQb4PMlMebehy2Kp5DiqMh t+oKKCe3jTGOy7wrFvTKZ7Rt0xj8H+x3yD6cJ+y0kFYZLipLjSnbscy6X vOHWqUtOu8Vit6MvIHV/OTOqqulu4lRHFFoTmmb43J2du5ZPxzSWxDSeo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIKANQJZVStJA2M/2dsb2JhbABbgw5UWYhhxAwBCYZ6VQKBIRYBAQEBAX2EAwEBBAEBAWsKEQsEHRYPCQMCAQIBFTAGDQYCAQGIPQ3QfwEBAQEBAQEDAQEBAQEBARcEkRuESwWeMYE0g0+CeopghAqEIBkwgksBAQE X-IronPort-AV: E=Sophos; i="5.07,379,1413244800"; d="scan'208,217"; a="96378414" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 13 Nov 2014 19:45:01 +0000 Received: from [10.21.102.44] ([10.21.102.44]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sADJixWi014465; Thu, 13 Nov 2014 19:44:59 GMT Message-ID: <54650A3B.5080508@cisco.com> Date: Thu, 13 Nov 2014 09:44:59 -1000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETCONF , "Jethanandani, Mahesh" References: <543BF489.7000708@cisco.com> In-Reply-To: <543BF489.7000708@cisco.com> Content-Type: multipart/alternative; boundary="------------000401060203020204060106" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/E7VHPHJlgZctp7EK_ak-EdnXMD0 Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:45:03 -0000 This is a multi-part message in MIME format. --------------000401060203020204060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please welcome Mahesh as new NETCONF co-chair. Regards, Benoit > Dear all, > > I have to announce, with mixed feelings, that one of my mentors at the > IETF decided to retire. > On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well > deserved retirement. > On the hand, Bert will be missed, for sure. Not only as a leader, a > mentor, but also a friend. > Note that Bert will be attending his last IETF meeting in Honolulu. > This is your chance... > > Practically, this implies that we are looking for a new NETCONF co-chair. > Please let Joel and I know if you are interested. > > Regards, Benoit > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------000401060203020204060106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Please welcome Mahesh as new NETCONF co-chair.

Regards, Benoit
Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance...

Practically, this implies that we are looking for a new NETCONF co-chair.
Please let Joel and I know if you are interested.

Regards, Benoit




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

--------------000401060203020204060106-- From nobody Thu Nov 13 12:14:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDB1ACF83 for ; Thu, 13 Nov 2014 12:14:19 -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 SesUiOvIPkuy for ; Thu, 13 Nov 2014 12:14:16 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (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 C817D1ACF0E for ; Thu, 13 Nov 2014 12:14:15 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Xp0mQ-00020t-1J; Thu, 13 Nov 2014 21:14:11 +0100 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=dhcp-b3d6.meeting.ietf.org) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Xp0mP-0000FV-A4; Thu, 13 Nov 2014 21:14:09 +0100 Message-ID: <5465110D.7000608@bwijnen.net> Date: Thu, 13 Nov 2014 21:14:05 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Benoit Claise , NETCONF , "Jethanandani, Mahesh" References: <543BF489.7000708@cisco.com> <54650A3B.5080508@cisco.com> In-Reply-To: <54650A3B.5080508@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd435201d591d0f049f77c982c640f714b2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rBagTFAdGyAuv3ShUP9jJwlFE2M Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:14:19 -0000 Welcome Mahesh. I wish you all the best and success in co-chairing with Mehmet. You have a great WG and the NETCONF (and NETMOD) work is at a stage where we see big acceptance in the market and in other organizations. I trust that you and Mehmet, Benoit and the whole WG (and NETMOD WG) will keep up the momentum. Thanks to all WG participants and our AD Benoit for your confidence in me as WG co-chair over the last (was it 6 or so?) years. Also a BIG THANKS to Mehmet for putting up with me and for the great wg-chair work he has been doing together with me. Without him, things would not have gone as smooth I can tell you that. To be clear: - I retire from my day job at RIPE NCC by jan 1st, - I step down from NETCONF WG co-chair position as of today. - I will not be at all IETF meetings in the future, but I may show up at some places. - I will try to follow (and participate in) netconf discussions on the mailing list. But cannot guarantee that. That will all depend a lot on how things fall in place once I have retired. Thanks again to you all. Bert On 13/11/14 20:44, Benoit Claise wrote: > Dear all, > > Please welcome Mahesh as new NETCONF co-chair. > > Regards, Benoit >> Dear all, >> >> I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire. >> On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well deserved retirement. >> On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend. >> Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance... >> >> Practically, this implies that we are looking for a new NETCONF co-chair. >> Please let Joel and I know if you are interested. >> >> Regards, Benoit >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Nov 13 15:00:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADED1AE187 for ; Thu, 13 Nov 2014 15:00:45 -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 XkLqYyN2Dwt1 for ; Thu, 13 Nov 2014 15:00:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCB11AE183 for ; Thu, 13 Nov 2014 15:00:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sADN0VI8023424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 23:00:31 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sADN0Uk3027463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 00:00:30 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 14 Nov 2014 00:00:29 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 00:00:30 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , Benoit Claise , NETCONF , "Jethanandani, Mahesh" Thread-Topic: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh Thread-Index: AQHP/35t4FYoKHP8Y0WYD485Tny5epxfKz5g Date: Thu, 13 Nov 2014 23:00:29 +0000 Message-ID: References: <543BF489.7000708@cisco.com> <54650A3B.5080508@cisco.com> <5465110D.7000608@bwijnen.net> In-Reply-To: <5465110D.7000608@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2857 X-purgate-ID: 151667::1415919632-0000437E-C29744A7/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/l99Ka4NpoxE0uTtud8XRLhmYkR4 Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:00:45 -0000 Welcome Mahesh, will be happy to work with you together. Let's meet today during the snack break. Cheers,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Bert Wij= nen (IETF) > Sent: Thursday, November 13, 2014 9:14 PM > To: Benoit Claise; NETCONF; Jethanandani, Mahesh > Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahes= h >=20 > Welcome Mahesh. >=20 > I wish you all the best and success in co-chairing with Mehmet. > You have a great WG and the NETCONF (and NETMOD) work is at a > stage where we see big acceptance in the market and in other > organizations. I trust that you and Mehmet, Benoit and the whole WG > (and NETMOD WG) will keep up the momentum. >=20 > Thanks to all WG participants and our AD Benoit for your confidence > in me as WG co-chair over the last (was it 6 or so?) years. >=20 > Also a BIG THANKS to Mehmet for putting up with me and for the great > wg-chair work he has been doing together with me. Without him, things > would not have gone as smooth I can tell you that. >=20 > To be clear: > - I retire from my day job at RIPE NCC by jan 1st, > - I step down from NETCONF WG co-chair position as of today. > - I will not be at all IETF meetings in the future, but > I may show up at some places. > - I will try to follow (and participate in) netconf discussions > on the mailing list. But cannot guarantee that. That will all depend > a lot on how things fall in place once I have retired. >=20 > Thanks again to you all. > Bert >=20 > On 13/11/14 20:44, Benoit Claise wrote: > > Dear all, > > > > Please welcome Mahesh as new NETCONF co-chair. > > > > Regards, Benoit > >> Dear all, > >> > >> I have to announce, with mixed feelings, that one of my mentors at the= IETF > decided to retire. > >> On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well dese= rved > retirement. > >> On the hand, Bert will be missed, for sure. Not only as a leader, a me= ntor, but > also a friend. > >> Note that Bert will be attending his last IETF meeting in Honolulu. Th= is is your > chance... > >> > >> Practically, this implies that we are looking for a new NETCONF co-cha= ir. > >> Please let Joel and I know if you are interested. > >> > >> Regards, Benoit > >> > >> > >> > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 13 19:40:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446A91A1BF0 for ; Thu, 13 Nov 2014 19:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 EH6YHx-loeL3 for ; Thu, 13 Nov 2014 19:40:26 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9130F1A1BE9 for ; Thu, 13 Nov 2014 19:40:26 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.161.204; From: "Susan Hares" To: "'Benoit Claise'" , "'NETCONF'" , "'Jethanandani, Mahesh'" References: <543BF489.7000708@cisco.com> <54650A3B.5080508@cisco.com> In-Reply-To: <54650A3B.5080508@cisco.com> Date: Thu, 13 Nov 2014 22:40:23 -0500 Message-ID: <013c01cfffbc$b97104c0$2c530e40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01CFFF92.D09D6DC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF2LrpggZ7KP3f3H1nZAYRgUXaydAH/uWBenQMeIDA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qbMPX6WSXQiaR9ZTW9HMFMA4VYE Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 03:40:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013D_01CFFF92.D09D6DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mahesh: Welcome! Sue From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, November 13, 2014 2:45 PM To: NETCONF; Jethanandani, Mahesh Subject: Re: [Netconf] Looking for a new NETCONF co-chair - Welcome Mahesh Dear all, Please welcome Mahesh as new NETCONF co-chair. Regards, Benoit Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire. On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved retirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_013D_01CFFF92.D09D6DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

Welcome!

 

Sue

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of = Benoit Claise
Sent: Thursday, November 13, 2014 2:45 = PM
To: NETCONF; Jethanandani, Mahesh
Subject: Re: = [Netconf] Looking for a new NETCONF co-chair - Welcome = Mahesh

 

Dear = all,

Please welcome Mahesh as new NETCONF = co-chair.

Regards, Benoit

Dear = all,

I have to announce, with mixed feelings, that one of my = mentors at the IETF decided to retire.
On one hand, I'm pretty happy = for Bert Wijnen to enjoy his well deserved retirement.
On the = hand, Bert will be missed, for sure. Not only as a leader, a mentor, but = also a friend.
Note that Bert will be attending his last IETF meeting = in Honolulu. This is your chance...

Practically, this implies = that we are looking for a new NETCONF co-chair.
Please let Joel and I = know if you are interested.

Regards, = Benoit





_______________________=
________________________
Netconf mailing =
list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

 

------=_NextPart_000_013D_01CFFF92.D09D6DC0-- From nobody Fri Nov 14 05:18:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A31A00DE for ; Fri, 14 Nov 2014 05:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jh5brd1hqlK for ; Fri, 14 Nov 2014 05:18:06 -0800 (PST) Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2781C1A00D8 for ; Fri, 14 Nov 2014 05:18:05 -0800 (PST) Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id FRJ31p0043BT6uC01RJ3ZJ; Fri, 14 Nov 2014 13:18:03 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=W7O2VHmk c=1 sm=1 tr=0 a=jSQgp9IWXRf89EXR5FPwJg==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=eDuwVpe5h8AA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=_b8vxhCIwAq4z4CtTEIA:9 a=QEXdDO2ut3YA:10 a=jM_x9b4JT8QA:10 a=2mLzDuUFM-0A:10 a=e3R5Qtt4um6GIFjy1UwA:9 a=A3jBEesAZaH0AqG3:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 14 Nov 2014 13:18:03 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_256e1e50aa3d3feefe533f58f665ed94" Date: Fri, 14 Nov 2014 13:18:03 +0000 From: Jonathan Hansford To: In-Reply-To: References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> Message-ID: <168e6dc03062eca48e58585ed91d503f@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.131.152] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/a5eIIrCFKj5i9b_fdzfptjuYq8Q Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:18:12 -0000 --=_256e1e50aa3d3feefe533f58f665ed94 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, Section 1.2 * The section is entitled "Simple Subset of NETCONF Functionality", but if the only aspects of NETCONF it is lacking are the transaction features bulleted in the third paragraph then the title seems to be underselling it somewhat. * I'm a little confused with the first paragraph; maybe it is just the way I am reading it. The first sentence appears to describe what RESTCONF needs to be, whereas the second appears to describe what RESTCONF lacks (based on the third paragraph). However, both sentences (and the second paragraph) talk about what is or is not "needed". Could these be reworded to clarify what RESTCONF provides and what it doesn't? * Is there any intent to address these additional needs at some point, or is it assumed RESTCONF is adequate without them? Is there any reason why they aren't being addressed at this time? * The transaction features listed in the third paragraph are all capabilities defined in RFC 6241 plus RFC 5717. Are all other capabilities from 6241 (i.e. those not listed in this paragraph) supported by RESTCONF (e.g. Rollback-on-Error)? Thanks, Jonathan On 2014-10-25 23:16, Andy Bierman wrote: > FYI, > > This version of RESTCONF addresses all issues on the github tracker > except maybe #9. Also, #11 was deferred to a future release. > > A change was made to the "stream" list in ietf-restconf-monitoring.yang > to allow separate stream links for XML and (optionally) JSON encoding > of notifications. > > A "collection" resource, plus "limit" and "offset" query parameters, > have been added to allow multiple leaf-list and list instances > to be retrieved. The optional "page" capability allows pagination of > list entries, using the limit and offset parameters. > > Issue List: > https://github.com/netconf-wg/restconf/issues > > Please review the draft and send any comments to the mailing list. > Please post any objections to closing the issues #2 - #8 and #10 - #13. > > thanks, > Andy > > On Sat, Oct 25, 2014 at 3:46 PM, wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ [1] There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 [2] A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-03 [3] 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/ [4] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org [5] https://www.ietf.org/mailman/listinfo/i-d-announce [6] Internet-Draft directories: http://www.ietf.org/shadow.html [7] or ftp://ftp.ietf.org/ietf/1shadow-sites.txt [8] > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Links: ------ [1] https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ [2] http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 [3] http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-03 [4] http://webmail.plus.net/ftp://ftp.ietf.org/internet-drafts/ [5] mailto:I-D-Announce@ietf.org [6] https://www.ietf.org/mailman/listinfo/i-d-announce [7] http://www.ietf.org/shadow.html [8] http://webmail.plus.net/ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=_256e1e50aa3d3feefe533f58f665ed94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

Section 1.2

  • The section is entitled "Simple Subset of NETCONF Functionality", but i= f the only aspects of NETCONF it is lacking are the transaction features bu= lleted in the third paragraph then the title seems to be underselling it so= mewhat.
  • I'm a little confused with the first paragraph; maybe it is just the wa= y I am reading it. The first sentence appears to describe what RESTCONF nee= ds to be, whereas the second appears to describe what RESTCONF lacks (based= on the third paragraph). However, both sentences (and the second paragraph= ) talk about what is or is not "needed". Could these be reworded to clarify= what RESTCONF provides and what it doesn't?
  • Is there any intent to address these additional needs at some point, or= is it assumed RESTCONF is adequate without them? Is there any reason why t= hey aren't being addressed at this time?
  • The transaction features listed in the third paragraph are all capabili= ties defined in RFC 6241 plus RFC 5717. Are all other capabilities from 624= 1 (i.e. those not listed in this paragraph) supported by RESTCONF (e.g. Rol= lback-on-Error)?

Thanks,

Jonathan

On 2014-10-25 23:16, Andy Bierman wrote:

FYI,

This version of RESTCONF addresses all issues on the github tracker
except maybe #9. Also,  #11 was deferred to a future release.

A change was made to the "stream" list in ietf-restconf-monitoring.yang
to allow separate stream links for XML and (optionally) JSON encoding
of notifications.

A "collection" resource, plus "limit" and "offset" query parameters,
have been added to allow multiple leaf-list and list instances
to be retrieved. The optional "page" capability allows pagination of
list entries, using the limit and offset parameters.

Issue List:
https://github.co=
m/netconf-wg/restconf/issues


Please review the draft and send any comments to the mailing list.
Please post any objections to closing the issues #2 - #8 and #10 - #13.

thanks,
Andy

On Sat, Oct 25, 2014 at 3:46 PM,  <internet-drafts@ietf.org> wrote:
A New Internet-Draft is available fro= m the on-line Internet-Drafts directories. This draft is a work item of the= Network Configuration Working Group of the IETF. Title : RESTCONF Protocol= Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-= netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 Abstract: This documen= t describes an HTTP-based protocol that provides a programmatic interface f= or accessing data defined in YANG, using the datastores defined in NETCONF= =2E The IETF datatracker status page for this draft is: https://datatracker= =2Eietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized ve= rsion available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from the previous version is available at: http://www.ietf= =2Eorg/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 Please note that i= t may take a couple of minutes from the time of submission until the htmliz= ed version and diff are available at tools.ietf.org. Internet-Drafts are al= so 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-announc= e Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf=
=2Eorg/mailman/listinfo/netconf
--=_256e1e50aa3d3feefe533f58f665ed94-- From nobody Fri Nov 14 08:29:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334891A1AA6 for ; Fri, 14 Nov 2014 08:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcm70qkalkp2 for ; Fri, 14 Nov 2014 08:29:01 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6C61A0010 for ; Fri, 14 Nov 2014 08:29:00 -0800 (PST) Received: from Vanguard ([84.92.149.4]) by avasout01 with smtp id FUUx1p00105w0Nk01UUyMG; Fri, 14 Nov 2014 16:28:59 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZZGTN6lA c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=6bkCdLdQAAAA:8 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=A_U3If8U8--RwtaXnEwA:9 a=QT5q1JX7flgmuH9G:21 a=PFrWf53cFg_aVYXw:21 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 a=2mLzDuUFM-0A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=3IHT68u9SFTyq0zC6L8A:9 a=K5DJQeMjWPUik-DO:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 From: "Jonathan Hansford" To: "'Andy Bierman'" References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 14 Nov 2014 16:29:06 -0000 Message-ID: <00b601d00028$1cb91d90$562b58b0$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D00028.1CBA5610" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMiybCIrL9oTg30tmRMAqnWcD0bwGnorXpm9nzcCA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gPPdl6LQtKISooZhqS0VetN-DgM Cc: 'Netconf' Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 16:29:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01D00028.1CBA5610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I've never worked with HTTP and so have been following up the HTTP definitions listed in section 1.4.2: * The terms 'fragment' and 'query' are actually defined in RFC 3986 * The term 'header line' is not defined in RFC 2616. Are you using it as a generic term for 'request line' and 'status line' that are defined in that RFC? * The term 'path' is not defined in RFC 2616 and is used in that RFC for a number of purposes. I presume it is the URI 'path' that is intended, which is defined in RFC 3986 * The term 'response body' is not defined in RFC 2616 but I presume it means the message body of the response. Jonathan -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: 26 October 2014 00:17 Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt FYI, This version of RESTCONF addresses all issues on the github tracker except maybe #9. Also, #11 was deferred to a future release. A change was made to the "stream" list in ietf-restconf-monitoring.yang to allow separate stream links for XML and (optionally) JSON encoding of notifications. A "collection" resource, plus "limit" and "offset" query parameters, have been added to allow multiple leaf-list and list instances to be retrieved. The optional "page" capability allows pagination of list entries, using the limit and offset parameters. Issue List: https://github.com/netconf-wg/restconf/issues Please review the draft and send any comments to the mailing list. Please post any objections to closing the issues #2 - #8 and #10 - #13. thanks, Andy On Sat, Oct 25, 2014 at 3:46 PM, < internet-drafts@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-03.txt > Pages : 99 > Date : 2014-10-25 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-03 > > > 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_00B7_01D00028.1CBA5610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve never worked with HTTP and so have been = following up the HTTP definitions listed in section = 1.4.2:

·         = The terms ‘fragment’ and = ‘query’ are actually defined in RFC 3986

·         = The term ‘header line’ is not = defined in RFC 2616. Are you using it as a generic term for = ‘request line’ and ‘status line’ that are = defined in that RFC?

·         = The term ‘path’ is not = defined in RFC 2616 and is used in that RFC for a number of purposes. I = presume it is the URI ‘path’ that is intended, which is = defined in RFC 3986

·         = The term ‘response body’ is = not defined in RFC 2616 but I presume it means the message body of the = response.

 

Jonathan

 

-----Original = Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On = Behalf Of Andy Bierman
Sent: 26 October 2014 00:17
Cc: = Netconf
Subject: Re: [Netconf] I-D Action: = draft-ietf-netconf-restconf-03.txt

 

FYI,

 

This = version of RESTCONF addresses all issues on the github tracker except = maybe #9. Also,  #11 was deferred to a future = release.

 

A change was made to the "stream" list in = ietf-restconf-monitoring.yang to allow separate stream links for XML and = (optionally) JSON encoding of notifications.

 

A = "collection" resource, plus "limit" and = "offset" query parameters, have been added to allow multiple = leaf-list and list instances to be retrieved. The optional = "page" capability allows pagination of list entries, using the = limit and offset parameters.

 

Issue = List:

https://github.com/netcon= f-wg/restconf/issues

 

 

Please = review the draft and send any comments to the mailing = list.

Please post any objections = to closing the issues #2 - #8 and #10 - #13.

 

thanks,

Andy

 

On = Sat, Oct 25, 2014 at 3:46 PM,  <internet-drafts@ietf.org<= /span>> wrote:

> 

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

>  This draft is a work item of the Network = Configuration Working Group of the IETF.

> 

>        = Title           : = RESTCONF Protocol

>        = Authors         : Andy = Bierman

>        =             &= nbsp;      Martin Bjorklund

>        =             &= nbsp;      Kent Watsen

>        = Filename        : = draft-ietf-netconf-restconf-03.txt

>        = Pages           : = 99

>        = Date            = : 2014-10-25

> 

> Abstract:

>    This document describes an = HTTP-based protocol that provides a

>    programmatic interface for = accessing data defined in YANG, using the

>    datastores defined in = NETCONF.

> 

> 

> The IETF datatracker status page for this = draft is:

> https://datatracker.ietf.= org/doc/draft-ietf-netconf-restconf/

> 

> There's also a htmlized version available = at:

> http://tools.ietf.org/htm= l/draft-ietf-netconf-restconf-03

> 

> A diff from the previous version is available = at:

> http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-netconf-restconf-03

> 

> 

> 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/intern= et-drafts/

> 

> = _______________________________________________

> I-D-Announce mailing list

> I-D-Announce@ietf.org

> https://www.ietf.org/mail= man/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shado= w.html or

> ftp://ftp.ietf.org/ietf/1= shadow-sites.txt

 

_______________________________________________=

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mail= man/listinfo/netconf

------=_NextPart_000_00B7_01D00028.1CBA5610-- From nobody Fri Nov 14 09:44:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2620E1A1B2A for ; Fri, 14 Nov 2014 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn8cpYp7PdKd for ; Fri, 14 Nov 2014 09:44:19 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2126E1A1B3B for ; Fri, 14 Nov 2014 09:44:18 -0800 (PST) Received: from Vanguard ([84.92.149.4]) by avasout01 with smtp id FVkD1p00N05w0Nk01VkELN; Fri, 14 Nov 2014 17:44:16 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZZGTN6lA c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=6bkCdLdQAAAA:8 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=A_U3If8U8--RwtaXnEwA:9 a=hmPDb6nMQr1p8acn:21 a=BBnGdD6L7NXFIp1E:21 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 a=2mLzDuUFM-0A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=amSGqL3xpFvFyZulNpoA:9 a=Y2w-jGrRS4ilHPEd:21 a=nYL0uaiVzu331mWl:21 a=T4mUlQ6PE1EVBVnm:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 From: "Jonathan Hansford" To: "'Andy Bierman'" References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> <00b601d00028$1cb91d90$562b58b0$@hansfords.net> In-Reply-To: <00b601d00028$1cb91d90$562b58b0$@hansfords.net> Date: Fri, 14 Nov 2014 17:44:22 -0000 Message-ID: <00f001d00032$a1724610$e456d230$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01D00032.A173F3C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMiybCIrL9oTg30tmRMAqnWcD0bwGnorXpAqmtXFKbxMRp0A== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/m0lOxubiQI6n_GhS5m-88mF-S1o Cc: 'Netconf' Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:44:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F1_01D00032.A173F3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Also, RFC2616 was obsoleted in June 2014 by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235, so should they be referenced instead? * RFC 3986 o Fragment o Path o Query * RFC 7230 o Message body o Header line (request line and status line?) o Request URI (the reference appears to be generally to the 'effective request URI') o Response body (actually the 'message body' of the response) * RFC 7231 o Method o Request (doesn't appear to be formally defined anywhere) o Resource * RFC 7232 o Entity tag From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan Hansford Sent: 14 November 2014 16:29 To: 'Andy Bierman' Cc: 'Netconf' Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt Hi, I've never worked with HTTP and so have been following up the HTTP definitions listed in section 1.4.2: * The terms 'fragment' and 'query' are actually defined in RFC 3986 * The term 'header line' is not defined in RFC 2616. Are you using it as a generic term for 'request line' and 'status line' that are defined in that RFC? * The term 'path' is not defined in RFC 2616 and is used in that RFC for a number of purposes. I presume it is the URI 'path' that is intended, which is defined in RFC 3986 * The term 'response body' is not defined in RFC 2616 but I presume it means the message body of the response. Jonathan -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: 26 October 2014 00:17 Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt FYI, This version of RESTCONF addresses all issues on the github tracker except maybe #9. Also, #11 was deferred to a future release. A change was made to the "stream" list in ietf-restconf-monitoring.yang to allow separate stream links for XML and (optionally) JSON encoding of notifications. A "collection" resource, plus "limit" and "offset" query parameters, have been added to allow multiple leaf-list and list instances to be retrieved. The optional "page" capability allows pagination of list entries, using the limit and offset parameters. Issue List: https://github.com/netconf-wg/restconf/issues Please review the draft and send any comments to the mailing list. Please post any objections to closing the issues #2 - #8 and #10 - #13. thanks, Andy On Sat, Oct 25, 2014 at 3:46 PM, < internet-drafts@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-03.txt > Pages : 99 > Date : 2014-10-25 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-03 > > > 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_00F1_01D00032.A173F3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also, RFC2616 was = obsoleted in June 2014 by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC = 7234 and RFC 7235, so should they be referenced = instead?

·         = RFC = 3986

o   = Fragment

o   = Path

o   = Query

·         = RFC = 7230

o   = Message = body

o   = Header line = (request line and status line?)

o   = Request URI = (the reference appears to be generally to the ‘effective request = URI’)

o   = Response = body (actually the ‘message body’ of the = response)

·         = RFC 7231 =

o   = Method

o   = Request = (doesn’t appear to be formally defined = anywhere)

o   = Resource

·         = RFC = 7232

o   = Entity = tag

 

 

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan = Hansford
Sent: 14 November 2014 16:29
To: 'Andy = Bierman'
Cc: 'Netconf'
Subject: Re: [Netconf] I-D = Action: = draft-ietf-netconf-restconf-03.txt

 

Hi,

 

I’ve never worked with HTTP and so have been = following up the HTTP definitions listed in section = 1.4.2:

·         = The terms ‘fragment’ and = ‘query’ are actually defined in RFC 3986

·         = The term ‘header line’ is not = defined in RFC 2616. Are you using it as a generic term for = ‘request line’ and ‘status line’ that are = defined in that RFC?

·         = The term ‘path’ is not = defined in RFC 2616 and is used in that RFC for a number of purposes. I = presume it is the URI ‘path’ that is intended, which is = defined in RFC 3986

·         = The term ‘response body’ is = not defined in RFC 2616 but I presume it means the message body of the = response.

 

Jonathan

 

-----Original = Message-----
From: Netconf [mailto:netconf-bounces@ietf.org<= /a>] On Behalf Of Andy Bierman
Sent: 26 October 2014 00:17
Cc: = Netconf
Subject: Re: [Netconf] I-D Action: = draft-ietf-netconf-restconf-03.txt

 

FYI,

 

This = version of RESTCONF addresses all issues on the github tracker except = maybe #9. Also,  #11 was deferred to a future = release.

 

A change was made to the "stream" list in = ietf-restconf-monitoring.yang to allow separate stream links for XML and = (optionally) JSON encoding of notifications.

 

A = "collection" resource, plus "limit" and = "offset" query parameters, have been added to allow multiple = leaf-list and list instances to be retrieved. The optional = "page" capability allows pagination of list entries, using the = limit and offset parameters.

 

Issue = List:

https://github.com/netcon= f-wg/restconf/issues

 

 

Please = review the draft and send any comments to the mailing = list.

Please post any objections = to closing the issues #2 - #8 and #10 - #13.

 

thanks,

Andy

 

On = Sat, Oct 25, 2014 at 3:46 PM,  <internet-drafts@ietf.org<= /span>> wrote:

> 

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

>  This draft is a work item of the Network = Configuration Working Group of the IETF.

> 

>        = Title           : = RESTCONF Protocol

>        = Authors         : Andy = Bierman

>        =             &= nbsp;      Martin Bjorklund

>        =             &= nbsp;      Kent Watsen

>        = Filename        : = draft-ietf-netconf-restconf-03.txt

>        = Pages           : = 99

>        = Date            = : 2014-10-25

> 

> Abstract:

>    This document describes an = HTTP-based protocol that provides a

>    programmatic interface for = accessing data defined in YANG, using the

>    datastores defined in = NETCONF.

> 

> 

> The IETF datatracker status page for this = draft is:

> https://datatracker.ietf.= org/doc/draft-ietf-netconf-restconf/

> 

> There's also a htmlized version available = at:

> http://tools.ietf.org/htm= l/draft-ietf-netconf-restconf-03

> 

> A diff from the previous version is available = at:

> http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-netconf-restconf-03

> 

> 

> 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/intern= et-drafts/

> 

> = _______________________________________________

> I-D-Announce mailing list

> I-D-Announce@ietf.org

> https://www.ietf.org/mail= man/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shado= w.html or

> ftp://ftp.ietf.org/ietf/1= shadow-sites.txt

 

_______________________________________________=

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mail= man/listinfo/netconf

------=_NextPart_000_00F1_01D00032.A173F3C0-- From nobody Fri Nov 14 17:48:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2E1A00AD; Fri, 14 Nov 2014 17:48:33 -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 SjvH31tS9Nwg; Fri, 14 Nov 2014 17:48:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041C01A00A9; Fri, 14 Nov 2014 17:48:31 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sat, 15 Nov 2014 01:48:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.239]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.239]) with mapi id 15.01.0016.006; Sat, 15 Nov 2014 01:48:09 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zero touch update Thread-Index: AQHQAHY0WDogy9sUUUCVbVxAwvNC9Q== Date: Sat, 15 Nov 2014 01:48:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(20776003)(83506001)(101416001)(36756003)(120916001)(2501002)(97736003)(86362001)(92726001)(2656002)(4396001)(50986999)(99396003)(99286002)(95666004)(110136001)(66066001)(106116001)(106356001)(40100003)(122556002)(21056001)(2351001)(46102003)(77156002)(105586002)(16236675004)(64706001)(107046002)(229853001)(54356999)(62966003)(77096003)(87936001)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D08BD4A58908Akwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nPxz76fksp50-vq_EuKx77fbKG0 Cc: Russ Mundy , Wes Hardaker , Sean Turner , "anima@ietf.org" Subject: [Netconf] zero touch update X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 01:48:34 -0000 --_000_D08BD4A58908Akwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ZeroTouch draft received a lot of valuable comments this week (thank yo= u everyone). One concern raised regards the feasibility for Vendors knowin= g which devices are owned by whom, especially in light of downstream channe= ls and resellers. The anima-bootstrapping-keyinfra resolves this by replac= ing proof of ownership with an audit log assertion, for post-incident foren= sics analysis. This approach is easy to implement, but the security assura= nce it provides is fairly low (e.g., the damage could be done before the lo= gs are reviewed). Leveraging L2 before L3 is fine, as is leveraging L1 before L2, so long as = the higher layers have equal or greater security assurances (no security do= wngrade attack). That said, our use-case of needing to support gateway de= vices connecting to 3rd-party networks precludes the use of L2, as there is= no other local device to connect to. One idea is say that the proof-of-ownership is only required for gateway de= vices connecting to remotely administered networks, so as to lower the burd= en on Vendors mentioned above with there being far fewer of these kinds of = devices. Whittling the numbers down further, we could add optional support= for NFC, so that proof-of-ownership is also not required for devices havin= g the right hardware. All this to say that the authors believe that this needs to be discussed mo= re and thus we will not likely be pushing for a WGLC in December after all. Thanks, Kent --_000_D08BD4A58908Akwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <62152BCE061A1947957BD87758C1AF83@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The ZeroTouch draft received a lot of valuable comments this week (tha= nk you everyone).  One concern raised regards the feasibility for Vend= ors knowing which devices are owned by whom, especially in light of downstr= eam channels and resellers.  The anima-bootstrapping-keyinfra resolves this by replacing proof of ownership with an audit log assertion,= for post-incident forensics analysis.  This approach is easy to imple= ment, but the security assurance it provides is fairly low (e.g., the damag= e could be done before the logs are reviewed).

Leveraging L2 before L3 is fine, as is leveraging L1 before L2, so lon= g as the higher layers have equal or greater security assurances (no securi= ty downgrade attack).   That said, our use-case of needing to support = gateway devices connecting to 3rd-party networks precludes the use of L2, as there is no other local device to con= nect to.

One idea is say that the proof-of-ownership is only required for gatew= ay devices connecting to remotely administered networks, so as to lower the= burden on Vendors mentioned above with there being far fewer of these kind= s of devices.  Whittling the numbers down further, we could add optional support for NFC, so that proof-of-owne= rship is also not required for devices having the right hardware.

All this to say that the authors believe that this needs to be discuss= ed more and thus we will not likely be pushing for a WGLC in December after= all.

Thanks,
Kent



--_000_D08BD4A58908Akwatsenjunipernet_-- From nobody Fri Nov 14 22:05:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216551A0275 for ; Fri, 14 Nov 2014 22:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 31ehPCFD7-TK for ; Fri, 14 Nov 2014 22:05:03 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491E81A19F1 for ; Fri, 14 Nov 2014 22:05:01 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id i13so12372872qae.8 for ; Fri, 14 Nov 2014 22:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mQ0wmFfELM3p0jqWdA6aquNHIBDK1594ruzdFkGhq4o=; b=CAeZkFFcx6hulEHpyec3KA5lrQIBXrFJyrKq3Zj0d/fK7Bt3BgRZxfHMphBDQ0LZ+l pW0aD6MqjmNUJ6udg0bpEkAISgfV+dlf4mKKvK2wAxS4jLrRAUaIm+nFGOL087N5dhKi DNicMORFIG/KNNX7gU+lMdrXFFat4Unnrkha28JHt0PYa5ecyKAZfmg5nVwdSPbU9FMx kDrJGj+JgpSIgVckihglVS0R+MzheM5TZ5+UW6WqF+9N5PETdnW1VLkL3cdw1E+Qw5la 9K4jxH8G32RpgW45iRHMBuRzUJ4OEshfHOye79KKLfCOPkDUIj6A1f5naTRvsS9LadJS xJNQ== MIME-Version: 1.0 X-Received: by 10.224.66.70 with SMTP id m6mr17178128qai.45.1416031501111; Fri, 14 Nov 2014 22:05:01 -0800 (PST) Received: by 10.140.151.132 with HTTP; Fri, 14 Nov 2014 22:05:01 -0800 (PST) Date: Sat, 15 Nov 2014 11:35:01 +0530 Message-ID: From: Sangita Rajankar To: Netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11c2300e9d57150507df86c8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5uoqGD9zoy4mzIWLZIDWcj6H9VE Subject: [Netconf] Pls remove my email id from your mailing list. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:05:07 -0000 --001a11c2300e9d57150507df86c8 Content-Type: text/plain; charset=UTF-8 -- *Mrs. Sangita P. Rajankar* Associate Scientist, Maharashtra Remote Sensing Applications Center (MRSAC), Nagpur - 440 011 Phone - 0712-2220086 Ext : 28 Mobile No. - 9325297336 --001a11c2300e9d57150507df86c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--
Mrs. Sangita P. Rajankar
Associate Scientist,
Maharashtra Remote Sensing Applications Center (MRSAC),
Nagpur - 440 011
Phone - 0712-2220086=C2=A0 Ext : 28
Mobile No. - 9325297336
=C2=A0
--001a11c2300e9d57150507df86c8-- From nobody Sat Nov 15 23:23:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95211A89AE for ; Sat, 15 Nov 2014 23:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ASxhAdnsrU3 for ; Sat, 15 Nov 2014 23:23:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65691A1AA7 for ; Sat, 15 Nov 2014 23:23:12 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAG7N9xr020238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Nov 2014 07:23:09 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAG7N8Ba027210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Nov 2014 08:23:09 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Sun, 16 Nov 2014 08:23:08 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: NETCONF Thread-Topic: Draft Minutes of the NETCONF session in IETF 91 Thread-Index: AdABbinK7MrVdZ4pS/edmTDzDyGoVA== Date: Sun, 16 Nov 2014 07:23:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819565F0DDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2486 X-purgate-ID: 151667::1416122589-0000437E-1E346264/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wptIO9xSe6db8IILxT0drfo-yzA Subject: [Netconf] Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 07:23:15 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819565F0DDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the draft minutes of the NETCONF session in IETF 91: http://www.ietf.org/proceedings/91/minutes/minutes-91-netconf Please send your comments to the co-chairs by November 24, 2014 EOB PT. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819565F0DDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
please find below the draft minutes of the NET= CONF session in IETF 91:
 
Please send your comments to the co-chairs by = November 24, 2014 EOB PT.
 
Cheers,
Mehmet
 
&nbs= p;
&nbs= p;
--_000_E4DE949E6CE3E34993A2FF8AE79131F819565F0DDEMUMBX005nsnin_-- From nobody Sat Nov 15 23:24:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423851A89A5; Sat, 15 Nov 2014 22:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.305 X-Spam-Level: **** X-Spam-Status: No, score=4.305 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, RP_MATCHES_RCVD=-0.594, 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 tM9_rGoOWyig; Sat, 15 Nov 2014 22:34:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3EC1A898A; Sat, 15 Nov 2014 22:34:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4732920012; Sun, 16 Nov 2014 01:36:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 71388637F5; Sun, 16 Nov 2014 01:34:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 55D0C637EA; Sun, 16 Nov 2014 01:34:11 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/t-rKAxcG5VlZOVusXWEqXAtggyQ X-Mailman-Approved-At: Sat, 15 Nov 2014 23:24:30 -0800 Cc: Russ Mundy , Wes Hardaker , Sean Turner , "netconf@ietf.org" , "anima@ietf.org" Subject: Re: [Netconf] [Anima] zero touch update X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 06:34:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Kent,=20 in the days up to Toronto, before it was clear the amount of convergence that we might get, I wrote the following email. This is intended to be a more detailed expansion of the certificates= =20 used in draft-pritikin-anima-bootstrapping-keyinfra-00. =20=20=20=20=20=20 It could be that the MASA provides the certificates online,=20 at deployment time, but the goal was to provide a system which could be used entirely offline, and then let parts of it go online as desired. Easier to go this way than the other way. draft-richardson-6tisch-idevid-cert-00 describes a RFC3779-like extension. the email is: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5y= qfRm0n00 this is what I imagine. I will perhaps put this into an appendix. Please remmeber that this comes from 6tisch, which anticipates deployment into industrial settings (Oil refineries, chemical plants, etc.), and while I've made up some semi-consumer oriented things here, we imagine something involving industrial consortia. I don't pretend that this is at all useful for other scenarioes due to lack of a high-enough margin for the supply cha= in to care about such things.=20 (I guess the Coyote Plant should have been in New Mexico) =3D=3D=3D=3D To make it easier to explain, and talk about, I'm going to give some names. Factory: ACME National-VAR: Cadabra Regional-Var: Sesame Plant: Coyote So, the manager (Wiley) at the Coyote Plant, has just received 1000 new (wireless) Road-Runner Detector, and plans to spread them along the highway. The detectors are IDevID 210001 through 210999. Each Detector has an 802.1AR certificate pre-installed that looks like: Issuer: C=3DUS, ST=3DNew Jersey, L=3DFairfield, O=3DACME Rocket-Powered Products, OU=3DSensor-Network-Division Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: CN=3Droadrunner210001 Data: Serial Number: 21:00:01 Subject Public Key Info: ... {this is the proof of identity certificate} When ACME Factory's Sensor Netowrk Division ships 100 crates of sensors to Cadabra, it issues a certificate: Issuer: C=3DUS, ST=3DNew Jersey, L=3DFairfield, O=3DACME Rocket-Powered Products, OU=3DSensor-Network-Division Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS,ST=3DWashington,L=3DSeattle,O=3DCadabra,OU=3DLogist= ics RFC3779-Like-Extension: Range(210000, 219999) When Cadabra ships cases 1-20 to Sesame, it issues a certificate: Issuer: C=3DUS,ST=3DWashington,L=3DSeattle,O=3DCadabra,OU=3DLogisti= cs Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS, ST=3DArkansus, L=3DBentonville, O=3DSesame Bix Box Retail, OU=3DSmall Stuff Distribution RFC3779-Like-Extension: Range(210000, 211999) When Coyote Inc buys those 10 boxes of 100 sensors, the bill of sale includes: Issuer: C=3DUS, ST=3DArkansus, L=3DBentonville, O=3DSesame Bix Box Retail, OU=3DSmall Stuff Distribution Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS, ST=3DNevada, L=3DTonopah, O=3DCoyote Inc, OU=3DSupper RFC3779-Like-Extension: Range(210000, 210099) RFC3779-Like-Extension: Range(210200, 210299) RFC3779-Like-Extension: Range(210400, 210499) RFC3779-Like-Extension: Range(210600, 210699) RFC3779-Like-Extension: Range(210800, 210899) RFC3779-Like-Extension: Range(211000, 211099) RFC3779-Like-Extension: Range(211200, 211299) RFC3779-Like-Extension: Range(211600, 211699) RFC3779-Like-Extension: Range(211800, 211899) (cause, a shipper sent them every other box, the ranges are not contiguous) The mote/sensor when it sees this certificate, can verity that it's DevID is in the range, and therefore knows that it has found the right network. Should Coyote find that they had too many, they can sell some of these sensors to Sheepdog Sam Inc, by issuing a certificate: Issuer: C=3DUS, ST=3DNevada, L=3DTonopah, O=3DCoyote Inc, OU=3DSupper Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DGB, ST=3DScotland, L=3DEdinburgh, O=3DSheepsRUs, OU=3DSheepdog RFC3779-Like-Extension: Range(210050, 210099) RFC3779-Like-Extension: Range(211611, 211623) of course, since Coyote actually still has a valid certificate, all parties would be advised to use the Enrollment over Secure Transport or an API into 802.1AR, to put an operational certificate in place. Getting back to factory default might be impossible (WirelessHart does this, I think), or at least, will wipe the private key associated with the new certificate from the device. BTW: the extension is likely about 20 bytes base, with 5 bytes per IDEVID. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGhFX4CLcPvd0N1lAQIjpAgAmLsziM4blxyDpMiVwagWiPjokxVp+Aoy iuXodKKUPLFoV3Ak69H+dGP9KtUhezmEIen/a8Sxoj9+li3oWmJ0O4x8a/klInHd c4VTBHJ8Bd4p8k6wJZG2NtDEXaVhubABzih6Lno4wcHw0xECn4SKNI9KkGETihoY D1xbhshwJZgmTAmiaVKkkQNgcIHMM/HnhgAv0JxF+0+bhlg7FpYVuKdjZdOzUqBT Ef4zWoDX0+1vmD1mi5h3tlQ8KuPqP1tUFU55xH+8A51Z6WjuwUPBYZDF58UpFNPE GUyg5Z4cZLJXoljN4wJL6AZ6A5JWxdNdd9/jwvjqqKC1o7+RvYtfkA== =NQ3M -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 15 23:24:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09FF1A89A6; Sat, 15 Nov 2014 22:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 Z02fZ_QjCFrx; Sat, 15 Nov 2014 22:35:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E271A89A5; Sat, 15 Nov 2014 22:35:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E91C120012; Sun, 16 Nov 2014 01:37:40 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3D39D637F4; Sun, 16 Nov 2014 01:35:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 26102637EA; Sun, 16 Nov 2014 01:35:21 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/StiGZVf1kG4dOH6anSYzGJG6KWU X-Mailman-Approved-At: Sat, 15 Nov 2014 23:24:31 -0800 Cc: Russ Mundy , Wes Hardaker , Sean Turner , "netconf@ietf.org" , "anima@ietf.org" Subject: Re: [Netconf] [Anima] zero touch update X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 06:35:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > The ZeroTouch draft received a lot of valuable comments this week > (thank you everyone). One concern raised regards the feasibility for > Vendors knowing which devices are owned by whom, especially in light = of > downstream channels and resellers. The anima-bootstrapping-keyinfra I should have been clear that it was the mention of channels and resellers that made me send the previous email with the RoadRunner/Coyote inspired example. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGhFpYCLcPvd0N1lAQKcswf/UVjy6k+3NDwGkNRcdYJxMbaF1D3YaqIc 8vFWM1aIkg4U8bL29ssD3u6uuHPjaiLUupsiCx7ZXWWhDgcuvIkiDiZ6N92PxTh/ ZQdpSQTVfcaUk8CGBqlaQXQTJS2BjGllTQbtN1YUg2aWe0vP6tmgXUNrQJQ3mMaV 6q0KyJrUod0Y04zP1aIGYpboHKWSD2gfMDaPKLcU0D/XcwSzyaq0KdnXo6uKqjRN 4drrTsu+8a7JVqGor5HY6pedD2D0SmNDF9ct4f7+xcFifmuz7vWK+R0RuRTUJt5n fHHfrkTn3B10nuPUqsDJi/lNwGR4N7VD5fSOQj7DIBPfZbcqhagNFg== =Cs14 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 16 13:17:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FCC1A1A9A for ; Sun, 16 Nov 2014 13:17:09 -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_29=0.6, 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 D0esOIZq0g_h for ; Sun, 16 Nov 2014 13:16:59 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3461A1A69 for ; Sun, 16 Nov 2014 13:16:59 -0800 (PST) Received: from BY2PR05CA032.namprd05.prod.outlook.com (10.141.250.22) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sun, 16 Nov 2014 21:16:36 +0000 Received: from BL2FFO11FD029.protection.gbl (2a01:111:f400:7c09::196) by BY2PR05CA032.outlook.office365.com (2a01:111:e400:2c5f::22) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Sun, 16 Nov 2014 21:16:36 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD029.mail.protection.outlook.com (10.173.160.69) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Sun, 16 Nov 2014 21:16:34 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 16 Nov 2014 13:16:33 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sAGLGVR10605; Sun, 16 Nov 2014 13:16:32 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sAGLGH7A060673; Sun, 16 Nov 2014 16:16:18 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201411162116.sAGLGH7A060673@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20141112.184427.21336884.mbj@tail-f.com> Date: Sun, 16 Nov 2014 16:16:17 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(54094003)(164054003)(51704005)(199003)(189002)(92566001)(92726001)(31966008)(64706001)(47776003)(20776003)(105596002)(81156004)(21056001)(77156002)(106466001)(62966003)(95666004)(107046002)(110136001)(76506005)(102836001)(99396003)(103666002)(53416004)(84676001)(120916001)(50466002)(69596002)(4396001)(48376002)(68736004)(6806004)(97736003)(86362001)(46102003)(87936001)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; H:P-EMF03-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Forefront-PRVS: 039735BC4E Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8YGz8XTU2MBORPgQOxFIXxSkUgI Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 21:17:10 -0000 Martin Bjorklund writes: >> For this purpose, a YANG extension is worthless. >> Only a grouping provides the reusable definitions without >> hacking or copying. > >Well, you can certainly have both: > > grouping errors { ... } > > rc:structure error { > uses errors; > } And they are distinct uses; groupings is used to reusability, where rc:structure would be used for, well, whatever the extension defines it as being used for. My objection is that an existing mechanism (groupings) is being repurposed in a way that it wasn't used for. My question was "would we be upset if another working group had done this?". Also I wonder if we'll hear "I though groupings were used to define protocol messages" ;^) Thanks, Phil From nobody Sun Nov 16 13:27:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41821A1AFC for ; Sun, 16 Nov 2014 13:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 p4paaxA2dhLR for ; Sun, 16 Nov 2014 13:27:25 -0800 (PST) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7231A1A6A for ; Sun, 16 Nov 2014 13:27:25 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id q107so14359481qgd.31 for ; Sun, 16 Nov 2014 13:27:24 -0800 (PST) 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=PXXBgXzO1uAwEg/FhTD+Q3gkQYfbAa5ijyKtS/ifBP4=; b=XkoOeqbfro8ofJxO3ZNVoKZ9giuTPeoeOD+yykp1Ig/MgdPPatJB+J+I2n2FoNzooL wqw7xKwpd+uKd5q5y1lsz/LIV2erOQahn6h7gOA6oTsP/B4Nynohc1d2duabMy39nv98 KChafQSbMUFD53xgjbc4Qkfp7B6KCm4HadcjZLTlpIaaXO6bDNl/LKVzJ/zVmmz74B3z StnuLeHb5hOlX5w6knzla5V1b1VNUbEC4EiTKkxAREYae5XVLoj5PPELWYeZGkp3tyWZ xe4g9DZOOcKXBAswjelkg7lvYrahVrXuDc+bSr3R+2exxNqhnkc/cuC0wmuhWry/3zfX YdCg== X-Gm-Message-State: ALoCoQmGTHLS1OeLT+TiOL8naTrGNTXGGrF3Oo/Nvzb7S95S2Ji6wWEH3419pVKQc7cCYHoj+6fw MIME-Version: 1.0 X-Received: by 10.229.105.196 with SMTP id u4mr28869205qco.27.1416173244739; Sun, 16 Nov 2014 13:27:24 -0800 (PST) Received: by 10.140.37.52 with HTTP; Sun, 16 Nov 2014 13:27:24 -0800 (PST) In-Reply-To: <201411162116.sAGLGH7A060673@idle.juniper.net> References: <20141112.184427.21336884.mbj@tail-f.com> <201411162116.sAGLGH7A060673@idle.juniper.net> Date: Sun, 16 Nov 2014 13:27:24 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xrZB4mC3wjlQGnLzlPBNwmV4Pzw Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 21:27:27 -0000 On Sun, Nov 16, 2014 at 1:16 PM, Phil Shafer wrote: > Martin Bjorklund writes: >>> For this purpose, a YANG extension is worthless. >>> Only a grouping provides the reusable definitions without >>> hacking or copying. >> >>Well, you can certainly have both: >> >> grouping errors { ... } >> >> rc:structure error { >> uses errors; >> } > > And they are distinct uses; groupings is used to reusability, where > rc:structure would be used for, well, whatever the extension defines > it as being used for. > > My objection is that an existing mechanism (groupings) is being > repurposed in a way that it wasn't used for. My question was "would > we be upset if another working group had done this?". > I would hope we would listen to their reasons first and try to find out why YANG is being extended to represent reusable data structures, including CLI parameters, log files, audit files, and protocol messages. > Also I wonder if we'll hear "I though groupings were used to > define protocol messages" ;^) too late for that -- already being done (YANG-ification has started. ;-) You shouldn't of helped create a DML with the best balance of readability and automation features ever created :-) > > Thanks, > Phil Andy From nobody Sun Nov 16 13:39:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6FE1A1A8D for ; Sun, 16 Nov 2014 13:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 vl3Gx2PhE5wl for ; Sun, 16 Nov 2014 13:39:18 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4E81A1B48 for ; Sun, 16 Nov 2014 13:39:18 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so2887944qab.16 for ; Sun, 16 Nov 2014 13:39:17 -0800 (PST) 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=MjMiybVA/BXU/TgaT7jqo9eAqAdR6gKmP6yIR68Coqo=; b=CJA7bqZdo5CHjukB750MLoM0XYZriincLB0Ur3/JH9U05DCrHEeCjuJMEK9ycjIYQn 26w/GrDmzt2ZHt9JIcH+s6P3yu/7ByzV2aud4q/rJTQ6xsX8k3VHZms7F6tMwst6LK8k tgPiNmlGKjXP+6iLqy2jgJF5jnbfN0pWWVrbtMQ9NJSK1IyowCXTPu30FGo7bDsiBKku g2P5cqOrkyceASbqkXDKKfzx8mkdu+/+Ma3rqeB+S+tiA+XoDi55Wk+WpyhnC6ZKtTQD hpdO11Z5g+KSC2u40MrgeAzlyyHurRwSeDrZeFFLzEh/a7k1CcrASKIGrXfQ6RH3HTen jwCQ== X-Gm-Message-State: ALoCoQmqIaz8qDUJeF/CFk2ZWMIb6I3KdO3DCNB1SIV9PWPZKz+ud27pLvd3lEzU4WVB2UjRwmJL MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr28656645qgd.36.1416173957883; Sun, 16 Nov 2014 13:39:17 -0800 (PST) Received: by 10.140.37.52 with HTTP; Sun, 16 Nov 2014 13:39:17 -0800 (PST) In-Reply-To: <201411162116.sAGLGH7A060673@idle.juniper.net> References: <20141112.184427.21336884.mbj@tail-f.com> <201411162116.sAGLGH7A060673@idle.juniper.net> Date: Sun, 16 Nov 2014 13:39:17 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/we1zrrmKHCGrFL30qDBtnrzQMBw Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 21:39:20 -0000 On Sun, Nov 16, 2014 at 1:16 PM, Phil Shafer wrote: > Martin Bjorklund writes: >>> For this purpose, a YANG extension is worthless. >>> Only a grouping provides the reusable definitions without >>> hacking or copying. >> >>Well, you can certainly have both: >> >> grouping errors { ... } >> >> rc:structure error { >> uses errors; >> } > > And they are distinct uses; groupings is used to reusability, where > rc:structure would be used for, well, whatever the extension defines > it as being used for. > > My objection is that an existing mechanism (groupings) is being > repurposed in a way that it wasn't used for. My question was "would > we be upset if another working group had done this?". > We wanted to provide a normative syntax and description that is encoding-independent, which also supports the specific XML and JSON encoding requirements for NETCONF and RESTCONF. (CoMI will define a YANG to CBOR encoding, so the list will grow...) This is going to be a real popular thing to do.... > Also I wonder if we'll hear "I though groupings were used to > define protocol messages" ;^) > > Thanks, > Phil Andy From nobody Sun Nov 16 13:42:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18FE1A1A8D for ; Sun, 16 Nov 2014 13:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594, 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 2TicaHenIkQD for ; Sun, 16 Nov 2014 13:42:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 01F371A0037 for ; Sun, 16 Nov 2014 13:42:29 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 118161280A11; Sun, 16 Nov 2014 22:42:28 +0100 (CET) Date: Sun, 16 Nov 2014 22:42:10 +0100 (CET) Message-Id: <20141116.224210.1003561071133220572.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20141112.184427.21336884.mbj@tail-f.com> <201411162116.sAGLGH7A060673@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bhycHDGIHZXoPMFS0APp20XhlFE Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 21:42:30 -0000 Andy Bierman wrote: > On Sun, Nov 16, 2014 at 1:16 PM, Phil Shafer wrote: > > Martin Bjorklund writes: > >>> For this purpose, a YANG extension is worthless. > >>> Only a grouping provides the reusable definitions without > >>> hacking or copying. > >> > >>Well, you can certainly have both: > >> > >> grouping errors { ... } > >> > >> rc:structure error { > >> uses errors; > >> } > > > > And they are distinct uses; groupings is used to reusability, where > > rc:structure would be used for, well, whatever the extension defines > > it as being used for. > > > > My objection is that an existing mechanism (groupings) is being > > repurposed in a way that it wasn't used for. My question was "would > > we be upset if another working group had done this?". > > > > We wanted to provide a normative syntax and description that > is encoding-independent, which also supports the specific > XML and JSON encoding requirements for NETCONF and RESTCONF. > (CoMI will define a YANG to CBOR encoding, so the list will grow...) > > This is going to be a real popular thing to do.... If we beleive this is going to be used more and more, I think we should define a proper statement for this. At least as an extension. /martin From nobody Sun Nov 16 14:32:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F21A1B7E for ; Sun, 16 Nov 2014 14:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 isBjNY_8GI_j for ; Sun, 16 Nov 2014 14:31:42 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDD91A1B73 for ; Sun, 16 Nov 2014 14:31:41 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so817043qcv.8 for ; Sun, 16 Nov 2014 14:31:41 -0800 (PST) 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=2GSYCGConS8wQAw5JHcEOZ/iKZapvqciIC8tgn7cLsU=; b=EFcW4hTVFxZmuW4BeV60GFZafmY1ByKU4NcOH7tr+lVUIbcYFbexKnJvS3M+yFj5t+ j6eQOeY+Z+EOlMiZ9awtWRuasHognE2lIFFU5fIAqXXG3oxK/ykWBpNijeIE20noD+0H oHzMeknEkpo3cRbCDFwwGI4sR7DIa3K30ALbWqTf1BvPmZlBvtR9obll0o1wONEp+Wal M7OCKywt0Ow4SO5udfmY7F0RNK6d4qnSU1GCFI6MgKHdrqoWmRIuZlU/VnLAiqqZ+xof jyumlPPut6kAtLw38PlYikDL0FEMKPseQt8kTJfN67Mvl7c6MmPPblc2fVY9BtG/l3f5 uTPQ== X-Gm-Message-State: ALoCoQkQpmfLAOPoAtC0ZRagtMKkJJ2tErnLiflYlqGBTpYUQxtmXP5fYv3zOcCosXpVhs19ShzD MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr16555313qas.99.1416177101137; Sun, 16 Nov 2014 14:31:41 -0800 (PST) Received: by 10.140.37.52 with HTTP; Sun, 16 Nov 2014 14:31:41 -0800 (PST) In-Reply-To: <20141116.224210.1003561071133220572.mbj@tail-f.com> References: <20141112.184427.21336884.mbj@tail-f.com> <201411162116.sAGLGH7A060673@idle.juniper.net> <20141116.224210.1003561071133220572.mbj@tail-f.com> Date: Sun, 16 Nov 2014 14:31:41 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KB3JIRjQK8ypKFBTk8YDnBugVfg Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 22:31:43 -0000 On Sun, Nov 16, 2014 at 1:42 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Sun, Nov 16, 2014 at 1:16 PM, Phil Shafer wrote: >> > Martin Bjorklund writes: >> >>> For this purpose, a YANG extension is worthless. >> >>> Only a grouping provides the reusable definitions without >> >>> hacking or copying. >> >> >> >>Well, you can certainly have both: >> >> >> >> grouping errors { ... } >> >> >> >> rc:structure error { >> >> uses errors; >> >> } >> > >> > And they are distinct uses; groupings is used to reusability, where >> > rc:structure would be used for, well, whatever the extension defines >> > it as being used for. >> > >> > My objection is that an existing mechanism (groupings) is being >> > repurposed in a way that it wasn't used for. My question was "would >> > we be upset if another working group had done this?". >> > >> >> We wanted to provide a normative syntax and description that >> is encoding-independent, which also supports the specific >> XML and JSON encoding requirements for NETCONF and RESTCONF. >> (CoMI will define a YANG to CBOR encoding, so the list will grow...) >> >> This is going to be a real popular thing to do.... > > If we beleive this is going to be used more and more, I think we > should define a proper statement for this. At least as an extension. > I prefer a real statement in YANG 1.1. There is already an "anyxml + extensions" based solution available in YANG 1.0. I would like it cover the following use-cases: 1) template for YANG document root ( or element) 2) template for a container for a specific node type 3) template for a container that has an "instance wrapper" list for instances from 1 or more 'contexts' (e.g YANG mount server instance) 4) template for an abstract reusable data structure (te.g. ietf-restconf) IMO, solution Y34-04 should be extended to support (2 - 4) > > /martin Andy From nobody Mon Nov 17 00:09:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00C1A026C for ; Mon, 17 Nov 2014 00:09:56 -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 IusLgicCheSS for ; Mon, 17 Nov 2014 00:09:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9B71A0373 for ; Mon, 17 Nov 2014 00:09:54 -0800 (PST) Received: from BLUPR05CA0043.namprd05.prod.outlook.com (10.141.20.13) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 17 Nov 2014 08:09:53 +0000 Received: from BL2FFO11FD055.protection.gbl (2a01:111:f400:7c09::131) by BLUPR05CA0043.outlook.office365.com (2a01:111:e400:855::13) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Mon, 17 Nov 2014 08:09:52 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD055.mail.protection.outlook.com (10.173.161.183) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Mon, 17 Nov 2014 08:09:52 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 17 Nov 2014 00:09:51 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sAH89nR15229; Mon, 17 Nov 2014 00:09:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sAH89YWk063551; Mon, 17 Nov 2014 03:09:35 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201411170809.sAH89YWk063551@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 17 Nov 2014 03:09:34 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(199003)(189002)(31966008)(95666004)(20776003)(64706001)(47776003)(92566001)(92726001)(81156004)(77156002)(21056001)(106466001)(62966003)(76506005)(107046002)(105596002)(110136001)(102836001)(99396003)(103666002)(53416004)(84676001)(120916001)(50466002)(69596002)(68736004)(4396001)(48376002)(6806004)(97736003)(44976005)(86362001)(46102003)(50986999)(87936001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; H:P-EMF03-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Forefront-PRVS: 03982FDC1D Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Rbp0jjvRj5ODiumaEdojqKbsWrQ Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 08:09:56 -0000 Andy Bierman writes: >We wanted to provide a normative syntax and description that >is encoding-independent, which also supports the specific >XML and JSON encoding requirements for NETCONF and RESTCONF. >(CoMI will define a YANG to CBOR encoding, so the list will grow...) > >This is going to be a real popular thing to do.... Then it's even more important that we do it right. Is there any objection to defining an extension suitable to this purpose? I strongly oject to repurposing groupings for this. It's a bad precendent. Thanks, Phil From nobody Mon Nov 17 00:13:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72DF1A0373 for ; Mon, 17 Nov 2014 00:13: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 M8h5iT5mhQBm for ; Mon, 17 Nov 2014 00:13:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:738]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01EE1A026C for ; Mon, 17 Nov 2014 00:13:31 -0800 (PST) Received: from BLUPR05CA0064.namprd05.prod.outlook.com (10.141.20.34) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 17 Nov 2014 08:13:08 +0000 Received: from BL2FFO11FD041.protection.gbl (2a01:111:f400:7c09::161) by BLUPR05CA0064.outlook.office365.com (2a01:111:e400:855::34) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Mon, 17 Nov 2014 08:13:08 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD041.mail.protection.outlook.com (10.173.161.137) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Mon, 17 Nov 2014 08:13:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 17 Nov 2014 00:13:06 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sAH8D4R19657; Mon, 17 Nov 2014 00:13:05 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sAH8Cpv0063611; Mon, 17 Nov 2014 03:12:51 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201411170812.sAH8Cpv0063611@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 17 Nov 2014 03:12:51 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(103666002)(107046002)(87936001)(53416004)(54356999)(105596002)(95666004)(102836001)(81156004)(106466001)(86362001)(69596002)(68736004)(31966008)(92566001)(46102003)(84676001)(92726001)(50986999)(110136001)(99396003)(6806004)(44976005)(120916001)(76506005)(21056001)(48376002)(20776003)(558084003)(62966003)(97736003)(47776003)(50466002)(4396001)(77156002)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:P-EMF03-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-Forefront-PRVS: 03982FDC1D X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hJc9U2WGCr8yZG9AxUCF7YipOlQ Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 08:13:34 -0000 Andy Bierman writes: >I prefer a real statement in YANG 1.1. There is already an >"anyxml + extensions" based solution available in YANG 1.0. This is also a bad precendent. If everyone thinks their new module requires a new version of YANG, we're DOA. Thanks, Phil From nobody Mon Nov 17 00:35:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38601A044D for ; Mon, 17 Nov 2014 00:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] 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 iEPuTD0y1ap4 for ; Mon, 17 Nov 2014 00:35: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 849B51A03A5 for ; Mon, 17 Nov 2014 00:35:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D30CB8D2; Mon, 17 Nov 2014 09:35: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 jqIEEPFEK3fz; Mon, 17 Nov 2014 09:35: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; Mon, 17 Nov 2014 09:35:52 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C81E22002C; Mon, 17 Nov 2014 09:35:51 +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 Jguv9_urOqb6; Mon, 17 Nov 2014 09:35:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73F9320013; Mon, 17 Nov 2014 09:35:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D16D32F878EF; Mon, 17 Nov 2014 09:35:47 +0100 (CET) Date: Mon, 17 Nov 2014 09:35:47 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141117083547.GA77961@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf References: <20141112.184427.21336884.mbj@tail-f.com> <201411162116.sAGLGH7A060673@idle.juniper.net> <20141116.224210.1003561071133220572.mbj@tail-f.com> 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: http://mailarchive.ietf.org/arch/msg/netconf/bB9_AxIK-4iNwzPivU91lcyrcjc Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 08:35:57 -0000 On Sun, Nov 16, 2014 at 02:31:41PM -0800, Andy Bierman wrote: > On Sun, Nov 16, 2014 at 1:42 PM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Sun, Nov 16, 2014 at 1:16 PM, Phil Shafer wrote: > >> > Martin Bjorklund writes: > >> >>> For this purpose, a YANG extension is worthless. > >> >>> Only a grouping provides the reusable definitions without > >> >>> hacking or copying. > >> >> > >> >>Well, you can certainly have both: > >> >> > >> >> grouping errors { ... } > >> >> > >> >> rc:structure error { > >> >> uses errors; > >> >> } > >> > > >> > And they are distinct uses; groupings is used to reusability, where > >> > rc:structure would be used for, well, whatever the extension defines > >> > it as being used for. > >> > > >> > My objection is that an existing mechanism (groupings) is being > >> > repurposed in a way that it wasn't used for. My question was "would > >> > we be upset if another working group had done this?". > >> > > >> > >> We wanted to provide a normative syntax and description that > >> is encoding-independent, which also supports the specific > >> XML and JSON encoding requirements for NETCONF and RESTCONF. > >> (CoMI will define a YANG to CBOR encoding, so the list will grow...) > >> > >> This is going to be a real popular thing to do.... > > > > If we beleive this is going to be used more and more, I think we > > should define a proper statement for this. At least as an extension. > > > > I prefer a real statement in YANG 1.1. There is already an > "anyxml + extensions" based solution available in YANG 1.0. YANG 1.1 is not supposed to become a kitchen sink. What can be done using extensions should be done using extensions. Note that such a 'structure' extension would have to answer what all the bits and pieces that are bound to the notion of datastores mean, config true/falls, must and when expressions, ... (it could be that many of these things would not mean anything but even that would have to be defined). /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 Nov 17 00:40:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32961A19F1 for ; Mon, 17 Nov 2014 00:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594, 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 EfEG6K-zXebp for ; Mon, 17 Nov 2014 00:40:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 649581A19ED for ; Mon, 17 Nov 2014 00:40:51 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EDB61280996; Mon, 17 Nov 2014 09:40:50 +0100 (CET) Date: Mon, 17 Nov 2014 09:40:50 +0100 (CET) Message-Id: <20141117.094050.1937205918333798539.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201411170812.sAH8Cpv0063611@idle.juniper.net> References: <201411170812.sAH8Cpv0063611@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/f6qzAUAiZBhWKjL8eAGcVApHMtE Cc: netconf@ietf.org Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 08:40:53 -0000 Phil Shafer wrote: > Andy Bierman writes: > >I prefer a real statement in YANG 1.1. There is already an > >"anyxml + extensions" based solution available in YANG 1.0. > > This is also a bad precendent. If everyone thinks their new module > requires a new version of YANG, we're DOA. Well, we *are* doing YANG 1.1 now so we do have an opportunity to get it right (if adding it is right...) For this particular statement, having it as a builtin YANG statement has one advantage - we can use 'augment' on the resulting structure: If we do it as an extension: module my-module { ... rc:structure my-structure { ... } } normal augment cannot be used: augment /my:my-structure { // won't work! ... } An alternative could be to mark the extension as introducing an augmentable node: extension structure { augmentable true; // new statement! ... } /martin From nobody Mon Nov 17 01:05:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F161A1A07 for ; Mon, 17 Nov 2014 01:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 GyEEynHADJRR for ; Mon, 17 Nov 2014 01:05:40 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7811A1A10 for ; Mon, 17 Nov 2014 01:05:40 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so4119628qcx.13 for ; Mon, 17 Nov 2014 01:05:39 -0800 (PST) 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=N8h/DfkzLyLqefwDNT2ve6v9R18qMvm1ZyWLPxlltsY=; b=ULvuH7ZHA15lzgSgVtAmR0tDPp7ZA5y3fMic3EJDVPVAX5s7QGtcTFWw/np6RqRVmh iNVmIRgVMqoNCwRJawNKh8f5+xMSugsTu+5GA6gjauEaabHDIDXgEfTfVY7DtWAe7CPh znr6XwbmK0f3R6NusWr2zWY+thon8QMVQKpJ2IIdla1lAKnrXBjZiEHTkv0cbjRdooyO zb9bmNF86IdIMl+9TIohbPpEe5eiRxeXNGLuHgpAoBh1mae518Kx2zS8CBHhncunLD74 cdyArEokQo2FD1yjfxr/r3mSrmwiLXawA7T2nBHXqlzDscRdB7z0rg9bY7UzmVJPGjSw OYVg== X-Gm-Message-State: ALoCoQmL7n4VFDaxNefoJqPUKg6e+q5bhKnhp2+nB4JWt48oUl4atcQnc2wLZ8P6CQ+EMcmH14VN MIME-Version: 1.0 X-Received: by 10.224.132.70 with SMTP id a6mr32929237qat.16.1416215139592; Mon, 17 Nov 2014 01:05:39 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 01:05:39 -0800 (PST) In-Reply-To: <201411170812.sAH8Cpv0063611@idle.juniper.net> References: <201411170812.sAH8Cpv0063611@idle.juniper.net> Date: Mon, 17 Nov 2014 01:05:39 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XUsr-BHnfIaKkrZyRnPdgHChxxo Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 09:05:42 -0000 On Mon, Nov 17, 2014 at 12:12 AM, Phil Shafer wrote: > Andy Bierman writes: >>I prefer a real statement in YANG 1.1. There is already an >>"anyxml + extensions" based solution available in YANG 1.0. > > This is also a bad precendent. If everyone thinks their new module > requires a new version of YANG, we're DOA. > It's hard to even respond to a strawman comment like this. I suppose OpenDaylight will stop using YANG as an IDL know they have been properly educated on the use of YANG... Anyxml is unconstrained. Any proper YANG tool will accept anyxml and the tools that know the extension will check the refinement indicated by the extension. YANG will continue to be used for templates even if they are moved to private modules and ignored in IETF modules. > Thanks, > Phil Andy From nobody Mon Nov 17 09:40:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBB1A0242 for ; Mon, 17 Nov 2014 09:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 F-8it6QrUqge for ; Mon, 17 Nov 2014 09:40:49 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DB21A005F for ; Mon, 17 Nov 2014 09:40:47 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id dc16so227502qab.11 for ; Mon, 17 Nov 2014 09:40:46 -0800 (PST) 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=tm4JTojfZSGYdY8j5e8z6SPPy6vaW1rSNtcdVhL2wqw=; b=e04HKd3XPynVNj4lJh0xOldso98qvb110tucj98xdoHHXQW96ivtBiAjOr1h/xPp2k VzOEikZh6QRpwNsxab/qyB+h9eFfOGcCrg6LRkDAIL50xrle0TdxRzxP8QXY6WWvWn6H I/JSZm4yKnVpBcxDFByKYFEopl508GduDvgK1SE2GXzVbAik7n9RXp0CsAYiQm9caTQw 7V7rPquXkaky+qxltYAlQ/romozh03VtduKZe4PN2EgAJJxmDb+T6SauKOhyoZ/1K0vZ dQyxNUDW9gNlhDnONKWTpVfFXm8jIVT3UZFPTzutwRshx9D+DAsQ6MZeeWugDdQSXcoK XngQ== X-Gm-Message-State: ALoCoQku8iSncQ2VB2MjXVZVNrbHT+KTzS4Mfygx85LXD1GWJeaeoopHA1TJtvYDCzywlzJYm+f2 MIME-Version: 1.0 X-Received: by 10.224.12.14 with SMTP id v14mr2297746qav.88.1416246046826; Mon, 17 Nov 2014 09:40:46 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 09:40:46 -0800 (PST) In-Reply-To: <201411170809.sAH89YWk063551@idle.juniper.net> References: <201411170809.sAH89YWk063551@idle.juniper.net> Date: Mon, 17 Nov 2014 09:40:46 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uSOizISIcqj-b9ztSvbEMMBBooI Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 17:40:50 -0000 On Mon, Nov 17, 2014 at 12:09 AM, Phil Shafer wrote: > Andy Bierman writes: >>We wanted to provide a normative syntax and description that >>is encoding-independent, which also supports the specific >>XML and JSON encoding requirements for NETCONF and RESTCONF. >>(CoMI will define a YANG to CBOR encoding, so the list will grow...) >> >>This is going to be a real popular thing to do.... > > Then it's even more important that we do it right. Is there > any objection to defining an extension suitable to this purpose? > How about this: module ietf-restconf { extension structure { ... Martin provided ext. def } // keep all groupings rc:structure errors { uses errors; } rc:structure restconf { uses restconf; } } This will use the groupings in this module and let them be reusable in external modules. As Martin said there is nothing invalid about defining a grouping for external reuse. Any XPath can all be relative to the grouping, so it is reusable as well. The extension provides a module namespace binding to make Lada happy. We can reference specific structure statements in the normative text instead of copying lots of text about XML and JSON encoding rules. Andy > I strongly oject to repurposing groupings for this. It's > a bad precendent. > > Thanks, > Phil From nobody Mon Nov 17 16:58:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97F1AD024 for ; Mon, 17 Nov 2014 16:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 na_27OHo6Ojx for ; Mon, 17 Nov 2014 16:58:53 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F451AD023 for ; Mon, 17 Nov 2014 16:58:52 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id n8so15582908qaq.12 for ; Mon, 17 Nov 2014 16:58:52 -0800 (PST) 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 :content-type; bh=6L8XJpacOkHtyhVcERovtMZdD+oDijs98eO3lYrJZQI=; b=BVhvJeRmXBZb+Jvyv/MeqrMz9CJVdOLwinekYBWSbmugeyGi4AMACVWSxp4VeXvtGb Kbp0lBBkgwVvUPU6UhJSNr3l3xlmA9tR79mPSdcfIxw+MEXAbyap6BtKGrWTHw7oBxVJ oP9AxvG1A7ttTo0ERMBbHwfzwF+V9rxiMqhuDYaqmDK+Ql9Kgu2hZ7F6pqm5WecE68Qt +1IDTPtuR4GYHTKEjE8LFY4lmXm1YG8h4QdqL6L/dN4b7m10vV5jiE17p58JtMT+HPrj IBmcSGe6CNKRASisCjSnydaBWSpp41IH3smngxQcXiB+2qRvk4vMgmXrOaTVdSWi3PSK HNxg== X-Gm-Message-State: ALoCoQn6zR2JcmVMVvp+IMuyVa+RAyPjLdoZW4zJ0FeBy01Vyb58CGnSaKXLbYDh3XfT2XYxyI0X MIME-Version: 1.0 X-Received: by 10.224.125.66 with SMTP id x2mr39753921qar.78.1416272332126; Mon, 17 Nov 2014 16:58:52 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 16:58:52 -0800 (PST) Date: Mon, 17 Nov 2014 16:58:52 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ovj6m0AaG4Ed-seiQ4i92zkPTCU Subject: [Netconf] RESTCONF #5: protocol capability URIs (move to CLOSED) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 00:58:55 -0000 Hi The following issue has been addressed and the proposed resolution is in draft-ietf-netconf-restconf-03.txt. https://github.com/netconf-wg/restconf/issues/5 No objections to the updated text have been received so this issue will be closed. Andy From nobody Mon Nov 17 16:59:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2011AD023 for ; Mon, 17 Nov 2014 16:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 AZVf4Q1UM4Rb for ; Mon, 17 Nov 2014 16:59:18 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749781AD032 for ; Mon, 17 Nov 2014 16:59:15 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so3676544qcx.3 for ; Mon, 17 Nov 2014 16:59:14 -0800 (PST) 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 :content-type; bh=oI3QVqfWem8yJJpZlZ2Gw/6MaiCw+KSaE5I8nZu0zaM=; b=V6fyvI0QPUy0clSivNcoX9u8E01KyGNI5idvephA+T5DQ5QV+9/5TL0R804Sr6pgE0 f/KCLhQ2M9+en2VzcuFzje8R4S4hsKWvA7h2LAMr9u2luSmfFYkPCbIRPRaEOCHTVCm4 4KYQRyYg9T8naErOaNP983tc/0qo3Yesc0HJbOXqHsSrhMNyT0/dsYFHi1O6by4InCxH ezR8ogVTEQFLqLJgG6Ct9qpCg0XQMEQm76eDsRdgfzvdplRSucUmT+/O5oyFv/MUfnY9 mEz6rW/bZ3H8SlNcvcwSa6hFZD46JM+itt1LRGSISDNTW69WGmts4c0AQ63WJhi8kTD1 Zhew== X-Gm-Message-State: ALoCoQkdkAUOf7lb70K+weG9HvdBysr+RIsTe30akfSSPSgRf+wFpY9YiE+3ulJzhdBR7q8Kw0P6 MIME-Version: 1.0 X-Received: by 10.224.132.70 with SMTP id a6mr38882872qat.16.1416272354708; Mon, 17 Nov 2014 16:59:14 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 16:59:14 -0800 (PST) Date: Mon, 17 Nov 2014 16:59:14 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gBsZ-ix2x1Lmk8LomH-UmlDAVIw Subject: [Netconf] RESTCONF #6: how to identify query parameters supported by the server (move to CLOSED) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 00:59:21 -0000 Hi The following issue has been addressed and the proposed resolution is in draft-ietf-netconf-restconf-03.txt. https://github.com/netconf-wg/restconf/issues/6 No objections to the updated text have been received so this issue will be closed. Andy From nobody Mon Nov 17 17:00:09 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0A31AD024 for ; Mon, 17 Nov 2014 17:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Y9fiy68Y9NLR for ; Mon, 17 Nov 2014 17:00:04 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992611AD028 for ; Mon, 17 Nov 2014 17:00:04 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id n8so15349159qaq.33 for ; Mon, 17 Nov 2014 17:00:03 -0800 (PST) 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 :content-type; bh=98nAok5lZRKnKKL1CKfn5l/CDKLkSyYkIcNKi2PhWN4=; b=KkNRn3I2um6M12GJWvDpxlKOOpl9Z9b2FnyAa07nd6YPgz0kVXwDEvXLETJz8xY2/N KTXJ/rBep3jnuxqAWOTcfFvK2ICD/Y6X/MupJpvyzhUKsq2w27TSeEuT7CvhlQWJShkm bFVRWZvKr6sctCAfQqxrgHcVhq0xetVCtsTf472FGlVIEtafEY2qqN0pqWq5yVPBjbFL 3xL2Q+dwchvS8/g45IFt6YZtLt7aNicpbL4e/BPQ8ErBJx+yKptDDFFoKTu5DTD+aaol 9geXIkB9MVNkdfXsrOpe6VlWaUxsnC6RZA3m5yle1o6Nq8hqlNUS+2LAHQCESItcOo6V K5Qw== X-Gm-Message-State: ALoCoQl8AQ4tR67edklUAlqzHHLRPpvTg2KOGXcdBi/PQQRP3zBBExjCJeKYgU/3nIO36oD03W7Q MIME-Version: 1.0 X-Received: by 10.140.81.36 with SMTP id e33mr38353801qgd.90.1416272403642; Mon, 17 Nov 2014 17:00:03 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 17:00:03 -0800 (PST) Date: Mon, 17 Nov 2014 17:00:03 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YpVHIhuvD78kcXUYULSmRlywsJA Subject: [Netconf] RESTCONF #7: mandatory-to-implement encoding (move to CLOSED) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:00:07 -0000 Hi The following issue has been addressed and the proposed resolution is in draft-ietf-netconf-restconf-03.txt. https://github.com/netconf-wg/restconf/issues/7 No objections to the updated text have been received so this issue will be closed. Andy From nobody Mon Nov 17 17:00:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53951AD035 for ; Mon, 17 Nov 2014 17:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 D8Koh31xi11Z for ; Mon, 17 Nov 2014 17:00:32 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0871AD02E for ; Mon, 17 Nov 2014 17:00:32 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id j7so4517257qaq.15 for ; Mon, 17 Nov 2014 17:00:31 -0800 (PST) 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 :content-type; bh=TXmGw3N79yUU+dXr2o8dUaGmnlZoxFMDXi6SZUGsSEg=; b=PLt/ypz3LuTZB1hBVgXt+GXT+bRYDZknU+OE9vCxPr83DsSuMJm6foA3y/pghvDCy1 Re49BVVxFzyfmPoa5xTYQEmYIvZ1m59R46i+cRrbUhezOeqX4vtSnIQnolJSPqAxTETJ 7/62P0WDSmbLeGx6y+Kma4aE3gvJSz5TZ44hP3UJTPEHkWYYSS37j2egb0KRYgAzM/tx O5DHZGBqll4XoNtEoaSUJ36aK8sZ/V4fKomWACXC1YCz2bJcslrKCDqiV6OAZLIp041a g4uH5haq63vXUjfkgVY4aWsAFjDkwDACqgDN82bsuZRBc/Ag2xgVT8k5aAdlTowObn9H 7Y6Q== X-Gm-Message-State: ALoCoQlcc6wSYRzAy3gM7ktkOC9p+karWbWQjvwkPHkWCidALxTtQEZPuWsFlb2pvPCDL+lKkenB MIME-Version: 1.0 X-Received: by 10.224.12.14 with SMTP id v14mr5088502qav.88.1416272431815; Mon, 17 Nov 2014 17:00:31 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 17:00:31 -0800 (PST) Date: Mon, 17 Nov 2014 17:00:31 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xmyHi9uUVjnqWC8TZ18h3FX2_pc Subject: [Netconf] RESTCONF #8: move the /restconf data to a YANG module so it is under /restconf/data (move to CLOSED) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:00:35 -0000 Hi The following issue has been addressed and the proposed resolution is in draft-ietf-netconf-restconf-03.txt. https://github.com/netconf-wg/restconf/issues/8 No objections to the updated text have been received so this issue will be closed. Andy From nobody Mon Nov 17 17:01:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A861AD027 for ; Mon, 17 Nov 2014 17:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 IuArSKJ4TKSn for ; Mon, 17 Nov 2014 17:00:59 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9421AD024 for ; Mon, 17 Nov 2014 17:00:58 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id j5so1624007qga.14 for ; Mon, 17 Nov 2014 17:00:58 -0800 (PST) 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 :content-type; bh=t8HhFVy86crLxofAnB6o6XKCvflxr0oH4r1KKr36uNA=; b=SsPN4tyk7uWDWUHuk92gx8gs9wJLgdmH2R9oMeWsBjK1QtS/nSi+sPSUCXArKxc21F vaQA15vo2bET2QHJk6yqORZbfrP/35JwMMYwskVAjyB4aU5uDV1yRW/XsBVHUJVZ9Gen Il70hPzvLIlGBEehALIAVyetmNZV5BDoLXxN38y8cSdEDvRqhF7mXbvNBRTvHZ6yCqa5 xKlCy4XeITdON2D+IfiNdyswVHq+xB1gRlldBVPAHB8E8pUINumpvQm+GTGY95L3ET7q 8RVy9xU9Q1ZgZ4YtnOq5zCfuHnCGKw4cisCrjXtXZguxAvNyHRGP1CyFmYrQFycyJ0nl FsUA== X-Gm-Message-State: ALoCoQlkUUe5v2I2wvJR+US5vfD8dON9aHQ13OLqyq7ll35sKpjy0xTOWE083oEBV/jsjoQmTr7a MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr26115524qas.99.1416272458134; Mon, 17 Nov 2014 17:00:58 -0800 (PST) Received: by 10.140.37.52 with HTTP; Mon, 17 Nov 2014 17:00:58 -0800 (PST) Date: Mon, 17 Nov 2014 17:00:58 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DXLs4g4I7WPv6ur35SemJhu0QTo Subject: [Netconf] RESTCONF #10 : Naming convention for Query Parameters (move to CLOSED) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:01:01 -0000 Hi The following issue has been addressed and the proposed resolution is in draft-ietf-netconf-restconf-03.txt. https://github.com/netconf-wg/restconf/issues/10 No objections to the updated text have been received so this issue will be closed. Andy From nobody Tue Nov 18 07:22:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB31A19E9 for ; Tue, 18 Nov 2014 07:22:22 -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_32=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-2t58HGheNY for ; Tue, 18 Nov 2014 07:22:21 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680061A03FF for ; Tue, 18 Nov 2014 07:22:21 -0800 (PST) Received: from BY2PR05CA042.namprd05.prod.outlook.com (10.141.250.32) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 18 Nov 2014 15:22:20 +0000 Received: from BY2FFO11FD015.protection.gbl (2a01:111:f400:7c0c::195) by BY2PR05CA042.outlook.office365.com (2a01:111:e400:2c5f::32) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Tue, 18 Nov 2014 15:22:19 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Tue, 18 Nov 2014 15:22:19 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 18 Nov 2014 07:21:56 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sAIFLeR66935; Tue, 18 Nov 2014 07:21:53 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sAIFLQ3a077937; Tue, 18 Nov 2014 10:21:26 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201411181521.sAIFLQ3a077937@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Tue, 18 Nov 2014 10:21:26 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(92566001)(69596002)(6806004)(21056001)(120916001)(97736003)(46102003)(92726001)(84676001)(44976005)(103666002)(86362001)(102836001)(53416004)(68736004)(87936001)(110136001)(76506005)(47776003)(20776003)(4396001)(64706001)(50986999)(50466002)(54356999)(48376002)(77156002)(99396003)(95666004)(105596002)(31966008)(107046002)(81156004)(106466001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:P-EMF03-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-Forefront-PRVS: 039975700A Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/p_2sdL3KjzHTkgzVRLvkcsbbHzQ Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:22:23 -0000 Andy Bierman writes: >This will use the groupings in this module and let them be reusable >in external modules. As Martin said there is nothing invalid >about defining a grouping for external reuse. Any XPath can >all be relative to the grouping, so it is reusable as well. Taking a step back, are we really looking at using YANG for an interface definition language (IDL)? Would it make sense to define an IDL module with a full set of IDL extensions? idl:id, idl:version, idl:request, idl:response, etc. would be useful. How does the current groupings reuse hook requests to replies? Thanks, Phil From nobody Tue Nov 18 07:43:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E31A19FD for ; Tue, 18 Nov 2014 07:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 s4lpfzQLQrh0 for ; Tue, 18 Nov 2014 07:43:51 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EB61A1A22 for ; Tue, 18 Nov 2014 07:43:49 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id e89so6103711qgf.37 for ; Tue, 18 Nov 2014 07:43:48 -0800 (PST) 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=W1tiTFaEUHcFVl4f0H9IOukK21mclP8G4Qy+ywMN4Qs=; b=WsarbayZ2ozhaB1PYNq/Ms9M7cUntU+Jp0/rBtebyqO7eOVuWgDzpCSKGorIu/satF H+2RUpekchw2MS6PtFU8zJ/x0FmORTbOyXRyraCPA9tZPHKEGRbKEh5x8K62MC4Dlsbj LFT440XnhmNCC539nlBu5u7naNsHjYRX56csQfrP8tIYXf7Vq1CrUFdU4zFxSl8dK3aV pe4HUf4BMSHmRnpkm6C4huel7/4iKBi0842E0ImCsonqN1M3p0qRWCDWqLRnR7AinZo4 PmpPaNPs3hUpqyknklPrP1It8DH3GSqRDpy7e7bZtGR2hlS1eZMYXqzoymcK9svxpeoi Kcdw== X-Gm-Message-State: ALoCoQn7lQjvOPMyxiSPX6yZnqUyEPB/lQYGfGwTvk8RMKZ8RtB/ztpamo8gYdXNR/45Z2itXQ1U MIME-Version: 1.0 X-Received: by 10.140.34.21 with SMTP id k21mr43416863qgk.21.1416325428740; Tue, 18 Nov 2014 07:43:48 -0800 (PST) Received: by 10.140.37.52 with HTTP; Tue, 18 Nov 2014 07:43:48 -0800 (PST) In-Reply-To: <201411181521.sAIFLQ3a077937@idle.juniper.net> References: <201411181521.sAIFLQ3a077937@idle.juniper.net> Date: Tue, 18 Nov 2014 07:43:48 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eP9Z3FcBapXVEAAxm_QTLd8sQvE Cc: Netconf Subject: Re: [Netconf] usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:43:53 -0000 On Tue, Nov 18, 2014 at 7:21 AM, Phil Shafer wrote: > Andy Bierman writes: >>This will use the groupings in this module and let them be reusable >>in external modules. As Martin said there is nothing invalid >>about defining a grouping for external reuse. Any XPath can >>all be relative to the grouping, so it is reusable as well. > > Taking a step back, are we really looking at using YANG for > an interface definition language (IDL)? Would it make sense > to define an IDL module with a full set of IDL extensions? > idl:id, idl:version, idl:request, idl:response, etc. would > be useful. > > How does the current groupings reuse hook requests to replies? > I am not trying to define an IDL. The module containing the usage of the extension binds a YANG module namespace to the structure definition. Once it has a namespace, semantics, and syntax, it can be reused. Our usage in the RFC is to simply have these 3 properties. The normative text in the RFC says "the foo resource type is encoded according to the structure "foo" in the "ietf-restconf" module. The protocol spec using the "structure" extension defines its own protocol messages. My logging module can happily import grouping "errors" and use that in a plain old YANG monitoring module. There are never any protocol messages incorrectly exposed as configuration data. > Thanks, > Phil Andy From nobody Tue Nov 18 09:23:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900181A1B9B for ; Tue, 18 Nov 2014 09:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 j_AWd2HyT6xR for ; Tue, 18 Nov 2014 09:23:19 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAC41A1B9A for ; Tue, 18 Nov 2014 09:23:17 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so5771034qcx.26 for ; Tue, 18 Nov 2014 09:23:16 -0800 (PST) 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 :content-type; bh=aF2yLihrF01h4SLm/jjYZeHG9HI+pHSNREo195KMAD0=; b=ShqyWNUkbhfLgAhVG0Fo1ACoVrYA1/kxjBShWuD3om6H55Bc0ExBwsMDyWU67IqNXz vlQwbDD3RdA420K5UZOkiBE5wkUtroYZ76pyxQO21C5tdw3HHqOEP49xtKbyNACwfVJD JccH+v/NJxAZeCJ1hE+F4dQs7Zl1GIjTEKitvmc0i6este95dYA8cEyMAiINH3sLOnux EjpQK5lHt26FG8CY8bkhKSzFCNv4q+CxT790u1Jc2Kj5JvoLAD2qg9dm1Txbn7gk/lqr Lhzo9xBVducWLmc6QbfNBHOt6vyUO/vNon3buMlqC2mmUYAbgpEIBcqPMdqv3Tk6QVX7 3/Gg== X-Gm-Message-State: ALoCoQlC6hT6ZCHRvFuBLTFdWRtJS+1azsn213WMgyP7fxZfgCqSeOE5FFz0dGRiM3DKHk8yQk5T MIME-Version: 1.0 X-Received: by 10.229.212.66 with SMTP id gr2mr12328579qcb.8.1416331396322; Tue, 18 Nov 2014 09:23:16 -0800 (PST) Received: by 10.140.37.52 with HTTP; Tue, 18 Nov 2014 09:23:16 -0800 (PST) Date: Tue, 18 Nov 2014 09:23:16 -0800 Message-ID: From: Andy Bierman To: Netconf , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/R-DJUS6-9xhFlPtZozRGgspTXQk Subject: [Netconf] RESTCONF #13 and Y45: ietf-yang-library (Consensus Call) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 17:23:21 -0000 Hi, I think the NETMOD and NETCONF WGs agreed in Honolulu that the ietf-yang-library should be moved to the YANG Conformance draft, which will be changed to a NETMOD WG draft. RESTCONF #13 https://github.com/netconf-wg/restconf/issues/13 YANG1.1 #Y45: better conformance mechanism http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-45 YANG Conformance draft http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt Initial changes to YC draft: - remove sec. 5: submodule capability - remove get-allowed-leafrefs RPC This email is to confirm the consensus from the IETF meeting. Andy From nobody Wed Nov 19 01:23:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C64D1ACFD5 for ; Wed, 19 Nov 2014 01:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1rrW4hK10zj for ; Wed, 19 Nov 2014 01:23:53 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1931ACF8F for ; Wed, 19 Nov 2014 01:23:53 -0800 (PST) Received: from Vanguard ([84.92.149.4]) by avasout04 with smtp id HMPp1p00405w0Nk01MPqL6; Wed, 19 Nov 2014 09:23:51 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZuVjKrLG c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=6bkCdLdQAAAA:8 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=9BXoarkDYCTAqRcJqs0A:9 a=9GN_YGQ8k12CwaPl:21 a=f2B2bL-D_bFfyfU1:21 a=QEXdDO2ut3YA:10 a=jM_x9b4JT8QA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=pemoRIqwloLzeZJd:21 a=gvGbIVqH-RtIdeln:21 a=BaILYF7XYl38AVGb:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 From: "Jonathan Hansford" To: References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> <168e6dc03062eca48e58585ed91d503f@imap.plus.net> In-Reply-To: <168e6dc03062eca48e58585ed91d503f@imap.plus.net> Date: Wed, 19 Nov 2014 09:24:02 -0000 Message-ID: <01f101d003da$8fb25f90$af171eb0$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F2_01D003DA.8FB3BF20" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMiybCIrL9oTg30tmRMAqnWcD0bwGnorXpAeE5Rweb0kifMA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2pigdHRdy6lKJ1UDSDnN2XjUfl8 Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 09:23:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F2_01D003DA.8FB3BF20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 Having read further, I am really confused about what section 1.2 is = telling me about the transaction features not directly provided by = RESTCONF. =20 Datastore locking: this is identified as not directly provided, yet = section 6.1 appears to show a lock attempt on a datastore. =20 Candidate and startup datastores: again not directly provided, yet = section 1.2 states a =E2=80=9Csimplified framework and protocol is = needed that utilizes the three NETCONF datastores (candidate, running, = startup)=E2=80=9D. Section 1.4.4 states: =20 unified datastore: A conceptual representation of the device running = configuration. The server will hide all NETCONF datastore details for = edit operations, such as the ":candidate" and ":startup" capabilities. =20 which seems to indicate the unified datastore is a representation of = just the running configuration. However, section 2.4 states: =20 The underlying NETCONF datastores (i.e., candidate, running, startup) = can be used to implement the unified datastore, but the server design is = not limited to the exact datastore procedures defined in NETCONF. =20 The "candidate" and "startup" datastores are not visible in the RESTCONF = protocol. Transaction management and configuration persistence are = handled by the server and not controlled by the client. =20 So, can the =E2=80=9Ccandidate=E2=80=9D and =E2=80=9Cstartup=E2=80=9D = datastores be used to implement the unified datastore or not?=20 =20 If so, what impact does that have on RESTCONF and how can the client = access them using RESTCONF?=20 =20 Or is it just that a server supporting both NETCONF and RESTCONF may = support both :candidate and :startup just for NETCONF clients?=20 =20 And how is transaction management and configuration persistence handled = by the server, or is that again through NETCONF but not through = RESTCONF? =20 Is RESTCONF providing the =E2=80=9Csimplified framework and protocol = =E2=80=A6 that utilizes the three NETCONF datastores (candidate, = running, startup)=E2=80=9D and, if not, why say it in this document? =20 Thanks, =20 Jonathan =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan = Hansford Sent: 14 November 2014 13:18 To: netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt =20 Hi, Section 1.2 * The section is entitled "Simple Subset of NETCONF Functionality", but = if the only aspects of NETCONF it is lacking are the transaction = features bulleted in the third paragraph then the title seems to be = underselling it somewhat. * I'm a little confused with the first paragraph; maybe it is just the = way I am reading it. The first sentence appears to describe what = RESTCONF needs to be, whereas the second appears to describe what = RESTCONF lacks (based on the third paragraph). However, both sentences = (and the second paragraph) talk about what is or is not "needed". Could = these be reworded to clarify what RESTCONF provides and what it doesn't? * Is there any intent to address these additional needs at some point, = or is it assumed RESTCONF is adequate without them? Is there any reason = why they aren't being addressed at this time? * The transaction features listed in the third paragraph are all = capabilities defined in RFC 6241 plus RFC 5717. Are all other = capabilities from 6241 (i.e. those not listed in this paragraph) = supported by RESTCONF (e.g. Rollback-on-Error)? Thanks, Jonathan On 2014-10-25 23:16, Andy Bierman wrote: FYI, =20 This version of RESTCONF addresses all issues on the github tracker except maybe #9. Also, #11 was deferred to a future release. =20 A change was made to the "stream" list in ietf-restconf-monitoring.yang to allow separate stream links for XML and (optionally) JSON encoding of notifications. =20 A "collection" resource, plus "limit" and "offset" query parameters, have been added to allow multiple leaf-list and list instances to be retrieved. The optional "page" capability allows pagination of list entries, using the limit and offset parameters. =20 Issue List: https://github.com/netconf-wg/restconf/issues =20 =20 Please review the draft and send any comments to the mailing list. Please post any objections to closing the issues #2 - #8 and #10 - #13. =20 thanks, Andy =20 On Sat, Oct 25, 2014 at 3:46 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Network Configuration = Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy = Bierman Martin Bjorklund Kent Watsen Filename : = draft-ietf-netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 = Abstract: This document describes an HTTP-based protocol that provides a = programmatic interface for accessing data defined in YANG, using the = datastores defined in NETCONF. The IETF datatracker status page for this = draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ = There's also a htmlized version available at: = http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from = the previous version is available at: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 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 _______________________________________________ Netconf mailing list Netconf@ietf.org =20 https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_01F2_01D003DA.8FB3BF20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Having read further, I am really confused = about what section 1.2 is telling me about the transaction features not = directly provided by RESTCONF.

 

Datastore locking: this is identified as not = directly provided, yet section 6.1 appears to show a lock attempt on a = datastore.

 

Candidate and startup datastores: again not = directly provided, yet section 1.2 states a =E2=80=9Csimplified = framework and protocol is needed that utilizes the three NETCONF = datastores (candidate, running, startup)=E2=80=9D. Section 1.4.4 = states:

 

unified datastore: A conceptual = representation of the device running configuration.=C2=A0 The server = will hide all NETCONF datastore details for edit operations, such as the = ":candidate" and ":startup" = capabilities.

 

which seems to indicate the unified = datastore is a representation of just the running configuration. = However, section 2.4 states:

 

The underlying NETCONF datastores (i.e., = candidate, running, startup) can be used to implement the unified = datastore, but the server design is not limited to the exact datastore = procedures defined in NETCONF.

 

The "candidate" and = "startup" datastores are not visible in the RESTCONF = protocol.=C2=A0 Transaction management and configuration persistence are = handled by the server and not controlled by the = client.

 

So, can the =E2=80=9Ccandidate=E2=80=9D and = =E2=80=9Cstartup=E2=80=9D datastores be used to implement the unified = datastore or not?

 

If so, what impact does that have on = RESTCONF and how can the client access them using RESTCONF? =

 

Or is it just that a server supporting both = NETCONF and RESTCONF may support both :candidate and :startup just for = NETCONF clients?

 

And how is transaction management and = configuration persistence handled by the server, or is that again = through NETCONF but not through RESTCONF?

 

Is RESTCONF providing the = =E2=80=9Csimplified framework and protocol =E2=80=A6 that utilizes the = three NETCONF datastores (candidate, running, startup)=E2=80=9D and, if = not, why say it in this document?

 

Thanks,

 

Jonathan

 

From:<= /b> Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan = Hansford
Sent: 14 November 2014 13:18
To: = netconf@ietf.org
Subject: Re: [Netconf] I-D Action: = draft-ietf-netconf-restconf-03.txt

 

Hi,

Section = 1.2

  • The section is entitled "Simple Subset of NETCONF = Functionality", but if the only aspects of NETCONF it is lacking = are the transaction features bulleted in the third paragraph then the = title seems to be underselling it somewhat.
  • I'm a little confused with the first paragraph; maybe it is = just the way I am reading it. The first sentence appears to describe = what RESTCONF needs to be, whereas the second appears to describe what = RESTCONF lacks (based on the third paragraph). However, both sentences = (and the second paragraph) talk about what is or is not = "needed". Could these be reworded to clarify what RESTCONF = provides and what it doesn't?
  • Is there any intent to address these additional needs at = some point, or is it assumed RESTCONF is adequate without them? Is there = any reason why they aren't being addressed at this = time?
  • The transaction features listed in the third paragraph are = all capabilities defined in RFC 6241 plus RFC 5717. Are all other = capabilities from 6241 (i.e. those not listed in this paragraph) = supported by RESTCONF (e.g. = Rollback-on-Error)?

Thanks,

Jonat= han

On 2014-10-25 23:16, Andy Bierman = wrote:

FYI,<=
o:p>
 
This version of =
RESTCONF addresses all issues on the github =
tracker
except maybe #9. Also,=C2=A0 #11 was =
deferred to a future =
release.
 
A change was =
made to the "stream" list in =
ietf-restconf-monitoring.yang
to allow separate =
stream links for XML and (optionally) JSON =
encoding
of =
notifications.
 
A =
"collection" resource, plus "limit" and =
"offset" query parameters,
have been =
added to allow multiple leaf-list and list =
instances
to be retrieved. The optional =
"page" capability allows pagination =
of
list entries, using the limit and offset =
parameters.
 
Issue =
List:
https://github.com=
/netconf-wg/restconf/issues
 
 
Please review the draft and send any =
comments to the mailing list.
Please post any =
objections to closing the issues #2 - #8 and #10 - =
#13.
 
thanks,<=
/pre>
Andy
 
On Sat, =
Oct 25, 2014 at 3:46 PM,=C2=A0 <internet-drafts@ietf.org>=
 wrote:
A New Internet-Draft is available from the on-line =
Internet-Drafts directories. This draft is a work item of the Network =
Configuration Working Group of the IETF. Title : RESTCONF Protocol =
Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : =
draft-ietf-netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 =
Abstract: This document describes an HTTP-based protocol that provides a =
programmatic interface for accessing data defined in YANG, using the =
datastores defined in NETCONF. The IETF datatracker status page for this =
draft is: ht=
tps://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's =
also a htmlized version available at: http:/=
/tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from the =
previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 =
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.i=
etf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html<=
/a> or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
_________________=
______________________________
Netconf mailing =
list
Netconf@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/netconf
------=_NextPart_000_01F2_01D003DA.8FB3BF20-- From nobody Thu Nov 20 16:14:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0601A8A0E for ; Thu, 20 Nov 2014 16:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 bQyB1c7aDwgX for ; Thu, 20 Nov 2014 16:14:54 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381F11A8A0D for ; Thu, 20 Nov 2014 16:14:54 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so2668950qaq.38 for ; Thu, 20 Nov 2014 16:14:53 -0800 (PST) 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 :content-transfer-encoding; bh=JyRxw5P/J2UEHOFMS9SBIjGhm8ktc3YCaaegoVTeb7o=; b=UXebK1aJUtYWXIs2snfIG3aSKPXjJOWQiGQRXE59HxqfQU29FHL+IijQDKY+a4waEa V9iCOGydJLd/3eJNNHrD10LMMmJgM0HZRo4HzgnJG62hZDjviUHqozJRjG4oJy/9ud+H JU/ZEMVhiHMvpFo2+A8hpzkenYc4kqxogteXYYgmTps+kR/h+YCPOEEJgWRdKLspu+NS DuNs059XvU8ZA9Z8JL2CQYSAXIqInP3wKf36H6Jfjp3X23Id+cNo6lR0c4MDgFESvF4r 42MSFsCcWVoCzP9IXcskG4ZmY17ZrmnB4tKoAFZzQkVG8TlJ9awMK/H6QUHCj8s17twf 2zqw== X-Gm-Message-State: ALoCoQldurjt95ejUrwv2IZ0SxRMY+FdC0W1MGB6Ovh2sCAk2igMmgjUYCBC5aJfjeGsHQ6e29hS MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr1656169qas.99.1416528893430; Thu, 20 Nov 2014 16:14:53 -0800 (PST) Received: by 10.140.37.52 with HTTP; Thu, 20 Nov 2014 16:14:53 -0800 (PST) In-Reply-To: <00f001d00032$a1724610$e456d230$@hansfords.net> References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> <00b601d00028$1cb91d90$562b58b0$@hansfords.net> <00f001d00032$a1724610$e456d230$@hansfords.net> Date: Thu, 20 Nov 2014 16:14:53 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NU4MzL3trR-eOSTyusvmmwa8O0Q Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:14:57 -0000 Hi, We are updating the draft based on this email and previous 2 emails. thanks, Andy On Fri, Nov 14, 2014 at 9:44 AM, Jonathan Hansford wrote: > Also, RFC2616 was obsoleted in June 2014 by RFC 7230, RFC 7231, RFC 7232, > RFC 7233, RFC 7234 and RFC 7235, so should they be referenced instead? > > =C2=B7 RFC 3986 > > o Fragment > > o Path > > o Query > > =C2=B7 RFC 7230 > > o Message body > > o Header line (request line and status line?) > > o Request URI (the reference appears to be generally to the =E2=80=98ef= fective > request URI=E2=80=99) > > o Response body (actually the =E2=80=98message body=E2=80=99 of the res= ponse) > > =C2=B7 RFC 7231 > > o Method > > o Request (doesn=E2=80=99t appear to be formally defined anywhere) > > o Resource > > =C2=B7 RFC 7232 > > o Entity tag > > > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan > Hansford > Sent: 14 November 2014 16:29 > To: 'Andy Bierman' > Cc: 'Netconf' > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt > > > > Hi, > > > > I=E2=80=99ve never worked with HTTP and so have been following up the HTT= P > definitions listed in section 1.4.2: > > =C2=B7 The terms =E2=80=98fragment=E2=80=99 and =E2=80=98query=E2= =80=99 are actually defined in RFC 3986 > > =C2=B7 The term =E2=80=98header line=E2=80=99 is not defined in R= FC 2616. Are you using > it as a generic term for =E2=80=98request line=E2=80=99 and =E2=80=98stat= us line=E2=80=99 that are defined > in that RFC? > > =C2=B7 The term =E2=80=98path=E2=80=99 is not defined in RFC 2616= and is used in that RFC > for a number of purposes. I presume it is the URI =E2=80=98path=E2=80=99 = that is intended, > which is defined in RFC 3986 > > =C2=B7 The term =E2=80=98response body=E2=80=99 is not defined in= RFC 2616 but I presume > it means the message body of the response. > > > > Jonathan > > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: 26 October 2014 00:17 > Cc: Netconf > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt > > > > FYI, > > > > This version of RESTCONF addresses all issues on the github tracker excep= t > maybe #9. Also, #11 was deferred to a future release. > > > > A change was made to the "stream" list in ietf-restconf-monitoring.yang t= o > allow separate stream links for XML and (optionally) JSON encoding of > notifications. > > > > A "collection" resource, plus "limit" and "offset" query parameters, have > been added to allow multiple leaf-list and list instances to be retrieved= . > The optional "page" capability allows pagination of list entries, using t= he > limit and offset parameters. > > > > Issue List: > > https://github.com/netconf-wg/restconf/issues > > > > > > Please review the draft and send any comments to the mailing list. > > Please post any objections to closing the issues #2 - #8 and #10 - #13. > > > > thanks, > > Andy > > > > On Sat, Oct 25, 2014 at 3:46 PM, wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. > >> This draft is a work item of the Network Configuration Working Group of >> the IETF. > >> > >> Title : RESTCONF Protocol > >> Authors : Andy Bierman > >> Martin Bjorklund > >> Kent Watsen > >> Filename : draft-ietf-netconf-restconf-03.txt > >> Pages : 99 > >> Date : 2014-10-25 > >> > >> Abstract: > >> This document describes an HTTP-based protocol that provides a > >> programmatic interface for accessing data defined in YANG, using the > >> datastores defined in NETCONF. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 > >> > >> > >> 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 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 20 16:28:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937251A86F3 for ; Thu, 20 Nov 2014 16:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 MGvF3aHj909i for ; Thu, 20 Nov 2014 16:28:28 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4A61A6F03 for ; Thu, 20 Nov 2014 16:28:28 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so3062230qcx.31 for ; Thu, 20 Nov 2014 16:28:27 -0800 (PST) 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 :content-transfer-encoding; bh=auPt8+b49AU9dElYB68SprerWKSvcTUOenNpGNYiFio=; b=lezpGzHolM5pkY+BI4RCsQslBRIbhcegMOvX04K6BuLOAFT48psW5OyEkHIFPX1M9D gBgVIZns7lwtV+lw5SIWGDEYVgd1mGGa3VpQ6zYMO0Wz83s67pkd08+p+E2Bgv5SHcT5 XPWuc6abRNB6Ij3yellrpzuZ/AbzURBaALUsmcM9m/WT4myAx5kJOTi0Qc8yZBba5VI0 LZCk6PlT2YcV9U7fGXhUqrPuOAvsflmnC9wPo5mlKaNBnw/XxNMF0jZAZZ6v6ZNL8Puw T0k0cpNgwlqwktUjr6UcqpQv+OorYO088f9mvKc1VSCA1Zs5DN1QShprG6DLmdIMP3hW DN1g== X-Gm-Message-State: ALoCoQmnzmCPLV9Cgf3/qxXG9pF3AYbVYYrgELBaMlFthav3C65FOiSyFF6UgTVpHNAptrFoG35T MIME-Version: 1.0 X-Received: by 10.229.176.198 with SMTP id bf6mr2041539qcb.12.1416529707837; Thu, 20 Nov 2014 16:28:27 -0800 (PST) Received: by 10.140.37.52 with HTTP; Thu, 20 Nov 2014 16:28:27 -0800 (PST) In-Reply-To: <01f101d003da$8fb25f90$af171eb0$@hansfords.net> References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> <168e6dc03062eca48e58585ed91d503f@imap.plus.net> <01f101d003da$8fb25f90$af171eb0$@hansfords.net> Date: Thu, 20 Nov 2014 16:28:27 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bPeh2X2I1R7TeMqlQRA6D48qdbY Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:28:31 -0000 On Wed, Nov 19, 2014 at 1:24 AM, Jonathan Hansford wrote: > Hi, > > > > Having read further, I am really confused about what section 1.2 is telli= ng > me about the transaction features not directly provided by RESTCONF. > > > > Datastore locking: this is identified as not directly provided, yet secti= on > 6.1 appears to show a lock attempt on a datastore. > that is a bad example -- we will change it. > > > Candidate and startup datastores: again not directly provided, yet sectio= n > 1.2 states a =E2=80=9Csimplified framework and protocol is needed that ut= ilizes the > three NETCONF datastores (candidate, running, startup)=E2=80=9D. Section = 1.4.4 > states: > > I think the term "utilizes" is wrong. It should be "co-exists". > > unified datastore: A conceptual representation of the device running > configuration. The server will hide all NETCONF datastore details for ed= it > operations, such as the ":candidate" and ":startup" capabilities. > > It is an implementation detail how the complete an edit within the unified datastore in RESTCONF. > > which seems to indicate the unified datastore is a representation of just > the running configuration. However, section 2.4 states: > > > > The underlying NETCONF datastores (i.e., candidate, running, startup) can= be > used to implement the unified datastore, but the server design is not > limited to the exact datastore procedures defined in NETCONF. > correct -- the unified datastore may act like distinct-startup, but is not required to be implemented in any specific manner. The results of the operation requests are what matter. > > > The "candidate" and "startup" datastores are not visible in the RESTCONF > protocol. Transaction management and configuration persistence are handl= ed > by the server and not controlled by the client. > > > > So, can the =E2=80=9Ccandidate=E2=80=9D and =E2=80=9Cstartup=E2=80=9D dat= astores be used to implement the > unified datastore or not? > > It is an implementation detail. The external datastores named candidate and startup are not present in RESTCONF. If you mean can you use your internal implementations, then yes. An edit is expected to persist right away in RESTCONF even if the :startup capability is supported in NETCONF. > > If so, what impact does that have on RESTCONF and how can the client acce= ss > them using RESTCONF? > Try /restconf/operations/edit-config > > > Or is it just that a server supporting both NETCONF and RESTCONF may supp= ort > both :candidate and :startup just for NETCONF clients? > > > > And how is transaction management and configuration persistence handled b= y > the server, or is that again through NETCONF but not through RESTCONF? > An edit is expected to persist right away Use /restconf/operations/ if you want to use NETCONF over HTTP. It is not a priority of RESTCONF to provide a state-full complex protocol l= ike NETCONF. Sec. 1.2 points out that you should use NETCONF if you need the features that RESTCONF does not provide,. > > > Is RESTCONF providing the =E2=80=9Csimplified framework and protocol =E2= =80=A6 that utilizes > the three NETCONF datastores (candidate, running, startup)=E2=80=9D and, = if not, why > say it in this document? > We will change the word "utilizes" to "co-exists with" > > > Thanks, > > > > Jonathan > > Andy > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jonathan > Hansford > Sent: 14 November 2014 13:18 > To: netconf@ietf.org > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt > > > > Hi, > > Section 1.2 > > The section is entitled "Simple Subset of NETCONF Functionality", but if = the > only aspects of NETCONF it is lacking are the transaction features bullet= ed > in the third paragraph then the title seems to be underselling it somewha= t. > I'm a little confused with the first paragraph; maybe it is just the way = I > am reading it. The first sentence appears to describe what RESTCONF needs= to > be, whereas the second appears to describe what RESTCONF lacks (based on = the > third paragraph). However, both sentences (and the second paragraph) talk > about what is or is not "needed". Could these be reworded to clarify what > RESTCONF provides and what it doesn't? > Is there any intent to address these additional needs at some point, or i= s > it assumed RESTCONF is adequate without them? Is there any reason why the= y > aren't being addressed at this time? > The transaction features listed in the third paragraph are all capabiliti= es > defined in RFC 6241 plus RFC 5717. Are all other capabilities from 6241 > (i.e. those not listed in this paragraph) supported by RESTCONF (e.g. > Rollback-on-Error)? > > Thanks, > > Jonathan > > On 2014-10-25 23:16, Andy Bierman wrote: > > FYI, > > > > This version of RESTCONF addresses all issues on the github tracker > > except maybe #9. Also, #11 was deferred to a future release. > > > > A change was made to the "stream" list in ietf-restconf-monitoring.yang > > to allow separate stream links for XML and (optionally) JSON encoding > > of notifications. > > > > A "collection" resource, plus "limit" and "offset" query parameters, > > have been added to allow multiple leaf-list and list instances > > to be retrieved. The optional "page" capability allows pagination of > > list entries, using the limit and offset parameters. > > > > Issue List: > > https://github.com/netconf-wg/restconf/issues > > > > > > Please review the draft and send any comments to the mailing list. > > Please post any objections to closing the issues #2 - #8 and #10 - #13. > > > > thanks, > > Andy > > > > On Sat, Oct 25, 2014 at 3:46 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network Configuration Worki= ng > Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Marti= n > Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-03.txt Pages= : > 99 Date : 2014-10-25 Abstract: This document describes an HTTP-based > protocol that provides a programmatic interface for accessing data define= d > in YANG, using the datastores defined in NETCONF. The IETF datatracker > status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's als= o a > htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from the > previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 Please = note > that it may take a couple of minutes from the time of submission until th= e > htmlized version and diff are available at tools.ietf.org. Internet-Draft= s > are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-draft= s/ > _______________________________________________ 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 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Nov 24 15:48:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA931A897F for ; Mon, 24 Nov 2014 15:48:24 -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 6ygtvJuYsyRD for ; Mon, 24 Nov 2014 15:48:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DD01A87E2 for ; Mon, 24 Nov 2014 15:48:22 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 24 Nov 2014 23:48:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) with mapi id 15.01.0026.003; Mon, 24 Nov 2014 23:48:20 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , "Mahesh Jethanandani" Thread-Topic: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Thread-Index: AQHQCEEg+eay93kJyEidHepFnAkBVA== Date: Mon, 24 Nov 2014 23:48:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 040513D301 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(189002)(199003)(20776003)(83506001)(87936001)(66066001)(4396001)(50986999)(92566001)(62966003)(77096003)(77156002)(92726001)(36756003)(15975445006)(16236675004)(86362001)(21056001)(19580395003)(19580405001)(120916001)(105586002)(2656002)(106356001)(64706001)(54356999)(31966008)(122556002)(107046002)(46102003)(101416001)(106116001)(19617315012)(99396003)(99286002)(97736003)(19625215002)(95666004)(15202345003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0992AE78A578kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Bu5rIFZm2kmA_6XX0THxXT8-v-U Cc: NETCONF Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:48:24 -0000 --_000_D0992AE78A578kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mehmet, Mahesh, Today is the 24th and no comments to the minutes have been raised. Can we = now state that WG consensus to the decisions captured in the minutes have b= een confirmed on the list? If so, then I'll proceed updating my drafts as follows: * draft-ietf-netconf-call-home - will be updated to include RESTCONF (separate ports) * draft-ietf-netconf-server-model - will also be updated to include RESTCONF (to support above edit= ) - remove YANG 1.1 if-feature statements - add support for configuring client certs for SSH also - remove read-only listing of keys/certs supported by server - add if-feature statement to the new global config options - clean up IANA section (andy's comment) * draft-ietf-netconf-zerotouch - clarify bootstrapping sequence diagram - (post-meeting) see if there a solution that doesn't entail vendo= r-tracking Thanks, Kent From: , "Mehmet (NSN - DE/Munich)" > Date: Sunday, November 16, 2014 at 2:23 AM To: NetConf > Subject: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Dear NETCONF WG, please find below the draft minutes of the NETCONF session in IETF 91: http://www.ietf.org/proceedings/91/minutes/minutes-91-netconf Please send your comments to the co-chairs by November 24, 2014 EOB PT. Cheers, Mehmet --_000_D0992AE78A578kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <8336E67DFC69354889C271CFC2A6EBE9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Mehmet, Mahesh,

Today is the 24th and no comments to the minutes have been raised. &nb= sp;Can we now state that WG consensus to the decisions captured in the minu= tes have been confirmed on the list?

If so, then I'll proceed updating my drafts as follows:

  * draft-ietf-netconf-call-home
         - will be updated to include RESTCON= F  (separate ports)

  * draft-ietf-netconf-server-model
         -  will also be updated to incl= ude RESTCONF (to support above edit)
         - remove YANG 1.1 if-feature stateme= nts
         - add support for configuring client= certs for SSH also
         - remove read-only listing of keys/c= erts supported by server
         - add if-feature statement to the ne= w global config options
         - clean up IANA section (andy's comm= ent)

  * draft-ietf-netconf-zerotouch
         - clarify bootstrapping sequence dia= gram
         - (post-meeting) see if there a solu= tion that doesn't entail vendor-tracking


Thanks,
Kent


From: <Ersue>, "Mehmet (= NSN - DE/Munich)" <mehmet.e= rsue@nsn.com>
Date: Sunday, November 16, 2014 at = 2:23 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] Draft Minutes of= the NETCONF session in IETF 91

Dear NETCONF WG,
 
please find below the draft minutes of the NET= CONF session in IETF 91:
 
Please send your comments to the co-chairs by = November 24, 2014 EOB PT.
 
Cheers,
Mehmet
 
&nbs= p;
&nbs= p;
 --_000_D0992AE78A578kwatsenjunipernet_-- From nobody Tue Nov 25 00:45:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01E91A006B for ; Tue, 25 Nov 2014 00:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgdmKFDlBUF1 for ; Tue, 25 Nov 2014 00:45:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C2EE71A006E for ; Tue, 25 Nov 2014 00:45:54 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B91351280471; Tue, 25 Nov 2014 09:45:50 +0100 (CET) Date: Tue, 25 Nov 2014 09:45:50 +0100 (CET) Message-Id: <20141125.094550.1767548124404245695.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CTynRU1q10jaIwuR7gkJ4AWegMo Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:45:56 -0000 Kent Watsen wrote: > Hi Mehmet, Mahesh, > > Today is the 24th and no comments to the minutes have been raised. > Can we now state that WG consensus to the decisions captured in the > minutes have been confirmed on the list? I hope not! I interpreted Mehmet's email to mean that we could provide comments on *the draft minutes* until the 24th. /martin > > If so, then I'll proceed updating my drafts as follows: > > * draft-ietf-netconf-call-home > - will be updated to include RESTCONF (separate ports) > > * draft-ietf-netconf-server-model > - will also be updated to include RESTCONF (to support above edit) > - remove YANG 1.1 if-feature statements > - add support for configuring client certs for SSH also > - remove read-only listing of keys/certs supported by server > - add if-feature statement to the new global config options > - clean up IANA section (andy's comment) > > * draft-ietf-netconf-zerotouch > - clarify bootstrapping sequence diagram > - (post-meeting) see if there a solution that doesn't entail > - vendor-tracking > > > Thanks, > Kent > > > From: , "Mehmet (NSN - DE/Munich)" > > > Date: Sunday, November 16, 2014 at 2:23 AM > To: NetConf > > Subject: [Netconf] Draft Minutes of the NETCONF session in IETF 91 > > Dear NETCONF WG, > > please find below the draft minutes of the NETCONF session in IETF 91: > http://www.ietf.org/proceedings/91/minutes/minutes-91-netconf > > Please send your comments to the co-chairs by November 24, 2014 EOB > PT. > > Cheers, > Mehmet > > > From nobody Tue Nov 25 03:22:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B81A008B for ; Tue, 25 Nov 2014 03:22:26 -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 XB4ygh-eDHJW for ; Tue, 25 Nov 2014 03:22:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BCF1A0084 for ; Tue, 25 Nov 2014 03:22:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAPBMIbF028860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Nov 2014 11:22:18 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAPBMG4f027383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 12:22:18 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:22:16 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Martin Bjorklund , "kwatsen@juniper.net" Thread-Topic: Agreed solutions from 91 to implement WAS:RE: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Thread-Index: AQHQCEEg+eay93kJyEidHepFnAkBVJxw9ycAgAA6PTA= Date: Tue, 25 Nov 2014 11:22:15 +0000 Message-ID: References: <20141125.094550.1767548124404245695.mbj@tail-f.com> In-Reply-To: <20141125.094550.1767548124404245695.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/mixed; boundary="_002_E4DE949E6CE3E34993A2FF8AE79131F81956C147DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 11014 X-purgate-ID: 151667::1416914539-00001FC1-4426A1A8/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qJooXtkDoac-sy78_68pi1Lx3eg Cc: "netconf@ietf.org" Subject: [Netconf] Agreed solutions from 91 to implement WAS:RE: Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 11:22:26 -0000 --_002_E4DE949E6CE3E34993A2FF8AE79131F81956C147DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I started the verification of IETF 91 WG session results with the attached = mail.=20 As there was no objection to the session results the draft authors will imp= lement the solutions as agreed. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, November 25, 2014 9:46 AM > To: kwatsen@juniper.net > Cc: Ersue, Mehmet (NSN - DE/Munich); mjethanandani@gmail.com; netconf@iet= f.org > Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 >=20 > Kent Watsen wrote: > > Hi Mehmet, Mahesh, > > > > Today is the 24th and no comments to the minutes have been raised. > > Can we now state that WG consensus to the decisions captured in the > > minutes have been confirmed on the list? >=20 > I hope not! I interpreted Mehmet's email to mean that we could > provide comments on *the draft minutes* until the 24th. >=20 >=20 > /martin >=20 >=20 >=20 > > > > If so, then I'll proceed updating my drafts as follows: > > > > * draft-ietf-netconf-call-home > > - will be updated to include RESTCONF (separate ports) > > > > * draft-ietf-netconf-server-model > > - will also be updated to include RESTCONF (to support above = edit) > > - remove YANG 1.1 if-feature statements > > - add support for configuring client certs for SSH also > > - remove read-only listing of keys/certs supported by server > > - add if-feature statement to the new global config options > > - clean up IANA section (andy's comment) > > > > * draft-ietf-netconf-zerotouch > > - clarify bootstrapping sequence diagram > > - (post-meeting) see if there a solution that doesn't entail > > - vendor-tracking > > > > > > Thanks, > > Kent > > > > > > From: , "Mehmet (NSN - DE/Munich)" > > > > > Date: Sunday, November 16, 2014 at 2:23 AM > > To: NetConf > > > Subject: [Netconf] Draft Minutes of the NETCONF session in IETF 91 > > > > Dear NETCONF WG, > > > > please find below the draft minutes of the NETCONF session in IETF 91: > > http://www.ietf.org/proceedings/91/minutes/minutes-91-netconf > > > > Please send your comments to the co-chairs by November 24, 2014 EOB > > PT. > > > > Cheers, > > Mehmet > > > > > > --_002_E4DE949E6CE3E34993A2FF8AE79131F81956C147DEMUMBX005nsnin_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 25 Nov 2014 11:22:15 GMT"; modification-date="Tue, 25 Nov 2014 11:22:15 GMT" Received: from DEMUHTC001.nsn-intra.net (10.159.42.32) by DEMUHTC007.nsn-intra.net (10.159.42.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 13 Nov 2014 06:07:55 +0100 Received: from muvmp319.nsn-intra.net (10.159.42.100) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 13 Nov 2014 06:07:55 +0100 Received: from mumrelp001.nsn-inter.net ([93.183.13.135]) by muvmp319.nsn-intra.net (8.14.3/8.14.3) with ESMTP id sAD57saR008621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Nov 2014 05:07:54 GMT Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mumrelp001.nsn-inter.net (8.13.8/8.13.8) with ESMTP id sAD57rM4027946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2014 06:07:54 +0100 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12921A1B81; Wed, 12 Nov 2014 21:07:51 -0800 (PST) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0C1A1B81 for ; Wed, 12 Nov 2014 21:07:49 -0800 (PST) Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIWZ0cxPWcVl for ; Wed, 12 Nov 2014 21:07:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD551A1B7F for ; Wed, 12 Nov 2014 21:07:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAD57hcK015139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 05:07:43 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAD57gVj016431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 06:07:42 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 13 Nov 2014 06:07:42 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 06:07:42 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise , netconf Subject: [Netconf] Summary of and AIs from the NETCONF Session in IETF #91 Thread-Topic: Summary of and AIs from the NETCONF Session in IETF #91 Thread-Index: AQHP/v/A0RV7p1iOEE6jjsWMtI6v8g== Sender: Netconf Date: Thu, 13 Nov 2014 05:07:41 +0000 Message-ID: List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: DEMUHTC001.nsn-intra.net X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-purgate-id: 151667::1415855274-0000645D-238ED0A7/9/30015 x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de x-purgate: This mail is sent in bulk (visit http://www.eleven.de for further information) x-purgate-size: 2892 x-purgate-type: bulk x-originating-ip: [10.159.42.116] x-original-to: netconf@ietfa.amsl.com x-mailman-version: 2.1.15 delivered-to: netconf@ietfa.amsl.com x-beenthere: netconf@ietf.org x-virus-scanned: amavisd-new at amsl.com errors-to: netconf-bounces@ietf.org list-id: Network Configuration WG mailing list list-post: x-spam-score: -6.901 list-archive: 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 dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1415855272; bh=9Tv66zWTlu7rxxE1Q+7s2n2v2ntemY4LryhZrXFkrow=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=eLn1dUPbSqVFT6zE/DqhETf+QrL+ImyesB0FtpYoMS6ms2Y3owZvF3o0SpvCcB4Os hMWOSS0SbKVIZYXmRR09WGO3hGiOKIzMRA8b0/wcGMEDvhOoiSZ0Pi10oCiUFbKPhh 28JJQMcTqtvJ7ulJvUqzcnXvR068BlVmhKPjr26c= x-spam-flag: NO Content-Type: text/plain; charset="us-ascii" Content-ID: <81B460F8CBC63943B809F49628CB1EE6@internal.nsn.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on November= 11, 2014, Honolulu, Hawaii. A short version of this summary will be made available at OPS area Wiki soo= n (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF91summary). - We had approx. 85+ participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on all 6 chartered documents. - Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe was R= olf Winter. Many thanks to the note takers and jabber scribe for volunteering. The session agenda is available at: http://www.ietf.org/proceedings/91/agen= da/agenda-91-netconf NETCONF co-chairs will ask for a room for 100 for the next meeting. Following are the decisions taken per humming in the NETCONF session. If there is no strong objection we will implement as proposed. RESTCONF Call home support: - humming supported this approach, and the WG wants to do it now. Separate ports for callhome for SSH, TLS, RESTCONF - The WG supports with a large humm multiple/separate ports. Focus on the use of X.509 for TLS (rfc5539bis) - supported by a large humm Describe algorithm for extracting a user name out of the X509 attributes - loud humm in favor Use if-feature for server-model instead of waiting for an YANG 1.1 solution - loud humm in favor, certainly we do not want to wait Should we generate ssh host keys/509-certificates via a yang model or gener= ate them out of band. - big humm for yes, i.e. we postpone and do it later. Report hostkeys/certificates via yang data model - Humm to take them out and not report them via a data model RESTCONF state monitoring would require RESTCONF sessions - ACTION item: Andy will take the issue to list RESTCONF Default handling: - ACTION item: Andy will take it to the list SHOULD or MUST use HTTP 1.1 - humm in favor of SHOULD The issue on the I2RS ephemeral state has been summarized by the I2RS co-ch= air Jeff Haas. The discussion will be continued in NETCONF virtual meetings. The two drafts on fragmentation support will be merged and provided to NETC= ONF maillist. The aim should be to raise a discussion and to get the support of NETCONF W= G memebers. Virtual Meetings: - The WG will continue with virtual meetings. - In the first meeting we will discuss I2RS ephemeral state. - Action item: Mehmet to send out a new doodle poll to chose the best ti= me for all. Potential requirements on zerotouch from ANIMA WG: - Action item: WG chairs to communicate with ANIMA WG co-chairs that the= y must agree on requirements and provide with a draft to NETCONF WG. Cheers, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_002_E4DE949E6CE3E34993A2FF8AE79131F81956C147DEMUMBX005nsnin_-- From nobody Tue Nov 25 03:27:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53521A00F0 for ; Tue, 25 Nov 2014 03:27:25 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka6fbbE_vweO for ; Tue, 25 Nov 2014 03:27:23 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905231A00EB for ; Tue, 25 Nov 2014 03:27:22 -0800 (PST) Received: from AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) by AMXPR07MB021.eurprd07.prod.outlook.com (10.242.67.141) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 11:26:59 +0000 Received: from pc6 (86.184.62.161) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 11:26:58 +0000 Message-ID: <041501d008a2$c47b8d60$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Mahesh Jethanandani References: Date: Tue, 25 Nov 2014 11:27:11 +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.184.62.161] X-ClientProxiedBy: AM3PR03CA027.eurprd03.prod.outlook.com (10.141.191.155) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Forefront-PRVS: 040655413E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(199003)(189002)(377454003)(15202345003)(21056001)(31966008)(77096003)(93916002)(77156002)(44716002)(92566001)(62236002)(84392001)(1941001)(86362001)(46102003)(99396003)(14496001)(87286001)(101416001)(107046002)(106356001)(95666004)(116806002)(97736003)(66066001)(92726001)(50466002)(64706001)(42186005)(40100003)(87976001)(105586002)(20776003)(47776003)(19580395003)(19580405001)(62966003)(76176999)(81816999)(89996001)(61296003)(50986999)(81686999)(33646002)(1556002)(15975445006)(120916001)(102836001)(88136002)(44736004)(104166001)(50226001)(122386002)(23756003)(4396001)(1456002)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB021; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xmuU7gCZQ2ocFsf1k6hUGUAYQQw Cc: NETCONF Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 11:27:25 -0000 Kent I made two comments, seeking clarification as to what the two hums were about, one of which was where the algorithm for extracting a user name out of the X.509 attributes would go (something I got the sense that Juergen had wanted more clarity on). For me, netconf-server is the right place but I have seen nothing that I would call consensus (or lack thereof) on this item. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "Ersue, Mehmet (NSN - DE/Munich)" ; "Mahesh Jethanandani" Cc: "NETCONF" Sent: Monday, November 24, 2014 11:48 PM Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Hi Mehmet, Mahesh, Today is the 24th and no comments to the minutes have been raised. Can we now state that WG consensus to the decisions captured in the minutes have been confirmed on the list? If so, then I'll proceed updating my drafts as follows: * draft-ietf-netconf-call-home - will be updated to include RESTCONF (separate ports) * draft-ietf-netconf-server-model - will also be updated to include RESTCONF (to support above edit) - remove YANG 1.1 if-feature statements - add support for configuring client certs for SSH also - remove read-only listing of keys/certs supported by server - add if-feature statement to the new global config options - clean up IANA section (andy's comment) * draft-ietf-netconf-zerotouch - clarify bootstrapping sequence diagram - (post-meeting) see if there a solution that doesn't entail vendor-tracking Thanks, Kent From: , "Mehmet (NSN - DE/Munich)" > Date: Sunday, November 16, 2014 at 2:23 AM To: NetConf > Subject: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Dear NETCONF WG, please find below the draft minutes of the NETCONF session in IETF 91: http://www.ietf.org/proceedings/91/minutes/minutes-91-netconf Please send your comments to the co-chairs by November 24, 2014 EOB PT. Cheers, Mehmet ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Nov 25 07:59:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBB1A6F34 for ; Tue, 25 Nov 2014 07:59: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, 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 tNWm1_FuETb8 for ; Tue, 25 Nov 2014 07:59:38 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5259A1A9308 for ; Tue, 25 Nov 2014 07:59:33 -0800 (PST) Received: from DM2PR05MB461.namprd05.prod.outlook.com (10.141.105.15) by DM2PR05MB461.namprd05.prod.outlook.com (10.141.105.15) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 15:59:31 +0000 Received: from DM2PR05MB461.namprd05.prod.outlook.com ([169.254.9.219]) by DM2PR05MB461.namprd05.prod.outlook.com ([169.254.9.219]) with mapi id 15.01.0026.003; Tue, 25 Nov 2014 15:59:31 +0000 From: Kent Watsen To: t.petch , "Ersue, Mehmet (NSN - DE/Munich)" , Mahesh Jethanandani Thread-Topic: [Netconf] Draft Minutes of the NETCONF session in IETF 91 Thread-Index: AQHQCEEg+eay93kJyEidHepFnAkBVJxxNRK7///4LwA= Date: Tue, 25 Nov 2014 15:59:30 +0000 Message-ID: References: <041501d008a2$c47b8d60$4001a8c0@gateway.2wire.net> In-Reply-To: <041501d008a2$c47b8d60$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB461; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB461; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(164054003)(76176999)(54356999)(50986999)(120916001)(64706001)(122556002)(97736003)(66066001)(20776003)(99396003)(101416001)(4396001)(2656002)(92566001)(62966003)(40100003)(21056001)(83506001)(31966008)(86362001)(87936001)(77096003)(92726001)(77156002)(46102003)(106116001)(106356001)(105586002)(36756003)(107046002)(99286002)(95666004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB461; H:DM2PR05MB461.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <164CCCC66300C146B2B0D6F2322AE734@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vmhcAmIyCNHwNqS4SlYyOTHvEKU Cc: NETCONF Subject: Re: [Netconf] Draft Minutes of the NETCONF session in IETF 91 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:59:40 -0000 >I made two comments, seeking clarification as to what the two hums were >about, one of which was where the algorithm for extracting a user name >out of the X.509 attributes would go (something I got the sense that >Juergen had wanted more clarity on). > >For me, netconf-server is the right place but I have seen nothing that I >would call consensus (or lack thereof) on this item. > >Tom Petch Fair point, the server-model draft has a dependency on 5539bis, also noted during the IETF 91 meeting. The expected impact of the 5539bis update onto the server-model draft will likely be only to add explicit references to 5539bis sections, in order to tie the two drafts together. I'll move forward making the other edits now, and make the needed adjustments for 5539bis, as soon as it's updated. Thanks, Kent From nobody Tue Nov 25 19:17:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158671A8792; Tue, 25 Nov 2014 19:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 bCuqWbuJYS2R; Tue, 25 Nov 2014 19:16:58 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF831A1A14; Tue, 25 Nov 2014 19:16:57 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "NETCONF" , Date: Tue, 25 Nov 2014 22:16:39 -0500 Message-ID: <007f01d00927$6c225bf0$446713d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01D008FD.834D3E50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAJIa+dZSiX90itRUONHuaL/EmoUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/SLF9xyiVvP5AnIW0ovGooesQ8bQ Cc: edc.ietf@gmail.com, 'Alia Atlas' Subject: [Netconf] Interims for I2RS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 03:17:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0080_01D008FD.834D3E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG will be holding 3+ virtual interims before IETF 92 on the following dates: 12/11/14, 12/16/14, and 1/8/15. The topics for the interims will be the following: 12/11/14: Use Case Document, RIB Info Model and the RIB Yang model 12/16/14: Protocol Requirements for I2RS, and I2RS topology documents. 1/8/15: I2RS Topology Yang modules The I2RS WG LC for Use Case Document and RIB Info Model will run from (12/1 to 12/15). I2RS yang modules document are being prepared RIB-Info, L3 Topologies, L2 Topologies, service topologies, and generic topologies by design teams. If you are interested in a yang model design team, please contact the I2RS chairs (shares@ndzh.com, jhass@pfrc.org) to be connected to these design teams. A design team is being also formed to refine the I2RS protocol refinements for the I2RS protocol. We encourage who have implemented features similar to the I2RS to volunteer to guide this work. If you are interested in this design team, please contact the I2RS chairs by (12/2/14). Existing drafts are listed below Doodle polls will be sent to the I2RS mail list to select the time of day for the interims. Sue Hares and Jeff Haas Documents Existing I2RS http://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/ http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ Existing Info Models and Yang models http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/ I2RS Yang models http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-l3-topo/ http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topology/ http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-network-topo/ Yang modules http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ Policy that may be related to modules http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/ http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ ------=_NextPart_000_0080_01D008FD.834D3E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The I2RS WG = will be holding 3+ virtual interims before IETF 92 on the following = dates: 12/11/14, 12/16/14, and 1/8/15.  The topics for the interims = will be the following:

 

12/11/14: = Use Case Document,  RIB Info Model and the RIB Yang = model

12/16/14: Protocol Requirements = for I2RS, and I2RS topology documents.

1/8/15:     I2RS Topology Yang = modules

 

The I2RS WG LC for Use Case Document and RIB Info = Model will run from (12/1 to 12/15).   I2RS yang modules = document are being prepared RIB-Info, L3 Topologies, L2 Topologies, =  service topologies, and generic topologies by design teams. =   If you are interested in a yang model design team, =  please contact the I2RS chairs (shares@ndzh.com, jhass@pfrc.org) to be connected to = these design teams.

 

A design = team is being also formed to refine the I2RS protocol refinements for = the I2RS protocol.  We encourage who have implemented features = similar to the I2RS to volunteer to guide this work.  If you are = interested in this design team, please contact the I2RS chairs by = (12/2/14).  Existing drafts are listed below

 

Doodle polls = will be sent to the I2RS mail list to select the time of day for the = interims.

 

Sue Hares and Jeff Haas

 

Documents =

Existing I2RS

http://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summar= y/

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

Existing = Info Models and Yang models

= http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/<= /o:p>

http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-ser= vice-topo/

 

I2RS Yang = models

h= ttp://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-l3-topo/

http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topology/=

http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-network-topo/

 

Yang modules

h= ttp://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

 

 

Policy that = may be related to modules

http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/=

http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/

 

 

------=_NextPart_000_0080_01D008FD.834D3E50-- From nobody Wed Nov 26 10:17:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C31D1A1A72 for ; Wed, 26 Nov 2014 10:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 2RO_9lVun-9H for ; Wed, 26 Nov 2014 10:17:52 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533601A01CB for ; Wed, 26 Nov 2014 10:17:52 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so2461251qcx.17 for ; Wed, 26 Nov 2014 10:17:50 -0800 (PST) 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 :content-type; bh=aKz2cCIFfpqkhKgnS/34egRHnuBeARXbhlbjRfKJRuk=; b=BnPtZQztFJxSMSeLSiKJBloSFuYVZqKWGzXycEDrcqAUYf2qLprGvOsm4bOAVrjyvh BGTgV5XWhKZnVwOosOLflCyqHwCeusJI/skZS75yOntmDdztWXsUu8Rl5rAFgkfCvJdA 2+VlHMvMyHA+A0t4LpE/Y5E0TzTbGPo1raY0oPfjjo72VkRWjfy2UWfDbCvEeXp04t9P t21+2mJcVw4LVdu2q652vrgQz0kzmwVZMvqSAiA3vi0p7VFUlr+N9rKVTCJklgCKipmj BcDcJVrMYnsEt2TbXuJKW0j/vGw5QlUuV9T7KAMOVNT5aU4usMAtOL4mXdggm56egoiZ 9kXw== X-Gm-Message-State: ALoCoQlUGegwYeKpGquYCjG6Rwu10nZ9zGku9hDshiEa9/7kTMVVDXJU/oN9fkYuVxKk3UK8uqmb MIME-Version: 1.0 X-Received: by 10.224.40.202 with SMTP id l10mr47182271qae.7.1417025870453; Wed, 26 Nov 2014 10:17:50 -0800 (PST) Received: by 10.140.37.52 with HTTP; Wed, 26 Nov 2014 10:17:50 -0800 (PST) Date: Wed, 26 Nov 2014 10:17:50 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pc1cZs0i3ueRkYCO-rPARV4QzZ0 Subject: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:17:54 -0000 Hi, There are some unresolved issues related to basic RESTCONF session monitoring. The WG agreed to define a "restconf-tls" identity that can be used for the 'transport' leaf in the NETCONF "session" list. Some solution options from here: S1) do nothing; let vendors populate session entries and increment counters any way they want S2) specify some details like which counters to increment, but let vendors decide how to determine a session that should be added to the list S3) specify all details including how to determine a session that should be added to the list Issues: I1) the server may not be able to detect persistent connections depending on the implementation. Is it possible to define S3 without considering implementation details? I2) the server needs to create the session monitoring entry right away, on the first request. The session may only last 1 request/response pair. Is this an issue? I3) RESTCONF is not designed to support or require the server to maintain session state. (Not REST-ful, remember?) A server should only be required to maintain sessions for a single request (where SSE long-poll notifications counts as a single request). I4) should the RESTCONF server only create session entries for long-lived SSE sessions? I5) should the server send netconf-session-start and netconf-session-end notifications for RESTCONF sessions? Comments: We need all RESTCONF sessions to get a session ID, show up in the monitoring and audit logs, because the configuration can be edited by RESTCONF. The netconf-config-change notification is always sent if RESTCONF changes the running datastore. Andy From nobody Wed Nov 26 12:42:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0A1A007C for ; Wed, 26 Nov 2014 12:42:06 -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 PUX_dWpaeZx3 for ; Wed, 26 Nov 2014 12:42:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030BE1A1B49 for ; Wed, 26 Nov 2014 12:42:03 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 20:41:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 20:41:40 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF #2: session monitoring Thread-Index: AQHQCaVPXGgdzz6O5U+oUKO0NtrCs5xzC6YA Date: Wed, 26 Nov 2014 20:41:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(479174003)(377454003)(189002)(24454002)(19580395003)(77096003)(77156002)(64706001)(50986999)(40100003)(92566001)(92726001)(101416001)(15202345003)(87936001)(46102003)(15975445006)(83506001)(120916001)(19580405001)(76176999)(122556002)(2656002)(36756003)(54356999)(20776003)(15395725005)(62966003)(97736003)(99396003)(105586002)(106116001)(106356001)(31966008)(66066001)(107886001)(107046002)(4396001)(1720100001)(99286002)(95666004)(86362001)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <67B5449C63D79C4A8729711945CD0810@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rivHpXJktGJML6yF4hSZgtJ6sWg Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 20:42:06 -0000 OK, I realize my folly in hoping we could leverage the TLS transport-level connection to derive a session. In particular, it fails if all the TLS connections are terminated by a load-balancer fronting a rack of HTTP-only application servers. So the next thing is if RESTCONF can leverage a cookie to derive a session (session exists so long as cookie is valid). Note the abstract for RFC 6265 (HTTP State Management Mechanism) says: This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. ^^^^^^^^^^^^^^^^^ This StackOverflow response is notable: http://stackoverflow.com/a/6068298 Also notable:=20 http://www.kaleidos.net/blog/295/stateless-authentication-with-api-rest/ So, for S3, it seems the choices are: K1: do nothing K2: use a cookie for session-tracking only (not auth), assume BasicAuth is mandatory-to-implement, but allow others K3: use a cookie for both auth and session-tracking, - RESTCONF would define specific login/logout resources Anything else? Kent On 11/26/14, 1:17 PM, "Andy Bierman" wrote: >Hi, > >There are some unresolved issues related to basic RESTCONF >session monitoring. The WG agreed to define a "restconf-tls" >identity that can be used for the 'transport' leaf in the >NETCONF "session" list. > >Some solution options from here: > >S1) do nothing; let vendors populate session entries and increment >counters any way they want > >S2) specify some details like which counters to increment, but >let vendors decide how to determine a session that should >be added to the list > >S3) specify all details including how to determine a session that should >be added to the list > >Issues: > >I1) the server may not be able to detect persistent connections >depending on the implementation. Is it possible to define S3 >without considering implementation details? > >I2) the server needs to create the session monitoring entry >right away, on the first request. The session may only last 1 >request/response pair. Is this an issue? > >I3) RESTCONF is not designed to support or require the server >to maintain session state. (Not REST-ful, remember?) >A server should only be required to maintain sessions for >a single request (where SSE long-poll notifications counts >as a single request). > >I4) should the RESTCONF server only create session >entries for long-lived SSE sessions? > >I5) should the server send netconf-session-start and >netconf-session-end notifications for RESTCONF sessions? > > >Comments: > >We need all RESTCONF sessions to get a session ID, show up >in the monitoring and audit logs, because the configuration >can be edited by RESTCONF. The netconf-config-change >notification is always sent if RESTCONF changes the running datastore. > > >Andy > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Nov 26 14:17:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5599F1A3BA0 for ; Wed, 26 Nov 2014 14:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 rVdGDFU9DY98 for ; Wed, 26 Nov 2014 14:17:09 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1DA1A3B9D for ; Wed, 26 Nov 2014 14:17:09 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so3059673qcw.37 for ; Wed, 26 Nov 2014 14:17:09 -0800 (PST) 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=Q36AEmgsSir7aspX2c03umd6YWXphC3VoE824cHfBhQ=; b=E96uDoYCoDt+U/yO4oBYeuF2vD5zNKtgJtCwcp1fgV92K5yLTol7XtsvK4u3XU5yrM xpNFTdZvmPsviY4YYTDywEc4pPo50XUO2cLrQ8KzR3lwSIoyQXd9Mywszffq4DJQgAkb uSsiQsyc0EhLTCDmX9kQIHLJXG96COMtjqqr/ooWxI+uipMgwhtKaoSJ6Y92I34dGcRt q1yhMZ4Z5hgZtT7oozKugfxBnwX5ZG8kKJMGy+8rABdZg2jhBJepXwdum6PnsxCmlYXE 8vRmbocmxc88YoLeR+iRa+DCr98k6w210k2lUsTLLfM2U3SiK1Q1t0ujP9Il1UKPSWpt OWzA== X-Gm-Message-State: ALoCoQmY0lEmxYEZMhQvyvVn/Z3XrCkHX9A19w3UzNPxKZWT5beQxgmyqXSRwd2rX8glpkrYq1Yr MIME-Version: 1.0 X-Received: by 10.224.25.79 with SMTP id y15mr1102278qab.78.1417040229005; Wed, 26 Nov 2014 14:17:09 -0800 (PST) Received: by 10.140.37.52 with HTTP; Wed, 26 Nov 2014 14:17:08 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Nov 2014 14:17:08 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-GKPMBW_J9Rj78Vp1OkDhA7zWpQ Cc: Netconf Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:17:12 -0000 On Wed, Nov 26, 2014 at 12:41 PM, Kent Watsen wrote: > > OK, I realize my folly in hoping we could leverage the TLS transport-level > connection to derive a session. In particular, it fails if all the TLS > connections are terminated by a load-balancer fronting a rack of HTTP-only > application servers. > > So the next thing is if RESTCONF can leverage a cookie to derive a session > (session exists so long as cookie is valid). Note the abstract for RFC > 6265 (HTTP State Management Mechanism) says: > > This document defines the HTTP Cookie and Set-Cookie header fields. > These header fields can be used by HTTP servers to store state > (called cookies) at HTTP user agents, letting the servers maintain a > stateful session over the mostly stateless HTTP protocol. > > ^^^^^^^^^^^^^^^^^ > > This StackOverflow response is notable: http://stackoverflow.com/a/6068298 > > Also notable: > http://www.kaleidos.net/blog/295/stateless-authentication-with-api-rest/ > > > So, for S3, it seems the choices are: > > K1: do nothing > K2: use a cookie for session-tracking only (not auth), > assume BasicAuth is mandatory-to-implement, but allow others > K3: use a cookie for both auth and session-tracking, > - RESTCONF would define specific login/logout resources > > Anything else? > > The original task was simply to identify SSE sessions because these are the only long-lived RESTCONF "sessions". We currently store all RESTCONF sessions in the session list, because the server instrumentation can block, so even a 1 request session can be a long-lived session. In the multi-threaded build, other sessions will still be running, and the RESTCONF session will be visible. IMO it is OK if a server treats 1 request as a session or N requests as a session, so picking S2 is good enough. > Kent > Andy > > > > > On 11/26/14, 1:17 PM, "Andy Bierman" wrote: > >>Hi, >> >>There are some unresolved issues related to basic RESTCONF >>session monitoring. The WG agreed to define a "restconf-tls" >>identity that can be used for the 'transport' leaf in the >>NETCONF "session" list. >> >>Some solution options from here: >> >>S1) do nothing; let vendors populate session entries and increment >>counters any way they want >> >>S2) specify some details like which counters to increment, but >>let vendors decide how to determine a session that should >>be added to the list >> >>S3) specify all details including how to determine a session that should >>be added to the list >> >>Issues: >> >>I1) the server may not be able to detect persistent connections >>depending on the implementation. Is it possible to define S3 >>without considering implementation details? >> >>I2) the server needs to create the session monitoring entry >>right away, on the first request. The session may only last 1 >>request/response pair. Is this an issue? >> >>I3) RESTCONF is not designed to support or require the server >>to maintain session state. (Not REST-ful, remember?) >>A server should only be required to maintain sessions for >>a single request (where SSE long-poll notifications counts >>as a single request). >> >>I4) should the RESTCONF server only create session >>entries for long-lived SSE sessions? >> >>I5) should the server send netconf-session-start and >>netconf-session-end notifications for RESTCONF sessions? >> >> >>Comments: >> >>We need all RESTCONF sessions to get a session ID, show up >>in the monitoring and audit logs, because the configuration >>can be edited by RESTCONF. The netconf-config-change >>notification is always sent if RESTCONF changes the running datastore. >> >> >>Andy >> >>_______________________________________________ >>Netconf mailing list >>Netconf@ietf.org >>https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Nov 26 15:14:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893C11A8785 for ; Wed, 26 Nov 2014 15:14: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 scxPd5sbwHMJ for ; Wed, 26 Nov 2014 15:14:38 -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 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1D61A1EF4 for ; Wed, 26 Nov 2014 15:14:38 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 23:14:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 23:14:14 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] RESTCONF #2: session monitoring Thread-Index: AQHQCaVPXGgdzz6O5U+oUKO0NtrCs5xzC6YAgABufgD//7wjgA== Date: Wed, 26 Nov 2014 23:14:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(77096003)(77156002)(50986999)(64706001)(40100003)(92726001)(101416001)(87936001)(46102003)(120916001)(83506001)(76176999)(122556002)(36756003)(2656002)(54356999)(20776003)(62966003)(99396003)(97736003)(105586002)(106116001)(106356001)(66066001)(4396001)(107046002)(99286002)(95666004)(110136001)(21056001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/j3qXsKChfSFmHq3wW8aSCjz9pqM Cc: Netconf Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:14:40 -0000 >The original task was simply to identify SSE sessions because >these are the only long-lived RESTCONF "sessions". Tracking just SSE sessions is so non-intuitive and somewhat pointless. What people want is some means to be aware of all the different "sessions" going on, not just the never-ending responses. I know we're struggling with the stateless-server constraint, but the articles I linked before are pretty pragmatic. >We currently store all RESTCONF sessions in the session list, >because the server instrumentation can block, so even a 1 request >session can be a long-lived session. In the multi-threaded build, >other sessions will still be running, and the RESTCONF session >will be visible. You mean that each REST API entry point is something like this: Foobar() { session_id =3D start_session(); // do bis logic here close_session(session_id); return HTTP_response; } So even short-lived responses show up as a session temporarily? >IMO it is OK if a server treats 1 request as a session or N requests >as a session, so picking S2 is good enough. Assuming cookies are needed to track sessions correctly, there would be a requirement for clients to implement the "Set-Cookie" and "Cookie" header fields from RFC 6265. Can we at least say that servers MAY use cookies? (i.e. clients MUST support) Having been thru a Common Criteria certification before, I'm painfully aware that every login and logout event needs to be logged, in addition to the actions performed. Without some form of a session, my understanding is that BasicAuth leads to 2/3-rds of the audit log being "login" and "logout" events, which doesn't match common expectations. Others must have experience with this, should we ask the Apps folks for advice? Thanks, Kent From nobody Wed Nov 26 15:41:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974121A87EE for ; Wed, 26 Nov 2014 15:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 WK0TH5pNaAjb for ; Wed, 26 Nov 2014 15:40:59 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5F81A87F1 for ; Wed, 26 Nov 2014 15:40:57 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id l89so2848083qgf.10 for ; Wed, 26 Nov 2014 15:40:56 -0800 (PST) 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=6vUXm2CfzYV9e3F4HISNEpDANex+ihoTRqoDw6PGfA4=; b=fdRqvy8MkHLUA5GhEHkm6JobJvXzDL6v+r/FYQ2OKnrhBqBiidmvy8aZf5h4bBwMZo c3OVfOhkwP9CPDGw+ohpC5X4wm+qYKxrajmykzhzXIpr/mt3SmPNjxo2BU9WeNEB7fL2 BaZciVcIZUaev1dnQS9KrMAxoga6W7971Z+FCcaUfClBZipLj3dUb2ritcPVXvyFCcRy Lu4DfcX2vADEawMETN3Bm+3nVaOEZmiwCAFf1hRsl8AvPceKLlGSsqnCNJrtQbBbZs7+ Ljjmj5eZiGfXVR4XbrZu0Phg80kqIqaQyvpbGM9USy7sKZlCOuXqJLtm+4ejSvt2aj7r qwRw== X-Gm-Message-State: ALoCoQm5j6GTZ8V77YAwtpXfp9p0mUY/EpGOB46BZU+mcaOzl3APJR4yhjWuGQn/rTvC8I7lsYV8 MIME-Version: 1.0 X-Received: by 10.224.37.67 with SMTP id w3mr50866334qad.88.1417045255990; Wed, 26 Nov 2014 15:40:55 -0800 (PST) Received: by 10.140.37.52 with HTTP; Wed, 26 Nov 2014 15:40:55 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Nov 2014 15:40:55 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MqRG-TdQ9I7mp6b5k12VAYgMzWs Cc: Netconf Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:41:00 -0000 On Wed, Nov 26, 2014 at 3:14 PM, Kent Watsen wrote: > >>The original task was simply to identify SSE sessions because >>these are the only long-lived RESTCONF "sessions". > > Tracking just SSE sessions is so non-intuitive and somewhat pointless. > What people want is some means to be aware of all the different "sessions" > going on, not just the never-ending responses. I know we're struggling > with the stateless-server constraint, but the articles I linked before are > pretty pragmatic. > > > >>We currently store all RESTCONF sessions in the session list, >>because the server instrumentation can block, so even a 1 request >>session can be a long-lived session. In the multi-threaded build, >>other sessions will still be running, and the RESTCONF session >>will be visible. > > You mean that each REST API entry point is something like this: > > Foobar() { > session_id = start_session(); > > // do bis logic here > > close_session(session_id); > return HTTP_response; > } > > So even short-lived responses show up as a session temporarily? > yes (except the response is sent before the session is closed) > > >>IMO it is OK if a server treats 1 request as a session or N requests >>as a session, so picking S2 is good enough. > > Assuming cookies are needed to track sessions correctly, there would be a > requirement for clients to implement the "Set-Cookie" and "Cookie" header > fields from RFC 6265. Can we at least say that servers MAY use cookies? > (i.e. clients MUST support) > IMO it should be left as an implementation detail. If not, then we should stick with the original decision to not have any standard RESTCONF session monitoring at all for now. > > Having been thru a Common Criteria certification before, I'm painfully > aware that every login and logout event needs to be logged, in addition to > the actions performed. Without some form of a session, my understanding > is that BasicAuth leads to 2/3-rds of the audit log being "login" and > "logout" events, which doesn't match common expectations. Others must > have experience with this, should we ask the Apps folks for advice? > OK -- we record username and timestamp + edit details. The session-id number is not very interesting. > Thanks, > Kent > Andy From mohammad.tanvir@mango.com.bd Thu Nov 27 17:43:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460001A0387 for ; Thu, 27 Nov 2014 17:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofmvj9Z6DTsd for ; Thu, 27 Nov 2014 17:43:09 -0800 (PST) Received: from mailbox.mango.com.bd (mailbox.mango.com.bd [114.130.4.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7271A0302 for ; Thu, 27 Nov 2014 17:43:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailbox.mango.com.bd (Postfix) with ESMTP id 2E29C12A1A02 for ; Fri, 28 Nov 2014 07:43:08 +0600 (BDT) X-Virus-Scanned: amavisd-new at mailbox.mango.com.bd Received: from mailbox.mango.com.bd ([127.0.0.1]) by localhost (mailbox.mango.com.bd [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bSFDQODnbUhD for ; Fri, 28 Nov 2014 07:43:07 +0600 (BDT) Received: from mailbox.mango.com.bd (mailbox.mango.com.bd [114.130.4.9]) by mailbox.mango.com.bd (Postfix) with ESMTP id 64DB912A198E for ; Fri, 28 Nov 2014 07:43:07 +0600 (BDT) Date: Fri, 28 Nov 2014 07:43:07 +0600 (BDT) From: Mohammad Tanvir Parvez To: netconf@ietf.org Message-ID: <97513010.499395.1417138987325.JavaMail.root@mango.com.bd> In-Reply-To: <1473176466.499290.1417138818206.JavaMail.root@mango.com.bd> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_499394_1668978932.1417138987325" X-Originating-IP: [114.130.10.3] X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraWebClient - GC38 (Win)/8.0.0_GA_5434) Thread-Topic: hello Thread-Index: jh0a70/HWQgVVvqqBIZAe8ymwB4I2w== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6B4lADsxEDFTBLS53phByAMtAUs Subject: [Netconf] hello X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 01:50:16 -0000 ------=_Part_499394_1668978932.1417138987325 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear All, I am your new group member. Thanks in advance for your co-operation. With Regards, Mohammad Tanvir Parvez Engineer (O&M) Mango Teleservices Limited M: +8801755632858 || Skype: mohammadtanvirparvez LinkedIn: https://www.linkedin.com/profile/view?id=234687776&trk=nav_responsive_tab_profile Facebook: https://www.facebook.com/mohammadtanvirparvezneo ------=_Part_499394_1668978932.1417138987325 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear A= ll,

I = am your new group member.

Thanks in  a= dvance for your co-operation.



<= /div>
With= Regards,

Moh= ammad Tanvir Parvez

Engineer (O&M)

Mango Teleservices Limited

M: +8801755632858 || Skype: mohammadtanvirparvez=


<= /div>
Facebook: https://www.facebook.com/mohammadtanvirparvezneo
------=_Part_499394_1668978932.1417138987325-- From nobody Thu Nov 27 22:37:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD381A1A4C for ; Thu, 27 Nov 2014 22:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 r9T-KZnoC6iC for ; Thu, 27 Nov 2014 22:37:23 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706021A1A2E for ; Thu, 27 Nov 2014 22:37:23 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so4336611qcz.38 for ; Thu, 27 Nov 2014 22:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yVMHv9QAQGrnSebsP5BQWY6u70AWsAMDhk2DGS+QR10=; b=bkCXnZn/CKJ08XeyB6g1WUqNmAd0mvzvmy5pQA8hmsQ5p2QLIjX0/kSAg0RQtE7y8m pKEOOeFNCOpTjrQfsrR3CgkWtOGhjG7hqjxIYdwsAqSnm6ZgT21XcH3GH8+qCQvJPK99 sPjYmT4cIwcEPF/GhRVOhm8QGC1x1DiS95KYN6kX6nrKy4btgOCCSFtEj36iRDRcRVWb FySY5v2/93kLHwW6e5gGgDhuCsb1XVhO2GzirrybwEz7+Uz/0W+iegp3OCM7wnOv6TxI 64efsTmfUB+DWafT0ZSEtTmfAh3rZqvVXz3igC15xu6ukiebSOaYteEctXFWFl942okh 8mmA== MIME-Version: 1.0 X-Received: by 10.140.21.230 with SMTP id 93mr59923159qgl.81.1417156642727; Thu, 27 Nov 2014 22:37:22 -0800 (PST) Received: by 10.140.151.132 with HTTP; Thu, 27 Nov 2014 22:37:22 -0800 (PST) Date: Fri, 28 Nov 2014 12:07:22 +0530 Message-ID: From: Sangita Rajankar To: Netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11c1503647ee000508e57e41 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xPj0RqbdX9uBg53RTLU0ltPCGHo Subject: [Netconf] removal of my email id X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 06:37:24 -0000 --001a11c1503647ee000508e57e41 Content-Type: text/plain; charset=UTF-8 Requested to kindly remove my email id from the mailing list. -- *Mrs. Sangita P. Rajankar* Associate Scientist, Maharashtra Remote Sensing Applications Center (MRSAC), Nagpur - 440 011 Phone - 0712-2220086 Ext : 28 Mobile No. - 9325297336 --001a11c1503647ee000508e57e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Requested to kindly remove my email id from the mailing li= st.

--
<= div>Mrs. Sangita P. Rajankar
Associate Scientist,
Maharashtra Remote Sensing Applications Center (MRSAC),
Nagpur - 440 011
Phone - 0712-2220086=C2=A0 Ext : 28
Mobile No. - 9325297336
=C2=A0
--001a11c1503647ee000508e57e41-- From nobody Sat Nov 29 08:12:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5AB1A1A27 for ; Sat, 29 Nov 2014 08:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, 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 YGrkwDbDoas8 for ; Sat, 29 Nov 2014 08:12:54 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690F41A0070 for ; Sat, 29 Nov 2014 08:12:54 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so5796196qcz.38 for ; Sat, 29 Nov 2014 08:12:53 -0800 (PST) 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=VYZpPUTYdBXG6wZcvkyO/XwMXg8EYB9uLg8E1q5wZwc=; b=N3uAZAijnmvC/XtNJq8m0IqQszgY6TLEldWBdkQ2yawkwqoQMhueMvUGI1yeTNFzNf eqeXoiCSK5gz3ouP3inuNytkVUoTseSsORymRmz1dthNzUMEcE0a7xOW81nW9e1El1yP XuQmNppnHgb0lb7XVQ4I+dwOHuSUE1xQ1qA2+QCE8FkgJSJaQSB5WDYaVjfouMrHiTnT uDAeoPJ43NmqGAEJfAynzE7Jh0/CFPwtLt0cJZY9OA0rbtxEQa5oGgLeF3SxGODROUQQ dVdjBWxSE26ryscggrGE3Eb45J4LXkkxYkex/7jv35qyNwrvolPh05yAgbTU1DwoPRXE ys4w== X-Gm-Message-State: ALoCoQllDoE4JFNXCVKxTDjMzhyA8+FQsR9TsFRQvZY4ryTjmWZyPn00U40On15aZYXK9fb2rVOU MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr70526331qgd.36.1417277573388; Sat, 29 Nov 2014 08:12:53 -0800 (PST) Received: by 10.140.37.52 with HTTP; Sat, 29 Nov 2014 08:12:53 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Nov 2014 08:12:53 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2Bdbgqu2O0eAvF8wwDGKL8isx5Y Cc: Netconf Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 16:12:56 -0000 Hi, There doesn't seem to be much interest in this issue. The original WG decision is to just define a "restconf-tls" identity for the session "transport" leaf. IMO the original consensus of "punt this until later" is confirmed. That would be solution S1. Andy On Wed, Nov 26, 2014 at 3:14 PM, Kent Watsen wrote: > >>The original task was simply to identify SSE sessions because >>these are the only long-lived RESTCONF "sessions". > > Tracking just SSE sessions is so non-intuitive and somewhat pointless. > What people want is some means to be aware of all the different "sessions" > going on, not just the never-ending responses. I know we're struggling > with the stateless-server constraint, but the articles I linked before are > pretty pragmatic. > > > >>We currently store all RESTCONF sessions in the session list, >>because the server instrumentation can block, so even a 1 request >>session can be a long-lived session. In the multi-threaded build, >>other sessions will still be running, and the RESTCONF session >>will be visible. > > You mean that each REST API entry point is something like this: > > Foobar() { > session_id = start_session(); > > // do bis logic here > > close_session(session_id); > return HTTP_response; > } > > So even short-lived responses show up as a session temporarily? > > > >>IMO it is OK if a server treats 1 request as a session or N requests >>as a session, so picking S2 is good enough. > > Assuming cookies are needed to track sessions correctly, there would be a > requirement for clients to implement the "Set-Cookie" and "Cookie" header > fields from RFC 6265. Can we at least say that servers MAY use cookies? > (i.e. clients MUST support) > > > Having been thru a Common Criteria certification before, I'm painfully > aware that every login and logout event needs to be logged, in addition to > the actions performed. Without some form of a session, my understanding > is that BasicAuth leads to 2/3-rds of the audit log being "login" and > "logout" events, which doesn't match common expectations. Others must > have experience with this, should we ask the Apps folks for advice? > > Thanks, > Kent > From nobody Sat Nov 29 08:23:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1801A1B20 for ; Sat, 29 Nov 2014 08:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 sbDFk2_amaVg for ; Sat, 29 Nov 2014 08:23:41 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9FB1A1B1E for ; Sat, 29 Nov 2014 08:23:41 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id w8so5454788qac.23 for ; Sat, 29 Nov 2014 08:23:41 -0800 (PST) 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=not3JaSz74ki+tBK6MPnMlmFrDedR8BkZ4WGh2mynp8=; b=icyb7a+UOElg3KL2wYAE5qAk8rASE4cNWUARpk105vvU+YKLh81GEgLojEaHjXMjK1 E7cZL06jjF2Enm17qGMCUCxJc/mrOL1Iyer/P8ky3Q6GSUE/Z3w+MeE82ZH4voFevlm0 qx+zw2Z85I3e1Okpz5iS4iB2YTDFOj9BI/DaPiMI+JJaJlflaZPMnbvkaXh7tx3UO4ZA +DD3S6GCj1ZdvSlGFUGqqjWswsnDyDcPWKw7C/i6nv5jhcqa5blee5psA4gdYsdCZiLi EZmSnQJvlKnixlThiQVxo91+ZaVOYt0oGW1Aq1wbTIvyCcZ37IOjQ2ZhVtOKMI6GgO9X 4FsQ== X-Gm-Message-State: ALoCoQn0uY/EuXTPYkGGaDcPyBgAvcjuXK+iJEJTCY70diWd7LzeIY3OftyGKVrYv/AjPbFSo6GA MIME-Version: 1.0 X-Received: by 10.229.104.199 with SMTP id q7mr19872166qco.8.1417278220929; Sat, 29 Nov 2014 08:23:40 -0800 (PST) Received: by 10.140.37.52 with HTTP; Sat, 29 Nov 2014 08:23:40 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Nov 2014 08:23:40 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FoSuNZNEyXDifcM8QJgcVfOewDk Cc: Netconf Subject: Re: [Netconf] RESTCONF #2: session monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 16:23:43 -0000 On Wed, Nov 26, 2014 at 3:14 PM, Kent Watsen wrote: > >>The original task was simply to identify SSE sessions because >>these are the only long-lived RESTCONF "sessions". > > Tracking just SSE sessions is so non-intuitive and somewhat pointless. > What people want is some means to be aware of all the different "sessions" > going on, not just the never-ending responses. I know we're struggling > with the stateless-server constraint, but the articles I linked before are > pretty pragmatic. > I don't think tracking SSE sessions is pointless, especially since the client has to initiate a "create-subscription" to receive notifications. If the operator wants to reboot the server, it might be good to know what SSE sessions are going to be terminated. I suppose the entire notion of RESTCONF sessions is non-intuitive, because only the server knows there is a session going on. Unlike NETCONF, the client does not actually start or close an application layer session. Andy > > >>We currently store all RESTCONF sessions in the session list, >>because the server instrumentation can block, so even a 1 request >>session can be a long-lived session. In the multi-threaded build, >>other sessions will still be running, and the RESTCONF session >>will be visible. > > You mean that each REST API entry point is something like this: > > Foobar() { > session_id = start_session(); > > // do bis logic here > > close_session(session_id); > return HTTP_response; > } > > So even short-lived responses show up as a session temporarily? > > > >>IMO it is OK if a server treats 1 request as a session or N requests >>as a session, so picking S2 is good enough. > > Assuming cookies are needed to track sessions correctly, there would be a > requirement for clients to implement the "Set-Cookie" and "Cookie" header > fields from RFC 6265. Can we at least say that servers MAY use cookies? > (i.e. clients MUST support) > > > Having been thru a Common Criteria certification before, I'm painfully > aware that every login and logout event needs to be logged, in addition to > the actions performed. Without some form of a session, my understanding > is that BasicAuth leads to 2/3-rds of the audit log being "login" and > "logout" events, which doesn't match common expectations. Others must > have experience with this, should we ask the Apps folks for advice? > > Thanks, > Kent > From nobody Sun Nov 30 03:55:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D61A0065 for ; Sun, 30 Nov 2014 03:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE-wvLS6gAbF for ; Sun, 30 Nov 2014 03:55:43 -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 110DC1A0067 for ; Sun, 30 Nov 2014 03:55:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 841601047 for ; Sun, 30 Nov 2014 12:55:41 +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 3_okepwCy3_T for ; Sun, 30 Nov 2014 12:55: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 for ; Sun, 30 Nov 2014 12:55:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E447320034 for ; Sun, 30 Nov 2014 12:55:40 +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 CH20_EMzmwH8; Sun, 30 Nov 2014 12:52:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 268932002C; Sun, 30 Nov 2014 12:55:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E9A572FDAFA4; Sun, 30 Nov 2014 12:55:39 +0100 (CET) Date: Sun, 30 Nov 2014 12:55:39 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20141130115539.GA13546@elstar.local> Mail-Followup-To: netconf@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: http://mailarchive.ietf.org/arch/msg/netconf/yrO-48IuYtlpzF__FJsCTQ08NSc Subject: [Netconf] restconf notifications - SSE vs HTTP 2.0 push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 11:55:48 -0000 Hi, the restconf I-D has text about using Server-Send Events (SSE) for event notifications but there is no normative reference for SSE. I assume I have to look at . I am wondering whether this is the proper way to go since we have HTTP 2.0 coming up as well. - Looking at , has someone verified that the encoding works with all possible content? - Since HTTP 2.0 will likely supports unsolicited push responses, would that not be a much cleaner solution for event notifications? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Nov 30 20:53:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80D1A19F2 for ; Sun, 30 Nov 2014 20:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYNmA9A6KdwA for ; Sun, 30 Nov 2014 20:53:23 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35461A0AFE for ; Sun, 30 Nov 2014 20:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1324; q=dns/txt; s=iport; t=1417409603; x=1418619203; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uGY1jWNpk5xHakLmm98EoXZ3hvtj4x6QT7Tvz8Ehogc=; b=Mfa0JRzDrgSSi7dS+z5b/yhTfsbOwKFt6cPHiWyrN8iWX3Ic9tmQGD2d lIeDCrePc15vIBAe70rdDn+E5ktI/yFpqDpqu19zHtniW4OEWmIYN21cY CLCE2B7uVMTfmCDCfu/HtQl273lrE14C1dyjPKZ+Cm1P2YeGbYSVtNQiW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAM3ye1StJV2c/2dsb2JhbABYA4MGUVgExnMKhXhWAoEQFgEBAQEBfYQDAQEEAQEBNzQJEAICAQgOAiYQGwwLJQIEARIbiCUN0WkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJBnFxGENwWRBYRNhnWVQ4N7b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="101392458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 01 Dec 2014 04:53:22 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sB14rM41011717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 04:53:22 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.11]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 22:53:22 -0600 From: "Reinaldo Penno (repenno)" To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] restconf notifications - SSE vs HTTP 2.0 push Thread-Index: AQHQDJSeMd713q5unkGLFmxs/lFajJx6CsWA Date: Mon, 1 Dec 2014 04:53:22 +0000 Message-ID: References: <20141130115539.GA13546@elstar.local> In-Reply-To: <20141130115539.GA13546@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.24.129.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GHgqXgeJ0nHBnudpYbimCEdgats Subject: Re: [Netconf] restconf notifications - SSE vs HTTP 2.0 push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 04:53:25 -0000 I think it will be a loooong time before HTTP 2.0 find its way into all browsers, Java/Python/C/other libraries and servers into significant numbers. The installed base is just too large. We should focus on what we can deploy with HTTP 1.1. Thanks, Reinaldo On 11/30/14, 3:55 AM, "Juergen Schoenwaelder" wrote: >Hi, > >the restconf I-D has text about using Server-Send Events (SSE) for >event notifications but there is no normative reference for SSE. I >assume I have to look at . I am >wondering whether this is the proper way to go since we have HTTP 2.0 >coming up as well. > >- Looking at , has someone > verified that the encoding works with all possible content? > >- Since HTTP 2.0 will likely supports unsolicited push responses, > would that not be a much cleaner solution for event notifications? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf