From nobody Sun Sep 3 21:20:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35D133245 for ; Sun, 3 Sep 2017 21:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Niu3kcB7sOtv for ; Sun, 3 Sep 2017 21:19:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F0B135FFC for ; Sun, 3 Sep 2017 20:58:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUS15204; Mon, 04 Sep 2017 03:58:41 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 4 Sep 2017 04:58:40 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 4 Sep 2017 11:58:33 +0800 From: Qin Wu To: Kent Watsen , "netconf@ietf.org" Thread-Topic: WG adoption poll draft-zheng-netconf-udp-pub-channel-00 Thread-Index: AQHTGslpu+5gO8PnQEm3VBneSJzb9qKPmyOggBSTNSA= Date: Mon, 4 Sep 2017 03:58:32 +0000 Message-ID: References: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8E8D3F56@dggemm512-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8E8D3F56@dggemm512-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.163] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59ACCF71.008F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c97029b2f4632662aa5552819ecf60a6 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 04:19:56 -0000 WWVzL1N1cHBvcnQuDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTmV0Y29uZiBbbWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBLZW50IFdhdHNlbg0Kt6LLzcqxvOQ6IDIw MTfE6jjUwjIyyNUgNjowNA0KytW8/sjLOiBuZXRjb25mQGlldGYub3JnDQrW98ziOiBbTmV0Y29u Zl0gV0cgYWRvcHRpb24gcG9sbCBkcmFmdC16aGVuZy1uZXRjb25mLXVkcC1wdWItY2hhbm5lbC0w MA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28td2VlayBwb2xsIG9uIG1ha2luZyB0 aGUgZm9sbG93aW5nIGRyYWZ0IGEgTkVUQ09ORiB3b3JraW5nIGdyb3VwIGRvY3VtZW50Og0KDQog IGRyYWZ0LXpoZW5nLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLTAwIFsxXQ0KDQpQbGVhc2Ugc2Vu ZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5v dCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0 aW9ucyB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRv IHByb3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRv Y3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGVuZy1uZXRjb25mLXVkcC1wdWItY2hhbm5lbC0wMA0KDQoNClRoYW5rIHlv dSwNCktlbnQgKGFuZCBNYWhlc2gpDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWls aW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0K From nobody Sun Sep 3 21:20:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126CB1331D2 for ; Sun, 3 Sep 2017 21:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt7aKLfbCyWx for ; Sun, 3 Sep 2017 21:19:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F218136051 for ; Sun, 3 Sep 2017 20:59:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNV77895; Mon, 04 Sep 2017 03:59:46 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 4 Sep 2017 04:59:45 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 4 Sep 2017 11:59:39 +0800 From: Qin Wu To: Kent Watsen , "netconf@ietf.org" Thread-Topic: WG adoption poll draft-voit-netconf-notification-messages-01 Thread-Index: AQHTGsmq2KiStu0LpUC+dtqUvYwssaKkLtTw Date: Mon, 4 Sep 2017 03:59:39 +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.136.79.163] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59ACCFB2.00E1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 708641c87858eee99a79e8b16a15f773 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 04:20:01 -0000 WWVzL3N1cHBvcnQuDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTmV0Y29uZiBbbWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBLZW50IFdhdHNlbg0Kt6LLzcqxvOQ6IDIw MTfE6jjUwjIyyNUgNjowNg0KytW8/sjLOiBuZXRjb25mQGlldGYub3JnDQrW98ziOiBbTmV0Y29u Zl0gV0cgYWRvcHRpb24gcG9sbCBkcmFmdC12b2l0LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3Nh Z2VzLTAxDQoNCg0KQWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvLXdlZWsgcG9sbCBvbiBt YWtpbmcgdGhlIGZvbGxvd2luZyBkcmFmdCBhIE5FVENPTkYgd29ya2luZyBncm91cCBkb2N1bWVu dDoNCg0KICBkcmFmdC12b2l0LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLTAxIFsxXQ0K DQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIg b3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5 b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28g ZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2Vk IG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNCg0KWzFdIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtdm9pdC1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy0w MQ0KDQoNClRoYW5rIHlvdSwNCktlbnQgKGFuZCBNYWhlc2gpDQoNCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5n IGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0K From nobody Mon Sep 4 00:56:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627A51320BD; Mon, 4 Sep 2017 00:56:03 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zs48PMzt0UG; Mon, 4 Sep 2017 00:56:00 -0700 (PDT) Received: from iron01.fraunhofer.de (iron01.fraunhofer.de [153.96.1.54]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF999126DD9; Mon, 4 Sep 2017 00:55:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2E3AwBSBq1Z/xoHYZlcGwEBAQMBAQEJAQEBg1pkgRUHg3CaPYFxljaCBAojhRsChBlXAQIBAQEBAQIDaCiCZUZYAQEBAQEBIwI+LAEBAiYPAQU/AgwNAg4DAQMBAQMCIwMCSAECBg4BDAEFAgEBiiwFAQuYJJ1mgieLTQEBAQEBAQQBAQEBAQEBAQEaBYENgh2CAoFOgWMrgn2EQgESAYMygmEFoHSBB4EnhS2PCYVng1UFhx2UfgIDBgUCGAGBOVhBQQtTJV2HHXSIbYEjAYEOAQEB X-IPAS-Result: A2E3AwBSBq1Z/xoHYZlcGwEBAQMBAQEJAQEBg1pkgRUHg3CaPYFxljaCBAojhRsChBlXAQIBAQEBAQIDaCiCZUZYAQEBAQEBIwI+LAEBAiYPAQU/AgwNAg4DAQMBAQMCIwMCSAECBg4BDAEFAgEBiiwFAQuYJJ1mgieLTQEBAQEBAQQBAQEBAQEBAQEaBYENgh2CAoFOgWMrgn2EQgESAYMygmEFoHSBB4EnhS2PCYVng1UFhx2UfgIDBgUCGAGBOVhBQQtTJV2HHXSIbYEjAYEOAQEB X-IronPort-AV: E=Sophos;i="5.41,473,1498514400"; d="scan'208";a="99129058" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by iron01.fraunhofer.de with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Sep 2017 09:55:57 +0200 X-IronPort-AV: E=Sophos;i="5.41,473,1498514400"; d="scan'208";a="260160717" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2017 09:55:54 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v847tqJk011648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Sep 2017 09:55:53 +0200 Received: from [10.119.133.32] (141.12.129.132) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Sep 2017 09:55:46 +0200 From: Henk Birkholz To: Kent Watsen , CC: Message-ID: Date: Mon, 4 Sep 2017 09:55:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [141.12.129.132] Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 07:56:03 -0000 Hi, I support this document to be adopted by the WG. A few comments: The header objects align well with the content-element metadata in the SACM WG. At the last Hackathon (in Prague) we showed interoperability between the SACM architecture and YANG push provided content. This draft would simplify the use cases even more in respect to automation and post-processing capabilities. If we can make the terminology and semantics of the header objects in notification messages and the SACM terminology/information model align, this also would simplify interoperability. The same is true, we assume, for interoperability with the Information Model for the Monitoring of Network Security Functions in the I2NSF WG. Viele Grüße, Henk > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Tuesday, August 22, 2017 6:06 AM > To: netconf@ietf.org > Subject: [Netconf] WG adoption poll > draft-voit-netconf-notification-messages-01> > > > All, > > This is start of a two-week poll on making the following draft a > NETCONF working group document: > > draft-voit-netconf-notification-messages-01 [1] > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > > [1] https://tools.ietf.org/id/draft-voit-netconf-notification-messages-01 > > > Thank you, > Kent (and Mahesh) From nobody Mon Sep 4 06:56:11 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB7132A81 for ; Mon, 4 Sep 2017 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3VdfTAY1Vfj for ; Mon, 4 Sep 2017 06:56:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B32132A1A for ; Mon, 4 Sep 2017 06:56:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNW65775; Mon, 04 Sep 2017 13:56:06 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 4 Sep 2017 14:56:05 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML701-CHM.china.huawei.com ([169.254.3.191]) with mapi id 14.03.0301.000; Mon, 4 Sep 2017 06:56:00 -0700 From: Igor Bryskin To: Kent Watsen , "netconf@ietf.org" Thread-Topic: WG adoption poll draft-zheng-netconf-udp-pub-channel-00 Thread-Index: AQHTGslpu+5gO8PnQEm3VBneSJzb9qKk1Dsg Date: Mon, 4 Sep 2017 13:55:59 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909C5A09B@SJCEML702-CHM.china.huawei.com> References: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> In-Reply-To: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59AD5B76.010B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b8c49f33eaa2e29a5bd3fe6fc55886e9 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 13:56:10 -0000 Hi, I support this draft. I believe it introduces important scalability/perform= ance improvements for the network telemetry streaming. Regards, Igor Bryskin =20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Monday, August 21, 2017 6:04 PM To: netconf@ietf.org Subject: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 All, This is start of a two-week poll on making the following draft a NETCONF working group document: draft-zheng-netconf-udp-pub-channel-00 [1] Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. [1] https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00 Thank you, Kent (and Mahesh) _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 4 14:14:30 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA71B1320DC; Mon, 4 Sep 2017 14:14:29 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtnlEg139quj; Mon, 4 Sep 2017 14:14:26 -0700 (PDT) Received: from iron02.fraunhofer.de (iron02.fraunhofer.de [153.96.1.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427821320B5; Mon, 4 Sep 2017 14:14:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2FtDQA0wa1Z/xoBYJldHAEBBAEBCgEBg1pkA4ESB4NwmkGBcZY2ggQKI4UbAoQdVwECAQEBAQECA2gogmVGWAEBAQEBASMCPiwBAQQkDwEFQQUHDQIOAwQBAQMCIwMCSAEIDgEMAQUCAQGKJQcFAQuTMZ1mgieLUwEBAQEBAQQBAQEBAQEBAQEaBYENgh2CAoFOgg6CfYRCARIBgzKCYQWgdIEHgSeFLY8JhWeDVQWHHZR+AgMGBQIYAYE5WIECC1MlXYUYHIFpdIkCgSMBgQ4BAQE X-IPAS-Result: A2FtDQA0wa1Z/xoBYJldHAEBBAEBCgEBg1pkA4ESB4NwmkGBcZY2ggQKI4UbAoQdVwECAQEBAQECA2gogmVGWAEBAQEBASMCPiwBAQQkDwEFQQUHDQIOAwQBAQMCIwMCSAEIDgEMAQUCAQGKJQcFAQuTMZ1mgieLUwEBAQEBAQQBAQEBAQEBAQEaBYENgh2CAoFOgg6CfYRCARIBgzKCYQWgdIEHgSeFLY8JhWeDVQWHHZR+AgMGBQIYAYE5WIECC1MlXYUYHIFpdIkCgSMBgQ4BAQE X-IronPort-AV: E=Sophos;i="5.41,476,1498514400"; d="scan'208";a="80814140" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Sep 2017 23:14:20 +0200 X-IronPort-AV: E=Sophos;i="5.41,476,1498514400"; d="scan'208";a="258970868" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2017 23:14:16 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v84LEFQ7010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Sep 2017 23:14:16 +0200 Received: from [172.16.222.47] (46.183.103.8) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Sep 2017 23:14:09 +0200 To: Kent Watsen , "netconf@ietf.org" CC: From: Henk Birkholz Message-ID: <4aa806ef-40fc-e556-40e7-138fa38a54df@sit.fraunhofer.de> Date: Mon, 4 Sep 2017 23:14:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [46.183.103.8] Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:14:29 -0000 yes/support This +1 comes with an request to align this work with the CORE WG, please. There are several drafts that focus on a related topic. First of all: > https://tools.ietf.org/wg/core/draft-ietf-core-comi/ and also: > https://tools.ietf.org/wg/core/draft-ietf-core-yang-cbor/ > https://tools.ietf.org/wg/core/draft-ietf-core-sid/ Viele Grüße, Henk -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Monday, August 21, 2017 6:04 PM > To: netconf@ietf.org > Subject: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 > > All, > > This is start of a two-week poll on making the following draft a > NETCONF working group document: > > draft-zheng-netconf-udp-pub-channel-00 [1] > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > > [1] https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00 > > > Thank you, > Kent (and Mahesh) > From nobody Mon Sep 4 18:01:28 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC56B1321B7; Mon, 4 Sep 2017 18:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz96_4MG_alF; Mon, 4 Sep 2017 18:01:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024501321A6; Mon, 4 Sep 2017 18:01:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNX29669; Tue, 05 Sep 2017 01:01:22 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 5 Sep 2017 02:01:21 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 5 Sep 2017 09:01:16 +0800 From: Tianran Zhou To: Henk Birkholz , Kent Watsen , "netconf@ietf.org" CC: "draft-zheng-netconf-udp-pub-channel@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 Thread-Index: AQHTJcLRtFC4+u7luU6ij/zMYFyicqKleFjA Date: Tue, 5 Sep 2017 01:00:53 +0000 Message-ID: References: <4aa806ef-40fc-e556-40e7-138fa38a54df@sit.fraunhofer.de> In-Reply-To: <4aa806ef-40fc-e556-40e7-138fa38a54df@sit.fraunhofer.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59ADF763.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ad0e13863e367fc0d2678f4196c78c89 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 01:01:27 -0000 SGkgSGVuaywNCg0KVGhhbmsgeW91LiANClN1cmUgd2Ugd2lsbCBjb25zaWRlciBvdGhlciByZWxh dGVkIHdvcmsuIA0KSSBhbSBzdHVkeWluZyB5b3VyIHBvaW50ZXJzLiBXaWxsIGdldCBiYWNrIHRv IHlvdSBzb29uLg0KDQpUaWFucmFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogSGVuayBCaXJraG9seiBbbWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIu ZGVdDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNSwgMjAxNyA1OjE0IEFNDQo+IFRvOiBL ZW50IFdhdHNlbjsgbmV0Y29uZkBpZXRmLm9yZw0KPiBDYzogZHJhZnQtemhlbmctbmV0Y29uZi11 ZHAtcHViLWNoYW5uZWxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBXRyBhZG9w dGlvbiBwb2xsDQo+IGRyYWZ0LXpoZW5nLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLTAwDQo+IA0K PiB5ZXMvc3VwcG9ydA0KPiANCj4gVGhpcyArMSBjb21lcyB3aXRoIGFuIHJlcXVlc3QgdG8gYWxp Z24gdGhpcyB3b3JrIHdpdGggdGhlIENPUkUgV0csIHBsZWFzZS4NCj4gVGhlcmUgYXJlIHNldmVy YWwgZHJhZnRzIHRoYXQgZm9jdXMgb24gYSByZWxhdGVkIHRvcGljLiBGaXJzdCBvZg0KPiBhbGw6 DQo+IA0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY29yZS9kcmFmdC1pZXRmLWNvcmUt Y29taS8NCj4gDQo+IGFuZCBhbHNvOg0KPiANCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL3dn L2NvcmUvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci8NCj4gPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL3dnL2NvcmUvZHJhZnQtaWV0Zi1jb3JlLXNpZC8NCj4gDQo+IFZpZWxlIEdyw7zDn2UsDQo+ IA0KPiBIZW5rDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9t OiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg S2VudA0KPiA+IFdhdHNlbg0KPiA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIxLCAyMDE3IDY6MDQg UE0NCj4gPiBUbzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtOZXRjb25mXSBXRyBh ZG9wdGlvbiBwb2xsDQo+ID4gZHJhZnQtemhlbmctbmV0Y29uZi11ZHAtcHViLWNoYW5uZWwtMDAN Cj4gPg0KPiA+IEFsbCwNCj4gPg0KPiA+IFRoaXMgaXMgc3RhcnQgb2YgYSB0d28td2VlayBwb2xs IG9uIG1ha2luZyB0aGUgZm9sbG93aW5nIGRyYWZ0IGENCj4gPiBORVRDT05GIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQ6DQo+ID4NCj4gPiAgIGRyYWZ0LXpoZW5nLW5ldGNvbmYtdWRwLXB1Yi1jaGFu bmVsLTAwIFsxXQ0KPiA+DQo+ID4gUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNh dGluZyAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3QNCj4gPiBzdXBwb3J0Ii4gIElmIGluZGlj YXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZQ0KPiA+IGRv Y3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50 cyB5b3UnZA0KPiA+IGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBh IFdHIGRvY3VtZW50Lg0KPiA+DQo+ID4NCj4gPiBbMV0NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoZW5nLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLTAwDQo+ID4NCj4gPg0K PiA+IFRoYW5rIHlvdSwNCj4gPiBLZW50IChhbmQgTWFoZXNoKQ0KPiA+DQo= From nobody Tue Sep 5 02:43:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B406E132392 for ; Tue, 5 Sep 2017 02:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyJ6PnkV9p0Q for ; Tue, 5 Sep 2017 02:43:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 23B2F13219C for ; Tue, 5 Sep 2017 02:43:18 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 18E9640026A for ; Tue, 5 Sep 2017 11:43:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504604597; bh=VQgSKwB/oej6vmPToWZCQslyrmO7bvUgg1XkzPLCz2s=; h=From:Subject:To:Date; b=hoS2gVqgz//iXuD9urVeqxscO8TN70R8JI8cJdZgtPThRsu79NL2iKAjGAfHeP0L/ o3ps/cTj8xY4UtjbSR2MguR9r7/bQXrPOkWlKSrIWtqM915cAiOBC6TLR2DTrkh2vP MaClV4SxnZ5XBlA9386RVhLcoLfbi/dmQqd1lq/A= From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= To: "netconf@ietf.org" Message-ID: Date: Tue, 5 Sep 2017 11:43:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 09:43:21 -0000 Hi, what is the idea behind the deprecated modules-state subtree in revised i= etf-yang-library schema? According to RFC, the deprecated node permits co= ntinued implementation because of interoperability. So, is the idea that = the data created according to the RFC7895, should work even with this sch= ema? And vice versa, that with the 7895bis, modes-state subtree is not ne= cessary and just yang-library subtree is enough? Because it does not curr= ently work this way. The modules-state as well as yang-library subtrees c= ontain mandatory nodes (module-set-id and checksum) so at least these nod= es are necessary to have in valid data. Am I wrong the the compatibility = idea or there should be a top-level choice? Regards, Radek From nobody Tue Sep 5 03:41:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80BB13291C for ; Tue, 5 Sep 2017 03:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJkZPYk_hKJO for ; Tue, 5 Sep 2017 03:40:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 8BA17132742 for ; Tue, 5 Sep 2017 03:40:55 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id F35D2400063 for ; Tue, 5 Sep 2017 12:40:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504608053; bh=RkA01QiJtPlEuSfMUNIrNx6CIjL+RuDFjwpizmVd/W8=; h=Subject:From:To:References:Date:In-Reply-To; b=b+6yEBY4DJma8QFkITzGbJ5iq0HZFvJ/mi7BCo4idx63M75V8NPc0SjTLC0SEa2k8 sIB09gIR9rLPFKQQKd2xrOFqNLj0W9lgqiUuxXbrxDwX8QZeCsZtPln8OZruefTVdh y5IMRQfrM/WOwMGOmEr0bwsvA5FVCf+pGIhaIKrM= From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= To: "netconf@ietf.org" References: Message-ID: Date: Tue, 5 Sep 2017 12:40:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 10:40:58 -0000 I'm going to try to answer myself :) The compatibility should be for clie= nts (old clients understand new servers), not for the servers (old server= generate data valid according to the new schema), so my idea was wrong. = The server is supposed to generate both subtrees (duplicating data) and c= lient can pick the subtree it understands. If I'm still not right, please= correct me. Radek Dne 5.9.2017 v 11:43 Radek Krej=E8=ED napsal(a): > Hi, > what is the idea behind the deprecated modules-state subtree in revised= ietf-yang-library schema? According to RFC, the deprecated node permits = continued implementation because of interoperability. So, is the idea tha= t the data created according to the RFC7895, should work even with this s= chema? And vice versa, that with the 7895bis, modes-state subtree is not = necessary and just yang-library subtree is enough? Because it does not cu= rrently work this way. The modules-state as well as yang-library subtrees= contain mandatory nodes (module-set-id and checksum) so at least these n= odes are necessary to have in valid data. Am I wrong the the compatibilit= y idea or there should be a top-level choice? > > Regards, > Radek > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 5 04:20:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD38B13292B for ; Tue, 5 Sep 2017 04:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsdFztdjzLb6 for ; Tue, 5 Sep 2017 04:19:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAB8132942 for ; Tue, 5 Sep 2017 04:19:52 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 72AD71AE02C9; Tue, 5 Sep 2017 13:19:50 +0200 (CEST) Date: Tue, 05 Sep 2017 13:18:16 +0200 (CEST) Message-Id: <20170905.131816.2135302521409049604.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 11:19:59 -0000 UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gSSdtIGdvaW5nIHRv IHRyeSB0byBhbnN3ZXIgbXlzZWxmIDopIFRoZSBjb21wYXRpYmlsaXR5IHNob3VsZCBiZSBmb3Ig Y2xpZW50cyAob2xkIGNsaWVudHMgdW5kZXJzdGFuZCBuZXcgc2VydmVycyksIG5vdCBmb3IgdGhl IHNlcnZlcnMgKG9sZCBzZXJ2ZXIgZ2VuZXJhdGUgZGF0YSB2YWxpZCBhY2NvcmRpbmcgdG8gdGhl IG5ldyBzY2hlbWEpLCBzbyBteSBpZGVhIHdhcyB3cm9uZy4gVGhlIHNlcnZlciBpcyBzdXBwb3Nl ZCB0byBnZW5lcmF0ZSBib3RoIHN1YnRyZWVzIChkdXBsaWNhdGluZyBkYXRhKSBhbmQgY2xpZW50 IGNhbiBwaWNrIHRoZSBzdWJ0cmVlIGl0IHVuZGVyc3RhbmRzLiBJZiBJJ20gc3RpbGwgbm90IHJp Z2h0LCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KVGhlIHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8g aW1wbGVtZW50IGRlcHJlY3RhdGVkIG5vZGVzLiAgNzk1MCBzYXlzOg0KDQogICBvICAiZGVwcmVj YXRlZCIgaW5kaWNhdGVzIGFuIG9ic29sZXRlIGRlZmluaXRpb24sIGJ1dCBpdCBwZXJtaXRzDQog ICAgICBuZXcvY29udGludWVkIGltcGxlbWVudGF0aW9uIGluIG9yZGVyIHRvIGZvc3RlciBpbnRl cm9wZXJhYmlsaXR5DQogICAgICB3aXRoIG9sZGVyL2V4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4N Cg0KVGhpcyB0ZXh0IGFwcGxpZXMgdG8gYm90aCBjbGllbnRzIGFuZCBzZXJ2ZXJzLg0KDQoNCg0K L21hcnRpbg0KDQoNCg0KDQo+IA0KPiBSYWRlaw0KPiANCj4gRG5lIDUuOS4yMDE3IHYgMTE6NDMg UmFkZWsgS3JlasSNw60gbmFwc2FsKGEpOg0KPiA+IEhpLA0KPiA+IHdoYXQgaXMgdGhlIGlkZWEg YmVoaW5kIHRoZSBkZXByZWNhdGVkIG1vZHVsZXMtc3RhdGUgc3VidHJlZSBpbiByZXZpc2VkIGll dGYteWFuZy1saWJyYXJ5IHNjaGVtYT8gQWNjb3JkaW5nIHRvIFJGQywgdGhlIGRlcHJlY2F0ZWQg bm9kZSBwZXJtaXRzIGNvbnRpbnVlZCBpbXBsZW1lbnRhdGlvbiBiZWNhdXNlIG9mIGludGVyb3Bl cmFiaWxpdHkuIFNvLCBpcyB0aGUgaWRlYSB0aGF0IHRoZSBkYXRhIGNyZWF0ZWQgYWNjb3JkaW5n IHRvIHRoZSBSRkM3ODk1LCBzaG91bGQgd29yayBldmVuIHdpdGggdGhpcyBzY2hlbWE/IEFuZCB2 aWNlIHZlcnNhLCB0aGF0IHdpdGggdGhlIDc4OTViaXMsIG1vZGVzLXN0YXRlIHN1YnRyZWUgaXMg bm90IG5lY2Vzc2FyeSBhbmQganVzdCB5YW5nLWxpYnJhcnkgc3VidHJlZSBpcyBlbm91Z2g/IEJl Y2F1c2UgaXQgZG9lcyBub3QgY3VycmVudGx5IHdvcmsgdGhpcyB3YXkuIFRoZSBtb2R1bGVzLXN0 YXRlIGFzIHdlbGwgYXMgeWFuZy1saWJyYXJ5IHN1YnRyZWVzIGNvbnRhaW4gbWFuZGF0b3J5IG5v ZGVzIChtb2R1bGUtc2V0LWlkIGFuZCBjaGVja3N1bSkgc28gYXQgbGVhc3QgdGhlc2Ugbm9kZXMg YXJlIG5lY2Vzc2FyeSB0byBoYXZlIGluIHZhbGlkIGRhdGEuIEFtIEkgd3JvbmcgdGhlIHRoZSBj b21wYXRpYmlsaXR5IGlkZWEgb3IgdGhlcmUgc2hvdWxkIGJlIGEgdG9wLWxldmVsIGNob2ljZT8N Cj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gUmFkZWsNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4g DQo= From nobody Tue Sep 5 04:34:53 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906D013219C for ; Tue, 5 Sep 2017 04:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvH5F5tH1qAf for ; Tue, 5 Sep 2017 04:34:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 66ADA1320C9 for ; Tue, 5 Sep 2017 04:34:49 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id BCAA740005D; Tue, 5 Sep 2017 13:34:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504611286; bh=5L5AqtwnSFZTPk6/lvogOuuyD64sBCJr8AJ/bGJao4A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jKLD69knUgJhyzWlpPrhdzg9R511zXjnog62T+xpWGySI9cQK5RLhpN/IbnvelEdS kvkIBmFEW97Xh7vVzx2DizQK9GQwd73bc4lHCqCmQbJk5O1QvIwX3uTfVCs1YKMWaz nMwJMCcNQ0DdpcWT7igr1LeR0t9TZo5qh15dDD34= To: Martin Bjorklund Cc: netconf@ietf.org References: <20170905.131816.2135302521409049604.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Tue, 5 Sep 2017 13:34:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170905.131816.2135302521409049604.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 11:34:51 -0000 ok, so what is the reason to have the deprecated nodes in this case? How does it improve interoperability? Radek Dne 5.9.2017 v 13:18 Martin Bjorklund napsal(a): > Radek Krejčí wrote: >> I'm going to try to answer myself :) The compatibility should be for clients (old clients understand new servers), not for the servers (old server generate data valid according to the new schema), so my idea was wrong. The server is supposed to generate both subtrees (duplicating data) and client can pick the subtree it understands. If I'm still not right, please correct me. > The server is not required to implement deprectated nodes. 7950 says: > > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > This text applies to both clients and servers. > > > > /martin > > > > >> Radek >> >> Dne 5.9.2017 v 11:43 Radek Krejčí napsal(a): >>> Hi, >>> what is the idea behind the deprecated modules-state subtree in revised ietf-yang-library schema? According to RFC, the deprecated node permits continued implementation because of interoperability. So, is the idea that the data created according to the RFC7895, should work even with this schema? And vice versa, that with the 7895bis, modes-state subtree is not necessary and just yang-library subtree is enough? Because it does not currently work this way. The modules-state as well as yang-library subtrees contain mandatory nodes (module-set-id and checksum) so at least these nodes are necessary to have in valid data. Am I wrong the the compatibility idea or there should be a top-level choice? >>> >>> Regards, >>> Radek >>> >>> _______________________________________________ >>> 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 >> -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET, Association of Legal Entities Zikova 4 160 00 Praha 6 Czech Republic From nobody Tue Sep 5 04:52:41 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0055132939 for ; Tue, 5 Sep 2017 04:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B97dn04hUJZ4 for ; Tue, 5 Sep 2017 04:52:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5F1320C9 for ; Tue, 5 Sep 2017 04:52:38 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 923B71AE02C9; Tue, 5 Sep 2017 13:52:36 +0200 (CEST) Date: Tue, 05 Sep 2017 13:51:03 +0200 (CEST) Message-Id: <20170905.135103.381115456845368347.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170905.131816.2135302521409049604.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 11:52:40 -0000 UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gb2ssIHNvIHdoYXQg aXMgdGhlIHJlYXNvbiB0byBoYXZlIHRoZSBkZXByZWNhdGVkIG5vZGVzIGluIHRoaXMgY2FzZT8g SG93IGRvZXMgaXQgaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5Pw0KDQpXaGF0IGRvIHlvdSBtZWFu IGJ5ICJoYXZlIiB0aGUgZGVwcmVjYXRlZCBub2Rlcz8gIElmIHlvdSBtZWFuDQoiaW1wbGVtZW50 IGluIHRoZSBzZXJ2ZXIiLCBpdCBoZWxwcyBvbGQgY2xpZW50cyB0byBiZSBhYmxlIHRvDQpjb250 aW51ZSB0byB3b3JrLiAgSWYgeW91IGtub3cgdGhhdCB5b3UgY2FuIHVwZ3JhZGUgYWxsIGNsaWVu dHMgYXQgdGhlDQpzYW1lIHRpbWUgYXMgdGhlIHNlcnZlciwgeW91IGRvbid0IGhhdmUgdG8gaW1w bGVtZW50IHRoZSBkZXByZWNhdGVkDQpub2Rlcy4NCg0KDQovbWFydGluDQoNCg0KPiANCj4gUmFk ZWsNCj4gDQo+IERuZSA1LjkuMjAxNyB2IDEzOjE4IE1hcnRpbiBCam9ya2x1bmQgbmFwc2FsKGEp Og0KPiA+IFJhZGVrIEtyZWrEjcOtIDxya3JlamNpQGNlc25ldC5jej4gd3JvdGU6DQo+ID4+IEkn bSBnb2luZyB0byB0cnkgdG8gYW5zd2VyIG15c2VsZiA6KSBUaGUgY29tcGF0aWJpbGl0eSBzaG91 bGQgYmUgZm9yIGNsaWVudHMgKG9sZCBjbGllbnRzIHVuZGVyc3RhbmQgbmV3IHNlcnZlcnMpLCBu b3QgZm9yIHRoZSBzZXJ2ZXJzIChvbGQgc2VydmVyIGdlbmVyYXRlIGRhdGEgdmFsaWQgYWNjb3Jk aW5nIHRvIHRoZSBuZXcgc2NoZW1hKSwgc28gbXkgaWRlYSB3YXMgd3JvbmcuIFRoZSBzZXJ2ZXIg aXMgc3VwcG9zZWQgdG8gZ2VuZXJhdGUgYm90aCBzdWJ0cmVlcyAoZHVwbGljYXRpbmcgZGF0YSkg YW5kIGNsaWVudCBjYW4gcGljayB0aGUgc3VidHJlZSBpdCB1bmRlcnN0YW5kcy4gSWYgSSdtIHN0 aWxsIG5vdCByaWdodCwgcGxlYXNlIGNvcnJlY3QgbWUuDQo+ID4gVGhlIHNlcnZlciBpcyBub3Qg cmVxdWlyZWQgdG8gaW1wbGVtZW50IGRlcHJlY3RhdGVkIG5vZGVzLiAgNzk1MCBzYXlzOg0KPiA+ DQo+ID4gICAgbyAgImRlcHJlY2F0ZWQiIGluZGljYXRlcyBhbiBvYnNvbGV0ZSBkZWZpbml0aW9u LCBidXQgaXQgcGVybWl0cw0KPiA+ICAgICAgIG5ldy9jb250aW51ZWQgaW1wbGVtZW50YXRpb24g aW4gb3JkZXIgdG8gZm9zdGVyIGludGVyb3BlcmFiaWxpdHkNCj4gPiAgICAgICB3aXRoIG9sZGVy L2V4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4NCj4gPg0KPiA+IFRoaXMgdGV4dCBhcHBsaWVzIHRv IGJvdGggY2xpZW50cyBhbmQgc2VydmVycy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPj4gUmFkZWsNCj4gPj4NCj4gPj4gRG5lIDUuOS4yMDE3IHYg MTE6NDMgUmFkZWsgS3JlasSNw60gbmFwc2FsKGEpOg0KPiA+Pj4gSGksDQo+ID4+PiB3aGF0IGlz IHRoZSBpZGVhIGJlaGluZCB0aGUgZGVwcmVjYXRlZCBtb2R1bGVzLXN0YXRlIHN1YnRyZWUgaW4g cmV2aXNlZCBpZXRmLXlhbmctbGlicmFyeSBzY2hlbWE/IEFjY29yZGluZyB0byBSRkMsIHRoZSBk ZXByZWNhdGVkIG5vZGUgcGVybWl0cyBjb250aW51ZWQgaW1wbGVtZW50YXRpb24gYmVjYXVzZSBv ZiBpbnRlcm9wZXJhYmlsaXR5LiBTbywgaXMgdGhlIGlkZWEgdGhhdCB0aGUgZGF0YSBjcmVhdGVk IGFjY29yZGluZyB0byB0aGUgUkZDNzg5NSwgc2hvdWxkIHdvcmsgZXZlbiB3aXRoIHRoaXMgc2No ZW1hPyBBbmQgdmljZSB2ZXJzYSwgdGhhdCB3aXRoIHRoZSA3ODk1YmlzLCBtb2Rlcy1zdGF0ZSBz dWJ0cmVlIGlzIG5vdCBuZWNlc3NhcnkgYW5kIGp1c3QgeWFuZy1saWJyYXJ5IHN1YnRyZWUgaXMg ZW5vdWdoPyBCZWNhdXNlIGl0IGRvZXMgbm90IGN1cnJlbnRseSB3b3JrIHRoaXMgd2F5LiBUaGUg bW9kdWxlcy1zdGF0ZSBhcyB3ZWxsIGFzIHlhbmctbGlicmFyeSBzdWJ0cmVlcyBjb250YWluIG1h bmRhdG9yeSBub2RlcyAobW9kdWxlLXNldC1pZCBhbmQgY2hlY2tzdW0pIHNvIGF0IGxlYXN0IHRo ZXNlIG5vZGVzIGFyZSBuZWNlc3NhcnkgdG8gaGF2ZSBpbiB2YWxpZCBkYXRhLiBBbSBJIHdyb25n IHRoZSB0aGUgY29tcGF0aWJpbGl0eSBpZGVhIG9yIHRoZXJlIHNob3VsZCBiZSBhIHRvcC1sZXZl bCBjaG9pY2U/DQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+IFJhZGVrDQo+ID4+Pg0KPiA+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gPj4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4NCj4gDQo+IC0tIA0KPiBSYWRl ayBLcmVqY2kNCj4gbW9iaWxlICA6ICs0MjAgNzMyIDIxMiA3MTQNCj4gb2ZmaWNlICA6ICs0MjAg MjM0IDY4MCAyNTYNCj4gZS1tYWlsICA6IHJrcmVqY2lAY2VzbmV0LmN6DQo+IExpbmtlZEluOiBo dHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9yYWRla2tyZWpjaQ0KPiANCj4gQ0VTTkVULCBBc3Nv Y2lhdGlvbiBvZiBMZWdhbCBFbnRpdGllcw0KPiBaaWtvdmEgNA0KPiAxNjAgMDAgUHJhaGEgNg0K PiBDemVjaCBSZXB1YmxpYw0KPiANCj4gDQo= From nobody Tue Sep 5 05:29:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB3132939 for ; Tue, 5 Sep 2017 05:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CORQgqY4lJwm for ; Tue, 5 Sep 2017 05:29:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 C949D132941 for ; Tue, 5 Sep 2017 05:29:16 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id EF8FC400063; Tue, 5 Sep 2017 14:29:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504614554; bh=4WdQ3IVhyBi3A3CeKOlUtoX4n4EDZ2misr7e4mskQ2o=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Bt0IEfmvtwJXWk46HXQ3fEkWOiL9xUfgxWY/N3ONuucj5GT/zWdeMNsB9bCoGgJy8 EMiwYxCfMW+W5drv5c/5fwKI2TcSjCSYcZdvb14cUZyTQTVVoM3v1hTaK5w/nnW67T SU9oF7zgxWmTNcPtCraFQ/H2kAIVPEwM2oMCmV54= To: Martin Bjorklund Cc: netconf@ietf.org References: <20170905.131816.2135302521409049604.mbj@tail-f.com> <20170905.135103.381115456845368347.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Tue, 5 Sep 2017 14:29:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170905.135103.381115456845368347.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 12:29:19 -0000 I meant "have" in schema, if the servers do not provide these nodes. But = even "may provide" meaning is useful (which is what I tried to say in my = answer) so, to improve interoperability (no one in real world is able to guarante= e that all clients were upgraded), the server is _supposed_ to generate b= oth subtrees, as I wrote. But it is not _required_ to do that (as you wro= te). However, in such a case there is no backward compatibility. Is this = answer correct and complete now? Radek Dne 5.9.2017 v 13:51 Martin Bjorklund napsal(a): > Radek Krej=C4=8D=C3=AD wrote: >> ok, so what is the reason to have the deprecated nodes in this case? H= ow does it improve interoperability? > What do you mean by "have" the deprecated nodes? If you mean > "implement in the server", it helps old clients to be able to > continue to work. If you know that you can upgrade all clients at the > same time as the server, you don't have to implement the deprecated > nodes. > > > /martin > > >> Radek >> >> Dne 5.9.2017 v 13:18 Martin Bjorklund napsal(a): >>> Radek Krej=C4=8D=C3=AD wrote: >>>> I'm going to try to answer myself :) The compatibility should be for= clients (old clients understand new servers), not for the servers (old s= erver generate data valid according to the new schema), so my idea was wr= ong. The server is supposed to generate both subtrees (duplicating data) = and client can pick the subtree it understands. If I'm still not right, p= lease correct me. >>> The server is not required to implement deprectated nodes. 7950 says= : >>> >>> o "deprecated" indicates an obsolete definition, but it permits >>> new/continued implementation in order to foster interoperabilit= y >>> with older/existing implementations. >>> >>> This text applies to both clients and servers. >>> >>> >>> >>> /martin >>> >>> >>> >>> >>>> Radek >>>> >>>> Dne 5.9.2017 v 11:43 Radek Krej=C4=8D=C3=AD napsal(a): >>>>> Hi, >>>>> what is the idea behind the deprecated modules-state subtree in rev= ised ietf-yang-library schema? According to RFC, the deprecated node perm= its continued implementation because of interoperability. So, is the idea= that the data created according to the RFC7895, should work even with th= is schema? And vice versa, that with the 7895bis, modes-state subtree is = not necessary and just yang-library subtree is enough? Because it does no= t currently work this way. The modules-state as well as yang-library subt= rees contain mandatory nodes (module-set-id and checksum) so at least the= se nodes are necessary to have in valid data. Am I wrong the the compatib= ility idea or there should be a top-level choice? >>>>> >>>>> Regards, >>>>> Radek >>>>> >>>>> _______________________________________________ >>>>> 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 >> Radek Krejci >> mobile : +420 732 212 714 >> office : +420 234 680 256 >> e-mail : rkrejci@cesnet.cz >> LinkedIn: http://www.linkedin.com/in/radekkrejci >> >> CESNET, Association of Legal Entities >> Zikova 4 >> 160 00 Praha 6 >> Czech Republic >> >> --=20 Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET, Association of Legal Entities Zikova 4 160 00 Praha 6 Czech Republic From nobody Tue Sep 5 05:35:58 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE413295E for ; Tue, 5 Sep 2017 05:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT6OZzTcebie for ; Tue, 5 Sep 2017 05:35:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 68CE2132939 for ; Tue, 5 Sep 2017 05:35:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 41E581AE02C9; Tue, 5 Sep 2017 14:35:54 +0200 (CEST) Date: Tue, 05 Sep 2017 14:34:20 +0200 (CEST) Message-Id: <20170905.143420.103728158240522515.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170905.135103.381115456845368347.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 12:35:57 -0000 UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gSSBtZWFudCAiaGF2 ZSIgaW4gc2NoZW1hLCBpZiB0aGUgc2VydmVycyBkbyBub3QgcHJvdmlkZSB0aGVzZQ0KPiBub2Rl cy4gQnV0IGV2ZW4gIm1heSBwcm92aWRlIiBtZWFuaW5nIGlzIHVzZWZ1bCAod2hpY2ggaXMgd2hh dCBJIHRyaWVkDQo+IHRvIHNheSBpbiBteSBhbnN3ZXIpDQo+IA0KPiBzbywgdG8gaW1wcm92ZSBp bnRlcm9wZXJhYmlsaXR5IChubyBvbmUgaW4gcmVhbCB3b3JsZCBpcyBhYmxlIHRvDQo+IGd1YXJh bnRlZSB0aGF0IGFsbCBjbGllbnRzIHdlcmUgdXBncmFkZWQpLCB0aGUgc2VydmVyIGlzIF9zdXBw b3NlZF8gdG8NCj4gZ2VuZXJhdGUgYm90aCBzdWJ0cmVlcywgYXMgSSB3cm90ZS4gQnV0IGl0IGlz IG5vdCBfcmVxdWlyZWRfIHRvIGRvDQo+IHRoYXQgKGFzIHlvdSB3cm90ZSkuIEhvd2V2ZXIsIGlu IHN1Y2ggYSBjYXNlIHRoZXJlIGlzIG5vIGJhY2t3YXJkDQo+IGNvbXBhdGliaWxpdHkuIElzIHRo aXMgYW5zd2VyIGNvcnJlY3QgYW5kIGNvbXBsZXRlIG5vdz8NCg0KT2suICBEaWQgeW91IGdldCB0 aGUgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24/DQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IFJhZGVr DQo+IA0KPiBEbmUgNS45LjIwMTcgdiAxMzo1MSBNYXJ0aW4gQmpvcmtsdW5kIG5hcHNhbChhKToN Cj4gPiBSYWRlayBLcmVqxI3DrSA8cmtyZWpjaUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+PiBvaywg c28gd2hhdCBpcyB0aGUgcmVhc29uIHRvIGhhdmUgdGhlIGRlcHJlY2F0ZWQgbm9kZXMgaW4gdGhp cyBjYXNlPw0KPiA+PiBIb3cgZG9lcyBpdCBpbXByb3ZlIGludGVyb3BlcmFiaWxpdHk/DQo+ID4g V2hhdCBkbyB5b3UgbWVhbiBieSAiaGF2ZSIgdGhlIGRlcHJlY2F0ZWQgbm9kZXM/ICBJZiB5b3Ug bWVhbg0KPiA+ICJpbXBsZW1lbnQgaW4gdGhlIHNlcnZlciIsIGl0IGhlbHBzIG9sZCBjbGllbnRz IHRvIGJlIGFibGUgdG8NCj4gPiBjb250aW51ZSB0byB3b3JrLiAgSWYgeW91IGtub3cgdGhhdCB5 b3UgY2FuIHVwZ3JhZGUgYWxsIGNsaWVudHMgYXQgdGhlDQo+ID4gc2FtZSB0aW1lIGFzIHRoZSBz ZXJ2ZXIsIHlvdSBkb24ndCBoYXZlIHRvIGltcGxlbWVudCB0aGUgZGVwcmVjYXRlZA0KPiA+IG5v ZGVzLg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4NCj4gPg0KPiA+PiBSYWRlaw0KPiA+Pg0K PiA+PiBEbmUgNS45LjIwMTcgdiAxMzoxOCBNYXJ0aW4gQmpvcmtsdW5kIG5hcHNhbChhKToNCj4g Pj4+IFJhZGVrIEtyZWrEjcOtIDxya3JlamNpQGNlc25ldC5jej4gd3JvdGU6DQo+ID4+Pj4gSSdt IGdvaW5nIHRvIHRyeSB0byBhbnN3ZXIgbXlzZWxmIDopIFRoZSBjb21wYXRpYmlsaXR5IHNob3Vs ZCBiZSBmb3INCj4gPj4+PiBjbGllbnRzIChvbGQgY2xpZW50cyB1bmRlcnN0YW5kIG5ldyBzZXJ2 ZXJzKSwgbm90IGZvciB0aGUgc2VydmVycyAob2xkDQo+ID4+Pj4gc2VydmVyIGdlbmVyYXRlIGRh dGEgdmFsaWQgYWNjb3JkaW5nIHRvIHRoZSBuZXcgc2NoZW1hKSwgc28gbXkgaWRlYQ0KPiA+Pj4+ IHdhcyB3cm9uZy4gVGhlIHNlcnZlciBpcyBzdXBwb3NlZCB0byBnZW5lcmF0ZSBib3RoIHN1YnRy ZWVzDQo+ID4+Pj4gKGR1cGxpY2F0aW5nIGRhdGEpIGFuZCBjbGllbnQgY2FuIHBpY2sgdGhlIHN1 YnRyZWUgaXQgdW5kZXJzdGFuZHMuIElmDQo+ID4+Pj4gSSdtIHN0aWxsIG5vdCByaWdodCwgcGxl YXNlIGNvcnJlY3QgbWUuDQo+ID4+PiBUaGUgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBpbXBs ZW1lbnQgZGVwcmVjdGF0ZWQgbm9kZXMuICA3OTUwIHNheXM6DQo+ID4+Pg0KPiA+Pj4gICAgbyAg ImRlcHJlY2F0ZWQiIGluZGljYXRlcyBhbiBvYnNvbGV0ZSBkZWZpbml0aW9uLCBidXQgaXQgcGVy bWl0cw0KPiA+Pj4gICAgICAgbmV3L2NvbnRpbnVlZCBpbXBsZW1lbnRhdGlvbiBpbiBvcmRlciB0 byBmb3N0ZXIgaW50ZXJvcGVyYWJpbGl0eQ0KPiA+Pj4gICAgICAgd2l0aCBvbGRlci9leGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+Pg0KPiA+Pj4gVGhpcyB0ZXh0IGFwcGxpZXMgdG8gYm90 aCBjbGllbnRzIGFuZCBzZXJ2ZXJzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gL21hcnRp bg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBSYWRlaw0KPiA+Pj4+DQo+ID4+ Pj4gRG5lIDUuOS4yMDE3IHYgMTE6NDMgUmFkZWsgS3JlasSNw60gbmFwc2FsKGEpOg0KPiA+Pj4+ PiBIaSwNCj4gPj4+Pj4gd2hhdCBpcyB0aGUgaWRlYSBiZWhpbmQgdGhlIGRlcHJlY2F0ZWQgbW9k dWxlcy1zdGF0ZSBzdWJ0cmVlIGluDQo+ID4+Pj4+IHJldmlzZWQgaWV0Zi15YW5nLWxpYnJhcnkg c2NoZW1hPyBBY2NvcmRpbmcgdG8gUkZDLCB0aGUgZGVwcmVjYXRlZA0KPiA+Pj4+PiBub2RlIHBl cm1pdHMgY29udGludWVkIGltcGxlbWVudGF0aW9uIGJlY2F1c2Ugb2YgaW50ZXJvcGVyYWJpbGl0 eS4gU28sDQo+ID4+Pj4+IGlzIHRoZSBpZGVhIHRoYXQgdGhlIGRhdGEgY3JlYXRlZCBhY2NvcmRp bmcgdG8gdGhlIFJGQzc4OTUsIHNob3VsZA0KPiA+Pj4+PiB3b3JrIGV2ZW4gd2l0aCB0aGlzIHNj aGVtYT8gQW5kIHZpY2UgdmVyc2EsIHRoYXQgd2l0aCB0aGUgNzg5NWJpcywNCj4gPj4+Pj4gbW9k ZXMtc3RhdGUgc3VidHJlZSBpcyBub3QgbmVjZXNzYXJ5IGFuZCBqdXN0IHlhbmctbGlicmFyeSBz dWJ0cmVlIGlzDQo+ID4+Pj4+IGVub3VnaD8gQmVjYXVzZSBpdCBkb2VzIG5vdCBjdXJyZW50bHkg d29yayB0aGlzIHdheS4gVGhlIG1vZHVsZXMtc3RhdGUNCj4gPj4+Pj4gYXMgd2VsbCBhcyB5YW5n LWxpYnJhcnkgc3VidHJlZXMgY29udGFpbiBtYW5kYXRvcnkgbm9kZXMNCj4gPj4+Pj4gKG1vZHVs ZS1zZXQtaWQgYW5kIGNoZWNrc3VtKSBzbyBhdCBsZWFzdCB0aGVzZSBub2RlcyBhcmUgbmVjZXNz YXJ5IHRvDQo+ID4+Pj4+IGhhdmUgaW4gdmFsaWQgZGF0YS4gQW0gSSB3cm9uZyB0aGUgdGhlIGNv bXBhdGliaWxpdHkgaWRlYSBvciB0aGVyZQ0KPiA+Pj4+PiBzaG91bGQgYmUgYSB0b3AtbGV2ZWwg Y2hvaWNlPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+PiBSYWRlaw0KPiA+Pj4+ Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBOZXRjb25mQGlldGYub3Jn DQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+Pj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4+Pj4N Cj4gPj4gLS0gDQo+ID4+IFJhZGVrIEtyZWpjaQ0KPiA+PiBtb2JpbGUgIDogKzQyMCA3MzIgMjEy IDcxNA0KPiA+PiBvZmZpY2UgIDogKzQyMCAyMzQgNjgwIDI1Ng0KPiA+PiBlLW1haWwgIDogcmty ZWpjaUBjZXNuZXQuY3oNCj4gPj4gTGlua2VkSW46IGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2lu L3JhZGVra3JlamNpDQo+ID4+DQo+ID4+IENFU05FVCwgQXNzb2NpYXRpb24gb2YgTGVnYWwgRW50 aXRpZXMNCj4gPj4gWmlrb3ZhIDQNCj4gPj4gMTYwIDAwIFByYWhhIDYNCj4gPj4gQ3plY2ggUmVw dWJsaWMNCj4gPj4NCj4gPj4NCj4gDQo+IC0tIA0KPiBSYWRlayBLcmVqY2kNCj4gbW9iaWxlICA6 ICs0MjAgNzMyIDIxMiA3MTQNCj4gb2ZmaWNlICA6ICs0MjAgMjM0IDY4MCAyNTYNCj4gZS1tYWls ICA6IHJrcmVqY2lAY2VzbmV0LmN6DQo+IExpbmtlZEluOiBodHRwOi8vd3d3LmxpbmtlZGluLmNv bS9pbi9yYWRla2tyZWpjaQ0KPiANCj4gQ0VTTkVULCBBc3NvY2lhdGlvbiBvZiBMZWdhbCBFbnRp dGllcw0KPiBaaWtvdmEgNA0KPiAxNjAgMDAgUHJhaGEgNg0KPiBDemVjaCBSZXB1YmxpYw0KPiAN Cj4gDQo= From nobody Tue Sep 5 05:41:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5EB132980 for ; Tue, 5 Sep 2017 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijV8zva6ZLh3 for ; Tue, 5 Sep 2017 05:41:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 A1FED132960 for ; Tue, 5 Sep 2017 05:41:11 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 225BB400063; Tue, 5 Sep 2017 14:41:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504615270; bh=ShXP3MlR+7PyuP0RWbFTO9siXEQDNdjJxQQBtcl3zQk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=DrHBM9pdWOGrQNQszFJ8NBS8Kealy/AkDrrfg72VzS08teyqKU6yAX3SQdEIFw/r+ umTF3DlwAgUZhZzIbC4XWvi8LzeYmGhYB7O0VOy7jvTGfUEDT6bb4qTBDpT36AVinP eWhK9BDUHvqeWG2Srq36DzJDRJM3dRygaM9q2fAI= To: Martin Bjorklund Cc: netconf@ietf.org References: <20170905.135103.381115456845368347.mbj@tail-f.com> <20170905.143420.103728158240522515.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Tue, 5 Sep 2017 14:41:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170905.143420.103728158240522515.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] deprecated subtree in revised ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 12:41:14 -0000 Dne 5.9.2017 v 14:34 Martin Bjorklund napsal(a): > Radek Krejčí wrote: >> I meant "have" in schema, if the servers do not provide these >> nodes. But even "may provide" meaning is useful (which is what I tried >> to say in my answer) >> >> so, to improve interoperability (no one in real world is able to >> guarantee that all clients were upgraded), the server is _supposed_ to >> generate both subtrees, as I wrote. But it is not _required_ to do >> that (as you wrote). However, in such a case there is no backward >> compatibility. Is this answer correct and complete now? > Ok. Did you get the answer to your question? I hope so :) Radek > > /martin > > >> Radek >> >> Dne 5.9.2017 v 13:51 Martin Bjorklund napsal(a): >>> Radek Krejčí wrote: >>>> ok, so what is the reason to have the deprecated nodes in this case? >>>> How does it improve interoperability? >>> What do you mean by "have" the deprecated nodes? If you mean >>> "implement in the server", it helps old clients to be able to >>> continue to work. If you know that you can upgrade all clients at the >>> same time as the server, you don't have to implement the deprecated >>> nodes. >>> >>> >>> /martin >>> >>> >>>> Radek >>>> >>>> Dne 5.9.2017 v 13:18 Martin Bjorklund napsal(a): >>>>> Radek Krejčí wrote: >>>>>> I'm going to try to answer myself :) The compatibility should be for >>>>>> clients (old clients understand new servers), not for the servers (old >>>>>> server generate data valid according to the new schema), so my idea >>>>>> was wrong. The server is supposed to generate both subtrees >>>>>> (duplicating data) and client can pick the subtree it understands. If >>>>>> I'm still not right, please correct me. >>>>> The server is not required to implement deprectated nodes. 7950 says: >>>>> >>>>> o "deprecated" indicates an obsolete definition, but it permits >>>>> new/continued implementation in order to foster interoperability >>>>> with older/existing implementations. >>>>> >>>>> This text applies to both clients and servers. >>>>> >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>> >>>>>> Radek >>>>>> >>>>>> Dne 5.9.2017 v 11:43 Radek Krejčí napsal(a): >>>>>>> Hi, >>>>>>> what is the idea behind the deprecated modules-state subtree in >>>>>>> revised ietf-yang-library schema? According to RFC, the deprecated >>>>>>> node permits continued implementation because of interoperability. So, >>>>>>> is the idea that the data created according to the RFC7895, should >>>>>>> work even with this schema? And vice versa, that with the 7895bis, >>>>>>> modes-state subtree is not necessary and just yang-library subtree is >>>>>>> enough? Because it does not currently work this way. The modules-state >>>>>>> as well as yang-library subtrees contain mandatory nodes >>>>>>> (module-set-id and checksum) so at least these nodes are necessary to >>>>>>> have in valid data. Am I wrong the the compatibility idea or there >>>>>>> should be a top-level choice? >>>>>>> >>>>>>> Regards, >>>>>>> Radek >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Wed Sep 6 11:17:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD81321A2 for ; Wed, 6 Sep 2017 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMEqA32WNUeE for ; Wed, 6 Sep 2017 11:16:59 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53483132980 for ; Wed, 6 Sep 2017 11:16:56 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id s11so19570258lfe.0 for ; Wed, 06 Sep 2017 11:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=aQ9u/9D3059ieZTR8zM1gfFgP5QaKWidzEzGVS3/hBY=; b=Odw5uwv+7jtIOR1obwW0DjtY4KHmkHRKGBUGzsjLUgl/S+ivGx0TNy4dAZ+3uT82UP k5GSJ54jRzF161pJgkScyvENsKxlL++1UU+HaDlLjx1YFTmi8eRdQDi/6+fyynIesoRF 2074e6/OggnRLJ3NM5JNpZXHSOlVaU1FOr+w1emoi5oXTY28LwKq/uEWoWdOrFuiIBxy PORsvu2+v0lJE2zE8XqWO1yiYtLBaSJpsHMAs5glq8g5e9Vfj0awvakhEzUdIHHrlS7V DOnmx3ZqgmzmI/8aPGMj1ct3HAXOH9TEIEFyG46JnWOnLpl+aY4HtvAVss7cX/DkDtcm 5/NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=aQ9u/9D3059ieZTR8zM1gfFgP5QaKWidzEzGVS3/hBY=; b=NNupMPvQqrlGbI+kLFVoYQnjq0FdFEe3aLHQ/1MGgyGbiIN/2pdjc7Sysfa9Tf7co0 9/Yc17A3kxdwvb6v0ob4Bm/G8r19S61fGN/AFhuGjzY5QHfPHiEIU4kgFiSNwOdYK62c /LvhydBq/oxS4+leHBsRwTtBTW2ASgBgL3YxJLVTt9P4ztkgP6QsWX8KzK3xjlWeZ+n6 uOEBl/DFlOPW5vuP4XU2uHTmEGCQaIBC2S1fXi+2aW2nmOjYzJ780o5wwL4RLetPlgjj /A+dP3EujE9kpIctzRGcGRl7BkpgTAGR6FKyysf7f6+JVm+N0LtfdSn3I0Q9SEc/mizy sLnw== X-Gm-Message-State: AHPjjUix9NkJ5FXJ9YwUOsJ3RRTsixBulc3yoTkpgU/WOZZlL8YGKNyM SDeXCvxqw9zrUCzlOwE= X-Google-Smtp-Source: AOwi7QDF6+RLbrV2PcVNyJM+b8UpS4iqjIiLpMsX80O6GYTTJqlLLDT9iHM1Jz9x3pK9aZzb3DnSkw== X-Received: by 10.46.86.18 with SMTP id k18mr2945ljb.73.1504721814661; Wed, 06 Sep 2017 11:16:54 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id 5sm82431ljz.51.2017.09.06.11.16.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 11:16:53 -0700 (PDT) From: "Xufeng Liu" To: "'Kent Watsen'" , References: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> In-Reply-To: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> Date: Wed, 6 Sep 2017 14:16:51 -0400 Message-ID: <061901d3273c$51197420$f34c5c60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEbVzDrp1hYg2SGLlZusIEhdMMmJKQXyiiw Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLThjN2ZlZDdhLTkzMmYtMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw4YzdmZWQ3Yy05MzJmLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjExMjAiIHQ9IjEzMTQ5MTk1NDEwNzA4NTkxNCIgaD0iUEZXZEFLeVJjM29IR0ozRlY4OEpHa2pMaCtrPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:17:00 -0000 Yes/Support. Thanks, - Xufeng > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Monday, August 21, 2017 6:04 PM > To: netconf@ietf.org > Subject: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 > > All, > > This is start of a two-week poll on making the following draft a NETCONF > working group document: > > draft-zheng-netconf-udp-pub-channel-00 [1] > > Please send email to the list indicating "yes/support" or "no/do not support". If > indicating no, please state your reservations with the document. If yes, please > also feel free to provide comments you'd like to see addressed once the > document is a WG document. > > > [1] https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00 > > > Thank you, > Kent (and Mahesh) > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Sep 7 17:53:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EAB133054 for ; Thu, 7 Sep 2017 17:53:54 -0700 (PDT) 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, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOE_qJEf-Bhj for ; Thu, 7 Sep 2017 17:53:53 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EC5133052 for ; Thu, 7 Sep 2017 17:53:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: "'Xufeng Liu'" , "'Kent Watsen'" , References: <05545A83-FEB9-486F-9003-8ADD500D5884@juniper.net> <061901d3273c$51197420$f34c5c60$@gmail.com> In-Reply-To: <061901d3273c$51197420$f34c5c60$@gmail.com> Date: Thu, 7 Sep 2017 20:53:49 -0400 Message-ID: <005101d3283c$ef081730$cd184590$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbVzDrp1hYg2SGLlZusIEhdMMmJAHWTOI2pAsY4MA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 00:53:55 -0000 Support. Read it. Think it is important for the suite of netconf protocols. Sue Hares From nobody Fri Sep 8 09:13:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425A8132EF6 for ; Fri, 8 Sep 2017 09:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHa8LsKx0_ID for ; Fri, 8 Sep 2017 09:13:13 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0135.outbound.protection.outlook.com [104.47.32.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A766132D42 for ; Fri, 8 Sep 2017 09:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5K8OzTX268yUfN6/hTtmCLyoc9xwkCC+EhDND+BKQZg=; b=hydYPS5unHPaBp8f1D3k5Ul75Udph87fyNmERssku9uQdZZM7wvLeaGNxRy19C/2rm4Hbc7LbjByKvjz18TQVye/dYz+kfOIMhPcv1BmGGNumKv/9eHJwaxvkrFUnYHmo3hpnvxvy8nJJvWO10mJ3oB06dTvsbZauLCkBoHkhvQ= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1505.namprd05.prod.outlook.com (10.160.117.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 8 Sep 2017 16:13:11 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Fri, 8 Sep 2017 16:13:11 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 Thread-Index: AQHTKL1eJb3TJyDFE0+yVaGPTwsSVA== Date: Fri, 8 Sep 2017 16:13:11 +0000 Message-ID: <108FD1E3-7944-4AC9-8CE4-1AC0082BB2DE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1505; 6:RSOffKSmnzPJorWIBZsqBZOi2XP4u/WBIbfhGgkZeXPKqrNw+VTbt3Yu/dxcxSJVoFZVRR/mhqxJPg7F2R3O0JN0hKAggqPKVEGw9J47AM9TwPMiSlZZu54c+KQKbWyGSeRDALsaoFpRPBrqTbpHt5aF1pldy9WKA/slIBemkbRsGq6ZDnVmDuQvPmqWlOs+lGD6wcI9Vc2aXH9PyDvcwwiITwhYWVDYAJ77CRzS/W1/DZLq7giCkuiNctCoIaUfZXMBwgs92u8LWeCPbRQNvh3NtuVAX5Mox6YGVk9WxeC/iy+dKbVac9RsEIovm9HztywBypVl8MP3FtappqkwVA==; 5:owamM+/dAxa90PvtUpormwAVZwdEVJVMmvfBf6zpY5Y+9Y3nsvSUoDy5lChBrP1oE3g6Z69Zt5y6CNlI3EKaq7THjj+hK2tUZ9feQfjKt6T05ADMRMVwuSS7EYTVIDsKztj246fI/YDPktoISbNuWQ==; 24:hOI9g583E7XJxYSzJNcALBL1JGxiwuhKLjDAuZDTGYmZjZgK4GbTON68+bTMoY9/VwoFLOvaxlw1Y9lq83w7QpkXsS8cCCCEn0EY9K5UMsM=; 7:k18N+BIbNW7g8QDgqSpppHqUUpUhbjS4DlKjP8SLOCtYlhmo2A0b5TFGoaWZqqtyoiYogstN0SPe62N2g3lJ/wWyyIscnyS1/QoywBRcLNFUKYCrGADLumWD7J5hMadMF6UTRlTFDkOsN12nnvijCFm37zIKmrNWPsIqe9BZhAzP1nGjH6WpD2XRnm+6SR//q9D/FTxlCfg6s29wL18QvmLEWAUslCXn1mb4s7cEU+c= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 54edf191-b35e-4ad6-0381-08d4f6d480b3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1505; x-ms-traffictypediagnostic: BN3PR0501MB1505: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1505; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1505; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(53936002)(77096006)(105586002)(2900100001)(6436002)(86362001)(6486002)(66066001)(5660300001)(478600001)(6246003)(6506006)(305945005)(7736002)(33656002)(110136004)(2906002)(966005)(3280700002)(189998001)(14454004)(68736007)(5640700003)(1730700003)(6512007)(99286003)(36756003)(81156014)(25786009)(81166006)(8676002)(102836003)(230783001)(229853002)(15650500001)(3660700001)(6306002)(6916009)(83506001)(83716003)(82746002)(4001350100001)(106356001)(6116002)(3846002)(101416001)(54356999)(50986999)(2501003)(2351001)(8936002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1505; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2017 16:13:11.8016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1505 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 16:13:15 -0000 DQpUaGlzIGNvbmNsdWRlcyB0aGUgYWRvcHRpb24gcG9sbCBmb3Igbm90aWZpY2F0aW9uLW1lc3Nh Z2VzLiAgVGhlDQpjaGFpcnMgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBjb25jZXJucyBhcm91 bmQgdGhlIHNwZWNpZmljcyANCm9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiwgYnV0IHRoYXQgdGhl cmUgaXMgZ2VuZXJhbCBzdXBwb3J0IGZvcg0KdGhlIHByb2JsZW0gc3RhdGVtZW50LiBXZSBoYXZl IGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IHRoZXJlIGlzDQpubyBrbm93biBJUFIgcGVydGFpbmlu ZyB0byB0aGlzIHdvcmsuIFRoZXJlYnkgdGhpcyBkcmFmdCBpcyBub3cNCmFkb3B0ZWQgYXMgYSBX RyBjaGFydGVyZWQgd29yayBpdGVtLg0KDQpBdXRob3JzLCBwbGVhc2UgcmVzdWJtaXQgZHJhZnQt dm9pdC1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy0wMQ0KYXMgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy0wMC4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIE1haGVz aCkNCg0KDQotLQ0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28td2VlayBwb2xsIG9u IG1ha2luZyB0aGUgZm9sbG93aW5nIGRyYWZ0IGENCk5FVENPTkYgd29ya2luZyBncm91cCBkb2N1 bWVudDoNCg0KICBkcmFmdC12b2l0LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLTAxIFsx XQ0KDQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9y dCIgb3IgIm5vL2RvIG5vdA0Kc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3Rh dGUgeW91ciByZXNlcnZhdGlvbnMgd2l0aCB0aGUNCmRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2Ug YWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cyB5b3UnZCBsaWtlDQp0byBzZWUgYWRk cmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNCg0KWzFdIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdm9pdC1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNz YWdlcy0wMQ0KDQoNClRoYW5rIHlvdSwNCktlbnQgKGFuZCBNYWhlc2gpDQoNCg0KDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBt YWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KDQoNCg== From nobody Fri Sep 8 09:17:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956A132EAB for ; Fri, 8 Sep 2017 09:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HA7aAIhjlkc for ; Fri, 8 Sep 2017 09:17:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A61132EF6 for ; Fri, 8 Sep 2017 09:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IQXq0O8S2W4dsPeaB8vWBX9tmioAyZX77HIf0uXl0d8=; b=g3O3Mso4ugFD8Tz9nca0Wm2cVksbhS5gGmZAhEZx3LJt1uTPO16Paxw2oAJNirqv6rlYg6UZNUXTZMn3tmwuiEaAyA6mCoq39M065qbtYGpK2XrfbdC57WS1WXnumNmg0B7SzR4BNeS4e6yLM5iiWDMJYRMJur+ufMCa7jwgiP8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1459.namprd05.prod.outlook.com (10.160.117.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 8 Sep 2017 16:17:00 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Fri, 8 Sep 2017 16:17:00 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 Thread-Index: AQHTKL3mu+5gO8PnQEm3VBneSJzb9g== Date: Fri, 8 Sep 2017 16:17:00 +0000 Message-ID: <3696292B-9C7E-4694-8826-D7FE131E3C21@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1459; 6:XjQu8Ui+wQe5Mg+g4HeP2DbtUnOhbs6e3iY7myIvsiqVYpaimCZiFvYcitcvcmuKsRRkG1tGgCF3213E/oMkV6Mg3fNb9END1b0KGm+l06qDHjD1yAYpkSsO6tQfODQ9Swxp4GWHzHuN3Uu9hZxC6VUUcSgx/OV9j9MJwPbNCPR3+lVUXzoSMPK7TfWNPpzNhm5gqir+p3MbVBQzdMQXk2Em0MhC2rKe7AnKuqBsXUABJxzMxzk4LW+pvU7EMcxA+MHqdsiMNKvX93dApmblut3AmzzA2xKW3kdrQj26r73499e6JxD0275Rny3x/FpUNNfTGrx+eO3JEqv/Qp08Qw==; 5:Gs4lhUA3YJHUmmiItUyWG2e23qgemLjpcsrRbBsQzGk8YrZ7TslXUtpIDZ5D8POnMEHV1JqlMJ2YOjzWRbxuugffCFq5h43fHKn+hzW04SYWsM8yorb0eCdsaBtKvz6FZXRMOs4dW1UXKjhTk1wAAw==; 24:xpIfOV2WJ1aHLsx3/edCykn6RvXsN0zPptHhLJLF+hWLj9Xm0PilXgvNvD0WbpIkhkTp6x+ziDok+ZQA5HBC6K3EEMSNXQ5mVIL7ldIH3U4=; 7:KQTSeOgVRdEDA07Y0iP/Lp79zF88OX4JowxRzSBp9+0I5X7/Ex7EmBRn2q+2wgG31bwY/7UHnzy9WWyoZPks8GMsHdm05FH3Dt2MoZSgIbO6HhHva8Cf2X7A+FxU/iURi4QDC/naMWOQj7F9/JcajTVoW9NIRAII8KC055zgcsEFsOxuSXxuFcbTMis3gNp/Gw0qU3OGoI6+shgub418UG+nfsru9n9ZJ79y289j+XQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7f6597db-fc93-4f78-d617-08d4f6d508d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1459; x-ms-traffictypediagnostic: BN3PR0501MB1459: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1459; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1459; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(54534003)(189002)(199003)(36756003)(99286003)(50986999)(6306002)(6512007)(77096006)(54356999)(3280700002)(6916009)(966005)(2501003)(6116002)(5660300001)(102836003)(8676002)(8936002)(2900100001)(3846002)(6246003)(82746002)(14454004)(230783001)(110136004)(97736004)(81166006)(101416001)(53936002)(4001350100001)(189998001)(68736007)(2351001)(6436002)(86362001)(6506006)(3660700001)(1730700003)(83506001)(83716003)(229853002)(6486002)(305945005)(2906002)(81156014)(33656002)(7736002)(25786009)(478600001)(105586002)(66066001)(5640700003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1459; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9FF488AA0F6AED43B271F712A2C82E56@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2017 16:17:00.1465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1459 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 16:17:19 -0000 DQpUaGlzIGNvbmNsdWRlcyB0aGUgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yIHVkcC1wdWItY2hh bm5lbC4gIFRoZQ0KY2hhaXJzIHVuZGVyc3RhbmQgdGhhdCB3aGlsZSB0aGVyZSB3ZXJlIHJlc2Vy dmF0aW9ucyByZWdhcmRpbmcgaWYNCnRoaXMgaXMgdGhlIHJpZ2h0IFdHIGZvciB0aGlzIHdvcmss IG1vc3Qgc3VwcG9ydCBpdCBiZWluZyBkb25lIGluDQpORVRDT05GLCBzbyBsb25nIGFzIGVhcmx5 IGNyb3NzLWFyZWEgcmV2aWV3cyBhcmUgZG9uZSB3aXRoLCBmb3INCmluc3RhbmNlLCB0aGUgVHJh bnNwb3J0IGFyZWEuICBXZSBoYXZlIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IA0KdGhlcmUgaXMg bm8ga25vd24gSVBSIHBlcnRhaW5pbmcgdG8gdGhpcyB3b3JrLiBUaGVyZWJ5IHRoaXMgZHJhZnQN CmlzIG5vdyBhZG9wdGVkIGFzIGEgV0cgY2hhcnRlcmVkIHdvcmsgaXRlbS4NCg0KQXV0aG9ycywg cGxlYXNlIHJlc3VibWl0IGRyYWZ0LXpoZW5nLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLTAwDQoo bm90IHRoZSAtMDEgdXBkYXRlLCBzaW5jZSB0aGUgcG9sbCBkaWRuJ3QgaW5jbHVkZSB0aGF0IHZl cnNpb24pDQphcyBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLTAwLiAgT25jZSBw b3N0ZWQsIHlvdSBtYXkNCnRoZW4gcG9zdCB0aGUgLTAxIHZlcnNpb24gYWdhaW4uICBQbGVhc2Ug Y29uc2lkZXIgYWRkaW5nIGENCkNoYW5nZSBMb2cgdG8gdGhlIEFwcGVuZGl4IHRvIHRyYWNrIHN1 YnNlcXVlbnQgY2hhbmdlcy4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIE1haGVzaCkNCg0KDQotLQ0K DQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28td2VlayBwb2xsIG9uIG1ha2luZyB0aGUg Zm9sbG93aW5nIGRyYWZ0IGENCk5FVENPTkYgd29ya2luZyBncm91cCBkb2N1bWVudDoNCg0KICBk cmFmdC16aGVuZy1uZXRjb25mLXVkcC1wdWItY2hhbm5lbC0wMCBbMV0NCg0KUGxlYXNlIHNlbmQg ZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3QN CnN1cHBvcnQiLiAgSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgcmVzZXJ2YXRp b25zIHdpdGggdGhlDQpkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRv IHByb3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZQ0KdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBk b2N1bWVudCBpcyBhIFdHIGRvY3VtZW50Lg0KDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhlbmctbmV0Y29uZi11ZHAtcHViLWNoYW5uZWwtMDANCg0KDQpUaGFuayB5 b3UsDQpLZW50IChhbmQgTWFoZXNoKQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQoN Cg== From nobody Fri Sep 8 12:41:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2441204DA for ; Fri, 8 Sep 2017 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh2vKNbyXT5B for ; Fri, 8 Sep 2017 12:41:20 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0112.outbound.protection.outlook.com [104.47.37.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE9B13292F for ; Fri, 8 Sep 2017 12:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GBkz32/FQkl6/rhiR8T0qSQkwcnemHSnCkXmonrAw0E=; b=d4AnQxBfj/8SJC1LYCn5yZeyVSAoQtmFLiL/JRd3ySLB22g3K/clSgJy6DtyArnuDD7EjmZ5OGCVLBjY7Esc0IF8SBD9v/osz74nk8xsQwE1awLHex3AXPvkpzhrml1CJGBwanbCXpuY2VEIw4IhP1Ebx6Yx38L3yHCDawYsTmQ= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1299.namprd05.prod.outlook.com (10.160.183.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 8 Sep 2017 19:41:18 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Fri, 8 Sep 2017 19:41:18 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 Thread-Index: AQHTKL1eJb3TJyDFE0+yVaGPTwsSVKKrIFgA Date: Fri, 8 Sep 2017 19:41:18 +0000 Message-ID: <61A96A1E-BC4D-4AB8-B26E-C6960CE1DD23@juniper.net> References: <108FD1E3-7944-4AC9-8CE4-1AC0082BB2DE@juniper.net> In-Reply-To: <108FD1E3-7944-4AC9-8CE4-1AC0082BB2DE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1299; 6:exljzpN3e/vLlEYCmMWK/32o8hYNT6vI4WvKM4RICA55HD0PONXBjtOTErtXQgd1AxQy1q2e/a/XmdBSHUWtMNuhCTGVr8wf8iV+z1a7EVbGc7WbMcrLXCla6yaHYAJ4VekBjUhRTqEdGV3AETFLPWyExdVPpXUy5Tzz/XPM7PyAtALyWQrm36JlKM3fw0lCYMd2AT8Vv5Gl+oMdPaoD2JhCd6/XRrBloXFp21wUutU1MgRteOHUkIDItTsWoqm0KYhmko6A5y2LPpjgxnzl/3aYLKlpry0n6j4PRyTIZaCv9CdH6XEkFJpng2ULqa3WmXtQlZgOr+AMQd0u6SSRWg==; 5:G7TbaUL6nDg9ghYBD9huSstbCnzNv/MFfA1dNE/fjv20oyoE5k1Fn6Ebr84Ar3Asx0s5EQTkV2/YFpggvKnH2SU/ZqFN87bVfCGl78mCbpUJ6hfiTirdEo7OTGfFPcIkLwcQgmRl835wtJWU6N+b2A==; 24:a0WUuN5wdRZYN3bcBoDJU3L8yDwDy6JZtAi9tCtrurL6Ixv5k/+VL7gGXM/tuo+FW+t0sEOkgWpZCddSm8rR7ZPu1niMeyXnSkxBGYEgr5A=; 7:lyzH1HGue2+yjB2xyDnlXIMmsxm7ocqL4wK8jy1zJ8ltJRX8OxJ4YxnzQTyDlj9aZer1a7YpMbm9dO88l8bOQsOCDdQsqZIGmxmMTNnnls/pTZqkGOZVm1D2oOGPHsbFErBxv3Oi5OWdO/4jGyA8dwAL01CTy4vJ4p4uc8HToBeEHWmGJ5IeWN6+3UxymfXPA4UefbHBHONp4ytwxisQF6/HTvvwhTQacsJwyrsIm/Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 552f359b-4856-420c-d913-08d4f6f19327 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1299; x-ms-traffictypediagnostic: BN3PR0501MB1299: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1299; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1299; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(2351001)(6506006)(3846002)(101416001)(102836003)(189998001)(2900100001)(6486002)(6512007)(53936002)(83506001)(2906002)(3660700001)(5640700003)(99286003)(3280700002)(6916009)(82746002)(2950100002)(77096006)(6116002)(66066001)(14454004)(33656002)(83716003)(68736007)(8676002)(86362001)(478600001)(50986999)(229853002)(6436002)(110136004)(54356999)(76176999)(6246003)(25786009)(305945005)(81166006)(1730700003)(106356001)(15650500001)(7736002)(2501003)(97736004)(8936002)(5660300001)(105586002)(81156014)(4001350100001)(36756003)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1299; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <61D407ED8C0C9A44B01D02067516CB61@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2017 19:41:18.1625 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1299 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 19:41:22 -0000 DQpSZWdhcmRpbmcgdGhlIHJlc29sdXRpb24gb2YgdGhlIGlzc3VlcyB3aXRoIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiwNCnRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBXRyBjYW4gZml4IHRoZW0g bm93IHRoYXQgdGhlIGRvY3VtZW50DQppcyBhZG9wdGVkLCBhcyBvcHBvc2UgdG8gdGhlIGF1dGhv cnMgbmVlZGluZyB0byBmaXggdGhlbSBiZWZvcmUNCnRoZSBhZG9wdGlvbi4NCg0KS2VudA0KDQoN Ci0tDQoNClRoaXMgY29uY2x1ZGVzIHRoZSBhZG9wdGlvbiBwb2xsIGZvciBub3RpZmljYXRpb24t bWVzc2FnZXMuICBUaGUNCmNoYWlycyB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIGNvbmNlcm5z IGFyb3VuZCB0aGUgc3BlY2lmaWNzIA0Kb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBidXQgdGhh dCB0aGVyZSBpcyBnZW5lcmFsIHN1cHBvcnQgZm9yDQp0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuIFdl IGhhdmUgYWxyZWFkeSBkZXRlcm1pbmVkIHRoYXQgdGhlcmUgaXMNCm5vIGtub3duIElQUiBwZXJ0 YWluaW5nIHRvIHRoaXMgd29yay4gVGhlcmVieSB0aGlzIGRyYWZ0IGlzIG5vdw0KYWRvcHRlZCBh cyBhIFdHIGNoYXJ0ZXJlZCB3b3JrIGl0ZW0uDQoNCkF1dGhvcnMsIHBsZWFzZSByZXN1Ym1pdCBk cmFmdC12b2l0LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLTAxDQphcyBkcmFmdC1pZXRm LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLTAwLg0KDQpUaGFua3MsDQpLZW50IChhbmQg TWFoZXNoKQ0KDQoNCg== From nobody Sat Sep 9 08:51:48 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D393A132936 for ; Sat, 9 Sep 2017 08:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IaQNVQ8BT9R for ; Sat, 9 Sep 2017 08:51:44 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0104.outbound.protection.outlook.com [104.47.1.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B27132339 for ; Sat, 9 Sep 2017 08:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QfH4epnYMldunJpgANCbDD2IIf5mLl3nzKoxW0OxgZI=; b=Y9xZyomABTQFDxq9bicfa9RxVBmfOWrXya+QAPOkEN9UkvB4XYyg4Kf8+QTiorNFYAojGvpgyxNjdjWkwa+EcK34jYhT4ufy0nQgX23yixQtQh1Jushfo4cfKQfOFbo1OvPCcGkd3LQ3QKighNzt8Of7gVMF0BGVCVxXI5Rm5wQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.245.5) by HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Sat, 9 Sep 2017 15:51:40 +0000 Message-ID: <00cb01d32983$552c5660$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" , References: <108FD1E3-7944-4AC9-8CE4-1AC0082BB2DE@juniper.net> <61A96A1E-BC4D-4AB8-B26E-C6960CE1DD23@juniper.net> Date: Sat, 9 Sep 2017 16:33:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.245.5] X-ClientProxiedBy: AM4PR07CA0022.eurprd07.prod.outlook.com (2603:10a6:205:1::35) To HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21f78f68-b0a9-49b0-5326-08d4f79aa9af X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 3:KAF1lRtE9PU2Cegj++rLfF2YaGnvmFtnKe6D3Og2zXZ+8uKNuTfts8lX4h7stOGBz+5CHH4MxPMelQVFWc82uKMEBmGZoQARsuNGjLM1aFdrd0+wnfCIZMtiDs7/NHKDfnGba6tNVCCg0fwg4vyA0PDNjr9QLURNz5+mV+uJj0U5yvfIIdm3CRvw314SYvf7x1pY549dlvblyB65FjFbYu5IUrj8WNKntweP471IAgrwi53bI+InOCEAoYlApAft; 25:/roIc19vNWnFNysOO2nkmhGjJI0YyjdjtnF1avQsxlNfMfb0GELc0qWzndT78mBajMIItGiKvBNIDN4p8RrcdDY1yxxIUKEjzIp0EBMdNfLkia070IVcBbv9xYb97P1XG55o/Ui7HyONkXgdLhBdTZqIMhcNWBj6EITjBReRuGlzKKrzVqKBzmq8zUbtYcS7Z1X1C2ROCodVyaa2yMqPnTi/4IZzE3/DR/K0aE/kvM7AhWvSCS1AF9H0aICPfoqEFBOqsnkqaFH/2kUySwW+3dRsPGOL9ms5pSU8LOJnDCotqAuFJHhEWdSS0BCb1v0spCs6VxoTCPRlG0r0bUXX/g==; 31:a1ojmdyCB8fK3EEdUCTqvciGZ7raMAoDkAi/I94U4fTaWoBHB4soWT1UseUhl4T0rDlzf26A/FH3PC2LIkoa8ygiUhjeukAafWTQ3XkCiSEAeCqj2BWUm7Wjta9FZO/XfW16CPhmM8ZAJOtYT0fmsGqvO8pN7aidWwc8LyhWXxTpdX5Zl/FTWLDSD0jqEDcm221tOcATrhdrlwAExFLQIK2ATBPOvsfI1P6trj6X7ww= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3004: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 20:/B3FOqJ3SlKaE2cxz9juMeNTqdbC9iIFcMCYJqp0N+mmKRecRnbPrjGdCLwDxzowXbpI5/w7sk74pbZ4ZQRh8VwzK79mDgOQCtZhkYuR4+8xyyQ2+MPQj5hDRndX1llmZxwDs6j3HVMFQgV34KAkErnmFJcEqgbtJKjxTrbpXjeuoWXWRzwzLGkL7inOOFur7dKg8KKKYN1eFayfltJq/eUsdwdS8FzCYFMeamD/qBcffB3XOGpxjtsg+2xKJDvo; 4:LvprIdw0c10RvT5TAmODCR5/iGkzenc9L5WSh/QLa3At7lFoYxY6MZwdEHSQZBanfUNv3t0o/Ve48F95bDw0z3Ec5tHGcHf/qZ4tHiRCkACxiz4MistdGzTZukLrLx7fpsLwpYsPFlnaSZKchpNg0SVmTl4wfNOVOO7Gp03FPkUBjg03XS8HnSMiMWWn1iTSfa+KmjFahMBLRYUPRfkU7mCdowQnt+zJ25bIVGSGOgaglk/TaZPVZIyMyUnj8cxXwBE90A1k+pCPBz0z/iDg+F86CAwrrc3HKJSGVHK+zFw= X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3004; X-Forefront-PRVS: 0425A67DEF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(39860400002)(189002)(13464003)(377454003)(199003)(3846002)(8676002)(68736007)(2906002)(81156014)(81166006)(6116002)(84392002)(50226002)(6246003)(230700001)(6496005)(53936002)(101416001)(50986999)(81686999)(81816999)(76176999)(86362001)(116806002)(230783001)(8666007)(305945005)(6306002)(7736002)(9686003)(229853002)(4720700003)(6486002)(15650500001)(6666003)(44736005)(97736004)(5660300001)(189998001)(14496001)(1941001)(66066001)(47776003)(33646002)(44716002)(62236002)(1456003)(7350300001)(42186005)(61296003)(106356001)(105586002)(478600001)(25786009)(966005)(1556002)(50466002)(23756003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3004; 23:fzpDBrqbEJ/fMvZV7yyPybx4It+kObokc2IyR?= =?iso-8859-1?Q?xl8oMtvc3wElNSMKNaiOX1OR4Q375zvQrlVoEaQlBYlUr/6fPBxfFPzjLd?= =?iso-8859-1?Q?MiC4kWFhmydTfx+SDhznmoqrGU4jNfcCpBnbNz6cHhp5yESb9qy1a2TZi8?= =?iso-8859-1?Q?OmIgOWB30ugO0pt5c6KNxL+/MplYaPWbGnzlEnUZu4l6I/dPCtfkyypLhw?= =?iso-8859-1?Q?b08wuiS4HTTCWFUEdpulGVvRmWHN5wLTY/NWK5xuSOW/h1cCc47udZpZy8?= =?iso-8859-1?Q?bVn+xox3ZlJtmFAr3/gju+UOp41J42gg6CNO2oUU4A/lsY/6ru3aTyO6f/?= =?iso-8859-1?Q?UnGO3C9zYrQx72gzwembjAp4mwz+GL9nwE2+4ywvNSCz+DnqF1mNu9sCTC?= =?iso-8859-1?Q?GsMtNWgyJWUtrOBhmAp/T7+qCOXCNoG+DMVltv0f6Ss1Cezeof+cL1gqhS?= =?iso-8859-1?Q?EvX5cUciLk8UZtuE6nm4rX+XLMw48BKUDL3X1HE0RJEPgBWlLlEGTxuV8B?= =?iso-8859-1?Q?+HRPSIXYlwmtNgrpo0ikHSPXXkAvAu25+i4lkEsTgTOsm0lGG6oRy8YlSp?= =?iso-8859-1?Q?MOlpSiL0zTo2Ygh5LWlT+GI3pUp69CzJKw4Aia2BSluNJ4DeyWRXDJPGXx?= =?iso-8859-1?Q?wrU17ka4I8/2q9I67D6aYA5LUbHie7EMKENA9K+IMqg7XYXjD5bHsIgSbg?= =?iso-8859-1?Q?YMzwXpU+6agMgjnR1gWzIM5aUDlZUAersKXGgQmykGvhZoM66jj+EQ1XF8?= =?iso-8859-1?Q?rVLYdqLlwp+9QR4B8xyA/lS/rP4ngV6F1QrxE5+1w3PJ4v3F8QXhcjt+GI?= =?iso-8859-1?Q?SiZ1h04uVJJWDsdeHgqAHQ258XehgwloxiyJpmnOn4UbeFpNUoc5gPs+O1?= =?iso-8859-1?Q?SZh3agJ7ECf6/G5jx6u6C+2rSmSCQrN9mjEkTXU04KgqeL/oAu8GsQcRrB?= =?iso-8859-1?Q?0pcBYQ43o/cXtdENmVVzVvMio89rwbWKz5flAa/Vs37nk26Z/O2qHiC2nc?= =?iso-8859-1?Q?XwPj+I8KgXc6eYt4VfCfX7/PyIek+loL+LOF0WJ4QRvY5AYqphK/Uiw/7z?= =?iso-8859-1?Q?9owLr0gejhwdaSsIfQpXgJ7rpx3B02YfBJybx71ikM+Jyi9QhZNhFgarwN?= =?iso-8859-1?Q?z8bhhfAcvgo6sh+HxvmULVf0hRFK7pnDjsdBfwCqM50Ozy+3Rj1NqLsKRf?= =?iso-8859-1?Q?6HFZtOEAGZ1FM5+pbI6YWPtq/gnXKqsLUL2b7/9t401pfFYApBMMQtO62p?= =?iso-8859-1?Q?fcri4V0Td80YwSf0SKgEedyiSZxkwBRs3FMo4+ACnv+aMKYXZPadeSUGX8?= =?iso-8859-1?Q?TM8qdSl3VTkRfIygvmNxf8IHDGK/fcfFh27CiZiHuSLtT32MRki9qxy8/r?= =?iso-8859-1?Q?auCeJnVd9Z1wToh6qrK4mRKD9srzi4GCbQl5R5PxGeHoHeGaX21Bp0wOkJ?= =?iso-8859-1?Q?8vjUtwEa/cTkEj7hnkGBc36Lqt38FJCon/t94NLXvxDREgDhE9XsgmQuZ9?= =?iso-8859-1?Q?9FB/5vazNMf2EPksviJc4wfLZ5v5vqvjQqnk8sVmmUhYWiAQ8NCwa0UPAR?= =?iso-8859-1?Q?LB3Qffg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:XO5lI6DBj2VqzCVlTiCb6j4gG0zrAP6cQ5iCu8JFsKpJCtTSr0s+F9GMJQNnenzp7OlV1B8ON9gGimOhXex7KSBHSONwoMd1i+JhXwnzDjDKO1QfCignXjffa/egCFff/pk3fhib1HX3P0VgnHtVZSSAruiVce8nvXJb5XxNXBZRnYHSCf44lW2PTV+NAh6N/VWbxEgdJGt7MKduDN12U/y+XoNGJ0UowthXZsSh8osHZsZZdFnYatDZcjXPUxcbef6RUYwQpryIko/ohOQzuKuVBZuv6PNVYRIrM9XJP2QWNRGtkpF/zJywEQ/oQE9nZjC7tj/LQCXOGEuWR370sg==; 5:Svrnat4P6jPP3BBpsjsiKka/xD/SxQU9VtHuWoHj+dTWNA+lvlf2oQ+iAZblE/y5HVZev8jQk4xlsIrOJ6SYFkWYSWAxkRyp91+UD/BpgyB3ccEBt2XsT7hpBg+ke+Y649ng5L5j09MmQmfCTy5hfw==; 24:4Lbohn1PuHYnEHdMlNyQWKq8lHVTVLW0P0pPEB5VmQts20k4sNAx38yDlraKpb4pZipLIaE7Z1wj/kX3oIOxWUsqGvAItz4TGjUGn9tutns=; 7:aKpKXRapZZHqAkpZKkrHjd8WHLq1myzR6Ch5EyA7unCDYn1vcBGbEqC+e1HDx8Q5/p+DO6LAXcQFFaTNfQIXvBvkmYUeCCvprQkVHqGhGw4sMIFgyDq06FDeSV2TXMZjClfSfOsXeWBWhq7uzHAI0AQWtIWXA5lv6x/XboY1tHGaKn0sTwQ9mwfKBrkmTJGF21LIPcnWi36i+PRfOzR4PzMui0Xisn7nH+6jP6fRpiU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2017 15:51:40.6665 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 15:51:47 -0000 Kent Martin made the point in this thread that there were a number of interacting issues which need resolving, around notification headers. This suggests we need an agreement of what goes into which document, something on which I do not see consensus. So we seem to be adopting a document when we have not decided what role it will fill. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: Sent: Friday, September 08, 2017 8:41 PM > Regarding the resolution of the issues with the proposed solution, > the expectation is that the WG can fix them now that the document > is adopted, as oppose to the authors needing to fix them before > the adoption. > > Kent > > > -- > > This concludes the adoption poll for notification-messages. The > chairs understand that there are concerns around the specifics > of the proposed solution, but that there is general support for > the problem statement. We have already determined that there is > no known IPR pertaining to this work. Thereby this draft is now > adopted as a WG chartered work item. > > Authors, please resubmit draft-voit-netconf-notification-messages-01 > as draft-ietf-netconf-notification-messages-00. > > Thanks, > Kent (and Mahesh) > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Sep 10 20:14:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01DA13234E for ; Sun, 10 Sep 2017 20:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMzYqKhb-yF0 for ; Sun, 10 Sep 2017 20:14:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BEC1320D8 for ; Sun, 10 Sep 2017 20:14:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOH98804; Mon, 11 Sep 2017 03:14:33 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 11 Sep 2017 04:14:32 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 11 Sep 2017 11:14:25 +0800 From: Tianran Zhou To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 Thread-Index: AQHTKL3mu+5gO8PnQEm3VBneSJzb9qKvBk0A Date: Mon, 11 Sep 2017 03:14:54 +0000 Message-ID: References: <3696292B-9C7E-4694-8826-D7FE131E3C21@juniper.net> In-Reply-To: <3696292B-9C7E-4694-8826-D7FE131E3C21@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59B5FF99.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ad0e13863e367fc0d2678f4196c78c89 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 03:14:37 -0000 Hi Kent, Thanks.=20 We will update and resubmit the document soon. Cheers, Tianran > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Saturday, September 09, 2017 12:17 AM > To: netconf@ietf.org > Subject: Re: [Netconf] WG adoption poll > draft-zheng-netconf-udp-pub-channel-00 >=20 >=20 > This concludes the 2-week adoption poll for udp-pub-channel. The chairs > understand that while there were reservations regarding if this is the ri= ght > WG for this work, most support it being done in NETCONF, so long as early > cross-area reviews are done with, for instance, the Transport area. We h= ave > already determined that there is no known IPR pertaining to this work. Th= ereby > this draft is now adopted as a WG chartered work item. >=20 > Authors, please resubmit draft-zheng-netconf-udp-pub-channel-00 > (not the -01 update, since the poll didn't include that version) as > draft-ietf-netconf-udp-pub-channel-00. Once posted, you may then post th= e > -01 version again. Please consider adding a Change Log to the Appendix t= o > track subsequent changes. >=20 > Thanks, > Kent (and Mahesh) >=20 >=20 > -- >=20 > All, >=20 > This is start of a two-week poll on making the following draft a NETCONF > working group document: >=20 > draft-zheng-netconf-udp-pub-channel-00 [1] >=20 > Please send email to the list indicating "yes/support" or "no/do not supp= ort". > If indicating no, please state your reservations with the document. If y= es, > please also feel free to provide comments you'd like to see addressed onc= e > the document is a WG document. >=20 >=20 > [1] https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00 >=20 >=20 > Thank you, > Kent (and Mahesh) >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 11 06:18:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604EB13306C for ; Mon, 11 Sep 2017 06:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOLnYF1WRm_a for ; Mon, 11 Sep 2017 06:18:29 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0132.outbound.protection.outlook.com [104.47.41.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F5A133060 for ; Mon, 11 Sep 2017 06:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZwkreTDZYRzOioM0vOEFCDM8ham24KdS3T2psfFDltI=; b=CE1R/p0wQwDmY5V+4OTOHy+jWDAO0K4Y11QbtlUTNV3G9Szclk3yTqgwZYUYhw30Sx+e8xWTK3Nmw6SRRX7EnYMVHggQGgFM/PlzPp4nKjCCXpjK5LsSaE0POFyZomfjbR5JZAr7QvzYIjfDPO1Q7xlW5LpYETNNHvX7W4U5CZ0= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Mon, 11 Sep 2017 13:18:27 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 11 Sep 2017 13:18:28 +0000 From: Kent Watsen To: t.petch , "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 Thread-Index: AQHTKL1eJb3TJyDFE0+yVaGPTwsSVKKrIFgAgAGVYPeAAraoAA== Date: Mon, 11 Sep 2017 13:18:28 +0000 Message-ID: References: <108FD1E3-7944-4AC9-8CE4-1AC0082BB2DE@juniper.net> <61A96A1E-BC4D-4AB8-B26E-C6960CE1DD23@juniper.net> <00cb01d32983$552c5660$4001a8c0@gateway.2wire.net> In-Reply-To: <00cb01d32983$552c5660$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB659; 6:ggA9bZBXAD2v2AX7ktVoSyBgBOITpH9PBkWXVUTJ//1/vjHf+BxOhVNFlDaD1vzwH3hhIhiT2hLH4rRC08H6HDVepUqeBI8xTEEm6c4KTpOjhoh7/8fyQolmpEFp1gz4KaaWHG0e8Zed0o6h1SCggR3TtpGJAkfOVgeqnhOcjmpEgdJkEqsV+vyUkAt/lfPJGFTVzqJD3OjqAx5oDi41ysqT0VbOjMAT8wZKfSVo00ogQYYnoqXD5iuW2gxEMAInNIRnocq5DtBE7zbXTWbiFFW3KtH4d/CeLzMPKjbcuRAd0Ae/CCxiusJoTCx+EB9sRnBEnGEssI01Cx88vva5yA==; 5:BhWw4Nqj0R3goHTh7sGku+hK3Z1mTenA/74UdN1lgOsyPC4xSm3Q+u91e/L6Ygva2QatvawcFm3drqqQ78mlzD+aXpw5eEAahgpeCKl7iW7HogLcI24Knch+tsGu3iPOeV9zBMkARDWCdUfmBJMsow==; 24:w4Y2xk2c3BSeqMkDyu8lb0OYJyAPIInnl9IV+nRM7UL5B59Fj7t8PqpNGA4BWaBxbaSUouB+q16ilmt+CeyKweozzSn1KwDMiWrzXilr3KU=; 7:kaumqarzr+rKoEthQxu+99kjc22S6Lny/aXsXn0vi/GMchRM3juF3m+8rDzHfuy3H+zzhLZE8J9AUizukjiiIOF/JiIhK/oIHgO5elv8AMnJuAWbaD4sdIXXXgjUYYuzNLz7+0sgAiD1cjpSYljajo67BgExtMceTi4GDtszkyPqrQbYCBdZ+Wn7K1T2/3nCDyqzm8b+FO6rSIRw2P6hqZzXaBjTqoN2BgyA8StEbfQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 476b55d8-777f-4628-4f3d-08d4f917972e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB659; x-ms-traffictypediagnostic: BLUPR05MB659: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB659; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB659; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(83506001)(7736002)(5660300001)(14454004)(66066001)(6436002)(6116002)(229853002)(68736007)(2900100001)(8676002)(230783001)(2501003)(101416001)(6246003)(6512007)(81156014)(102836003)(99286003)(3846002)(8936002)(81166006)(33656002)(97736004)(8666007)(6486002)(77096006)(6506006)(54356999)(53936002)(105586002)(50986999)(76176999)(82746002)(83716003)(4001350100001)(25786009)(2906002)(478600001)(2950100002)(3660700001)(36756003)(189998001)(305945005)(106356001)(15650500001)(86362001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB659; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <15F8BDEB8C24AD42B7FC707F16A11663@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 13:18:28.0634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB659 Archived-At: Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:18:31 -0000 DQpIaSBUb20sDQoNCkkgYXBwcmVjaWF0ZSB0aGUgY29uY2VybiwgYnV0IEkgdGhpbmsgdGhlIHJv bGUgb2YgdGhpcyBkb2N1bWVudA0KaXMgb2J2aW91cywgb3IgYXQgbGVhc3Qgd2VsbCB1bmRlcnN0 b29kIHRvIG5lZWRpbmcgdG8gZGVmaW5lIGENCm5ldyAnbm90aWZpY2F0aW9uJyBtZXNzYWdlIGZv cm1hdCB1c2luZyB5YW5nLWRhdGEuICBUaGlzIHNob3VsZA0KaGF2ZSBiZWVuIGRvbmUgYmVmb3Jl LCBldmVuIGJlZm9yZSBkaXNjdXNzaW5nIG5ldyBtZXNzYWdlIGhlYWRlcnMsDQp3ZSdyZSBqdXN0 IG9ubHkgZGlzY292ZXJpbmcgaXQgbm93LiAgSXQncyBteSBleHBlY3RhdGlvbiB0aGF0DQp0aGUg YXV0aG9ycyBvZiB0aGlzIGRyYWZ0IHdpbGwgaGF2ZSB0aGUgLTAxIHZlcnNpb24gb3V0IEFTQVAg dG8NCm1ha2UgdGhhdCBhZGp1c3RtZW50Lg0KDQpNYXJ0aW4gZXhwcmVzc2VkIGEgbGFyZ2VyIGNv bmNlcm4gYXMgd2VsbCwgb25lIHRoYXQgSSBzaGFyZSwgDQpyZWdhcmRpbmcgdGhlIGdlbmVyYWwg c3RhdGUgb2YgdGhlIGRyYWZ0cy4gIFBhcnQgb2YgdGhlIGlzc3VlDQpzZWVtcyB0byBiZSB0aGF0 IGhvdyB0aGV5IGZpdCB0b2dldGhlciBpc24ndCBlYXN5IHRvIHVuZGVyc3RhbmQuDQpUbyBhZGRy ZXNzIHRoaXMsIEkndmUgYXNrZWQgdGhlIGF1dGhvcnMgdG8gcHJlcGFyZSBhbiBvdmVydmlldw0K ZG9jdW1lbnQgdGhhdCBJIGhvcGUgd2lsbCBiZSBzaGFyZWQgd2l0aCB0aGUgV0cgc2hvcnRseS4g QW5vdGhlcg0KaXNzdWUgd2l0aCB0aGVzZSBkcmFmdHMsIEkgdGhpbmssIGlzIHVzZSBvZiB1bmNv bW1vbiB0ZXJtcyBhbmQNCmV4dHJhbmVvdXMgdGV4dCBsZWFkaW5nIHRvIGEgc2Vuc2Ugb2Ygb3Bl bi1lbmRlZG5lc3MuIEhvcGVmdWxseQ0KdGhlIGF1dGhvcnMgd2lsbCB1cGRhdGUgYWxsIHRoZSBk cmFmdHMgd2lsbCBhbiBleWUgdG93YXJkcyANCmFkZHJlc3NpbmcgdGhlc2UgZWRpdG9yaWFsIGlz c3VlcyBhcyB3ZWxsLg0KDQpPbmNlIGFsbCB0aGlzIGlzIGRvbmUsIEkgYmVsaWV2ZSB0aGUgZHJh ZnRzIHdpbGwgYmUgaW4gZ29vZA0Kc2hhcGUgZm9yIHRob3JvdWdoIHJldmlld3MsIHBlcmhhcHMg Zm9yIHRoZSBmaXJzdCB0aW1lLiAgSSBhc2sNCnRoZSBhdXRob3JzIHRvIHBsZWFzZSByZWZyYWlu IGZyb20gYWRkaW5nIG1vcmUgZmVhdHVyZXMgdW50aWwNCnRoaXMgc3RhYmlsaXR5IGlzIHJlYWNo ZWQuDQoNCg0KS2VudCAvLyBjby1jaGFpcg0KDQoNCg0K From nobody Mon Sep 11 08:02:10 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EB21330B7; Mon, 11 Sep 2017 08:02:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= To: Cc: draft-ietf-netconf-rfc6536bis.all@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150514212825.9627.4482318729492694955@ietfa.amsl.com> Date: Mon, 11 Sep 2017 08:02:08 -0700 Archived-At: Subject: [Netconf] Yangdoctors last call review of draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 15:02:08 -0000 Reviewer: Radek Krejčí Review result: Ready with Nits Hi, I have been assigned to review draft-ietf-netconf-rfc6536bis as YANG Doctor. The document is almost ready to publish, I have just the following few comments: - section 1.1 Terminology - access control rule: s/protocol operation/access operation/ - "NETCONF transport" is mentioned at several places within the draft and model in connection with information about the user. What about the RESTCONF transport, shouldn't it be also mentioned or (better) shouldn't it be changed to a general transport of the protocols accessing the datastore? - /nacm/rule-list/rule/rule-type in schema: I would consider to explicitely state into which case the action and notification defined in data subtree belong to. Especially the notification placement can be confusing at the first sight since there is the "notification" case. From nobody Mon Sep 11 14:05:58 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887D0132F8F for ; Mon, 11 Sep 2017 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxopEbcZmPJ9 for ; Mon, 11 Sep 2017 14:05:55 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900A11331F5 for ; Mon, 11 Sep 2017 14:05:55 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id c80so21707215lfh.0 for ; Mon, 11 Sep 2017 14:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qwYEHx/IgCa+mzCK5kqEA36Zxdx1h5WHTH+25/mgf9A=; b=Tg7bf46sEWcRUV+M1QjJSDy5nthoxlvftDXwZ1HirL/5tp4hih/3JZx6gsfpI53cnK Dr0YZqXc2vBtTsXIx1ePD7BMoxZvEyv8jjX+PWc0YVc/f3WPuDTdZwH+RrbD67a89sZx Jf9Or0t0ezUQo6SxP34QrysLEqDkmEncMCWpK5IMnhQxY4gHsX7fsKqEIMR6Kvm29WuL F8X4xTceJQDxcfNjP6FKboV68nt59wG9qyv1YW5oHMXtYsuZGCaVSURzA3G1FJfvol8F GfUbH9pRn1rBReP7dKPIV1vgJi7fli9GgwFMotjlMONjLbwU5MkueJB3k66iIglOc9LG XUhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qwYEHx/IgCa+mzCK5kqEA36Zxdx1h5WHTH+25/mgf9A=; b=n0gV2kYGhKy/AXazdgwKxVY0YhLolhrUeR/xN+J1qp5gGAvgWN7sjLaf3o9d4c4Ox4 MHxtto5LOmTIX/VNtqYh7dqF2a4u1W9zsZdZLgIYgx2pxbtsL573A6suyT6wFIhwZ2eY HKuNarKLdpNl4tbm5nub5EgROp2fL4omVq7r5gjeX4OaB0BdlPWgPrXCOpUuE5V8p0TF TgHOJN3f8A3hhixAfS8ZgjpwCbCC/kWA338qKxBhFzbfL/bQ9lL4xem2GolLqtg3M8F7 H43uYjyHx2K/99zJ7UlW8/GDRIqzkCAAlE5+fOxzBb24yMmqhtjUX6KkT1L2N7cT6k4e n5Vw== X-Gm-Message-State: AHPjjUhHZS0KlF7qsD9pHVZDA+CNBhTqTAZRhww/OVhQGhjhugQfXNAc xATqitant4Kibj3c5iXIFU+Wv7hDK7Iq X-Google-Smtp-Source: AOwi7QB7GDf8oV0eiwPskSMYMB76Z9/AGeRICJx4awn5BF9+5wFwMGl5/v2vhTk7tiWsuQH6eimf9g+i9Zoxh9rGV+U= X-Received: by 10.25.204.198 with SMTP id c189mr5106286lfg.49.1505163953782; Mon, 11 Sep 2017 14:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.41 with HTTP; Mon, 11 Sep 2017 14:05:53 -0700 (PDT) In-Reply-To: <150514212825.9627.4482318729492694955@ietfa.amsl.com> References: <150514212825.9627.4482318729492694955@ietfa.amsl.com> From: Andy Bierman Date: Mon, 11 Sep 2017 14:05:53 -0700 Message-ID: To: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Cc: YANG Doctors , draft-ietf-netconf-rfc6536bis.all@ietf.org, Netconf Content-Type: multipart/alternative; boundary="94eb2c1a07fecb5e450558f04a6e" Archived-At: Subject: Re: [Netconf] Yangdoctors last call review of draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 21:05:57 -0000 --94eb2c1a07fecb5e450558f04a6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 11, 2017 at 8:02 AM, Radek Krej=C4=8D=C3=AD = wrote: > Reviewer: Radek Krej=C4=8D=C3=AD > Review result: Ready with Nits > > Hi, > I have been assigned to review draft-ietf-netconf-rfc6536bis as YANG > Doctor. > The document is almost ready to publish, I have just the following few > comments: > > - section 1.1 Terminology - access control rule: s/protocol > operation/access > operation/ > > fixed > - "NETCONF transport" is mentioned at several places within the draft and > model > in connection with information about the user. What about the RESTCONF > transport, shouldn't it be also mentioned or (better) shouldn't it be > changed > to a general transport of the protocols accessing the datastore? > > changed all NETCONF transport layer to just transport layer, which was already used in several places > - /nacm/rule-list/rule/rule-type in schema: I would consider to explicite= ly > state into which case the action and notification defined in data subtree > belong to. Especially the notification placement can be confusing at the > first > sight since there is the "notification" case. > > not sure what text this is about. Do you have section, para or page/para info? Andy --94eb2c1a07fecb5e450558f04a6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 11, 2017 at 8:02 AM, Radek Krej=C4=8D=C3=AD <rkrejci@cesne= t.cz> wrote:
Reviewer: Rade= k Krej=C4=8D=C3=AD
Review result: Ready with Nits

Hi,
I have been assigned to review draft-ietf-netconf-rfc6536bis as YANG Doctor= .
The document is almost ready to publish, I have just the following few comm= ents:

- section 1.1 Terminology - access control rule: s/protocol operation/acces= s
operation/


fixed

=C2=A0<= /div>
- "NETCONF transport" is mentioned at several places within the d= raft and model
in connection with information about the user. What about the RESTCONF
transport, shouldn't it be also mentioned or (better) shouldn't it = be changed
to a general transport of the protocols accessing the datastore?



changed all NETCONF tra= nsport layer to just transport layer,
which was already used in s= everal places

=C2=A0
- /nacm/rule-list/rule/rule-type in schema: I would consider to explicitely=
state into which case the action and notification defined in data subtree belong to. Especially the notification placement can be confusing at the fi= rst
sight since there is the "notification" case.


not sure what text = this is about.
Do you have section, para or= page/para info?


Andy

--94eb2c1a07fecb5e450558f04a6e-- From nobody Mon Sep 11 18:21:04 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA25120720; Mon, 11 Sep 2017 18:21:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150517926341.4589.8335942490710626257@ietfa.amsl.com> Date: Mon, 11 Sep 2017 18:21:03 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 01:21:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Ian Farrer Filename : draft-ietf-netconf-zerotouch-17.txt Pages : 69 Date : 2017-09-11 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its preconfigured initial state (e.g., factory default settings), and its deployment specific network management system (NMS). Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in the IANA Considerations section contains placeholder values for DHCP options pending IANA assignment. Please apply the following replacements: o "OPTION_V4_ZEROTOUCH_REDIRECT" --> the option code assigned for the "DHCPv4 Zero Touch Option" option o "OPTION_V6_ZEROTOUCH_REDIRECT" --> the option code assigned for the "DHCPv6 Zero Touch Option" option Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2017-09-11" --> the publication date of this draft Please update the following references to reflect their final RFC assignments: o I-D.ieft-netconf-netconf-client-server The following one Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 11 18:47:30 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDE9132710 for ; Mon, 11 Sep 2017 18:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwAMA3slT9Pf for ; Mon, 11 Sep 2017 18:47:26 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0116.outbound.protection.outlook.com [104.47.36.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACB0132705 for ; Mon, 11 Sep 2017 18:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I1wnkIZlkTy4ZuC1qDDKJIcnwfaI/xsgWepGg1Fx8n8=; b=YgPOoY1EkpoMfjDFIQUOuj/NS/uV3Ov6zn8gpH/H/8u9QdjzEtvhCvUm5N0daIH6bxE6evD25ociAteb9Vq7iXuq3aWT47kOO6XGdf1q8vKxnTj8TSCu9GaFFzZLbZ+2pjdFCR/TXXR7A0ohT03kMxzABhX52IUDCrvxJi75KZU= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB482.namprd05.prod.outlook.com (10.141.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 01:47:24 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 12 Sep 2017 01:47:23 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-17.txt Thread-Index: AQHTK2Vpm+pJHtu08kyCQJFo5LfSUqKwOEgA Date: Tue, 12 Sep 2017 01:47:21 +0000 Message-ID: <8130C8C0-3960-4809-8274-F21C180C629E@juniper.net> References: <150517926341.4589.8335942490710626257@ietfa.amsl.com> In-Reply-To: <150517926341.4589.8335942490710626257@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB482; 6:R/1975Ht4AJ6DNjFtEncwXmZWTQkLEeR3tV0on7v7xb+SfiqaTQXeTpBZjewBWH12h7aXkMWjTQ8i9xzUVJKYnKz2KkZQGVqHZB/IiyG44QxZKfzGzUn6yWmKxDYynJbdzNPAMH50d1tjT4HD71GxaawjmTNAkWhsChRt708WLfI2qk4quZuCaKjZw6e46GXZiSrFrS6IuSwfzoyjnxwYfJJmI4Tdll7VIEBb6JCJ2t3q9sj+pEvCpdkFqpZfGh4EqVgxTor+BIojap+C3w+RbH5rsOnyYyJJm5+1rAq6YG28q4HoslOkKUeGMhNKeUt3J5lL/774cUQBY/C3FYD9g==; 5:c+FP8Fn/aauaGqwmT02ZyEMaHBca0BfqF4oly4e26FFFGNcd6wuwJ35pjl8OG2SAGXlsnHjas9ayCDyfdSvTqOfzuTFozfffYlfkP2vU3IhPs8Y1B2AodSn6K41VQP9uxNDOy3mvE234QsE9PfYUfl67g4rXsfE7qfb15Oa9ZzM=; 24:8zbanL8hmsC9DkwQtdxd/GEIliRZ9e2jCfm6DwSd8M5PpC5KQ8bbCkcZ+cZPDh/aKcGaOxuBu0oKlBzQnRBfWfcSz0SEDGrtS9LdCIZhU44=; 7:P9ssiD3txpvh9nb6q5zFylk1lijQa6yR8BTIcFaQnZL8LiP/cp3v/My0QMLs3Xfsm0/KH25LYtlsrZcCmqFFkfkeungKDjxvxFWRnuc6F7S5Fbyfq/cWTniidYovb4eOtBuf2KZud03KrFX8dcKzA2sSuyUbte1hvyzM9Sv0I18EVB3qI3SjVpza+uXamT2oJo+NkIn3xH+IhB2lv65PeRSY1hmq3ALa3tn3uaYuf3E= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 48587d3e-44e4-4545-41c3-08d4f9803694 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB482; x-ms-traffictypediagnostic: BLUPR05MB482: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB482; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(54534003)(199003)(189002)(377424004)(36756003)(2900100001)(77096006)(66066001)(6486002)(2906002)(83716003)(7736002)(189998001)(81166006)(50986999)(1730700003)(83506001)(3660700001)(5660300001)(305945005)(81156014)(76176999)(101416001)(6506006)(3280700002)(8936002)(8676002)(316002)(54356999)(6436002)(68736007)(229853002)(230783001)(5640700003)(966005)(6512007)(6306002)(97736004)(105586002)(4001350100001)(2351001)(6246003)(110136004)(53936002)(106356001)(6916009)(478600001)(33656002)(2501003)(102836003)(82746002)(2950100002)(25786009)(86362001)(3846002)(6116002)(14454004)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB482; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6B4FDED8D4AF0A449CBDE40638FE869B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2017 01:47:22.3054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB482 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 01:47:29 -0000 DQpUaGlzIGNvbmNsdWRlcyB0aGUgdXBkYXRlcyBuZWVkZWQgdG8gYWRkcmVzcyBhbGwgdGhlIGNv bW1lbnRzDQpyYWlzZWQgZnJvbSB0aGUgcHJldmlvdXMgTGFzdCBDYWxsLiAgSXQgaXMgc3ViamVj dGl2ZSBhcyB0byBpZg0KdGhlICJtYWtlIGl0IG1vcmUgY29uY2lzZSIgY29tbWVudCB3YXMgZnVs bHkgYWRkcmVzc2VkIGJ1dCwNCm90aGVyd2lzZSwgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBhbm90 aGVyIExhc3QgQ2FsbCBhdHRlbXB0Lg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KLS0NCg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg TmV0d29yayBDb25maWd1cmF0aW9uIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAg ICAgICAgICA6IFplcm8gVG91Y2ggUHJvdmlzaW9uaW5nIGZvciBORVRDT05GIG9yIFJFU1RDT05G IGJhc2VkIE1hbmFnZW1lbnQNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VudCBXYXRzZW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgTWlrYWVsIEFicmFoYW1zc29uDQogICAgICAgICAg ICAgICAgICAgICAgICAgIElhbiBGYXJyZXINCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LW5ldGNvbmYtemVyb3RvdWNoLTE3LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDY5DQoJRGF0ZSAg ICAgICAgICAgIDogMjAxNy0wOS0xMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgcHJlc2Vu dHMgYSBzZWN1cmUgdGVjaG5pcXVlIGZvciBlc3RhYmxpc2hpbmcgYSBORVRDT05GIG9yDQogICBS RVNUQ09ORiBjb25uZWN0aW9uIGJldHdlZW4gYSBuZXdseSBkZXBsb3llZCBkZXZpY2UsIGNvbmZp Z3VyZWQgd2l0aA0KICAganVzdCBpdHMgcHJlY29uZmlndXJlZCBpbml0aWFsIHN0YXRlIChlLmcu LCBmYWN0b3J5IGRlZmF1bHQNCiAgIHNldHRpbmdzKSwgYW5kIGl0cyBkZXBsb3ltZW50IHNwZWNp ZmljIG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW0NCiAgIChOTVMpLg0KDQpFZGl0b3JpYWwgTm90 ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0KDQogICBUaGlzIGRyYWZ0IGNvbnRhaW5z IG1hbnkgcGxhY2Vob2xkZXIgdmFsdWVzIHRoYXQgbmVlZCB0byBiZSByZXBsYWNlZA0KICAgd2l0 aCBmaW5hbGl6ZWQgdmFsdWVzIGF0IHRoZSB0aW1lIG9mIHB1YmxpY2F0aW9uLiAgVGhpcyBub3Rl DQogICBzdW1tYXJpemVzIGFsbCBvZiB0aGUgc3Vic3RpdHV0aW9ucyB0aGF0IGFyZSBuZWVkZWQu ICBQbGVhc2Ugbm90ZQ0KICAgdGhhdCBubyBvdGhlciBSRkMgRWRpdG9yIGluc3RydWN0aW9ucyBh cmUgc3BlY2lmaWVkIGFueXdoZXJlIGVsc2UgaW4NCiAgIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEFy dHdvcmsgaW4gdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBjb250YWlucyBwbGFjZWhv bGRlcg0KICAgdmFsdWVzIGZvciBESENQIG9wdGlvbnMgcGVuZGluZyBJQU5BIGFzc2lnbm1lbnQu ICBQbGVhc2UgYXBwbHkgdGhlDQogICBmb2xsb3dpbmcgcmVwbGFjZW1lbnRzOg0KDQogICBvICAi T1BUSU9OX1Y0X1pFUk9UT1VDSF9SRURJUkVDVCIgLS0+IHRoZSBvcHRpb24gY29kZSBhc3NpZ25l ZCBmb3INCiAgICAgIHRoZSAiREhDUHY0IFplcm8gVG91Y2ggT3B0aW9uIiBvcHRpb24NCg0KICAg byAgIk9QVElPTl9WNl9aRVJPVE9VQ0hfUkVESVJFQ1QiIC0tPiB0aGUgb3B0aW9uIGNvZGUgYXNz aWduZWQgZm9yDQogICAgICB0aGUgIkRIQ1B2NiBaZXJvIFRvdWNoIE9wdGlvbiIgb3B0aW9uDQoN CiAgIEFydHdvcmsgaW4gdGhpcyBkb2N1bWVudCBjb250YWlucyBzaG9ydGhhbmQgcmVmZXJlbmNl cyB0byBkcmFmdHMgaW4NCiAgIHByb2dyZXNzLiAgUGxlYXNlIGFwcGx5IHRoZSBmb2xsb3dpbmcg cmVwbGFjZW1lbnRzOg0KDQogICBvICAiWFhYWCIgLS0+IHRoZSBhc3NpZ25lZCBSRkMgdmFsdWUg Zm9yIHRoaXMgZHJhZnQNCg0KICAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHBs YWNlaG9sZGVyIHZhbHVlcyBmb3IgdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMg ZHJhZnQuICBQbGVhc2UgYXBwbHkgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVudDoNCg0KICAgbyAg IjIwMTctMDktMTEiIC0tPiB0aGUgcHVibGljYXRpb24gZGF0ZSBvZiB0aGlzIGRyYWZ0DQogICBQ bGVhc2UgdXBkYXRlIHRoZSBmb2xsb3dpbmcgcmVmZXJlbmNlcyB0byByZWZsZWN0IHRoZWlyIGZp bmFsIFJGQw0KICAgYXNzaWdubWVudHM6DQoNCiAgIG8gIEktRC5pZWZ0LW5ldGNvbmYtbmV0Y29u Zi1jbGllbnQtc2VydmVyDQoNCiAgIFRoZSBmb2xsb3dpbmcgb25lIEFwcGVuZGl4IHNlY3Rpb24g aXMgdG8gYmUgcmVtb3ZlZCBwcmlvciB0bw0KICAgcHVibGljYXRpb246DQoNCiAgIG8gIEFwcGVu ZGl4IEEuICBDaGFuZ2UgTG9nDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJz aW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1uZXRjb25mLXplcm90b3VjaC0xNw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTE3DQoNCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTE3DQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQo= From nobody Tue Sep 12 02:29:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C463133029; Tue, 12 Sep 2017 02:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfaipiHB52vH; Tue, 12 Sep 2017 02:29:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 3560A133011; Tue, 12 Sep 2017 02:29:17 -0700 (PDT) Received: from [IPv6:2001:67c:1220:8b4:2:143f:863d:b8cf] (unknown [IPv6:2001:67c:1220:8b4:2:143f:863d:b8cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id E7F23400275; Tue, 12 Sep 2017 11:29:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1505208555; bh=4LQ94hJ70ialoKdy75r4EUwu1bVdUc/LfMqJGCzCmes=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QkmMaZ17DvCdMDQE1cnPAEkD5ud33tKcgvmhpre0nacMqFcnSpOL/hhYNdVajhUZG pCnoO0guwXBOQJRHZ6BN8Xhtj54vyh8k+jLi/2VZN5TMLZdWwscJFrt0Ye43qFZPVj 9h9Atc+h+awfA6xBUa1x4SUCL+6gheMNxIVkbHzw= To: Andy Bierman Cc: YANG Doctors , draft-ietf-netconf-rfc6536bis.all@ietf.org, Netconf References: <150514212825.9627.4482318729492694955@ietfa.amsl.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Organization: CESNET, z.s.p.o. Message-ID: Date: Tue, 12 Sep 2017 11:29:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Yangdoctors last call review of draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 09:29:20 -0000 Dne 11.9.2017 v 23:05 Andy Bierman napsal(a): > > - /nacm/rule-list/rule/rule-type in schema: I would consider to > explicitely > state into which case the action and notification defined in data > subtree > belong to. Especially the notification placement can be confusing at > the first > sight since there is the "notification" case. > > > not sure what text this is about. > Do you have section, para or page/para info? > > It's description of cases in rule-type choice (page 39 in draft). One of the cases is named "notification" which may be little confusing for notifications defined in data subtree. I propose the following change (or something similar) in the description of the data-node case: ... associated with the data node controlled by this rule. -> ... associated with the data node, action or notification (specified within a data tree) controlled by this rule. Radek From nobody Tue Sep 12 06:32:36 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F2133017 for ; Tue, 12 Sep 2017 06:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 227Q1cGrDoqr for ; Tue, 12 Sep 2017 06:32:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3BB1321C7 for ; Tue, 12 Sep 2017 06:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2992; q=dns/txt; s=iport; t=1505223152; x=1506432752; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=YJodsVAu8xSb73F0jhXdrdo/KMri3boo3xlqxPyG8dE=; b=UNql9BQh82chhnZu+Rmij+ICTDN3gOJ3OiniTCd2k1RN5G0/5q3ltqpf S3837wmRp1O26+Uljsug8s0Ql/37m4id4m1fXPKEvYIRqja71H1V6TeWu HT4zqcV7stw4iIhayIHXuHlweSIwwBslcZm36D4O4zhmvwF7KtI7mJtA9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeCADM4LdZ/xbLJq1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBhS2EHosVkHkJgRmXQwqKQBQBAgEBAQEBAQFrKIVCDwEFdgImAl8BDAgBAYo?= =?us-ascii?q?tqzaCJ4szAQEBBwEBAQEkgQ6CHYNSgWMrC4I9iD+CYQWJfIkSjWaUUoITiUIkh?= =?us-ascii?q?nmNWodVgTk2IUFMMiEIHBWHZj+KPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208";a="657404195" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 13:32:28 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8CDWR6j016063; Tue, 12 Sep 2017 13:32:27 GMT To: "netconf@ietf.org" , Andy Bierman , Martin Bjorklund From: Robert Wilton Message-ID: Date: Tue, 12 Sep 2017 14:32:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Netconf] NMDA related comments on draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:32:34 -0000 Hi, I appreciate that this document is well passed WG LC, but I raised an NMDA related question with one of the authors and he suggested that I post the question here. Sections 3.2 and 3.2.1 of rfc6536bis-04 already cover the new datastores described in NMDA - good. However, both the RESTCONF NMDA draft and NETCONF NMDA draft are also introducing new functionality that ideally would be implicitly covered by this draft. I think that section in 3.2.3 on RESTCONF Methods, and in particular "Table 1" at the end of this section already generically cover the changes proposed in RESTCONF NMDA, and no changes are required.  However, this may be worth confirming. But for NETCONF, the plan is to introduce a new "get-data" operation, and hence it might be helpful to add a paragraph to the beginning on section 3.2.4, in a similar style to the first paragraph in 3.2.5, to make the text apply more generically. Hence I propose that the following paragraph is inserted into the beginning of section 3.2.4: NEW:    The NACM access rights are not directly coupled to the and    protocol operations, but apply to all operations that would result in a    'read' access operation to the target datastore.  This sectiondescribes    how these access rights apply to the specific accessoperations supported    by the and protocol operations. Or in context with the existing -04 text: 3.2.4.  and Operations    The NACM access rights are not directly coupled to the and    protocol operations, but apply to all operations that would result in a    'read' access operation to the target datastore.  This sectiondescribes    how these access rights apply to the specific accessoperations supported    by the and protocol operations.    Data nodes to which the client does not have read access are silently    omitted from the message.  This is done to allow NETCONF    filters for and to function properly, instead of    causing an "access-denied" error because the filter criteria would    otherwise include unauthorized read access to some data nodes.  For    NETCONF filtering purposes, the selection criteria is applied to the    subset of nodes that the user is authorized to read, not the entire    datastore. 3.2.5.  Operation    The NACM access rights are not directly coupled to the    "operation" attribute, although they are similar. Instead, a NACM    access right applies to all protocol operations that would result in    a particular access operation to the target datastore.  This section    describes how these access rights apply to the specific access    operations supported by the protocol operation.    ... Thanks, Rob From nobody Tue Sep 12 08:56:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DD2132D8A for ; Tue, 12 Sep 2017 08:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJn1SwkdJvxB for ; Tue, 12 Sep 2017 08:56:20 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02EB1326FE for ; Tue, 12 Sep 2017 08:56:19 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id q132so27500320lfe.5 for ; Tue, 12 Sep 2017 08:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wVpnrcfuDbrKSYRuUqOwdWgXF8fuq/t+nMnlpF8Mbs0=; b=TLpfXwZ2MaPSvmqK/BefmeWFiPx2sdqVymXhA+y0+MV1bKCxCvcbIHeZIKjeOgFpA3 33SKswmgPj6waSVoRMeJNVx1+B0rkckVhu3q8DSMnS0JUuHIX0GKvyeZsLECaqy+b5DD f3Sg01b8iLSjvtX2ebZzTugr5ZXOABS74zyvwEcEs/gQ9YgKaIEfi9B4ODuGjNWH4gjP uYxdXiwZ6IWfZip3xFsH9s20PlKwUhDAfdYNfh0KD3oCCECYtrxwEumfg59uLqZGMFUH Zss7qoimEmCS/xnlF29xVp6uqCEJvMA2zq/zffk52zyyw/7dgBj33Rreukdm13GkO+tN 1jgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wVpnrcfuDbrKSYRuUqOwdWgXF8fuq/t+nMnlpF8Mbs0=; b=e9aDNfO+Nsl0W8CaUFEcDIiAvXvLCNcIsiSOkFPm0VTsZD/37XtFSl8J3BIOk5ZOMb srJBOp4y47DuPQryLWHuqYpJUYR4lmMDd34OnFRXpbyWthtaJDsayRpfggFPXcR52rbK PTDjmiZlEC2IkW/54N8s7c+Vc9h5GctG2rfHy27MV4E3u1DafSvUM1zqU9yZeiZ1LcBW ZMyW3hXkhEasxJFR9xxxHKpCOLt0e1WIRivzGq6rkuW3rj6dUEGaR2shTpDw2axOpxXh GsJRvJvXosYFV8mCgd5tES1zntXLp6HXABuVGV9TnJpxHwEghl96s4uCYYoo82p0DMpS RoGA== X-Gm-Message-State: AHPjjUgioZxNfyw+z21AUUyoVY/FKo2PBq/iRkhQ4nDFGIFGVAoRX8rN 6xUQLzjYrUYiTcd+dhYdgrtgXyfNFeT7 X-Google-Smtp-Source: AOwi7QA0fR5RRHQ/z2tfTAp8QExLBGeVm47U2Y0JZ1SGlJ1KrqtYkB8x/w+U+rfIhC3AfP87uoqhDS11PqH+wHFXaWs= X-Received: by 10.25.211.14 with SMTP id k14mr5790386lfg.51.1505231778069; Tue, 12 Sep 2017 08:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.41 with HTTP; Tue, 12 Sep 2017 08:56:17 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Tue, 12 Sep 2017 08:56:17 -0700 Message-ID: To: Robert Wilton Cc: "netconf@ietf.org" , Martin Bjorklund Content-Type: multipart/alternative; boundary="001a11400d726fd23c05590015b6" Archived-At: Subject: Re: [Netconf] NMDA related comments on draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 15:56:22 -0000 --001a11400d726fd23c05590015b6 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 6:32 AM, Robert Wilton wrote: > Hi, > > I appreciate that this document is well passed WG LC, but I raised an NMDA > related question with one of the authors and he suggested that I post the > question here. > > Sections 3.2 and 3.2.1 of rfc6536bis-04 already cover the new datastores > described in NMDA - good. > > However, both the RESTCONF NMDA draft and NETCONF NMDA draft are also > introducing new functionality that ideally would be implicitly covered by > this draft. > > I think that section in 3.2.3 on RESTCONF Methods, and in particular > "Table 1" at the end of this section already generically cover the changes > proposed in RESTCONF NMDA, and no changes are required. However, this may > be worth confirming. > > But for NETCONF, the plan is to introduce a new "get-data" operation, and > hence it might be helpful to add a paragraph to the beginning on section > 3.2.4, in a similar style to the first paragraph in 3.2.5, to make the text > apply more generically. Hence I propose that the following paragraph is > inserted into the beginning of section 3.2.4: > > NEW: > > The NACM access rights are not directly coupled to the and > > protocol operations, but apply to all operations that would > result in a > 'read' access operation to the target datastore. This sectiondescribes > how these access rights apply to the specific accessoperations supported > by the and protocol operations. > > > OK with me to add this text as the new first paragraph to 3.2.4 Andy > Or in context with the existing -04 text: > > 3.2.4. and Operations > > The NACM access rights are not directly coupled to the and > > protocol operations, but apply to all operations that would > result in a > 'read' access operation to the target datastore. This sectiondescribes > how these access rights apply to the specific accessoperations supported > by the and protocol operations. > > Data nodes to which the client does not have read access are silently > omitted from the message. This is done to allow NETCONF > filters for and to function properly, instead of > causing an "access-denied" error because the filter criteria would > otherwise include unauthorized read access to some data nodes. For > NETCONF filtering purposes, the selection criteria is applied to the > subset of nodes that the user is authorized to read, not the entire > datastore. > > 3.2.5. Operation > > The NACM access rights are not directly coupled to the > "operation" attribute, although they are similar. Instead, a NACM > access right applies to all protocol operations that would result in > a particular access operation to the target datastore. This section > describes how these access rights apply to the specific access > operations supported by the protocol operation. > > ... > > Thanks, > Rob > --001a11400d726fd23c05590015b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 12, 2017 at 6:32 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
Hi,

I appreciate that this document is well passed WG LC, but I raised an NMDA = related question with one of the authors and he suggested that I post the q= uestion here.

Sections 3.2 and 3.2.1 of rfc6536bis-04 already cover the new datastores de= scribed in NMDA - good.

However, both the RESTCONF NMDA draft and NETCONF NMDA draft are also intro= ducing new functionality that ideally would be implicitly covered by this d= raft.

I think that section in 3.2.3 on RESTCONF Methods, and in particular "= Table 1" at the end of this section already generically cover the chan= ges proposed in RESTCONF NMDA, and no changes are required.=C2=A0 However, = this may be worth confirming.

But for NETCONF, the plan is to introduce a new "get-data" operat= ion, and hence it might be helpful to add a paragraph to the beginning on s= ection 3.2.4, in a similar style to the first paragraph in 3.2.5, to make t= he text apply more generically. Hence I propose that the following paragrap= h is inserted into the beginning of section 3.2.4:

NEW:

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <get= > and <get-config>
=C2=A0=C2=A0 protocol operations, but apply to all <rpc> operations t= hat would result in a
=C2=A0=C2=A0 'read' access operation to the target datastore.=C2=A0= This sectiondescribes
=C2=A0=C2=A0 how these access rights apply to the specific accessoperations= supported
=C2=A0=C2=A0 by the <get> and <get-config> protocol operations.=




OK with me to add this = text as the new first paragraph to 3.2.4


Andy
=C2=A0
Or in context with the existing -04 text:

3.2.4.=C2=A0 <get> and <get-config> Operations

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <get= > and <get-config>
=C2=A0=C2=A0 protocol operations, but apply to all <rpc> operations t= hat would result in a
=C2=A0=C2=A0 'read' access operation to the target datastore.=C2=A0= This sectiondescribes
=C2=A0=C2=A0 how these access rights apply to the specific accessoperations= supported
=C2=A0=C2=A0 by the <get> and <get-config> protocol operations.=

=C2=A0=C2=A0 Data nodes to which the client does not have read access are s= ilently
=C2=A0=C2=A0 omitted from the <rpc-reply> message.=C2=A0 This is done= to allow NETCONF
=C2=A0=C2=A0 filters for <get> and <get-config> to function pro= perly, instead of
=C2=A0=C2=A0 causing an "access-denied" error because the filter = criteria would
=C2=A0=C2=A0 otherwise include unauthorized read access to some data nodes.= =C2=A0 For
=C2=A0=C2=A0 NETCONF filtering purposes, the selection criteria is applied = to the
=C2=A0=C2=A0 subset of nodes that the user is authorized to read, not the e= ntire
=C2=A0=C2=A0 datastore.

3.2.5.=C2=A0 <edit-config> Operation

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <edi= t-config>
=C2=A0=C2=A0 "operation" attribute, although they are similar. In= stead, a NACM
=C2=A0=C2=A0 access right applies to all protocol operations that would res= ult in
=C2=A0=C2=A0 a particular access operation to the target datastore.=C2=A0 T= his section
=C2=A0=C2=A0 describes how these access rights apply to the specific access=
=C2=A0=C2=A0 operations supported by the <edit-config> protocol opera= tion.

=C2=A0=C2=A0 ...

Thanks,
Rob

--001a11400d726fd23c05590015b6-- From nobody Wed Sep 13 10:05:12 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548813292D for ; Wed, 13 Sep 2017 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1CUmcQqYPs7 for ; Wed, 13 Sep 2017 10:05:04 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9407C1252BA for ; Wed, 13 Sep 2017 10:04:35 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id m199so2263174lfe.3 for ; Wed, 13 Sep 2017 10:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mgoLkuqRCrLOPB6HNz25CZLWqwKW/2mBf5jyCWnJ18E=; b=Xi+f+pzjRvZcX1WcHb4T0+bxOFrdE9EqolGi+vcwt/A1m1q31dKnElqHBTZF9H3+hF frQ229JAAsAMw0nihbIznSmbjTQ43iZPndA3b1QqS9/CBCCwgY/wjLHGwUfLk8yk9V/7 1FNUSdD54gdPTGBXhsJMlHg/zJId2ZcUODOs7H9vojOjXjI47chl62ACskq0BneY/lF8 X3gNQ3NBbS3QnSkgDxCJeK7MIdf14xufEpsNRfL4MhhMbvSeS/1H3sFqT7YZf+oY8if9 Hd7AeeYcVdhoBI4IH84G8aJL3y+55i/Utzf064hykGX03gY8heCxRn8/jgRLlzJEaFPL m5dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mgoLkuqRCrLOPB6HNz25CZLWqwKW/2mBf5jyCWnJ18E=; b=Mb+j8spiutHZHjHDTka14ZgYR87n7lawb28n1A/R7u23inDDCTOf6OJ9MWezLlb69j PkZn5D9/AjaVErnsPbVHgDU03e7i3Yp0IUQsGSAzkYqLst/+4kerI3p4eFUzw+MaJP5h vVMZ8p/XbmRpLuToyNvQNCau+Z5i5igYPmrsrZ9fs1KxVPz7ZHomU8ugQNb7E7QR5V+j w1EGM6aiu559ELqwsNrdyVZanmu/49u1ykmNb2tejNI0HVbMzRkJBiUTi21sH9gugp3+ nXEtbqxIhES5A35hvGarB/tha/oDhG8BaSOb8P6n7cLc0KIW+Nv4+oX8dK1+C5qsMD8l YTsA== X-Gm-Message-State: AHPjjUgPJTTFAA8lL0m2qXYhk8G49u0lS/1pzY+U5xAsrz64i7bXt1da tvvJer+yu2CNaYOtuJd1KIBg2IJpEduNqKbAG1jBjQ== X-Google-Smtp-Source: AOwi7QCp9pFJDP4gVWDeTV1oGPArmMvjdDj0U9rLWRQBUYNbPblrgiQFvj+6vst5AxgI6wpz14abiuTkZlQh6+JejTA= X-Received: by 10.25.22.228 with SMTP id 97mr7166368lfw.205.1505322273834; Wed, 13 Sep 2017 10:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.41 with HTTP; Wed, 13 Sep 2017 10:04:33 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 13 Sep 2017 10:04:33 -0700 Message-ID: To: Robert Wilton Cc: "netconf@ietf.org" , Martin Bjorklund Content-Type: multipart/alternative; boundary="001a1140260c67a0d8055915273e" Archived-At: Subject: Re: [Netconf] NMDA related comments on draft-ietf-netconf-rfc6536bis-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:05:11 -0000 --001a1140260c67a0d8055915273e Content-Type: text/plain; charset="UTF-8" Hi, I have not seen any objections to clarifying this section so it supports NMDA. I will add this text to the github version. I will publish a new version of rfc6536bis that addresses your comments and the ops-dir review comments by Linda Dunbar. Andy On Tue, Sep 12, 2017 at 8:56 AM, Andy Bierman wrote: > > > On Tue, Sep 12, 2017 at 6:32 AM, Robert Wilton wrote: > >> Hi, >> >> I appreciate that this document is well passed WG LC, but I raised an >> NMDA related question with one of the authors and he suggested that I post >> the question here. >> >> Sections 3.2 and 3.2.1 of rfc6536bis-04 already cover the new datastores >> described in NMDA - good. >> >> However, both the RESTCONF NMDA draft and NETCONF NMDA draft are also >> introducing new functionality that ideally would be implicitly covered by >> this draft. >> >> I think that section in 3.2.3 on RESTCONF Methods, and in particular >> "Table 1" at the end of this section already generically cover the changes >> proposed in RESTCONF NMDA, and no changes are required. However, this may >> be worth confirming. >> >> But for NETCONF, the plan is to introduce a new "get-data" operation, and >> hence it might be helpful to add a paragraph to the beginning on section >> 3.2.4, in a similar style to the first paragraph in 3.2.5, to make the text >> apply more generically. Hence I propose that the following paragraph is >> inserted into the beginning of section 3.2.4: >> >> NEW: >> >> The NACM access rights are not directly coupled to the and >> >> protocol operations, but apply to all operations that would >> result in a >> 'read' access operation to the target datastore. This sectiondescribes >> how these access rights apply to the specific accessoperations >> supported >> by the and protocol operations. >> >> >> > > OK with me to add this text as the new first paragraph to 3.2.4 > > > Andy > > >> Or in context with the existing -04 text: >> >> 3.2.4. and Operations >> >> The NACM access rights are not directly coupled to the and >> >> protocol operations, but apply to all operations that would >> result in a >> 'read' access operation to the target datastore. This sectiondescribes >> how these access rights apply to the specific accessoperations >> supported >> by the and protocol operations. >> >> Data nodes to which the client does not have read access are silently >> omitted from the message. This is done to allow NETCONF >> filters for and to function properly, instead of >> causing an "access-denied" error because the filter criteria would >> otherwise include unauthorized read access to some data nodes. For >> NETCONF filtering purposes, the selection criteria is applied to the >> subset of nodes that the user is authorized to read, not the entire >> datastore. >> >> 3.2.5. Operation >> >> The NACM access rights are not directly coupled to the >> "operation" attribute, although they are similar. Instead, a NACM >> access right applies to all protocol operations that would result in >> a particular access operation to the target datastore. This section >> describes how these access rights apply to the specific access >> operations supported by the protocol operation. >> >> ... >> >> Thanks, >> Rob >> > > --001a1140260c67a0d8055915273e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have not seen any objections to c= larifying this section so it supports NMDA.
I will add this text = to the github version.

I will publish a new versio= n of rfc6536bis that addresses your comments
and the ops-dir revi= ew comments by Linda Dunbar.


Andy


On Tue, Sep 12, 2017 at 8:56 AM, Andy Bierman <= ;andy@yumaworks.com= > wrote:
<= br>

On Tue, Sep 12= , 2017 at 6:32 AM, Robert Wilton <rwilton@cisco.com> wrote:<= br>
Hi,

I appreciate that this document is well passed WG LC, but I raised an NMDA = related question with one of the authors and he suggested that I post the q= uestion here.

Sections 3.2 and 3.2.1 of rfc6536bis-04 already cover the new datastores de= scribed in NMDA - good.

However, both the RESTCONF NMDA draft and NETCONF NMDA draft are also intro= ducing new functionality that ideally would be implicitly covered by this d= raft.

I think that section in 3.2.3 on RESTCONF Methods, and in particular "= Table 1" at the end of this section already generically cover the chan= ges proposed in RESTCONF NMDA, and no changes are required.=C2=A0 However, = this may be worth confirming.

But for NETCONF, the plan is to introduce a new "get-data" operat= ion, and hence it might be helpful to add a paragraph to the beginning on s= ection 3.2.4, in a similar style to the first paragraph in 3.2.5, to make t= he text apply more generically. Hence I propose that the following paragrap= h is inserted into the beginning of section 3.2.4:

NEW:

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <get= > and <get-config>
=C2=A0=C2=A0 protocol operations, but apply to all <rpc> operations t= hat would result in a
=C2=A0=C2=A0 'read' access operation to the target datastore.=C2=A0= This sectiondescribes
=C2=A0=C2=A0 how these access rights apply to the specific accessoperations= supported
=C2=A0=C2=A0 by the <get> and <get-config> protocol operations.=




OK with me to add this = text as the new first paragraph to 3.2.4


Andy
=C2=A0
Or in context with the existing -04 text:

3.2.4.=C2=A0 <get> and <get-config> Operations

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <get= > and <get-config>
=C2=A0=C2=A0 protocol operations, but apply to all <rpc> operations t= hat would result in a
=C2=A0=C2=A0 'read' access operation to the target datastore.=C2=A0= This sectiondescribes
=C2=A0=C2=A0 how these access rights apply to the specific accessoperations= supported
=C2=A0=C2=A0 by the <get> and <get-config> protocol operations.=

=C2=A0=C2=A0 Data nodes to which the client does not have read access are s= ilently
=C2=A0=C2=A0 omitted from the <rpc-reply> message.=C2=A0 This is done= to allow NETCONF
=C2=A0=C2=A0 filters for <get> and <get-config> to function pro= perly, instead of
=C2=A0=C2=A0 causing an "access-denied" error because the filter = criteria would
=C2=A0=C2=A0 otherwise include unauthorized read access to some data nodes.= =C2=A0 For
=C2=A0=C2=A0 NETCONF filtering purposes, the selection criteria is applied = to the
=C2=A0=C2=A0 subset of nodes that the user is authorized to read, not the e= ntire
=C2=A0=C2=A0 datastore.

3.2.5.=C2=A0 <edit-config> Operation

=C2=A0=C2=A0 The NACM access rights are not directly coupled to the <edi= t-config>
=C2=A0=C2=A0 "operation" attribute, although they are similar. In= stead, a NACM
=C2=A0=C2=A0 access right applies to all protocol operations that would res= ult in
=C2=A0=C2=A0 a particular access operation to the target datastore.=C2=A0 T= his section
=C2=A0=C2=A0 describes how these access rights apply to the specific access=
=C2=A0=C2=A0 operations supported by the <edit-config> protocol opera= tion.

=C2=A0=C2=A0 ...

Thanks,
Rob


--001a1140260c67a0d8055915273e-- From nobody Wed Sep 13 10:32:44 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D34F0132D8A; Wed, 13 Sep 2017 10:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150532396282.30385.3587655126572397832@ietfa.amsl.com> Date: Wed, 13 Sep 2017 10:32:42 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc6536bis-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:32:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Network Configuration Protocol (NETCONF) Access Control Model Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-rfc6536bis-05.txt Pages : 54 Date : 2017-09-13 Abstract: The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-rfc6536bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 14 06:58:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C43132D49 for ; Thu, 14 Sep 2017 06:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.602 X-Spam-Level: X-Spam-Status: No, score=-12.602 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6MQt-wMcwHu for ; Thu, 14 Sep 2017 06:57:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F1D132355 for ; Thu, 14 Sep 2017 06:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=527; q=dns/txt; s=iport; t=1505397476; x=1506607076; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=DSz8WfznGlXqApT70K2/QPnFiPmLUCguOVwh0qqvzMU=; b=IqfPDaOYhCrl2HB6AOa85qKhLIFGg27qsyOPlQqNeXZAMx4YkS0NSak0 xoucKr/7iTKzAf6/DgwBWzx/h/87B0k902C6BesCAHGlzFsscTa3D35Qz gE2P3zqm9lqCW1ytmks7UJSmXFpC2z+3mEIU8UG9wZa0ShJoSqs4LrV5K 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAgB1irpZ/xbLJq1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBhSyEHosUkEeYZQqKJRQBAgEBAQEBAQFrHQuFQhV2AiYCXw0IAQGKLpwLkBC?= =?us-ascii?q?CJ4s1AQEIAiaBDoIdg1KCDoJ9iAuCYAWhApRSgXuJWochjVyHVYE5NiFBTDIhC?= =?us-ascii?q?BwVh2c/iSMBAQE?= X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="697186805" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 13:57:52 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8EDvqZ2018429 for ; Thu, 14 Sep 2017 13:57:52 GMT From: Robert Wilton To: "netconf@ietf.org" Message-ID: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> Date: Thu, 14 Sep 2017 14:57:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 13:57:58 -0000 Hi, If I make a RESTCONF GET request with a path to a data resource that doesn't exist, but has an in scope schema default value, and I'm using one of the with-defaults options that means that the default value is returned, then what value is the "Last-Modified" header expected or required to take? Specifically, I am thinking of a device that uses per data resource timestamps for all explicitly configured data resources rather than having a single top level datastore resource timestamp. Thanks, Rob From nobody Thu Sep 14 08:05:43 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFAF132F31 for ; Thu, 14 Sep 2017 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF7s9ZCkuPki for ; Thu, 14 Sep 2017 08:05:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0109.outbound.protection.outlook.com [104.47.41.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D753132930 for ; Thu, 14 Sep 2017 08:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cvJH4/1PGYiGQK8j1w4lf335q9uMqtxej9P/Pddekx0=; b=eA+OwL0TyXVBhb9yfBTjUDDeBwLyLMRD6ilv33mN3SvwS/z7WvjY7YFkl9OgCqMk05RPmbWfrukZOrz43Xzd5QZEdGVu5pYAnzgTuORzQRRn8FO3MtzD6wW0OatN10QLh5VIQBUyCxCV2IsgUBuTrlIk6ga5+8+rWg8eSQlzfUU= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB596.namprd05.prod.outlook.com (10.141.203.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 15:05:38 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 15:05:38 +0000 From: Kent Watsen To: Robert Wilton , "netconf@ietf.org" Thread-Topic: [Netconf] RESTCONF timestamp and entity-tag for "default" resources Thread-Index: AQHTLWF6snZM6X05B0Oig+iLOfnCYaK0OAoA Date: Thu, 14 Sep 2017 15:05:38 +0000 Message-ID: References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> In-Reply-To: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB596; 6:gNOI92beEEs2fEzkA2M1W08ED62mlNm78fRlC925x7laMmYoIYUStdp7Z4jydDUNFQHYUVuc3Ne1k62rnyvlRkq7fnjnVQqJ9vfWmox44EUBDrKSWjhpY+bagg1eP3wOiBlhwLb4s6VSMB7tqvufF8GQ0V9ecVe7FuBpkg9TMUZjmVEaNnCtAyZca1ibWN02sWHXq6+MekTPhRsPBxQgtnLtb+RdqxC27qVXhRnZlZnOBFhZ3V94jfCUlN99WUixfA7pth71MV+PiE8lOJKvNCWFLY3Yzlj+Ve7QHLYa10WgmhxMSB92gEBlslh4/MSmi3dNJnV5QagqbOWg5AfsUQ==; 5:4d05BROtTRFFyKQmFsT5LBsJDpmWL579/g/BxEMWfunapGCtZHe/TJOcvku2U23wkvPqRY+c8Xz1WxuScaG30uqL+l1+JHMVG27GLEf94+RLVH1CqwyyK3ALfxJeYaHxI+3WGSoaTNsYttUvzl6zng==; 24:ozcpug5hg9zV3DTvKbYzLw3I8pTNq4WKefanZNIZTDF0x0v6pDZlmR41iLVLQ2EIk0lmlWV0nqeblRLUDTLg9DnDyy9C9QODyUJ44pdUnog=; 7:dkOm7VtLB69exAV4HyOgwKLeD2dSkSZ/32o00Zkk0W2mt2dZirBOiAZWXDoQhSB+vC1SjXSPJ91ySbq3ouwH3nwBs95Q+IMvLBMTKkBUVKbChArkLsGYNiEag4GcUhrx+T3A3V9tI9iruha6oHk8BmpGxNmvyBLFxCr2jWAseVAJ/YIjTU7V+vPNTxCfWP9tkPz94rjwtp47qPV3zsddGyOAreTcNJNfxdmzgIb7ex8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9a982df7-caa6-44d3-fee5-08d4fb820f68 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB596; x-ms-traffictypediagnostic: BLUPR05MB596: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB596; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB596; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(106356001)(8936002)(2501003)(86362001)(2900100001)(82746002)(8676002)(66066001)(68736007)(81166006)(81156014)(3660700001)(5660300001)(53936002)(33656002)(25786009)(105586002)(14454004)(101416001)(6246003)(305945005)(3280700002)(6486002)(7736002)(2950100002)(2906002)(76176999)(54356999)(77096006)(50986999)(4001350100001)(316002)(478600001)(97736004)(189998001)(83506001)(102836003)(83716003)(6116002)(3846002)(36756003)(6306002)(99286003)(6512007)(6506006)(6436002)(229853002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB596; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6AE08923E1C1CC4BBB1322118F5BBB35@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 15:05:38.7692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB596 Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 15:05:42 -0000 DQpUaGUgZGVmYXVsdCB2YWx1ZSBub2RlIHdhcyBpbXBsaWNpdGx5IGluc3RhbnRpYXRlZCB3aGVu IHRoZSBwYXJlbnQgbm9kZSB3YXMgY3JlYXRlZCwgc28gSSdkIHNldCBpdHMgTGFzdC1Nb2RpZmll ZCB2YWx1ZSB0byB0aGF0IHZhbHVlLg0KDQpLLiAgLy8gY29udHJpYnV0b3INCg0KDQotLQ0KDQpI aSwNCg0KSWYgSSBtYWtlIGEgUkVTVENPTkYgR0VUIHJlcXVlc3Qgd2l0aCBhIHBhdGggdG8gYSBk YXRhIHJlc291cmNlIHRoYXQgDQpkb2Vzbid0IGV4aXN0LCBidXQgaGFzIGFuIGluIHNjb3BlIHNj aGVtYSBkZWZhdWx0IHZhbHVlLCBhbmQgSSdtIHVzaW5nIA0Kb25lIG9mIHRoZSB3aXRoLWRlZmF1 bHRzIG9wdGlvbnMgdGhhdCBtZWFucyB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlIGlzIA0KcmV0dXJu ZWQsIHRoZW4gd2hhdCB2YWx1ZSBpcyB0aGUgIkxhc3QtTW9kaWZpZWQiIGhlYWRlciBleHBlY3Rl ZCBvciANCnJlcXVpcmVkIHRvIHRha2U/DQoNClNwZWNpZmljYWxseSwgSSBhbSB0aGlua2luZyBv ZiBhIGRldmljZSB0aGF0IHVzZXMgcGVyIGRhdGEgcmVzb3VyY2UgDQp0aW1lc3RhbXBzIGZvciBh bGwgZXhwbGljaXRseSBjb25maWd1cmVkIGRhdGEgcmVzb3VyY2VzIHJhdGhlciB0aGFuIA0KaGF2 aW5nIGEgc2luZ2xlIHRvcCBsZXZlbCBkYXRhc3RvcmUgcmVzb3VyY2UgdGltZXN0YW1wLg0KDQpU aGFua3MsDQpSb2INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQo= From nobody Fri Sep 15 01:40:42 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601B8133070 for ; Fri, 15 Sep 2017 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AKtZQKMWloy for ; Fri, 15 Sep 2017 01:40:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2C713306B for ; Fri, 15 Sep 2017 01:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2263; q=dns/txt; s=iport; t=1505464839; x=1506674439; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=daf93XA0IYp/Q9eaPsdq662qg9Rof9Yp29T19qsanp8=; b=aUu0n6BzmK6q9J7gThTnaDhsot3N44KzUYmo8FVfSWbV/NuIv0FsmC2H 1fnYDqx+H8C7JiXkEtp8VKn62r9HwBdhfYWiL/ji+rsDrbn0/CiPFcRUT s/BldvZjhHY+GLDr5BSm0TPiUwTXbb9H18dTFlU0geIAujH42sTcij44D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AQAZkbtZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3ixSQRgkimDoKGAuESk8ChGkVAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?BBAEBIQ8BBTYbCw4KAgImAgInMAYBDAYCAQEXihgQqz+CJ4sxAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGwWBDoIdg1KCDguCcogLgmAFmD2IRZRSi1WHIY1ch1WBOTUigQ0?= =?us-ascii?q?yIQgcFUqHHT82hlQrghQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="697204685" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 08:40:35 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8F8eZaM016464; Fri, 15 Sep 2017 08:40:35 GMT To: Kent Watsen , "netconf@ietf.org" References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> From: Robert Wilton Message-ID: Date: Fri, 15 Sep 2017 09:40:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 08:40:41 -0000 Hi Kent, Thanks for the suggestion. I think that your solution works if the implementation instantiates an an actual leaf to represent the default value, but I'm not sure that is meant to be required.  Without this "Last-Modified" requirement an implementation could implicitly instantiate default values from the schema when required (e.g. for validation) but not necessarily explicitly store them. But from my reading of RESTCONF section 3.5, the two choices seem to be either: (i) the device has to store the timestamp of when the default value took effect (e.g. the last time it was implicitly instantiated for whatever reason). (ii) the device could return the datastore timestamp for the implicitly created default node.  But I'm not sure how meaningful that is if the device also chooses to return accurate last modified timestamps for explicitly configured nodes.  If an implementation was to do this then you could easily have a scenario where an implicitly created child node has a later timestamp than its parent node, which doesn't seem to to be good. So, perhaps the conclusion is: if you want to return accurate timestamps for explicitly created nodes, then it is necessary to also maintain accurate timestamps for implicitly created default nodes as well? Thanks, Rob On 14/09/2017 16:05, Kent Watsen wrote: > The default value node was implicitly instantiated when the parent node was created, so I'd set its Last-Modified value to that value. > > K. // contributor > > > -- > > Hi, > > If I make a RESTCONF GET request with a path to a data resource that > doesn't exist, but has an in scope schema default value, and I'm using > one of the with-defaults options that means that the default value is > returned, then what value is the "Last-Modified" header expected or > required to take? > > Specifically, I am thinking of a device that uses per data resource > timestamps for all explicitly configured data resources rather than > having a single top level datastore resource timestamp. > > Thanks, > Rob > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From nobody Fri Sep 15 01:47:31 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742FB132F30 for ; Fri, 15 Sep 2017 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mfDFcOABIee for ; Fri, 15 Sep 2017 01:47:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AC6A3132F2F for ; Fri, 15 Sep 2017 01:47:27 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id C751B1AE00A0; Fri, 15 Sep 2017 10:47:26 +0200 (CEST) Date: Fri, 15 Sep 2017 10:48:11 +0200 (CEST) Message-Id: <20170915.104811.2023692176220307321.mbj@tail-f.com> To: rwilton@cisco.com Cc: kwatsen@juniper.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 08:47:29 -0000 Robert Wilton wrote: > Hi Kent, > = > Thanks for the suggestion. > = > I think that your solution works if the implementation instantiates a= n > an actual leaf to represent the default value, but I'm not sure that > is meant to be required.=A0 Without this "Last-Modified" requirement = an > implementation could implicitly instantiate default values from the > schema when required (e.g. for validation) but not necessarily > explicitly store them. > = > But from my reading of RESTCONF section 3.5, the two choices seem to > be either: > = > (i) the device has to store the timestamp of when the default value > took effect (e.g. the last time it was implicitly instantiated for > whatever reason). > = > (ii) the device could return the datastore timestamp for the > implicitly created default node.=A0 But I'm not sure how meaningful t= hat > is if the device also chooses to return accurate last modified > timestamps for explicitly configured nodes.=A0 If an implementation w= as > to do this then you could easily have a scenario where an implicitly > created child node has a later timestamp than its parent node, which > doesn't seem to to be good. > = > So, perhaps the conclusion is: if you want to return accurate > timestamps for explicitly created nodes, then it is necessary to also= > maintain accurate timestamps for implicitly created default nodes as > well? IMO this is all implementation details. One implementation might instantiate all defaults, while another comes up with some other clever mechanism to avoid redundant storage. The spec should clearly define the semantics associated with the timestamp, and not talk about how it must be implemented. /martin > = > Thanks, > Rob > = > = > On 14/09/2017 16:05, Kent Watsen wrote: > > The default value node was implicitly instantiated when the parent > > node was created, so I'd set its Last-Modified value to that value.= > > > > K. // contributor > > > > > > -- > > > > Hi, > > > > If I make a RESTCONF GET request with a path to a data resource tha= t > > doesn't exist, but has an in scope schema default value, and I'm us= ing > > one of the with-defaults options that means that the default value = is > > returned, then what value is the "Last-Modified" header expected or= > > required to take? > > > > Specifically, I am thinking of a device that uses per data resource= > > timestamps for all explicitly configured data resources rather than= > > having a single top level datastore resource timestamp. > > > > Thanks, > > Rob > > > > _______________________________________________ > > 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 Fri Sep 15 01:55:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC49133083 for ; Fri, 15 Sep 2017 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_i5GcKEtF1W for ; Fri, 15 Sep 2017 01:55:30 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C384133082 for ; Fri, 15 Sep 2017 01:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3151; q=dns/txt; s=iport; t=1505465730; x=1506675330; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=IeDarWPKu/0ku2/n+KYQsKFrynB0H4br+G3cS7Cm46c=; b=AzKCTL9TgwgoM7hb1uEp/3nHrZaHE/F5QfbfpvXjnibCTKC6ze0V+1x6 jmSE+7L72BKq+fydb+xPOVaeedfAkDWuTTKk5tM1FvGSppcuxUvUhEY4S X1Ypu22ew6hqaGKezKjcz8qqh60/kdAncRxuERa+oJcCnevZtEuqNVx+X g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AQCOlLtZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3ixSQRgkiliiCEgoYC4RKTwKEahYBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQEEAQEhDwEFNgsQCw4KAgImAgInMAYNBgIBAReKGBCrR4InizEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGgWBDoIdg1KCDguCcoRkgyeCYAWhApRSi1WHIY1ch1WBOSY?= =?us-ascii?q?OI4ENMiEIHBVKhx0/NoZTASQHghQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="657480191" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 08:55:25 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8F8tPRB029761; Fri, 15 Sep 2017 08:55:25 GMT To: Martin Bjorklund Cc: kwatsen@juniper.net, netconf@ietf.org References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> <20170915.104811.2023692176220307321.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Fri, 15 Sep 2017 09:55:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170915.104811.2023692176220307321.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 08:55:32 -0000 On 15/09/2017 09:48, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi Kent, >> >> Thanks for the suggestion. >> >> I think that your solution works if the implementation instantiates an >> an actual leaf to represent the default value, but I'm not sure that >> is meant to be required.  Without this "Last-Modified" requirement an >> implementation could implicitly instantiate default values from the >> schema when required (e.g. for validation) but not necessarily >> explicitly store them. >> >> But from my reading of RESTCONF section 3.5, the two choices seem to >> be either: >> >> (i) the device has to store the timestamp of when the default value >> took effect (e.g. the last time it was implicitly instantiated for >> whatever reason). >> >> (ii) the device could return the datastore timestamp for the >> implicitly created default node.  But I'm not sure how meaningful that >> is if the device also chooses to return accurate last modified >> timestamps for explicitly configured nodes.  If an implementation was >> to do this then you could easily have a scenario where an implicitly >> created child node has a later timestamp than its parent node, which >> doesn't seem to to be good. >> >> So, perhaps the conclusion is: if you want to return accurate >> timestamps for explicitly created nodes, then it is necessary to also >> maintain accurate timestamps for implicitly created default nodes as >> well? > IMO this is all implementation details. One implementation might > instantiate all defaults, while another comes up with some other > clever mechanism to avoid redundant storage. The spec should clearly > define the semantics associated with the timestamp, and not talk about > how it must be implemented. Sure. Do you agree that both (i) and (ii) are allowed by the spec? Do you also agree that doing (ii) could be confusing to clients? Thanks, Rob > > > /martin > > >> Thanks, >> Rob >> >> >> On 14/09/2017 16:05, Kent Watsen wrote: >>> The default value node was implicitly instantiated when the parent >>> node was created, so I'd set its Last-Modified value to that value. >>> >>> K. // contributor >>> >>> >>> -- >>> >>> Hi, >>> >>> If I make a RESTCONF GET request with a path to a data resource that >>> doesn't exist, but has an in scope schema default value, and I'm using >>> one of the with-defaults options that means that the default value is >>> returned, then what value is the "Last-Modified" header expected or >>> required to take? >>> >>> Specifically, I am thinking of a device that uses per data resource >>> timestamps for all explicitly configured data resources rather than >>> having a single top level datastore resource timestamp. >>> >>> Thanks, >>> Rob >>> >>> _______________________________________________ >>> 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 Fri Sep 15 02:01:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ED313307A for ; Fri, 15 Sep 2017 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ujMY9EYa1Td for ; Fri, 15 Sep 2017 02:01:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5A1321BB for ; Fri, 15 Sep 2017 02:01:01 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 213551AE00A0; Fri, 15 Sep 2017 11:01:01 +0200 (CEST) Date: Fri, 15 Sep 2017 11:01:46 +0200 (CEST) Message-Id: <20170915.110146.1429439848671351415.mbj@tail-f.com> To: rwilton@cisco.com Cc: kwatsen@juniper.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170915.104811.2023692176220307321.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 09:01:03 -0000 Robert Wilton wrote: > = > = > On 15/09/2017 09:48, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> Hi Kent, > >> > >> Thanks for the suggestion. > >> > >> I think that your solution works if the implementation instantiate= s an > >> an actual leaf to represent the default value, but I'm not sure th= at > >> is meant to be required.=A0 Without this "Last-Modified" requireme= nt an > >> implementation could implicitly instantiate default values from th= e > >> schema when required (e.g. for validation) but not necessarily > >> explicitly store them. > >> > >> But from my reading of RESTCONF section 3.5, the two choices seem = to > >> be either: > >> > >> (i) the device has to store the timestamp of when the default valu= e > >> took effect (e.g. the last time it was implicitly instantiated for= > >> whatever reason). > >> > >> (ii) the device could return the datastore timestamp for the > >> implicitly created default node.=A0 But I'm not sure how meaningfu= l that > >> is if the device also chooses to return accurate last modified > >> timestamps for explicitly configured nodes.=A0 If an implementatio= n was > >> to do this then you could easily have a scenario where an implicit= ly > >> created child node has a later timestamp than its parent node, whi= ch > >> doesn't seem to to be good. > >> > >> So, perhaps the conclusion is: if you want to return accurate > >> timestamps for explicitly created nodes, then it is necessary to a= lso > >> maintain accurate timestamps for implicitly created default nodes = as > >> well? > > IMO this is all implementation details. One implementation might > > instantiate all defaults, while another comes up with some other > > clever mechanism to avoid redundant storage. The spec should clear= ly > > define the semantics associated with the timestamp, and not talk ab= out > > how it must be implemented. > Sure. > = > Do you agree that both (i) and (ii) are allowed by the spec? I don't think (ii) is allowed, and it is not special for defaults. The extreme of (ii) would be to have a single timestamp for the datastore, but report it for every resource. OTOH, just b/c the timestamp differ for a node doesn't mean that the value is different. The value might have been changed and the changed back. So an implementation might get away with (ii), but as you note, this is confusing to clients. > Do you also agree that doing (ii) could be confusing to clients? Yes. /martin From nobody Fri Sep 15 02:48:31 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91841252BA for ; Fri, 15 Sep 2017 02:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jizWxi_QTbep for ; Fri, 15 Sep 2017 02:48:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4B1124B18 for ; Fri, 15 Sep 2017 02:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3341; q=dns/txt; s=iport; t=1505468907; x=1506678507; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ou9xMaJNdFyAZz5adyIihwJI2hOYuz+izMpQtrqpA+Y=; b=AEv+ybHUJfPMQyBJOPC/IZPveF058U+TK45i4e09wFKMUYLvpmbV7flg SDNvBuzx2M1IKExPnC+IEjVTD7Te3oBlJehl4YCR5GOiSE9v/bhSCpI3c dR6QO3w/PZkoXf1hMxas/a6rBpEwqL7KvybEr+NB1CSyqWT4StvexnxHv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgByobtZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy2BfyeDdYsUkEYrmDkKhTwChG0VAQIBAQEBAQEBayiFGQEFIw8BBUE?= =?us-ascii?q?QCw4KAgImAgJXBg0GAgEBF4oYqzyCJ4syAQEBAQEBAQEBAQEBAQEBAQEhgQ6CH?= =?us-ascii?q?YNSgWMrgn2EZIMngmAFmD6IRpRVi1eHIY1dh1WBOTUigQ0yIQgcFYdmPzaGUQE?= =?us-ascii?q?kB4IUAQEB?= X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="655660882" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 09:48:25 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8F9mOql010557; Fri, 15 Sep 2017 09:48:25 GMT To: Martin Bjorklund Cc: kwatsen@juniper.net, netconf@ietf.org References: <20170915.104811.2023692176220307321.mbj@tail-f.com> <20170915.110146.1429439848671351415.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Fri, 15 Sep 2017 10:48:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170915.110146.1429439848671351415.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 09:48:30 -0000 Hi Martin, Thanks for the clarification. OK.  I think the point that I was missing is that node is still a YANG data node even if it hasn't been explicitly created in the data tree and is taking a default value.  Hence the text for 3.5 applies to default nodes as well. I think that the text at the top of 3.5.1 could be slightly clearer in that if a device chooses to maintain a "last-modified" timestamp for some configuration resources then it really needs to do this for all configuration resources.  I.e. I think that the text in the 3rd paragraph of 3.5.1 stating that the datastore timestamp must be used instead only reliably works if the device isn't maintaining any per data resource timestamps. Rob On 15/09/2017 10:01, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 15/09/2017 09:48, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> Hi Kent, >>>> >>>> Thanks for the suggestion. >>>> >>>> I think that your solution works if the implementation instantiates an >>>> an actual leaf to represent the default value, but I'm not sure that >>>> is meant to be required.  Without this "Last-Modified" requirement an >>>> implementation could implicitly instantiate default values from the >>>> schema when required (e.g. for validation) but not necessarily >>>> explicitly store them. >>>> >>>> But from my reading of RESTCONF section 3.5, the two choices seem to >>>> be either: >>>> >>>> (i) the device has to store the timestamp of when the default value >>>> took effect (e.g. the last time it was implicitly instantiated for >>>> whatever reason). >>>> >>>> (ii) the device could return the datastore timestamp for the >>>> implicitly created default node.  But I'm not sure how meaningful that >>>> is if the device also chooses to return accurate last modified >>>> timestamps for explicitly configured nodes.  If an implementation was >>>> to do this then you could easily have a scenario where an implicitly >>>> created child node has a later timestamp than its parent node, which >>>> doesn't seem to to be good. >>>> >>>> So, perhaps the conclusion is: if you want to return accurate >>>> timestamps for explicitly created nodes, then it is necessary to also >>>> maintain accurate timestamps for implicitly created default nodes as >>>> well? >>> IMO this is all implementation details. One implementation might >>> instantiate all defaults, while another comes up with some other >>> clever mechanism to avoid redundant storage. The spec should clearly >>> define the semantics associated with the timestamp, and not talk about >>> how it must be implemented. >> Sure. >> >> Do you agree that both (i) and (ii) are allowed by the spec? > I don't think (ii) is allowed, and it is not special for defaults. > The extreme of (ii) would be to have a single timestamp for the > datastore, but report it for every resource. > > OTOH, just b/c the timestamp differ for a node doesn't mean that the > value is different. The value might have been changed and the changed > back. So an implementation might get away with (ii), but as you note, > this is confusing to clients. > >> Do you also agree that doing (ii) could be confusing to clients? > Yes. > > > /martin > . > From nobody Tue Sep 19 04:44:15 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC1134217; Tue, 19 Sep 2017 04:44:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150582144787.11806.3182940665667264587@ietfa.amsl.com> Date: Tue, 19 Sep 2017 04:44:07 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:44:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Custom Subscription to Event Notifications Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-04.txt Pages : 50 Date : 2017-09-19 Abstract: This document defines capabilities and operations for the customized establishment of subscriptions upon a publisher's event streams. Also defined are delivery mechanisms for instances of the resulting events. Effectively this allows a subscriber to request and receive a continuous, custom influx of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 19 14:46:32 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3248E132026; Tue, 19 Sep 2017 14:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150585758416.29344.297630642869020128@ietfa.amsl.com> Date: Tue, 19 Sep 2017 14:46:24 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:46:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Eric Voit Alberto Gonzalez Prieto Ambika Prasad Tripathy Einar Nilsen-Nygaard Andy Bierman Balazs Lengyel Filename : draft-ietf-netconf-yang-push-09.txt Pages : 52 Date : 2017-09-19 Abstract: Providing rapid visibility into changes made on YANG configuration and operational objects enables new capabilities such as remote mirroring of configuration and operational state. Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 22 08:21:44 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1661344AC for ; Fri, 22 Sep 2017 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZS0QDf0y_Fz for ; Fri, 22 Sep 2017 08:21:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 439011344AA for ; Fri, 22 Sep 2017 08:21:40 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 1AB321820F79; Fri, 22 Sep 2017 17:20:53 +0200 (CEST) Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id A417318201B0; Fri, 22 Sep 2017 17:20:50 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , rwilton@cisco.com Cc: netconf@ietf.org In-Reply-To: <20170915.104811.2023692176220307321.mbj@tail-f.com> References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> <20170915.104811.2023692176220307321.mbj@tail-f.com> Date: Fri, 22 Sep 2017 17:22:16 +0200 Message-ID: <87r2uyzrkn.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 15:21:43 -0000 Martin Bjorklund writes: > Robert Wilton wrote: >> Hi Kent, >>=20 >> Thanks for the suggestion. >>=20 >> I think that your solution works if the implementation instantiates an >> an actual leaf to represent the default value, but I'm not sure that >> is meant to be required.=C2=A0 Without this "Last-Modified" requirement = an >> implementation could implicitly instantiate default values from the >> schema when required (e.g. for validation) but not necessarily >> explicitly store them. >>=20 >> But from my reading of RESTCONF section 3.5, the two choices seem to >> be either: >>=20 >> (i) the device has to store the timestamp of when the default value >> took effect (e.g. the last time it was implicitly instantiated for >> whatever reason). >>=20 >> (ii) the device could return the datastore timestamp for the >> implicitly created default node.=C2=A0 But I'm not sure how meaningful t= hat >> is if the device also chooses to return accurate last modified >> timestamps for explicitly configured nodes.=C2=A0 If an implementation w= as >> to do this then you could easily have a scenario where an implicitly >> created child node has a later timestamp than its parent node, which >> doesn't seem to to be good. >>=20 >> So, perhaps the conclusion is: if you want to return accurate >> timestamps for explicitly created nodes, then it is necessary to also >> maintain accurate timestamps for implicitly created default nodes as >> well? > > IMO this is all implementation details. One implementation might > instantiate all defaults, while another comes up with some other > clever mechanism to avoid redundant storage. The spec should clearly > define the semantics associated with the timestamp, and not talk about > how it must be implemented. I think it would be better and simpler to adhere to the semantics that is defined for each header field in HTTP specs. For Last-Modified it is section 2.2 in RFC 7232: The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, ... So I think Kent's conclusion is correct: the representation was last modified when the resource was (conceptually) created, which was at the time of parent container creation. ETag is also quite interesting (sec. 2.3): An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. As I understand it, if an otherwise unmodified resource (e.g. a container instance) is represented once with defaults and another time without defaults, the two representations should have different ETags. Lada > > > /martin > > >>=20 >> Thanks, >> Rob >>=20 >>=20 >> On 14/09/2017 16:05, Kent Watsen wrote: >> > The default value node was implicitly instantiated when the parent >> > node was created, so I'd set its Last-Modified value to that value. >> > >> > K. // contributor >> > >> > >> > -- >> > >> > Hi, >> > >> > If I make a RESTCONF GET request with a path to a data resource that >> > doesn't exist, but has an in scope schema default value, and I'm using >> > one of the with-defaults options that means that the default value is >> > returned, then what value is the "Last-Modified" header expected or >> > required to take? >> > >> > Specifically, I am thinking of a device that uses per data resource >> > timestamps for all explicitly configured data resources rather than >> > having a single top level datastore resource timestamp. >> > >> > Thanks, >> > Rob >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Sat Sep 23 22:18:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EA9132193 for ; Sat, 23 Sep 2017 22:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVfLpy2YjZJi for ; Sat, 23 Sep 2017 22:18:30 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A2D1270AB for ; Sat, 23 Sep 2017 22:18:30 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id u12so2316931pfl.4 for ; Sat, 23 Sep 2017 22:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=bv+3LxryWENDic4IjDTxPh2YFWcAC3I/TJh3zMHkByQ=; b=d8/QKBrbAR0ilPpBjZDi2LMvdWUDqVtqBNqemS8fC/8TdMjm+O3KvTXhGVcHwp2piq DTVJ4ks3pNSRWfdwExPixIANF1Eicq5eGRuQGmLTYzysseK+PwLouySO+d0XxMrLbDD9 kyMYsAIov98pmlPU4lVo+4Y+Hvm6HIApWsM9HL17K6lWpi+y3vPg6Xw1AFNrp9rF6BJq 2rxj4/gBlEvYZzh3iDfq8GidzMSdmRWZBrNnce3uahAzzuiwcIaJJCiiHY1oaK489oo+ F3kM4DWt49ORjkWQ9xwrto50S3KTVUdpu07qG5N7SM2yB0+A2bOkXfjF0feDgrydr/zk nbpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=bv+3LxryWENDic4IjDTxPh2YFWcAC3I/TJh3zMHkByQ=; b=PhDrFVWvJ3gL7Qtp2NmMQY2HyU60lf0jIE2j1EFQafDXZU04j7WpCr8UmWs4rzXU2Y 2M6QEidStyBngXorJuNRAPbzGBCcFG5/OQegYeQYAOpoE5FU2Kq5ZS6CZPOX5g3I5Z7h kThGsG7kIGSN6dhrz8kjbDHp1m4F3GwSRuICVkFLsubuDCNuLDMH2aGcOiN3vdtCy8fj EK7pJDNclCaitVlY2ARESEwXcnOO0jD0qBC6ZmbhAriL5yDq73emNyweWWNhSWYEsxvV K+QoKNYS8nCsB5bcweQyX3IZWnN3WDCLAyBE9mT6duFcvUoUD0NDq8Gp1IbS/HXAQiQb haGQ== X-Gm-Message-State: AHPjjUhBgfYCrR1QDlpXW6lloSf6Ey4SCIDJxC9HL0Ni5knCxz3nVfPz FmCXLrcIwwIiuoJdyKeUeUrRttus X-Google-Smtp-Source: AOwi7QDeJ/yDxiRSM/7nHsu3freijdNu2ghFe4Hleen0AQuqZ8BgWtvyO/XVVmB/WYKIXB0w0V+RYg== X-Received: by 10.84.196.131 with SMTP id l3mr3747924pld.195.1506230309385; Sat, 23 Sep 2017 22:18:29 -0700 (PDT) Received: from sjc-mahesh-nitro13.cisco.com ([128.107.241.184]) by smtp.gmail.com with ESMTPSA id q13sm5419419pgt.87.2017.09.23.22.18.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Sep 2017 22:18:27 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B57230-9864-46FF-B844-721ED60E44C7" Message-Id: Date: Sat, 23 Sep 2017 22:18:28 -0700 To: netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 05:18:32 -0000 --Apple-Mail=_E6B57230-9864-46FF-B844-721ED60E44C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. = The authors agreed to provide an update, which they did with -01 version = of the draft. The authors believe the document is ready for WG adoption. This starts a two week call to adopt NETCONF NDMA draft as a WG = document. Since the focus of the draft is NDMA compliance, it falls = within the charter of the WG. https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 = Please indicate whether you think this draft should be adopted as a WG = item. If you have objections to it being adopted, please state your = reasons by responding on this thread. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E6B57230-9864-46FF-B844-721ED60E44C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The NETCONF NDMA draft was presented an discussed in IETF 99 = in Prague. The authors agreed to provide an update, which they did with = -01 version of the draft. The authors believe the document is ready for = WG adoption.

This = starts a two week call to adopt NETCONF NDMA draft as a WG document. = Since the focus of the draft is NDMA compliance, it falls within the = charter of the WG.

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01

Please = indicate whether you think this draft should be adopted as a WG item. If = you have objections to it being adopted, please state your reasons by = responding on this thread.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E6B57230-9864-46FF-B844-721ED60E44C7-- From nobody Sat Sep 23 22:20:14 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A513306F; Sat, 23 Sep 2017 22:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150623041311.6587.12052377720733509794.idtracker@ietfa.amsl.com> Date: Sat, 23 Sep 2017 22:20:13 -0700 Archived-At: Subject: [Netconf] The NETCONF WG has placed draft-dsdt-nmda-netconf in state "Call For Adoption By WG Issued" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 05:20:13 -0000 The NETCONF WG has placed draft-dsdt-nmda-netconf in state Call For Adoption By WG Issued (entered by Mahesh Jethanandani) The document is available at https://datatracker.ietf.org/doc/draft-dsdt-nmda-netconf/ From nobody Sun Sep 24 16:13:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328E12421A for ; Sun, 24 Sep 2017 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HgXhT8KBoLG for ; Sun, 24 Sep 2017 16:13:15 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7C513213D for ; Sun, 24 Sep 2017 16:13:15 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id r68so2898091pfj.3 for ; Sun, 24 Sep 2017 16:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nFZG7yTkE2c529X/gXN7mddXQ0kRlcR9FWhIz7fSBbg=; b=UN/L45NZ2pw6DEiCKfZBoexZhXKwrGareVfMn5+I7opxmJAQ9h1gVTigZzzNOlLeWL WOXAG+E+SapW/yTlAotjHfZsFnbxz6lUzZo5SHcr2DySeFvi80/PCsssZv0b7ee1a2vn dwsMX+/4A4b6O62UTHGYURyLMXR0KK9mxsagYzs0PbSA6BbExiQ1zleyhfnU+prxllbz s9W9mS1opWIYqClX3OHLooT8WCnLU3fw8C1Y+nwI0PfD6bm/N4bKP+AvvfwA1JP9pwim yuc1elXwqQxH8dds5qiN1aEaZX82CfGxr1w2tL4jw7X5qq4kY0naSmg0QfJ+w5mj9XpQ /jgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nFZG7yTkE2c529X/gXN7mddXQ0kRlcR9FWhIz7fSBbg=; b=irT9QRA7ABosu/Iat61S9sh79fd7KpBD+Q/DDlFEZtEZkYgiU53lpHrf5QzV/B3uwc qGDDs27qw8h3njjON6ehk352+JGJcMtgKmWs3JPpFScS85FYw5ftDjyBYhuuh5HEurMa QzhPcKDB4TUVDM6f4gcHW8xvfjpdY33eaGf4kqZBlfIi5u/S6hanM3PL3nKrWJbDgNkV Fp0kY5gToSYsv+Vu+43FpKXomDIRmVwupM6dBmLQV81Tk6f+/o6SY9F3WJvFb2ZLJSFf GeUMT18Gr1DNvbx4UCxxIuUU1d5FhEKKzIdLqjY0NNQxWMCwDsscQJJnpfmwJI1Xse+4 njFA== X-Gm-Message-State: AHPjjUj4sQ+skMwxANv/yjiTdxXzUOB4/PwpKoRpQjjMlYvXFjo78MH/ tWrvd9w+DrTjvAt9ytSANAUfbwCh X-Google-Smtp-Source: AOwi7QCll7zoAqi9GJGT78KYfgdeHerKkWLqV6XQ1EB+IxEkVv3mJQEZev6ZxKyfj/4C/eihtkvGlQ== X-Received: by 10.99.167.6 with SMTP id d6mr5807807pgf.414.1506294794524; Sun, 24 Sep 2017 16:13:14 -0700 (PDT) Received: from ?IPv6:2607:fb90:28b0:e95d:8059:877b:626c:c567? ([2607:fb90:28b0:e95d:8059:877b:626c:c567]) by smtp.gmail.com with ESMTPSA id 126sm7846140pfd.181.2017.09.24.16.13.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Sep 2017 16:13:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EB1E3D55-BC24-49E7-A4B8-57617786183D Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Sun, 24 Sep 2017 16:13:12 -0700 Cc: netconf Content-Transfer-Encoding: 7bit Message-Id: <733F5225-177F-4496-BB77-69C3F0A0BDC6@gmail.com> References: To: Mahesh Jethanandani Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 23:13:18 -0000 --Apple-Mail-EB1E3D55-BC24-49E7-A4B8-57617786183D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Strongly support! Regards, Jeff > On Sep 23, 2017, at 22:18, Mahesh Jethanandani w= rote: >=20 > The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. Th= e authors agreed to provide an update, which they did with -01 version of th= e draft. The authors believe the document is ready for WG adoption. >=20 > This starts a two week call to adopt NETCONF NDMA draft as a WG document. S= ince the focus of the draft is NDMA compliance, it falls within the charter o= f the WG. >=20 > https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 >=20 > Please indicate whether you think this draft should be adopted as a WG ite= m. If you have objections to it being adopted, please state your reasons by r= esponding on this thread. >=20 > Thanks. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-EB1E3D55-BC24-49E7-A4B8-57617786183D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Strongly support!

Regards,
Jeff

On Sep 23, 2017, at 22:18= , Mahesh Jethanandani <mjethan= andani@gmail.com> wrote:

= T= he NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The a= uthors agreed to provide an update, which they did with -01 version of the d= raft. The authors believe the document is ready for WG adoption.

This starts a two week call to adopt= NETCONF NDMA draft as a WG document. Since the focus of the draft is NDMA c= ompliance, it falls within the charter of the WG.

https://tools.ietf.org/html/draft-dsdt-nmda-netco= nf-01

Please indicate whether you think this draft should be adopted as a WG item= . If you have objections to it being adopted, please state your reasons by r= esponding on this thread.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



_______________________________________________
= Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
= --Apple-Mail-EB1E3D55-BC24-49E7-A4B8-57617786183D-- From nobody Sun Sep 24 19:05:43 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30302126B7E for ; Sun, 24 Sep 2017 19:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5SCQ2BQb1Mj for ; Sun, 24 Sep 2017 19:05:39 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 A4219126B71 for ; Sun, 24 Sep 2017 19:05:39 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 9D96675A729FC3F994FA; Mon, 25 Sep 2017 10:05:36 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse01.zte.com.cn with SMTP id v8P2573i038813; Mon, 25 Sep 2017 10:05:07 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Mon, 25 Sep 2017 10:05:07 +0800 (CST) Date: Mon, 25 Sep 2017 10:05:07 +0800 (CST) X-Zmail-TransId: 2afc59c86453372-9c8ee X-Mailer: Zmail v1.0 Message-ID: <201709251005077124475@zte.com.cn> References: AA781EFC-A7B5-490B-BF85-DE4FA3FDE26F@gmail.com Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn v8P2573i038813 Archived-At: Subject: Re: [Netconf] =?utf-8?q?WG_adoption_of_NETCONF_NDMA_draft?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 02:05:42 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WWVzLCBJIHN1cHBvcnQgdGhlIFdHIGFkb3B0aW9uLg0KDQpUaGlzIGRyYWZ0IGZhbGxzIHdpdGhp biB0aGUgY2hhcnRlciBhbmQgaXQncyBuZWNlc3NhcnkgZm9yIE5ldGNvbmYgdG8gYmUgTk1EQSBj b21wbGlhbnQuDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KWGlhbyBNaW4NCg0KDQoNCg0KDQrl jp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8miA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+ DQrmlLbku7bkurrvvJogPG5ldGNvbmZAaWV0Zi5vcmc+DQrml6Ug5pyfIO+8mjIwMTflubQwOeac iDI05pelIDEzOjE0DQrkuLsg6aKYIO+8mltOZXRjb25mXSBXRyBhZG9wdGlvbiBvZiBORVRDT05G IE5ETUEgZHJhZnQNCg0KDQoNCg0KDQpUaGUgTkVUQ09ORiBORE1BIGRyYWZ0IHdhcyBwcmVzZW50 ZWQgYW4gZGlzY3Vzc2VkIGluIElFVEYgOTkgaW4gUHJhZ3VlLiBUaGUgYXV0aG9ycyBhZ3JlZWQg dG8gcHJvdmlkZSBhbiB1cGRhdGUsIHdoaWNoIHRoZXkgZGlkIHdpdGggLTAxIHZlcnNpb24gb2Yg dGhlIGRyYWZ0LiBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3Ig V0cgYWRvcHRpb24uDQoNCg0KVGhpcyBzdGFydHMgYSB0d28gd2VlayBjYWxsIHRvIGFkb3B0IE5F VENPTkYgTkRNQSBkcmFmdCBhcyBhIFdHIGRvY3VtZW50LiBTaW5jZSB0aGUgZm9jdXMgb2YgdGhl IGRyYWZ0IGlzIE5ETUEgY29tcGxpYW5jZSwgaXQgZmFsbHMgd2l0aGluIHRoZSBjaGFydGVyIG9m IHRoZSBXRy4NCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRh LW5ldGNvbmYtMDENCg0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgdGhpbmsgdGhpcyBk cmFmdCBzaG91bGQgYmUgYWRvcHRlZCBhcyBhIFdHIGl0ZW0uIElmIHlvdSBoYXZlIG9iamVjdGlv bnMgdG8gaXQgYmVpbmcgYWRvcHRlZCwgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBieSByZXNw b25kaW5nIG9uIHRoaXMgdGhyZWFkLg0KDQoNClRoYW5rcy4NCg0KDQoNCk1haGVzaCBKZXRoYW5h bmRhbmkNCg0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb20= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWls eTphcmlhbDsiPiA8cD5ZZXMsIEkgc3VwcG9ydCB0aGUgV0cgYWRvcHRpb24uPC9wPjxwPlRoaXMg ZHJhZnQgZmFsbHMgd2l0aGluIHRoZSBjaGFydGVyIGFuZCBpdCdzIG5lY2Vzc2FyeSBmb3IgTmV0 Y29uZiB0byBiZSBOTURBIGNvbXBsaWFudC48L3A+PHA+PGJyPjwvcD48cD5CZXN0IFJlZ2FyZHMs PC9wPjxwPlhpYW8gTWluPC9wPjxkaXYgY2xhc3M9InpNYWlsRnJvbSI+PC9kaXY+PGRpdj48ZGl2 IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9Inpo aXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6 IDI4cHg7IGJhY2tncm91bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFs aWduOiBjZW50ZXI7IiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8 L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9s LWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0i cGFkZGluZzogOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFu IGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj4gJmx0O21qZXRoYW5hbmRhbmlAZ21haWwuY29tJmd0Ozs8 L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlUT1R4dCI+5pS2 5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7Ij4gJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2 PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJv bmc+PHNwYW4gY2xhc3M9IiI+MjAxN+W5tDA55pyIMjTml6UgMTM6MTQ8L3NwYW4+PC9kaXY+PGRp dj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwv c3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25nPltOZXRjb25mXSBXRyBhZG9w dGlvbiBvZiBORVRDT05GIE5ETUEgZHJhZnQ8L3N0cm9uZz48L3NwYW4+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGJyPjwvcD48ZGl2PjxtZXRhIGh0dHAtZXF1aXY9IkNv bnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sIGNoYXJzZXQ9dXMtYXNjaWkiPlRoZSBORVRD T05GIE5ETUEgZHJhZnQgd2FzIHByZXNlbnRlZCBhbiBkaXNjdXNzZWQgaW4gSUVURiA5OSBpbiBQ cmFndWUuIFRoZSBhdXRob3JzIGFncmVlZCB0byBwcm92aWRlIGFuIHVwZGF0ZSwgd2hpY2ggdGhl eSBkaWQgd2l0aCAtMDEgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIFRoZSBhdXRob3JzIGJlbGlldmUg dGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBXRyBhZG9wdGlvbi48ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPlRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgY2FsbCB0 byBhZG9wdCBORVRDT05GIE5ETUEgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4gU2luY2UgdGhlIGZv Y3VzIG9mIHRoZSBkcmFmdCBpcyBORE1BIGNvbXBsaWFuY2UsIGl0IGZhbGxzIHdpdGhpbiB0aGUg Y2hhcnRlciBvZiB0aGUgV0cuPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBj bGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1u bWRhLW5ldGNvbmYtMDEiIGNsYXNzPSIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLW5ldGNvbmYtMDE8L2E+PGJyIGNsYXNzPSIiPjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+UGxlYXNlIGluZGlj YXRlIHdoZXRoZXIgeW91IHRoaW5rIHRoaXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBX RyBpdGVtLiBJZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGl0IGJlaW5nIGFkb3B0ZWQsIHBsZWFz ZSBzdGF0ZSB5b3VyIHJlYXNvbnMgYnkgcmVzcG9uZGluZyBvbiB0aGlzIHRocmVhZC48YnIgY2xh c3M9IiI+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5UaGFu a3MuPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj48ZGl2IGNs YXNzPSIiPk1haGVzaCBKZXRoYW5hbmRhbmk8L2Rpdj48ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Im1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiIgdGFyZ2V0PSJfYmxhbmsiPm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi PjwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ICZuYnNwOzwvZGl2 PjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48L3A+IDwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Sun Sep 24 20:27:29 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051C512ECEC for ; Sun, 24 Sep 2017 20:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz0uHlBXanQr for ; Sun, 24 Sep 2017 20:27:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B8F120724 for ; Sun, 24 Sep 2017 20:27:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWD43351; Mon, 25 Sep 2017 03:27:22 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 25 Sep 2017 04:27:21 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 25 Sep 2017 11:27:19 +0800 From: Tianran Zhou To: Mahesh Jethanandani , netconf Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNPSfJz2iWPeZLEemqREZP0bsTqLE8mrA Date: Mon, 25 Sep 2017 03:27:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A244DE89NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59C8779C.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c930c112c1fa38a323930b2219d1a345 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 03:27:28 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21A244DE89NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this work. Regards, Tianran From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana= ndani Sent: Sunday, September 24, 2017 1:18 PM To: netconf Subject: [Netconf] WG adoption of NETCONF NDMA draft The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The= authors agreed to provide an update, which they did with -01 version of th= e draft. The authors believe the document is ready for WG adoption. This starts a two week call to adopt NETCONF NDMA draft as a WG document. S= ince the focus of the draft is NDMA compliance, it falls within the charter= of the WG. https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 Please indicate whether you think this draft should be adopted as a WG item= . If you have objections to it being adopted, please state your reasons by = responding on this thread. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --_000_BBA82579FD347748BEADC4C445EA0F21A244DE89NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption of this w= ork.

 

Regards,

Tianran

 

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Sunday, September 24, 2017 1:18 PM
To: netconf
Subject: [Netconf] WG adoption of NETCONF NDMA draft

 

The NETCONF NDMA draft was pres= ented an discussed in IETF 99 in Prague. The authors agreed to provide an u= pdate, which they did with -01 version of the draft. The authors believe th= e document is ready for WG adoption.

 

This starts a two week call to = adopt NETCONF NDMA draft as a WG document. Since the focus of the draft is = NDMA compliance, it falls within the charter of the WG.

 

https://tools.ietf.org/html/draft-dsdt-= nmda-netconf-01

 

Please indicate whether you thi= nk this draft should be adopted as a WG item. If you have objections to it = being adopted, please state your reasons by responding on this thread.=

 

Thanks.

 

Mahesh Jethanandani<= /span>

 

 

 

--_000_BBA82579FD347748BEADC4C445EA0F21A244DE89NKGEML515MBXchi_-- From nobody Mon Sep 25 01:38:28 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB599133047 for ; Mon, 25 Sep 2017 01:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDPVLq5PwHkC for ; Mon, 25 Sep 2017 01:38:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA54813303F for ; Mon, 25 Sep 2017 01:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4088; q=dns/txt; s=iport; t=1506328704; x=1507538304; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1Zm7Rpfk2DeTaanYgXubWyB953hlSnT9NMtew5Nf+GM=; b=PVF80VElvXod2KcpdhK+SfTCX4dzXiLP3AQbeMdDevvx0BQyHaEA0vED n7xHSE5VNVcaKxE1LfuQreibMqzpRgWYLE3LPW3kJrrBxYR0xxC2ZnRV1 P1kVZ72pu2U4OnaQIn43zSiODO4ozJbkzc5gdqonqF8ztfhslTJn7Pwfg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQDkv8hZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ48KkFAriEGIK4U+ghIKGAEKhElPAoRuFgECAQEBAQEBAWs?= =?us-ascii?q?ohRkBAQEDAQFsGwsECgonByEGHxEGAQwGAgEBihcDFRCpTieHBg2DWAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyuDU4FnK4J9gl6IGAWYTYgWPIddiAaEeYIThW+?= =?us-ascii?q?DWocqigqCXIEHh1mBOSYJKIEOMiEIHRVJhRocgWg/NogzAQEB?= X-IronPort-AV: E=Sophos;i="5.42,435,1500940800"; d="scan'208,217";a="697531946" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 08:38:22 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8P8cMre018470; Mon, 25 Sep 2017 08:38:22 GMT To: Mahesh Jethanandani , netconf References: From: Robert Wilton Message-ID: <72d2e5af-da1e-6e3c-d033-7899a47377dd@cisco.com> Date: Mon, 25 Sep 2017 09:38:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8D5B312CFA7D17F526789592" Content-Language: en-US Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 08:38:27 -0000 This is a multi-part message in MIME format. --------------8D5B312CFA7D17F526789592 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Support (as an author). Thanks, Rob On 24/09/2017 06:18, Mahesh Jethanandani wrote: > The NETCONF NDMA draft was presented an discussed in IETF 99 in > Prague. The authors agreed to provide an update, which they did with > -01 version of the draft. The authors believe the document is ready > for WG adoption. > > This starts a two week call to adopt NETCONF NDMA draft as a WG > document. Since the focus of the draft is NDMA compliance, it falls > within the charter of the WG. > > https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 > > Please indicate whether you think this draft should be adopted as a WG > item. If you have objections to it being adopted, please state your > reasons by responding on this thread. > > Thanks. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------8D5B312CFA7D17F526789592 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Support (as an author).

Thanks,
Rob


On 24/09/2017 06:18, Mahesh Jethanandani wrote:
The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The authors agreed to provide an update, which they did with -01 version of the draft. The authors believe the document is ready for WG adoption.

This starts a two week call to adopt NETCONF NDMA draft as a WG document. Since the focus of the draft is NDMA compliance, it falls within the charter of the WG.

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01

Please indicate whether you think this draft should be adopted as a WG item. If you have objections to it being adopted, please state your reasons by responding on this thread.

Thanks.

Mahesh Jethanandani





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

--------------8D5B312CFA7D17F526789592-- From nobody Mon Sep 25 05:57:39 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8BE134224 for ; Mon, 25 Sep 2017 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK6ccYbQq3YZ for ; Mon, 25 Sep 2017 05:57:37 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE721342FA for ; Mon, 25 Sep 2017 05:57:36 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id o42so7575131wrb.3 for ; Mon, 25 Sep 2017 05:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=0pxJUgb97AvfmAayAaEiRvR+VoX08R+nuU8MYGHVxpY=; b=EFELYo0Yuk/FUaHxqhf9NJuUGFuZV7vX47pQ8XRkTuD8Y4++UCFr8U2M6/9HKCQU0V /RgEAt3CR14n53ynpZ3Vl+8aw1SB7EWoHh4+7Z5ovwFrKYzZDwzlpG5h/R61DZsdHWPK BWVMtyHrqNyl65BeZ3JIBDs7Q7JVpwNUai0xHss0qDu35ZFREEpL7OLRCdU6Ck1ZjM/W ohb33vnNeKsD4/SoTgjGTK8FqcO1ampNr9Kwy+95ah/ah15i0onyeK59/sfBrEsSRxvr 1cDDWo2U49sZXyi5avwDxDZX1Rx1gM4kAyqjmptqgSKpMM3SoLiR7U26eHNiSF20iLkV 6LKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=0pxJUgb97AvfmAayAaEiRvR+VoX08R+nuU8MYGHVxpY=; b=RXMEt61r9QPoDakKcIPkNF+nH/XxHTP9xm1KIQdlWlRAE+JKxyy+PgOJBOfa4vn0HQ cFpojDSEyp1PGE+broieAn4Wb7pSQFEOSbRvittcbsaXKHe/+N7Vgsc8XiQY++GWGgGP ldsdUWffy4DdnehFc4F3lC99JBsdo6OM2ZCmfDEixWhVDSaGW/7j2Ndg+kGXQn8vOKQG j2fsG99W5bUydkqucwthAoZLneJ0/9xcalugv67Sht0R4mJFk5MkSLSlhVWCgmWadGcT q7wcgl2EMLBZzPIhyVv1i2ZvcaOKZuHh847HQwce9U+P45GD638s2xPhN6Z4Szf860Bt N6Ew== X-Gm-Message-State: AHPjjUj5+qE/G13ageqZ/nB/sHMEYTp3cH7T9GeEbKcSbBp7fu3wS6dz Xf4TxJIHztS012MhURmGGQs= X-Google-Smtp-Source: AOwi7QDzzN5Q2c1hEdyTdi2sDQvjFbtp9KZN6kX4rowvXftu+HYvXCxczhGa7gJq1w+T9+ZP6U6G5Q== X-Received: by 10.223.164.206 with SMTP id h14mr5812910wrb.221.1506344254767; Mon, 25 Sep 2017 05:57:34 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p57A7792D.dip0.t-ipconnect.de. [87.167.121.45]) by smtp.gmail.com with ESMTPSA id v78sm3291634wmv.48.2017.09.25.05.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 05:57:33 -0700 (PDT) From: "Mehmet Ersue" To: "'Mahesh Jethanandani'" , "'netconf'" References: In-Reply-To: Date: Mon, 25 Sep 2017 14:57:34 +0200 Message-ID: <012f01d335fd$dbf411c0$93dc3540$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0130_01D3360E.9F7DA510" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKnIWaf+XxG3mxnCCxok0yu8h8s96EduMpQ Content-Language: de Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:57:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0130_01D3360E.9F7DA510 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Support. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Sunday, September 24, 2017 7:18 AM To: netconf Subject: [Netconf] WG adoption of NETCONF NDMA draft The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The authors agreed to provide an update, which they did with -01 version of the draft. The authors believe the document is ready for WG adoption. This starts a two week call to adopt NETCONF NDMA draft as a WG document. Since the focus of the draft is NDMA compliance, it falls within the charter of the WG. https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 Please indicate whether you think this draft should be adopted as a WG item. If you have objections to it being adopted, please state your reasons by responding on this thread. Thanks. Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_0130_01D3360E.9F7DA510 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Support.

 

Mehmet

 

From: = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Sunday, September 24, 2017 7:18 = AM
To: netconf <netconf@ietf.org>
Subject: = [Netconf] WG adoption of NETCONF NDMA draft

 

The NETCONF = NDMA draft was presented an discussed in IETF 99 in Prague. The authors = agreed to provide an update, which they did with -01 version of the = draft. The authors believe the document is ready for WG = adoption.

 

This starts a two week call to adopt NETCONF NDMA = draft as a WG document. Since the focus of the draft is NDMA compliance, = it falls within the charter of the WG.

 

https://t= ools.ietf.org/html/draft-dsdt-nmda-netconf-01

 

Please indicate whether you think this draft should be = adopted as a WG item. If you have objections to it being adopted, please = state your reasons by responding on this thread.

 

Thanks.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0130_01D3360E.9F7DA510-- From nobody Mon Sep 25 06:59:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C078913431D for ; Mon, 25 Sep 2017 06:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb1mN6JuQ4Zs for ; Mon, 25 Sep 2017 06:59:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFBD134318 for ; Mon, 25 Sep 2017 06:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10034; q=dns/txt; s=iport; t=1506347942; x=1507557542; h=from:to:subject:date:message-id:mime-version; bh=sQlVJsmdfIXy41FiXXhw+ctfEQpx3vHLCQKrDbPjrCw=; b=EszGihLcGRkynIOCXkytHwpl3sTDv3Oa6S+SCS5jkIrnKza9PlHmj2GQ knVAp+Up5kqJlcM/W0eMDltlaI0bVnewJtPEcRym3qrO+r7UQ3VpgBKzg VQ/0fcCL6PE3xmJDCRemJzJFnst00bzGR8bYngGtnDXxc3oJ+v4OtbOFf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AACjCslZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG4ujg+PeoUmjTyFPoISColyPxgBAgEBAQEBAQFrKIUZBi1?= =?us-ascii?q?eAQglUyYBBBsTiTRkqW2LFwEBAQEGAQEBAQEBIoMrggKBUYUPinYFoR8ClFGCH?= =?us-ascii?q?JBzigqLDwIRGQGBOAEfOIEOeBWHZod+gRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,436,1500940800"; d="scan'208,217";a="297822325" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 13:59:00 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8PDx0Rg031017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Sep 2017 13:59:00 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 09:59:00 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 09:58:59 -0400 From: "Eric Voit (evoit)" To: "'netconf'" Thread-Topic: Re: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AdM2AeB+uGoalW8kTtGQ8uaBx60/Eg== Date: Mon, 25 Sep 2017 13:58:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_a1cfd5eb7e36498387fb902470e1076eXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:59:04 -0000 --_000_a1cfd5eb7e36498387fb902470e1076eXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support, with one caveat: that the modeling of the filter elements of dsdt-nmda-netconf and the filte= ring elements of yang-push converge into a common set of objects across bot= h solutions. The reason for this caveat is as follows: Until April 2017, yang-push had the same explicit filter subtyping as is no= w proposed within dsdt-nmda-netconf-01 subscription* +-- update-filter +--:(subtree) | +-- subtree-filter anydata +--:(xpath) +-- xpath-filter? yang:xpath1.0 However this structure has a downside. Any new filter type to be added re= quires a revision to any data nodes, rpcs, and notifications. An argument can be made that the explicit subtyping results in better prote= ctions. However datatyping of filter contents is trivial compared to the e= valuation of the actual contents to see if these are meaningful. And in an= y case the typedef on xpath1.0 in RFC6021 is "string", so meaningful protec= tions require logic anyway. Based on that, the current structure of the yang-push filter is now: subscription* +--: (selected-content) +-- selection-filter-type selection-filter-type +-- selection-filter anydata This structure allows the addition of filter types through the use of addi= tional identities, and doesn't require corresponding changes to yang models= , rpcs, or notifications. Eric --_000_a1cfd5eb7e36498387fb902470e1076eXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support, with one caveat:

that the modeling of the filter elements of dsdt-nmd= a-netconf and the filtering elements of yang-push converge into a common se= t of objects across both solutions.

 

The reason for this caveat is as follows:=

 

Until April 2017, yang-push had the same explicit fi= lter subtyping as is now proposed within dsdt-nmda-netconf-01

=  

= subscription*

=    +-- update-filter

=       +--:(subtree)

=       |  +-- subtree-filter  &n= bsp;   anyd= ata

=       +--:(xpath)

=          +-- xpath-filter? = ;      yang:xpath1.0

 

 

However this structure has a downside.   A= ny new filter type to be added requires a revision to any data nodes, rpcs,= and notifications.  

 

An argument can be made that the explicit subtyping = results in better protections.  However datatyping of filter contents = is trivial compared to the evaluation of the actual contents to see if thes= e are meaningful.  And in any case the typedef on xpath1.0 in RFC6021 is “string”, so meaningful prot= ections require logic anyway.

 

Based on that, the current structure of the yang-pus= h filter is now:

=  

= subscription*

=    +--: (selected-content)

=       +-- selection-filter-type  sele= ction-filter-type

=       +-- selection-filter   &n= bsp;   anyd= ata

 

This structure allows the addition of filter types t= hrough the use of  additional identities, and doesn’t require co= rresponding changes to yang models, rpcs, or notifications.

 

Eric  

--_000_a1cfd5eb7e36498387fb902470e1076eXCHRTP013ciscocom_-- From nobody Mon Sep 25 07:05:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA037133032 for ; Mon, 25 Sep 2017 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM1DS6p--phm for ; Mon, 25 Sep 2017 07:05:42 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757F0120724 for ; Mon, 25 Sep 2017 07:05:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4F4F1F14; Mon, 25 Sep 2017 16:05:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id H8fdGFwExPK1; Mon, 25 Sep 2017 16:05:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Sep 2017 16:05:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AB43200F4; Mon, 25 Sep 2017 16:05:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id euu-ROXeBEvG; Mon, 25 Sep 2017 16:05:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1F34200F1; Mon, 25 Sep 2017 16:05:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C016411495B; Mon, 25 Sep 2017 16:05:40 +0200 (CEST) Date: Mon, 25 Sep 2017 16:05:40 +0200 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: 'netconf' Message-ID: <20170925140540.djxmhbgtjhghjh6l@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , 'netconf' References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:05:45 -0000 On Mon, Sep 25, 2017 at 01:58:59PM +0000, Eric Voit (evoit) wrote: > Support, with one caveat: > that the modeling of the filter elements of dsdt-nmda-netconf and the filtering elements of yang-push converge into a common set of objects across both solutions. > > The reason for this caveat is as follows: > > Until April 2017, yang-push had the same explicit filter subtyping as is now proposed within dsdt-nmda-netconf-01 > > subscription* > +-- update-filter > +--:(subtree) > | +-- subtree-filter anydata > +--:(xpath) > +-- xpath-filter? yang:xpath1.0 > > > However this structure has a downside. Any new filter type to be added requires a revision to any data nodes, rpcs, and notifications. Why would that be? Or what does 'any data modes, rpcs, and notifications' mean here? > An argument can be made that the explicit subtyping results in better protections. However datatyping of filter contents is trivial compared to the evaluation of the actual contents to see if these are meaningful. And in any case the typedef on xpath1.0 in RFC6021 is "string", so meaningful protections require logic anyway. > > Based on that, the current structure of the yang-push filter is now: > > subscription* > +--: (selected-content) > +-- selection-filter-type selection-filter-type > +-- selection-filter anydata > > This structure allows the addition of filter types through the use of additional identities, and doesn't require corresponding changes to yang models, rpcs, or notifications. > An augment to a choice is a good thing. It requires to spell out how a filter mechanism works and what the parameters of the filter mechanism are. I also automatically get a way to announce what filtering mechanisms an implementation supports. Something entirely opaque is well entirely opaque. /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 Sep 25 07:19:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB7134325 for ; Mon, 25 Sep 2017 07:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCnduCtU_-ho for ; Mon, 25 Sep 2017 07:19:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CF133032 for ; Mon, 25 Sep 2017 07:19:17 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 19F4F1AE02A7; Mon, 25 Sep 2017 16:19:16 +0200 (CEST) Date: Mon, 25 Sep 2017 16:17:45 +0200 (CEST) Message-Id: <20170925.161745.619992510057596315.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:19:19 -0000 "Eric Voit (evoit)" wrote: > Support, with one caveat: > that the modeling of the filter elements of dsdt-nmda-netconf and the > filtering elements of yang-push converge into a common set of objects > across both solutions. Yes this might be a good idea, if the filters are used for the same purpose, i.e., select a set of nodes. > The reason for this caveat is as follows: > > Until April 2017, yang-push had the same explicit filter subtyping as > is now proposed within dsdt-nmda-netconf-01 > > subscription* > +-- update-filter > +--:(subtree) > | +-- subtree-filter anydata > +--:(xpath) > +-- xpath-filter? yang:xpath1.0 > > > However this structure has a downside. Any new filter type to be > added requires a revision to any data nodes, rpcs, and notifications. I don't understand the last sentence. Can you elaborate? > An argument can be made that the explicit subtyping results in better > protections. However datatyping of filter contents is trivial > compared to the evaluation of the actual contents to see if these are > meaningful. And in any case the typedef on xpath1.0 in RFC6021 is > "string", so meaningful protections require logic anyway. > > Based on that, the current structure of the yang-push filter is now: > > subscription* > +--: (selected-content) > +-- selection-filter-type selection-filter-type > +-- selection-filter anydata But what would an XPath filter look like with this solution? Note that this doesn't validate: /interfaces Also, suppose we add a new cool filter type in the future, which requires 4 leafs to be set. Modelling these as "anydata" is not as exact as: container new-cool-filter { leaf foo { ... } leaf bar { ... } ... } > This structure allows the addition of filter types through the use of > additional identities, and doesn't require corresponding changes to > yang models, rpcs, or notifications. Well, IMO you have to model the filter parameters, otherwise we end up with just an "anydata" node whose contents are described in plain text. /martin From nobody Mon Sep 25 08:08:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6A21344A3 for ; Mon, 25 Sep 2017 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G26THQa4pj1s for ; Mon, 25 Sep 2017 08:08:34 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6282E13448E for ; Mon, 25 Sep 2017 08:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4844; q=dns/txt; s=iport; t=1506352107; x=1507561707; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=M/yVKSqcr6Ac8+pD/B1Xwyrj8fttMW4L1nyc0Q6oBuU=; b=Wa5xZpYp8J5PloqV52vy64F5i6ky1wt0l07x/i2AkObnXSI1bVpD+wTe gGHT/32dJSIYZkx8WMwecf6Q1GyGhizN/ufmgsdao1gVFde8MFscbdRLi Ra0qz59YQwfdFvlwx585QFY1tkpzsqK/veRrBi4iMC6U813KEdP6asFIL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQCjGslZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N2ixSQUiuWKg6CBAoYC4RJTwKEdxYBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhDwEFNgsQCxgCAiYCAicwBgEMBgIBAReKEAgQp02CJ4sXAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBDoIdg1OCEoJ9hGsCAoMngmAFoR+UXItchyq?= =?us-ascii?q?NbYdZgTkmByqBDjIhCB0VSYcePzaFVwEkB4IVAQEB?= X-IronPort-AV: E=Sophos;i="5.42,436,1500940800"; d="scan'208";a="655996426" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 15:08:25 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8PF8P4n029153; Mon, 25 Sep 2017 15:08:25 GMT To: Ladislav Lhotka , Martin Bjorklund Cc: netconf@ietf.org References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> <20170915.104811.2023692176220307321.mbj@tail-f.com> <87r2uyzrkn.fsf@nic.cz> From: Robert Wilton Message-ID: Date: Mon, 25 Sep 2017 16:08:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87r2uyzrkn.fsf@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:08:37 -0000 On 22/09/2017 16:22, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> Robert Wilton wrote: >>> Hi Kent, >>> >>> Thanks for the suggestion. >>> >>> I think that your solution works if the implementation instantiates an >>> an actual leaf to represent the default value, but I'm not sure that >>> is meant to be required.  Without this "Last-Modified" requirement an >>> implementation could implicitly instantiate default values from the >>> schema when required (e.g. for validation) but not necessarily >>> explicitly store them. >>> >>> But from my reading of RESTCONF section 3.5, the two choices seem to >>> be either: >>> >>> (i) the device has to store the timestamp of when the default value >>> took effect (e.g. the last time it was implicitly instantiated for >>> whatever reason). >>> >>> (ii) the device could return the datastore timestamp for the >>> implicitly created default node.  But I'm not sure how meaningful that >>> is if the device also chooses to return accurate last modified >>> timestamps for explicitly configured nodes.  If an implementation was >>> to do this then you could easily have a scenario where an implicitly >>> created child node has a later timestamp than its parent node, which >>> doesn't seem to to be good. >>> >>> So, perhaps the conclusion is: if you want to return accurate >>> timestamps for explicitly created nodes, then it is necessary to also >>> maintain accurate timestamps for implicitly created default nodes as >>> well? >> IMO this is all implementation details. One implementation might >> instantiate all defaults, while another comes up with some other >> clever mechanism to avoid redundant storage. The spec should clearly >> define the semantics associated with the timestamp, and not talk about >> how it must be implemented. > I think it would be better and simpler to adhere to the semantics that is > defined for each header field in HTTP specs. > > For Last-Modified it is section 2.2 in RFC 7232: > > The "Last-Modified" header field in a response provides a timestamp > indicating the date and time at which the origin server believes the > selected representation was last modified, ... > > So I think Kent's conclusion is correct: the representation was last > modified when the resource was (conceptually) created, which was at the > time of parent container creation. I don't think that this is necessarily true.  The default value may get "created" if an explicitly configured value for the leaf is removed/deleted. So, i think that it is required to explicitly track the timestamp of when the default node logically came into existence, i.e. the same as for any other explicitly configured node. > > ETag is also quite interesting (sec. 2.3): > > An entity-tag is an opaque validator for differentiating between > multiple representations of the same resource, regardless of whether > those multiple representations are due to resource state changes over > time, content negotiation resulting in multiple representations being > valid at the same time, or both. > > As I understand it, if an otherwise unmodified resource (e.g. a > container instance) is represented once with defaults and another time > without defaults, the two representations should have different ETags. Yes, I would think so. Thanks, Rob > > Lada > > >> >> /martin >> >> >>> Thanks, >>> Rob >>> >>> >>> On 14/09/2017 16:05, Kent Watsen wrote: >>>> The default value node was implicitly instantiated when the parent >>>> node was created, so I'd set its Last-Modified value to that value. >>>> >>>> K. // contributor >>>> >>>> >>>> -- >>>> >>>> Hi, >>>> >>>> If I make a RESTCONF GET request with a path to a data resource that >>>> doesn't exist, but has an in scope schema default value, and I'm using >>>> one of the with-defaults options that means that the default value is >>>> returned, then what value is the "Last-Modified" header expected or >>>> required to take? >>>> >>>> Specifically, I am thinking of a device that uses per data resource >>>> timestamps for all explicitly configured data resources rather than >>>> having a single top level datastore resource timestamp. >>>> >>>> Thanks, >>>> Rob >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 25 09:55:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322E81344F1 for ; Mon, 25 Sep 2017 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZarZKnHqFIjT for ; Mon, 25 Sep 2017 09:55:05 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDF31344CA for ; Mon, 25 Sep 2017 09:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4872; q=dns/txt; s=iport; t=1506358505; x=1507568105; h=to:from:subject:message-id:date:mime-version; bh=s63SB8glrpwnA4Maug7DFWBzT944k4XkBQX0br9L0MY=; b=XQ7AMAveZ5uqi4XEtXP6wwRYETpMiBPHTF6B1iII+20XO0xYGfeoF6aY +71d/f1Q03NXqGBLIH02th5TqtWhEtOmlE6kAYRgev+dL0RpwRX3xKKgy dz5BSUyRGxS3dKDeVLR48CkhnpbDEkFuB9kPOWfO8CfEYwlwVMIXx0b+r A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQCeM8lZ/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvgU9uJ4N2ixSQUpEXh1AKI4oUFAECAQEBAQEBAWsohUJ1PgJ?= =?us-ascii?q?fAQwIAQGKLxCnb4InJ4pxAQEBAQYBAQEBAR4FgyuDU4FnK4dVFYMpgmAFoR+HX?= =?us-ascii?q?Yx/i1yHKo1th1mBOTYhQkwyIQgdFYdnPzYBiBcBAQE?= X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208,217";a="654975116" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 16:55:03 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8PGt2bo015458; Mon, 25 Sep 2017 16:55:02 GMT To: "netconf@ietf.org" , Andy Bierman , Martin Bjorklund , Kent Watsen From: Robert Wilton Message-ID: Date: Mon, 25 Sep 2017 17:55:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6246ADFA4EEF260B3632BDC4" Content-Language: en-US Archived-At: Subject: [Netconf] YANG Patch 'remove' operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:55:07 -0000 This is a multi-part message in MIME format. --------------6246ADFA4EEF260B3632BDC4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I might have found a possible bug in YANG Patch: Regarding section 2.2 of RFC 8072, the second paragraph states (as I would expect): The "merge", "replace", "create", "delete", and "remove" edit operations have exactly the same meanings as those defined for the "operation" attribute described inSection 7.2 of [RFC6241] . However, the third paragraph in this section then goes on to say: ... If the edit does not identify any existing resource instance and the operation for the edit is not "create", then the request MUST NOT be processed and a "404 Not Found" error response MUST be sent by the server. This seems to be require that "merge" operations have to be handled like "create" operations, and "remove" operations have to be handled like "delete" operations. Hence I think that the text in this third paragraph may be slightly wrong, and perhaps should be?: ... If the edit does not identify any existing resource instance and the operation for the edit is not "create", "merge", or "remove", then the request MUST NOT be processed and a "404 Not Found" error response MUST be sent by the server. Otherwise, it seems like 'merge' has to be handled like 'create', and 'remove' like 'delete', which then directly conflicts with the second paragraph? Thanks, Rob --------------6246ADFA4EEF260B3632BDC4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I might have found a possible bug in YANG Patch:

Regarding section 2.2 of RFC 8072, the second paragraph states (as I would expect):

   The "merge", "replace", "create", "delete", and "remove" edit
   operations have exactly the same meanings as those defined for the
   "operation" attribute described in Section 7.2 of [RFC6241].

However, the third paragraph in this section then goes on to say:

   ... If the edit does not identify
   any existing resource instance and the operation for the edit is not
   "create", then the request MUST NOT be processed and a "404 Not
   Found" error response MUST be sent by the server.

This seems to be require that "merge" operations have to be handled like "create" operations, and "remove" operations have to be handled like "delete" operations. 

Hence I think that the text in this third paragraph may be slightly wrong, and perhaps should be?:

   ... If the edit does not identify
   any existing resource instance and the operation for the edit is not
   "create", "merge", or "remove", then the request MUST NOT be processed and a "404 Not
   Found" error response MUST be sent by the server.

Otherwise, it seems like 'merge' has to be handled like 'create', and 'remove' like 'delete', which then directly conflicts with the second paragraph?

Thanks,
Rob
--------------6246ADFA4EEF260B3632BDC4-- From nobody Mon Sep 25 10:01:14 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F511344F0 for ; Mon, 25 Sep 2017 10:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbedKGXzHn5t for ; Mon, 25 Sep 2017 10:01:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8FF1344E6 for ; Mon, 25 Sep 2017 10:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17628; q=dns/txt; s=iport; t=1506358869; x=1507568469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XroyCK6Z7UW2yhPj0owpA84oCydqd23W0CZlp5JBt5Y=; b=gKHsrsA4tk2h4I6hcZWuNO5AyG5uJ0VR7Abutb3HQlCdmPLjHxXO4mzg MhHfnSjNaFgDodyiBodmYeBH6CM/NCjOlbPMfhf81k9H4yAVKzbUyo+P8 uTd6HYh3lMcbbVkoTZsV06ctnjdbf3HM4BrHc0WGzFchkSWS8hD/XlRGo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQBhNclZ/4oNJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJva2RuJweFdZgVgXaQbIdQCiODOoEPTwKEN1cBAgEBAQEBAms?= =?us-ascii?q?ohRgBAQEBAgEOHzgUBQsCAQgOBwIOGgcyFAkIAgQOBQgTiTRcCBCqFosZAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDK4ICgVGBZ4IbgQ2EWQMHAQGGEQWYTYhSApR?= =?us-ascii?q?RghyQc4oKiw8CERkBgTgBV4EOeBWFKjkcgWd2AYVVAg0XB4EFgRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208,217";a="7869403" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Sep 2017 17:01:08 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8PH17GI007768 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 17:01:08 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 13:01:07 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 13:01:07 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNglTsFoIhismq06+Nfgq5lEDuqLFtEfw Date: Mon, 25 Sep 2017 17:01:07 +0000 Message-ID: References: <20170925.161745.619992510057596315.mbj@tail-f.com> In-Reply-To: <20170925.161745.619992510057596315.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_bc16c18fd5d7408dae9d86335eeca7f1XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:01:12 -0000 --_000_bc16c18fd5d7408dae9d86335eeca7f1XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Martin Bjorklund, September 25, 2017 10:18 AM > To: Eric Voit (evoit) > Cc: netconf@ietf.org > Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft > > "Eric Voit (evoit)" > wrote: > > Support, with one caveat: > > that the modeling of the filter elements of dsdt-nmda-netconf and the > > filtering elements of yang-push converge into a common set of objects > > across both solutions. > > Yes this might be a good idea, if the filters are used for the same purpo= se, i.e., > select a set of nodes. Excellent. And yes, they are both node selection filters. In any case, I am fine with whatever the WG decides after we close the issu= es below. The funny thing here is we did have the explicit subtyping like = you currently have with this draft, and only shifted to the abstracted stru= cture based on our interpretation of NMDA discussions from IETF 98. https://www.ietf.org/mail-archive/web/netconf/current/msg12596.html > > The reason for this caveat is as follows: > > > > Until April 2017, yang-push had the same explicit filter subtyping as > > is now proposed within dsdt-nmda-netconf-01 > > > > subscription* > > +-- update-filter > > +--:(subtree) > > | +-- subtree-filter anydata > > +--:(xpath) > > +-- xpath-filter? yang:xpath1.0 > > > > > > However this structure has a downside. Any new filter type to be > > added requires a revision to any data nodes, rpcs, and notifications. > > I don't understand the last sentence. Can you elaborate? Subtree and xpath might not be the only filtering subtypes that customers w= ant to use. While it is possible to add new types via augmentation, this= can be complex and verbose. For example, in yang-push, every new explicit filter subtyping added will r= esult in six separate augmentations. So if we added something like your co= ol-new filter below, augmented would be: module: ietf-subscribed-notifications (several places) rpc: establish-subscription notification subscription-started notification: subscription-modified >From a model structure/readability viewpoint, this is far more complex. Ju= st adding an identity seems preferable. Likewise for platforms doing deviations if they don't support every filter = type, they will have to deviate away every explicit subtree. Yes the new leaf needs to be set, and this is not free. Like with any mode= l, we need to balance abstraction & complexity. > > An argument can be made that the explicit subtyping results in better > > protections. However datatyping of filter contents is trivial > > compared to the evaluation of the actual contents to see if these are > > meaningful. And in any case the typedef on xpath1.0 in RFC6021 is > > "string", so meaningful protections require logic anyway. > > > > Based on that, the current structure of the yang-push filter is now: > > > > subscription* > > +--: (selected-content) > > +-- selection-filter-type selection-filter-type > > +-- selection-filter anydata > > But what would an XPath filter look like with this solution? Note that t= his > doesn't validate: > > /interfaces The contents of nmda's xpath-filter would be 100% identical to the contents= of yang-push's selection-filter when selection-filter-type is of type xpat= h-selection-filter. I suspect that the data typing protections are limited vs. what is needed t= o validate a particular selection filter. And these protections are achiev= able by looking at the contents of the selection-filter-type in conjunction= with the selection-filter. Perhaps we could use the "when" statement to do= this? > Also, suppose we add a new cool filter type in the future, which requires= 4 leafs > to be set. Modelling these as "anydata" is not as exact as: > > container new-cool-filter { > leaf foo { ... } > leaf bar { ... } > ... > } It is true that it is not as exact. But the exactness does come at the pri= ce of a more verbose model. Every new filter type adds about 11% on the to= tal size of the yang-push model. > > This structure allows the addition of filter types through the use of > > additional identities, and doesn't require corresponding changes to > > yang models, rpcs, or notifications. > > Well, IMO you have to model the filter parameters, otherwise we end up wi= th > just an "anydata" node whose contents are described in plain text. Yes, just an anydata node. With additional protections that can be applied= based on the value of selection-filter-type. Eric > /martin --_000_bc16c18fd5d7408dae9d86335eeca7f1XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> From: Martin Bjorklund, September 25, 2017 1= 0:18 AM

> To: Eric Voit (evoit) <evoit@cisco.com>= ;

> Cc: netconf@ietf.org

> Subject: Re: [Netconf] WG adoption of NETCON= F NDMA draft

>

> "Eric Voit (evoit)" <evoit@cisco.com> wrote:

> > Support, with one caveat:

> > that the modeling of the filter element= s of dsdt-nmda-netconf and the

> > filtering elements of yang-push converg= e into a common set of objects

> > across both solutions.

>

> Yes this might be a good idea, if the filter= s are used for the same purpose, i.e.,

> select a set of nodes.

 

Excellent.  

 

And yes, they are both node selection filters.&nb= sp;

 

In any case, I am fin= e with whatever the WG decides after we close the issues below.  The f= unny thing here is we did have the explicit subtyping like you currently ha= ve with this draft, and only shifted to the abstracted structure based on our interpretation of NMDA discussions from = IETF 98.

https://www.ietf= .org/mail-archive/web/netconf/current/msg12596.html

 

> > The reason for this caveat is as follow= s:

> >

> > Until April 2017, yang-push had the sam= e explicit filter subtyping as

> > is now proposed within dsdt-nmda-netcon= f-01

> >

> > subscription*

> >    +-- update-filter=

> >       = 3;--:(subtree)

> >       |&n= bsp; +-- subtree-filter      anydata

> >       = 3;--:(xpath)

> >      &nbs= p;   +-- xpath-filter?       ya= ng:xpath1.0

> >

> >

> > However this structure has a downside.&= nbsp; Any new filter type to be

> > added requires a revision to any data n= odes, rpcs, and notifications.

>

> I don't understand the last sentence.  = Can you elaborate?

 

Subtree and xpath mig= ht not be the only filtering subtypes that customers want to use.  &nb= sp; While it is possible to add new types via augmentation, this can b= e complex and verbose.

 

For example, in yang-= push, every new explicit filter subtyping added will result in six separate= augmentations.  So if we added something like your cool-new filter be= low, augmented would be:

 

module: ietf-subscrib= ed-notifications (several places)

rpc: establish-subscr= iption

notification subscrip= tion-started

notification: subscri= ption-modified

 

From a model structur= e/readability viewpoint, this is far more complex.  Just adding an ide= ntity seems preferable.   

 

Likewise for platform= s doing deviations if they don’t support every filter type, they will= have to deviate away every explicit subtree.

 

Yes the new leaf need= s to be set, and this is not free.  Like with any model, we need to ba= lance abstraction & complexity. 

 

> > An argument can be made that the explic= it subtyping results in better

> > protections.  However datatyping o= f filter contents is trivial

> > compared to the evaluation of the actua= l contents to see if these are

> > meaningful.  And in any case the t= ypedef on xpath1.0 in RFC6021 is

> > "string", so meaningful prote= ctions require logic anyway.

> >

> > Based on that, the current structure of= the yang-push filter is now:

> >

> > subscription*

> >    +--: (selected-co= ntent)

> >       = 3;-- selection-filter-type  selection-filter-type

> >       = 3;-- selection-filter       anydata

>

> But what would an XPath filter look like wit= h this solution?  Note that this

> doesn't validate:

>

>    <selection-filter>/i= nterfaces</selection-filter>

 

The contents of nmda&= #8217;s xpath-filter would be 100% ident= ical to the contents of yang-push’s selection-filter when selection-filter-type is of type xpath-selection-filter.  =

 

I suspect that the data typing protections are li= mited vs. what is needed to validate a particular selection filter.  A= nd these protections are achievable by looking at the contents of the selec= tion-filter-type in conjunction with the selection-filter. Perhaps we could use the “when” statement to= do this? 

 

> Also, suppose we add a new cool filter type = in the future, which requires 4 leafs

> to be set.  Modelling these as "an= ydata" is not as exact as:

>

>    container new-cool-filter = {

>      leaf foo { ...= }

>      leaf bar { ...= }

>      ...

>    }

 

It is true that it is= not as exact.  But the exactness does come at the price of a more ver= bose model.  Every new filter type adds about 11% on the total size of= the yang-push model.

 

> > This structure allows the addition of f= ilter types through the use of

> > additional identities, and doesn't requ= ire corresponding changes to

> > yang models, rpcs, or notifications.

>

> Well, IMO you have to model the filter param= eters, otherwise we end up with

> just an "anydata" node whose conte= nts are described in plain text.

 

Yes, just an anydata node.  With additional = protections that can be applied based on the value of selection-filter-type= .

 

Eric

 

> /martin

--_000_bc16c18fd5d7408dae9d86335eeca7f1XCHRTP013ciscocom_-- From nobody Mon Sep 25 10:14:55 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E7134516; Mon, 25 Sep 2017 10:14:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150635968827.27362.12941484059056029708@ietfa.amsl.com> Date: Mon, 25 Sep 2017 10:14:48 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:14:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : UDP based Publication Channel for Streaming Telemetry Authors : Guangying Zheng Tianran Zhou Alexander Clemm Filename : draft-ietf-netconf-udp-pub-channel-00.txt Pages : 13 Date : 2017-09-22 Abstract: This document describes a UDP-based publication channel for streaming telemetry use to collect data from devices. A new shim header is proposed to facilitate the distributed data collection mechanism which directly pushes data from line cards to the collector. Because of the lightweight UDP encapsulation, higher frequency and better transit performance can be achieved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-pub-channel-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 25 10:25:47 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72B9134512 for ; Mon, 25 Sep 2017 10:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd_7HSWcOykz for ; Mon, 25 Sep 2017 10:25:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0400134507 for ; Mon, 25 Sep 2017 10:25:42 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id C1F8D1AE02A7; Mon, 25 Sep 2017 19:25:40 +0200 (CEST) Date: Mon, 25 Sep 2017 19:28:03 +0200 (CEST) Message-Id: <20170925.192803.763609160917048321.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170925.161745.619992510057596315.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:25:46 -0000 "Eric Voit (evoit)" wrote: > > From: Martin Bjorklund, September 25, 2017 10:18 AM > > > To: Eric Voit (evoit) > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft > > > > > > "Eric Voit (evoit)" > wrote: > > > > Support, with one caveat: > > > > that the modeling of the filter elements of dsdt-nmda-netconf and the > > > > filtering elements of yang-push converge into a common set of objects > > > > across both solutions. > > > > > > Yes this might be a good idea, if the filters are used for the same > > purpose, i.e., > > > select a set of nodes. > > > > Excellent. > > > > And yes, they are both node selection filters. > > > > In any case, I am fine with whatever the WG decides after we close the > issues below. The funny thing here is we did have the explicit > subtyping like you currently have with this draft, and only shifted to > the abstracted structure based on our interpretation of NMDA > discussions from IETF 98. > > https://www.ietf.org/mail-archive/web/netconf/current/msg12596.html > > > > > > The reason for this caveat is as follows: > > > > > > > > Until April 2017, yang-push had the same explicit filter subtyping as > > > > is now proposed within dsdt-nmda-netconf-01 > > > > > > > > subscription* > > > > +-- update-filter > > > > +--:(subtree) > > > > | +-- subtree-filter anydata > > > > +--:(xpath) > > > > +-- xpath-filter? yang:xpath1.0 > > > > > > > > > > > > However this structure has a downside. Any new filter type to be > > > > added requires a revision to any data nodes, rpcs, and notifications. > > > > > > I don't understand the last sentence. Can you elaborate? > > > > Subtree and xpath might not be the only filtering subtypes that > customers want to use. While it is possible to add new types via > augmentation, this can be complex and verbose. With the same argument, we could have defined the interface model like this: container interfaces { list interface { key name; leaf name { ... } anydata properties; } } anydata should be used only when the contents are truly generic, e.g., in the input to or in a list of received notifications. > For example, in yang-push, every new explicit filter subtyping added > will result in six separate augmentations. So if we added something > like your cool-new filter below, augmented would be: > > > > module: ietf-subscribed-notifications (several places) > > rpc: establish-subscription > > notification subscription-started > > notification: subscription-modified Why is this one needed? Isn't one of the ideas with yang push that we won't need special notifications for config changes? Wouldn't you use yang-push to subscribe to the subscription config, if you want to get this info? > From a model structure/readability viewpoint, this is far more > complex. Just adding an identity seems preferable. > > > > Likewise for platforms doing deviations if they don't support every > filter type, they will have to deviate away every explicit subtree. How would they deviate away a specific filter with your proposal? Or deviate away one of the four parameters of "new-cool-filter"? > Yes the new leaf needs to be set, and this is not free. Like with any > model, we need to balance abstraction & complexity. > > > > > > An argument can be made that the explicit subtyping results in better > > > > protections. However datatyping of filter contents is trivial > > > > compared to the evaluation of the actual contents to see if these are > > > > meaningful. And in any case the typedef on xpath1.0 in RFC6021 is > > > > "string", so meaningful protections require logic anyway. > > > > > > > > Based on that, the current structure of the yang-push filter is now: > > > > > > > > subscription* > > > > +--: (selected-content) > > > > +-- selection-filter-type selection-filter-type > > > > +-- selection-filter anydata > > > > > > But what would an XPath filter look like with this solution? Note > > that this > > > doesn't validate: > > > > > > /interfaces > > > > The contents of nmda's xpath-filter would be 100% identical to the > contents of yang-push's selection-filter when selection-filter-type is > of type xpath-selection-filter. And what does that look like? Can you provide an example of a filter that selects the "/interfaces" node with XPath? > I suspect that the data typing protections are limited vs. what is > needed to validate a particular selection filter. And these > protections are achievable by looking at the contents of the > selection-filter-type in conjunction with the > selection-filter. Perhaps we could use the "when" statement to do > this? I don't understand what that would be, can you provide an example? /martin > > Also, suppose we add a new cool filter type in the future, which > > requires 4 leafs > > > to be set. Modelling these as "anydata" is not as exact as: > > > > > > container new-cool-filter { > > > leaf foo { ... } > > > leaf bar { ... } > > > ... > > > } > > > > It is true that it is not as exact. But the exactness does come at > the price of a more verbose model. Every new filter type adds about > 11% on the total size of the yang-push model. > > > > > > This structure allows the addition of filter types through the use of > > > > additional identities, and doesn't require corresponding changes to > > > > yang models, rpcs, or notifications. > > > > > > Well, IMO you have to model the filter parameters, otherwise we end up > > with > > > just an "anydata" node whose contents are described in plain text. > > > > Yes, just an anydata node. With additional protections that can be > applied based on the value of selection-filter-type. > > > > Eric > > > > > /martin From nobody Mon Sep 25 10:27:37 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93A134515 for ; Mon, 25 Sep 2017 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BesMC-tmsv_U for ; Mon, 25 Sep 2017 10:27:34 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38110134528 for ; Mon, 25 Sep 2017 10:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3581; q=dns/txt; s=iport; t=1506360454; x=1507570054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kvYAhFYWQ7jvvau6zRsIXpLmBlk/tM8AdScUh6xoEEQ=; b=le80My60iwd0eclCItLtSaSrQ9rfSIsFyjINkcIqeC70/YtXNjhia+/g 6Kbqc4jR/RrJgZgPbnd0qEJH6x2+QRuPvAJZ15g917NhzjAouVAIcT/1m /hdDVzfGV9c0bB1CscT9xAL9rV451qoSTwhfJr7LGXEqLEW5O9SK9Ey2/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAQBCO8lZ/5JdJa1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWmRuLp4KgXaYPAofhRwChDdXAQIBAQEBAQJrKIUYAQEBAQI?= =?us-ascii?q?BOj8FCQICAQgOAgUDDREQGxclAgQODROKEAiqHIsZAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHQWDJoICgVGFD4RZBEcmhSwFoR8ClFGCHJBzigqLDwIRGQGBOAFXgQ5?= =?us-ascii?q?4FYdmhk2BMYEQAQEB?= X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208";a="7880328" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 17:27:33 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8PHRWKc031349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 17:27:33 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 13:27:32 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 13:27:32 -0400 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder CC: "'netconf'" Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNgd4J5OLOU6LbUK/pZLIDT/TLaLF07pQ Date: Mon, 25 Sep 2017 17:27:31 +0000 Message-ID: <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> References: <20170925140540.djxmhbgtjhghjh6l@elstar.local> In-Reply-To: <20170925140540.djxmhbgtjhghjh6l@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:27:36 -0000 Hi Juergen, > From: Juergen Schoenwaelder, September 25, 2017 10:06 AM >=20 > On Mon, Sep 25, 2017 at 01:58:59PM +0000, Eric Voit (evoit) wrote: > > Support, with one caveat: > > that the modeling of the filter elements of dsdt-nmda-netconf and the > filtering elements of yang-push converge into a common set of objects acr= oss > both solutions. > > > > The reason for this caveat is as follows: > > > > Until April 2017, yang-push had the same explicit filter subtyping as > > is now proposed within dsdt-nmda-netconf-01 > > > > subscription* > > +-- update-filter > > +--:(subtree) > > | +-- subtree-filter anydata > > +--:(xpath) > > +-- xpath-filter? yang:xpath1.0 > > > > > > However this structure has a downside. Any new filter type to be adde= d > requires a revision to any data nodes, rpcs, and notifications. >=20 > Why would that be? Or what does 'any data modes, rpcs, and notifications' > mean here? Yang-push has the same information (selection filters). This selection fi= lter appears in rpcs, notifications, and datanodes. A new filter type requ= ires augmentations across all of these. A non-supported filter type requir= es deviations spanning all of these. > > An argument can be made that the explicit subtyping results in better > protections. However datatyping of filter contents is trivial compared t= o the > evaluation of the actual contents to see if these are meaningful. And in= any > case the typedef on xpath1.0 in RFC6021 is "string", so meaningful protec= tions > require logic anyway. > > > > Based on that, the current structure of the yang-push filter is now: > > > > subscription* > > +--: (selected-content) > > +-- selection-filter-type selection-filter-type > > +-- selection-filter anydata > > > > This structure allows the addition of filter types through the use of = additional > identities, and doesn't require corresponding changes to yang models, rpc= s, or > notifications. > > >=20 > An augment to a choice is a good thing. It requires to spell out how a fi= lter > mechanism works and what the parameters of the filter mechanism are. There are many possibilities for filter parameters and mechanisms. Even if= we limit things to just xpath, every vendor will have differences in the c= omplexity and elements of expression support. The question is whether we a= re buying meaningful with the explicit subtyping that cannot be delivered i= n other ways. Based on these drivers, I feel it useful to decouple the problems of transp= orting the selection filter object from the interpretation of that object. = It scales better. > I also > automatically get a way to announce what filtering mechanisms an > implementation supports. Something entirely opaque is well entirely opaqu= e. Yes, augmentations are good things. We have 14 of them in yang-push. The= issue is that new filter types each requires six additional augmentations.= This makes new vendor specific filter type difficult to add, expose, and = explain to 3rd party developers. This is complex, is a place where errors c= ould easily be introduced, and will inhibit adoption. I have been hoping for something simpler like just adding a new identity. Eric > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Sep 25 13:01:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7F132055 for ; Mon, 25 Sep 2017 13:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVuOj-bYLDNl for ; Mon, 25 Sep 2017 13:01:20 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA5413219C for ; Mon, 25 Sep 2017 13:01:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A4F13375; Mon, 25 Sep 2017 22:01:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id PE5KcQBtAOU6; Mon, 25 Sep 2017 22:01:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Sep 2017 22:01:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D861200F4; Mon, 25 Sep 2017 22:01:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WKsVxjzvCip7; Mon, 25 Sep 2017 22:01:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3443D200F1; Mon, 25 Sep 2017 22:01:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D70BC4114EE1; Mon, 25 Sep 2017 22:01:17 +0200 (CEST) Date: Mon, 25 Sep 2017 22:01:17 +0200 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: 'netconf' Message-ID: <20170925200117.6tcnga7rg3gy5rie@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , 'netconf' References: <20170925140540.djxmhbgtjhghjh6l@elstar.local> <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:01:22 -0000 On Mon, Sep 25, 2017 at 05:27:31PM +0000, Eric Voit (evoit) wrote: > > An augment to a choice is a good thing. It requires to spell out how a filter > > mechanism works and what the parameters of the filter mechanism are. > > There are many possibilities for filter parameters and mechanisms. Even if we limit things to just xpath, every vendor will have differences in the complexity and elements of expression support. The question is whether we are buying meaningful with the explicit subtyping that cannot be delivered in other ways. If every vendor implement a different variant of xpath, we failed to create a standard. A standard that allows everybody to implement whatever he prefers is not useful. Standards are for interoperability. > Based on these drivers, I feel it useful to decouple the problems of transporting the selection filter object from the interpretation of that object. It scales better. It hurts interoperability more. > > I also > > automatically get a way to announce what filtering mechanisms an > > implementation supports. Something entirely opaque is well entirely opaque. > > Yes, augmentations are good things. We have 14 of them in yang-push. The issue is that new filter types each requires six additional augmentations. This makes new vendor specific filter type difficult to add, expose, and explain to 3rd party developers. This is complex, is a place where errors could easily be introduced, and will inhibit adoption. And all this goes away if the filter is opaque? I doubt this very much. Hiding the issue does not help 3rd part developers, it does not help interoperability. /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 Sep 25 13:16:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62E6134592 for ; Mon, 25 Sep 2017 13:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHU0HlRBviAm for ; Mon, 25 Sep 2017 13:16:43 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08794134596 for ; Mon, 25 Sep 2017 13:16:41 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id c23so9873962wrg.9 for ; Mon, 25 Sep 2017 13:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=27YRsojyB5qZWj/T8ryBsz5s/a78eFvFiWSB1/Ond8k=; b=T3RvBa84RLnPTUQAyRypiASXwMfnhQodPK+dsUDFqRUcdfxi93toYQ7CkUsnfFZJo3 F3uargHb2Ml7blECeR6pVi26ZOeVhiazE5Z247RM85QOgF8DMEyMu1e6Eld0obdTRtb4 PE+auMusvNF29iji5dbzmHQcfr3fcaexFc+lgdcuEsbKHD13XwncsJcSBA0DTkHq3wdV TdtIvRTays5R9rr6YwdXKezUAru19Ea4qa34WNk1d1d/T87hYfFqe89X/4dLxKCfIDvo uTEBku6S42YkMTjjzvc4p806u42aw6X6eTHyMsiF3eKBcPS0SveEY97K1hc41qxOWu2V ITjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=27YRsojyB5qZWj/T8ryBsz5s/a78eFvFiWSB1/Ond8k=; b=VAI5unTWJp1sCMR7GEcDpQvlDYcE7Xuj5o27FzEEPZLlHc1Yekvf0oHmD1pb+o15hw oCnt4x10/i1eWh9DBA0XVPBnS6Vx5M3bczp1XyL8dMuXCEGO9i3pGsteXeTnfBAVQ71T IOAJ77zfelOjBss4yvFQn8w7DpSggOkltNcrYpEXqob6XWddhPw4WpxtWKCxyCGresB4 tPy7PWdGFrguqZQRQdXX+XJ3yz8dWcl5yv2O0xxAq5PCF8mfO2nORGRNyRBlnY63zHu/ NiKhZsApiMHijdvmC2cBZrXzebLQhIgl4Em+7yyZKEoSbDx5fx1IcDs7WGABF5l10D1C 0nGg== X-Gm-Message-State: AHPjjUhIEv/N+xvMc4cOk+/PRT9tWpw/Gi274Qemms+cQJ0e53vlyFyF OBWSfbyn/k9/rN23SQ/7/ee1NTB81H7eWM4vfT92Gw== X-Google-Smtp-Source: AOwi7QAn/IFQRFMldv5XI6hu3SuQkKobbQJSjH2buxkqlV2GcHiWnGFmofd2j64eES1FmM7uwUDhJTk62NssN6ITmzA= X-Received: by 10.25.211.14 with SMTP id k14mr2586277lfg.51.1506370599538; Mon, 25 Sep 2017 13:16:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.41 with HTTP; Mon, 25 Sep 2017 13:16:38 -0700 (PDT) In-Reply-To: <20170925200117.6tcnga7rg3gy5rie@elstar.local> References: <20170925140540.djxmhbgtjhghjh6l@elstar.local> <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> <20170925200117.6tcnga7rg3gy5rie@elstar.local> From: Andy Bierman Date: Mon, 25 Sep 2017 13:16:38 -0700 Message-ID: To: Juergen Schoenwaelder , "Eric Voit (evoit)" , netconf Content-Type: multipart/alternative; boundary="001a11400d727c68ce055a093cbd" Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:16:45 -0000 --001a11400d727c68ce055a093cbd Content-Type: text/plain; charset="UTF-8" On Mon, Sep 25, 2017 at 1:01 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Sep 25, 2017 at 05:27:31PM +0000, Eric Voit (evoit) wrote: > > > An augment to a choice is a good thing. It requires to spell out how a > filter > > > mechanism works and what the parameters of the filter mechanism are. > > > > There are many possibilities for filter parameters and mechanisms. Even > if we limit things to just xpath, every vendor will have differences in the > complexity and elements of expression support. The question is whether we > are buying meaningful with the explicit subtyping that cannot be delivered > in other ways. > > If every vendor implement a different variant of xpath, we failed to > create a standard. A standard that allows everybody to implement > whatever he prefers is not useful. Standards are for interoperability. > > > Based on these drivers, I feel it useful to decouple the problems of > transporting the selection filter object from the interpretation of that > object. It scales better. > > It hurts interoperability more. > +1 > > > > I also > > > automatically get a way to announce what filtering mechanisms an > > > implementation supports. Something entirely opaque is well entirely > opaque. > > > > Yes, augmentations are good things. We have 14 of them in yang-push. > The issue is that new filter types each requires six additional > augmentations. This makes new vendor specific filter type difficult to > add, expose, and explain to 3rd party developers. This is complex, is a > place where errors could easily be introduced, and will inhibit adoption. > > And all this goes away if the filter is opaque? I doubt this very > much. Hiding the issue does not help 3rd part developers, it does not > help interoperability. > Using anydata instead of real YANG data nodes is the worst thing possible for a 3rd-party client developer. It makes YANG automation impossible, not just harder. YANG compilers have no problem sorting out statements from multiple files. 14 things may be a lot for humans to read, but not for a YANG compiler. Removing the filter specification from the standard does not help client developers writing code to use a filter. > /js > Andy > > -- > 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 > --001a11400d727c68ce055a093cbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 25, 2017 at 1:01 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 25, 2017 at 05:27:31PM +0000, Eric Voit = (evoit) wrote:
> > An augment to a choice is a good thing. It requires to spell out = how a filter
> > mechanism works and what the parameters of the filter mechanism a= re.
>
> There are many possibilities for filter parameters and mechanisms.=C2= =A0 Even if we limit things to just xpath, every vendor will have differenc= es in the complexity and elements of expression support.=C2=A0 The question= is whether we are buying meaningful with the explicit subtyping that canno= t be delivered in other ways.

If every vendor implement a different variant of xpath, we failed to
create a standard. A standard that allows everybody to implement
whatever he prefers is not useful. Standards are for interoperability.

> Based on these drivers, I feel it useful to decouple the problems of t= ransporting the selection filter object from the interpretation of that obj= ect.=C2=A0 It scales better.

It hurts interoperability more.

+1
=C2=A0

> > I also
> > automatically get a way to announce what filtering mechanisms an<= br> > > implementation supports. Something entirely opaque is well entire= ly opaque.
>
> Yes, augmentations are good things.=C2=A0 We have 14 of them in yang-p= ush.=C2=A0 =C2=A0The issue is that new filter types each requires six addit= ional augmentations.=C2=A0 This makes new vendor specific filter type diffi= cult to add, expose, and explain to 3rd party developers. This is complex, = is a place where errors could easily be introduced, and will inhibit adopti= on.

And all this goes away if the filter is opaque? I doubt this very
much.=C2=A0 Hiding the issue does not help 3rd part developers, it does not=
help interoperability.


U= sing anydata instead of real YANG data nodes is the worst thing possible
for a 3rd-party client developer.=C2=A0 It makes YANG automation im= possible, not just harder.
YANG compilers have no problem sorting= out statements from multiple files.
14 things may be a lot for h= umans to read, but not for a YANG compiler.=C2=A0

<= div>Removing the filter specification from the standard does not help clien= t
developers writing code to use =C2=A0a filter.




/js


Andy

=C2=A0

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a11400d727c68ce055a093cbd-- From nobody Mon Sep 25 14:47:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D211345C3 for ; Mon, 25 Sep 2017 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLZS9_rd4HMG for ; Mon, 25 Sep 2017 14:47:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353A012EC30 for ; Mon, 25 Sep 2017 14:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18884; q=dns/txt; s=iport; t=1506376031; x=1507585631; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/LmD+CQ8GZcOltWP1eKDa3VyDHYO70m4H1t/qGXAzCo=; b=Nq5jkvbfnF+dGAjYNaJIA1tPkDz1Y6MeZWEpmWGLMeWMk36cZf78Wi2/ JCgy6cb+msWPyyv2bFGxVOLwpcjymlYZImDV+ZRSuFqRF8Bl8HvISrlzR vz7n6EC1eukeLjfMxr7ZgWoGtwf/OMwNSat1XI+BmRq7CYCEr3hq5CsLD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQCceMlZ/5NdJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJva2RuJweDb5wSkGyHUAoYAQqESU8CGoQdVwECAQEBAQECayi?= =?us-ascii?q?FGAEBAQECAQEBIQpBEAkCAgEIEAEEAQEBJwMCAgIZDAsUCQgCBAESCIlHXAgQq?= =?us-ascii?q?AyCJ4QWAYcIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWDJoICgVGFD4RdPQoVEYI?= =?us-ascii?q?PPYJgBYoLiRiFKohSApRRghyJbYcGlRkCERkBgTgBV4EOeBVJhmIBOnaIF4Exg?= =?us-ascii?q?RABAQE?= X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208,217";a="8524875" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 21:47:10 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8PLl9Ja007633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 21:47:10 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 17:47:07 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 17:47:07 -0400 From: "Eric Voit (evoit)" To: Andy Bierman , Juergen Schoenwaelder , netconf , "Martin Bjorklund" , Alexander Clemm Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNgd4J5OLOU6LbUK/pZLIDT/TLaLF07pQgAB1XYCAAARKAP//0lJQ Date: Mon, 25 Sep 2017 21:47:07 +0000 Message-ID: References: <20170925140540.djxmhbgtjhghjh6l@elstar.local> <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> <20170925200117.6tcnga7rg3gy5rie@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_e6378a66672b43f489c9815e0dd1d626XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:47:14 -0000 --_000_e6378a66672b43f489c9815e0dd1d626XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyIHRoZSBwYXJhbGxlbCB0aHJlYWQgd2l0aCBNYXJ0aW4sIHlhbmctcHVzaOKAmXMgbW92ZSB0 byBzZWxlY3Rpb24tZmlsdGVyLXR5cGUgd2FzIGRvbmUgb25seSBiYWNrIGluIEFwcmlsIGJhc2Vk IG9uIG91ciBpbnRlcnByZXRhdGlvbiBvZiB3aGVyZSBubWRhIHdhcyBnb2luZy4NCg0KTW92aW5n IGJhY2sgdG8gdGhlIHByZXZpb3VzIGV4cGxpY2l0IHN1YnR5cGluZyB0aGF0IHdlIGhhZCBsb29r cyBsaWtlIGl0IHdpbGwgZHJpdmUgY29uc2Vuc3VzIGZhc3Rlci4gICBBbmQgY29uc2lkZXJpbmcg b3VyIGN1cnJlbnQgeWFuZy1wdXNoIGltcGxlbWVudGF0aW9uIGlzIGJhc2VkIG9uIHRoaXMgc2Ft ZSBleHBsaWNpdCBzdWJ0eXBlIGJyZWFrZG93biwgdGhpcyBpcyBhY3R1YWxseSBtdWNoIGVhc2ll ciBmb3IgbWUuDQoNClNvIEkgd2lsbCByZXR1cm4geWFuZy1wdXNoIHRvIHNvbWV0aGluZyBjbG9z ZSB0byB0aGUgZmlsdGVyIHN1YnR5cGluZyB3ZSBoYWQgYmVmb3JlIElFVEY5OC4gIFdoaWNoIGhh cHBlbnMgdG8gYmUgd2hhdCBpcyBpbiB0aGlzIGRyYWZ0Lg0KDQpFcmljDQoNCkZyb206IEFuZHkg Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVt YmVyIDI1LCAyMDE3IDQ6MTcgUE0NClRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT47IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBj aXNjby5jb20+OyBuZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRj b25mXSBXRyBhZG9wdGlvbiBvZiBORVRDT05GIE5ETUEgZHJhZnQNCg0KDQoNCk9uIE1vbiwgU2Vw IDI1LCAyMDE3IGF0IDE6MDEgUE0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGU+PiB3cm90ZToNCk9uIE1vbiwgU2VwIDI1LCAyMDE3IGF0IDA1OjI3OjMxUE0g KzAwMDAsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+IEFuIGF1Z21lbnQgdG8gYSBjaG9p Y2UgaXMgYSBnb29kIHRoaW5nLiBJdCByZXF1aXJlcyB0byBzcGVsbCBvdXQgaG93IGEgZmlsdGVy DQo+ID4gbWVjaGFuaXNtIHdvcmtzIGFuZCB3aGF0IHRoZSBwYXJhbWV0ZXJzIG9mIHRoZSBmaWx0 ZXIgbWVjaGFuaXNtIGFyZS4NCj4NCj4gVGhlcmUgYXJlIG1hbnkgcG9zc2liaWxpdGllcyBmb3Ig ZmlsdGVyIHBhcmFtZXRlcnMgYW5kIG1lY2hhbmlzbXMuICBFdmVuIGlmIHdlIGxpbWl0IHRoaW5n cyB0byBqdXN0IHhwYXRoLCBldmVyeSB2ZW5kb3Igd2lsbCBoYXZlIGRpZmZlcmVuY2VzIGluIHRo ZSBjb21wbGV4aXR5IGFuZCBlbGVtZW50cyBvZiBleHByZXNzaW9uIHN1cHBvcnQuICBUaGUgcXVl c3Rpb24gaXMgd2hldGhlciB3ZSBhcmUgYnV5aW5nIG1lYW5pbmdmdWwgd2l0aCB0aGUgZXhwbGlj aXQgc3VidHlwaW5nIHRoYXQgY2Fubm90IGJlIGRlbGl2ZXJlZCBpbiBvdGhlciB3YXlzLg0KDQpJ ZiBldmVyeSB2ZW5kb3IgaW1wbGVtZW50IGEgZGlmZmVyZW50IHZhcmlhbnQgb2YgeHBhdGgsIHdl IGZhaWxlZCB0bw0KY3JlYXRlIGEgc3RhbmRhcmQuIEEgc3RhbmRhcmQgdGhhdCBhbGxvd3MgZXZl cnlib2R5IHRvIGltcGxlbWVudA0Kd2hhdGV2ZXIgaGUgcHJlZmVycyBpcyBub3QgdXNlZnVsLiBT dGFuZGFyZHMgYXJlIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQo+IEJhc2VkIG9uIHRoZXNlIGRy aXZlcnMsIEkgZmVlbCBpdCB1c2VmdWwgdG8gZGVjb3VwbGUgdGhlIHByb2JsZW1zIG9mIHRyYW5z cG9ydGluZyB0aGUgc2VsZWN0aW9uIGZpbHRlciBvYmplY3QgZnJvbSB0aGUgaW50ZXJwcmV0YXRp b24gb2YgdGhhdCBvYmplY3QuICBJdCBzY2FsZXMgYmV0dGVyLg0KDQpJdCBodXJ0cyBpbnRlcm9w ZXJhYmlsaXR5IG1vcmUuDQoNCisxDQoNCg0KPiA+IEkgYWxzbw0KPiA+IGF1dG9tYXRpY2FsbHkg Z2V0IGEgd2F5IHRvIGFubm91bmNlIHdoYXQgZmlsdGVyaW5nIG1lY2hhbmlzbXMgYW4NCj4gPiBp bXBsZW1lbnRhdGlvbiBzdXBwb3J0cy4gU29tZXRoaW5nIGVudGlyZWx5IG9wYXF1ZSBpcyB3ZWxs IGVudGlyZWx5IG9wYXF1ZS4NCj4NCj4gWWVzLCBhdWdtZW50YXRpb25zIGFyZSBnb29kIHRoaW5n cy4gIFdlIGhhdmUgMTQgb2YgdGhlbSBpbiB5YW5nLXB1c2guICAgVGhlIGlzc3VlIGlzIHRoYXQg bmV3IGZpbHRlciB0eXBlcyBlYWNoIHJlcXVpcmVzIHNpeCBhZGRpdGlvbmFsIGF1Z21lbnRhdGlv bnMuICBUaGlzIG1ha2VzIG5ldyB2ZW5kb3Igc3BlY2lmaWMgZmlsdGVyIHR5cGUgZGlmZmljdWx0 IHRvIGFkZCwgZXhwb3NlLCBhbmQgZXhwbGFpbiB0byAzcmQgcGFydHkgZGV2ZWxvcGVycy4gVGhp cyBpcyBjb21wbGV4LCBpcyBhIHBsYWNlIHdoZXJlIGVycm9ycyBjb3VsZCBlYXNpbHkgYmUgaW50 cm9kdWNlZCwgYW5kIHdpbGwgaW5oaWJpdCBhZG9wdGlvbi4NCg0KQW5kIGFsbCB0aGlzIGdvZXMg YXdheSBpZiB0aGUgZmlsdGVyIGlzIG9wYXF1ZT8gSSBkb3VidCB0aGlzIHZlcnkNCm11Y2guICBI aWRpbmcgdGhlIGlzc3VlIGRvZXMgbm90IGhlbHAgM3JkIHBhcnQgZGV2ZWxvcGVycywgaXQgZG9l cyBub3QNCmhlbHAgaW50ZXJvcGVyYWJpbGl0eS4NCg0KDQpVc2luZyBhbnlkYXRhIGluc3RlYWQg b2YgcmVhbCBZQU5HIGRhdGEgbm9kZXMgaXMgdGhlIHdvcnN0IHRoaW5nIHBvc3NpYmxlDQpmb3Ig YSAzcmQtcGFydHkgY2xpZW50IGRldmVsb3Blci4gIEl0IG1ha2VzIFlBTkcgYXV0b21hdGlvbiBp bXBvc3NpYmxlLCBub3QganVzdCBoYXJkZXIuDQpZQU5HIGNvbXBpbGVycyBoYXZlIG5vIHByb2Js ZW0gc29ydGluZyBvdXQgc3RhdGVtZW50cyBmcm9tIG11bHRpcGxlIGZpbGVzLg0KMTQgdGhpbmdz IG1heSBiZSBhIGxvdCBmb3IgaHVtYW5zIHRvIHJlYWQsIGJ1dCBub3QgZm9yIGEgWUFORyBjb21w aWxlci4NCg0KUmVtb3ZpbmcgdGhlIGZpbHRlciBzcGVjaWZpY2F0aW9uIGZyb20gdGhlIHN0YW5k YXJkIGRvZXMgbm90IGhlbHAgY2xpZW50DQpkZXZlbG9wZXJzIHdyaXRpbmcgY29kZSB0byB1c2Ug IGEgZmlsdGVyLg0KDQoNCg0KDQovanMNCg0KDQpBbmR5DQoNCg0KDQotLQ0KSnVlcmdlbiBTY2hv ZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25l OiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8 IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCg0K --_000_e6378a66672b43f489c9815e0dd1d626XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVyIHRoZSBwYXJhbGxlbCB0aHJl YWQgd2l0aCBNYXJ0aW4sIHlhbmctcHVzaOKAmXMgbW92ZSB0byBzZWxlY3Rpb24tZmlsdGVyLXR5 cGUgd2FzIGRvbmUgb25seSBiYWNrIGluIEFwcmlsIGJhc2VkIG9uIG91ciBpbnRlcnByZXRhdGlv biBvZiB3aGVyZSBubWRhIHdhcyBnb2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPk1vdmluZyBiYWNrIHRvIHRoZSBwcmV2aW91cyBleHBsaWNpdCBzdWJ0eXBp bmcgdGhhdCB3ZSBoYWQgbG9va3MgbGlrZSBpdCB3aWxsIGRyaXZlIGNvbnNlbnN1cyBmYXN0ZXIu Jm5ic3A7Jm5ic3A7IEFuZCBjb25zaWRlcmluZyBvdXIgY3VycmVudCB5YW5nLXB1c2ggaW1wbGVt ZW50YXRpb24gaXMNCiBiYXNlZCBvbiB0aGlzIHNhbWUgZXhwbGljaXQgc3VidHlwZSBicmVha2Rv d24sIHRoaXMgaXMgYWN0dWFsbHkgbXVjaCBlYXNpZXIgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gSSB3aWxsIHJldHVybiB5YW5nLXB1c2ggdG8g c29tZXRoaW5nIGNsb3NlIHRvIHRoZSBmaWx0ZXIgc3VidHlwaW5nIHdlIGhhZCBiZWZvcmUgSUVU Rjk4LiZuYnNwOyBXaGljaCBoYXBwZW5zIHRvIGJlIHdoYXQgaXMgaW4gdGhpcyBkcmFmdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBB bmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTcgNDoxNyBQTTxicj4NCjxiPlRvOjwvYj4gSnVl cmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGUmZ3Q7OyBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7ZXZvaXRAY2lzY28uY29tJmd0OzsgbmV0Y29u ZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRj b25mXSBXRyBhZG9wdGlvbiBvZiBORVRDT05GIE5ETUEgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjUsIDIwMTcgYXQgMTowMSBQTSwg SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgU2VwIDI1LCAyMDE3IGF0IDA1OjI3OjMxUE0gJiM0MzswMDAwLCBFcmlj IFZvaXQgKGV2b2l0KSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgQW4gYXVnbWVudCB0byBhIGNob2lj ZSBpcyBhIGdvb2QgdGhpbmcuIEl0IHJlcXVpcmVzIHRvIHNwZWxsIG91dCBob3cgYSBmaWx0ZXI8 YnI+DQomZ3Q7ICZndDsgbWVjaGFuaXNtIHdvcmtzIGFuZCB3aGF0IHRoZSBwYXJhbWV0ZXJzIG9m IHRoZSBmaWx0ZXIgbWVjaGFuaXNtIGFyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBhcmUg bWFueSBwb3NzaWJpbGl0aWVzIGZvciBmaWx0ZXIgcGFyYW1ldGVycyBhbmQgbWVjaGFuaXNtcy4m bmJzcDsgRXZlbiBpZiB3ZSBsaW1pdCB0aGluZ3MgdG8ganVzdCB4cGF0aCwgZXZlcnkgdmVuZG9y IHdpbGwgaGF2ZSBkaWZmZXJlbmNlcyBpbiB0aGUgY29tcGxleGl0eSBhbmQgZWxlbWVudHMgb2Yg ZXhwcmVzc2lvbiBzdXBwb3J0LiZuYnNwOyBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBhcmUg YnV5aW5nIG1lYW5pbmdmdWwgd2l0aCB0aGUNCiBleHBsaWNpdCBzdWJ0eXBpbmcgdGhhdCBjYW5u b3QgYmUgZGVsaXZlcmVkIGluIG90aGVyIHdheXMuPGJyPg0KPGJyPg0KSWYgZXZlcnkgdmVuZG9y IGltcGxlbWVudCBhIGRpZmZlcmVudCB2YXJpYW50IG9mIHhwYXRoLCB3ZSBmYWlsZWQgdG88YnI+ DQpjcmVhdGUgYSBzdGFuZGFyZC4gQSBzdGFuZGFyZCB0aGF0IGFsbG93cyBldmVyeWJvZHkgdG8g aW1wbGVtZW50PGJyPg0Kd2hhdGV2ZXIgaGUgcHJlZmVycyBpcyBub3QgdXNlZnVsLiBTdGFuZGFy ZHMgYXJlIGZvciBpbnRlcm9wZXJhYmlsaXR5Ljxicj4NCjxicj4NCiZndDsgQmFzZWQgb24gdGhl c2UgZHJpdmVycywgSSBmZWVsIGl0IHVzZWZ1bCB0byBkZWNvdXBsZSB0aGUgcHJvYmxlbXMgb2Yg dHJhbnNwb3J0aW5nIHRoZSBzZWxlY3Rpb24gZmlsdGVyIG9iamVjdCBmcm9tIHRoZSBpbnRlcnBy ZXRhdGlvbiBvZiB0aGF0IG9iamVjdC4mbmJzcDsgSXQgc2NhbGVzIGJldHRlci48YnI+DQo8YnI+ DQpJdCBodXJ0cyBpbnRlcm9wZXJhYmlsaXR5IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgJmd0OyBJIGFsc288YnI+DQom Z3Q7ICZndDsgYXV0b21hdGljYWxseSBnZXQgYSB3YXkgdG8gYW5ub3VuY2Ugd2hhdCBmaWx0ZXJp bmcgbWVjaGFuaXNtcyBhbjxicj4NCiZndDsgJmd0OyBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cy4g U29tZXRoaW5nIGVudGlyZWx5IG9wYXF1ZSBpcyB3ZWxsIGVudGlyZWx5IG9wYXF1ZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBZZXMsIGF1Z21lbnRhdGlvbnMgYXJlIGdvb2QgdGhpbmdzLiZuYnNwOyBX ZSBoYXZlIDE0IG9mIHRoZW0gaW4geWFuZy1wdXNoLiZuYnNwOyAmbmJzcDtUaGUgaXNzdWUgaXMg dGhhdCBuZXcgZmlsdGVyIHR5cGVzIGVhY2ggcmVxdWlyZXMgc2l4IGFkZGl0aW9uYWwgYXVnbWVu dGF0aW9ucy4mbmJzcDsgVGhpcyBtYWtlcyBuZXcgdmVuZG9yIHNwZWNpZmljIGZpbHRlciB0eXBl IGRpZmZpY3VsdCB0byBhZGQsIGV4cG9zZSwgYW5kIGV4cGxhaW4gdG8gM3JkIHBhcnR5IGRldmVs b3BlcnMuDQogVGhpcyBpcyBjb21wbGV4LCBpcyBhIHBsYWNlIHdoZXJlIGVycm9ycyBjb3VsZCBl YXNpbHkgYmUgaW50cm9kdWNlZCwgYW5kIHdpbGwgaW5oaWJpdCBhZG9wdGlvbi48YnI+DQo8YnI+ DQpBbmQgYWxsIHRoaXMgZ29lcyBhd2F5IGlmIHRoZSBmaWx0ZXIgaXMgb3BhcXVlPyBJIGRvdWJ0 IHRoaXMgdmVyeTxicj4NCm11Y2guJm5ic3A7IEhpZGluZyB0aGUgaXNzdWUgZG9lcyBub3QgaGVs cCAzcmQgcGFydCBkZXZlbG9wZXJzLCBpdCBkb2VzIG5vdDxicj4NCmhlbHAgaW50ZXJvcGVyYWJp bGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VXNpbmcgYW55ZGF0YSBpbnN0ZWFkIG9mIHJlYWwgWUFORyBkYXRhIG5vZGVz IGlzIHRoZSB3b3JzdCB0aGluZyBwb3NzaWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIGEgM3JkLXBhcnR5IGNsaWVudCBkZXZlbG9wZXIu Jm5ic3A7IEl0IG1ha2VzIFlBTkcgYXV0b21hdGlvbiBpbXBvc3NpYmxlLCBub3QganVzdCBoYXJk ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z QU5HIGNvbXBpbGVycyBoYXZlIG5vIHByb2JsZW0gc29ydGluZyBvdXQgc3RhdGVtZW50cyBmcm9t IG11bHRpcGxlIGZpbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MTQgdGhpbmdzIG1heSBiZSBhIGxvdCBmb3IgaHVtYW5zIHRvIHJlYWQsIGJ1 dCBub3QgZm9yIGEgWUFORyBjb21waWxlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVtb3ZpbmcgdGhlIGZpbHRlciBzcGVjaWZp Y2F0aW9uIGZyb20gdGhlIHN0YW5kYXJkIGRvZXMgbm90IGhlbHAgY2xpZW50PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXZlbG9wZXJzIHdyaXRp bmcgY29kZSB0byB1c2UgJm5ic3A7YSBmaWx0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFu IGNsYXNzPSJob2VuemIiPi9qczwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJob2VuemIiPlBob25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy bWFueTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5GYXg6Jm5ic3A7ICZuYnNwOyYj NDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8 L3NwYW4+PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2E+PHNwYW4g Y2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZndDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0i aG9lbnpiIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5OZXRjb25mIG1haWxpbmcgbGlzdDwvc3Bh bj48YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZA aWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjwvc3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_e6378a66672b43f489c9815e0dd1d626XCHRTP013ciscocom_-- From nobody Mon Sep 25 14:51:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244081345C3 for ; Mon, 25 Sep 2017 14:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eleeYZS4TqpP for ; Mon, 25 Sep 2017 14:51:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880F313202D for ; Mon, 25 Sep 2017 14:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5034; q=dns/txt; s=iport; t=1506376303; x=1507585903; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DQtKgniPYdEcony3K/a4WrLtt/2hG1v3GvlG2h2xwTA=; b=fgDN8l0zWyhyHAB6UMMYSbxXverRUZdyuBRUh1ypm1H6o60fAAwKaUXp Wf9MsrO0CjUHyEwm0IcWLRHMpZMgBWT96j18tjwIPlkIQOzBd8x+VQs5i nzj1sEKDEvTtCK6FokkV7XZfDpYcjKZRd8PVYbpOcy2DwSo1MBvs6I0d6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQAYeslZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG4nB6ABkGyFPoISCoU7AoQ3QBcBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBLUwFCwIBCA4HDwEaBzIUEQIEDgUIiUdcCKo/ix8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyuCAoFRhQ+KdgWhHwKUUZMPlRkCERkBgTgBIAE2gQ54FYdmdol?= =?us-ascii?q?IgRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208,217";a="289475297" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 21:51:17 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8PLpGru030161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 21:51:17 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 17:51:16 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 17:51:16 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNglTsFoIhismq06+Nfgq5lEDuqLFtEfwgABp/ID//75nUA== Date: Mon, 25 Sep 2017 21:51:16 +0000 Message-ID: References: <20170925.161745.619992510057596315.mbj@tail-f.com> <20170925.192803.763609160917048321.mbj@tail-f.com> In-Reply-To: <20170925.192803.763609160917048321.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_c8418dbe4b8240acb79f727be39b608dXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:51:45 -0000 --_000_c8418dbe4b8240acb79f727be39b608dXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, Based on the parallel thread, most of the questions below are not open anym= ore. Therefore I only pick out the one question you asked completely spec= ific to yang-push.... > From: Martin Bjorklund, September 25, 2017 1:28 PM > > >"Eric Voit (evoit)" > wrote: > > > > notification: subscription-modified > > Why is this one needed? Isn't one of the ideas with yang push that we > won't need special notifications for config changes? Wouldn't you > use yang-push to subscribe to the subscription config, if you want to get= this > info? It is certainly possible to subscribe to subscription config. But you like= ly don't have the permissions for this when using configured/static subscri= ptions. The notification subscription-modified allows the receiver know th= e exact terms of the subscription if there is a policy transition. Eric --_000_c8418dbe4b8240acb79f727be39b608dXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

Based on the parallel thread, most of the questio= ns below are not open anymore.   Therefore I only pick out the on= e question you asked completely specific to yang-push....

 

> From: Martin Bjorklund, September 25, 2017 1= :28 PM

>

> >"Eric Voit (evoit)" <evoit@cisco.com> wrote:

> >

> > notification: subscription-modified

>

> Why is this one needed?  Isn't one of t= he ideas with yang push that we

> won't need special notifications for config = changes?   Wouldn't you

> use yang-push to subscribe to the subscripti= on config, if you want to get this

> info?

 

It is certainly possi= ble to subscribe to subscription config.  But you likely don't have th= e permissions for this when using configured/static subscriptions.  Th= e notification subscription-modified allows the receiver know the exact terms of the subscription if there is a policy tra= nsition.

 

Eric

--_000_c8418dbe4b8240acb79f727be39b608dXCHRTP013ciscocom_-- From nobody Mon Sep 25 18:45:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C52132D18 for ; Mon, 25 Sep 2017 18:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms8itTW1ynRi for ; Mon, 25 Sep 2017 18:45:18 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A323813214D for ; Mon, 25 Sep 2017 18:45:18 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id u18so5071163pgo.0 for ; Mon, 25 Sep 2017 18:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=ALMgkCbWvaPiZffLB9c3jl26dxcAQ6v/th1vMZGTs8g=; b=R0qj9CkRUc2rKh8elTRN4csjORA2e9Y2NigLXVaMqbNT/Ow+catfNWj/HTHmWWFgs8 ym1czTQ3hiEWKMbg1m2c0l0dvd+LURhcUarNr71fx1o3AmhU7vHKnrAGPEIR7xq3M9Of QRuTUMF7+suALQhtlzqViEGihVXuSRldQqyP98lAHHiqWbQl1/2BBog+lobqwD4ppXPA u+bmCBry0BozDdRRYQCxJet9kOeMhbROvQ9OA09LvVWGF+dkaPesXTb8WinxbwWrc6YW vYyTLR835aYarL+lyp86KrxZKYTcDwig0xY8qGIgDGjiK9pRHlzdhTuwSa/YrpuL1gY5 9sGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=ALMgkCbWvaPiZffLB9c3jl26dxcAQ6v/th1vMZGTs8g=; b=dwlRvwTiEWUPp9E/5F4eyN7oEt4jV7WcQKB20l2kdqk41XyD/99ugPck0L5OtE7nvs qZipwWYfpUTLm/jh5c5zc0C91iK3YkZCL98J2xAoo8jhecWJl9ZPXR6W9xW6IFw75eQf otS57A4F6CtjTcoPDdUYdsww5OXGAG+sTDGdh7xadru5MsclvCq4Kt1C9rhR9G+dovVI 5ttsEJVsUDygwxvOUkOgdsoF3X+IILNVc0E8JUGU4Vav9alffoy0OqQo35xsJlWgcr/e PSs+XVWJZ+PIPoIf+UHIr5JadbNh4XiM7ioUyYrT0XtpvEi2NQOU+Ir+uBqQHAx1piaN 3ttw== X-Gm-Message-State: AHPjjUi2u81yjMBUT6TBs/+hlP/tK3r1Lc/zM3DpBHMGpEEYArZjwPsx oAUmRJtzz3V4l8lRkJ4hXopBj75s X-Google-Smtp-Source: AOwi7QBmD+Og0tDAeJLAJAvrvUOdqOLXyZZi3Zjo53q46c3ZIXpKZ7xxLId2bgIrl4a/gyLOGk1UAA== X-Received: by 10.99.114.20 with SMTP id n20mr9375977pgc.448.1506390318030; Mon, 25 Sep 2017 18:45:18 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:65b7:9fab:cfca:b3ab? ([2001:420:30d:1320:65b7:9fab:cfca:b3ab]) by smtp.gmail.com with ESMTPSA id 75sm13533050pfx.145.2017.09.25.18.45.17 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Sep 2017 18:45:17 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_ED62F622-6DC7-419D-BE79-25E5040306FE" Message-Id: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> Date: Mon, 25 Sep 2017 18:45:17 -0700 To: netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] WG LC for zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 01:45:20 -0000 --Apple-Mail=_ED62F622-6DC7-419D-BE79-25E5040306FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The last round of WG LC on Zerotouch draft = resulted = in lot comments being posted about the draft. Kent has since then = updated the document to address all those comments and posted -17 = version of the draft. We believe the document is now ready for a re-run of that call. This = starts a two-week WG LC on the draft. Please indicate your support if = you believe the document is now ready for LC. We need affirmation of = support for the LC to succeed. Unfortunately, silence is not = affirmation. If you believe the document is still not ready, please = indicate why. The LC will conclude on Oct. 9. Authors, please indicate if you are aware of any IPRs related to the = document. Also, please indicate if there are any known implementations = of the draft. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_ED62F622-6DC7-419D-BE79-25E5040306FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The last round of WG LC on Zerotouch draft resulted in lot comments being = posted about the draft. Kent has since then updated the document to = address all those comments and posted -17 version of the draft.

We believe the document = is now ready for a re-run of that call. This starts a two-week WG LC on = the draft. Please indicate your support if you believe the document is = now ready for LC. We need affirmation of support for the LC to succeed. = Unfortunately, silence is not affirmation. If you believe the document = is still not ready, please indicate why. The LC will conclude on Oct. = 9.

Authors, = please indicate if you are aware of any IPRs related to the document. = Also, please indicate if there are any known implementations of the = draft.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_ED62F622-6DC7-419D-BE79-25E5040306FE-- From nobody Mon Sep 25 19:27:58 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F41134641 for ; Mon, 25 Sep 2017 19:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3n8AAc2HxeA for ; Mon, 25 Sep 2017 19:27:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4181C13463C for ; Mon, 25 Sep 2017 19:27:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWF40035; Tue, 26 Sep 2017 02:27:48 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 03:27:46 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Tue, 26 Sep 2017 10:27:43 +0800 From: wangzitao To: Mahesh Jethanandani , netconf Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AdM2a9P1ZFrQXkWWTg6QrpGR+s5scg== Date: Tue, 26 Sep 2017 02:27:42 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.152] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC17A8DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59C9BB24.0128, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c930c112c1fa38a323930b2219d1a345 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 02:27:56 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC17A8DGGEMM506MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV0csDQpJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyB3b3JrLiBBbmQgSSBoYXZlIHNvbWUg Y29tbWVudHM6DQoNCqGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGt oa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2hraGtoa2h raGtoa2hraGtoa2hraGtoa2hraGtoa2hrS4uDQogICAgICAgICBjb250YWluZXIgd2hlcmUgew0K ICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICJGaWx0ZXIgY29udGVudCB3aXRo IHRoZSBzcGVjaWZpZWQgY3JpdGVyaWEuICBBbGwgZ2l2ZW4NCiAgICAgICAgICAgICAgY3JpdGVy aWEgYXJlIGxvZ2ljYWxseSBBTkQ6ZWQuIjsNCg0KICAgICAgICAgICBsZWFmIGNvbmZpZyB7DQog ICAgICAgICAgICAgdHlwZSBib29sZWFuOw0KICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAg ICAgICAgICAgICAiRmlsdGVyIGZvciBub2RlcyB3aXRoIHRoZSBnaXZlbiB2YWx1ZSBmb3IgdGhl aXINCiAgICAgICAgICAgICAgICAnY29uZmlnJyBwcm9wZXJ0eS4iOw0KICAgICAgICAgICB9DQo8 TWljaGFlbD46IEhlcmUgZGVmaW5lZCBjb25maWcgdHJ1dGgvZmFsc2UgYXMgYSBmaWx0ZXKhr3Mg Y3JpdGVyaWEuIEFjY29yZGluZyB0byBOTURBIHJldmlzZWQgZGF0YXN0b3JlLCB0aGVyZSBhcmUg Zm91ciB0eXBlIChjdCA9IGNvbmZpZyB0cnVlOyBjZiA9IGNvbmZpZyBmYWxzZQ0KDQogICAgICAg cncgPSByZWFkLXdyaXRlOyBybyA9IHJlYWQtb25seSkuIFdoeSBub3QgZGVmaW5lIHRoZSChsHJ3 obEgYW5kIKGwcm+hsSBhcyBvdGhlciBjcml0ZXJpYT8NCiAgICAgICAgICAgbGVhZiBvcmlnaW4g ew0KPE1pY2hhZWw+OiB3aHkgbm90IGRlZmluZSBzb21lIKGwd2hlbqGxIHN0YXRlbWVudCBsaWtl OiAgd2hlbiAnZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vc291cmNlLCAib3I6b3BlcmF0aW9uYWwi KSc7Pw0KICAgICAgICAgICAgICAgICAgICAgICBUaGUgoa5vcmlnaW6hrqGvIHNlZW1zIG9ubHkg ZXhpc3Qgd2hlbiByZXRyaWV2aW5nIHRoZSBkYXRhIGluIG9wZXJhdGlvbmFsIGRhdGFzdG9yZS4N CiAgICAgICAgICAgICBpZi1mZWF0dXJlIG9yaWdpbjsNCiAgICAgICAgICAgICB0eXBlIGlkZW50 aXR5cmVmIHsNCiAgICAgICAgICAgICAgIGJhc2Ugb3I6b3JpZ2luOw0KICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgIkZpbHRlciBiYXNlZCBv biAnb3JpZ2luJyBhbm5vdGF0aW9uLiAgQSBub2RlIG1hdGNoZXMgdGhlDQogICAgICAgICAgICAg ICAgZmlsdGVyIGlmIGl0cyAnb3JpZ2luJyBhbm5vdGF0aW9uIGlzIGRlcml2ZWQgZnJvbSBvcg0K ICAgICAgICAgICAgICAgIGVxdWFsIHRvIHRoZSBnaXZlbiBmaWx0ZXIgdmFsdWUuIjsNCiAgICAg ICAgICAgfQ0KICAgICAgICAgfQ0KDQogICAgICAgICBsZWFmIHdpdGgtb3JpZ2luIHsNCiAgICAg ICAgICAgd2hlbiAnZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vc291cmNlLCAib3I6b3BlcmF0aW9u YWwiKSc7DQogICAgICAgICAgIGlmLWZlYXR1cmUgb3JpZ2luOw0KICAgICAgICAgICB0eXBlIGJv b2xlYW47DQogICAgICAgICAgIGRlZmF1bHQgZmFsc2U7DQogICAgICAgICAgIGRlc2NyaXB0aW9u DQogICAgICAgICAgICAgIklmIHRoaXMgcGFyYW1ldGVyIGlzICd0cnVlJywgdGhlIHNlcnZlciB3 aWxsIHJldHVybg0KICAgICAgICAgICAgICB0aGUgJ29yaWdpbicgYW5ub3RhdGlvbiBmb3IgdGhl IG5vZGVzIHRoYXQgaGFzIG9uZS4iOw0KICAgICAgICAgfQ0KDQpCZXN0IFJlZ2FyZHMhDQotTWlj aGFlbA0KDQq3orz+yMs6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gTWFoZXNoIEpldGhhbmFuZGFuaQ0Kt6LLzcqxvOQ6IDIwMTfE6jnUwjI0yNUgMTM6MTgN CsrVvP7IyzogbmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NCtb3zOI6IFtOZXRjb25mXSBXRyBh ZG9wdGlvbiBvZiBORVRDT05GIE5ETUEgZHJhZnQNCg0KVGhlIE5FVENPTkYgTkRNQSBkcmFmdCB3 YXMgcHJlc2VudGVkIGFuIGRpc2N1c3NlZCBpbiBJRVRGIDk5IGluIFByYWd1ZS4gVGhlIGF1dGhv cnMgYWdyZWVkIHRvIHByb3ZpZGUgYW4gdXBkYXRlLCB3aGljaCB0aGV5IGRpZCB3aXRoIC0wMSB2 ZXJzaW9uIG9mIHRoZSBkcmFmdC4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMg cmVhZHkgZm9yIFdHIGFkb3B0aW9uLg0KDQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrIGNhbGwgdG8g YWRvcHQgTkVUQ09ORiBORE1BIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQuIFNpbmNlIHRoZSBmb2N1 cyBvZiB0aGUgZHJhZnQgaXMgTkRNQSBjb21wbGlhbmNlLCBpdCBmYWxscyB3aXRoaW4gdGhlIGNo YXJ0ZXIgb2YgdGhlIFdHLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNk dC1ubWRhLW5ldGNvbmYtMDENCg0KUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHRoaW5rIHRo aXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBpdGVtLiBJZiB5b3UgaGF2ZSBvYmpl Y3Rpb25zIHRvIGl0IGJlaW5nIGFkb3B0ZWQsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgYnkg cmVzcG9uZGluZyBvbiB0aGlzIHRocmVhZC4NCg0KVGhhbmtzLg0KDQpNYWhlc2ggSmV0aGFuYW5k YW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5j b20+DQoNCg0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC17A8DGGEMM506MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi WG,

I support adoption of this work. And = I have some comments:

 

=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1= =AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD= =A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1= =AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD= =A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD=A1= =AD=A1=AD=A1=AD=A1=AD=A1=AD=A1=AD..

       &nbs= p; container where {

       &nbs= p;   description

       &nbs= p;     "Filter content with the specified criteria= .  All given

       &nbs= p;      criteria are logically AND:ed.";=

 

       &nbs= p;   leaf config {

       &nbs= p;     type boolean;

       &nbs= p;     description

       &nbs= p;       "Filter for nodes with the give= n value for their

       &nbs= p;        'config' property.";=

       &nbs= p;   }

<Michael>: Here defined config truth/false as a filter=A1=AFs cr= iteria. According to NMDA revised datastore, there are four type (ct =3D co= nfig true; cf =3D config false

       rw =3D read-write;=
 ro =3D read-only). Why not define the =A1=B0rw=A1=B1 and =A1=B0ro=A1=B1 as=
 other criteria?

       &nbs= p;   leaf origin {

<Michael>: why not define some = =A1=B0when=A1=B1 statement like:  w= hen 'derived-from-or-self(../source, "or:operational")';?      &= nbsp;           &nbs= p;    The =A1=AEorigin=A1=AE=A1=AF seems only exist when ret= rieving the data in operational datastore.

       &nbs= p;     if-feature origin;

       &nbs= p;     type identityref {

       &nbs= p;       base or:origin;

       &nbs= p;     }

       &nbs= p;     description

       &nbs= p;       "Filter based on 'origin' annot= ation.  A node matches the

       &nbs= p;        filter if its 'origin' annotat= ion is derived from or

       &nbs= p;        equal to the given filter valu= e.";

       &nbs= p;   }

       &nbs= p; }

 

       &nbs= p; leaf with-origin {

       &nbs= p;   when 'derived-from-or-self(../source, "or:operational&q= uot;)';

       &nbs= p;   if-feature origin;

       &nbs= p;   type boolean;

       &nbs= p;   default false;

       &nbs= p;   description

       &nbs= p;     "If this parameter is 'true', the server wi= ll return

       &nbs= p;      the 'origin' annotation for the nodes that= has one.";

       &nbs= p; }

 

Best Regards!

-Michael

 

=B7=A2=BC=FE=C8= =CB: Netconf [mailto:netconf-bounces@ietf.org] =B4=FA=B1=ED Mahesh Jethanandani
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA9=D4=C224=C8=D5 13:18
=CA=D5=BC=FE=C8=CB: netconf <netconf@= ietf.org>
=D6=F7=CC=E2: [Netconf] WG adoption of N= ETCONF NDMA draft

 

The NETCONF NDMA draft was presented an discussed in= IETF 99 in Prague. The authors agreed to provide an update, which they did= with -01 version of the draft. The authors believe the document is ready f= or WG adoption.

 

This starts a two week call to adopt NETCONF NDMA dr= aft as a WG document. Since the focus of the draft is NDMA compliance, it f= alls within the charter of the WG.

 

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01

 

Please indicate whether you think this draft should = be adopted as a WG item. If you have objections to it being adopted, please= state your reasons by responding on this thread.

 

Thanks.

 

Mahesh Jethanandani

 

 

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC17A8DGGEMM506MBXchi_-- From nobody Mon Sep 25 23:15:13 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38691321F5 for ; Mon, 25 Sep 2017 23:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbxcOVGUB7eN for ; Mon, 25 Sep 2017 23:15:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9143D1321C9 for ; Mon, 25 Sep 2017 23:15:07 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FEDE1AE018C; Tue, 26 Sep 2017 08:15:05 +0200 (CEST) Date: Tue, 26 Sep 2017 08:17:32 +0200 (CEST) Message-Id: <20170926.081732.1052294124211547008.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170925.192803.763609160917048321.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] subscription-modified [Was: WG adoption of NETCONF NDMA draft] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 06:15:12 -0000 "Eric Voit (evoit)" wrote: > Hi Martin, > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > >"Eric Voit (evoit)" > wrote: > > > > > > > > notification: subscription-modified > > > > > > Why is this one needed? Isn't one of the ideas with yang push that we > > > won't need special notifications for config changes? Wouldn't you > > > use yang-push to subscribe to the subscription config, if you want to > > get this > > > info? > > > > It is certainly possible to subscribe to subscription config. But you > likely don't have the permissions for this when using > configured/static subscriptions. Why do you think that? Why is the subscription config different from any other config? If we end up with a multitude of specialized xxx-modified notifications, what is then the value of yang push? /martin From nobody Tue Sep 26 00:23:39 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D995F132620 for ; Tue, 26 Sep 2017 00:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hBs0KAdIHrY for ; Tue, 26 Sep 2017 00:23:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECC7132355 for ; Tue, 26 Sep 2017 00:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1529; q=dns/txt; s=iport; t=1506410617; x=1507620217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gkMhCReUwbmpVtL8jED+9vNPm1sxx0Jx5VBXeyHi0ms=; b=bVse1cvMDbEJxEMz3zUHWcgxpwPzxM0A/KBeOUy7R7xRTvzLai9OtYTJ sI/fy6Ef8LiDcDytmC2dPKAtX/DSyPEQMN+pEU51uDUQZX3kbENwl6eX1 +gLvYgpw0E+Ybi4IrAOUEEoAlQihx7GQQoafjRFUP9pITHxgcqsK/Wbvq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQAKAMpZ/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHoACWKoISCoU7AoQ9QBcBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BOj8FCwIBCA4HAgEMAREJBzIUCQgCBA4FCIojCKpKiyEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyuCAoFRhRKKdwWYTYhTApRSkw+VGgIRGQGBOAEgATaBDngVh2Z?= =?us-ascii?q?2h1iBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,440,1500940800"; d="scan'208";a="299981074" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 07:23:36 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8Q7Na80016597 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 07:23:36 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 03:23:35 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 26 Sep 2017 03:23:35 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: subscription-modified [Was: WG adoption of NETCONF NDMA draft] Thread-Index: AQHTNo7Nx3+b3kVvdka1SgM+ciHDMqLGwigQ Date: Tue, 26 Sep 2017 07:23:35 +0000 Message-ID: <50c46f0026ed4a9f89995d82f0b090e0@XCH-RTP-013.cisco.com> References: <20170925.192803.763609160917048321.mbj@tail-f.com> <20170926.081732.1052294124211547008.mbj@tail-f.com> In-Reply-To: <20170926.081732.1052294124211547008.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] subscription-modified [Was: WG adoption of NETCONF NDMA draft] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:23:39 -0000 > From: Martin Bjorklund, September 26, 2017 2:18 AM > Subject: subscription-modified [Was: WG adoption of NETCONF NDMA draft] >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > > > > > >"Eric Voit (evoit)" > wrote: > > > > > > > > > > > > notification: subscription-modified > > > > > > > > > > Why is this one needed? Isn't one of the ideas with yang push that > > > we > > > > > won't need special notifications for config changes? Wouldn't you > > > > > use yang-push to subscribe to the subscription config, if you want > > > to get this > > > > > info? > > > > > > > > It is certainly possible to subscribe to subscription config. But you > > likely don't have the permissions for this when using > > configured/static subscriptions. >=20 > Why do you think that? Why is the subscription config different from any= other > config? If we end up with a multitude of specialized xxx-modified notifi= cations, > what is then the value of yang push? Promise theory. When someone establishes the subscription via config, you forward to the re= ceiver the set of criteria you are trying to fulfil. If someone changes the subscription, you let them know the new set of crite= ria that you are trying to fulfil. Without this notification in the middle, you don't know the rules under whi= ch the updates are being sent. Eric > /martin From nobody Tue Sep 26 00:44:26 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B14D13209C for ; Tue, 26 Sep 2017 00:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie7bx7GKuOoE for ; Tue, 26 Sep 2017 00:44:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA212426E for ; Tue, 26 Sep 2017 00:44:23 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 89AE01AE018C; Tue, 26 Sep 2017 09:44:21 +0200 (CEST) Date: Tue, 26 Sep 2017 09:46:49 +0200 (CEST) Message-Id: <20170926.094649.1193359387861348510.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <50c46f0026ed4a9f89995d82f0b090e0@XCH-RTP-013.cisco.com> References: <20170926.081732.1052294124211547008.mbj@tail-f.com> <50c46f0026ed4a9f89995d82f0b090e0@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] subscription-modified X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:44:24 -0000 "Eric Voit (evoit)" wrote: > > From: Martin Bjorklund, September 26, 2017 2:18 AM > > Subject: subscription-modified [Was: WG adoption of NETCONF NDMA > > draft] > > > > "Eric Voit (evoit)" wrote: > > > Hi Martin, > > > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > > > > > > > > > >"Eric Voit (evoit)" > wrote: > > > > > > > > > > > > > > > > notification: subscription-modified > > > > > > > > > > > > > > Why is this one needed? Isn't one of the ideas with yang push that > > > > we > > > > > > > won't need special notifications for config changes? Wouldn't you > > > > > > > use yang-push to subscribe to the subscription config, if you want > > > > to get this > > > > > > > info? > > > > > > > > > > > > It is certainly possible to subscribe to subscription config. But you > > > likely don't have the permissions for this when using > > > configured/static subscriptions. > > > > Why do you think that? I don't think you answered this one. To be clear, let me rephrase my question: Why do you think that the client won't have the permissions for receiving yang push notifications when using configured/static subscriptions? > > Why is the subscription config different from > > any other > > config? If we end up with a multitude of specialized xxx-modified > > notifications, > > what is then the value of yang push? > > Promise theory. > > When someone establishes the subscription via config, you forward to > the receiver the set of criteria you are trying to fulfil. I'm sorry but I don't follow. I see "someone", "receiver" and "you". Can you rephrase using the terms "client A", "client B" and "server" (assuming multiple clients are involved). Also, can you explain what "forward to the receiver" means, in concrete terms? > If someone changes the subscription, you let them know the new set of > criteria that you are trying to fulfil. Again, why can't I use yang push to get a notification when my subscription is modified? > Without this notification in the middle, you don't know the rules > under which the updates are being sent. /martin From nobody Tue Sep 26 01:10:26 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72AE128D0D for ; Tue, 26 Sep 2017 01:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtlDh9Lbo3Yx for ; Tue, 26 Sep 2017 01:10:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B321270AB for ; Tue, 26 Sep 2017 01:10:22 -0700 (PDT) Received: from birdie6 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 34F1C62337; Tue, 26 Sep 2017 10:10:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1506413420; bh=a6F8VQE3v/RygJuwFUO9CrBQ9LVTFdNWu5+8DDn1fl0=; h=From:To:Date; b=sLpLOaJ4M5mRR/LVScZPUGsUlQPRda6m+0xo8OGbAj7DTuOEKNykEXr8t2a67uU1W +e2MfPmqvW6KXQodj6tySAepCh8kDlbxdhRfTtCi+IHBAan++ITbmqlphdPnnKHju1 cNu9BV00iCcSpAigfluiAqZnfBHhL8D9e4sq0PIg= Message-ID: <1506413462.8691.12.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , Martin Bjorklund Cc: netconf@ietf.org Date: Tue, 26 Sep 2017 10:11:02 +0200 In-Reply-To: References: <54b127dd-a53b-60ca-4b0c-ad7f07c6d553@cisco.com> <20170915.104811.2023692176220307321.mbj@tail-f.com> <87r2uyzrkn.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Netconf] RESTCONF timestamp and entity-tag for "default" resources X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:10:25 -0000 Robert Wilton píše v Po 25. 09. 2017 v 16:08 +0100: > > On 22/09/2017 16:22, Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Robert Wilton wrote: > > > > Hi Kent, > > > > > > > > Thanks for the suggestion. > > > > > > > > I think that your solution works if the implementation instantiates an > > > > an actual leaf to represent the default value, but I'm not sure that > > > > is meant to be required. Without this "Last-Modified" requirement an > > > > implementation could implicitly instantiate default values from the > > > > schema when required (e.g. for validation) but not necessarily > > > > explicitly store them. > > > > > > > > But from my reading of RESTCONF section 3.5, the two choices seem to > > > > be either: > > > > > > > > (i) the device has to store the timestamp of when the default value > > > > took effect (e.g. the last time it was implicitly instantiated for > > > > whatever reason). > > > > > > > > (ii) the device could return the datastore timestamp for the > > > > implicitly created default node. But I'm not sure how meaningful that > > > > is if the device also chooses to return accurate last modified > > > > timestamps for explicitly configured nodes. If an implementation was > > > > to do this then you could easily have a scenario where an implicitly > > > > created child node has a later timestamp than its parent node, which > > > > doesn't seem to to be good. > > > > > > > > So, perhaps the conclusion is: if you want to return accurate > > > > timestamps for explicitly created nodes, then it is necessary to also > > > > maintain accurate timestamps for implicitly created default nodes as > > > > well? > > > > > > IMO this is all implementation details. One implementation might > > > instantiate all defaults, while another comes up with some other > > > clever mechanism to avoid redundant storage. The spec should clearly > > > define the semantics associated with the timestamp, and not talk about > > > how it must be implemented. > > > > I think it would be better and simpler to adhere to the semantics that is > > defined for each header field in HTTP specs. > > > > For Last-Modified it is section 2.2 in RFC 7232: > > > > The "Last-Modified" header field in a response provides a timestamp > > indicating the date and time at which the origin server believes the > > selected representation was last modified, ... > > > > So I think Kent's conclusion is correct: the representation was last > > modified when the resource was (conceptually) created, which was at the > > time of parent container creation. > > I don't think that this is necessarily true. The default value may get > "created" if an explicitly configured value for the leaf is removed/deleted. Yes, but this is a later step: - If the parent container is created without that leaf and the default value is returned, it should have the same timestamp as the parent container. - If the leaf is edited with a value that is different from the default, the timestamp of the leaf and its ancestors should be bumped. - If the leaf is then removed so that the default value is back in use, the timestamp should be bumped again. Lada > > So, i think that it is required to explicitly track the timestamp of > when the default node logically came into existence, i.e. the same as > for any other explicitly configured node. > > > > > ETag is also quite interesting (sec. 2.3): > > > > An entity-tag is an opaque validator for differentiating between > > multiple representations of the same resource, regardless of whether > > those multiple representations are due to resource state changes over > > time, content negotiation resulting in multiple representations being > > valid at the same time, or both. > > > > As I understand it, if an otherwise unmodified resource (e.g. a > > container instance) is represented once with defaults and another time > > without defaults, the two representations should have different ETags. > > Yes, I would think so. > > Thanks, > Rob > > > > > Lada > > > > > > > > > > /martin > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 14/09/2017 16:05, Kent Watsen wrote: > > > > > The default value node was implicitly instantiated when the parent > > > > > node was created, so I'd set its Last-Modified value to that value. > > > > > > > > > > K. // contributor > > > > > > > > > > > > > > > -- > > > > > > > > > > Hi, > > > > > > > > > > If I make a RESTCONF GET request with a path to a data resource that > > > > > doesn't exist, but has an in scope schema default value, and I'm using > > > > > one of the with-defaults options that means that the default value is > > > > > returned, then what value is the "Last-Modified" header expected or > > > > > required to take? > > > > > > > > > > Specifically, I am thinking of a device that uses per data resource > > > > > timestamps for all explicitly configured data resources rather than > > > > > having a single top level datastore resource timestamp. > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Sep 26 01:20:29 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4D1321AC for ; Tue, 26 Sep 2017 01:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCP9nUlE7Jsy for ; Tue, 26 Sep 2017 01:20:26 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD94126B6D for ; Tue, 26 Sep 2017 01:20:26 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m127so4958921wmm.3 for ; Tue, 26 Sep 2017 01:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AbWDs42EsrUeqM4DyVF12gYr0bAJBhp2pGyXdiehlQ0=; b=u2iDGO7zR9f/AUXiUwaakhDTpzXVfAhjJrPvw0afbsD4plFNiv7KhhjAMbLW8mWy1u YO877aF6utg8hu7sEjZ8isz87BaJwwP5qgtUEqEeaEbiMso/yr3qJ+33FxDph6k19zib +QNLq85omtXZJ8Z+j8Ot8yJvG+09WMcqPmbYBReaiUvnsppNPGa2F8PspjJlGwSbFdO0 FVADSWwAxNtSw9Ilzt363TvkO1VFi6qSZ9Z/dAj60VbAKuUpAwpyju2hQaAq+XalLYlf boNk+o7o5OOFgHNgC6LvbbpVJ2bnioDkjFrZJV3jlE7Ke+P3Sys8g6Er71QaDwtLMVzj SBxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AbWDs42EsrUeqM4DyVF12gYr0bAJBhp2pGyXdiehlQ0=; b=NnvP0XHpTJ0UEvU2qaUMiXi/qksMR2yZmrfx2OjgEas8J4/vET7CM4FS0TWGqD1834 UsV1Vonz1ShpN6/HrrcVY/94IiReCVRbftTqdbVr+lwbil11I7i19fXrqWdGTiuQWHFd JQhyn1LKBHpQBO4ruh/+/a1K1ZZ6HQb2zRvnBEfqQrwFyzLQH/fIrZZ4yPAcmdJNEOTA QDKcZSmsikvCXJjV3QBcGynjvE7B4WVVN1wGsKmwzg8OpBW5N0oI78nIrsH85uLkKAuN q9HFD8WvsWD8/AAmyKFsDKF77jf7q/F3bSfRNFuJqnuThLkDtLHP0yNka1hG5TBAYxS4 QGWQ== X-Gm-Message-State: AHPjjUgHeV6+FUGnplsuHnITdgVPlysx7CQzJ8IZi9/cxFOquqmfZirr KxAt/NYGzw2qmkbYs53jRIVxeyWF X-Google-Smtp-Source: AOwi7QDociAVXnFo69OHRin4rBy9wzC9o2az0eB3PRsm7Rcw807ckZHdGjsTQsa8mNxFeNXHLuLDqg== X-Received: by 10.28.238.218 with SMTP id j87mr2528550wmi.44.1506414025144; Tue, 26 Sep 2017 01:20:25 -0700 (PDT) Received: from ?IPv6:2001:420:c0c0:1005::1c8? ([2001:420:c0c0:1005::1c8]) by smtp.gmail.com with ESMTPSA id o11sm5166911wrg.5.2017.09.26.01.20.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2017 01:20:24 -0700 (PDT) From: Giles Heron Message-Id: <2421997E-7511-49C4-AA8C-C51F3B28A94F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A461CBEA-2C88-4EAB-A976-B74A41F927A7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 26 Sep 2017 10:20:47 +0200 In-Reply-To: Cc: netconf To: Mahesh Jethanandani References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:20:28 -0000 --Apple-Mail=_A461CBEA-2C88-4EAB-A976-B74A41F927A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii support - looks good to me. > On 24 Sep 2017, at 07:18, Mahesh Jethanandani = wrote: >=20 > The NETCONF NDMA draft was presented an discussed in IETF 99 in = Prague. The authors agreed to provide an update, which they did with -01 = version of the draft. The authors believe the document is ready for WG = adoption. >=20 > This starts a two week call to adopt NETCONF NDMA draft as a WG = document. Since the focus of the draft is NDMA compliance, it falls = within the charter of the WG. >=20 > https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 = >=20 > Please indicate whether you think this draft should be adopted as a WG = item. If you have objections to it being adopted, please state your = reasons by responding on this thread. >=20 > Thanks. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_A461CBEA-2C88-4EAB-A976-B74A41F927A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii support - looks good to me.

On = 24 Sep 2017, at 07:18, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The NETCONF = NDMA draft was presented an discussed in IETF 99 in Prague. The authors = agreed to provide an update, which they did with -01 version of the = draft. The authors believe the document is ready for WG adoption.

This starts a two week = call to adopt NETCONF NDMA draft as a WG document. Since the focus of = the draft is NDMA compliance, it falls within the charter of the WG.

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01

Please = indicate whether you think this draft should be adopted as a WG item. If = you have objections to it being adopted, please state your reasons by = responding on this thread.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



_________________________________= ______________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_A461CBEA-2C88-4EAB-A976-B74A41F927A7-- From nobody Tue Sep 26 02:14:35 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00801326F6 for ; Tue, 26 Sep 2017 02:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p9YRP0z767W for ; Tue, 26 Sep 2017 02:14:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F046213217D for ; Tue, 26 Sep 2017 02:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4779; q=dns/txt; s=iport; t=1506417273; x=1507626873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kG+5JYNW465lZp6KpRu7MfVzapfhX4VFc46JsNrEOlc=; b=A9EJ5EkjUIW6D73z8zXJQ0qI7a8RrZTjfn1js5cB6n93mvVCiqvrjRGD tCSg0ugNVdjTxszkfMy7YC/svyI3TyCPmjsI4T9GrKuY9Muawsr6dhe38 w/QQQUTY+9KGdxLf46wH4hzXUAPkWtEbM2V3FyCC6iGwKmWN3Xf0q7gtm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQCwGcpZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tgVInB6ABmDwKGIUjAoRDVwECAQEBAQECayiFGAEBAQECATo?= =?us-ascii?q?/BQsCAQgOBwIBDAERCQcyFAkIAgQOBQiKIwiqeIshAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEegyuCAoFRhRKEboYJBaEgApRSghyQc4oLiw8CERkBgTgBV4EOeBWHZna?= =?us-ascii?q?GJgUBgSyBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,440,1500940800"; d="scan'208";a="8732065" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 09:14:32 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8Q9EVax029519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 09:14:32 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 05:14:31 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 26 Sep 2017 05:14:31 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: subscription-modified Thread-Index: AQHTNptFSOP8IMSx502sS5y77QP5O6LGzbPA Date: Tue, 26 Sep 2017 09:14:31 +0000 Message-ID: <0c55e9a8324441bba3cce3a60ca5d0af@XCH-RTP-013.cisco.com> References: <20170926.081732.1052294124211547008.mbj@tail-f.com> <50c46f0026ed4a9f89995d82f0b090e0@XCH-RTP-013.cisco.com> <20170926.094649.1193359387861348510.mbj@tail-f.com> In-Reply-To: <20170926.094649.1193359387861348510.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] subscription-modified X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 09:14:34 -0000 > From: Martin Bjorklund, September 26, 2017 3:47 AM >=20 > "Eric Voit (evoit)" wrote: > > > From: Martin Bjorklund, September 26, 2017 2:18 AM > > > Subject: subscription-modified [Was: WG adoption of NETCONF NDMA > > > draft] > > > > > > "Eric Voit (evoit)" wrote: > > > > Hi Martin, > > > > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > > > > > > > > > > > > > >"Eric Voit (evoit)" > wr= ote: > > > > > > > > > > > > > > > > > > > > notification: subscription-modified > > > > > > > > > > > > > > > > > > Why is this one needed? Isn't one of the ideas with yang push > > > > > that we > > > > > > > > > won't need special notifications for config changes? Wouldn't y= ou > > > > > > > > > use yang-push to subscribe to the subscription config, if you > > > > > want to get this > > > > > > > > > info? > > > > > > > > > > > > > > > > It is certainly possible to subscribe to subscription config. But > > > > you likely don't have the permissions for this when using > > > > configured/static subscriptions. > > > > > > Why do you think that? >=20 > I don't think you answered this one. To be clear, let me rephrase my > question: Why do you think that the client won't have the permissions for > receiving yang push notifications when using configured/static subscripti= ons? My statement was that a receiver might not have permissions to subscribe*, = not that it won't have permissions to receive information about the subscri= ption. The modify-subscription notification does have the same elements that would= be received if you also subscribed to the subscription information. And = as a separate type of notification you get several benefits including: (a) A receiver knows immediately that this content is not part of the telem= etry feed originally requested (i.e., no confusion as to why you are getti= ng push-updates which includes content not in the original selection filter= ) (b) The modify-subscription notification may not be dampened or filtered. (c) As it is also possible to explicitly subscribe to the subscription tree= , this separates what otherwise might be overlapping information. *As a side-note: there are many reasons why some receivers won't manage con= figured subscriptions directly... (1) A third party is managing its subscriptions (think controller/NMS drivi= ng a feed towards a data collector/repository) (2) A proxy for IoT devices manages the threads of telemetry information be= ing pushed to devices/receivers (3) A receiver which doesn't have the horsepower to manage subscriptions. = =20 (4) A receiver is in an insecure environment (5) There are many receivers for the same subscription, and they aren't all= owed to impact the others=20 >=20 > > > Why is the subscription config different from any other config? If > > > we end up with a multitude of specialized xxx-modified > > > notifications, what is then the value of yang push? > > > > Promise theory. > > > > When someone establishes the subscription via config, you forward to > > the receiver the set of criteria you are trying to fulfil. >=20 > I'm sorry but I don't follow. I see "someone", "receiver" and "you". > Can you rephrase using the terms "client A", "client B" and "server" > (assuming multiple clients are involved). >=20 > Also, can you explain what "forward to the receiver" means, in concrete t= erms? Using the terms of yang-push, let me try again... When a management interface writes to subscription-config, there is no guar= antee that the configured receiver will be aware of this change. And if th= ey are aware, it will be hard to know for which push-update the change went= into effect unless they get some notification in-line with the push update= s. By pushing the full set of policy rules at any point a subscription is modi= fied, a record is available on the receiver of explicitly which rules which= governed any individual push-update when it was generated. > > If someone changes the subscription, you let them know the new set of > > criteria that you are trying to fulfil. >=20 > Again, why can't I use yang push to get a notification when my subscripti= on is > modified? If you mean why isn't it possible to use a push-update or a push-change-upd= ate to communicate the subscription info in the middle of the configured te= lemetry stream, yes this was a design option considered. But for reasons (= a), (b), & (c) above, it wasn't pursued. Eric > > Without this notification in the middle, you don't know the rules > > under which the updates are being sent. >=20 >=20 > /martin From nobody Tue Sep 26 08:11:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992613330E for ; Tue, 26 Sep 2017 08:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McJEhwGKGDUz for ; Tue, 26 Sep 2017 08:11:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8302D1201F8 for ; Tue, 26 Sep 2017 08:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3423; q=dns/txt; s=iport; t=1506438675; x=1507648275; h=from:to:cc:subject:date:message-id:mime-version; bh=TsH0Rl0OMWS457WeVYYkM8njuaa/+1xMLa7YgQJRyuw=; b=UnE2blf+Ajyjskapkfw/p52LIvcUDyRdFOpPvWEuYsk7h6piCTUqX2uB Veq1Bwy0YzuRncipU04Xe4A3mafbzhV8bjv6uCJiyWuKEx7xBx09Fv+fJ l6yivoW2GqlMPjupJuQQYEuMPDw7xOEUpxFIWZgFfFU41z0ZvBq5du0d5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAACtbcpZ/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9sZG4ujg6PfJJihT6CEgqFO4RPPxgBAgEBAQEBAQFrKIVMTBI?= =?us-ascii?q?BDApqJgEEDg2JRmSqVYseAQEBAQEBAQECAQEBAQEBAQEBAR6DK4ICgVGBao4fB?= =?us-ascii?q?aEgApRSkw+VGgIRGQGBOAEfOIEOeBWHZophgRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="scan'208,217";a="298013690" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2017 15:11:14 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v8QFBEMU032750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 15:11:14 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 11:11:13 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 26 Sep 2017 11:11:13 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: netconf Thread-Topic: Netconf NMDA: Default datastore for rpc get-data? Thread-Index: AdM22a8nrlV6JMuQRSayfqCV03EDAg== Date: Tue, 26 Sep 2017 15:11:13 +0000 Message-ID: <157194c0acce4c04aa3c335a8d65b510@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_157194c0acce4c04aa3c335a8d65b510XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Netconf NMDA: Default datastore for rpc get-data? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 15:11:21 -0000 --_000_157194c0acce4c04aa3c335a8d65b510XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, I see you have mandatory instead of default for your source datastore of th= e rpc get-data. What do you think about having the default of "operational= " in place so that all queries need not specify this? Eric --_000_157194c0acce4c04aa3c335a8d65b510XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

I see you have mandatory instead of d= efault for your source datastore of the rpc get-data.  What do you thi= nk about having the default of “operational” in place so that all queries need not specify this?

 

Eric

--_000_157194c0acce4c04aa3c335a8d65b510XCHRTP013ciscocom_-- From nobody Tue Sep 26 08:48:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B32313301F for ; Tue, 26 Sep 2017 08:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-U57Y5sca-9 for ; Tue, 26 Sep 2017 08:47:57 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A17B128D0D for ; Tue, 26 Sep 2017 08:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rw9pulieniNSljn8/zEZtigV2pJUpSSxJUJDaXiOaGQ=; b=DUngKgz7AwxneF60zIFrOCCRpsAFzVI6LTYIvLigRIIOvs7cag2k6LcqxkFKU0anf7nCvyPU5KX7ZaLDrqWcy4XR2kilNjpoGVAzN11nZnsOEoBbQC1eGt1hDRsFaFG2+stYQJXJ+qG5ftHmEQMbNytARm2TGwR4roFxqEizil8= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 26 Sep 2017 15:47:55 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 26 Sep 2017 15:47:56 +0000 From: Kent Watsen To: Giles Heron , Mahesh Jethanandani CC: netconf Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNPSVb+GtFzEhjEqLinPQDJERyKLG1syAgAA54AA= Date: Tue, 26 Sep 2017 15:47:55 +0000 Message-ID: <3C61A3FD-DFD9-444A-89D5-580ADDB27DEC@juniper.net> References: <2421997E-7511-49C4-AA8C-C51F3B28A94F@gmail.com> In-Reply-To: <2421997E-7511-49C4-AA8C-C51F3B28A94F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:ooDpuGDFHlx4JmYi2VtVJdLA8tXLRE9RoHUKd9WT0SfQ4ijTAUcE56yDcLrjIpEVxYxcw1aQ/HWmhUC7ANLgiN/XdUuLaYXqdEg175U0zdYfXC4YLLJA/PzYgsiEO2KvN5lGXLas5ZOtgm+Daq/rnuCssC6NzD8F5WchxNiV3Qvo0Ql56qeCk5+zLHCksDvvv0zSWbFvXun5d8hI/LL4YWVFeCCiLm9XVE+ZPLQnTQG383E6Wo7TeXuw2dOMvFfI+QtgL+l5tdzNTmdfvAamGs0xDi6QwMNTArYabiXm8iNEQVzDQUgj6rHywgiA74H4/IIqJDY+OYb7g6uBXl+9KQ==; 5:a6LZkswCYlo904i5mX+pYW9rYd3mEEYndrHRmV11WYNLToLpZl5/XrPo7zm0sUQUVzXS5DoInVj4vr6hiKvqpDoRqa1pGmWKH0wK3Hg2dWekQK6IkUXfrP4AVJjjjn3O+KuRtAnl1YbGOu+PtakmOQ==; 24:/+CdcGH/FbtsFz4R8vCJE9GEUB2IPxOVMA2ina4o3jKNHOjvMvrKWJTjTCsuoGF66FcN7bxRe6dgSeKqTIoX5jB2pGuol0Yk8u1+3redwMA=; 7:XEExzX1zEyBfoVczlsiJf1EhZAZsapLcaHj0c1v7oCCaiR+R10QCgGaCSTd4NHBM246xudQ4LVj+lq+M4F9UZXzysTFTkLSaEY7qrRjyUgTMm3jiKF4WnGgEWL4JNmzAn0A1ZYfZ0HaIqkDf6qFYMdoUYXybKh+T479JL1yXJa3n4Zkl/E7fyvjdMElWAVIjweKr9lWPHYfQzgrhLTtMRoWras3J0E/IfE3umL3Xc1g= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fbd2ec5f-1bf8-41cc-9010-08d504f5f4a4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB276; x-ms-traffictypediagnostic: BLUPR05MB276: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:(10436049006162)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB276; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(377454003)(189002)(24454002)(199003)(36756003)(77096006)(25786009)(2950100002)(82746002)(3846002)(102836003)(58126008)(2906002)(83716003)(68736007)(3280700002)(83506001)(86362001)(81166006)(81156014)(14454004)(3660700001)(6436002)(53936002)(478600001)(8676002)(966005)(6246003)(39060400002)(7736002)(66066001)(54356999)(6486002)(106356001)(76176999)(97736004)(99286003)(5660300001)(316002)(189998001)(101416001)(50986999)(33656002)(606006)(236005)(6116002)(2900100001)(110136005)(105586002)(53546010)(4326008)(6306002)(6512007)(6506006)(229853002)(54896002)(8936002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3C61A3FDDFD9444A89D5580ADDB27DECjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 15:47:55.9154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 15:48:00 -0000 --_000_3C61A3FDDFD9444A89D5580ADDB27DECjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4gIFdlIG5lZWQgdG8gdXBkYXRlIHRoZSBORVRDT05GIHByb3RvY29sIHRvIHN1cHBv cnQgdGhlIE5NREEuICBEZXRhaWxzIGNhbiBiZSB3b3JrZWQgb3V0IGFzIGEgV0cgZG9jdW1lbnQu DQoNCktlbnQsIGFzIGEgY29udHJpYnV0b3IgYW5kIGF1dGhvci4NCg0KDQpPbiA5LzI2LzE3LCA0 OjIwIEFNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgR2lsZXMgSGVyb24iIDxuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IGdpbGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPj4gd3Jv dGU6DQoNCnN1cHBvcnQgLSBsb29rcyBnb29kIHRvIG1lLg0KDQpPbiAyNCBTZXAgMjAxNywgYXQg MDc6MTgsIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpUaGUgTkVUQ09ORiBORE1BIGRy YWZ0IHdhcyBwcmVzZW50ZWQgYW4gZGlzY3Vzc2VkIGluIElFVEYgOTkgaW4gUHJhZ3VlLiBUaGUg YXV0aG9ycyBhZ3JlZWQgdG8gcHJvdmlkZSBhbiB1cGRhdGUsIHdoaWNoIHRoZXkgZGlkIHdpdGgg LTAxIHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoZSBkb2N1bWVu dCBpcyByZWFkeSBmb3IgV0cgYWRvcHRpb24uDQoNClRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgY2Fs bCB0byBhZG9wdCBORVRDT05GIE5ETUEgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4gU2luY2UgdGhl IGZvY3VzIG9mIHRoZSBkcmFmdCBpcyBORE1BIGNvbXBsaWFuY2UsIGl0IGZhbGxzIHdpdGhpbiB0 aGUgY2hhcnRlciBvZiB0aGUgV0cuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1kc2R0LW5tZGEtbmV0Y29uZi0wMTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRkc2R0LTJEbm1k YS0yRG5ldGNvbmYtMkQwMSZkPUR3TUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk Y1pvJm09VzZ5S1hTMkw5eElnNURBaGZhUW1oTGpkNkFnQ2U1OVVwZlNBN2hKTFR6NCZzPWtZYjZm cWZwZjFKQVBBZG9xVVBwcDRvdF95dXhHeDZYVnFNMXpVUUs4ZjAmZT0+DQoNClBsZWFzZSBpbmRp Y2F0ZSB3aGV0aGVyIHlvdSB0aGluayB0aGlzIGRyYWZ0IHNob3VsZCBiZSBhZG9wdGVkIGFzIGEg V0cgaXRlbS4gSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBpdCBiZWluZyBhZG9wdGVkLCBwbGVh c2Ugc3RhdGUgeW91ciByZWFzb25zIGJ5IHJlc3BvbmRpbmcgb24gdGhpcyB0aHJlYWQuDQoNClRo YW5rcy4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFp bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25m QGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_3C61A3FDDFD9444A89D5580ADDB27DECjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7F0DC2A685990242B174E73C026068A2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlN1cHBvcnQu Jm5ic3A7IFdlIG5lZWQgdG8gdXBkYXRlIHRoZSBORVRDT05GIHByb3RvY29sIHRvIHN1cHBvcnQg dGhlIE5NREEuJm5ic3A7IERldGFpbHMgY2FuIGJlIHdvcmtlZCBvdXQgYXMgYSBXRyBkb2N1bWVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQs IGFzIGEgY29udHJpYnV0b3IgYW5kIGF1dGhvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOS8yNi8xNywgNDoyMCBBTSwgJnF1b3Q7 TmV0Y29uZiBvbiBiZWhhbGYgb2YgR2lsZXMgSGVyb24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4g b24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tIj5naWxl cy5oZXJvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1cHBvcnQgLSBsb29rcyBnb29kIHRvIG1l LiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNCBT ZXAgMjAxNywgYXQgMDc6MTgsIE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBORVRDT05GIE5ETUEgZHJhZnQgd2FzIHByZXNlbnRlZCBhbiBkaXNjdXNzZWQgaW4gSUVURiA5 OSBpbiBQcmFndWUuIFRoZSBhdXRob3JzIGFncmVlZCB0byBwcm92aWRlIGFuIHVwZGF0ZSwgd2hp Y2ggdGhleSBkaWQgd2l0aCAtMDEgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIFRoZSBhdXRob3JzIGJl bGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBXRyBhZG9wdGlvbi4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzdGFydHMgYSB0d28gd2Vl ayBjYWxsIHRvIGFkb3B0IE5FVENPTkYgTkRNQSBkcmFmdCBhcyBhIFdHIGRvY3VtZW50LiBTaW5j ZSB0aGUgZm9jdXMgb2YgdGhlIGRyYWZ0IGlzIE5ETUEgY29tcGxpYW5jZSwgaXQgZmFsbHMgd2l0 aGluIHRoZSBjaGFydGVyIG9mIHRoZSBXRy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEZHNkdC0y RG5tZGEtMkRuZXRjb25mLTJEMDEmYW1wO2Q9RHdNRkFnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2Ni ZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFu MmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1XNnlLWFMyTDl4SWc1REFoZmFRbWhMamQ2QWdDZTU5 VXBmU0E3aEpMVHo0JmFtcDtzPWtZYjZmcWZwZjFKQVBBZG9xVVBwcDRvdF95dXhHeDZYVnFNMXpV UUs4ZjAmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRh LW5ldGNvbmYtMDE8L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgdGhpbmsgdGhpcyBkcmFmdCBzaG91bGQg YmUgYWRvcHRlZCBhcyBhIFdHIGl0ZW0uIElmIHlvdSBoYXZlIG9iamVjdGlvbnMgdG8gaXQgYmVp bmcgYWRvcHRlZCwgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBieSByZXNwb25kaW5nIG9uIHRo aXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9y ZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_3C61A3FDDFD9444A89D5580ADDB27DECjunipernet_-- From nobody Tue Sep 26 10:25:06 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6368013428A for ; Tue, 26 Sep 2017 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9ZFNobqytCg for ; Tue, 26 Sep 2017 10:24:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA91342FE for ; Tue, 26 Sep 2017 10:24:32 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 326E61AE018C; Tue, 26 Sep 2017 19:24:30 +0200 (CEST) Date: Tue, 26 Sep 2017 19:27:01 +0200 (CEST) Message-Id: <20170926.192701.1726303533240950350.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] WG LC for zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:25:04 -0000 Hi, Mahesh Jethanandani wrote: > The last round of WG LC on Zerotouch draft resulted in lot comments being posted about the draft. Kent has since then updated the document to address all those comments and posted -17 version of the draft. > > We believe the document is now ready for a re-run of that call. This starts a two-week WG LC on the draft. Please indicate your support if you believe the document is now ready for LC. We need affirmation of support for the LC to succeed. Unfortunately, silence is not affirmation. If you believe the document is still not ready, please indicate why. The LC will conclude on Oct. 9. I have reviewed this document, and I believe the document is ready to be published after a couple of issues have been addressed (see below). I don't have the expertise to tell if the solution is secure enough or not. Here are my comments. Major issues ------------ o Section 7.2 Adding custom query parameters like this breaks the normal YANG contract. If I understand this correctly, the instance data tree presented to the client is supposed to change based on these query parameters. If you really need to have that functionality, it would better to model the device-specific data as an action; input would be the os-name, os-version etc, and output would be the zerotouch-information and voucher etc. Also, the draft doesn't discuss things like "one-time use voucher"; this term is just used here. It seems to me that this requires more descriptive text. o Section 4.4 When a device is not able to trust a bootstrap server, it MUST NOT send its IDevID certificate in the form of a TLS client certificate How will the server authenticate the client in this case? I see that in section 7.3 you have: Note that the bootstrap server MUST NOT process a progress update from a device without first authenticating the device. This is in contrast to when a device is fetching data from the server, a read- only operation, in which case device authentication is not strictly required (e.g., when sending signed information). But the server is a normal RESTCONF server, so it will follow section 2.5 of RFC 8040; it will require clients to be authenticated. Normal issues ------------- o Section 1.2 The term "manufacturer" is used herein to refer to the manufacturer of a device or a delegate of the manufacturer. In the text you sometimes use "manufacturer" and sometimes "manufacturer ot delegate". Perhaps the term "manufacturer" should be reserved to mean just the manufacturer, and then use "manufacturer or delegate" in the places where that's appropriate. o Section 3.2 In the first paragraph, maybe include a reference to RFC 5280. o Section 5.1 The numbers in the picture don't match the numbers in the list (specifically 4-5). o Section 5.6 Upon rebooting, the device MUST still be in its initial state, causing the bootstrapping process to run again, which will eventually come to this very point, Why this MUST? What if the new boot image contains other factory defaults that does not enable ZTP, would that be illegal? I would think that implementations are free to do whatever they want in case of errors. In the case of errors, the device MUST reset itself in such a way that forces a reinstallation of the boot image, thereby wiping out any bad state the script may have left behind. Is this also required? Why can't stop and wait for manual intervention be allowed? o Section 7.3 The examples have "device=123456" in the URLs; it should be "device=123456789". I suggest you shorten the lines of the examples even more, so that the examples are properly indented in the draft (they are currently outdented) o Section 9 Should you also mention that /device list should be protected by nacm rules? If the RESTCONF user name is the device's unique-id, then a single NACM rule can be used: allow-device /ztbs:device[ztbs:unique-id=$USER] read permit o ietf-zerotouch-information.yang o sha256 is defined like this: leaf sha256 { type string; "The hex-encoded SHA-256 hash over the boot image file. Should this be type yang:hex-string? If not, I think you need to specify how the hex-chars are encoded in the string. o uri is defined like this: leaf-list uri { type inet:uri; min-elements 1; description "An ordered list of URIs to where the boot-image file MAY be obtained. This leaf-list should be ordered-by user to indicate that the order is significant. o ietf-zerotouch-bootstrap-server.yang o the action "update-progress" should have a description o If a script is erroneously provided to a device that does not support the execution of scripts, the device SHOULD send a 'script-warning' notification message Rephrase to avoid the term "notification message" Also, the types are "pre-script-warning" and "post-script-warning". o The description of the "script" typedef says: No attempt is made to standardize the contents, running context, or programming language of the script. [...] The script returns exit status code '0' on success and non-zero on error, with accompanying stderr/stdout for logging purposes. I think the last quoted sentence contradicts the first - it does in fact make assumptions about the running context of the script. I suggest the latter sentence is removed, and the rest of the test adjusted. Don't talk about exit codes, but instead talk about "success" or "error" etc. o Other comment Is it assumed that there will be a vendor-specific YANG module to enable the zero-touch process? Did you consider an ietf-zerotouch-device module for this purpose? Such a configuration must be carefully designed to allow for a "merge" configuration file to actually disable the zero touch process. Editorial nits: --------------- o use "" instead of '' consistently (except in YANG strings) o you probably should include a reference to ITU-T X.690. o s/bootstrap data/bootstrapping data/ o I suggest you run the modules through 'pyang -f yang --keep-comments' in order to fix some inconsistent indentations /martin From nobody Tue Sep 26 10:30:31 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C848213334E for ; Tue, 26 Sep 2017 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZbA1ObgOK6S for ; Tue, 26 Sep 2017 10:30:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907EE132D51 for ; Tue, 26 Sep 2017 10:30:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWG98970; Tue, 26 Sep 2017 17:30:24 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 18:30:23 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Tue, 26 Sep 2017 10:30:20 -0700 From: Alexander Clemm To: "Eric Voit (evoit)" , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: subscription-modified Thread-Index: AQHTNqfpeG5yKW176ECKSORW/1p1SaLHazBA Date: Tue, 26 Sep 2017 17:30:19 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA55C3@sjceml521-mbx.china.huawei.com> References: <20170926.081732.1052294124211547008.mbj@tail-f.com> <50c46f0026ed4a9f89995d82f0b090e0@XCH-RTP-013.cisco.com> <20170926.094649.1193359387861348510.mbj@tail-f.com> <0c55e9a8324441bba3cce3a60ca5d0af@XCH-RTP-013.cisco.com> In-Reply-To: <0c55e9a8324441bba3cce3a60ca5d0af@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59CA8EB1.013C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 77c26b744be5608b1163882d3ad847ab Archived-At: Subject: Re: [Netconf] subscription-modified X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:30:30 -0000 Martin, One more aspect to add to Eric's: =20 Really, the fact that a subscription has been modified is an OAM-type of no= tification. It is important that a receiver will receive these notificatio= ns, even if it has not explicitly subscribed to that (or accidentally unsub= scribed). Consider it part of the control channel. =20 This is a similar argument along the lines why you need to take special pre= cautions to not allow configurations that accidentally disconnect your mana= gement channel from a remote device (which was one of the initial drivers b= ehind the "Autonomic Control Plane" stuff in Anima)=20 --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, September 26, 2017 2:15 AM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] subscription-modified > From: Martin Bjorklund, September 26, 2017 3:47 AM >=20 > "Eric Voit (evoit)" wrote: > > > From: Martin Bjorklund, September 26, 2017 2:18 AM > > > Subject: subscription-modified [Was: WG adoption of NETCONF NDMA=20 > > > draft] > > > > > > "Eric Voit (evoit)" wrote: > > > > Hi Martin, > > > > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > > > > > > > > > > > > > >"Eric Voit (evoit)" > wr= ote: > > > > > > > > > > > > > > > > > > > > notification: subscription-modified > > > > > > > > > > > > > > > > > > Why is this one needed? Isn't one of the ideas with yang push=20 > > > > > that we > > > > > > > > > won't need special notifications for config changes? Wouldn't y= ou > > > > > > > > > use yang-push to subscribe to the subscription config, if you=20 > > > > > want to get this > > > > > > > > > info? > > > > > > > > > > > > > > > > It is certainly possible to subscribe to subscription config. =20 > > > > But you likely don't have the permissions for this when using=20 > > > > configured/static subscriptions. > > > > > > Why do you think that? >=20 > I don't think you answered this one. To be clear, let me rephrase my > question: Why do you think that the client won't have the permissions=20 > for receiving yang push notifications when using configured/static subscr= iptions? My statement was that a receiver might not have permissions to subscribe*, = not that it won't have permissions to receive information about the subscri= ption. The modify-subscription notification does have the same elements that would= be received if you also subscribed to the subscription information. And = as a separate type of notification you get several benefits including: (a) A receiver knows immediately that this content is not part of the telem= etry feed originally requested (i.e., no confusion as to why you are getti= ng push-updates which includes content not in the original selection filter= ) (b) The modify-subscription notification may not be dampened or filtered. (c) As it is also possible to explicitly subscribe to the subscription tree= , this separates what otherwise might be overlapping information. *As a side-note: there are many reasons why some receivers won't manage con= figured subscriptions directly... (1) A third party is managing its subscriptions (think controller/NMS drivi= ng a feed towards a data collector/repository) (2) A proxy for IoT devices manages the threads of telemetry information be= ing pushed to devices/receivers (3) A receiver which doesn't have the horsepower to manage subscriptions. = =20 (4) A receiver is in an insecure environment (5) There are many receivers for the same subscription, and they aren't all= owed to impact the others=20 >=20 > > > Why is the subscription config different from any other config? =20 > > > If we end up with a multitude of specialized xxx-modified=20 > > > notifications, what is then the value of yang push? > > > > Promise theory. > > > > When someone establishes the subscription via config, you forward to=20 > > the receiver the set of criteria you are trying to fulfil. >=20 > I'm sorry but I don't follow. I see "someone", "receiver" and "you". > Can you rephrase using the terms "client A", "client B" and "server" > (assuming multiple clients are involved). >=20 > Also, can you explain what "forward to the receiver" means, in concrete t= erms? Using the terms of yang-push, let me try again... When a management interface writes to subscription-config, there is no guar= antee that the configured receiver will be aware of this change. And if th= ey are aware, it will be hard to know for which push-update the change went= into effect unless they get some notification in-line with the push update= s. By pushing the full set of policy rules at any point a subscription is modi= fied, a record is available on the receiver of explicitly which rules which= governed any individual push-update when it was generated. > > If someone changes the subscription, you let them know the new set=20 > > of criteria that you are trying to fulfil. >=20 > Again, why can't I use yang push to get a notification when my=20 > subscription is modified? If you mean why isn't it possible to use a push-update or a push-change-upd= ate to communicate the subscription info in the middle of the configured te= lemetry stream, yes this was a design option considered. But for reasons (= a), (b), & (c) above, it wasn't pursued. Eric > > Without this notification in the middle, you don't know the rules=20 > > under which the updates are being sent. >=20 >=20 > /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 26 10:38:45 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDCB1342EE for ; Tue, 26 Sep 2017 10:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgacEJ2mdiUg for ; Tue, 26 Sep 2017 10:38:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59B031330AD for ; Tue, 26 Sep 2017 10:38:37 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 9218C1AE018C; Tue, 26 Sep 2017 19:38:36 +0200 (CEST) Date: Tue, 26 Sep 2017 19:41:08 +0200 (CEST) Message-Id: <20170926.194108.385481830078769211.mbj@tail-f.com> To: alexander.clemm@huawei.com Cc: evoit@cisco.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA55C3@sjceml521-mbx.china.huawei.com> References: <20170926.094649.1193359387861348510.mbj@tail-f.com> <0c55e9a8324441bba3cce3a60ca5d0af@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA55C3@sjceml521-mbx.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] subscription-modified X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:38:40 -0000 Alexander Clemm wrote: > Martin, > > One more aspect to add to Eric's: > > Really, the fact that a subscription has been modified is an OAM-type > of notification. It is important that a receiver will receive these > notifications, even if it has not explicitly subscribed to that (or > accidentally unsubscribed). Consider it part of the control channel. Ok, this makes sense. Thanks for the explanation! /martin > > This is a similar argument along the lines why you need to take > special precautions to not allow configurations that accidentally > disconnect your management channel from a remote device (which was one > of the initial drivers behind the "Autonomic Control Plane" stuff in > Anima) > > --- Alex > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit > (evoit) > Sent: Tuesday, September 26, 2017 2:15 AM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] subscription-modified > > > From: Martin Bjorklund, September 26, 2017 3:47 AM > > > > "Eric Voit (evoit)" wrote: > > > > From: Martin Bjorklund, September 26, 2017 2:18 AM > > > > Subject: subscription-modified [Was: WG adoption of NETCONF NDMA > > > > draft] > > > > > > > > "Eric Voit (evoit)" wrote: > > > > > Hi Martin, > > > > > > From: Martin Bjorklund, September 25, 2017 1:28 PM > > > > > > > > > > > > > > > > > > > > > > >"Eric Voit (evoit)" > wrote: > > > > > > > > > > > > > > > > > > > > > > > > notification: subscription-modified > > > > > > > > > > > > > > > > > > > > > > Why is this one needed? Isn't one of the ideas with yang push > > > > > > that we > > > > > > > > > > > won't need special notifications for config changes? Wouldn't you > > > > > > > > > > > use yang-push to subscribe to the subscription config, if you > > > > > > want to get this > > > > > > > > > > > info? > > > > > > > > > > > > > > > > > > > > It is certainly possible to subscribe to subscription config. > > > > > But you likely don't have the permissions for this when using > > > > > configured/static subscriptions. > > > > > > > > Why do you think that? > > > > I don't think you answered this one. To be clear, let me rephrase my > > question: Why do you think that the client won't have the permissions > > for receiving yang push notifications when using configured/static > > subscriptions? > > My statement was that a receiver might not have permissions to > subscribe*, not that it won't have permissions to receive information > about the subscription. > > The modify-subscription notification does have the same elements that > would be received if you also subscribed to the subscription > information. And as a separate type of notification you get several > benefits including: > > (a) A receiver knows immediately that this content is not part of the > telemetry feed originally requested (i.e., no confusion as to why you > are getting push-updates which includes content not in the original > selection filter) > > (b) The modify-subscription notification may not be dampened or > filtered. > > (c) As it is also possible to explicitly subscribe to the subscription > tree, this separates what otherwise might be overlapping information. > > > *As a side-note: there are many reasons why some receivers won't manage > *configured subscriptions directly... > (1) A third party is managing its subscriptions (think controller/NMS > driving a feed towards a data collector/repository) > (2) A proxy for IoT devices manages the threads of telemetry > information being pushed to devices/receivers > (3) A receiver which doesn't have the horsepower to manage > subscriptions. > (4) A receiver is in an insecure environment > (5) There are many receivers for the same subscription, and they > aren't allowed to impact the others > > > > > > > > > Why is the subscription config different from any other config? > > > > If we end up with a multitude of specialized xxx-modified > > > > notifications, what is then the value of yang push? > > > > > > Promise theory. > > > > > > When someone establishes the subscription via config, you forward to > > > the receiver the set of criteria you are trying to fulfil. > > > > I'm sorry but I don't follow. I see "someone", "receiver" and "you". > > Can you rephrase using the terms "client A", "client B" and "server" > > (assuming multiple clients are involved). > > > > Also, can you explain what "forward to the receiver" means, in > > concrete terms? > > Using the terms of yang-push, let me try again... > > When a management interface writes to subscription-config, there is no > guarantee that the configured receiver will be aware of this change. > And if they are aware, it will be hard to know for which push-update > the change went into effect unless they get some notification in-line > with the push updates. > > By pushing the full set of policy rules at any point a subscription is > modified, a record is available on the receiver of explicitly which > rules which governed any individual push-update when it was generated. > > > > If someone changes the subscription, you let them know the new set > > > of criteria that you are trying to fulfil. > > > > Again, why can't I use yang push to get a notification when my > > subscription is modified? > > If you mean why isn't it possible to use a push-update or a > push-change-update to communicate the subscription info in the middle > of the configured telemetry stream, yes this was a design option > considered. But for reasons (a), (b), & (c) above, it wasn't pursued. > > Eric > > > > Without this notification in the middle, you don't know the rules > > > under which the updates are being sent. > > > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 26 11:31:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B101331D2 for ; Tue, 26 Sep 2017 11:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT0FrYrFHr6F for ; Tue, 26 Sep 2017 11:30:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A019A13305E for ; Tue, 26 Sep 2017 11:30:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWH05573; Tue, 26 Sep 2017 18:30:54 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 19:30:52 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Tue, 26 Sep 2017 11:30:40 -0700 From: Alexander Clemm To: Mahesh Jethanandani , netconf Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNPSgetXKUUF3XUuwWn+KdOmrUqLHfnqg Date: Tue, 26 Sep 2017 18:30:40 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA5692@sjceml521-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.89] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA5692sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59CA9CDE.0138, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c930c112c1fa38a323930b2219d1a345 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:30:59 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA5692sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Conditional support: Strong support in the sense that this is work that is clearly needed to mak= e NMDA complete or usable with Netconf, really. Conditional on ensuring that the effort going into this will not slow the p= rocess to get the current work items (e.g. YANG-Push and subscribed notific= ations set of drafts, been waiting in queue for a while) through the WGLC p= ipeline. Thanks --- Alex From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana= ndani Sent: Saturday, September 23, 2017 10:18 PM To: netconf Subject: [Netconf] WG adoption of NETCONF NDMA draft The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The= authors agreed to provide an update, which they did with -01 version of th= e draft. The authors believe the document is ready for WG adoption. This starts a two week call to adopt NETCONF NDMA draft as a WG document. S= ince the focus of the draft is NDMA compliance, it falls within the charter= of the WG. https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 Please indicate whether you think this draft should be adopted as a WG item= . If you have objections to it being adopted, please state your reasons by = responding on this thread. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA5692sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Conditional support:

 

Strong support in the sense that this= is work that is clearly needed to make NMDA complete or usable with Netcon= f, really. 

 

Conditional on ensuring that the effo= rt going into this will not slow the process to get the current work items = (e.g. YANG-Push and subscribed notifications set of drafts, been waiting in queue for a while) through the WGLC pipeline. <= o:p>

 

Thanks

--- Alex

 

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Saturday, September 23, 2017 10:18 PM
To: netconf <netconf@ietf.org>
Subject: [Netconf] WG adoption of NETCONF NDMA draft

 

The NETCONF NDMA draft was presented an discussed in= IETF 99 in Prague. The authors agreed to provide an update, which they did= with -01 version of the draft. The authors believe the document is ready f= or WG adoption.

 

This starts a two week call to adopt NETCONF NDMA dr= aft as a WG document. Since the focus of the draft is NDMA compliance, it f= alls within the charter of the WG.

 

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01

 

Please indicate whether you think this draft should = be adopted as a WG item. If you have objections to it being adopted, please= state your reasons by responding on this thread.

 

Thanks.

 

Mahesh Jethanandani

 

 

 

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA5692sjceml521mbxchi_-- From nobody Tue Sep 26 13:15:32 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990FF134460 for ; Tue, 26 Sep 2017 13:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc7AKp6jw9f3 for ; Tue, 26 Sep 2017 13:15:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A8E134452 for ; Tue, 26 Sep 2017 13:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26548; q=dns/txt; s=iport; t=1506456927; x=1507666527; h=from:to:cc:subject:date:message-id:references: mime-version; bh=bp2AxgRUdIoY7ct5/05gP6Me4Db3G/F14BAG2P+D/KU=; b=i1o7SAZoJTpjVfxvuLwsHq2aYTzryGaW7UmUgJT6RnbKDeI5dnafz5eC ILmZXX028JuaC96pDACYW4tWOg7XeTVNiUWKxuke1sTj6A6RMJtVGfTTz 6OdNrZsf7v98Gql3wyQJ1Hj4u4sTMp6X0WuKYoAdCjbMlAsoRpoWgBe7/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQAUtcpZ/5pdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvbGRuJweDb5obgXaYPAoYAQyER08CGoQ1VwECAQEBAQECayi?= =?us-ascii?q?FGAEBAQECAQEBIQpBCwUJAgIBCBABBAEBAScDAgICGQwLFAkIAgQBDQEECIlGX?= =?us-ascii?q?AgQqECCJ4saAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWDJoICgVGFEoRePQoVCAm?= =?us-ascii?q?CDz2CYAWKC4kYhSqIUwKHXIx2ghyJbYcGlRoCERkBgTgBV4EOeBVJhx12B4gzg?= =?us-ascii?q?TGBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="scan'208,217";a="8510758" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 20:15:13 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8QKFDcb019603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 20:15:13 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 16:15:12 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 26 Sep 2017 16:15:12 -0400 From: "Eric Voit (evoit)" To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , Alexander Clemm CC: netconf Thread-Topic: [Netconf] WG adoption of NETCONF NDMA draft Thread-Index: AQHTNgd4J5OLOU6LbUK/pZLIDT/TLaLF07pQgAB1XYCAAARKAP//0lJQgAFxbCA= Date: Tue, 26 Sep 2017 20:15:12 +0000 Message-ID: <22bce73d0b7a4c0e9ab900c913b296d5@XCH-RTP-013.cisco.com> References: <20170925140540.djxmhbgtjhghjh6l@elstar.local> <6097f1bb21d346bd9f4cce12b25cadbb@XCH-RTP-013.cisco.com> <20170925200117.6tcnga7rg3gy5rie@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_22bce73d0b7a4c0e9ab900c913b296d5XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 20:15:29 -0000 --_000_22bce73d0b7a4c0e9ab900c913b296d5XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyIHRoZSBkaXNjdXNzaW9uIGJlbG93LCBiZWxvdyBhcmUgdmVyc2lvbnMgdGhlIHlhbmctcHVz aCBtb2RlbHMgd2hpY2ggaW5jbHVkZSB0aGUgdHlwZSBvZiBleHBsaWNpdCBzdWJ0eXBpbmcgd2hp Y2ggd2UgYXBwbGllZCBmcm9tIHYwMCB0aHJvdWdoIHYwNQ0KDQpUcmVlIHZpZXcNCmh0dHBzOi8v Z2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmctcHVzaC9ibG9iL21hc3Rlci9zdWJzY3JpcHRpb25z LXRyZWUlNDAyNi1TZXB0LTIwMTcudHJlZQ0KKHRyZWUgaXMgMTQlIGxhcmdlciB0aGFuIHYwOSwg YWN0dWFsIHlhbmcgbW9kZWwgc2l6ZXMgYXJlIHRoZSBzYW1lLikNCg0KaWV0Zi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnMNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmctcHVzaC9i bG9iL21hc3Rlci9pZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyU0MDIwMTctMDktMjYueWFu Zw0KDQppZXRmLXlhbmctcHVzaC55YW5nDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95 YW5nLXB1c2gvYmxvYi9tYXN0ZXIvaWV0Zi15YW5nLXB1c2glNDAyMDE3LTA1LTI2LnlhbmcNCg0K VW5sZXNzIEkgaGVhciBvYmplY3Rpb25zLCBJIHdpbGwgcG9zdCB0aGVzZSBhcyB0aGUgbmV3IG1v ZGVsIHZlcnNpb25zLg0KDQpFcmljDQoNCg0KRnJvbTogRXJpYyBWb2l0IChldm9pdCkNClNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDI1LCAyMDE3IDU6NDcgUE0NClRvOiAnQW5keSBCaWVybWFuJyA8 YW5keUB5dW1hd29ya3MuY29tPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyBuZXRjb25mIDxuZXRjb25mQGlldGYub3JnPjsgJ01h cnRpbiBCam9ya2x1bmQnIDxtYmpAdGFpbC1mLmNvbT47ICdBbGV4YW5kZXIgQ2xlbW0nIDxhbGV4 YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gV0cgYWRvcHRp b24gb2YgTkVUQ09ORiBORE1BIGRyYWZ0DQoNClBlciB0aGUgcGFyYWxsZWwgdGhyZWFkIHdpdGgg TWFydGluLCB5YW5nLXB1c2jigJlzIG1vdmUgdG8gc2VsZWN0aW9uLWZpbHRlci10eXBlIHdhcyBk b25lIG9ubHkgYmFjayBpbiBBcHJpbCBiYXNlZCBvbiBvdXIgaW50ZXJwcmV0YXRpb24gb2Ygd2hl cmUgbm1kYSB3YXMgZ29pbmcuDQoNCk1vdmluZyBiYWNrIHRvIHRoZSBwcmV2aW91cyBleHBsaWNp dCBzdWJ0eXBpbmcgdGhhdCB3ZSBoYWQgbG9va3MgbGlrZSBpdCB3aWxsIGRyaXZlIGNvbnNlbnN1 cyBmYXN0ZXIuICAgQW5kIGNvbnNpZGVyaW5nIG91ciBjdXJyZW50IHlhbmctcHVzaCBpbXBsZW1l bnRhdGlvbiBpcyBiYXNlZCBvbiB0aGlzIHNhbWUgZXhwbGljaXQgc3VidHlwZSBicmVha2Rvd24s IHRoaXMgaXMgYWN0dWFsbHkgbXVjaCBlYXNpZXIgZm9yIG1lLg0KDQpTbyBJIHdpbGwgcmV0dXJu IHlhbmctcHVzaCB0byBzb21ldGhpbmcgY2xvc2UgdG8gdGhlIGZpbHRlciBzdWJ0eXBpbmcgd2Ug aGFkIGJlZm9yZSBJRVRGOTguICBXaGljaCBoYXBwZW5zIHRvIGJlIHdoYXQgaXMgaW4gdGhpcyBk cmFmdC4NCg0KRXJpYw0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jr cy5jb21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNSwgMjAxNyA0OjE3IFBNDQpUbzogSnVl cmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8 bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+OyBFcmljIFZvaXQg KGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PjsgbmV0Y29u ZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW05ldGNvbmZdIFdHIGFkb3B0aW9uIG9mIE5FVENPTkYgTkRNQSBkcmFmdA0KDQoNCg0KT24g TW9uLCBTZXAgMjUsIDIwMTcgYXQgMTowMSBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3RlOg0KT24gTW9uLCBTZXAgMjUsIDIwMTcgYXQgMDU6 Mjc6MzFQTSArMDAwMCwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQo+ID4gQW4gYXVnbWVudCB0 byBhIGNob2ljZSBpcyBhIGdvb2QgdGhpbmcuIEl0IHJlcXVpcmVzIHRvIHNwZWxsIG91dCBob3cg YSBmaWx0ZXINCj4gPiBtZWNoYW5pc20gd29ya3MgYW5kIHdoYXQgdGhlIHBhcmFtZXRlcnMgb2Yg dGhlIGZpbHRlciBtZWNoYW5pc20gYXJlLg0KPg0KPiBUaGVyZSBhcmUgbWFueSBwb3NzaWJpbGl0 aWVzIGZvciBmaWx0ZXIgcGFyYW1ldGVycyBhbmQgbWVjaGFuaXNtcy4gIEV2ZW4gaWYgd2UgbGlt aXQgdGhpbmdzIHRvIGp1c3QgeHBhdGgsIGV2ZXJ5IHZlbmRvciB3aWxsIGhhdmUgZGlmZmVyZW5j ZXMgaW4gdGhlIGNvbXBsZXhpdHkgYW5kIGVsZW1lbnRzIG9mIGV4cHJlc3Npb24gc3VwcG9ydC4g IFRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIGFyZSBidXlpbmcgbWVhbmluZ2Z1bCB3aXRoIHRo ZSBleHBsaWNpdCBzdWJ0eXBpbmcgdGhhdCBjYW5ub3QgYmUgZGVsaXZlcmVkIGluIG90aGVyIHdh eXMuDQoNCklmIGV2ZXJ5IHZlbmRvciBpbXBsZW1lbnQgYSBkaWZmZXJlbnQgdmFyaWFudCBvZiB4 cGF0aCwgd2UgZmFpbGVkIHRvDQpjcmVhdGUgYSBzdGFuZGFyZC4gQSBzdGFuZGFyZCB0aGF0IGFs bG93cyBldmVyeWJvZHkgdG8gaW1wbGVtZW50DQp3aGF0ZXZlciBoZSBwcmVmZXJzIGlzIG5vdCB1 c2VmdWwuIFN0YW5kYXJkcyBhcmUgZm9yIGludGVyb3BlcmFiaWxpdHkuDQoNCj4gQmFzZWQgb24g dGhlc2UgZHJpdmVycywgSSBmZWVsIGl0IHVzZWZ1bCB0byBkZWNvdXBsZSB0aGUgcHJvYmxlbXMg b2YgdHJhbnNwb3J0aW5nIHRoZSBzZWxlY3Rpb24gZmlsdGVyIG9iamVjdCBmcm9tIHRoZSBpbnRl cnByZXRhdGlvbiBvZiB0aGF0IG9iamVjdC4gIEl0IHNjYWxlcyBiZXR0ZXIuDQoNCkl0IGh1cnRz IGludGVyb3BlcmFiaWxpdHkgbW9yZS4NCg0KKzENCg0KDQo+ID4gSSBhbHNvDQo+ID4gYXV0b21h dGljYWxseSBnZXQgYSB3YXkgdG8gYW5ub3VuY2Ugd2hhdCBmaWx0ZXJpbmcgbWVjaGFuaXNtcyBh bg0KPiA+IGltcGxlbWVudGF0aW9uIHN1cHBvcnRzLiBTb21ldGhpbmcgZW50aXJlbHkgb3BhcXVl IGlzIHdlbGwgZW50aXJlbHkgb3BhcXVlLg0KPg0KPiBZZXMsIGF1Z21lbnRhdGlvbnMgYXJlIGdv b2QgdGhpbmdzLiAgV2UgaGF2ZSAxNCBvZiB0aGVtIGluIHlhbmctcHVzaC4gICBUaGUgaXNzdWUg aXMgdGhhdCBuZXcgZmlsdGVyIHR5cGVzIGVhY2ggcmVxdWlyZXMgc2l4IGFkZGl0aW9uYWwgYXVn bWVudGF0aW9ucy4gIFRoaXMgbWFrZXMgbmV3IHZlbmRvciBzcGVjaWZpYyBmaWx0ZXIgdHlwZSBk aWZmaWN1bHQgdG8gYWRkLCBleHBvc2UsIGFuZCBleHBsYWluIHRvIDNyZCBwYXJ0eSBkZXZlbG9w ZXJzLiBUaGlzIGlzIGNvbXBsZXgsIGlzIGEgcGxhY2Ugd2hlcmUgZXJyb3JzIGNvdWxkIGVhc2ls eSBiZSBpbnRyb2R1Y2VkLCBhbmQgd2lsbCBpbmhpYml0IGFkb3B0aW9uLg0KDQpBbmQgYWxsIHRo aXMgZ29lcyBhd2F5IGlmIHRoZSBmaWx0ZXIgaXMgb3BhcXVlPyBJIGRvdWJ0IHRoaXMgdmVyeQ0K bXVjaC4gIEhpZGluZyB0aGUgaXNzdWUgZG9lcyBub3QgaGVscCAzcmQgcGFydCBkZXZlbG9wZXJz LCBpdCBkb2VzIG5vdA0KaGVscCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNClVzaW5nIGFueWRhdGEg aW5zdGVhZCBvZiByZWFsIFlBTkcgZGF0YSBub2RlcyBpcyB0aGUgd29yc3QgdGhpbmcgcG9zc2li bGUNCmZvciBhIDNyZC1wYXJ0eSBjbGllbnQgZGV2ZWxvcGVyLiAgSXQgbWFrZXMgWUFORyBhdXRv bWF0aW9uIGltcG9zc2libGUsIG5vdCBqdXN0IGhhcmRlci4NCllBTkcgY29tcGlsZXJzIGhhdmUg bm8gcHJvYmxlbSBzb3J0aW5nIG91dCBzdGF0ZW1lbnRzIGZyb20gbXVsdGlwbGUgZmlsZXMuDQox NCB0aGluZ3MgbWF5IGJlIGEgbG90IGZvciBodW1hbnMgdG8gcmVhZCwgYnV0IG5vdCBmb3IgYSBZ QU5HIGNvbXBpbGVyLg0KDQpSZW1vdmluZyB0aGUgZmlsdGVyIHNwZWNpZmljYXRpb24gZnJvbSB0 aGUgc3RhbmRhcmQgZG9lcyBub3QgaGVscCBjbGllbnQNCmRldmVsb3BlcnMgd3JpdGluZyBjb2Rl IHRvIHVzZSAgYSBmaWx0ZXIuDQoNCg0KDQoNCi9qcw0KDQoNCkFuZHkNCg0KDQoNCi0tDQpKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDov L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KDQo= --_000_22bce73d0b7a4c0e9ab900c913b296d5XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVyIHRoZSBkaXNjdXNzaW9uIGJl bG93LCBiZWxvdyBhcmUgdmVyc2lvbnMgdGhlIHlhbmctcHVzaCBtb2RlbHMgd2hpY2ggaW5jbHVk ZSB0aGUgdHlwZSBvZiBleHBsaWNpdCBzdWJ0eXBpbmcgd2hpY2ggd2UgYXBwbGllZCBmcm9tIHYw MCB0aHJvdWdoIHYwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VHJlZSB2aWV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9u ZXRjb25mLXdnL3lhbmctcHVzaC9ibG9iL21hc3Rlci9zdWJzY3JpcHRpb25zLXRyZWUlNDAyNi1T ZXB0LTIwMTcudHJlZSI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1wdXNoL2Js b2IvbWFzdGVyL3N1YnNjcmlwdGlvbnMtdHJlZSU0MDI2LVNlcHQtMjAxNy50cmVlPC9hPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPih0cmVlIGlzIDE0JSBsYXJnZXIgdGhhbiB2MDksIGFjdHVhbCB5YW5n IG1vZGVsIHNpemVzIGFyZSB0aGUgc2FtZS4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5pZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1c2gvYmxv Yi9tYXN0ZXIvaWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMlNDAyMDE3LTA5LTI2Lnlhbmci Pmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmctcHVzaC9ibG9iL21hc3Rlci9pZXRm LXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyU0MDIwMTctMDktMjYueWFuZzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5pZXRmLXlhbmctcHVzaC55YW5nPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRj b25mLXdnL3lhbmctcHVzaC9ibG9iL21hc3Rlci9pZXRmLXlhbmctcHVzaCU0MDIwMTctMDUtMjYu eWFuZyI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1wdXNoL2Jsb2IvbWFzdGVy L2lldGYteWFuZy1wdXNoJTQwMjAxNy0wNS0yNi55YW5nPC9hPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBoZWFyIG9iamVjdGlvbnMsIEkgd2ls bCBwb3N0IHRoZXNlIGFzIHRoZSBuZXcgbW9kZWwgdmVyc2lvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEVyaWMgVm9pdCAoZXZvaXQpDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBT ZXB0ZW1iZXIgMjUsIDIwMTcgNTo0NyBQTTxicj4NCjxiPlRvOjwvYj4gJ0FuZHkgQmllcm1hbicg Jmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0OzsgbmV0Y29uZiAmbHQ7bmV0Y29u ZkBpZXRmLm9yZyZndDs7ICdNYXJ0aW4gQmpvcmtsdW5kJyAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7 OyAnQWxleGFuZGVyIENsZW1tJyAmbHQ7YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbTmV0Y29uZl0gV0cgYWRvcHRpb24gb2YgTkVUQ09ORiBO RE1BIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlciB0aGUgcGFyYWxsZWwgdGhyZWFkIHdp dGggTWFydGluLCB5YW5nLXB1c2jigJlzIG1vdmUgdG8gc2VsZWN0aW9uLWZpbHRlci10eXBlIHdh cyBkb25lIG9ubHkgYmFjayBpbiBBcHJpbCBiYXNlZCBvbiBvdXIgaW50ZXJwcmV0YXRpb24gb2Yg d2hlcmUgbm1kYSB3YXMgZ29pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5Nb3ZpbmcgYmFjayB0byB0aGUgcHJldmlvdXMgZXhwbGljaXQgc3VidHlwaW5nIHRo YXQgd2UgaGFkIGxvb2tzIGxpa2UgaXQgd2lsbCBkcml2ZSBjb25zZW5zdXMgZmFzdGVyLiZuYnNw OyZuYnNwOyBBbmQgY29uc2lkZXJpbmcgb3VyIGN1cnJlbnQgeWFuZy1wdXNoIGltcGxlbWVudGF0 aW9uIGlzDQogYmFzZWQgb24gdGhpcyBzYW1lIGV4cGxpY2l0IHN1YnR5cGUgYnJlYWtkb3duLCB0 aGlzIGlzIGFjdHVhbGx5IG11Y2ggZWFzaWVyIGZvciBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIEkgd2lsbCByZXR1cm4geWFuZy1wdXNoIHRvIHNvbWV0 aGluZyBjbG9zZSB0byB0aGUgZmlsdGVyIHN1YnR5cGluZyB3ZSBoYWQgYmVmb3JlIElFVEY5OC4m bmJzcDsgV2hpY2ggaGFwcGVucyB0byBiZSB3aGF0IGlzIGluIHRoaXMgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBC aWVybWFuIFs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5tYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRlbWJlciAy NSwgMjAxNyA0OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7OyBFcmljIFZvaXQgKGV2 b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29t PC9hPiZndDs7IG5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5u ZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25m XSBXRyBhZG9wdGlvbiBvZiBORVRDT05GIE5ETUEgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjUsIDIwMTcgYXQgMTowMSBQTSwgSnVl cmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgU2VwIDI1LCAyMDE3IGF0IDA1OjI3OjMxUE0gJiM0MzswMDAwLCBFcmljIFZv aXQgKGV2b2l0KSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgQW4gYXVnbWVudCB0byBhIGNob2ljZSBp cyBhIGdvb2QgdGhpbmcuIEl0IHJlcXVpcmVzIHRvIHNwZWxsIG91dCBob3cgYSBmaWx0ZXI8YnI+ DQomZ3Q7ICZndDsgbWVjaGFuaXNtIHdvcmtzIGFuZCB3aGF0IHRoZSBwYXJhbWV0ZXJzIG9mIHRo ZSBmaWx0ZXIgbWVjaGFuaXNtIGFyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBhcmUgbWFu eSBwb3NzaWJpbGl0aWVzIGZvciBmaWx0ZXIgcGFyYW1ldGVycyBhbmQgbWVjaGFuaXNtcy4mbmJz cDsgRXZlbiBpZiB3ZSBsaW1pdCB0aGluZ3MgdG8ganVzdCB4cGF0aCwgZXZlcnkgdmVuZG9yIHdp bGwgaGF2ZSBkaWZmZXJlbmNlcyBpbiB0aGUgY29tcGxleGl0eSBhbmQgZWxlbWVudHMgb2YgZXhw cmVzc2lvbiBzdXBwb3J0LiZuYnNwOyBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBhcmUgYnV5 aW5nIG1lYW5pbmdmdWwgd2l0aCB0aGUNCiBleHBsaWNpdCBzdWJ0eXBpbmcgdGhhdCBjYW5ub3Qg YmUgZGVsaXZlcmVkIGluIG90aGVyIHdheXMuPGJyPg0KPGJyPg0KSWYgZXZlcnkgdmVuZG9yIGlt cGxlbWVudCBhIGRpZmZlcmVudCB2YXJpYW50IG9mIHhwYXRoLCB3ZSBmYWlsZWQgdG88YnI+DQpj cmVhdGUgYSBzdGFuZGFyZC4gQSBzdGFuZGFyZCB0aGF0IGFsbG93cyBldmVyeWJvZHkgdG8gaW1w bGVtZW50PGJyPg0Kd2hhdGV2ZXIgaGUgcHJlZmVycyBpcyBub3QgdXNlZnVsLiBTdGFuZGFyZHMg YXJlIGZvciBpbnRlcm9wZXJhYmlsaXR5Ljxicj4NCjxicj4NCiZndDsgQmFzZWQgb24gdGhlc2Ug ZHJpdmVycywgSSBmZWVsIGl0IHVzZWZ1bCB0byBkZWNvdXBsZSB0aGUgcHJvYmxlbXMgb2YgdHJh bnNwb3J0aW5nIHRoZSBzZWxlY3Rpb24gZmlsdGVyIG9iamVjdCBmcm9tIHRoZSBpbnRlcnByZXRh dGlvbiBvZiB0aGF0IG9iamVjdC4mbmJzcDsgSXQgc2NhbGVzIGJldHRlci48YnI+DQo8YnI+DQpJ dCBodXJ0cyBpbnRlcm9wZXJhYmlsaXR5IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgJmd0OyBJIGFsc288YnI+DQomZ3Q7 ICZndDsgYXV0b21hdGljYWxseSBnZXQgYSB3YXkgdG8gYW5ub3VuY2Ugd2hhdCBmaWx0ZXJpbmcg bWVjaGFuaXNtcyBhbjxicj4NCiZndDsgJmd0OyBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cy4gU29t ZXRoaW5nIGVudGlyZWx5IG9wYXF1ZSBpcyB3ZWxsIGVudGlyZWx5IG9wYXF1ZS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBZZXMsIGF1Z21lbnRhdGlvbnMgYXJlIGdvb2QgdGhpbmdzLiZuYnNwOyBXZSBo YXZlIDE0IG9mIHRoZW0gaW4geWFuZy1wdXNoLiZuYnNwOyAmbmJzcDtUaGUgaXNzdWUgaXMgdGhh dCBuZXcgZmlsdGVyIHR5cGVzIGVhY2ggcmVxdWlyZXMgc2l4IGFkZGl0aW9uYWwgYXVnbWVudGF0 aW9ucy4mbmJzcDsgVGhpcyBtYWtlcyBuZXcgdmVuZG9yIHNwZWNpZmljIGZpbHRlciB0eXBlIGRp ZmZpY3VsdCB0byBhZGQsIGV4cG9zZSwgYW5kIGV4cGxhaW4gdG8gM3JkIHBhcnR5IGRldmVsb3Bl cnMuDQogVGhpcyBpcyBjb21wbGV4LCBpcyBhIHBsYWNlIHdoZXJlIGVycm9ycyBjb3VsZCBlYXNp bHkgYmUgaW50cm9kdWNlZCwgYW5kIHdpbGwgaW5oaWJpdCBhZG9wdGlvbi48YnI+DQo8YnI+DQpB bmQgYWxsIHRoaXMgZ29lcyBhd2F5IGlmIHRoZSBmaWx0ZXIgaXMgb3BhcXVlPyBJIGRvdWJ0IHRo aXMgdmVyeTxicj4NCm11Y2guJm5ic3A7IEhpZGluZyB0aGUgaXNzdWUgZG9lcyBub3QgaGVscCAz cmQgcGFydCBkZXZlbG9wZXJzLCBpdCBkb2VzIG5vdDxicj4NCmhlbHAgaW50ZXJvcGVyYWJpbGl0 eS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VXNpbmcgYW55ZGF0YSBpbnN0ZWFkIG9mIHJlYWwgWUFORyBkYXRhIG5vZGVzIGlz IHRoZSB3b3JzdCB0aGluZyBwb3NzaWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIGEgM3JkLXBhcnR5IGNsaWVudCBkZXZlbG9wZXIuJm5i c3A7IEl0IG1ha2VzIFlBTkcgYXV0b21hdGlvbiBpbXBvc3NpYmxlLCBub3QganVzdCBoYXJkZXIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5H IGNvbXBpbGVycyBoYXZlIG5vIHByb2JsZW0gc29ydGluZyBvdXQgc3RhdGVtZW50cyBmcm9tIG11 bHRpcGxlIGZpbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MTQgdGhpbmdzIG1heSBiZSBhIGxvdCBmb3IgaHVtYW5zIHRvIHJlYWQsIGJ1dCBu b3QgZm9yIGEgWUFORyBjb21waWxlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVtb3ZpbmcgdGhlIGZpbHRlciBzcGVjaWZpY2F0 aW9uIGZyb20gdGhlIHN0YW5kYXJkIGRvZXMgbm90IGhlbHAgY2xpZW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXZlbG9wZXJzIHdyaXRpbmcg Y29kZSB0byB1c2UgJm5ic3A7YSBmaWx0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNs YXNzPSJob2VuemIiPi9qczwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2Vu emIiPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJob2VuemIiPlBob25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFu eTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5GYXg6Jm5ic3A7ICZuYnNwOyYjNDM7 NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8L3Nw YW4+PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2E+PHNwYW4gY2xh c3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZndDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9l bnpiIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5OZXRjb25mIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0 Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjwvc3Bhbj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_22bce73d0b7a4c0e9ab900c913b296d5XCHRTP013ciscocom_-- From nobody Wed Sep 27 03:20:43 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0DB134995 for ; Wed, 27 Sep 2017 03:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_MWpQLicKJD for ; Wed, 27 Sep 2017 03:20:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 31DA2134996 for ; Wed, 27 Sep 2017 03:20:41 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 083E71AE0397; Wed, 27 Sep 2017 12:20:39 +0200 (CEST) Date: Wed, 27 Sep 2017 12:19:09 +0200 (CEST) Message-Id: <20170927.121909.927734040822388744.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <157194c0acce4c04aa3c335a8d65b510@XCH-RTP-013.cisco.com> References: <157194c0acce4c04aa3c335a8d65b510@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Netconf NMDA: Default datastore for rpc get-data? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 10:20:42 -0000 "Eric Voit (evoit)" wrote: > Hi Martin, > > I see you have mandatory instead of default for your source datastore > of the rpc get-data. What do you think about having the default of > "operational" in place so that all queries need not specify this? The operation get-data is generic, and accepts any datastore as input parameter. It is not clear why "operational" should be the default if no datastore is specified. Maybe we think it will be the most common datastore to ask for, but that's not a good reason for a default value. I think it is better to be explicit. /martin From nobody Wed Sep 27 05:52:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107FB134AD1 for ; Wed, 27 Sep 2017 05:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06w_6aqqulAj for ; Wed, 27 Sep 2017 05:52:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90FD134AC4 for ; Wed, 27 Sep 2017 05:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=976; q=dns/txt; s=iport; t=1506516768; x=1507726368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JJZ77VUfamuEGCxexte4VBl4tAjfkx8iX16PzfcZ7ls=; b=YgZDOUU17y99SR+B83V93tRgmXPUGyMCjb0hjbKidvhTsBW9z8XFphfV iH4/R8H2cGGK/Uz3BJH3BPUcLqc+mDZaoWZIeNBPXJp3vC+FfYUw8W/A1 oQAgR8ie5ux/NJjhnoRSBEqvtBuTIm7ROvQpn/rF5wChZfJVtKESsDDqh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACbnstZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1yBUicHjhCPXoF2liuCEgqFOwKEWj8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAToxDgULAgEIDgcDHhAyJQIEDgUIiiEIqzKLBQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2DK4ICgVGBaoMoincFoSMClFSTD5UcAhEZAYE4AR84gQ54FYdmdok?= =?us-ascii?q?fgRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,445,1500940800"; d="scan'208";a="298439580" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 12:52:20 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8RCqKHY027161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2017 12:52:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 27 Sep 2017 08:52:19 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 27 Sep 2017 08:52:19 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: Netconf NMDA: Default datastore for rpc get-data? Thread-Index: AQHTN3pGv/txw60qt0iWbsPLy1OlHqLIqkBA Date: Wed, 27 Sep 2017 12:52:19 +0000 Message-ID: <105c9d5bd0784957bea833479499df79@XCH-RTP-013.cisco.com> References: <157194c0acce4c04aa3c335a8d65b510@XCH-RTP-013.cisco.com> <20170927.121909.927734040822388744.mbj@tail-f.com> In-Reply-To: <20170927.121909.927734040822388744.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Netconf NMDA: Default datastore for rpc get-data? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 12:52:50 -0000 > From: Martin Bjorklund, September 27, 2017 6:19 AM >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > > I see you have mandatory instead of default for your source datastore > > of the rpc get-data. What do you think about having the default of > > "operational" in place so that all queries need not specify this? >=20 > The operation get-data is generic, and accepts any datastore as input > parameter. It is not clear why "operational" should be the default if no > datastore is specified. Maybe we think it will be the most common datast= ore > to ask for, but that's not a good reason for a default value. The reason I was thinking it might be a good default is to simplify the int= erface for less expert users. =20 Having new users internalize the NMDA partitioning before being able to ask= what is running on the box will add some complexity. Eric > I think it is better to be explicit. >=20 >=20 > /martin From nobody Wed Sep 27 07:29:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4D134D5D for ; Wed, 27 Sep 2017 07:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.935 X-Spam-Level: ** X-Spam-Status: No, score=2.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Emsrxri3S1 for ; Wed, 27 Sep 2017 07:29:46 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBD3134D63 for ; Wed, 27 Sep 2017 07:23:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: "'Kent Watsen'" , "'Giles Heron'" , "'Mahesh Jethanandani'" Cc: "'netconf'" References: <2421997E-7511-49C4-AA8C-C51F3B28A94F@gmail.com> <3C61A3FD-DFD9-444A-89D5-580ADDB27DEC@juniper.net> In-Reply-To: <3C61A3FD-DFD9-444A-89D5-580ADDB27DEC@juniper.net> Date: Wed, 27 Sep 2017 10:23:01 -0400 Message-ID: <031a01d3379c$2052f5d0$60f8e170$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01D3377A.99424030" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKnIWaf+XxG3mxnCCxok0yu8h8s9wFP4zySAPlJ58ehDquh8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:29:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_031B_01D3377A.99424030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would like to second Kent=E2=80=99s comments as an individual = contributor and as the i2RS WG co-chair.=20 =20 The NETCONF WG has shown that they can pick apart difficult problems and = come up with a complete solution. I trust that they can do this with = this draft.=20 =20 Susan Hares=20 =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, September 26, 2017 11:48 AM To: Giles Heron; Mahesh Jethanandani Cc: netconf Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft =20 Support. We need to update the NETCONF protocol to support the NMDA. = Details can be worked out as a WG document. =20 Kent, as a contributor and author. =20 =20 On 9/26/17, 4:20 AM, "Netconf on behalf of Giles Heron" = wrote: =20 support - looks good to me.=20 =20 On 24 Sep 2017, at 07:18, Mahesh Jethanandani = wrote: =20 The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. = The authors agreed to provide an update, which they did with -01 version = of the draft. The authors believe the document is ready for WG adoption. = =20 This starts a two week call to adopt NETCONF NDMA draft as a WG = document. Since the focus of the draft is NDMA compliance, it falls = within the charter of the WG.=20 =20 https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 = =20 =20 Please indicate whether you think this draft should be adopted as a WG = item. If you have objections to it being adopted, please state your = reasons by responding on this thread. =20 Thanks. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =20 ------=_NextPart_000_031B_01D3377A.99424030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I would like to second Kent=E2=80=99s comments as an individual = contributor and as the i2RS WG co-chair.

 

The NETCONF WG has shown that they can pick apart difficult problems = and come up with a complete solution.=C2=A0 I trust that they can do = this with this draft.

 

Susan Hares

 

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent = Watsen
Sent: Tuesday, September 26, 2017 11:48 = AM
To: Giles Heron; Mahesh Jethanandani
Cc: = netconf
Subject: Re: [Netconf] WG adoption of NETCONF NDMA = draft

 

Support.  We need to = update the NETCONF protocol to support the NMDA.  Details can be = worked out as a WG document.

 

=

Kent, as a contributor and = author.

 

=

 

=

On 9/26/17, 4:20 AM, "Netconf on = behalf of Giles Heron" <netconf-bounces@ietf.org on = behalf of giles.heron@gmail.com> = wrote:

 

support - looks good to me.

 

On 24 Sep 2017, at 07:18, Mahesh Jethanandani <mjethanandani@gmail.com> = wrote:

 

The NETCONF NDMA draft was presented an discussed in = IETF 99 in Prague. The authors agreed to provide an update, which they = did with -01 version of the draft. The authors believe the document is = ready for WG adoption.

 

This starts a two week call to adopt NETCONF NDMA = draft as a WG document. Since the focus of the draft is NDMA compliance, = it falls within the charter of the WG.

 

https://tools.= ietf.org/html/draft-dsdt-nmda-netconf-01

 

Please indicate whether you think this draft should be = adopted as a WG item. If you have objections to it being adopted, please = state your reasons by responding on this thread.

 

Thanks.

 

Mahesh Jethanandani

 

 

 

_______________________________________________
Netc= onf mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

 

------=_NextPart_000_031B_01D3377A.99424030-- From nobody Wed Sep 27 20:29:41 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8778D133011 for ; Wed, 27 Sep 2017 20:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IlKMxceBaSE for ; Wed, 27 Sep 2017 20:29:37 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0119.outbound.protection.outlook.com [104.47.36.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494F3135299 for ; Wed, 27 Sep 2017 20:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yYRdwDCSMIlI66tVZ81AsE8CravMWZGGY8k7oSr9KOg=; b=RVhYL7dlrhMN2Tz9mwNEKvfGFNiIz0JDl6/hA7EolXFp1UzslsdxyRXyJWhFJkSe+g4qTefilvEFMK+wWnOGjNGJTAXRT/hAV5mJhvrT9vpYqJ2kB6JUyB2Hei3Q+BJY8q6l2AXWZXNlj5QHhZMzAWU8iykv+vaazSrQJejgNFE= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Thu, 28 Sep 2017 03:29:34 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 28 Sep 2017 03:29:34 +0000 From: Kent Watsen To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] WG LC for zerotouch Thread-Index: AQHTNmkgNr3NKKCDrEalHAYIEUO5aqLHbIGAgAH3n4A= Date: Thu, 28 Sep 2017 03:29:34 +0000 Message-ID: References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> <20170926.192701.1726303533240950350.mbj@tail-f.com> In-Reply-To: <20170926.192701.1726303533240950350.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:PvaSceqxJC4WTV1FkDkAO2mjBAdUejOW9F9kAXDqU8s9gFzDnU+ueAH7hS4tWMMpKd8m2WvG/6Ln4MYYQ4fsKJ+1wRL9uUeBGYAqIvVYEcgfgubBwddK27At+58YEvhB4QpaYkY57eLlMh4kId9skmycQReL8ITN4PCL0GCbXaMkEXKqL246lVHfZvFRzMY4e+/45GgOVZ0Nh6Ca1jcqNZ8uLD1LNqm3dtlw4hGqhxEPki665nVjSa3zMd0TQ5hO+LKnXy1KCtQmt60fczvXxujDfXTs4kZyWKesQuH1PEU/ndtrOp8rJxTWSpvQd0dfmBfFR4ikCUSBvd2aWLtuTw==; 5:w5ehi0iLAcSR99+VVJsmLWez5C+RYWxUSEdmVb1qufKEn7pP7a5SfzEHhh4tyeLebChcaYcfjxnCM4r01yo95ksj9z5Yv+s8VNIrt2zn0z/P2D+HK2oaiXo2KKOukayR3VL06dQKaVEAhTva9+HavA==; 24:p9dk9DzRbroBAqIGOyG4QtJ+eqvhui2v1QzC6h66t/EI5l6OkaooTorog2T2CCtOXWsEdgQneFQqPlCqcAhIuLItlLRtPOTtua3IGZ0JSBM=; 7:cbhWwsJmAc4PrtMU2XUmZqjc9NQfBDAX24OkmAoITo/24fXdYZg1JquklQOjlmwziBnt44NhXNFhIpVdHtrbYlnsa/tLjYm1x9BNtfIE2CfFkLoKH3Lsqk0Tef5Ol+hBCxOF1IwuB69j40xkKJOYnhfxdBnfegTBpbFK4R3tYw7Y8pWVW8CzvR6GScqk+DN5uQdMDOX4J4mu6FV84b0Weeg0TcsuWtX/IkJ/rrJ7ecI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3c68423f-362e-4f25-4678-08d506212380 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(43784003)(51444003)(199003)(40224003)(4326008)(229853002)(106356001)(189998001)(2950100002)(6486002)(6916009)(105586002)(33656002)(77096006)(5660300001)(3846002)(101416001)(2906002)(99286003)(68736007)(6116002)(6512007)(53936002)(102836003)(6436002)(66066001)(25786009)(14454004)(2900100001)(7736002)(305945005)(97736004)(81166006)(8936002)(8676002)(6246003)(54356999)(76176999)(3280700002)(50986999)(81156014)(83716003)(478600001)(316002)(86362001)(83506001)(82746002)(3660700001)(6506006)(58126008)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <609A49D218CBF44098C91F8A2C728A6A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2017 03:29:34.0996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275 Archived-At: Subject: Re: [Netconf] WG LC for zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:29:39 -0000 SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3ISAgQ29tbWVudHMgYmVsb3cuDQoN CksuDQoNCg0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgYW5kIEkgYmVsaWV2ZSB0 aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8NCj4gYmUgcHVibGlzaGVkIGFmdGVyIGEgY291cGxlIG9m IGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkIChzZWUgYmVsb3cpLg0KDQpXZSdyZSBnZXR0aW5n IHRoZXJlLg0KDQoNCj4gSSBkb24ndCBoYXZlIHRoZSBleHBlcnRpc2UgdG8gdGVsbCBpZiB0aGUg c29sdXRpb24gaXMgc2VjdXJlIGVub3VnaCBvcg0KPiBub3QuDQoNClRoaXMgY29tbWVudCBoYXMg YmVlbiBtYWRlIGJ5IG90aGVycyBhcyB3ZWxsLiAgVGhlIGFzc3VtcHRpb24gaXMgdGhhdA0KU2Vj RGlyIHdpbGwgZG8gdGhhdCBldmFsdWF0aW9uLiAgSXMgdGhhdCBmYWlyPw0KDQoNCj4gSGVyZSBh cmUgbXkgY29tbWVudHMuDQo+IA0KPiBNYWpvciBpc3N1ZXMNCj4gLS0tLS0tLS0tLS0tDQo+DQo+ IG8gIFNlY3Rpb24gNy4yDQo+DQo+ICBBZGRpbmcgY3VzdG9tIHF1ZXJ5IHBhcmFtZXRlcnMgbGlr ZSB0aGlzIGJyZWFrcyB0aGUgbm9ybWFsIFlBTkcNCj4gIGNvbnRyYWN0LiAgSWYgSSB1bmRlcnN0 YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgaW5zdGFuY2UgZGF0YSB0cmVlDQo+ICBwcmVzZW50ZWQg dG8gdGhlIGNsaWVudCBpcyBzdXBwb3NlZCB0byBjaGFuZ2UgYmFzZWQgb24gdGhlc2UgcXVlcnkN Cj4gIHBhcmFtZXRlcnMuDQoNCkNvcnJlY3QuICBUaGUgaWRlYSBpcyB0aGF0IHRoZSByZXNwb25z ZSBjb3VsZCB2YXJ5IGJhc2VkIG9uIHRoZSBpbnB1dA0KcXVlcnkgcGFyYW1zLiAgT2YgY291cnNl LCBpbiBjYXNlIHRoZXJlIHdhcyBhbnkgZG91YnQsIHRoZSByZXNwb25zZSANCndvdWxkIGFsd2F5 cyBjb25mb3JtIHRvIHNhbWUgWUFORyBzY2hlbWEuDQoNCg0KPiAgSWYgeW91IHJlYWxseSBuZWVk IHRvIGhhdmUgdGhhdCBmdW5jdGlvbmFsaXR5LCBpdCB3b3VsZCBiZXR0ZXIgdG8NCj4gIG1vZGVs IHRoZSBkZXZpY2Utc3BlY2lmaWMgZGF0YSBhcyBhbiBhY3Rpb247IGlucHV0IHdvdWxkIGJlIHRo ZQ0KPiAgb3MtbmFtZSwgb3MtdmVyc2lvbiBldGMsIGFuZCBvdXRwdXQgd291bGQgYmUgdGhlDQo+ ICB6ZXJvdG91Y2gtaW5mb3JtYXRpb24gYW5kIHZvdWNoZXIgZXRjLg0KDQpJIHRob3VnaHQgb2Yg dGhpcyBhcyB3ZWxsLCBidXQgZGlkbid0IGRvIGFueXRoaW5nIGFib3V0IGl0IGFzIG15IA0KbGFz dCBtZXNzYWdlIHRvIHRoZSBsaXN0IHNhaWQgdGhhdCB3ZSdkIGFkZCAicXVlcnkgcGFyYW1ldGVy cyINCmFuZCBJIHdhbnRlZCB0byBmb2xsb3cgdGhyb3VnaCBvbiB0aGF0IHN0YXRlbWVudC4NCg0K QnV0IHdoYXQgaXMgdGhlIGlzc3VlPyAgSXMgaXQgcHJpbWFyaWx5IHRoYXQgdXNpbmcgcXVlcnkg cGFyYW1zIA0Kb24gR0VUIHNob3VsZCBiZSBsaW1pdGVkIHRvIHJldHVybmluZyBkaWZmZXJlbnQg cmVwcmVzZW50YXRpb25zDQpvZiBhIHJlc291cmNlLCBhbmQgdGhpcyB1c2Ugc2VlbXMgdG8gYmUg cmV0dXJuaW5nIGRpZmZlcmVudCANCnJlc291cmNlcyBhbHRvZ2V0aGVyPyAgSSB0aGluayB0aGF0 IHRoaXMgaXMgYSBncmV5IGFyZWEsIGJ1dA0KYXBwcmVjaWF0ZSB0aGUgcGVyc3BlY3RpdmUuDQoN CkFsdGVybmF0aXZlbHksIGlzIHRoZSBpc3N1ZSBtb3JlIHByYWdtYXRpYywgaW4gdGhhdCB0aGUg bGlzdCBvZg0KcXVlcnkgcGFyYW1zIHNlZW1zIHVuYm91bmRlZCwgYW5kIHdlIG1pZ2h0IHJ1biBv dXQgb2Ygcm9vbSBvbg0KdGhlIFVSTCBzdHJpbmcgKDEwMjQgY2hhcnM/KSBzb21lZGF5PyAgT3Ig bWF5YmUgcGVyaGFwcyB0aGF0DQppbnB1dCBjYW4gYmUgaGllcmFyY2hhbCB3aGVyZWFzIHBhcmFt cyBjYW4ndD8NCg0KSSBpbWFnaW5lIHRoZSBhbnN3ZXIgaXMgImFsbCBvZiB0aGUgYWJvdmUiICA7 KQ0KDQpGV0lXLCBpZiB3ZSB3ZXJlIHRvIGRvIHRoaXMsIHdlIG1pZ2h0IGFsc28gY29uc2lkZXIg bW92aW5nIHRoZSANCidzZXJpYWwtbnVtYmVyJyBmaWVsZCBmcm9tIHRoZSBVUkwgdG8gYW4gaW5w dXQgZmllbGQsIGFuZCBtYWtlDQphIHNpbWlsYXIgY2hhbmdlIHRvIHRoZSAndXBkYXRlLXByb2dy ZXNzJyBhY3Rpb24uICBCdXQgdGhhdCB0aGVuDQp3b3VsZCBtZXNzIHVwIHlvdXIgTkFDTSBydWxl IGJlbG93LiAgVGhvdWdodHM/DQoNCg0KPiAgQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3QgZGlzY3Vz cyB0aGluZ3MgbGlrZSAib25lLXRpbWUgdXNlIHZvdWNoZXIiOw0KPiAgdGhpcyB0ZXJtIGlzIGp1 c3QgdXNlZCBoZXJlLiAgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHJlcXVpcmVzIG1vcmUNCj4g IGRlc2NyaXB0aXZlIHRleHQuDQoNCkdvb2QgY2F0Y2guICBkcmFmdC1pZXRmLWFuaW1hLXZvdWNo ZXIgaW5mb3JtYWxseSBjYWxscyBpdCBhbiAiYXVkaXQNCnZvdWNoZXIiLCB3aGljaCBpcyBhbiB1 bmZvcnR1bmF0ZSBtaXNub21lci4gICBOb25ldGhlbGVzcywgcG9pbnQgdGFrZW4sDQp0aGUgZHJh ZnQgc2hvdWxkIHRpZSBpbnRvIHdoYXQncyBpbiB0aGUgdm91Y2hlciBkcmFmdC4gIE1heCBQcml0 aWtpbg0KdG9sZCBtZSBhIGNvdXBsZSB3ZWVrcyBhZ28gdGhhdCBjYWxsaW5nIGl0IGEgIm5vbmNl ZCB2b3VjaGVyIiBvciBhIA0KInZvdWNoZXIgd2l0aCBhIG5vbmNlIiB3YXMgcHJvYmFibHkgYmVz dC4gIEJUVywgdGhpcyBzZWVtcyBsaWtlIGFuDQplZGl0b3JpYWwgZml4IHRvIG1lLCBidXQgSSBj YW4gc2VlIGhvdyBpdCBjb3VsZCBsb29rIGxpa2UgYSBtYWpvcg0KaXNzdWUgaWYgeW91IGRpZG4n dCBrbm93IHdoYXQgdGhlIHRleHQgd2FzIGFsbHVkaW5nIHRvLi4uIA0KDQoNCj4gbyAgU2VjdGlv biA0LjQNCj4NCj4gICAgIFdoZW4gYSBkZXZpY2UgaXMNCj4gICAgIG5vdCBhYmxlIHRvIHRydXN0 IGEgYm9vdHN0cmFwIHNlcnZlciwgaXQgTVVTVCBOT1Qgc2VuZCBpdHMgSURldklEDQo+ICAgICBj ZXJ0aWZpY2F0ZSBpbiB0aGUgZm9ybSBvZiBhIFRMUyBjbGllbnQgY2VydGlmaWNhdGUNCj4NCj4g IEhvdyB3aWxsIHRoZSBzZXJ2ZXIgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaW4gdGhpcyBjYXNl Pw0KDQpUaGUgaWRlYSBpcyB0aGF0IHRoZSBzZXJ2ZXIgZG9lc24ndCBhdXRoIHRoZSBjbGllbnQg aW4gdGhpcyBjYXNlLg0KVGhlIGdvYWwgYmVoaW5kIG5vdCBzZW5kaW5nIHRoZSBJRGV2SUQgY2Vy dGlmaWNhdGUgd2FzIHNvIGEgcm91Z2UNCmJvb3RzdHJhcCBzZXJ2ZXIgd291bGRuJ3QgYmUgYWJs ZSB0byBkaXNjb3ZlciB0aGUgZGV2aWNlJ3Mgc2VyaWFsDQpudW1iZXIsIHdoaWNoIGlzIHdoeSBB cHBlbmRpeCBCIHN1Z2dlc3RzIGFsc28gbWFza2luZyB0aGUgc2VyaWFsDQpudW1iZXIgdGhlIGRl dmljZSBzZW5kcyBpbiB0aGUgVVJMLiAgVGhhdCBzYWlkLCB3ZSBtaWdodCBuZWVkIHRvDQpyZXRo aW5rIHRoaXMsIGVzcGVjaWFsbHkgaW4gY29uanVuY3Rpb24gd2l0aCB5b3VyIG5leHQgY29tbWVu dC4gIA0KKGNvbnRpbnVlZCBiZWxvdykgIA0KDQoNCj4gIEkgc2VlIHRoYXQgaW4gc2VjdGlvbiA3 LjMgeW91IGhhdmU6DQo+DQo+ICAgTm90ZSB0aGF0IHRoZSBib290c3RyYXAgc2VydmVyIE1VU1Qg Tk9UIHByb2Nlc3MgYSBwcm9ncmVzcyB1cGRhdGUNCj4gICBmcm9tIGEgZGV2aWNlIHdpdGhvdXQg Zmlyc3QgYXV0aGVudGljYXRpbmcgdGhlIGRldmljZS4gIFRoaXMgaXMgaW4NCj4gICBjb250cmFz dCB0byB3aGVuIGEgZGV2aWNlIGlzIGZldGNoaW5nIGRhdGEgZnJvbSB0aGUgc2VydmVyLCBhIHJl YWQtDQo+ICAgb25seSBvcGVyYXRpb24sIGluIHdoaWNoIGNhc2UgZGV2aWNlIGF1dGhlbnRpY2F0 aW9uIGlzIG5vdCBzdHJpY3RseQ0KPiAgIHJlcXVpcmVkIChlLmcuLCB3aGVuIHNlbmRpbmcgc2ln bmVkIGluZm9ybWF0aW9uKS4NCj4NCj4gIEJ1dCB0aGUgc2VydmVyIGlzIGEgbm9ybWFsIFJFU1RD T05GIHNlcnZlciwgc28gaXQgd2lsbCBmb2xsb3cNCj4gIHNlY3Rpb24gMi41IG9mIFJGQyA4MDQw OyBpdCB3aWxsIHJlcXVpcmUgY2xpZW50cyB0byBiZQ0KPiAgYXV0aGVudGljYXRlZC4NCg0KSSB3 YXMgaG9waW5nIHRoYXQgdGhlIGRyYWZ0IGNvdWxkIHN1cHByZXNzIHRoaXMgYXV0aCByZXF1aXJl bWVudA0KZm9yIHRoaXMgc3BlY2lmaWMgInVudHJ1c3RlZCIgaW50ZXJhY3Rpb24uICBJbiBlc3Nl bmNlLCByZWR1Y2luZw0KdGhlIGJvb3RzdHJhcCBzZXJ2ZXIgdG8gYSBzaW1wbGUgZmlsZSBzZXJ2 ZXIgcHJvdmlkaW5nIGFub255bW91cw0KcmVhZC1hY2Nlc3MuDQoNCkJ1dCBpbiB0aGUgc2VjdXJp dHkgYW5hbHlzaXMgb2YgdGhpbmdzLCBpdCBjb21lcyBkb3duIHRvIHdoYXQncyANCm1vcmUgaW1w b3J0YW50IHRvIHByZXZlbnQ6DQogYSkgYSByb2d1ZSBzZXJ2ZXIgZGlzY292ZXJpbmcgYSB2YWxp ZCBkZXZpY2UncyBzZXJpYWwgbnVtYmVyLA0KICAgIHdoaWxlIG5vdCBiZWluZyBhYmxlIHRvIHBy b3ZpZGUgdGhlIGRldmljZSBhIHJlc3BvbnNlIHRoZQ0KICAgIGRldmljZSBjYW4gdHJ1c3QsIG9y DQogYikgYSB2YWxpZCBzZXJ2ZXIgZ2l2aW5nIHNpZ25lZCByZWRpcmVjdCBpbmZvcm1hdGlvbiB0 byBhDQogICAgcm9ndWUgZGV2aWNlLCB3aGVyZSB0aGUgaW5mb3JtYXRpb24gZ2l2ZW4gZG9lc24n dCBwcm92aWRlDQogICAgdGhlIGRldmljZSBhbnkgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHRoZSBk ZXZpY2UgbXVzdCBoYXZlDQogICAgYWxyZWFkeSBoYWQgdG8gbWFrZSB0aGUgcmVxdWVzdCBpbiB0 aGUgZmlyc3QgcGxhY2UsIG90aGVyDQogICAgdGhhbiBhIGNvbmZpcm1hdGlvbiB0aGF0IGluZGVl ZCB0aGF0IHNlcmlhbCBudW1iZXIgaXMgb25lDQogICAgdGhhdCB0aGUgc2VydmVyIGlzIGV4cGVj dGluZy4gIA0KDQpMb29raW5nIGF0IGl0IHRoaXMgd2F5LCAoYikgaXMgbW9yZSBpbXBvcnRhbnQg dG8gcHJldmVudCBhbmQsIA0KYmVzaWRlczoNCjEpIHRoZXJlIGlzIGFscmVhZHkgYSBTZWN1cml0 eSBDb25zaWRlcmF0aW9uIHJlbGF0ZWQgdG8gdGhlIHVzZQ0KICAgb2Ygc2VyaWFsIG51bWJlcnMg aW4gdGhlIHNvbHV0aW9uLCBzbyAoYSkgc2VlbXMgdG8gYmUganVzdA0KICAgbW9yZSBvZiB0aGUg c2FtZSwgDQoyKSByb2d1ZSBjb25uZWN0aW9ucyBjb3VsZCBwbGF5IGhhdm9jIHdpdGggdGhlIHNl cnZlcidzIGxvZ3MsIGFuZA0KMykgKHRvIHlvdXIgcG9pbnQpIGl0IHdvdWxkIGJlIHRyaWNreSBi dXNpbmVzcyB0byBkZWZpbmUgYW4NCiAgIGV4Y2VwdGlvbiBmb3IgdGhlIHN0YW5kYXJkIFJFU1RD T05GIHNlcnZlciB0byBmb2xsb3cuDQoNCkFsbCB0aGlzIGlzIHRvIHNheSB0aGF0IEkgdGhpbmsg d2Ugc2hvdWxkIGdvIGJhY2sgdG8gdGhlIGRldmljZQ0KYWx3YXlzIHNlbmRpbmcgaXRzIElEZXZJ RCBjZXJ0IGFuZCwgb2YgY291cnNlLCB0aGUgc2VydmVyIGFsd2F5cw0KYXV0aGVudGljYXRpbmcg dGhlIGRldmljZS4gIEJ1dCBJIGFsc28gdGhpbmsgdGhhdCBhIGRldmljZSBzaG91bGQNCmNvbnRp bnVlIE5PVCBzZW5kaW5nIGFueSBvdGhlciBpbmZvcm1hdGlvbiAoaS5lLiBxdWVyeSBwYXJhbXMs DQpwcm9ncmVzcyB1cGRhdGVzLCBldGMuKSwgYmV5b25kIGl0cyBzZXJpYWwgbnVtYmVyICYgSURl dklEIGNlcnQsDQp1bnRpbCBpdCBjYW4gZnVsbHkgYXV0aGVudGljYXRlIHRoZSBzZXJ2ZXIuDQoN Cg0KDQo+IE5vcm1hbCBpc3N1ZXMNCj4gLS0tLS0tLS0tLS0tLQ0KPg0KPiBvICBTZWN0aW9uIDEu Mg0KPiAgICAgICBUaGUgdGVybSAibWFudWZhY3R1cmVyIiBpcyB1c2VkIGhlcmVpbiB0byByZWZl ciB0byB0aGUNCj4gICAgICAgbWFudWZhY3R1cmVyIG9mIGEgZGV2aWNlIG9yIGEgZGVsZWdhdGUg b2YgdGhlIG1hbnVmYWN0dXJlci4NCj4NCj4gIEluIHRoZSB0ZXh0IHlvdSBzb21ldGltZXMgdXNl ICJtYW51ZmFjdHVyZXIiIGFuZCBzb21ldGltZXMNCj4gICJtYW51ZmFjdHVyZXIgb3QgZGVsZWdh dGUiLiAgUGVyaGFwcyB0aGUgdGVybSAibWFudWZhY3R1cmVyIiBzaG91bGQNCj4gIGJlIHJlc2Vy dmVkIHRvIG1lYW4ganVzdCB0aGUgbWFudWZhY3R1cmVyLCBhbmQgdGhlbiB1c2UNCj4gICJtYW51 ZmFjdHVyZXIgb3IgZGVsZWdhdGUiIGluIHRoZSBwbGFjZXMgd2hlcmUgdGhhdCdzIGFwcHJvcHJp YXRlLg0KDQpJIG1lYW4gZm9yIGl0IHRvIGFsd2F5cyBiZSAibWFudWZhY3R1cmVyIG9yIGRlbGVn YXRlIi4gIFRoZSBiZXR0ZXINCmZpeCBpcyB0byByZW1vdmUgIm9yIGRlbGVnYXRlIiB0aHJvdWdo b3V0IHRoZSBkb2N1bWVudC4gIEFncmVlZD8NCg0KDQo+IG8gIFNlY3Rpb24gMy4yDQo+DQo+ICBJ biB0aGUgZmlyc3QgcGFyYWdyYXBoLCBtYXliZSBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIFJGQyA1 MjgwLg0KDQpZZXMuDQoNCg0KPiBvICBTZWN0aW9uIDUuMQ0KPg0KPiAgVGhlIG51bWJlcnMgaW4g dGhlIHBpY3R1cmUgZG9uJ3QgbWF0Y2ggdGhlIG51bWJlcnMgaW4gdGhlIGxpc3QNCj4gIChzcGVj aWZpY2FsbHkgNC01KS4NCg0KT29vcHMsIEkgbWVhbnQgMiAmIDMgdG8gYmUgMmEgYW5kIDJiIHJl c3BlY3RpdmVseS4gIFdpbGwgZml4LCBtb3N0DQpsaWtlbHkgYnkgZmxhdHRlbmluZyB0aGUgKDIp IHRleHQgaW50byBkaXN0aW5jdCAyICYgMyBzZWN0aW9ucw0KYWdhaW4uDQoNCg0KPiBvICBTZWN0 aW9uIDUuNg0KPg0KPiAgICAgVXBvbiByZWJvb3RpbmcsIHRoZSBkZXZpY2UgTVVTVCBzdGlsbCBi ZQ0KPiAgICAgaW4gaXRzIGluaXRpYWwgc3RhdGUsIGNhdXNpbmcgdGhlIGJvb3RzdHJhcHBpbmcg cHJvY2VzcyB0byBydW4gYWdhaW4sDQo+ICAgICB3aGljaCB3aWxsIGV2ZW50dWFsbHkgY29tZSB0 byB0aGlzIHZlcnkgcG9pbnQsDQo+DQo+ICBXaHkgdGhpcyBNVVNUPyAgV2hhdCBpZiB0aGUgbmV3 IGJvb3QgaW1hZ2UgY29udGFpbnMgb3RoZXIgZmFjdG9yeQ0KPiAgZGVmYXVsdHMgdGhhdCBkb2Vz IG5vdCBlbmFibGUgWlRQLCB3b3VsZCB0aGF0IGJlIGlsbGVnYWw/DQo+DQo+ICBJIHdvdWxkIHRo aW5rIHRoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBmcmVlIHRvIGRvIHdoYXRldmVyIHRoZXkgd2Fu dA0KPiAgaW4gY2FzZSBvZiBlcnJvcnMuDQoNCk1heWJlIG5vdCAqaWxsZWdhbCosIGJ1dCBpdCB3 b3VsZCBjZXJ0YWlubHkgYnJpY2sgdGhlIGRldmljZSBhdCB0aGF0DQpwb2ludC4gIFdvdWxkIGp1 c3QgcmVkdWNpbmcgdGhlICJNVVNUIiB0byBhICJtdXN0IiBzdWZmaWNlLCBvciBzaG91bGQNCndl IGFkZCBhIHF1YWxpZmllciBhbG9uZyB0aGUgbGluZXMgb2YgImluIG9yZGVyIGZvciB0aGUgc29s dXRpb24gdG8NCndvcmsuLi4iID8NCg0KDQo+ICAgIEluIHRoZSBjYXNlIG9mIGVycm9ycywgdGhl IGRldmljZSBNVVNUIHJlc2V0DQo+ICAgIGl0c2VsZiBpbiBzdWNoIGEgd2F5IHRoYXQgZm9yY2Vz IGEgcmVpbnN0YWxsYXRpb24gb2YgdGhlIGJvb3QgaW1hZ2UsDQo+ICAgIHRoZXJlYnkgd2lwaW5n IG91dCBhbnkgYmFkIHN0YXRlIHRoZSBzY3JpcHQgbWF5IGhhdmUgbGVmdCBiZWhpbmQuDQo+DQo+ ICBJcyB0aGlzIGFsc28gcmVxdWlyZWQ/ICBXaHkgY2FuJ3Qgc3RvcCBhbmQgd2FpdCBmb3IgbWFu dWFsDQo+ICBpbnRlcnZlbnRpb24gYmUgYWxsb3dlZD8NCg0KSXQgY291bGQsIGJ1dCBhZ2Fpbiwg aXQgd291bGQgYnJpY2sgdGhlIGRldmljZS4gIFNhbWUgcXVlc3Rpb24gYXMgYWJvdmUsDQp3b3Vs ZCByZWR1Y2luZyB0aGUgIk1VU1QiIHRvIGEgIm11c3QiIHN1ZmZpY2UsIG9yIHNob3VsZCB3ZSBh ZGQgYSANCnF1YWxpZmllciBhbG9uZyB0aGUgbGluZXMgb2YgImluIG9yZGVyIGZvciB0aGUgc29s dXRpb24gdG8gd29yay4uLiIgPw0KDQoNCj4gbyAgU2VjdGlvbiA3LjMNCj4NCj4gIFRoZSBleGFt cGxlcyBoYXZlICJkZXZpY2U9MTIzNDU2IiBpbiB0aGUgVVJMczsgaXQgc2hvdWxkIGJlDQo+ICAi ZGV2aWNlPTEyMzQ1Njc4OSIuDQoNClllcy4NCg0KDQo+ICBJIHN1Z2dlc3QgeW91IHNob3J0ZW4g dGhlIGxpbmVzIG9mIHRoZSBleGFtcGxlcyBldmVuIG1vcmUsIHNvIHRoYXQNCj4gIHRoZSBleGFt cGxlcyBhcmUgcHJvcGVybHkgaW5kZW50ZWQgaW4gdGhlIGRyYWZ0ICh0aGV5IGFyZSBjdXJyZW50 bHkNCj4gIG91dGRlbnRlZCkNCg0KSXQncyBoYXJkIHRvIG1ha2UgdGhlIGxpbmVzIG11Y2ggc2hv cnRlciB3aXRoIHRoZSBVUk4gYmVpbmcgc28gbG9uZy4NCk9wdGlvbnMgYXJlIDEpIGRvbid0IGlu ZGVudCBqdXN0IHRoZSB4bWxucyBsaW5lIG9yIDIpIG1vdmUgZnJvbSB0d28tDQpzcGFjZSBpbmRl bnQgdG8gc2luZ2xlLXNwYWNlIGluZGVudC4gIERvIHlvdSBoYXZlIGEgcHJlZmVyZW5jZT8NCg0K DQo+IG8gIFNlY3Rpb24gOQ0KPg0KPiAgU2hvdWxkIHlvdSBhbHNvIG1lbnRpb24gdGhhdCAvZGV2 aWNlIGxpc3Qgc2hvdWxkIGJlIHByb3RlY3RlZCBieQ0KPiAgbmFjbSBydWxlcz8NCg0KWWVzLCBp bmRlZWQsIEkgbGVmdCBvdXQgdGhlIHN0YW5kYXJkIHNlY3VyaXR5IHRlbXBsYXRlIGZvciB0aGUg Ym9vdHN0cmFwDQpzZXJ2ZXIgWUFORyBtb2R1bGUuICBXaWxsIGFkZC4NCg0KDQo+ICBJZiB0aGUg UkVTVENPTkYgdXNlciBuYW1lIGlzIHRoZSBkZXZpY2UncyB1bmlxdWUtaWQsIHRoZW4gYSBzaW5n bGUNCj4gIE5BQ00gcnVsZSBjYW4gYmUgdXNlZDoNCj4NCj4gICAgICAgPHJ1bGU+DQo+ICAgICAg ICAgPG5hbWU+YWxsb3ctZGV2aWNlPC9uYW1lPg0KPiAgICAgICAgIDxwYXRoIHhtbG5zOnp0YnM9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpcaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNl cnZlciI+DQo+ICAgICAgICAgICAvenRiczpkZXZpY2VbenRiczp1bmlxdWUtaWQ9JFVTRVJdDQo+ ICAgICAgICAgPC9wYXRoPg0KPiAgICAgICAgIDxhY2Nlc3Mtb3BlcmF0aW9ucz5yZWFkPC9hY2Nl c3Mtb3BlcmF0aW9ucz4NCj4gICAgICAgICA8YWN0aW9uPnBlcm1pdDwvYWN0aW9uPg0KPiAgICAg ICA8L3J1bGU+DQoNClllcywgYnV0IHdvdWxkIHlvdSBleHBlY3QgdGhpcyB0byBhcHBlYXIgaW4g dGhlIGRyYWZ0PyAgVHlwaWNhbGx5LCB0aGUgc3BlY2lmaWMNCk5BQ00gcnVsZSBzeW50YXggaXMg bGVmdCBhcyBhbiBleGVyY2lzZSB0byB0aGUgcmVhZGVyLi4uDQoNCg0KPiBvICBpZXRmLXplcm90 b3VjaC1pbmZvcm1hdGlvbi55YW5nDQo+DQo+ICBvIHNoYTI1NiBpcyBkZWZpbmVkIGxpa2UgdGhp czoNCj4NCj4gICAgICAgICAgICAgbGVhZiBzaGEyNTYgew0KPiAgICAgICAgICAgICAgICB0eXBl IHN0cmluZzsNCj4gICAgICAgICAgICAgICAgICAiVGhlIGhleC1lbmNvZGVkIFNIQS0yNTYgaGFz aCBvdmVyIHRoZSBib290DQo+ICAgICAgICAgICAgICAgICAgIGltYWdlIGZpbGUuDQo+DQo+ICAg IFNob3VsZCB0aGlzIGJlIHR5cGUgeWFuZzpoZXgtc3RyaW5nPyAgSWYgbm90LCBJIHRoaW5rIHlv dSBuZWVkIHRvDQo+ICAgIHNwZWNpZnkgaG93IHRoZSBoZXgtY2hhcnMgYXJlIGVuY29kZWQgaW4g dGhlIHN0cmluZy4NCg0KWWVzLCBpdCBzaG91bGQgYmUgeWFuZzpoZXgtc3RyaW5nLg0KDQoNCj4g ICBvIHVyaSBpcyBkZWZpbmVkIGxpa2UgdGhpczoNCj4NCj4gICAgICAgICAgbGVhZi1saXN0IHVy aSB7DQo+ICAgICAgICAgICAgdHlwZSBpbmV0OnVyaTsNCj4gICAgICAgICAgICBtaW4tZWxlbWVu dHMgMTsNCj4gICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgIkFuIG9yZGVy ZWQgbGlzdCBvZiBVUklzIHRvIHdoZXJlIHRoZSBib290LWltYWdlIGZpbGUgTUFZDQo+ICAgICAg ICAgICAgICAgYmUgb2J0YWluZWQuDQo+DQo+ICAgVGhpcyBsZWFmLWxpc3Qgc2hvdWxkIGJlIG9y ZGVyZWQtYnkgdXNlciB0byBpbmRpY2F0ZSB0aGF0IHRoZSBvcmRlciBpcw0KPiAgIHNpZ25pZmlj YW50Lg0KDQpZZXMsIGl0IHNob3VsZCBiZSBvcmRlcmVkLWJ5IHVzZXIuDQoNCg0KPiBvICBpZXRm LXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyLnlhbmcNCj4NCj4gIG8gdGhlIGFjdGlvbiAidXBk YXRlLXByb2dyZXNzIiBzaG91bGQgaGF2ZSBhIGRlc2NyaXB0aW9uDQoNClN0cmFuZ2UsIHRoaXMg d2Fzbid0IGNhdWdodCBieSBhbnkgb2Y6DQogIHB5YW5nIC0taWV0ZiAtLXN0cmljdCAuLi4NCiAg cHlhbmcgLS1jYW5vbmljYWwgLi4uDQogIHlhbmdsaW50IC4uLg0KDQpCdXQgd2lsbCBhZGQgYW55 d2F5cy4NCg0KDQo+ICBvICAgICBJZiBhIHNjcmlwdCBpcyBlcnJvbmVvdXNseSBwcm92aWRlZCB0 byBhIGRldmljZSB0aGF0IGRvZXMgbm90DQo+ICAgICAgICBzdXBwb3J0IHRoZSBleGVjdXRpb24g b2Ygc2NyaXB0cywgdGhlIGRldmljZSBTSE9VTEQgc2VuZCBhDQo+ICAgICAgICAnc2NyaXB0LXdh cm5pbmcnIG5vdGlmaWNhdGlvbiBtZXNzYWdlDQo+DQo+ICAgIFJlcGhyYXNlIHRvIGF2b2lkIHRo ZSB0ZXJtICJub3RpZmljYXRpb24gbWVzc2FnZSINCj4gICAgQWxzbywgdGhlIHR5cGVzIGFyZSAi cHJlLXNjcmlwdC13YXJuaW5nIiBhbmQgInBvc3Qtc2NyaXB0LXdhcm5pbmciLg0KDQpXaWxsIGZp eC4NCg0KDQo+ICAgbyBUaGUgZGVzY3JpcHRpb24gb2YgdGhlICJzY3JpcHQiIHR5cGVkZWYgc2F5 czoNCj4NCj4gICAgICAgTm8gYXR0ZW1wdCBpcyBtYWRlIHRvIHN0YW5kYXJkaXplIHRoZSBjb250 ZW50cywgcnVubmluZyBjb250ZXh0LA0KPiAgICAgICBvciBwcm9ncmFtbWluZyBsYW5ndWFnZSBv ZiB0aGUgc2NyaXB0Lg0KPiAgICAgICBbLi4uXQ0KPiAgICAgICBUaGUgc2NyaXB0IHJldHVybnMg ZXhpdCBzdGF0dXMgY29kZSAnMCcgb24gc3VjY2VzcyBhbmQgbm9uLXplcm8NCj4gICAgICAgb24g ZXJyb3IsIHdpdGggYWNjb21wYW55aW5nIHN0ZGVyci9zdGRvdXQgZm9yIGxvZ2dpbmcgcHVycG9z ZXMuDQo+DQo+ICAgICBJIHRoaW5rIHRoZSBsYXN0IHF1b3RlZCBzZW50ZW5jZSBjb250cmFkaWN0 cyB0aGUgZmlyc3QgLSBpdCBkb2VzIGluDQo+ICAgICBmYWN0IG1ha2UgYXNzdW1wdGlvbnMgYWJv dXQgdGhlIHJ1bm5pbmcgY29udGV4dCBvZiB0aGUgc2NyaXB0Lg0KPg0KPiAgICAgSSBzdWdnZXN0 IHRoZSBsYXR0ZXIgc2VudGVuY2UgaXMgcmVtb3ZlZCwgYW5kIHRoZSByZXN0IG9mIHRoZSB0ZXN0 DQo+ICAgICBhZGp1c3RlZC4gIERvbid0IHRhbGsgYWJvdXQgZXhpdCBjb2RlcywgYnV0IGluc3Rl YWQgdGFsayBhYm91dA0KPiAgICAgInN1Y2Nlc3MiIG9yICJlcnJvciIgZXRjLg0KDQpXaWxsIGRv Lg0KDQoNCj4gbyAgT3RoZXIgY29tbWVudA0KPg0KPiAgSXMgaXQgYXNzdW1lZCB0aGF0IHRoZXJl IHdpbGwgYmUgYSB2ZW5kb3Itc3BlY2lmaWMgWUFORyBtb2R1bGUgdG8NCj4gIGVuYWJsZSB0aGUg emVyby10b3VjaCBwcm9jZXNzPyAgRGlkIHlvdSBjb25zaWRlciBhbg0KPiAgaWV0Zi16ZXJvdG91 Y2gtZGV2aWNlIG1vZHVsZSBmb3IgdGhpcyBwdXJwb3NlPyAgU3VjaCBhIGNvbmZpZ3VyYXRpb24N Cj4gIG11c3QgYmUgY2FyZWZ1bGx5IGRlc2lnbmVkIHRvIGFsbG93IGZvciBhICJtZXJnZSIgY29u ZmlndXJhdGlvbiBmaWxlDQo+ICB0byBhY3R1YWxseSBkaXNhYmxlIHRoZSB6ZXJvIHRvdWNoIHBy b2Nlc3MuDQoNCkl0IGlzIGFzc3VtZWQgdG8gYmUgdmVuZG9yLXNwZWNpZmljIGN1cnJlbnRseS4g IEkgaGF2ZSBub3QgdGhvdWdodCB0bw0KZGVmaW5lIGEgaWV0Zi16ZXJvdG91Y2gtZGV2aWNlIG1v ZHVsZSBhcyBvZiB5ZXQgdGhhdCwgcHJlc3VtYWJseSwgd291bGQNCmNvbnRhaW4gYSBib29sZWFu IG9yIGFuIGVudW0gKGJ1dCBub3QgYSBwLWNvbnRhaW5lcikgZm9yIGVuYWJsaW5nIHRoZQ0Kc2Vy dmljZS4gIERvIHlvdSB0aGluayB3ZSBzaG91bGQgYWRkIHN1Y2ggYSBtb2R1bGUgdG8gdGhlIGRy YWZ0LCBvciBqdXN0DQpwdXQgYSBub3RlIHNvbWV3aGVyZSBhYm91dCBpdD8NCg0KDQo+IEVkaXRv cmlhbCBuaXRzOg0KPiAtLS0tLS0tLS0tLS0tLS0NCj4NCj4gbyAgdXNlICIiIGluc3RlYWQgb2Yg JycgY29uc2lzdGVudGx5ICAoZXhjZXB0IGluIFlBTkcgc3RyaW5ncykNCg0KVGhhbmtzLiBXaWxs IGRvdWJsZS1jaGVjayBhbGwuDQoNCg0KPiBvICB5b3UgcHJvYmFibHkgc2hvdWxkIGluY2x1ZGUg YSByZWZlcmVuY2UgdG8gSVRVLVQgWC42OTAuDQoNCldpbGwgZG8uDQoNCg0KPiBvICBzL2Jvb3Rz dHJhcCBkYXRhL2Jvb3RzdHJhcHBpbmcgZGF0YS8NCg0KR29vZCBjYXRjaCwgdGhvdWdodCBJIGdv dCB0aGVtIGFsbCBiZWZvcmUuDQoNCg0KPiBvICBJIHN1Z2dlc3QgeW91IHJ1biB0aGUgbW9kdWxl cyB0aHJvdWdoICdweWFuZyAtZiB5YW5nDQo+ICAgLS1rZWVwLWNvbW1lbnRzJyBpbiBvcmRlciB0 byBmaXggc29tZSBpbmNvbnNpc3RlbnQgaW5kZW50YXRpb25zDQoNCldpbGwgZG8uDQoNCg0KVGhh bmtzIGFnYWluIQ0KS2VudA0KDQoNCg0KDQo= From nobody Thu Sep 28 00:46:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A750E135457 for ; Thu, 28 Sep 2017 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCfhY8ILZX_B for ; Thu, 28 Sep 2017 00:46:48 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EF135449 for ; Thu, 28 Sep 2017 00:46:46 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id EFF8A1AE02A7; Thu, 28 Sep 2017 09:46:44 +0200 (CEST) Date: Thu, 28 Sep 2017 09:45:14 +0200 (CEST) Message-Id: <20170928.094514.526215195914925651.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> <20170926.192701.1726303533240950350.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] WG LC for zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:46:51 -0000 Kent Watsen wrote: > Hi Martin, > > Thanks for your review! Comments below. > > K. > > > > I have reviewed this document, and I believe the document is ready to > > be published after a couple of issues have been addressed (see below). > > We're getting there. > > > > I don't have the expertise to tell if the solution is secure enough or > > not. > > This comment has been made by others as well. The assumption is that > SecDir will do that evaluation. Is that fair? Fine with me! > > Here are my comments. > > > > Major issues > > ------------ > > > > o Section 7.2 > > > > Adding custom query parameters like this breaks the normal YANG > > contract. If I understand this correctly, the instance data tree > > presented to the client is supposed to change based on these query > > parameters. > > Correct. The idea is that the response could vary based on the input > query params. Of course, in case there was any doubt, the response > would always conform to same YANG schema. See below. > > If you really need to have that functionality, it would better to > > model the device-specific data as an action; input would be the > > os-name, os-version etc, and output would be the > > zerotouch-information and voucher etc. > > I thought of this as well, but didn't do anything about it as my > last message to the list said that we'd add "query parameters" > and I wanted to follow through on that statement. > > But what is the issue? Is it primarily that using query params > on GET should be limited to returning different representations > of a resource, and this use seems to be returning different > resources altogether? Yes, this is my concern. A normal RESTCONF / YANG server has *one* single instance of the operational state, and it just provides an API to this data. It can be filtered and pruned based on access rights, but not modified from the outside based on query parameters. > I think that this is a grey area, but > appreciate the perspective. > > Alternatively, is the issue more pragmatic, in that the list of > query params seems unbounded, and we might run out of room on > the URL string (1024 chars?) someday? Or maybe perhaps that > input can be hierarchal whereas params can't? > > I imagine the answer is "all of the above" ;) > > FWIW, if we were to do this, we might also consider moving the > 'serial-number' field from the URL to an input field Hmm, did you mean 'unique-id'? > , and make > a similar change to the 'update-progress' action. But that then > would mess up your NACM rule below. Thoughts? We can have: list device { key unique-id; leaf unique-id { ... } action get-bootstrapping-data { input { leaf os-name { ... } leaf os-version { ... } ... } output { leaf zerotouch-information { ... } leaf ownership-voucher { ... } leaf owner-certificate { ... } } } action report-progress { // I like this name better :) ... } } And then NACM can still be used to provide access control to this list. > > Also, the draft doesn't discuss things like "one-time use voucher"; > > this term is just used here. It seems to me that this requires more > > descriptive text. > > Good catch. draft-ietf-anima-voucher informally calls it an "audit > voucher", which is an unfortunate misnomer. Nonetheless, point taken, > the draft should tie into what's in the voucher draft. Max Pritikin > told me a couple weeks ago that calling it a "nonced voucher" or a > "voucher with a nonce" was probably best. BTW, this seems like an > editorial fix to me, but I can see how it could look like a major > issue if you didn't know what the text was alluding to... Ok. > > o Section 4.4 > > > > When a device is > > not able to trust a bootstrap server, it MUST NOT send its IDevID > > certificate in the form of a TLS client certificate > > > > How will the server authenticate the client in this case? > > The idea is that the server doesn't auth the client in this case. > The goal behind not sending the IDevID certificate was so a rouge > bootstrap server wouldn't be able to discover the device's serial > number, which is why Appendix B suggests also masking the serial > number the device sends in the URL. That said, we might need to > rethink this, especially in conjunction with your next comment. > (continued below) > > > > I see that in section 7.3 you have: > > > > Note that the bootstrap server MUST NOT process a progress update > > from a device without first authenticating the device. This is in > > contrast to when a device is fetching data from the server, a read- > > only operation, in which case device authentication is not strictly > > required (e.g., when sending signed information). > > > > But the server is a normal RESTCONF server, so it will follow > > section 2.5 of RFC 8040; it will require clients to be > > authenticated. > > I was hoping that the draft could suppress this auth requirement > for this specific "untrusted" interaction. In essence, reducing > the bootstrap server to a simple file server providing anonymous > read-access. > > But in the security analysis of things, it comes down to what's > more important to prevent: > a) a rogue server discovering a valid device's serial number, > while not being able to provide the device a response the > device can trust, or > b) a valid server giving signed redirect information to a > rogue device, where the information given doesn't provide > the device any more information than the device must have > already had to make the request in the first place, other > than a confirmation that indeed that serial number is one > that the server is expecting. > > Looking at it this way, (b) is more important to prevent and, > besides: > 1) there is already a Security Consideration related to the use > of serial numbers in the solution, so (a) seems to be just > more of the same, > 2) rogue connections could play havoc with the server's logs, and > 3) (to your point) it would be tricky business to define an > exception for the standard RESTCONF server to follow. > > All this is to say that I think we should go back to the device > always sending its IDevID cert and, of course, the server always > authenticating the device. But I also think that a device should > continue NOT sending any other information (i.e. query params, > progress updates, etc.), beyond its serial number & IDevID cert, > until it can fully authenticate the server. Ok. > > Normal issues > > ------------- > > > > o Section 1.2 > > The term "manufacturer" is used herein to refer to the > > manufacturer of a device or a delegate of the manufacturer. > > > > In the text you sometimes use "manufacturer" and sometimes > > "manufacturer ot delegate". Perhaps the term "manufacturer" should > > be reserved to mean just the manufacturer, and then use > > "manufacturer or delegate" in the places where that's appropriate. > > I mean for it to always be "manufacturer or delegate". The better > fix is to remove "or delegate" throughout the document. Agreed? Ok. > > o Section 3.2 > > > > In the first paragraph, maybe include a reference to RFC 5280. > > Yes. > > > > o Section 5.1 > > > > The numbers in the picture don't match the numbers in the list > > (specifically 4-5). > > Ooops, I meant 2 & 3 to be 2a and 2b respectively. Will fix, most > likely by flattening the (2) text into distinct 2 & 3 sections > again. > > > > o Section 5.6 > > > > Upon rebooting, the device MUST still be > > in its initial state, causing the bootstrapping process to run again, > > which will eventually come to this very point, > > > > Why this MUST? What if the new boot image contains other factory > > defaults that does not enable ZTP, would that be illegal? > > > > I would think that implementations are free to do whatever they want > > in case of errors. > > Maybe not *illegal*, but it would certainly brick the device at that > point. Would just reducing the "MUST" to a "must" suffice, or should > we add a qualifier along the lines of "in order for the solution to > work..." ? I would just say something like Upon rebooting, if the new image also enables zerotouch, the device will still be in its initial state, causing the bootstrapping process to run again, which will eventually come to this very point, > > In the case of errors, the device MUST reset > > itself in such a way that forces a reinstallation of the boot image, > > thereby wiping out any bad state the script may have left behind. > > > > Is this also required? Why can't stop and wait for manual > > intervention be allowed? > > It could, but again, it would brick the device. Same question as above, > would reducing the "MUST" to a "must" suffice, or should we add a > qualifier along the lines of "in order for the solution to work..." ? Well, this depends if the error is transient or not. If it is not transient, it will just happen again and again. I don't have a strong opinion, but I would probably be silent about what to do in case of these kinds of errors. Leave that to the implementation to figure out. > > o Section 7.3 > > > > The examples have "device=123456" in the URLs; it should be > > "device=123456789". > > Yes. > > > > I suggest you shorten the lines of the examples even more, so that > > the examples are properly indented in the draft (they are currently > > outdented) > > It's hard to make the lines much shorter with the URN being so long. > Options are 1) don't indent just the xmlns line or 2) move from two- > space indent to single-space indent. Do you have a preference? In the second example you use (1). You can also use "\", which you are also already using. I just found another outdented figure in section 5.3, which probably is easier to fix. > > o Section 9 > > > > Should you also mention that /device list should be protected by > > nacm rules? > > Yes, indeed, I left out the standard security template for the bootstrap > server YANG module. Will add. > > > > If the RESTCONF user name is the device's unique-id, then a single > > NACM rule can be used: > > > > > > allow-device > > > > /ztbs:device[ztbs:unique-id=$USER] > > > > read > > permit > > > > Yes, but would you expect this to appear in the draft? Typically, the specific > NACM rule syntax is left as an exercise to the reader... In order to do this, the "username" must be the same as the "unique-id". This requires the client cert to be constructed properly. Since the NACM rule is not obvious, and due to the cert implications, I think it would be very helpful with an appendix that describes how this can be set up. > > o ietf-zerotouch-information.yang > > > > o sha256 is defined like this: > > > > leaf sha256 { > > type string; > > "The hex-encoded SHA-256 hash over the boot > > image file. > > > > Should this be type yang:hex-string? If not, I think you need to > > specify how the hex-chars are encoded in the string. > > Yes, it should be yang:hex-string. > > > > o uri is defined like this: > > > > leaf-list uri { > > type inet:uri; > > min-elements 1; > > description > > "An ordered list of URIs to where the boot-image file MAY > > be obtained. > > > > This leaf-list should be ordered-by user to indicate that the order is > > significant. > > Yes, it should be ordered-by user. > > > > o ietf-zerotouch-bootstrap-server.yang > > > > o the action "update-progress" should have a description > > Strange, this wasn't caught by any of: > pyang --ietf --strict ... > pyang --canonical ... > yanglint ... Yes, this is b/c --ietf implements 6087, and actions were not listed there. Will be fixed! > But will add anyways. > > > > o If a script is erroneously provided to a device that does not > > support the execution of scripts, the device SHOULD send a > > 'script-warning' notification message > > > > Rephrase to avoid the term "notification message" > > Also, the types are "pre-script-warning" and "post-script-warning". > > Will fix. > > > > o The description of the "script" typedef says: > > > > No attempt is made to standardize the contents, running context, > > or programming language of the script. > > [...] > > The script returns exit status code '0' on success and non-zero > > on error, with accompanying stderr/stdout for logging purposes. > > > > I think the last quoted sentence contradicts the first - it does in > > fact make assumptions about the running context of the script. > > > > I suggest the latter sentence is removed, and the rest of the test > > adjusted. Don't talk about exit codes, but instead talk about > > "success" or "error" etc. > > Will do. > > > > o Other comment > > > > Is it assumed that there will be a vendor-specific YANG module to > > enable the zero-touch process? Did you consider an > > ietf-zerotouch-device module for this purpose? Such a configuration > > must be carefully designed to allow for a "merge" configuration file > > to actually disable the zero touch process. > > It is assumed to be vendor-specific currently. I have not thought to > define a ietf-zerotouch-device module as of yet that, presumably, would > contain a boolean or an enum (but not a p-container) for enabling the > service. Do you think we should add such a module to the draft, or just > put a note somewhere about it? I don't have a strong opinion, but if there's not a standard module for this, the text should mention that it is assumed that vendors define this themselves. Hmm, I think I would prefer a standard module; it would make the solution more complete. > > Editorial nits: > > --------------- > > > > o use "" instead of '' consistently (except in YANG strings) > > Thanks. Will double-check all. > > > > o you probably should include a reference to ITU-T X.690. > > Will do. > > > > o s/bootstrap data/bootstrapping data/ > > Good catch, thought I got them all before. > > > > o I suggest you run the modules through 'pyang -f yang > > --keep-comments' in order to fix some inconsistent indentations > > Will do. > > > Thanks again! > Kent /martin From nobody Thu Sep 28 01:55:07 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32201321D8 for ; Thu, 28 Sep 2017 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9Y4wPgT_13p for ; Thu, 28 Sep 2017 01:55:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85505134551 for ; Thu, 28 Sep 2017 01:55:04 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 570541AE02A7; Thu, 28 Sep 2017 10:55:01 +0200 (CEST) Date: Thu, 28 Sep 2017 10:53:30 +0200 (CEST) Message-Id: <20170928.105330.688772851180412548.mbj@tail-f.com> To: rwilton@cisco.com Cc: netconf@ietf.org, andy@yumaworks.com, kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] YANG Patch 'remove' operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:55:06 -0000 Robert Wilton wrote: > Hi, > = > I might have found a possible bug in YANG Patch: > = > Regarding section 2.2 of RFC 8072, the second paragraph states (as I > would expect): > = > The "merge", "replace", "create", "delete", and "remove" edit > operations have exactly the same meanings as those defined for the= > "operation" attribute described inSection=A07.2 of [RFC6241] > . > = > However, the third paragraph in this section then goes on to say: > = > ... If the edit does not identify > any existing resource instance and the operation for the edit is n= ot > "create", then the request MUST NOT be processed and a "404 Not > Found" error response MUST be sent by the server. > = > = > This seems to be require that "merge" operations have to be handled > like "create" operations, and "remove" operations have to be handled > like "delete" operations. > = > Hence I think that the text in this third paragraph may be slightly > wrong, and perhaps should be?: > = > ... If the edit does not identify > any existing resource instance and the operation for the edit is n= ot > "create", "merge", or "remove", then the request MUST NOT be proce= ssed > and a "404 Not > Found" error response MUST be sent by the server. > = > = > Otherwise, it seems like 'merge' has to be handled like 'create', and= > 'remove' like 'delete', which then directly conflicts with the second= > paragraph? I agree with your analysis. I think this should be filed as an errata to RFC 8072. /martin From nobody Thu Sep 28 02:23:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42B51345AB for ; Thu, 28 Sep 2017 02:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT3tgzDuwd6l for ; Thu, 28 Sep 2017 02:23:21 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995321345B7 for ; Thu, 28 Sep 2017 02:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2139; q=dns/txt; s=iport; t=1506590590; x=1507800190; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=SCQNBn7N8k6I9xvxNaaw3D2T/fjqSS+j4fh0Ko/do1Y=; b=JZGGiV4Lw//eRyQSKTREUhxteDiZmSnlPQoiWJtw35goD5jmHAG7T559 7JIK2oD2GKyE4b8Hz1KaCHwzUf8dZecuX7H5NLV/i3LIUHUtieDSV01i7 woTkwjaecR6+gtp3euTZ0kf8+xbFJBScSZRRZvwNEJpYyRi5+le26L+kf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAQAfv8xZ/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRAbieDeIsTkD4imD0KI4UYAoUoFQECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?PAQVBEAsOCgICJgICVwYNBgIBAYotEKckgieLAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQ6CHYNTgWorC4JyhFkVgymCYAWhJYdejQGLW4crjXOHWYE5NSKBDjI?= =?us-ascii?q?hCB0Vh2c/NgGITwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208";a="656062083" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 09:23:02 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8S9N1HV014282; Thu, 28 Sep 2017 09:23:01 GMT To: Martin Bjorklund Cc: netconf@ietf.org, andy@yumaworks.com, kwatsen@juniper.net References: <20170928.105330.688772851180412548.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Thu, 28 Sep 2017 10:23:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170928.105330.688772851180412548.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] YANG Patch 'remove' operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:23:23 -0000 On 28/09/2017 09:53, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi, >> >> I might have found a possible bug in YANG Patch: >> >> Regarding section 2.2 of RFC 8072, the second paragraph states (as I >> would expect): >> >> The "merge", "replace", "create", "delete", and "remove" edit >> operations have exactly the same meanings as those defined for the >> "operation" attribute described inSection 7.2 of [RFC6241] >> . >> >> However, the third paragraph in this section then goes on to say: >> >> ... If the edit does not identify >> any existing resource instance and the operation for the edit is not >> "create", then the request MUST NOT be processed and a "404 Not >> Found" error response MUST be sent by the server. >> >> >> This seems to be require that "merge" operations have to be handled >> like "create" operations, and "remove" operations have to be handled >> like "delete" operations. >> >> Hence I think that the text in this third paragraph may be slightly >> wrong, and perhaps should be?: >> >> ... If the edit does not identify >> any existing resource instance and the operation for the edit is not >> "create", "merge", or "remove", then the request MUST NOT be processed >> and a "404 Not >> Found" error response MUST be sent by the server. >> >> >> Otherwise, it seems like 'merge' has to be handled like 'create', and >> 'remove' like 'delete', which then directly conflicts with the second >> paragraph? > I agree with your analysis. I think this should be filed as an errata > to RFC 8072. I can file an errata. When I looked at this again, it looks like "replace" also shouldn't fail on non existence.  So, perhaps the text is: ... If the edit does not identify any existing resource instance and the operation for the edit is "delete" then the request MUST NOT be processed and a "404 Not Found" error response MUST be sent by the server. Is that right? Thanks, Rob > > > /martin > . > From nobody Thu Sep 28 03:24:58 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B15134660 for ; Thu, 28 Sep 2017 03:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW8QH5fO4zmY for ; Thu, 28 Sep 2017 03:24:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D684D1321DF for ; Thu, 28 Sep 2017 03:24:54 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5FEA21AE02A7; Thu, 28 Sep 2017 12:24:53 +0200 (CEST) Date: Thu, 28 Sep 2017 12:23:23 +0200 (CEST) Message-Id: <20170928.122323.1469629889500942367.mbj@tail-f.com> To: rwilton@cisco.com Cc: netconf@ietf.org, andy@yumaworks.com, kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20170928.105330.688772851180412548.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] YANG Patch 'remove' operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 10:24:57 -0000 Robert Wilton wrote: > = > = > On 28/09/2017 09:53, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> Hi, > >> > >> I might have found a possible bug in YANG Patch: > >> > >> Regarding section 2.2 of RFC 8072, the second paragraph states (as= I > >> would expect): > >> > >> The "merge", "replace", "create", "delete", and "remove" edit > >> operations have exactly the same meanings as those defined for= the > >> "operation" attribute described inSection=A07.2 of [RFC6241] > >> . > >> > >> However, the third paragraph in this section then goes on to say: > >> > >> ... If the edit does not identify > >> any existing resource instance and the operation for the edit = is not > >> "create", then the request MUST NOT be processed and a "404 No= t > >> Found" error response MUST be sent by the server. > >> > >> > >> This seems to be require that "merge" operations have to be handle= d > >> like "create" operations, and "remove" operations have to be handl= ed > >> like "delete" operations. > >> > >> Hence I think that the text in this third paragraph may be slightl= y > >> wrong, and perhaps should be?: > >> > >> ... If the edit does not identify > >> any existing resource instance and the operation for the edit = is not > >> "create", "merge", or "remove", then the request MUST NOT be p= rocessed > >> and a "404 Not > >> Found" error response MUST be sent by the server. > >> > >> > >> Otherwise, it seems like 'merge' has to be handled like 'create', = and > >> 'remove' like 'delete', which then directly conflicts with the sec= ond > >> paragraph? > > I agree with your analysis. I think this should be filed as an err= ata > > to RFC 8072. > I can file an errata. > = > When I looked at this again, it looks like "replace" also shouldn't > fail on non existence.=A0 So, perhaps the text is: > = > ... If the edit does not identify > any existing resource instance and the operation for the edit is > "delete" > then the request MUST NOT be processed and a "404 Not Found" error= > response MUST be sent by the server. "delete" or "move" Also, the spec doesn't specify what happens if it is "create" and the resource already exists. I assume it should be 400. /martin From nobody Thu Sep 28 03:50:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9FE1329B5 for ; Thu, 28 Sep 2017 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFMvdW1XL0kE for ; Thu, 28 Sep 2017 03:50:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AB5134686 for ; Thu, 28 Sep 2017 03:50:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B2A88B81896; Thu, 28 Sep 2017 03:50:16 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rwilton@cisco.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170928105016.B2A88B81896@rfc-editor.org> Date: Thu, 28 Sep 2017 03:50:16 -0700 (PDT) Archived-At: Subject: [Netconf] [Technical Errata Reported] RFC8072 (5131) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 10:50:46 -0000 The following errata report has been submitted for RFC8072, "YANG Patch Media Type". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5131 -------------------------------------- Type: Technical Reported by: Robert Wilton Section: 2.2 Original Text ------------- Regarding section 2.2 of RFC 8072, the third paragraph states: ... If the edit does not identify any existing resource instance and the operation for the edit is not "create", then the request MUST NOT be processed and a "404 Not Found" error response MUST be sent by the server. Corrected Text -------------- ... If the edit does not identify any existing resource instance and the operation for the edit is "delete" or "move" then the request MUST NOT be processed and a "404 Not Found" error response MUST be sent by the server. Notes ----- As per the second paragraph of section 2.2 of RFC 8072, the operations are expected to mirror the semantics of the "operation" attribute described in Section 7.2 of [RFC6241]. The spec also doesn't specify what happens if it is a "create" operation and the resource already exists. It should probably also state that "400 Bad Request" is returned. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8072 (draft-ietf-netconf-yang-patch-14) -------------------------------------- Title : YANG Patch Media Type Publication Date : February 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Sep 28 18:44:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388AD1344C3 for ; Thu, 28 Sep 2017 18:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl8BpdTnKnz1 for ; Thu, 28 Sep 2017 18:44:20 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0102.outbound.protection.outlook.com [104.47.42.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF86134493 for ; Thu, 28 Sep 2017 18:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=79yYjt5kh0q6m/H1InJ12FgXBD51AyvYd/qfaT755nM=; b=gwwX+nykZttI4Q/iPZ4VFp5xNRUAQoPTSh3ztKlqGJNim51iCATGs+jVXdyOKROnGiXtTrxz/MbIRCdXKUxow5WvXKLFkM7YSikby2xa0lYQmDyXkMroQSrn3L+CC/f3PJpVAQexAOp8X8LLMcW2TSz24GK5UHzedc61zWL9/ic= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Fri, 29 Sep 2017 01:44:16 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Fri, 29 Sep 2017 01:44:16 +0000 From: Kent Watsen To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] WG LC for zerotouch Thread-Index: AQHTNmkgNr3NKKCDrEalHAYIEUO5aqLHbIGAgAH3n4CAAIp+AIAA6muA Date: Fri, 29 Sep 2017 01:44:16 +0000 Message-ID: <36B6D286-F8B6-4423-8DD2-4DF74943F2A1@juniper.net> References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> <20170926.192701.1726303533240950350.mbj@tail-f.com> <20170928.094514.526215195914925651.mbj@tail-f.com> In-Reply-To: <20170928.094514.526215195914925651.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:FVpiZng7PBpSrpjqWHSuq0JqX+iVB+wsVu0yEK8R+AJNc59UZ4MUvqToh53x6r/JQpxP0Nkt+zFyhG3k5WmbA1+DoUVQ0UdlfjOstkxW1OM/n3PGMeSmJOH2V3hR5g9syFw82r9kf2Ej321XVFlOHMsfnwIYePSs+nVCCzq6WptloTMCXRpptQWNyRuyuuZpN3scrTyEM4U12KQWsyo2/gqRZgIXd969MY8GFyzqPy9aNHIcUoBUU0LUETmb7jcbK2rmhI0waIUKLY0/vaOsvZa1swBUTGHJBSNQNG8YW32kU0NYCLZ9a+6hCBqefMd3AjZLM6pImwMAlvnbvs9YeA==; 5:7h6m0iEFp+F89SOo1bLeigBlsp5OoQLCuWvOJaeLrbmcM8R2JtPyiEzZSZB1jjAnR9C+wReLJVJZ0LOTEW+9edQu0DRikVuT4RYe/ms8Tvcmqrw42+hsZYNSRG8FTtODunzFk3RhuxalJwfebWcQwGT88lfBM6cfj4FqsxwKXjc=; 24:ypVUzrPecW+rWEjMFsRkFfXT6aU1StdaGjd88kh/4/kyblZeyS2wv5bjpuMjbTK88ba1KnqVQ1FkwIJEbFloT8/Pqxubd2njbNDnf83wYg0=; 7:SuPKfmTV/5FtwocYTB7k30NNjmWTjFE52Pov5CbmRWMOANj+rUw8+ZLdFiZdkNL7ksv1vgU0vUPuYdL9bZX0bKwq1nk7goQwZwWHs343RwhcJJfoVbXQspjqn9PacRIpBpQjfEVQJ5H5eC01uiLKJ7HP6X/fLCyUb3krzU3DLWQ1HxW/TkMlew2iDl+x5WJnbTdA3INNgDtQKcZQyfQTm72yPbh0+vQrk7RPhnBaxbA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 816dc892-23e6-477f-d2fb-08d506db9821 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(12181511122)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(51444003)(43784003)(40224003)(189002)(57704003)(199003)(81166006)(53936002)(93886005)(102836003)(76176999)(6436002)(6506006)(6116002)(2906002)(99286003)(6246003)(3280700002)(189998001)(6512007)(316002)(14454004)(478600001)(83716003)(86362001)(97736004)(58126008)(3846002)(6486002)(77096006)(2900100001)(50986999)(54356999)(83506001)(81156014)(25786009)(105586002)(305945005)(106356001)(4326008)(8936002)(33656002)(5660300001)(7736002)(2950100002)(101416001)(8676002)(82746002)(66066001)(3660700001)(68736007)(6916009)(229853002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8711C489189E9344B089A533EFC54A9B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 01:44:16.1657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 Archived-At: Subject: Re: [Netconf] WG LC for zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 01:44:24 -0000 SGkgTWFydGluLA0KDQpJIHRyaW1tZWQgdGhlIGRpc2N1c3Npb24gZG93biB0byBqdXN0IHRoZSBv cGVuIHRocmVhZHMuDQoNCg0KPj4gPiBvICBTZWN0aW9uIDcuMg0KPj4gPg0KPj4gPiAgQWRkaW5n IGN1c3RvbSBxdWVyeSBwYXJhbWV0ZXJzIGxpa2UgdGhpcyBicmVha3MgdGhlIG5vcm1hbCBZQU5H DQo+PiA+ICBjb250cmFjdC4gIElmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgdGhlIGlu c3RhbmNlIGRhdGEgdHJlZQ0KPj4gPiAgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgc3VwcG9z ZWQgdG8gY2hhbmdlIGJhc2VkIG9uIHRoZXNlIHF1ZXJ5DQo+PiA+ICBwYXJhbWV0ZXJzLg0KPj4g DQo+PiBDb3JyZWN0LiAgVGhlIGlkZWEgaXMgdGhhdCB0aGUgcmVzcG9uc2UgY291bGQgdmFyeSBi YXNlZCBvbiB0aGUgaW5wdXQNCj4+IHF1ZXJ5IHBhcmFtcy4gIE9mIGNvdXJzZSwgaW4gY2FzZSB0 aGVyZSB3YXMgYW55IGRvdWJ0LCB0aGUgcmVzcG9uc2UgDQo+PiB3b3VsZCBhbHdheXMgY29uZm9y bSB0byBzYW1lIFlBTkcgc2NoZW1hLg0KPg0KPlNlZSBiZWxvdy4NCj4NCj4+ID4gIElmIHlvdSBy ZWFsbHkgbmVlZCB0byBoYXZlIHRoYXQgZnVuY3Rpb25hbGl0eSwgaXQgd291bGQgYmV0dGVyIHRv DQo+PiA+ICBtb2RlbCB0aGUgZGV2aWNlLXNwZWNpZmljIGRhdGEgYXMgYW4gYWN0aW9uOyBpbnB1 dCB3b3VsZCBiZSB0aGUNCj4+ID4gIG9zLW5hbWUsIG9zLXZlcnNpb24gZXRjLCBhbmQgb3V0cHV0 IHdvdWxkIGJlIHRoZQ0KPj4gPiAgemVyb3RvdWNoLWluZm9ybWF0aW9uIGFuZCB2b3VjaGVyIGV0 Yy4NCj4+IA0KPj4gSSB0aG91Z2h0IG9mIHRoaXMgYXMgd2VsbCwgYnV0IGRpZG4ndCBkbyBhbnl0 aGluZyBhYm91dCBpdCBhcyBteSANCj4+IGxhc3QgbWVzc2FnZSB0byB0aGUgbGlzdCBzYWlkIHRo YXQgd2UnZCBhZGQgInF1ZXJ5IHBhcmFtZXRlcnMiDQo+PiBhbmQgSSB3YW50ZWQgdG8gZm9sbG93 IHRocm91Z2ggb24gdGhhdCBzdGF0ZW1lbnQuDQo+PiANCj4+IEJ1dCB3aGF0IGlzIHRoZSBpc3N1 ZT8gIElzIGl0IHByaW1hcmlseSB0aGF0IHVzaW5nIHF1ZXJ5IHBhcmFtcyANCj4+IG9uIEdFVCBz aG91bGQgYmUgbGltaXRlZCB0byByZXR1cm5pbmcgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucw0K Pj4gb2YgYSByZXNvdXJjZSwgYW5kIHRoaXMgdXNlIHNlZW1zIHRvIGJlIHJldHVybmluZyBkaWZm ZXJlbnQgDQo+PiByZXNvdXJjZXMgYWx0b2dldGhlcj8NCj4NCj4gWWVzLCB0aGlzIGlzIG15IGNv bmNlcm4uICBBIG5vcm1hbCBSRVNUQ09ORiAvIFlBTkcgc2VydmVyIGhhcyAqb25lKg0KPiBzaW5n bGUgaW5zdGFuY2Ugb2YgdGhlIG9wZXJhdGlvbmFsIHN0YXRlLCBhbmQgaXQganVzdCBwcm92aWRl cyBhbiBBUEkNCj4gdG8gdGhpcyBkYXRhLiAgSXQgY2FuIGJlIGZpbHRlcmVkIGFuZCBwcnVuZWQg YmFzZWQgb24gYWNjZXNzIHJpZ2h0cywNCj4gYnV0IG5vdCBtb2RpZmllZCBmcm9tIHRoZSBvdXRz aWRlIGJhc2VkIG9uIHF1ZXJ5IHBhcmFtZXRlcnMuDQoNCkkgYWdyZWUsIGl0IHNlZW1zIG1vcmUg cHJvcGVyLiAgT2theSwgbGV0J3MgbWFrZSB0aGlzIGNoYW5nZS4gIE5vDQpvYmplY3Rpb25zIGZy b20gdGhlIFdHLCByaWdodD8gIEFzIGEgaGVhZHMtdXAgZm9yIHRob3NlIGZvbGxvd2luZw0KYWxv bmcsIHRoaXMgY2hhbmdlIGRvZXNuJ3QgYWZmZWN0IHRoZSBlc3NlbmNlIG9mIHRoZSBzb2x1dGlv biwgYnV0DQp0aGUgZGlmZiB3aWxsIGFwcGVhciBzb21ld2hhdCBiaWcuLi4NCg0KDQo+PiBGV0lX LCBpZiB3ZSB3ZXJlIHRvIGRvIHRoaXMsIHdlIG1pZ2h0IGFsc28gY29uc2lkZXIgbW92aW5nIHRo ZSANCj4+ICdzZXJpYWwtbnVtYmVyJyBmaWVsZCBmcm9tIHRoZSBVUkwgdG8gYW4gaW5wdXQgZmll bGQNCj4NCj4gSG1tLCBkaWQgeW91IG1lYW4gJ3VuaXF1ZS1pZCc/DQoNClllcy4gQnV0IHdoYXQg YWJvdXQgdGhlIGlkZWEsIG1vdmluZyAndW5pcXVlLWlkJyBmcm9tIHRoZSBVUkwgcGF0aA0KdG8g YW4gaW5wdXQgcGFyYW0/ICBPciwgZXZlbiBtb3JlIGRyYW1hdGljYWxseSwgd2UgY291bGQgcmVt b3ZlIA0KJ3VuaXF1ZS1pZCcgYWx0b2dldGhlciwgcmVseWluZyBpbnN0ZWFkIG9uIHRoZSBSRVNU Q09ORiB1c2VybmFtZQ0KZXh0cmFjdGVkIGZyb20gdGhlIERldklEIGNlcnRpZmljYXRlPw0KDQpJ ZiByZWx5aW5nIG9uIHRoZSBleHRyYWN0ZWQgdXNlcm5hbWUsIG5vdGUgdGhhdCBub25lIG9mIHRo ZSANCidjZXJ0LXRvLW5hbWUnIGlkZW50aXRpZXMgZGVmaW5lZCBpbiBSRkMgNzQwNywgd2hpY2gg aXMgYWxzbw0KdXNlZCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtY2xpZW50LXNlcnZl ciwgd291bGQgd29yay4NClRoZSAnY29tbW9uLW5hbWUnIGlkZW50aXR5IGlzIGNsb3Nlc3QsIGJ1 dCB3aGF0IGlzIHJlYWxseSBuZWVkZWQNCmlzIGEgY29tYmluYXRpb24gb2YgYSAnc2VyaWFsTnVt YmVyJyBhdHRyaWJ1dGUgYW5kIGFuIG9wdGlvbmFsDQonaGFyZHdhcmVNb2R1bGVOYW1lJyBhdHRy aWJ1dGUgKG5vdCBhbGwgRGV2SUQgY2VydHMgZGVmaW5lIGl0KS4NCkkgc3VwcG9zZSB0aGF0IHRo aXMgaXMgYW4gaXNzdWUgZm9yIHRoZSBhZm9yZS1tZW50aW9uZWQgcmVzdGNvbmYNCmNsaWVudC9z ZXJ2ZXIgZHJhZnQgbW9yZSBzbyB0aGFuIHRoaXMgb25lIHRob3VnaC4gIFN0aWxsLCBzaW5jZQ0K d2UncmUgdGFsa2luZyBhYm91dCBpdCwgYXNzdW1pbmcgd2UgZGlkIHRoaXMsIHdvdWxkIHRoYXQg ZHJhZnQNCmFkZCBzYWlkIGlkZW50aXRpZXMsIG9yIHdvdWxkIGEgNzQwN2JpcyBiZSBiZXR0ZXI/ DQoNCg0KPj4gLCBhbmQgbWFrZQ0KPj4gYSBzaW1pbGFyIGNoYW5nZSB0byB0aGUgJ3VwZGF0ZS1w cm9ncmVzcycgYWN0aW9uLiAgQnV0IHRoYXQgdGhlbg0KPj4gd291bGQgbWVzcyB1cCB5b3VyIE5B Q00gcnVsZSBiZWxvdy4gIFRob3VnaHRzPw0KPg0KPldlIGNhbiBoYXZlOg0KPg0KPiAgbGlzdCBk ZXZpY2Ugew0KPiAgICBrZXkgdW5pcXVlLWlkOw0KPg0KPiAgICBsZWFmIHVuaXF1ZS1pZCB7IC4u LiB9DQo+DQo+ICAgIGFjdGlvbiBnZXQtYm9vdHN0cmFwcGluZy1kYXRhIHsNCj4gICAgICBpbnB1 dCB7DQo+ICAgICAgICBsZWFmIG9zLW5hbWUgeyAuLi4gfQ0KPiAgICAgICAgbGVhZiBvcy12ZXJz aW9uIHsgLi4uIH0NCj4gICAgICAgIC4uLg0KPiAgICAgIH0NCj4gICAgICBvdXRwdXQgew0KPiAg ICAgICAgbGVhZiB6ZXJvdG91Y2gtaW5mb3JtYXRpb24geyAuLi4gfQ0KPiAgICAgICAgbGVhZiBv d25lcnNoaXAtdm91Y2hlciB7IC4uLiB9DQo+ICAgICAgICBsZWFmIG93bmVyLWNlcnRpZmljYXRl IHsgLi4uIH0NCj4gICAgICB9DQo+ICAgIH0NCj4NCj4gICAgYWN0aW9uIHJlcG9ydC1wcm9ncmVz cyB7ICAvLyBJIGxpa2UgdGhpcyBuYW1lIGJldHRlciA6KQ0KPiAgICAgIC4uLg0KPiAgICB9DQo+ ICB9DQoNClllcywgdGhpcyBpcyByb3VnaGx5IHdoYXQgc3dpdGNoaW5nIHRvIGFuIGFjdGlvbiBz dGF0ZW1lbnQgd291bGQgbG9vaw0KbGlrZSB0aG91Z2gsIHBlbmRpbmcgb24gdGhlIGFib3ZlIGRp c2N1c3Npb24sIHdlIG1heSB1c2UgdG9wLWxldmVsIFJQQ3MNCmluc3RlYWQgb2YgYWN0aW9ucywg aWYgcmVseWluZyBvbiB0aGUgUkVTVENPTkYgdXNlcm5hbWUuDQoNCkkgYWdyZWUsICdyZXBvcnQt cHJvZ3Jlc3MnIGRvZXMgc2VlbSBiZXR0ZXIuICBJdCdzIGEgbWlub3IgdGhpbmcsIGJ1dA0KaGFw cHkgdG8gb2JsaWdlLiAgKG5vIG9iamVjdGlvbnMgZnJvbSB0aGUgV0csIHJpZ2h0PykNCg0KDQo+ PiA+IG8gIFNlY3Rpb24gNC40DQo+PiA+DQo+PiA+ICAgICBXaGVuIGEgZGV2aWNlIGlzDQo+PiA+ ICAgICBub3QgYWJsZSB0byB0cnVzdCBhIGJvb3RzdHJhcCBzZXJ2ZXIsIGl0IE1VU1QgTk9UIHNl bmQgaXRzIElEZXZJRA0KPj4gPiAgICAgY2VydGlmaWNhdGUgaW4gdGhlIGZvcm0gb2YgYSBUTFMg Y2xpZW50IGNlcnRpZmljYXRlDQo+PiA+DQo+PiA+ICBIb3cgd2lsbCB0aGUgc2VydmVyIGF1dGhl bnRpY2F0ZSB0aGUgY2xpZW50IGluIHRoaXMgY2FzZT8NCj4+IA0KPj4gVGhlIGlkZWEgaXMgdGhh dCB0aGUgc2VydmVyIGRvZXNuJ3QgYXV0aCB0aGUgY2xpZW50IGluIHRoaXMgY2FzZS4NCj4+IFRo ZSBnb2FsIGJlaGluZCBub3Qgc2VuZGluZyB0aGUgSURldklEIGNlcnRpZmljYXRlIHdhcyBzbyBh IHJvdWdlDQo+PiBib290c3RyYXAgc2VydmVyIHdvdWxkbid0IGJlIGFibGUgdG8gZGlzY292ZXIg dGhlIGRldmljZSdzIHNlcmlhbA0KPj4gbnVtYmVyLCB3aGljaCBpcyB3aHkgQXBwZW5kaXggQiBz dWdnZXN0cyBhbHNvIG1hc2tpbmcgdGhlIHNlcmlhbA0KPj4gbnVtYmVyIHRoZSBkZXZpY2Ugc2Vu ZHMgaW4gdGhlIFVSTC4gIFRoYXQgc2FpZCwgd2UgbWlnaHQgbmVlZCB0bw0KPj4gcmV0aGluayB0 aGlzLCBlc3BlY2lhbGx5IGluIGNvbmp1bmN0aW9uIHdpdGggeW91ciBuZXh0IGNvbW1lbnQuICAN Cj4+IChjb250aW51ZWQgYmVsb3cpICANCj4+IA0KPj4gDQo+PiA+ICBJIHNlZSB0aGF0IGluIHNl Y3Rpb24gNy4zIHlvdSBoYXZlOg0KPj4gPg0KPj4gPiAgIE5vdGUgdGhhdCB0aGUgYm9vdHN0cmFw IHNlcnZlciBNVVNUIE5PVCBwcm9jZXNzIGEgcHJvZ3Jlc3MgdXBkYXRlDQo+PiA+ICAgZnJvbSBh IGRldmljZSB3aXRob3V0IGZpcnN0IGF1dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2UuICBUaGlzIGlz IGluDQo+PiA+ICAgY29udHJhc3QgdG8gd2hlbiBhIGRldmljZSBpcyBmZXRjaGluZyBkYXRhIGZy b20gdGhlIHNlcnZlciwgYSByZWFkLQ0KPj4gPiAgIG9ubHkgb3BlcmF0aW9uLCBpbiB3aGljaCBj YXNlIGRldmljZSBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3RyaWN0bHkNCj4+ID4gICByZXF1aXJl ZCAoZS5nLiwgd2hlbiBzZW5kaW5nIHNpZ25lZCBpbmZvcm1hdGlvbikuDQo+PiA+DQo+PiA+ICBC dXQgdGhlIHNlcnZlciBpcyBhIG5vcm1hbCBSRVNUQ09ORiBzZXJ2ZXIsIHNvIGl0IHdpbGwgZm9s bG93DQo+PiA+ICBzZWN0aW9uIDIuNSBvZiBSRkMgODA0MDsgaXQgd2lsbCByZXF1aXJlIGNsaWVu dHMgdG8gYmUNCj4+ID4gIGF1dGhlbnRpY2F0ZWQuDQo+PiANCj4+IEkgd2FzIGhvcGluZyB0aGF0 IHRoZSBkcmFmdCBjb3VsZCBzdXBwcmVzcyB0aGlzIGF1dGggcmVxdWlyZW1lbnQNCj4+IGZvciB0 aGlzIHNwZWNpZmljICJ1bnRydXN0ZWQiIGludGVyYWN0aW9uLiAgSW4gZXNzZW5jZSwgcmVkdWNp bmcNCj4+IHRoZSBib290c3RyYXAgc2VydmVyIHRvIGEgc2ltcGxlIGZpbGUgc2VydmVyIHByb3Zp ZGluZyBhbm9ueW1vdXMNCj4+IHJlYWQtYWNjZXNzLg0KPj4gDQo+PiBCdXQgaW4gdGhlIHNlY3Vy aXR5IGFuYWx5c2lzIG9mIHRoaW5ncywgaXQgY29tZXMgZG93biB0byB3aGF0J3MgDQo+PiBtb3Jl IGltcG9ydGFudCB0byBwcmV2ZW50Og0KPj4gIGEpIGEgcm9ndWUgc2VydmVyIGRpc2NvdmVyaW5n IGEgdmFsaWQgZGV2aWNlJ3Mgc2VyaWFsIG51bWJlciwNCj4+ICAgICB3aGlsZSBub3QgYmVpbmcg YWJsZSB0byBwcm92aWRlIHRoZSBkZXZpY2UgYSByZXNwb25zZSB0aGUNCj4+ICAgICBkZXZpY2Ug Y2FuIHRydXN0LCBvcg0KPj4gIGIpIGEgdmFsaWQgc2VydmVyIGdpdmluZyBzaWduZWQgcmVkaXJl Y3QgaW5mb3JtYXRpb24gdG8gYQ0KPj4gICAgIHJvZ3VlIGRldmljZSwgd2hlcmUgdGhlIGluZm9y bWF0aW9uIGdpdmVuIGRvZXNuJ3QgcHJvdmlkZQ0KPj4gICAgIHRoZSBkZXZpY2UgYW55IG1vcmUg aW5mb3JtYXRpb24gdGhhbiB0aGUgZGV2aWNlIG11c3QgaGF2ZQ0KPj4gICAgIGFscmVhZHkgaGFk IHRvIG1ha2UgdGhlIHJlcXVlc3QgaW4gdGhlIGZpcnN0IHBsYWNlLCBvdGhlcg0KPj4gICAgIHRo YW4gYSBjb25maXJtYXRpb24gdGhhdCBpbmRlZWQgdGhhdCBzZXJpYWwgbnVtYmVyIGlzIG9uZQ0K Pj4gICAgIHRoYXQgdGhlIHNlcnZlciBpcyBleHBlY3RpbmcuICANCj4+IA0KPj4gTG9va2luZyBh dCBpdCB0aGlzIHdheSwgKGIpIGlzIG1vcmUgaW1wb3J0YW50IHRvIHByZXZlbnQgYW5kLCANCj4+ IGJlc2lkZXM6DQo+PiAxKSB0aGVyZSBpcyBhbHJlYWR5IGEgU2VjdXJpdHkgQ29uc2lkZXJhdGlv biByZWxhdGVkIHRvIHRoZSB1c2UNCj4+ICAgIG9mIHNlcmlhbCBudW1iZXJzIGluIHRoZSBzb2x1 dGlvbiwgc28gKGEpIHNlZW1zIHRvIGJlIGp1c3QNCj4+ICAgIG1vcmUgb2YgdGhlIHNhbWUsIA0K Pj4gMikgcm9ndWUgY29ubmVjdGlvbnMgY291bGQgcGxheSBoYXZvYyB3aXRoIHRoZSBzZXJ2ZXIn cyBsb2dzLCBhbmQNCj4+IDMpICh0byB5b3VyIHBvaW50KSBpdCB3b3VsZCBiZSB0cmlja3kgYnVz aW5lc3MgdG8gZGVmaW5lIGFuDQo+PiAgICBleGNlcHRpb24gZm9yIHRoZSBzdGFuZGFyZCBSRVNU Q09ORiBzZXJ2ZXIgdG8gZm9sbG93Lg0KPj4gDQo+PiBBbGwgdGhpcyBpcyB0byBzYXkgdGhhdCBJ IHRoaW5rIHdlIHNob3VsZCBnbyBiYWNrIHRvIHRoZSBkZXZpY2UNCj4+IGFsd2F5cyBzZW5kaW5n IGl0cyBJRGV2SUQgY2VydCBhbmQsIG9mIGNvdXJzZSwgdGhlIHNlcnZlciBhbHdheXMNCj4+IGF1 dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2UuICBCdXQgSSBhbHNvIHRoaW5rIHRoYXQgYSBkZXZpY2Ug c2hvdWxkDQo+PiBjb250aW51ZSBOT1Qgc2VuZGluZyBhbnkgb3RoZXIgaW5mb3JtYXRpb24gKGku ZS4gcXVlcnkgcGFyYW1zLA0KPj4gcHJvZ3Jlc3MgdXBkYXRlcywgZXRjLiksIGJleW9uZCBpdHMg c2VyaWFsIG51bWJlciAmIElEZXZJRCBjZXJ0LA0KPj4gdW50aWwgaXQgY2FuIGZ1bGx5IGF1dGhl bnRpY2F0ZSB0aGUgc2VydmVyLg0KPg0KPiBPay4NCg0KT2theSwgaXQgc2VlbXMgdGhhdCB3ZSBh Z3JlZS4gIEFueSBvYmplY3Rpb25zIGZyb20gdGhlIFdHPyAgSW4gY2FzZSBpdCdzDQp1bmNsZWFy LCB0aGlzIGNoYW5nZSBpcyBmYWlybHkgc2lnbmlmaWNhbnQgZnJvbSBhIHNvbHV0aW9uLXBlcnNw ZWN0aXZlLg0KSXQgd2lsbCBhbHNvIGhhdmUgYSBub24tdHJpdmlhbCBpbXBhY3QgZnJvbSBhIGRy YWZ0LWRpZmYgcGVyc3BlY3RpdmUuDQpQbGVhc2UgY2hpbWUgaW4gbm93IHdpdGggYW55IG9waW5p b25zIG5vdy4NCg0KIA0KPj4gPiBvICBTZWN0aW9uIDUuNg0KPj4gPg0KPj4gPiAgICAgVXBvbiBy ZWJvb3RpbmcsIHRoZSBkZXZpY2UgTVVTVCBzdGlsbCBiZQ0KPj4gPiAgICAgaW4gaXRzIGluaXRp YWwgc3RhdGUsIGNhdXNpbmcgdGhlIGJvb3RzdHJhcHBpbmcgcHJvY2VzcyB0byBydW4gYWdhaW4s DQo+PiA+ICAgICB3aGljaCB3aWxsIGV2ZW50dWFsbHkgY29tZSB0byB0aGlzIHZlcnkgcG9pbnQs DQo+PiA+DQo+PiA+ICBXaHkgdGhpcyBNVVNUPyAgV2hhdCBpZiB0aGUgbmV3IGJvb3QgaW1hZ2Ug Y29udGFpbnMgb3RoZXIgZmFjdG9yeQ0KPj4gPiAgZGVmYXVsdHMgdGhhdCBkb2VzIG5vdCBlbmFi bGUgWlRQLCB3b3VsZCB0aGF0IGJlIGlsbGVnYWw/DQo+PiA+DQo+PiA+ICBJIHdvdWxkIHRoaW5r IHRoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBmcmVlIHRvIGRvIHdoYXRldmVyIHRoZXkgd2FudA0K Pj4gPiAgaW4gY2FzZSBvZiBlcnJvcnMuDQo+PiANCj4+IE1heWJlIG5vdCAqaWxsZWdhbCosIGJ1 dCBpdCB3b3VsZCBjZXJ0YWlubHkgYnJpY2sgdGhlIGRldmljZSBhdCB0aGF0DQo+PiBwb2ludC4g IFdvdWxkIGp1c3QgcmVkdWNpbmcgdGhlICJNVVNUIiB0byBhICJtdXN0IiBzdWZmaWNlLCBvciBz aG91bGQNCj4+IHdlIGFkZCBhIHF1YWxpZmllciBhbG9uZyB0aGUgbGluZXMgb2YgImluIG9yZGVy IGZvciB0aGUgc29sdXRpb24gdG8NCj4+IHdvcmsuLi4iID8NCj4NCj4gSSB3b3VsZCBqdXN0IHNh eSBzb21ldGhpbmcgbGlrZSANCj4NCj4gICAgIFVwb24gcmVib290aW5nLCBpZiB0aGUgbmV3IGlt YWdlIGFsc28gZW5hYmxlcyB6ZXJvdG91Y2gsIHRoZQ0KPiAgICAgZGV2aWNlIHdpbGwgc3RpbGwg YmUNCj4gICAgIGluIGl0cyBpbml0aWFsIHN0YXRlLCBjYXVzaW5nIHRoZSBib290c3RyYXBwaW5n IHByb2Nlc3MgdG8gcnVuIGFnYWluLA0KPiAgICAgd2hpY2ggd2lsbCBldmVudHVhbGx5IGNvbWUg dG8gdGhpcyB2ZXJ5IHBvaW50LA0KDQpPa2F5Lg0KDQoNCj4+ID4gICAgSW4gdGhlIGNhc2Ugb2Yg ZXJyb3JzLCB0aGUgZGV2aWNlIE1VU1QgcmVzZXQNCj4+ID4gICAgaXRzZWxmIGluIHN1Y2ggYSB3 YXkgdGhhdCBmb3JjZXMgYSByZWluc3RhbGxhdGlvbiBvZiB0aGUgYm9vdCBpbWFnZSwNCj4+ID4g ICAgdGhlcmVieSB3aXBpbmcgb3V0IGFueSBiYWQgc3RhdGUgdGhlIHNjcmlwdCBtYXkgaGF2ZSBs ZWZ0IGJlaGluZC4NCj4+ID4NCj4+ID4gIElzIHRoaXMgYWxzbyByZXF1aXJlZD8gIFdoeSBjYW4n dCBzdG9wIGFuZCB3YWl0IGZvciBtYW51YWwNCj4+ID4gIGludGVydmVudGlvbiBiZSBhbGxvd2Vk Pw0KPj4gDQo+PiBJdCBjb3VsZCwgYnV0IGFnYWluLCBpdCB3b3VsZCBicmljayB0aGUgZGV2aWNl LiAgU2FtZSBxdWVzdGlvbiBhcyBhYm92ZSwNCj4+IHdvdWxkIHJlZHVjaW5nIHRoZSAiTVVTVCIg dG8gYSAibXVzdCIgc3VmZmljZSwgb3Igc2hvdWxkIHdlIGFkZCBhIA0KPj4gcXVhbGlmaWVyIGFs b25nIHRoZSBsaW5lcyBvZiAiaW4gb3JkZXIgZm9yIHRoZSBzb2x1dGlvbiB0byB3b3JrLi4uIiA/ DQo+DQo+IFdlbGwsIHRoaXMgZGVwZW5kcyBpZiB0aGUgZXJyb3IgaXMgdHJhbnNpZW50IG9yIG5v dC4gIElmIGl0IGlzIG5vdA0KPiB0cmFuc2llbnQsIGl0IHdpbGwganVzdCBoYXBwZW4gYWdhaW4g YW5kIGFnYWluLg0KDQpNYXliZSwgbWF5YmUgbm90LiAgVGhlIGRldmljZSBjb3VsZCBwb3RlbnRp YWxseSBsYW5kIG9udG8gYW5vdGhlci9kaWZmZXJlbnQNCnNvdXJjZSBvZiBib290c3RyYXBwaW5n IGRhdGEgdGhhdCB3b3JrcyB0aGUgbmV4dCBnbyBhcm91bmQuICBUaGUgaG9wZSBpcw0KdGhhdCB0 aGUgZGV2aWNlIGtlZXBzIHRyeWluZyAoYW5kIHBvc3RpbmcgcHJvZ3Jlc3MtdXBkYXRlcyByZWdh cmRpbmcgaXRzDQplcnJvcnMpIGFkIGluZmluaXR1bSB1bnRpbCB0aGluZ3MgZXZlbnR1YWxseSBj bGVhciB1cC4gIEZvciBpbnN0YW5jZSwgYW4NCmFkbWluIGV2ZW50dWFsbHkgdGFrZXMgbm90aWNl IGFuZCBhZG1pbmlzdGVycyBjb3JyZWN0aXZlIGFjdGlvbi4NCg0KPiBJIGRvbid0IGhhdmUgYSBz dHJvbmcgb3BpbmlvbiwgYnV0IEkgd291bGQgcHJvYmFibHkgYmUgc2lsZW50IGFib3V0DQo+IHdo YXQgdG8gZG8gaW4gY2FzZSBvZiB0aGVzZSBraW5kcyBvZiBlcnJvcnMuICBMZWF2ZSB0aGF0IHRv IHRoZQ0KPiBpbXBsZW1lbnRhdGlvbiB0byBmaWd1cmUgb3V0Lg0KDQpJIGZlZWwgdGhhdCBpdCdz IGNyaXRpY2FsIHRoYXQgbWFudWFsIGludGVydmVudGlvbiBpcyBuZXZlciByZXF1aXJlZC4NClll cywgYSBtYW51YWwgc3RlcCBjb3VsZCBiZSBlbXBsb3llZCwgYnV0IGl0IHNob3VsZCBiZSBhIHJh cmUgc3RlcC4gIEkNCnRoaW5rIGl0J3MgYmVzdCB0byBzYXkgc29tZXRoaW5nIGFsb25nIHRoZXNl IGxpbmVzLiAgSSdsbCB0cnkgdG8gc3RhdGUNCnRoaXMgbW9yZSBjbGVhcmx5Lg0KDQoNCj4+ID4g IEkgc3VnZ2VzdCB5b3Ugc2hvcnRlbiB0aGUgbGluZXMgb2YgdGhlIGV4YW1wbGVzIGV2ZW4gbW9y ZSwgc28gdGhhdA0KPj4gPiAgdGhlIGV4YW1wbGVzIGFyZSBwcm9wZXJseSBpbmRlbnRlZCBpbiB0 aGUgZHJhZnQgKHRoZXkgYXJlIGN1cnJlbnRseQ0KPj4gPiAgb3V0ZGVudGVkKQ0KPj4gDQo+PiBJ dCdzIGhhcmQgdG8gbWFrZSB0aGUgbGluZXMgbXVjaCBzaG9ydGVyIHdpdGggdGhlIFVSTiBiZWlu ZyBzbyBsb25nLg0KPj4gT3B0aW9ucyBhcmUgMSkgZG9uJ3QgaW5kZW50IGp1c3QgdGhlIHhtbG5z IGxpbmUgb3IgMikgbW92ZSBmcm9tIHR3by0NCj4+IHNwYWNlIGluZGVudCB0byBzaW5nbGUtc3Bh Y2UgaW5kZW50LiAgRG8geW91IGhhdmUgYSBwcmVmZXJlbmNlPw0KPg0KPiBJbiB0aGUgc2Vjb25k IGV4YW1wbGUgeW91IHVzZSAoMSkuICBZb3UgY2FuIGFsc28gdXNlICJcIiwgd2hpY2ggeW91DQo+ IGFyZSBhbHNvIGFscmVhZHkgdXNpbmcuDQoNClNvIEkgZG8sIGFsYmVpdCBvbmx5IGluIHRoZSBI VFRQLWhlYWRlciBwYXJ0cywgbm90IHRoZSBIVFRQLWJvZHkgcGFydHMuDQoNCkZXSVcsIG15IGJ1 aWxkLXNjcmlwdCBpbnNlcnRzIHNvdXJjZSBmaWxlcyBpbiBzaXR1IGFzIGRpcmVjdGVkIGJ5DQpw cm9jZXNzaW5nIGluc3RydWN0aW9ucy4gSSBjYW4gbW9kaWZ5IHRoZSBidWlsZC1zY3JpcHQgdG8g ZG8gdGhlIA0KYXV0by0nXCcgaW5zZXJ0aW9uIGxvZ2ljIG9uIHNvbWUgY29sdW1uLWJvdW5kYXJ5 LCBidXQgaXQgbWF5IG5lZWQNCmEgY29tcGxpbWVudGFyeSB1cGRhdGUgb24gdGhlIGV4dHJhY3Rp b24gdG9vbHMuICBEbyB3ZSBuZWVkIHNvbWUgDQpzb3J0IG9mIHN0YW5kYXJkIGFyb3VuZCB0aGlz Pw0KDQpJJ20gYXdhcmUgdGhhdCBoZXJlIHlvdSdyZSBvbmx5IHRhbGtpbmcgYWJvdXQgZXhhbXBs ZXMsIHdoaWNoIA0KY3VycmVudGx5IGFyZSBub3QgZXh0cmFjdGVkIHZpYSB0b29scywgYnV0IHRo ZSBzYW1lIGF1dG8tJ1wnIA0KaW5zZXJ0aW9uIGxvZ2ljIGNvdWxkIGFsc28gaGVscCB3aXRoIHRo ZSBZQU5HIG1vZHVsZXMsIGFzIHRoZXkNCmNvdWxkIGJlY29tZSB1bndpZWxkeSB0b28uLi50aG91 Z2ggSSBzdXBwb3NlIGxpYmVyYWwgdXNlIG9mIA0KZ3JvdXBpbmdzIGNvdWxkIGFsd2F5cyBiZSBl bXBsb3llZCB0byBrZWVwIGxpbmUtbGVuZ3RocyBpbg0KY2hlY2suICBPa2F5LCBidXQgc3RpbGws IGEgWUFORyBEb2N0b3JzIGRpc2N1c3Npb24gYXQgSUVURiA5OQ0Kc3VnZ2VzdGVkIGludHJvZHVj aW5nIHRoZSBhYmlsaXR5IHRvIGF1dG8tZXh0cmFjdCBhbmQgdmFsaWRhdGUNCmV4YW1wbGVzIGlu IGRyYWZ0cyB0b28sIHRvIGF1dG9tYXRlIGFzIG11Y2ggb2YgdGhlIFlEIHJldmlldw0KcHJvY2Vz cyBhcyBwb3NzaWJsZSwgc28gc3RpbGwgSSB0aGluayB0aGVyZSBtYXkgYmUgYSBuZWVkIGZvcg0K YSAnXCcgc3RhbmRhcmQgb2Ygc29tZSBzb3J0IGhlcmUuICBUaG9ndWh0cz8NCg0KDQoNCj4gSSBq dXN0IGZvdW5kIGFub3RoZXIgb3V0ZGVudGVkIGZpZ3VyZSBpbiBzZWN0aW9uIDUuMywgd2hpY2gg cHJvYmFibHkNCj4gaXMgZWFzaWVyIHRvIGZpeC4NCg0KSHVoPyAgSSBkb24ndCBzZWUgaXQuICBU aGUgZmlndXJlIGluIDUuMyBsb29rcyBva2F5IHRvIG1lLi4uDQoNCg0KPj4gPiBvICBTZWN0aW9u IDkNCj4+ID4NCj4+ID4gIFNob3VsZCB5b3UgYWxzbyBtZW50aW9uIHRoYXQgL2RldmljZSBsaXN0 IHNob3VsZCBiZSBwcm90ZWN0ZWQgYnkNCj4+ID4gIG5hY20gcnVsZXM/DQo+PiANCj4+IFllcywg aW5kZWVkLCBJIGxlZnQgb3V0IHRoZSBzdGFuZGFyZCBzZWN1cml0eSB0ZW1wbGF0ZSBmb3IgdGhl IGJvb3RzdHJhcA0KPj4gc2VydmVyIFlBTkcgbW9kdWxlLiAgV2lsbCBhZGQuDQo+PiANCj4+IA0K Pj4gPiAgSWYgdGhlIFJFU1RDT05GIHVzZXIgbmFtZSBpcyB0aGUgZGV2aWNlJ3MgdW5pcXVlLWlk LCB0aGVuIGEgc2luZ2xlDQo+PiA+ICBOQUNNIHJ1bGUgY2FuIGJlIHVzZWQ6DQo+PiA+DQo+PiA+ ICAgICAgIDxydWxlPg0KPj4gPiAgICAgICAgIDxuYW1lPmFsbG93LWRldmljZTwvbmFtZT4NCj4+ ID4gICAgICAgICA8cGF0aCB4bWxuczp6dGJzPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6 XGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXIiPg0KPj4gPiAgICAgICAgICAgL3p0YnM6 ZGV2aWNlW3p0YnM6dW5pcXVlLWlkPSRVU0VSXQ0KPj4gPiAgICAgICAgIDwvcGF0aD4NCj4+ID4g ICAgICAgICA8YWNjZXNzLW9wZXJhdGlvbnM+cmVhZDwvYWNjZXNzLW9wZXJhdGlvbnM+DQo+PiA+ ICAgICAgICAgPGFjdGlvbj5wZXJtaXQ8L2FjdGlvbj4NCj4+ID4gICAgICAgPC9ydWxlPg0KPj4g DQo+PiBZZXMsIGJ1dCB3b3VsZCB5b3UgZXhwZWN0IHRoaXMgdG8gYXBwZWFyIGluIHRoZSBkcmFm dD8gIFR5cGljYWxseSwgdGhlIHNwZWNpZmljDQo+PiBOQUNNIHJ1bGUgc3ludGF4IGlzIGxlZnQg YXMgYW4gZXhlcmNpc2UgdG8gdGhlIHJlYWRlci4uLg0KPg0KPiBJbiBvcmRlciB0byBkbyB0aGlz LCB0aGUgInVzZXJuYW1lIiBtdXN0IGJlIHRoZSBzYW1lIGFzIHRoZQ0KPiAidW5pcXVlLWlkIi4g IFRoaXMgcmVxdWlyZXMgdGhlIGNsaWVudCBjZXJ0IHRvIGJlIGNvbnN0cnVjdGVkDQo+IHByb3Bl cmx5Lg0KDQpBZ3JlZWQuICBJbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQgY2VydCBpcyBhIERldklE IGNlcnQsIGFuZCAgODAyLjFBUiANCmdvdmVybnMgaXRzIGNvbnN0cnVjdGlvbi4gIE5vdCB0b28g bWFueSBvcHRpb25zIHRoZXJlLiAgT2YgY291cnNlLCANCnRoZSBtYXBwaW5nIG9mIHNhaWQgY2Vy dCB0byB1c2VybmFtZSBpcyBiZWluZyBkaXNjdXNzZWQgYWJvdmUgd3J0IHRoZQ0KY2VydC10by1u YW1lIG1hcHBpbmcgbG9naWMuLi4gDQoNCg0KPj4gU2luY2UgdGhlIE5BQ00gcnVsZSBpcyBub3Qg b2J2aW91cywgYW5kIGR1ZSB0byB0aGUgY2VydCBpbXBsaWNhdGlvbnMsDQo+PiBJIHRoaW5rIGl0 IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCB3aXRoIGFuIGFwcGVuZGl4IHRoYXQgZGVzY3JpYmVzIGhv dw0KPj4gdGhpcyBjYW4gYmUgc2V0IHVwLg0KDQpJIHRoaW5rIHRoYXQgdGhpcyB3aWxsIGRlcGVu ZCBvbiBpZiB3ZSBnbyB3aXRoIGFuIGFjdGlvbiBvciBhIHRvcC1sZXZlbCANClJQQy4gSWYgYW4g YWN0aW9uLCB0aGVuIE5BQ00gbWF5IGhhdmUgYSBwbGFjZSBhbmQgYW4gZXhhbXBsZSBtYXkgaGVs cC4NCkJ1dCwgaWYgdXNpbmcgYSB0b3AtbGV2ZWwgUlBDLCB0aGVuIGl0IHNlZW1zIHRoYXQgdGhl IHNlcnZlciBoYXMgbm8gDQpvcHRpb24gYnV0IHRvIGF1dGggdGhlIERldklEIGNlcnQgYW5kIHBy b3ZpZGUgYSBSRVNUQ09ORiB1c2VybmFtZS1zcGVjaWZpYw0KcmVzcG9uc2UgLSBOQUNNIGNhbid0 IGNvbnN0cmFpbiBpdCBhbnkgZnVydGhlciwgcmlnaHQ/ICAobm90ZTogdGhpcyBzZWVtcw0KbW9y ZSBzZWN1cmUgdG8gbWUgLSBJIGxpa2UgaXQpDQoNCg0KPj4gPiBvICBPdGhlciBjb21tZW50DQo+ PiA+DQo+PiA+ICBJcyBpdCBhc3N1bWVkIHRoYXQgdGhlcmUgd2lsbCBiZSBhIHZlbmRvci1zcGVj aWZpYyBZQU5HIG1vZHVsZSB0bw0KPj4gPiAgZW5hYmxlIHRoZSB6ZXJvLXRvdWNoIHByb2Nlc3M/ ICBEaWQgeW91IGNvbnNpZGVyIGFuDQo+PiA+ICBpZXRmLXplcm90b3VjaC1kZXZpY2UgbW9kdWxl IGZvciB0aGlzIHB1cnBvc2U/ICBTdWNoIGEgY29uZmlndXJhdGlvbg0KPj4gPiAgbXVzdCBiZSBj YXJlZnVsbHkgZGVzaWduZWQgdG8gYWxsb3cgZm9yIGEgIm1lcmdlIiBjb25maWd1cmF0aW9uIGZp bGUNCj4+ID4gIHRvIGFjdHVhbGx5IGRpc2FibGUgdGhlIHplcm8gdG91Y2ggcHJvY2Vzcy4NCj4+ IA0KPj4gSXQgaXMgYXNzdW1lZCB0byBiZSB2ZW5kb3Itc3BlY2lmaWMgY3VycmVudGx5LiAgSSBo YXZlIG5vdCB0aG91Z2h0IHRvDQo+PiBkZWZpbmUgYSBpZXRmLXplcm90b3VjaC1kZXZpY2UgbW9k dWxlIGFzIG9mIHlldCB0aGF0LCBwcmVzdW1hYmx5LCB3b3VsZA0KPj4gY29udGFpbiBhIGJvb2xl YW4gb3IgYW4gZW51bSAoYnV0IG5vdCBhIHAtY29udGFpbmVyKSBmb3IgZW5hYmxpbmcgdGhlDQo+ PiBzZXJ2aWNlLiAgRG8geW91IHRoaW5rIHdlIHNob3VsZCBhZGQgc3VjaCBhIG1vZHVsZSB0byB0 aGUgZHJhZnQsIG9yIGp1c3QNCj4+IHB1dCBhIG5vdGUgc29tZXdoZXJlIGFib3V0IGl0Pw0KPg0K PiBJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiwgYnV0IGlmIHRoZXJlJ3Mgbm90IGEgc3Rh bmRhcmQgbW9kdWxlDQo+IGZvciB0aGlzLCB0aGUgdGV4dCBzaG91bGQgbWVudGlvbiB0aGF0IGl0 IGlzIGFzc3VtZWQgdGhhdCB2ZW5kb3JzDQo+IGRlZmluZSB0aGlzIHRoZW1zZWx2ZXMuICAgSG1t LCBJIHRoaW5rIEkgd291bGQgcHJlZmVyIGEgc3RhbmRhcmQNCj4gbW9kdWxlOyBpdCB3b3VsZCBt YWtlIHRoZSBzb2x1dGlvbiBtb3JlIGNvbXBsZXRlLg0KDQpXZSBjYW4gYWRkIGEgbW9kdWxlLCBi dXQgbWF5YmUgaXQgc2hvdWxkIGJlIGNhbGxlZCBzb21ldGhpbmcgbGlrZQ0KaWV0Zi16ZXJvdG91 Y2gtYm9vdHN0cmFwLWNsaWVudCwgdG8gbWlycm9yIHRoZSBpZXRmLXplcm90b3VjaC0NCmJvb3Rz dHJhcC1zZXJ2ZXIgbW9kdWxlPyAtIHRob3VnaCB0aGlzIG1heSBiZSBhIG1pc21hdGNoIGFzIHRo ZQ0KZm9ybWVyIHJlZ2FyZHMgYSBzb3V0aGJvdW5kIHByb3RvY29sIGFuZCB0aGUgbGF0dGVyIHJl Z2FyZHMgYQ0KY29uZmlndXJhdGlvbiBtb2RlbC4uLg0KDQpNYXliZSB3ZSBjYW4gZGlzY3VzcyB3 aGF0IHdvdWxkIGJlIGluIHRoaXMgbW9kZWwuICBJJ20gbm90IHN1cmUgaWYNCkknbSBvdmVyc2lt cGxpZnlpbmcgaXQsIGJ1dCBJIHRoaW5rIHRoZSBtb2R1bGUgbWlnaHQgYmUganVzdCBhIHNpbmds ZQ0KY29uZmlnIHRydWUgbGVhZiBjYWxsZWQgc29tZXRoaW5nIGxpa2UgImVuYWJsZWQiLiAgIFRo ZXJlIG1pZ2h0IGFsc28NCmJlIHNvbWUgY29uZmlnIGZhbHNlIGxlYWZzIGZvciB0aGUgc3R1ZmYg bWVudGlvbmVkIGluIHNlY3Rpb24gNS4xLCANCnRob3VnaCBpdCBkb2luZyBzbyBpcyBub3Qgc28g aW1wb3J0YW50IHNpbmNlIHRoZSBib290c3RyYXBwaW5nIG9ubHkNCm9jY3VycyBvbmNlIChub3Qg b25nb2luZyBtYW5hZ2VtZW50KS4gIFNvIGEgbW9kdWxlIHdvdWxkIHByaW1hcmlseQ0KYmUgZm9y IHRoZSAiZW5hYmxlZCIgbGVhZi4gIEFueXRoaW5nIGVsc2U/ICBTdGlsbCB0aGluayBpdCdzIHdv cnRoIGl0Pw0KDQoNClRoYW5rcyBhZ2FpbiwNCktlbnQNCg0KDQoNCg== From nobody Fri Sep 29 03:46:11 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0783126C7A; Fri, 29 Sep 2017 03:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2Y9MYZdJNC7; Fri, 29 Sep 2017 03:46:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62A8132076; Fri, 29 Sep 2017 03:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9052; q=dns/txt; s=iport; t=1506681961; x=1507891561; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=vFQvXd4NcNd1EJwj8MJO0sBziszLOt0I/cSPtD6jtIU=; b=bWreyUTJrQNS9bJF5Fp6Pigx/YcP95rcvFajnooTsup5nSNrk0artX5s 0ByLHe/u7noSvEn1GG3Jd6ShH6GOvxlDC2mDMh/IpHE7DvJ+gYD9HGybV x+nuzVAGqSuT7dXV/IIuy6rPUr2dJPKPpWMer6Qh7A4zNHntSObCoM33J s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQAEI85Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+CP4QfixOQQSKQbYQ9gxMKhTsChG0VAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FIwpcCRoqAgJXBgEMCAEBii2JSp1mgicnix4BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgy2DU4FqKwuLCYJgBaEsgW2Sd4IUiUgkhweNdYdZgTk1IoEOMiEIHRWGGIF?= =?us-ascii?q?PP4hwAQEB?= X-IronPort-AV: E=Sophos;i="5.42,452,1500940800"; d="scan'208,217";a="657908349" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 10:45:56 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8TAjulp025374; Fri, 29 Sep 2017 10:45:56 GMT To: wangzitao , Mahesh Jethanandani , netconf , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <598c104e-4e7b-44bf-7328-0a7f6c05bafe@cisco.com> Date: Fri, 29 Sep 2017 11:45:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C23AC0AA0291209F29A1A142" Content-Language: en-US Archived-At: Subject: [Netconf] Config true/false Read/Write vs Read Only [was Re: WG adoption of NETCONF NDMA draft] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 10:46:04 -0000 This is a multi-part message in MIME format. --------------C23AC0AA0291209F29A1A142 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit [Cross posting to Netmod WG] Hi Michael, On 26/09/2017 03:27, wangzitao wrote: > > Hi WG, > > I support adoption of this work. And I have some comments: > > ……………………………………………………………………………………………………………………………………………………………………….. > >          container where { > >            description > >              "Filter content with the specified criteria.  All given > >               criteria are logically AND:ed."; > >            leaf config { > >              type boolean; > >              description > >                "Filter for nodes with the given value for their > >                 'config' property."; > >            } > > : Here defined config truth/false as a filter’s criteria. > According to NMDA revised datastore, there are four type (ct = config > true; cf = config false > >        rw = read-write; ro = read-only). Why not define the “rw” and > “ro” as other criteria? The ct/cf and rw/ro are reporting two different things are 2 different things: A YANG schema node can be labelled as config true, or config false. Some YANG datastores can only be read by a client (e.g. and ). Other YANG datastores can be both read and also written by the client (e.g. , , ). Do you think that the NMDA draft is sufficiently clear on this point, or does this need to be clarified in some way? Thanks, Rob --------------C23AC0AA0291209F29A1A142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit [Cross posting to Netmod WG]

Hi Michael,

On 26/09/2017 03:27, wangzitao wrote:

Hi WG,

I support adoption of this work. And I have some comments:

 

………………………………………………………………………………………………………………………………………………………………………..

         container where {

           description

             "Filter content with the specified criteria.  All given

              criteria are logically AND:ed.";

 

           leaf config {

             type boolean;

             description

               "Filter for nodes with the given value for their

                'config' property.";

           }

<Michael>: Here defined config truth/false as a filter’s criteria. According to NMDA revised datastore, there are four type (ct = config true; cf = config false

       rw = read-write; ro = read-only). Why not define the “rw” and “ro” as other criteria?
The ct/cf and rw/ro are reporting two different things are 2 different things:

A YANG schema node can be labelled as config true, or config false.
Some YANG datastores can only be read by a client (e.g. <intended> and <operational>).
Other YANG datastores can be both read and also written by the client (e.g. <running>, <startup>, <candidate>).
 
Do you think that the NMDA draft is sufficiently clear on this point, or does this need to be clarified in some way?

Thanks,
Rob

--------------C23AC0AA0291209F29A1A142-- From nobody Fri Sep 29 09:25:36 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF0126E64 for ; Fri, 29 Sep 2017 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oUUaMrJ_Wl9 for ; Fri, 29 Sep 2017 09:25:33 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6228F126B6D for ; Fri, 29 Sep 2017 09:25:33 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id t81so161738lff.0 for ; Fri, 29 Sep 2017 09:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=aKcbiCR9mMgnpUTATiZ1rvAMJy6EVRZYD2ZycSQc7qs=; b=ljLwTsdDQHeE1Vmvt0efArozpw2m589TZ0Z9bEGLZuswkCn2BHrQZp8z2TkOxaXGjR 5JFhlIOj+hYzaJYE14IidoyktPLADesg7D0OZoQTO1tzD5OKSnn+eUImGVGknDa7PKEU bOCn9UeCvkX5o13xxwZttWgHuQa24p2tRgXBX17wn+VUyGpbXTJ9umLxQ3ZeYZ0RD+dn rMNr9KKKvXtpHkZmtEGD3aF09BdrZAYowKjC8lU3VMd6oAs0hl6QZHhyWhZJt7VAcAvt uu8AaXahOSQisDVAQOyTjorloHjSaV9MEpmTUEbcUa3gJenbvDReW6AI3W2EwZLdjQXp XM6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=aKcbiCR9mMgnpUTATiZ1rvAMJy6EVRZYD2ZycSQc7qs=; b=UNtVxmO6uhayR9QMSfJYjRZymxR2iXzivoMAz4+MN1i3W/rs209E+GTOY1HhubR8pT 2n/RHYsSf/XNBMISs7lkXNhIGy/pfwwLD77wrHzGbnFRCzvxje16t2ywpMmdLUEJH3BP hbviw3/551jUWBeIPgQwZvbR0gpmaXwVG/eWw9z7B8VVpLXKXBo5sVxRJdkB1cQqu8RT etej5iPbUPhbPE/SCrEe6M02wuZIAXVV1C+z1WKVxsMmtTJwJG3s6FfW1AiqpJnLdpeF 3zKIqc7t0+Cdd0twT2af66bLQz79vg3yJ+Zyi4Q4/tpHKZ76ms/fksnBr3bLufNC2ek/ W5Dw== X-Gm-Message-State: AHPjjUj1NL2l/cGGU3gbUXx7SPkP9J+PJ2S8ncuBKLDoIp+XU89DCLc0 vyaC9QGo0DXWrfuUDGQQ2b0= X-Google-Smtp-Source: AOwi7QBY88n2e/V9ndory6M7CCi0wRKE9JxDKFH7dvFTvBCmHc9/cZAxTKUC8/nonhiBKOYwXmUHYw== X-Received: by 10.46.109.10 with SMTP id i10mr3728086ljc.76.1506702331689; Fri, 29 Sep 2017 09:25:31 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id q68sm615442lfd.63.2017.09.29.09.25.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 09:25:31 -0700 (PDT) From: "Xufeng Liu" To: "'Mahesh Jethanandani'" , "'netconf'" References: In-Reply-To: Date: Fri, 29 Sep 2017 12:25:28 -0400 Message-ID: <029e01d3393f$9164c6a0$b42e53e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029F_01D3391E.0A53E9F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKnIWaf+XxG3mxnCCxok0yu8h8s96EkPBiA Content-Language: en-us Archived-At: Subject: Re: [Netconf] WG adoption of NETCONF NDMA draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 16:25:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_029F_01D3391E.0A53E9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support. Thanks, - Xufneg From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Sunday, September 24, 2017 1:18 AM To: netconf Subject: [Netconf] WG adoption of NETCONF NDMA draft The NETCONF NDMA draft was presented an discussed in IETF 99 in Prague. The authors agreed to provide an update, which they did with -01 version of the draft. The authors believe the document is ready for WG adoption. This starts a two week call to adopt NETCONF NDMA draft as a WG document. Since the focus of the draft is NDMA compliance, it falls within the charter of the WG. https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 Please indicate whether you think this draft should be adopted as a WG item. If you have objections to it being adopted, please state your reasons by responding on this thread. Thanks. Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_029F_01D3391E.0A53E9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Thanks,

- = Xufneg

 

From: = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Sunday, September 24, 2017 1:18 = AM
To: netconf <netconf@ietf.org>
Subject: = [Netconf] WG adoption of NETCONF NDMA draft

 

The NETCONF = NDMA draft was presented an discussed in IETF 99 in Prague. The authors = agreed to provide an update, which they did with -01 version of the = draft. The authors believe the document is ready for WG = adoption.

 

This starts a two week call to adopt NETCONF NDMA = draft as a WG document. Since the focus of the draft is NDMA compliance, = it falls within the charter of the WG.

 

https://t= ools.ietf.org/html/draft-dsdt-nmda-netconf-01

 

Please indicate whether you think this draft should be = adopted as a WG item. If you have objections to it being adopted, please = state your reasons by responding on this thread.

 

Thanks.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_029F_01D3391E.0A53E9F0-- From nobody Fri Sep 29 15:23:47 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 920B7134307; Fri, 29 Sep 2017 15:23:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150672381653.3200.16003306212846397024@ietfa.amsl.com> Date: Fri, 29 Sep 2017 15:23:36 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-notification-messages-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 22:23:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Notification Message Headers and Bundles Authors : Eric Voit Andy Bierman Alexander Clemm Tim Jenkins Filename : draft-ietf-netconf-notification-messages-00.txt Pages : 15 Date : 2017-09-29 Abstract: This document specifies transport independent capabilities for messages transporting event notifications and YANG datastore update records. Included are: o a set of transport agnostic message header objects, and o how to associate a subset of these header objects with one or more events, YANG datastore updates, and/or alarms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-messages-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-messages-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 29 15:43:03 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D33E113339A; Fri, 29 Sep 2017 15:42:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150672497782.3192.14195088295012705194@ietfa.amsl.com> Date: Fri, 29 Sep 2017 15:42:57 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-notification-messages-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 22:42:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Notification Message Headers and Bundles Authors : Eric Voit Andy Bierman Alexander Clemm Tim Jenkins Filename : draft-ietf-netconf-notification-messages-01.txt Pages : 21 Date : 2017-09-29 Abstract: This document defines a new notification message format, using yang- data. Included are: o a new notification mechanism and encoding to replace the one way operation of RFC-5277 o a set of common, transport agnostic message header objects. o how to bundle multiple event records into a single notification message. o how to ensure these new capabilities are only used with capable receivers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-messages-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-messages-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-messages-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/