From nobody Tue Feb 2 03:55:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB951B2A25 for ; Tue, 2 Feb 2016 03:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMQIcNHV-VPA for ; Tue, 2 Feb 2016 03:55:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19C5F1B2A24 for ; Tue, 2 Feb 2016 03:55:35 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 4FCF91AE0285; Tue, 2 Feb 2016 12:55:33 +0100 (CET) Date: Tue, 02 Feb 2016 12:55:36 +0100 (CET) Message-Id: <20160202.125536.1496489376576425450.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 11:55:36 -0000 Hi, Going through all comments on YANG library, I found this one, where no decision has been made. Andy Bierman wrote: > On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka wrote: > > > Hi, > > > > I reviewed the draft and found several issues: [...] > > - The name "conformance" seems to be a misnomer: the leaf gives > > information about how the module is used by the server. What > > about "role"? > > > > > Role is rather generic. How about conformance-role? Since the description of this leaf already says: "Indicates the type of conformance the server is claiming for the YANG module identified by this entry."; should the name be "conformance-type"? /martin From nobody Tue Feb 2 04:07:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFBC1A6F68 for ; Tue, 2 Feb 2016 04:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVrFqrjLpGYe for ; Tue, 2 Feb 2016 04:07:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325231A1B51 for ; Tue, 2 Feb 2016 04:07:19 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c] (unknown [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c]) by mail.nic.cz (Postfix) with ESMTPSA id ED747180C10; Tue, 2 Feb 2016 13:07:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454414837; bh=7152dCjtT7svbwohkVTxWeWEyoXIP+mCJfddOuKmAfY=; h=From:Date:To; b=GZ4uckE1hmOjx3RZmVSgdIymwoIUitxmwcbqqaoqoPjYDfTEXJo6Yu4VGV5Nt7rrK ocZIhln5T64EijvIMXxzzxG77mvN3XIx9Zm7I9DLpGEOli4xyWUEJhTSP4HZTyiHe5 U6fa2qlWVTpkFYcIpEEUyoeBSO31CE3ztdi2q0ic= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160202.125536.1496489376576425450.mbj@tail-f.com> Date: Tue, 2 Feb 2016 13:07:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160202.125536.1496489376576425450.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 12:07:20 -0000 > On 02 Feb 2016, at 12:55, Martin Bjorklund wrote: >=20 > Hi, >=20 > Going through all comments on YANG library, I found this one, where no > decision has been made. >=20 > Andy Bierman wrote: >> On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka = wrote: >>=20 >>> Hi, >>>=20 >>> I reviewed the draft and found several issues: >=20 > [...] >=20 >>> - The name "conformance" seems to be a misnomer: the leaf gives >>> information about how the module is used by the server. What >>> about "role"? >>>=20 >>=20 >>=20 >> Role is rather generic. How about conformance-role? >=20 > Since the description of this leaf already says: >=20 > "Indicates the type of conformance the server is claiming > for the YANG module identified by this entry."; >=20 > should the name be "conformance-type"? I'd prefer conformance-role because "type" already has a diferrent = meaning in YANG. Perhaps the description could be updated like this: = =20 "Indicates the role in conformance the server is claiming for the YANG module identified by this entry."; Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 05:11:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27A1B2A92 for ; Tue, 2 Feb 2016 05:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9fYaInV7De4 for ; Tue, 2 Feb 2016 05:11:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 53F661A0031 for ; Tue, 2 Feb 2016 05:11:14 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id D1A151AE0285; Tue, 2 Feb 2016 14:11:12 +0100 (CET) Date: Tue, 02 Feb 2016 14:11:16 +0100 (CET) Message-Id: <20160202.141116.1182471876520058511.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160202.125536.1496489376576425450.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:11:15 -0000 Ladislav Lhotka wrote: > > > On 02 Feb 2016, at 12:55, Martin Bjorklund wrote: > > > > Hi, > > > > Going through all comments on YANG library, I found this one, where no > > decision has been made. > > > > Andy Bierman wrote: > >> On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka > >> wrote: > >> > >>> Hi, > >>> > >>> I reviewed the draft and found several issues: > > > > [...] > > > >>> - The name "conformance" seems to be a misnomer: the leaf gives > >>> information about how the module is used by the server. What > >>> about "role"? > >>> > >> > >> > >> Role is rather generic. How about conformance-role? > > > > Since the description of this leaf already says: > > > > "Indicates the type of conformance the server is claiming > > for the YANG module identified by this entry."; > > > > should the name be "conformance-type"? > > I'd prefer conformance-role because "type" already has a diferrent > meaning in YANG. If we following that logic, we cannot have interface type, no routing-instance type etc. To me "conformance role" sounds a bit weird, but maybe someone native speaker can comment? /martin > Perhaps the description could be updated like this: > > "Indicates the role in conformance the server is claiming > for the YANG module identified by this entry."; > > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Feb 2 05:28:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D31B2AD9 for ; Tue, 2 Feb 2016 05:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSDkzMHDjzDD for ; Tue, 2 Feb 2016 05:28:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F901B2ACC for ; Tue, 2 Feb 2016 05:28:55 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c] (unknown [IPv6:2001:1488:fffe:255:21d4:572a:e9f9:8a7c]) by mail.nic.cz (Postfix) with ESMTPSA id E9997181AE8; Tue, 2 Feb 2016 14:28:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454419733; bh=d1ubG/7NlBilgn7Ln0GtIeNDg+f9BLq+TcmdRBudVoo=; h=From:Date:To; b=g3jIHIakd/tZZn3Q9j9YvKNpSNe0s+VgDCAgRmyo9xK5RSvNRcXAnePvuq0OBmh4M PXPTGanV4JlKoHKgeU/e/su2ZO8walomq4iAqVnjUQ7o0DhuZdpe+dpKj95rdtvxiV Ymt6RlG0+9KgqKl6xX9w+hSio/DclGCpJyszEOZ4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160202.141116.1182471876520058511.mbj@tail-f.com> Date: Tue, 2 Feb 2016 14:28:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1464B357-ADBE-4312-888F-3FE738A76BF1@nic.cz> References: <20160202.125536.1496489376576425450.mbj@tail-f.com> <20160202.141116.1182471876520058511.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:28:57 -0000 > On 02 Feb 2016, at 14:11, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 02 Feb 2016, at 12:55, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> Going through all comments on YANG library, I found this one, where = no >>> decision has been made. >>>=20 >>> Andy Bierman wrote: >>>> On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I reviewed the draft and found several issues: >>>=20 >>> [...] >>>=20 >>>>> - The name "conformance" seems to be a misnomer: the leaf gives >>>>> information about how the module is used by the server. What >>>>> about "role"? >>>>>=20 >>>>=20 >>>>=20 >>>> Role is rather generic. How about conformance-role? >>>=20 >>> Since the description of this leaf already says: >>>=20 >>> "Indicates the type of conformance the server is claiming >>> for the YANG module identified by this entry."; >>>=20 >>> should the name be "conformance-type"? >>=20 >> I'd prefer conformance-role because "type" already has a diferrent >> meaning in YANG. >=20 > If we following that logic, we cannot have interface type, no > routing-instance type etc. >=20 > To me "conformance role" sounds a bit weird, but maybe someone native > speaker can comment? Actually, is the way how the module is used in the data model related to = conformance? Lada >=20 >=20 > /martin >=20 >=20 >> Perhaps the description could be updated like this: >>=20 >> "Indicates the role in conformance the server is claiming >> for the YANG module identified by this entry."; >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 2 09:52:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B31B2DCD for ; Tue, 2 Feb 2016 09:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gYPmic4G4BI for ; Tue, 2 Feb 2016 09:52:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169141B2E01 for ; Tue, 2 Feb 2016 09:52:34 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-33-56b0ecdfc0ad Received: from ESGSCHC003.ericsson.se (Unknown_Domain [146.11.116.74]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8F.D4.30208.0ECE0B65; Tue, 2 Feb 2016 18:52:33 +0100 (CET) Received: from ESGSCMB103.ericsson.se ([169.254.3.89]) by ESGSCHC003.ericsson.se ([10.0.18.179]) with mapi id 14.03.0248.002; Wed, 3 Feb 2016 01:52:32 +0800 From: Yong Zhu To: Juergen Schoenwaelder Thread-Topic: [Netconf] Question on filter - is it valid that multiple content match nodes in nested containers Thread-Index: AdFap8Ot36Q1Kvl+TcuewGBb8tchfv//04cA//letxA= Date: Tue, 2 Feb 2016 17:52:30 +0000 Message-ID: <31BFEF67CF6AC44BBEDE1890158D7377388AB002@ESGSCMB103.ericsson.se> References: <31BFEF67CF6AC44BBEDE1890158D737738896D59@ESGSCMB103.ericsson.se> <20160129203526.GA6532@elstar.local> In-Reply-To: <20160129203526.GA6532@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZxF3ipfvwzYYwg32rxSyubvzJaDF1021W ByaPJUt+MnlsOOAZwBTFZZOSmpNZllqkb5fAldF+eBNrwWzeinf757M3MG7m6mLk5JAQMJFY saqBFcIWk7hwbz1bFyMXh5DAYUaJI/MvMUM4Cxgl9v+ewQRSxSagJnHi8lYWEFtEwEGif1s3 G4jNLKAp8f5nH5gtLFAg0f9sATtETaHEl7P/WCFsK4l3b6aBzWERUJHY9m86WJxXwFdi2pLv YDOFBEokbiw/AVbDKWAocXfVQzCbEei676fWMEHsEpe49WQ+E8TVAhJL9pxnhrBFJV4+/gf1 jZJE46ttUPU6Egt2f4K6U1ti2cLXzBB7BSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjKLF qcVJuelGxnqpRZnJxcX5eXp5qSWbGIHxc3DLb9UdjJffOB5iFOBgVOLhLXi8PkyINbGsuDL3 EKMEB7OSCK/e4w1hQrwpiZVVqUX58UWlOanFhxilOViUxHnXOANVC6QnlqRmp6YWpBbBZJk4 OKUaGHs5fjHUx1molzHPOrlt4q0GrdOqvxU9i7X2xz51F/29/OIz8ctuk3f6d3VkqW/fOkvg CJ/XuenaPcKr8jfOdrhp3la183Nx8PQF6/Z9FHtr+mjawcK17vsnBRdbni+0swgx8Q3l+rf+ 59WKSfO0qnqPB6m7z7y97c+EVvH2O+YX377e4LHWrlOJpTgj0VCLuag4EQDyZJElmwIAAA== Archived-At: Cc: "Netconf@ietf.org" Subject: Re: [Netconf] Question on filter - is it valid that multiple content match nodes in nested containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:52:37 -0000 Hi Juergen, Thank for reminder. I modified the filter request. Please comment on the fo= llowing: > > > > users leaf1 match content > > user leaf1 match content > > > > -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 29, 2016 12:35 PM To: Yong Zhu Cc: Netconf@ietf.org Subject: Re: [Netconf] Question on filter - is it valid that multiple conte= nt match nodes in nested containers This is invalid XML. /js On Fri, Jan 29, 2016 at 03:21:45PM +0000, Yong Zhu wrote: > Hi Workgroup, >=20 > I just want to verify the "nested multiple content match nodes" filter is= valid or not. > " o If any containment nodes are present in the sibling set, then they > are processed further and included if any nested filter criteria > are also met. > "=20 > >From the above, I think it is valid filter, right? >=20 > For example: > > > > users leaf1 match content > > user leaf1 match content > > > > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=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 Tue Feb 2 22:55:20 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEB11A7014 for ; Tue, 2 Feb 2016 22:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkIJFhkM_MFG for ; Tue, 2 Feb 2016 22:55:16 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DDB1A700E for ; Tue, 2 Feb 2016 22:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7373; q=dns/txt; s=iport; t=1454482516; x=1455692116; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=liCAAq22qE8WEXw4OaIdrjzR/6eMdYsXcWbZm6c8zO8=; b=kNFdIornt6Lj+64eU60arGxDCYqoheuvf43Kz5CWt6usqvVaWQpBnOdB pKW0zQXyJpest2E+3IIKGUjQey85OmreMcJMyybjUMVdeBtZ5pWrx68+g ofOaRj+VvI+1ACyRIGA+SifxW1URAhePHn4HTmDh3e+4itHki/ndGhXNa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBADLo7FW/xbLJq1ehAxtiFuzYhcBC?= =?us-ascii?q?YVsAoIRAQEBAQEBgQuEQQEBAQQBAQFLKhEcAwECCgMTDwkDAgECARUKFQcCCAY?= =?us-ascii?q?NBgIBARAHAgSHeg6/PgEBAQEBAQEBAgEBAQEBAQEBAReGD4Q3gTaCW0GEGgWSb?= =?us-ascii?q?IQFhUmIBIFbh0WFUYVwiFBighCBVTsuAYg6gTABAQE?= X-IronPort-AV: E=Sophos;i="5.22,388,1449532800"; d="scan'208,217";a="623991356" 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; 03 Feb 2016 06:55:13 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u136tDe8023848 for ; Wed, 3 Feb 2016 06:55:13 GMT References: <20160203015859.4428B1804F4@rfc-editor.org> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20160203015859.4428B1804F4@rfc-editor.org> Message-ID: <56B1A451.4060001@cisco.com> Date: Wed, 3 Feb 2016 07:55:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160203015859.4428B1804F4@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------020700020108060103080403" Archived-At: Subject: [Netconf] Fwd: RFC 7758 on Time Capability in NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:55:18 -0000 This is a multi-part message in MIME format. --------------020700020108060103080403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: RFC 7758 on Time Capability in NETCONF Date: Tue, 2 Feb 2016 17:58:59 -0800 (PST) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7758 Title: Time Capability in NETCONF Author: T. Mizrahi, Y. Moses Status: Experimental Stream: IETF Date: February 2016 Mailbox: dew@tx.technion.ac.il, moses@ee.technion.ac.il Pages: 32 Characters: 56330 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-mm-netconf-time-capability-09.txt URL: https://www.rfc-editor.org/info/rfc7758 DOI: http://dx.doi.org/10.17487/RFC7758 This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC . --------------020700020108060103080403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: RFC 7758 on Time Capability in NETCONF
Date: Tue, 2 Feb 2016 17:58:59 -0800 (PST)
From: rfc-editor@rfc-editor.org
Reply-To: ietf@ietf.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org 


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

        
        RFC 7758

        Title:      Time Capability in NETCONF 
        Author:     T. Mizrahi, Y. Moses
        Status:     Experimental
        Stream:     IETF
        Date:       February 2016
        Mailbox:    dew@tx.technion.ac.il, 
                    moses@ee.technion.ac.il
        Pages:      32
        Characters: 56330
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-mm-netconf-time-capability-09.txt

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

        DOI:        http://dx.doi.org/10.17487/RFC7758

This document defines a capability-based extension to the Network
Configuration Protocol (NETCONF) that allows time-triggered
configuration and management operations.  This extension allows
NETCONF clients to invoke configuration updates according to
scheduled times and allows NETCONF servers to attach timestamps to
the data they send to NETCONF clients.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

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

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

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


The RFC Editor Team
Association Management Solutions, LLC


.


--------------020700020108060103080403-- From nobody Tue Feb 2 23:32:09 2016 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 3E30D1ACCF0; Tue, 2 Feb 2016 23:32:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203073208.31793.31874.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 23:32:08 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-library-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 07:32: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 Working Group of the IETF. Title : YANG Module Library Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-library-04.txt Pages : 15 Date : 2016-02-02 Abstract: This document describes a YANG library, which provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-library-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 3 11:30:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032F1B2BB3 for ; Wed, 3 Feb 2016 11:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi-o5GWwU79z for ; Wed, 3 Feb 2016 11:30:09 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1B1B2BB2 for ; Wed, 3 Feb 2016 11:30:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=R0qPJ3jWnhtpLqkbHQd+pEaaKgKH7It2qlHpR4g5vpx4P9D2x5eDWuTEv6nPZ1uq; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aR37r-0001Wd-3n for netconf@ietf.org; Wed, 03 Feb 2016 14:30:03 -0500 Received: from 76.254.54.151 by webmail.earthlink.net with HTTP; Wed, 3 Feb 2016 14:30:02 -0500 Message-ID: <19278805.1454527803112.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Wed, 3 Feb 2016 11:30:02 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddcb12e66837f8e69036a923554b222ef20350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:30:10 -0000 Hi - >From: Martin Bjorklund >Sent: Feb 2, 2016 5:11 AM >To: lhotka@nic.cz >Cc: netconf@ietf.org >Subject: Re: [Netconf] LL review of yang-library-03 ... >To me "conformance role" sounds a bit weird, but maybe someone native >speaker can comment? The first meaning that comes to the mind of this native speaker is not the intended one. I'd suggest something like "conformance category" or "conformance class". Randy From nobody Thu Feb 4 11:09:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F51ACDC1; Thu, 4 Feb 2016 11:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpU-Qx2_dMhU; Thu, 4 Feb 2016 11:09:15 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A6E1ACDB1; Thu, 4 Feb 2016 11:09:15 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id o185so53986470pfb.1; Thu, 04 Feb 2016 11:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=w1oujLD1FKzx2I4W/8VG4uwsRSghKrEVhyA+kpv+UKo=; b=ZZdkRaskR4OsCL5Q3gRvtsgy6rGxqwOKEIeU4jjGRzGnsTO3ka6L4iK07s4Th1I/XT 80l/cg8gojjZhQH52fGCkcunDpq+HY8DwM3dV4sMY5V9s/MPsrYjEUtgyhRMYg0niYZu Jpcrzrba9OpATNKGDq0Z8iIe1BC9DeYu5fQwc2+uPdWe3XOmkIhSLYUOLk05z8vCl4o+ Z0AC7U/q8G3niUB2MsPJ1kCfAITjpbVI5M+k819qVcbmq0y7dQdg5gEH4tVv0odMQPQu mhKMIqWHv3ezid3c+LS/8kB92Uj4u3O56bN2kIDq38LyEdJ4axAKJJo9u9DxTGocJ4NW 0g9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=w1oujLD1FKzx2I4W/8VG4uwsRSghKrEVhyA+kpv+UKo=; b=ASgbXLTunxc9+t2NGuYpodXoGJYH9n5FhVr5KgEZFksAclYwKaE3zV6iVJzkjccBQc Y+51OuhpoaopxfSMKcAD/+ofLHlE5tCbAaynU1O7chceky5DsIs0Q7i60K4dXmIOGqRt RDXvfX2hhwegHwfpyDtSl/1zlIC83+h1T/NqS1WSY9dmAITmKUsRtcQxUE/9cvU6hrWi Ha7GNp5IP9FjGhvOvxwVAFARbypXrNbzCJ+pkPz62AAttkIDpW6jkWXet9q27GnGke2U mD5hZJHrMoCmpS5QPa7DJIZnynR2+bFmc9dR8QsBqudvy6Hmr4vpkfX37HY+k8qZtlqy 19Ig== X-Gm-Message-State: AG10YORuwKU/3p2BEM4GkWeNt81awyz6hFwtS1o7Ikxc9jG3BsJN2jbWy2UFEfqI+L70MQ== X-Received: by 10.66.227.73 with SMTP id ry9mr13411451pac.120.1454612955324; Thu, 04 Feb 2016 11:09:15 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1004::442? ([2001:420:c0c8:1004::442]) by smtp.gmail.com with ESMTPSA id ud8sm11956415pac.11.2016.02.04.11.09.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Feb 2016 11:09:14 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9" Date: Thu, 4 Feb 2016 11:09:13 -0800 Message-Id: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> To: NETCONF Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: NETMOD Working Group Subject: [Netconf] YANG library draft. WG check of last call edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 19:09:17 -0000 --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The yang-library draft went through a Last Call that ended January 22. = Martin has taken the suggestions from the last call comments and posted = an updated draft. https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = Please review it for the changes made to the draft and any edits that = were either missed or are not right. This would not be a time to bring = in new changes or comments. The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. Cheers. Mahesh & Mehmet. --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The yang-library draft went through a Last Call that ended = January 22. Martin has taken the suggestions from the last call comments = and posted an updated draft.

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

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

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

Cheers.

Mahesh & Mehmet.



= --Apple-Mail=_6867F086-5686-49E8-ABEE-74F45D9821C9-- From nobody Mon Feb 8 01:59:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC321ACE03; Mon, 8 Feb 2016 01:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgFVn6fJ_bLB; Mon, 8 Feb 2016 01:59:27 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCEF1ACE63; Mon, 8 Feb 2016 01:59:17 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 316A71CC02FD; Mon, 8 Feb 2016 10:59:18 +0100 (CET) From: Ladislav Lhotka To: Mahesh Jethanandani , NETCONF In-Reply-To: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 08 Feb 2016 10:59:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NETMOD Working Group Subject: Re: [Netconf] YANG library draft. WG check of last call edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 09:59:29 -0000 Hi, I found one thing that may need clarification: consider a module containing deviations that's present in the "module" list as required. What happens if such a module does not appear in the "deviation" list of a module to which its deviation(s) are supposed to apply? Does it mean that such deviations are ignored? This doesn't seem to be specified in the description of the "deviation" list, or elsewhere. Lada Mahesh Jethanandani writes: > The yang-library draft went through a Last Call that ended January 22. Martin has taken the suggestions from the last call comments and posted an updated draft. > > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 > > Please review it for the changes made to the draft and any edits that were either missed or are not right. This would not be a time to bring in new changes or comments. > > The comment/review period will go till Monday, February 15, at which time it will be sent to our fearless AD, Benoit Claise for publication. > > Cheers. > > Mahesh & Mehmet. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 8 02:12:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E386D1ACE6E; Mon, 8 Feb 2016 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiG7J6SHx26k; Mon, 8 Feb 2016 02:12:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3B41ACE54; Mon, 8 Feb 2016 02:12:38 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 8504D1AE0285; Mon, 8 Feb 2016 11:12:36 +0100 (CET) Date: Mon, 08 Feb 2016 11:12:40 +0100 (CET) Message-Id: <20160208.111240.1169306129093802193.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] YANG library draft. WG check of last call edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 10:12:40 -0000 Ladislav Lhotka wrote: > Hi, > > I found one thing that may need clarification: consider a module > containing deviations that's present in the "module" list as > required. What happens if such a module does not appear in the "deviation" > list of a module to which its deviation(s) are supposed to apply? Does > it mean that such deviations are ignored? Yes. Just as it does today with similar info in . Note that this is not an error. For example, you might have a deviation module that deviates A and B, but in one particular implemementation, only the deviation for A applies. /martin > This doesn't seem to be specified in the description of the "deviation" > list, or elsewhere. > > Lada > > Mahesh Jethanandani writes: > > > The yang-library draft went through a Last Call that ended January 22. Martin has taken the suggestions from the last call comments and posted an updated draft. > > > > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 > > > > Please review it for the changes made to the draft and any edits that were either missed or are not right. This would not be a time to bring in new changes or comments. > > > > The comment/review period will go till Monday, February 15, at which time it will be sent to our fearless AD, Benoit Claise for publication. > > > > Cheers. > > > > Mahesh & Mehmet. > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Feb 8 02:33:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D11ACE8E; Mon, 8 Feb 2016 02:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkaODZ4KTFeL; Mon, 8 Feb 2016 02:33:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC661ACE92; Mon, 8 Feb 2016 02:33:04 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33] (unknown [IPv6:2001:718:1a02:1:c0d8:27e0:6fb7:ad33]) by mail.nic.cz (Postfix) with ESMTPSA id 267331804C6; Mon, 8 Feb 2016 11:33:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454927582; bh=FBPZULW/COkZNQsb/tjTdfPgDu6Texy8oxhlWFQPmlI=; h=From:Date:To; b=asFO5dpofye86nxzSfx+y+24riZPAZJ9m7o3x+ef5SLRdwGZvjJSzP+y4GPBbm1Dg kPW8wOr05SVV6OgCtpF+CCNQECNniL9P2yYnencTYXdjzb+s0B7HH1opi+f/HCeLzX Y6MzqlEJvMaNxjp5MEx6mB5V1MDbPt0lRuXI2cl8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160208.111240.1169306129093802193.mbj@tail-f.com> Date: Mon, 8 Feb 2016 11:33:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2AA00D5E-87E3-4797-93D9-44B0604E8883@nic.cz> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> <20160208.111240.1169306129093802193.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] YANG library draft. WG check of last call edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 10:33:08 -0000 > On 08 Feb 2016, at 11:12, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I found one thing that may need clarification: consider a module >> containing deviations that's present in the "module" list as >> required. What happens if such a module does not appear in the = "deviation" >> list of a module to which its deviation(s) are supposed to apply? = Does >> it mean that such deviations are ignored? >=20 > Yes. Just as it does today with similar info in . Note that IMO this isn't sufficiently explained in RFC 6020 either. > this is not an error. For example, you might have a deviation module > that deviates A and B, but in one particular implemementation, only > the deviation for A applies. OK, although this seems over-engineered, given that deviations are = strongly discouraged and cannot be standardised. I assume deviation = modules should mostly be very device-specific. Lada >=20 >=20 > /martin >=20 >> This doesn't seem to be specified in the description of the = "deviation" >> list, or elsewhere. >>=20 >> Lada >>=20 >> Mahesh Jethanandani writes: >>=20 >>> The yang-library draft went through a Last Call that ended January = 22. Martin has taken the suggestions from the last call comments and = posted an updated draft. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = >>>=20 >>> Please review it for the changes made to the draft and any edits = that were either missed or are not right. This would not be a time to = bring in new changes or comments. >>>=20 >>> The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. >>>=20 >>> Cheers. >>>=20 >>> Mahesh & Mehmet. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 8 14:23:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F171A88DC; Mon, 8 Feb 2016 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkATmEguD62e; Mon, 8 Feb 2016 14:23:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891941B3423; Mon, 8 Feb 2016 14:23:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIF99592; Mon, 08 Feb 2016 22:23:10 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 8 Feb 2016 22:23:10 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 8 Feb 2016 14:23:01 -0800 From: Linda Dunbar To: "'Netconf'" Thread-Topic: What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"? Thread-Index: AdFiv0TiE9T6VE7/TRiLhiatv3duJw== Date: Mon, 8 Feb 2016 22:23:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DE8236dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.56B9154F.00B3, 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: 03abb5c2a45dd58e9d41697e3b465cb0 Archived-At: Cc: "i2nsf@ietf.org" Subject: [Netconf] What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:23:21 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DE8236dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF participants, Your Chair Mehmet suggested sending the following questions to the list. I2NSF has a draft on remote attestation (https://datatracker.ietf.org/doc/d= raft-pastor-i2nsf-vnsf-attestation/ ) which documented the following securi= ty threats between Client and Controller. I think those issues also face I= 2RS and NETCONF. Has NETCONF specified some mechanisms to address those iss= ues? o An unknown/unauthorized user can try to impersonate another user that can legitimately access virtualized NSF services (or Network Services)= . This attack may lead to accessing the policies and applications of the attacked user or to generate network traffic outside a the security functions with a falsified identity. o An authorized user may misuse assigned privileges to alter the network traffic processing of other users in the virtualization platform. This can become especially serious when such a user has administration privileges granted by the virtualization provider, the ISP or the local network operator. o A user may try to install malformed elements (policy or application), trying to directly take the control of a NSF or virtualization platform (for example by exploiting a vulnerability on one of the functions or may try to intercept or modify the traffic of other users in the same platform. o A malicious virtualization provider can modify the software running on it (the operating system or a concrete vNSF) to alter the behaviour of the latter. This event has a high impact on all users accessing vNSFs as the virtualization provider has the highest level of privilege on the software in execution. o A user with physical access to the virtualization platform can modify the behavior of hardware components, or the components themselves. Furthermore, it can access a serial console (most devices offer this interface for maintenance reasons) to access the NSF software with the same level of privilege of the virtualization provider Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657DE8236dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NETCONF   participants,

 

Your Chair Mehmet suggested sending the following qu= estions to the list.

 

I2NSF has a draft on remote attestation (http= s://datatracker.ietf.org/doc/draft-pastor-i2nsf-vnsf-attestation/ ) whi= ch documented the following security threats between Client and Controller. I  think those issues also fac= e I2RS and NETCONF. Has NETCONF specified some mechanisms to address those = issues?

 

o An unknown/unauthorized u= ser can try to impersonate another user

that can legitimately acces= s virtualized NSF services (or Network Services). This

attack may lead to accessin= g the policies and applications of the

attacked user or to generat= e network traffic outside a the

security functions with a f= alsified identity.

 

o An authorized user may mi= suse assigned privileges to alter the

network traffic processing = of other users in the virtualization

platform. This can become e= specially serious when such a user has

administration privileges g= ranted by the virtualization provider,

the ISP or the local networ= k operator.

 

o A user may try to install= malformed elements (policy or

application), trying to dir= ectly take the control of a NSF or

virtualization platform (fo= r example by exploiting a vulnerability

on one of the functions or = may try to intercept or modify the

traffic of other users in t= he same platform.

 

o A malicious virtualizatio= n provider can modify the software

running on it (the operatin= g system or a concrete vNSF) to alter

the behaviour of the latter= . This event has a high impact on all

users accessing vNSFs as th= e virtualization provider has the

highest level of privilege = on the software in execution.

 

o A user with physical acce= ss to the virtualization platform can

modify the behavior of hard= ware components, or the components

themselves. Furthermore, it= can access a serial console (most

devices offer this interfac= e for maintenance reasons) to access

the NSF software with the s= ame level of privilege of the

virtualization provider

 

 

 

Thanks, Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657DE8236dfweml701chm_-- From nobody Mon Feb 8 16:21:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A4D1B3E1E; Mon, 8 Feb 2016 16:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok_M7WE6_qkD; Mon, 8 Feb 2016 16:20:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A111B3E20; Mon, 8 Feb 2016 16:20:51 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.403.16; Tue, 9 Feb 2016 00:20:32 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0403.017; Tue, 9 Feb 2016 00:20:32 +0000 From: Kent Watsen To: Linda Dunbar , 'Netconf' Thread-Topic: [Netconf] What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"? Thread-Index: AdFiv0TiE9T6VE7/TRiLhiatv3duJ///zQOA Date: Tue, 9 Feb 2016 00:20:32 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:i/l6puIHi8r3NWf5epclJp8Oxg6J1Nn7xxMKBzehrOmYRMMxraTcgWHcnkccXqQ3HPtsW0SB8WDR3U+qlWWc8B9fLNNE6Jdi+H96DlgQhZMnfF1qWbvLt77Frpnx02sYNRMSn15rVZHfVXwx53VihQ==; 24:26HoRZzKHJlLylHjrjJ+RuqzIBBNqTjSapqHO9yFi9nliK0g5rZH4xQJ91y7Gh9xI4qOjMHhOKH75dIzdceVVQ0etPifcjhvj14wD4P8j84= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: f89452c2-1af3-437d-82ab-08d330e6d2e5 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(51444003)(377454003)(50986999)(76176999)(92566002)(5002640100001)(3280700002)(36756003)(18717965001)(33656002)(16236675004)(19617315012)(83506001)(54356999)(82746002)(5001770100001)(19580395003)(19580405001)(4001350100001)(189998001)(5001960100002)(11100500001)(4326007)(2906002)(5004730100002)(19300405004)(3660700001)(1220700001)(1096002)(5008740100001)(6116002)(790700001)(3846002)(102836003)(586003)(83716003)(77096005)(122556002)(87936001)(15975445007)(10400500002)(40100003)(86362001)(2950100001)(2900100001)(19625215002)(99286002)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ACD729F5A4F644069F52C7ED697B3623junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2016 00:20:32.6989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [Netconf] What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 00:20:59 -0000 --_000_ACD729F5A4F644069F52C7ED697B3623junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHRoaW5rIHRoYXQgdGhpcyBpc3N1ZSBpcyBzaGFyZWQgYnkgKmFsbCogcmVtb3RlIG1hbmFn ZW1lbnQgbWVjaGFuaXNtcyAtIG5vdCBWTkZzLCBidXQga25vd2luZyB0aGF0IHRoZSBzeXN0ZW0g aGFzbuKAmXQgYmVlbiBjb21wcm9taXNlZC4gICBORVRDT05GL1JFU1RDT05GIHJlbHkgb24gc2Vy dmVyIGF1dGhlbnRpY2F0aW9uLCB1c2luZyB0aGUgc2VydmVy4oCZcyBwcmVzZW50ZWQgU1NIIGhv c3Qga2V5IG9yIFRMUyBzZXJ2ZXIgY2VydGlmaWNhdGUuICBPbmx5IHJlY2VudGx5IHdpdGggZHJh ZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaCBpcyB0aGVyZSBhIHB1c2ggdG8gc3RhcnQgdXNpbmcg SURldklEIGNlcnRpZmljYXRlcyB0aGF0IGFyZSBib3VuZCB0byBhIFRQTSwgYnV0IHRoaXMgb25s eSBnb2VzIHRvIHNob3cgdGhhdCB0aGUgc2VjdXJlLXR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCBo YXMgYWNjZXNzIHRvIHRoZSBUUE0gYW5kIG5vdGhpbmcgZWxzZS4gICBUaGF0IHNhaWQsIGlmIHRo ZSBwbGF0Zm9ybSBpcyBjZXJ0aWZpZWQgdG8gaW1wbGVtZW50IFNlY3VyZSBCb290LCB3aGljaCBp cyBhIG5lY2Vzc2FyeSBwcmVjb25kaXRpb24gdG8gc3VwcG9ydGluZyByZW1vdGUgYXR0ZXN0YXRp b24sIGl0IHNlZW1zIHRoYXQgY2xpZW50IGNhbiBhbHJlYWR5IGJlIHNhdGlzZmllZCB0aGF0IGl0 IGlzIGNvbW11bmljYXRpbmcgdG8gYW4gdW5jb21wcm9taXNlZCBzeXN0ZW0gd2l0aG91dCBuZWVk IGZvciByZW1vdGUgYXR0ZXN0YXRpb24uICAgSG93ZXZlciwgU2VjdXJlIEJvb3Qgb25seSB2ZXJp ZmllcyB0aGF0IHRoZSBwbGF0Zm9ybSBpcyBleGVjdXRpbmcgdGhlIHJpZ2h0IHNvZnR3YXJlIHN0 YWNrLCBidXQgZG9lcyBub3RoaW5nIHRvIGVuc3VyZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlcyBh bmQgdGhlIGxpa2UgaGF2ZW7igJl0IGJlZW4gdHdlYWtlZCAtIHRoaXMgaXMgd2hlcmUgVHJ1c3Rl ZCBCb290IChhLmsuYS4gTWVhc3VyZWQgQm9vdCkgY29tZXMgaW4uICBCdXQgaWYgdGhlIHBsYXRm b3JtIGlzIGtub3duIHRvIGJlIGdvb2QgKHZpYSBTZWN1cmUgQm9vdCksIHRoZW4gYW55IHR3ZWFr aW5nIHdvdWxkIGJlIHRoZSByZXN1bHQgb2YgdW5hdXRob3JpemVkIGFjY2VzcyAoZS5nLiwgc29t ZW9uZSBzdG9sZSB5b3VyIGxvZ2luIGNyZWRlbnRpYWxzKSwgd2hpY2ggbmVlZHMgYSBkaWZmZXJl bnQgc29sdXRpb24uICBTdXJlLCBUcnVzdGVkIEJvb3QgY2FuIHRlbGwgeW91IHNvbWV0aGluZ+KA mXMgdW5leHBlY3RlZCBjaGFuZ2VkLCBidXQgbm90IHdoYXQsIHdoZW4sIHdobywgZXRjLi4gIEFu eXdheXMsIEkgdGhpbmsgdGhpcyBpcyBhbGwgd2VsbCBhbmQgZ29vZCwgYnV0IHRoZSBpc3N1ZSBo YXMgYSBzY29wZSB0aGF0IGlzIGJleW9uZCBORVRDT05GLg0KDQpSZWxhdGVkIHRvIFZORnMgaW4g cGFydGljdWxhciwgbXkgdW5kZXJzdGFuZGluZyBhcyBvZiBsYXRlIGxhc3QgeWVhciBpcyB0aGF0 IGh5cGVydmlzb3JzIHN0aWxsIGxhY2tlZCBzdXBwb3J0IGZvciBTZWN1cmUgQm9vdC4gIEl0IHNl ZW1zIGxpa2UgdGhpcyBkcmFmdCBtaWdodCBiZSBnZXR0aW5nIGFoZWFkIG9mIHdoYXTigJlzIHBv c3NpYmxlLg0KDQpQUzogSeKAmW0gbm90IHN1YnNjcmliZWQgdG8gdGhlIGkybnNmIGxpc3QuDQoN CktlbnQNCg0KDQoNCkZyb206IE5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIExpbmRhIER1bmJhciA8 bGluZGEuZHVuYmFyQGh1YXdlaS5jb208bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4N CkRhdGU6IE1vbmRheSwgRmVicnVhcnkgOCwgMjAxNiBhdCA1OjIzIFBNDQpUbzogIm5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWls dG86bmV0Y29uZkBpZXRmLm9yZz4+DQpDYzogImkybnNmQGlldGYub3JnPG1haWx0bzppMm5zZkBp ZXRmLm9yZz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+Pg0KU3ViamVj dDogW05ldGNvbmZdIFdoYXQga2luZCBvZiBtZWNoYW5pc21zIGhhdmUgTkVUQ09ORiBzcGVjaWZp ZWQgdG8gcHJldmVudCBpbGxlZ2l0aW1hdGUiQ2xpZW50cyIgb3IgIkFnZW50Ij8NCg0KTkVUQ09O RiAgIHBhcnRpY2lwYW50cywNCg0KWW91ciBDaGFpciBNZWhtZXQgc3VnZ2VzdGVkIHNlbmRpbmcg dGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgdG8gdGhlIGxpc3QuDQoNCkkyTlNGIGhhcyBhIGRyYWZ0 IG9uIHJlbW90ZSBhdHRlc3RhdGlvbiAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcGFzdG9yLWkybnNmLXZuc2YtYXR0ZXN0YXRpb24vICkgd2hpY2ggZG9jdW1lbnRlZCB0 aGUgZm9sbG93aW5nIHNlY3VyaXR5IHRocmVhdHMgYmV0d2VlbiBDbGllbnQgYW5kIENvbnRyb2xs ZXIuIEkgIHRoaW5rIHRob3NlIGlzc3VlcyBhbHNvIGZhY2UgSTJSUyBhbmQgTkVUQ09ORi4gSGFz IE5FVENPTkYgc3BlY2lmaWVkIHNvbWUgbWVjaGFuaXNtcyB0byBhZGRyZXNzIHRob3NlIGlzc3Vl cz8NCg0KbyBBbiB1bmtub3duL3VuYXV0aG9yaXplZCB1c2VyIGNhbiB0cnkgdG8gaW1wZXJzb25h dGUgYW5vdGhlciB1c2VyDQp0aGF0IGNhbiBsZWdpdGltYXRlbHkgYWNjZXNzIHZpcnR1YWxpemVk IE5TRiBzZXJ2aWNlcyAob3IgTmV0d29yayBTZXJ2aWNlcykuIFRoaXMNCmF0dGFjayBtYXkgbGVh ZCB0byBhY2Nlc3NpbmcgdGhlIHBvbGljaWVzIGFuZCBhcHBsaWNhdGlvbnMgb2YgdGhlDQphdHRh Y2tlZCB1c2VyIG9yIHRvIGdlbmVyYXRlIG5ldHdvcmsgdHJhZmZpYyBvdXRzaWRlIGEgdGhlDQpz ZWN1cml0eSBmdW5jdGlvbnMgd2l0aCBhIGZhbHNpZmllZCBpZGVudGl0eS4NCg0KbyBBbiBhdXRo b3JpemVkIHVzZXIgbWF5IG1pc3VzZSBhc3NpZ25lZCBwcml2aWxlZ2VzIHRvIGFsdGVyIHRoZQ0K bmV0d29yayB0cmFmZmljIHByb2Nlc3Npbmcgb2Ygb3RoZXIgdXNlcnMgaW4gdGhlIHZpcnR1YWxp emF0aW9uDQpwbGF0Zm9ybS4gVGhpcyBjYW4gYmVjb21lIGVzcGVjaWFsbHkgc2VyaW91cyB3aGVu IHN1Y2ggYSB1c2VyIGhhcw0KYWRtaW5pc3RyYXRpb24gcHJpdmlsZWdlcyBncmFudGVkIGJ5IHRo ZSB2aXJ0dWFsaXphdGlvbiBwcm92aWRlciwNCnRoZSBJU1Agb3IgdGhlIGxvY2FsIG5ldHdvcmsg b3BlcmF0b3IuDQoNCm8gQSB1c2VyIG1heSB0cnkgdG8gaW5zdGFsbCBtYWxmb3JtZWQgZWxlbWVu dHMgKHBvbGljeSBvcg0KYXBwbGljYXRpb24pLCB0cnlpbmcgdG8gZGlyZWN0bHkgdGFrZSB0aGUg Y29udHJvbCBvZiBhIE5TRiBvcg0KdmlydHVhbGl6YXRpb24gcGxhdGZvcm0gKGZvciBleGFtcGxl IGJ5IGV4cGxvaXRpbmcgYSB2dWxuZXJhYmlsaXR5DQpvbiBvbmUgb2YgdGhlIGZ1bmN0aW9ucyBv ciBtYXkgdHJ5IHRvIGludGVyY2VwdCBvciBtb2RpZnkgdGhlDQp0cmFmZmljIG9mIG90aGVyIHVz ZXJzIGluIHRoZSBzYW1lIHBsYXRmb3JtLg0KDQpvIEEgbWFsaWNpb3VzIHZpcnR1YWxpemF0aW9u IHByb3ZpZGVyIGNhbiBtb2RpZnkgdGhlIHNvZnR3YXJlDQpydW5uaW5nIG9uIGl0ICh0aGUgb3Bl cmF0aW5nIHN5c3RlbSBvciBhIGNvbmNyZXRlIHZOU0YpIHRvIGFsdGVyDQp0aGUgYmVoYXZpb3Vy IG9mIHRoZSBsYXR0ZXIuIFRoaXMgZXZlbnQgaGFzIGEgaGlnaCBpbXBhY3Qgb24gYWxsDQp1c2Vy cyBhY2Nlc3Npbmcgdk5TRnMgYXMgdGhlIHZpcnR1YWxpemF0aW9uIHByb3ZpZGVyIGhhcyB0aGUN CmhpZ2hlc3QgbGV2ZWwgb2YgcHJpdmlsZWdlIG9uIHRoZSBzb2Z0d2FyZSBpbiBleGVjdXRpb24u DQoNCm8gQSB1c2VyIHdpdGggcGh5c2ljYWwgYWNjZXNzIHRvIHRoZSB2aXJ0dWFsaXphdGlvbiBw bGF0Zm9ybSBjYW4NCm1vZGlmeSB0aGUgYmVoYXZpb3Igb2YgaGFyZHdhcmUgY29tcG9uZW50cywg b3IgdGhlIGNvbXBvbmVudHMNCnRoZW1zZWx2ZXMuIEZ1cnRoZXJtb3JlLCBpdCBjYW4gYWNjZXNz IGEgc2VyaWFsIGNvbnNvbGUgKG1vc3QNCmRldmljZXMgb2ZmZXIgdGhpcyBpbnRlcmZhY2UgZm9y IG1haW50ZW5hbmNlIHJlYXNvbnMpIHRvIGFjY2Vzcw0KdGhlIE5TRiBzb2Z0d2FyZSB3aXRoIHRo ZSBzYW1lIGxldmVsIG9mIHByaXZpbGVnZSBvZiB0aGUNCnZpcnR1YWxpemF0aW9uIHByb3ZpZGVy DQoNCg0KDQpUaGFua3MsIExpbmRhDQoNCg== --_000_ACD729F5A4F644069F52C7ED697B3623junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSSB0aGlu ayB0aGF0IHRoaXMgaXNzdWUgaXMgc2hhcmVkIGJ5ICphbGwqIHJlbW90ZSBtYW5hZ2VtZW50IG1l Y2hhbmlzbXMgLSBub3QgVk5GcywgYnV0IGtub3dpbmcgdGhhdCB0aGUgc3lzdGVtIGhhc27igJl0 IGJlZW4gY29tcHJvbWlzZWQuICZuYnNwOyBORVRDT05GL1JFU1RDT05GIHJlbHkgb24gc2VydmVy IGF1dGhlbnRpY2F0aW9uLCB1c2luZyB0aGUgc2VydmVy4oCZcyBwcmVzZW50ZWQgU1NIIGhvc3Qg a2V5IG9yIFRMUyBzZXJ2ZXIgY2VydGlmaWNhdGUuICZuYnNwO09ubHkNCiByZWNlbnRseSB3aXRo Jm5ic3A7ZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaCBpcyB0aGVyZSBhIHB1c2ggdG8gc3Rh cnQgdXNpbmcgSURldklEIGNlcnRpZmljYXRlcyB0aGF0IGFyZSBib3VuZCB0byBhIFRQTSwgYnV0 IHRoaXMgb25seSBnb2VzIHRvIHNob3cgdGhhdCB0aGUgc2VjdXJlLXR1bm5lbCB0ZXJtaW5hdGlv biBwb2ludCBoYXMgYWNjZXNzIHRvIHRoZSBUUE0gYW5kIG5vdGhpbmcgZWxzZS4gJm5ic3A7IFRo YXQgc2FpZCwgaWYgdGhlIHBsYXRmb3JtDQogaXMgY2VydGlmaWVkIHRvIGltcGxlbWVudCBTZWN1 cmUgQm9vdCwgd2hpY2ggaXMgYSBuZWNlc3NhcnkgcHJlY29uZGl0aW9uIHRvIHN1cHBvcnRpbmcg cmVtb3RlIGF0dGVzdGF0aW9uLCBpdCBzZWVtcyB0aGF0IGNsaWVudCBjYW4gYWxyZWFkeSBiZSBz YXRpc2ZpZWQgdGhhdCBpdCBpcyBjb21tdW5pY2F0aW5nIHRvIGFuIHVuY29tcHJvbWlzZWQgc3lz dGVtIHdpdGhvdXQgbmVlZCBmb3IgcmVtb3RlIGF0dGVzdGF0aW9uLiAmbmJzcDsgSG93ZXZlciwg U2VjdXJlDQogQm9vdCBvbmx5IHZlcmlmaWVzIHRoYXQgdGhlIHBsYXRmb3JtIGlzIGV4ZWN1dGlu ZyB0aGUgcmlnaHQgc29mdHdhcmUgc3RhY2ssIGJ1dCBkb2VzIG5vdGhpbmcgdG8gZW5zdXJlIHRo ZSBjb25maWd1cmF0aW9uIGZpbGVzIGFuZCB0aGUgbGlrZSBoYXZlbuKAmXQgYmVlbiB0d2Vha2Vk IC0gdGhpcyBpcyB3aGVyZSBUcnVzdGVkIEJvb3QgKGEuay5hLiBNZWFzdXJlZCBCb290KSBjb21l cyBpbi4gJm5ic3A7QnV0IGlmIHRoZSBwbGF0Zm9ybSBpcyBrbm93biB0bw0KIGJlIGdvb2QgKHZp YSBTZWN1cmUgQm9vdCksIHRoZW4gYW55IHR3ZWFraW5nIHdvdWxkIGJlIHRoZSByZXN1bHQgb2Yg dW5hdXRob3JpemVkIGFjY2VzcyAoZS5nLiwgc29tZW9uZSBzdG9sZSB5b3VyIGxvZ2luIGNyZWRl bnRpYWxzKSwgd2hpY2ggbmVlZHMgYSBkaWZmZXJlbnQgc29sdXRpb24uICZuYnNwO1N1cmUsIFRy dXN0ZWQgQm9vdCBjYW4gdGVsbCB5b3Ugc29tZXRoaW5n4oCZcyB1bmV4cGVjdGVkIGNoYW5nZWQs IGJ1dCBub3Qgd2hhdCwgd2hlbiwgd2hvLA0KIGV0Yy4uICZuYnNwO0FueXdheXMsIEkgdGhpbmsg dGhpcyBpcyBhbGwgd2VsbCBhbmQgZ29vZCwgYnV0IHRoZSBpc3N1ZSBoYXMgYSBzY29wZSB0aGF0 IGlzIGJleW9uZCBORVRDT05GLjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpSZWxhdGVkIHRvIFZO RnMgaW4gcGFydGljdWxhciwgbXkgdW5kZXJzdGFuZGluZyBhcyBvZiBsYXRlIGxhc3QgeWVhciBp cyB0aGF0IGh5cGVydmlzb3JzIHN0aWxsIGxhY2tlZCBzdXBwb3J0IGZvciBTZWN1cmUgQm9vdC4g Jm5ic3A7SXQgc2VlbXMgbGlrZSB0aGlzIGRyYWZ0IG1pZ2h0IGJlIGdldHRpbmcgYWhlYWQgb2Yg d2hhdOKAmXMgcG9zc2libGUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClBTOiBJ4oCZbSBub3Qg c3Vic2NyaWJlZCB0byB0aGUgaTJuc2YgbGlzdC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KS2Vu dDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBpZD0iTUFD X09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPk5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmci Pm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBMaW5kYSBEdW5i YXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVu YmFyQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+TW9uZGF5LCBGZWJydWFyeSA4LCAyMDE2IGF0IDU6MjMgUE08YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJt YWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj5pMm5zZkBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bTmV0Y29u Zl0gV2hhdCBraW5kIG9mIG1lY2hhbmlzbXMgaGF2ZSBORVRDT05GIHNwZWNpZmllZCB0byBwcmV2 ZW50IGlsbGVnaXRpbWF0ZSZxdW90O0NsaWVudHMmcXVvdDsgb3IgJnF1b3Q7QWdlbnQmcXVvdDs/ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3 b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEy L29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5h bWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1 bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg MSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk5FVENPTkYmbmJzcDsmbmJzcDsgcGFydGljaXBhbnRzLCA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WW91ciBDaGFpciBNZWhtZXQgc3VnZ2VzdGVkIHNlbmRpbmcgdGhlIGZvbGxv d2luZyBxdWVzdGlvbnMgdG8gdGhlIGxpc3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+STJO U0YgaGFzIGEgZHJhZnQgb24gcmVtb3RlIGF0dGVzdGF0aW9uICg8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaTJuc2Ytdm5zZi1hdHRlc3RhdGlv bi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhc3Rvci1pMm5zZi12 bnNmLWF0dGVzdGF0aW9uLzwvYT4gKSB3aGljaCBkb2N1bWVudGVkIHRoZSBmb2xsb3dpbmcgc2Vj dXJpdHkNCiB0aHJlYXRzIGJldHdlZW4gQ2xpZW50IGFuZCBDb250cm9sbGVyLiBJICZuYnNwO3Ro aW5rIHRob3NlIGlzc3VlcyBhbHNvIGZhY2UgSTJSUyBhbmQgTkVUQ09ORi4gSGFzIE5FVENPTkYg c3BlY2lmaWVkIHNvbWUgbWVjaGFuaXNtcyB0byBhZGRyZXNzIHRob3NlIGlzc3Vlcz88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+ byBBbiB1bmtub3duL3VuYXV0aG9yaXplZCB1c2VyIGNhbiB0cnkgdG8gaW1wZXJzb25hdGUgYW5v dGhlciB1c2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+dGhhdCBjYW4gbGVnaXRpbWF0ZWx5 IGFjY2VzcyB2aXJ0dWFsaXplZCBOU0Ygc2VydmljZXMgKG9yIE5ldHdvcmsgU2VydmljZXMpLiBU aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+YXR0YWNrIG1heSBsZWFkIHRvIGFjY2Vzc2lu ZyB0aGUgcG9saWNpZXMgYW5kIGFwcGxpY2F0aW9ucyBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD b3VyaWVyIj5hdHRhY2tlZCB1c2VyIG9yIHRvIGdlbmVyYXRlIG5ldHdvcmsgdHJhZmZpYyBvdXRz aWRlIGEgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+c2VjdXJpdHkgZnVuY3Rpb25zIHdp dGggYSBmYWxzaWZpZWQgaWRlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+byBBbiBhdXRob3JpemVkIHVzZXIgbWF5IG1pc3Vz ZSBhc3NpZ25lZCBwcml2aWxlZ2VzIHRvIGFsdGVyIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPm5ldHdvcmsgdHJhZmZpYyBwcm9jZXNzaW5nIG9mIG90aGVyIHVzZXJzIGluIHRoZSB2aXJ0 dWFsaXphdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPnBsYXRmb3JtLiBUaGlzIGNhbiBi ZWNvbWUgZXNwZWNpYWxseSBzZXJpb3VzIHdoZW4gc3VjaCBhIHVzZXIgaGFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47 dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+YWRtaW5pc3RyYXRpb24gcHJpdmlsZWdlcyBncmFudGVkIGJ5IHRoZSB2 aXJ0dWFsaXphdGlvbiBwcm92aWRlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj50aGUgSVNQ IG9yIHRoZSBsb2NhbCBuZXR3b3JrIG9wZXJhdG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPm8gQSB1c2VyIG1heSB0cnkgdG8gaW5z dGFsbCBtYWxmb3JtZWQgZWxlbWVudHMgKHBvbGljeSBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPmFwcGxpY2F0aW9uKSwgdHJ5aW5nIHRvIGRpcmVjdGx5IHRha2UgdGhlIGNvbnRyb2wgb2Yg YSBOU0Ygb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj52aXJ0dWFsaXphdGlvbiBwbGF0Zm9y bSAoZm9yIGV4YW1wbGUgYnkgZXhwbG9pdGluZyBhIHZ1bG5lcmFiaWxpdHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyIj5vbiBvbmUgb2YgdGhlIGZ1bmN0aW9ucyBvciBtYXkgdHJ5IHRvIGludGVy Y2VwdCBvciBtb2RpZnkgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+dHJhZmZpYyBvZiBv dGhlciB1c2VycyBpbiB0aGUgc2FtZSBwbGF0Zm9ybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5vIEEgbWFsaWNpb3VzIHZpcnR1YWxp emF0aW9uIHByb3ZpZGVyIGNhbiBtb2RpZnkgdGhlIHNvZnR3YXJlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1h dXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q291cmllciI+cnVubmluZyBvbiBpdCAodGhlIG9wZXJhdGluZyBzeXN0ZW0gb3IgYSBjb25jcmV0 ZSB2TlNGKSB0byBhbHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPnRoZSBiZWhhdmlvdXIg b2YgdGhlIGxhdHRlci4gVGhpcyBldmVudCBoYXMgYSBoaWdoIGltcGFjdCBvbiBhbGw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb3VyaWVyIj51c2VycyBhY2Nlc3Npbmcgdk5TRnMgYXMgdGhlIHZpcnR1YWxp emF0aW9uIHByb3ZpZGVyIGhhcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5oaWdoZXN0 IGxldmVsIG9mIHByaXZpbGVnZSBvbiB0aGUgc29mdHdhcmUgaW4gZXhlY3V0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPm8gQSB1 c2VyIHdpdGggcGh5c2ljYWwgYWNjZXNzIHRvIHRoZSB2aXJ0dWFsaXphdGlvbiBwbGF0Zm9ybSBj YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5tb2RpZnkgdGhlIGJlaGF2aW9yIG9mIGhhcmR3 YXJlIGNvbXBvbmVudHMsIG9yIHRoZSBjb21wb25lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll ciI+dGhlbXNlbHZlcy4gRnVydGhlcm1vcmUsIGl0IGNhbiBhY2Nlc3MgYSBzZXJpYWwgY29uc29s ZSAobW9zdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmRldmljZXMgb2ZmZXIgdGhpcyBpbnRl cmZhY2UgZm9yIG1haW50ZW5hbmNlIHJlYXNvbnMpIHRvIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQt YXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXIiPnRoZSBOU0Ygc29mdHdhcmUgd2l0aCB0aGUgc2FtZSBsZXZlbCBvZiBwcml2aWxl Z2Ugb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXIiPnZpcnR1YWxpemF0aW9uIHByb3ZpZGVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoYW5rcywgTGluZGEgPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ACD729F5A4F644069F52C7ED697B3623junipernet_-- From nobody Wed Feb 17 08:30:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9F1A6EE6; Wed, 17 Feb 2016 08:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4JyvTq6pypO; Wed, 17 Feb 2016 08:30:45 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F36C1A90AC; Wed, 17 Feb 2016 08:30:45 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id gc3so21613598obb.3; Wed, 17 Feb 2016 08:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ifv75VO/L3+EXwInzkoLThhx5NiFYcPgQoIjKj6lI74=; b=z7zcP0CsVF4Azm6YY6T5CxYbYt8rDw9wpBUENtc4uxcrtkDKQ7hvu9hXQf2HjkpRiJ u1fsKxSZGwarSHdNjz5WCSxZIV9I/4Z1C3feiyzD/vxtdbJybw+753+i8Nmje3y6V1Fi g1mIRGmHvEUI3jYKCjOsbVs2CLaGylwwtm3ZSYW/bJIBHWNaYF5TUwAusaOPKwqFG0Ak bjY3XSimZvI7aBotouFoU5yDgH59g3zVK4hPIlK7JIU3cU8KgW7Zl8wOjq7v40fx6cwN WggeuFDDMstRJwFVHajg8KpzjApaDIhmJRYddoeruiXQiydozbFYSBjq/1U5GqSBqcZ/ RUEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ifv75VO/L3+EXwInzkoLThhx5NiFYcPgQoIjKj6lI74=; b=OQZGUklQneRY2WfIzqFZUUiXoq43OW8hVpcL6BLAJPhKlkFRe1fabnjxQtvhMF3Icv gsvk0sv6yfhMKIaEjZOiG7UnTIb7qVlWuAy5f1MTBExGHAN3xtydVYGKI+q4Cqq15uuE iKG8QHgcLn0mwfbXxMlBEGglzRBzowpiTWiO1CSuagdEwXWkt2E6wP+6cvJ+/M8/AWtQ AwbItBGsvI6V1W25MUnIsoOjuv1VfcPRYl3Hifme6fNeQVaSmIsA4M34jmqEraVAI0NM V03jbdW4bzI9R2djQKHDFb0L0+B9PsfWYGjk1jtuQBAbidxjtODx9pBdKlhxhFjW74qf sqBQ== X-Gm-Message-State: AG10YOTqgoSyCP5zbfXGNlPseUgVi4Cnif0zDpRffwv5yEHLOcvRMUKgbc2pqdlVMWRFng== X-Received: by 10.202.195.209 with SMTP id t200mr1931887oif.26.1455726644520; Wed, 17 Feb 2016 08:30:44 -0800 (PST) Received: from ?IPv6:2602:306:cf77:df90:d0:64b8:65b8:c43d? ([2602:306:cf77:df90:d0:64b8:65b8:c43d]) by smtp.gmail.com with ESMTPSA id cc2sm1006004obb.25.2016.02.17.08.30.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 08:30:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> Date: Wed, 17 Feb 2016 08:30:41 -0800 Message-Id: <35E9544A-65E8-4D4D-8D65-942801A9F3E5@gmail.com> References: <6797F80B-67C5-45B8-AFE9-82813E03B099@gmail.com> To: NETCONF X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Tom Yu , NETMOD Working Group Subject: Re: [Netconf] YANG library draft. WG check of last call edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:30:48 -0000 --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The review period for changes made to the draft is now closed. There are two issues that are open on GitHub that need addressing. The = authors are waiting on a response on how to address the secdir review = comments, and will work on addressing the second issue raised by Lada. Other than that, idnits has revealed this issue, although it is not = clear why. I see that in terminology section (1.1), the recommended = boiler plate statements exist for RFC 2119. Miscellaneous warnings: = --------------------------------------------------------------------------= -- =3D=3D The document seems to lack the recommended RFC 2119 = boilerplate, even if it appears to use RFC 2119 keywords.=20 RFC 2119, paragraph 2: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). It also complains about this, which is not clear to me. tmp/draft-ietf-netconf-yang-library-04.txt(201): Line has weird spacing: = '...-set-id str...' tmp/draft-ietf-netconf-yang-library-04.txt(210): Line has weird spacing: = '...evision uni...' tmp/draft-ietf-netconf-yang-library-04.txt(215): Line has weird spacing: = '...evision uni...' Once the authors have received a response from secdir, and post an = updated draft (as need to address the other open issue), I will check = the diffs, finish my writeup and send the document to Benoit. Thanks > On Feb 4, 2016, at 11:09 AM, Mahesh Jethanandani = wrote: >=20 > The yang-library draft went through a Last Call that ended January 22. = Martin has taken the suggestions from the last call comments and posted = an updated draft. >=20 > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-04 = >=20 > Please review it for the changes made to the draft and any edits that = were either missed or are not right. This would not be a time to bring = in new changes or comments. >=20 > The comment/review period will go till Monday, February 15, at which = time it will be sent to our fearless AD, Benoit Claise for publication. >=20 > Cheers. >=20 --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The review period for changes made to the draft is now = closed.

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

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

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

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

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

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

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

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

Thanks






= --Apple-Mail=_0117C591-412B-4C0C-8E20-7B494D94F91C-- From nobody Wed Feb 17 10:02:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2367B1B2AAD for ; Wed, 17 Feb 2016 10:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmEihvxon6gg for ; Wed, 17 Feb 2016 10:02:54 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771441B2AAE for ; Wed, 17 Feb 2016 10:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4181; q=dns/txt; s=iport; t=1455732174; x=1456941774; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8SPvW0H74ftS58jqKFR9kbgRd+5wSw/5VAtVSOKbWBc=; b=ZYKHLBJS7YFnqQbCoi4CSebrLzrJgEl/DmhcWTgzemRrtfKx8G9Vf0tQ Gm6Bi5ro02s6MbOeyVujtUZwop8c1WCDxUG3Axm5+QzVssRs2ZWLBFAYW rh3PE0wmzEZawI7qu1yL9WTlFklr+6i5ag00H0a5q3A8ecyVuEMfuSCqk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBAAYtcRW/xbLJq1ehAxtvBEdhXACg?= =?us-ascii?q?hcBAQEBAQFlJ4RCAQEEOEABEAsYCRYPCQMCAQIBRQYNCAEBiBYOu0wBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARmGEoQ7g3qEdQEEjSqJWoVTiAaBXEqGeyOFL45HYoNjPC6IY?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,461,1449532800"; d="scan'208";a="625525216" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 18:02:52 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1HI2pbF003927; Wed, 17 Feb 2016 18:02:52 GMT To: Netconf References: From: Robert Wilton Message-ID: <56C4B5CC.2090908@cisco.com> Date: Wed, 17 Feb 2016 18:02:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] LL review of restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:02:57 -0000 To add to Lada's comment below: " **** Sec. 3.5 - first paragraph: leaf-list entries aren't data resources? And shouldn't it in fact be "Every instance of a container, ..."? " It was unclear to me in section 3.5.1 whether the data resource identifier list encoding applies only to YANG lists, or to leaf-lists as well. In particular, it wasn't clear to me how the "point" query parameter is to be encoded for insert before/after in leaf-lists. Thanks, Rob On 11/01/2016 10:35, Ladislav Lhotka wrote: > Hi, > > I have read the document and my comments are below. Overall, I think the > document is in a good shape, and I support its publication. My company > is working on an open-source implementation. > > Lada > > *** General comments > > - RESTCONF separates the specification of the target node (in > Request-URI) from new data (in the message body). This allows > for a more flexible handling of lists and their entries, but I > am not sure whether the following operations are permitted: > 1. DELETE an entire list by specifying it as the target > resource; > 2. GET all list entries; > 3. create multiple list entries in one operation; > 4. change a list key (e.g. via PATCH), for example: > > PATCH /restconf/data/example-jukebox:jukebox/ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > If-Match: b8389233a4c > Content-Type: application/yang.data+xml > > > Something Else > > > *** Specific comments > > **** Sec. 1 > - s/operational data/state data/ (also in several other places in > the text). > - JSON reference should be RFC 7159, 7158 is obsoleted by it. > **** Sec. 1.2 > - HATEOAS acronym should be expanded at the first occurence > **** Sec. 3.3.1 > - shouldn't the example have as the document element? > **** Sec. 3.5 > - first paragraph: leaf-list entries aren't data resources? And > shouldn't it in fact be "Every instance of a container, ..."? > **** Sec. 3.5.1 > - 6th bullet: how can a key be missing? > **** Sec. 3.6 > - last two paragraphs: what does "successfully invoked" mean? > **** Sec. 3.7 > - It is a bit weird that the response has date "25 Apr 2012", but > the returned revision is "2015-06-04". > **** Sec. 4 > - table: POST also corresponds to invoking an operation > **** Sec. 4.4.1 > - second paragraph: s/YANG definition/"ietf-restconf" module/ > **** Sec. 4.5 > - What happens if the list key specified in the Request-URI isn't > the same as the key specified in the message body? > **** Sec. 4.8.1 > - I don't understand what the default is: does "requested data > nodes" mean the target resource? I would expect "all" to be the > default. > **** Sec. 4.8.2 > - I don't understand how "depth" interacts with "fields": if > "album" is the target resource, what is returned with > "depth=1&fields=genre;year"? > **** Sec. 4.8.3 > - Is this legal: "fields=jukebox(library/artist;playlist)/name"? > **** Sec. 5.3 (also in 7.1) > - "Response output content encoding format is identified with the > Accept header in the request. If is not specified, the request > input encoding format is used." This deviates from the > semantics of HTTP Accept header. RFC 7231: "A request without > any Accept header field implies that the user agent will accept > any media type in response." > **** Sec. 6.4 > - example-mod should have "prefix" statement > > *** Typos etc. > - sec. 2.5, last paragraph: s/For when/When/ > - sec. 4: The table is numbered (Table 1), other tables in the > document aren't > - the titles of sections 4.8.7-9 contain non-breaking hyphen > (U+2011) which is not rendered in the table of contents > From nobody Wed Feb 17 10:11:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070541AD375 for ; Wed, 17 Feb 2016 10:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCajAveqCVXX for ; Wed, 17 Feb 2016 10:11:51 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 35E691A86FC for ; Wed, 17 Feb 2016 10:11:51 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id x1so14388413lbj.3 for ; Wed, 17 Feb 2016 10:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PW74zajL2ZaCpD1ERDakMWhxpBaNbhYhPOnqZZqsnok=; b=slQvdxkJEVVK5bvfSYtbl656inWplHpHNZdjs7jt+Rbr2rQBES6fND/k/ze/88xRrO VcCYdOUlKRd70lO2V8ac3RbVDw0h3p+0N5Z347aSeaq4r380O8Hu/0ymWknwIRmPtaKG AAL0xe9MRI7ftmWCJAOVaFSq1kN6jD07Y3CseE12aQsLgbxhddxxBrW9Mc36LQfmhWPr SJdoUQzw88vFfPRdSYz4bz30W/NVUQuOT5N3UA3kg5eKvYm+na+gBbZXD0VAdZtG1MPP flPJJrZO7lbji8LCuQyTEiA5z8aAsK4o/GPf0aE+BgMhjuij8jjaJFIalJf7lohheEmQ 4WyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PW74zajL2ZaCpD1ERDakMWhxpBaNbhYhPOnqZZqsnok=; b=AI6eNLZSMb4IzyUo+6VYglC68wxJ4juw23wzRF8OHvVpDrXq7H+Baj1jWnNo2pz6Lm E5DdwVVkP4iIK8JEzwzGxVlyIj8emSBpy149RtRVXJPrQC11lRCvBtzZfSToyFbYe/fU eKqcaTJL5UkxjcFstlpDLLao4oc6ij+FFx5DdF7qnUbb+pKUeJvxKgO912/fW3ysKeKI SwPTHd1yvxi173ewznQC7k71dUpjJfK38K0ceR7a/GjhJMVUoP1gEjuZ0l5W4AkZq3GZ rUFI20u/QqKg3uNtROK+W99LoRvGzUXxFRr2RLqi7SLgZwq7BgvGBBa0hEaaiT5ZH+yj PXDw== X-Gm-Message-State: AG10YORDIO0S7JgZEC7ajzZq99T9EAVZEckGaGa8sYKyFaMM+/mUmmZ6X3vizCw0G9sMfJfH+382DgZiDey4Kg== MIME-Version: 1.0 X-Received: by 10.112.161.131 with SMTP id xs3mr1388631lbb.65.1455732709464; Wed, 17 Feb 2016 10:11:49 -0800 (PST) Received: by 10.112.110.68 with HTTP; Wed, 17 Feb 2016 10:11:49 -0800 (PST) In-Reply-To: <56C4B5CC.2090908@cisco.com> References: <56C4B5CC.2090908@cisco.com> Date: Wed, 17 Feb 2016 10:11:49 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c31f52092aa0052bfb2fcb Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:11:54 -0000 --001a11c31f52092aa0052bfb2fcb Content-Type: text/plain; charset=UTF-8 Hi, This will be clarified in draft-10. A leaf-list instance is a resource. It is identified by its value. /restconf/data/leaf-list=test1 Andy On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton wrote: > To add to Lada's comment below: > " > > **** Sec. 3.5 > - first paragraph: leaf-list entries aren't data resources? And > shouldn't it in fact be "Every instance of a container, ..."? > > " > It was unclear to me in section 3.5.1 whether the data resource identifier > list encoding applies only to YANG lists, or to leaf-lists as well. > > In particular, it wasn't clear to me how the "point" query parameter is to > be encoded for insert before/after in leaf-lists. > > Thanks, > Rob > > > On 11/01/2016 10:35, Ladislav Lhotka wrote: > >> Hi, >> >> I have read the document and my comments are below. Overall, I think the >> document is in a good shape, and I support its publication. My company >> is working on an open-source implementation. >> >> Lada >> >> *** General comments >> >> - RESTCONF separates the specification of the target node (in >> Request-URI) from new data (in the message body). This allows >> for a more flexible handling of lists and their entries, but I >> am not sure whether the following operations are permitted: >> 1. DELETE an entire list by specifying it as the target >> resource; >> 2. GET all list entries; >> 3. create multiple list entries in one operation; >> 4. change a list key (e.g. via PATCH), for example: >> >> PATCH /restconf/data/example-jukebox:jukebox/ >> library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 >> Host: example.com >> If-Match: b8389233a4c >> Content-Type: application/yang.data+xml >> >> >> Something Else >> >> >> *** Specific comments >> >> **** Sec. 1 >> - s/operational data/state data/ (also in several other places in >> the text). >> - JSON reference should be RFC 7159, 7158 is obsoleted by it. >> **** Sec. 1.2 >> - HATEOAS acronym should be expanded at the first occurence >> **** Sec. 3.3.1 >> - shouldn't the example have as the document element? >> **** Sec. 3.5 >> - first paragraph: leaf-list entries aren't data resources? And >> shouldn't it in fact be "Every instance of a container, ..."? >> **** Sec. 3.5.1 >> - 6th bullet: how can a key be missing? >> **** Sec. 3.6 >> - last two paragraphs: what does "successfully invoked" mean? >> **** Sec. 3.7 >> - It is a bit weird that the response has date "25 Apr 2012", but >> the returned revision is "2015-06-04". >> **** Sec. 4 >> - table: POST also corresponds to invoking an operation >> **** Sec. 4.4.1 >> - second paragraph: s/YANG definition/"ietf-restconf" module/ >> **** Sec. 4.5 >> - What happens if the list key specified in the Request-URI isn't >> the same as the key specified in the message body? >> **** Sec. 4.8.1 >> - I don't understand what the default is: does "requested data >> nodes" mean the target resource? I would expect "all" to be the >> default. >> **** Sec. 4.8.2 >> - I don't understand how "depth" interacts with "fields": if >> "album" is the target resource, what is returned with >> "depth=1&fields=genre;year"? >> **** Sec. 4.8.3 >> - Is this legal: "fields=jukebox(library/artist;playlist)/name"? >> **** Sec. 5.3 (also in 7.1) >> - "Response output content encoding format is identified with the >> Accept header in the request. If is not specified, the request >> input encoding format is used." This deviates from the >> semantics of HTTP Accept header. RFC 7231: "A request without >> any Accept header field implies that the user agent will accept >> any media type in response." >> **** Sec. 6.4 >> - example-mod should have "prefix" statement >> >> *** Typos etc. >> - sec. 2.5, last paragraph: s/For when/When/ >> - sec. 4: The table is numbered (Table 1), other tables in the >> document aren't >> - the titles of sections 4.8.7-9 contain non-breaking hyphen >> (U+2011) which is not rendered in the table of contents >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c31f52092aa0052bfb2fcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This will be clarified in draft-10.= A leaf-list instance is a resource.
It is identified by its valu= e.

=C2=A0 =C2=A0/restconf/data/leaf-list=3Dtest1


Andy




On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton &= lt;rwilton@cisco.com= > wrote:
To add to Lada'= ;s comment below:
"

**** Sec. 3.5
=C2=A0 =C2=A0 =C2=A0- first paragraph: leaf-list entries aren't data re= sources? And
=C2=A0 =C2=A0 =C2=A0 =C2=A0shouldn't it in fact be "Every instance= of a container, ..."?

"
It was unclear to me in section 3.5.1 whether the data resource identifier = list encoding applies only to YANG lists, or to leaf-lists as well.

In particular, it wasn't clear to me how the "point" query pa= rameter is to be encoded for insert before/after in leaf-lists.

Thanks,
Rob


On 11/01/2016 10:35, Ladislav Lhotka wrote:
Hi,

I have read the document and my comments are below. Overall, I think the document is in a good shape, and I support its publication. My company
is working on an open-source implementation.

Lada

*** General comments

=C2=A0 =C2=A0 =C2=A0- RESTCONF separates the specification of the target no= de (in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Request-URI) from new data (in the message body)= . This allows
=C2=A0 =C2=A0 =C2=A0 =C2=A0for a more flexible handling of lists and their = entries, but I
=C2=A0 =C2=A0 =C2=A0 =C2=A0am not sure whether the following operations are= permitted:
=C2=A0 =C2=A0 =C2=A0 =C2=A01. DELETE an entire list by specifying it as the= target
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resource;
=C2=A0 =C2=A0 =C2=A0 =C2=A02. GET all list entries;
=C2=A0 =C2=A0 =C2=A0 =C2=A03. create multiple list entries in one operation= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A04. change a list key (e.g. via PATCH), for examp= le:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PATCH /restconf/data/example-jukebox:juk= ebox/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library/artist=3DFoo%20Fig= hters/album=3DWasting%20Light HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If-Match: b8389233a4c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+xml<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <album xmlns=3D"http= ://example.com/ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>Something Else</nam= e>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </album>

*** Specific comments

**** Sec. 1
=C2=A0 =C2=A0 =C2=A0 - s/operational data/state data/ (also in several othe= r places in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the text).
=C2=A0 =C2=A0 =C2=A0 - JSON reference should be RFC 7159, 7158 is obsoleted= by it.
**** Sec. 1.2
=C2=A0 =C2=A0 =C2=A0 - HATEOAS acronym should be expanded at the first occu= rence
**** Sec. 3.3.1
=C2=A0 =C2=A0 =C2=A0 - shouldn't the example have <jukebox> as th= e document element?
**** Sec. 3.5
=C2=A0 =C2=A0 =C2=A0 - first paragraph: leaf-list entries aren't data r= esources? And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 shouldn't it in fact be "Every instanc= e of a container, ..."?
**** Sec. 3.5.1
=C2=A0 =C2=A0 =C2=A0 - 6th bullet: how can a key be missing?
**** Sec. 3.6
=C2=A0 =C2=A0 =C2=A0 - last two paragraphs: what does "successfully in= voked" mean?
**** Sec. 3.7
=C2=A0 =C2=A0 =C2=A0 - It is a bit weird that the response has date "2= 5 Apr 2012", but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the returned revision is "2015-06-04"= .
**** Sec. 4
=C2=A0 =C2=A0 =C2=A0 - table: POST also corresponds to invoking an operatio= n
**** Sec. 4.4.1
=C2=A0 =C2=A0 =C2=A0 - second paragraph: s/YANG definition/"ietf-restc= onf" module/
**** Sec. 4.5
=C2=A0 =C2=A0 =C2=A0 - What happens if the list key specified in the Reques= t-URI isn't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same as the key specified in the message bo= dy?
**** Sec. 4.8.1
=C2=A0 =C2=A0 =C2=A0 - I don't understand what the default is: does &qu= ot;requested data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nodes" mean the target resource? I would e= xpect "all" to be the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 default.
**** Sec. 4.8.2
=C2=A0 =C2=A0 =C2=A0 - I don't understand how "depth" interac= ts with "fields": if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "album" is the target resource, what = is returned with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "depth=3D1&fields=3Dgenre;year"?<= br> **** Sec. 4.8.3
=C2=A0 =C2=A0 =C2=A0 - Is this legal: "fields=3Djukebox(library/artist= ;playlist)/name"?
**** Sec. 5.3 (also in 7.1)
=C2=A0 =C2=A0 =C2=A0 - "Response output content encoding format is ide= ntified with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Accept header in the request.=C2=A0 If is not s= pecified, the request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 input encoding format is used." This devia= tes from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics of HTTP Accept header. RFC 7231: &quo= t;A request without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any Accept header field implies that the user a= gent will accept
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any media type in response."
**** Sec. 6.4
=C2=A0 =C2=A0 =C2=A0 - example-mod should have "prefix" statement=

*** Typos etc.
=C2=A0 =C2=A0 =C2=A0- sec. 2.5, last paragraph: s/For when/When/
=C2=A0 =C2=A0 =C2=A0- sec. 4: The table is numbered (Table 1), other tables= in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0document aren't
=C2=A0 =C2=A0 =C2=A0- the titles of sections 4.8.7-9 contain non-breaking h= yphen
=C2=A0 =C2=A0 =C2=A0 =C2=A0(U+2011) which is not rendered in the table of c= ontents


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

--001a11c31f52092aa0052bfb2fcb-- From nobody Thu Feb 18 00:55:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E6D1B3B9D for ; Thu, 18 Feb 2016 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8NFqNIbv5l2 for ; Thu, 18 Feb 2016 00:55:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778741B3B9A for ; Thu, 18 Feb 2016 00:55:40 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:7579:b54e:8f91:5cba] (unknown [IPv6:2001:718:1a02:1:7579:b54e:8f91:5cba]) by mail.nic.cz (Postfix) with ESMTPSA id 871D2181C04 for ; Thu, 18 Feb 2016 09:55:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1455785738; bh=EkKTuTR6DCxIbhW6rukimN/4OcyI8yh2pEzGM/RBWhc=; h=To:From:Date; b=XQJ6KOr3raNQlLF68AR/9wBME5e1AlT5INw/E3xE71HS0oshhwlmrEmN05LQf7HDu fPwoy1EPTZTiVSMun8tsHr5dWN1b4qqvzVeJPlflaAvn0hweFwgBjr9k+n2VbzE1fm cl9xxck9cFvYwy852FYtfDwbxGrtRo2bd+6em+Nk= To: netconf@ietf.org From: =?UTF-8?B?UGF2ZWwgxaBww61yZWs=?= Message-ID: <56C5869C.2030207@nic.cz> Date: Thu, 18 Feb 2016 09:53:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [Netconf] Permission inheritance in NACM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 08:55:42 -0000 Hello, I am currently working on implementation of NACM for RESTCONF and I would like to ask if there is some kind of permission inheritance in Netconf Access Control Module (RFC 6536). The procedure of access validation to specific data node is described in paragraph 3.4.5. of RFC 6536. But it's not quite clear if I should also consider rules controlling access to parent data nodes. I checked implementation of NACM in libnetconf (nacm.c:1236), and it also doesn't look like that parent nodes are processed there (or I am missing something)... Thanks, Pavel Spirek From nobody Thu Feb 18 01:52:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120161B3B4B for ; Thu, 18 Feb 2016 01:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-aLOg1YoXlK for ; Thu, 18 Feb 2016 01:52:40 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615F21B3759 for ; Thu, 18 Feb 2016 01:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15735; q=dns/txt; s=iport; t=1455789159; x=1456998759; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Eg1B0o/fdUx/djpcUpHthhIdKWnady5mx6oHD2LWmHc=; b=M+Cy3S2PtwcshJksD4beycAFFNQrtVDjs6nux87DEQ7iypEzqQ4RENg9 Ik4qH9oUavkz7zOMrGD5xjWsSZa8h1wRMd0wdW5cyqCM7RGWPscz4JS0y T8ojUUDuShzDw//PMQ0kJELpIHsDy30ANsboYjy+gkN/m+PDxzYOChVmi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBABYk8VW/xbLJq1ehAxtvBMXAQmFI?= =?us-ascii?q?koCgisBAQEBAQFlJ4RCAQEEAQEBIEsKARAJAhgJFggDAgIJAwIBAgEVHxEGDQY?= =?us-ascii?q?CAQGIFg6PTp0TjngBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKEO4N6gzuBOgWNK?= =?us-ascii?q?oVJhBKFVIgGgVxKhnsjhS+OR2KDYzwuiR8BAQE?= X-IronPort-AV: E=Sophos;i="5.22,464,1449532800"; d="scan'208,217";a="625541688" 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; 18 Feb 2016 09:52:36 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1I9qaXu021582; Thu, 18 Feb 2016 09:52:36 GMT To: Andy Bierman References: <56C4B5CC.2090908@cisco.com> From: Robert Wilton Message-ID: <56C59463.6050506@cisco.com> Date: Thu, 18 Feb 2016 09:52:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090305080600070801040608" Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 09:52:43 -0000 This is a multi-part message in MIME format. --------------090305080600070801040608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Thanks for the clarification. I have one further question based on your answer: Given that a leaf-list instance is a resource, am I correct in presuming that sections 3.4.1.1/3.4.1.2 (Timestamp/Entity tag) imply that each instance in a leaf-list "SHOULD" have its own timestamp and entity tag? Thanks, Rob On 17/02/2016 18:11, Andy Bierman wrote: > Hi, > > This will be clarified in draft-10. A leaf-list instance is a resource. > It is identified by its value. > > /restconf/data/leaf-list=test1 > > > Andy > > > > > On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton > wrote: > > To add to Lada's comment below: > " > > **** Sec. 3.5 > - first paragraph: leaf-list entries aren't data resources? And > shouldn't it in fact be "Every instance of a container, ..."? > > " > It was unclear to me in section 3.5.1 whether the data resource > identifier list encoding applies only to YANG lists, or to > leaf-lists as well. > > In particular, it wasn't clear to me how the "point" query > parameter is to be encoded for insert before/after in leaf-lists. > > Thanks, > Rob > > > On 11/01/2016 10:35, Ladislav Lhotka wrote: > > Hi, > > I have read the document and my comments are below. Overall, I > think the > document is in a good shape, and I support its publication. My > company > is working on an open-source implementation. > > Lada > > *** General comments > > - RESTCONF separates the specification of the target node (in > Request-URI) from new data (in the message body). This > allows > for a more flexible handling of lists and their > entries, but I > am not sure whether the following operations are permitted: > 1. DELETE an entire list by specifying it as the target > resource; > 2. GET all list entries; > 3. create multiple list entries in one operation; > 4. change a list key (e.g. via PATCH), for example: > > PATCH /restconf/data/example-jukebox:jukebox/ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > If-Match: b8389233a4c > Content-Type: application/yang.data+xml > > > Something Else > > > *** Specific comments > > **** Sec. 1 > - s/operational data/state data/ (also in several other > places in > the text). > - JSON reference should be RFC 7159, 7158 is obsoleted > by it. > **** Sec. 1.2 > - HATEOAS acronym should be expanded at the first occurence > **** Sec. 3.3.1 > - shouldn't the example have as the document > element? > **** Sec. 3.5 > - first paragraph: leaf-list entries aren't data > resources? And > shouldn't it in fact be "Every instance of a > container, ..."? > **** Sec. 3.5.1 > - 6th bullet: how can a key be missing? > **** Sec. 3.6 > - last two paragraphs: what does "successfully invoked" > mean? > **** Sec. 3.7 > - It is a bit weird that the response has date "25 Apr > 2012", but > the returned revision is "2015-06-04". > **** Sec. 4 > - table: POST also corresponds to invoking an operation > **** Sec. 4.4.1 > - second paragraph: s/YANG definition/"ietf-restconf" > module/ > **** Sec. 4.5 > - What happens if the list key specified in the > Request-URI isn't > the same as the key specified in the message body? > **** Sec. 4.8.1 > - I don't understand what the default is: does > "requested data > nodes" mean the target resource? I would expect "all" > to be the > default. > **** Sec. 4.8.2 > - I don't understand how "depth" interacts with "fields": if > "album" is the target resource, what is returned with > "depth=1&fields=genre;year"? > **** Sec. 4.8.3 > - Is this legal: > "fields=jukebox(library/artist;playlist)/name"? > **** Sec. 5.3 (also in 7.1) > - "Response output content encoding format is identified > with the > Accept header in the request. If is not specified, > the request > input encoding format is used." This deviates from the > semantics of HTTP Accept header. RFC 7231: "A request > without > any Accept header field implies that the user agent > will accept > any media type in response." > **** Sec. 6.4 > - example-mod should have "prefix" statement > > *** Typos etc. > - sec. 2.5, last paragraph: s/For when/When/ > - sec. 4: The table is numbered (Table 1), other tables > in the > document aren't > - the titles of sections 4.8.7-9 contain non-breaking hyphen > (U+2011) which is not rendered in the table of contents > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --------------090305080600070801040608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

Thanks for the clarification.

I have one further question based on your answer:

Given that a leaf-list instance is a resource, am I correct in presuming that sections 3.4.1.1/3.4.1.2 (Timestamp/Entity tag) imply that each instance in a leaf-list "SHOULD" have its own timestamp and entity tag?

Thanks,
Rob


On 17/02/2016 18:11, Andy Bierman wrote:
Hi,

This will be clarified in draft-10. A leaf-list instance is a resource.
It is identified by its value.

   /restconf/data/leaf-list=test1


Andy




On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton <rwilton@cisco.com> wrote:
To add to Lada's comment below:
"

**** Sec. 3.5
     - first paragraph: leaf-list entries aren't data resources? And
       shouldn't it in fact be "Every instance of a container, ..."?

"
It was unclear to me in section 3.5.1 whether the data resource identifier list encoding applies only to YANG lists, or to leaf-lists as well.

In particular, it wasn't clear to me how the "point" query parameter is to be encoded for insert before/after in leaf-lists.

Thanks,
Rob


On 11/01/2016 10:35, Ladislav Lhotka wrote:
Hi,

I have read the document and my comments are below. Overall, I think the
document is in a good shape, and I support its publication. My company
is working on an open-source implementation.

Lada

*** General comments

     - RESTCONF separates the specification of the target node (in
       Request-URI) from new data (in the message body). This allows
       for a more flexible handling of lists and their entries, but I
       am not sure whether the following operations are permitted:
       1. DELETE an entire list by specifying it as the target
          resource;
       2. GET all list entries;
       3. create multiple list entries in one operation;
       4. change a list key (e.g. via PATCH), for example:

          PATCH /restconf/data/example-jukebox:jukebox/
              library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
          Host: example.com
          If-Match: b8389233a4c
          Content-Type: application/yang.data+xml

          <album xmlns="http://example.com/ns/example-jukebox">
           <name>Something Else</name>
          </album>

*** Specific comments

**** Sec. 1
      - s/operational data/state data/ (also in several other places in
        the text).
      - JSON reference should be RFC 7159, 7158 is obsoleted by it.
**** Sec. 1.2
      - HATEOAS acronym should be expanded at the first occurence
**** Sec. 3.3.1
      - shouldn't the example have <jukebox> as the document element?
**** Sec. 3.5
      - first paragraph: leaf-list entries aren't data resources? And
        shouldn't it in fact be "Every instance of a container, ..."?
**** Sec. 3.5.1
      - 6th bullet: how can a key be missing?
**** Sec. 3.6
      - last two paragraphs: what does "successfully invoked" mean?
**** Sec. 3.7
      - It is a bit weird that the response has date "25 Apr 2012", but
        the returned revision is "2015-06-04".
**** Sec. 4
      - table: POST also corresponds to invoking an operation
**** Sec. 4.4.1
      - second paragraph: s/YANG definition/"ietf-restconf" module/
**** Sec. 4.5
      - What happens if the list key specified in the Request-URI isn't
        the same as the key specified in the message body?
**** Sec. 4.8.1
      - I don't understand what the default is: does "requested data
        nodes" mean the target resource? I would expect "all" to be the
        default.
**** Sec. 4.8.2
      - I don't understand how "depth" interacts with "fields": if
        "album" is the target resource, what is returned with
        "depth=1&fields=genre;year"?
**** Sec. 4.8.3
      - Is this legal: "fields=jukebox(library/artist;playlist)/name"?
**** Sec. 5.3 (also in 7.1)
      - "Response output content encoding format is identified with the
        Accept header in the request.  If is not specified, the request
        input encoding format is used." This deviates from the
        semantics of HTTP Accept header. RFC 7231: "A request without
        any Accept header field implies that the user agent will accept
        any media type in response."
**** Sec. 6.4
      - example-mod should have "prefix" statement

*** Typos etc.
     - sec. 2.5, last paragraph: s/For when/When/
     - sec. 4: The table is numbered (Table 1), other tables in the
       document aren't
     - the titles of sections 4.8.7-9 contain non-breaking hyphen
       (U+2011) which is not rendered in the table of contents


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


--------------090305080600070801040608-- From nobody Thu Feb 18 09:11:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357451A8893 for ; Thu, 18 Feb 2016 09:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuVp88P1Xywy for ; Thu, 18 Feb 2016 09:11:22 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5176D1A3BA4 for ; Thu, 18 Feb 2016 09:11:22 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id 78so37046155lfy.3 for ; Thu, 18 Feb 2016 09:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VVPl25v64reUTkxh1N+gkhEl26ZKU3bZOgcnw3p3TrA=; b=B8btpSaaZ02OfFzzDtpvxrnrUdlmL/jUzZd1RHq37hpoervQTy3fQZr8wwZ0Z7o68w xFGj70VvKEmMdlRmjJhSaoR5uV4L5NN+ORvtCsbkamRrjimcPatOeMIYL63caDfgVHgS GJNfl5g3sROeocRbCth5SDAvwzCCKeV0Aq4nlHLAl6yia+oFiQc1VpOm7LF//zUS57Jg djniLcBrK+RJe8gelR1gpKOsxQhqNggFOE9+QcmTbOu9ykEitrfOHeT7BZSA8YL4WOJI 7rx688svlEPFCf4kH7MlA8iHCfddEUKyLQC1ZTCZJeG3I+binlAN+M7ZwJd5WHQofmmf hnnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VVPl25v64reUTkxh1N+gkhEl26ZKU3bZOgcnw3p3TrA=; b=ifGG5RDp42G3zCtSKDCZfuhwj2dq1nAl6NGPqfdkBFmLOOnqFLgMpZzAOfPgHDGmIP iS2cjPvSLGwyLY52XAqcE1KoxtPwE8JSbtRqWI2LS6U0ETKO80kvSYh+/jDHCBwvosU3 2eQgZVI4Q9qnEovAAqoyYpKvndgYqLYlqr43HlWW+sN1MGI4CqbEzHMCOo0hlsrA1XoO UJdnDTilgqGxY4jUD4+5i4DryCdI+50WHhCuCQoXiQYY1ff0nX1vEdWg+iZTitromCEL MaZeahCeClas7kkiUKBOwcIPKn58n7ipY12DTFsFsKjG9PjDmtDBjp1Wry/ah+38kayN v4vw== X-Gm-Message-State: AG10YORKD9SM9kxp/4zvLKxzwF/P/+2Zojg7qlcv+MDC2DgCOgmXHzAiC6yH5AZnTMaCSeBFMLg3MUFveGbuCA== MIME-Version: 1.0 X-Received: by 10.25.16.214 with SMTP id 83mr3724610lfq.13.1455815480514; Thu, 18 Feb 2016 09:11:20 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 18 Feb 2016 09:11:20 -0800 (PST) In-Reply-To: <56C59463.6050506@cisco.com> References: <56C4B5CC.2090908@cisco.com> <56C59463.6050506@cisco.com> Date: Thu, 18 Feb 2016 09:11:20 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a113fc384933867052c0e74e2 Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:11:25 -0000 --001a113fc384933867052c0e74e2 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 1:52 AM, Robert Wilton wrote: > Hi Andy, > > Thanks for the clarification. > > I have one further question based on your answer: > > Given that a leaf-list instance is a resource, am I correct in presuming > that sections 3.4.1.1/3.4.1.2 (Timestamp/Entity tag) imply that each > instance in a leaf-list "SHOULD" have its own timestamp and entity tag? > > yes > Thanks, > Rob > > Andy > > On 17/02/2016 18:11, Andy Bierman wrote: > > Hi, > > This will be clarified in draft-10. A leaf-list instance is a resource. > It is identified by its value. > > /restconf/data/leaf-list=test1 > > > Andy > > > > > On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton wrote: > >> To add to Lada's comment below: >> " >> >> **** Sec. 3.5 >> - first paragraph: leaf-list entries aren't data resources? And >> shouldn't it in fact be "Every instance of a container, ..."? >> >> " >> It was unclear to me in section 3.5.1 whether the data resource >> identifier list encoding applies only to YANG lists, or to leaf-lists as >> well. >> >> In particular, it wasn't clear to me how the "point" query parameter is >> to be encoded for insert before/after in leaf-lists. >> >> Thanks, >> Rob >> >> >> On 11/01/2016 10:35, Ladislav Lhotka wrote: >> >>> Hi, >>> >>> I have read the document and my comments are below. Overall, I think the >>> document is in a good shape, and I support its publication. My company >>> is working on an open-source implementation. >>> >>> Lada >>> >>> *** General comments >>> >>> - RESTCONF separates the specification of the target node (in >>> Request-URI) from new data (in the message body). This allows >>> for a more flexible handling of lists and their entries, but I >>> am not sure whether the following operations are permitted: >>> 1. DELETE an entire list by specifying it as the target >>> resource; >>> 2. GET all list entries; >>> 3. create multiple list entries in one operation; >>> 4. change a list key (e.g. via PATCH), for example: >>> >>> PATCH /restconf/data/example-jukebox:jukebox/ >>> library/artist=Foo%20Fighters/album=Wasting%20Light >>> HTTP/1.1 >>> Host: example.com >>> If-Match: b8389233a4c >>> Content-Type: application/yang.data+xml >>> >>> >>> Something Else >>> >>> >>> *** Specific comments >>> >>> **** Sec. 1 >>> - s/operational data/state data/ (also in several other places in >>> the text). >>> - JSON reference should be RFC 7159, 7158 is obsoleted by it. >>> **** Sec. 1.2 >>> - HATEOAS acronym should be expanded at the first occurence >>> **** Sec. 3.3.1 >>> - shouldn't the example have as the document element? >>> **** Sec. 3.5 >>> - first paragraph: leaf-list entries aren't data resources? And >>> shouldn't it in fact be "Every instance of a container, ..."? >>> **** Sec. 3.5.1 >>> - 6th bullet: how can a key be missing? >>> **** Sec. 3.6 >>> - last two paragraphs: what does "successfully invoked" mean? >>> **** Sec. 3.7 >>> - It is a bit weird that the response has date "25 Apr 2012", but >>> the returned revision is "2015-06-04". >>> **** Sec. 4 >>> - table: POST also corresponds to invoking an operation >>> **** Sec. 4.4.1 >>> - second paragraph: s/YANG definition/"ietf-restconf" module/ >>> **** Sec. 4.5 >>> - What happens if the list key specified in the Request-URI isn't >>> the same as the key specified in the message body? >>> **** Sec. 4.8.1 >>> - I don't understand what the default is: does "requested data >>> nodes" mean the target resource? I would expect "all" to be the >>> default. >>> **** Sec. 4.8.2 >>> - I don't understand how "depth" interacts with "fields": if >>> "album" is the target resource, what is returned with >>> "depth=1&fields=genre;year"? >>> **** Sec. 4.8.3 >>> - Is this legal: "fields=jukebox(library/artist;playlist)/name"? >>> **** Sec. 5.3 (also in 7.1) >>> - "Response output content encoding format is identified with the >>> Accept header in the request. If is not specified, the request >>> input encoding format is used." This deviates from the >>> semantics of HTTP Accept header. RFC 7231: "A request without >>> any Accept header field implies that the user agent will accept >>> any media type in response." >>> **** Sec. 6.4 >>> - example-mod should have "prefix" statement >>> >>> *** Typos etc. >>> - sec. 2.5, last paragraph: s/For when/When/ >>> - sec. 4: The table is numbered (Table 1), other tables in the >>> document aren't >>> - the titles of sections 4.8.7-9 contain non-breaking hyphen >>> (U+2011) which is not rendered in the table of contents >>> >>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > --001a113fc384933867052c0e74e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 18, 2016 at 1:52 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20
Hi Andy,

Thanks for the clarification.

I have one further question based on your answer:

Given that a leaf-list instance is a resource, am I correct in presuming that sections 3.4.1.1/3.4.1.2 (Timestamp/Entity tag) imply that each instance in a leaf-list "SHOULD" have its own times= tamp and entity tag?


yes
=C2=A0
Thanks,
Rob


Andy
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

On 17/02/2016 18:11, Andy Bierman wrote:
=20
Hi,

This will be clarified in draft-10. A leaf-list instance is a resource.
It is identified by its value.

=C2=A0 =C2=A0/restconf/data/leaf-list=3Dtest1


Andy




On Wed, Feb 17, 2016 at 10:02 AM, Robert Wilton <rwilton@cisco.com> wrote:
To add to Lada's comment below:
"

**** Sec. 3.5
=C2=A0 =C2=A0 =C2=A0- first paragraph: leaf-list entries aren&#= 39;t data resources? And
=C2=A0 =C2=A0 =C2=A0 =C2=A0shouldn't it in fact be "Ev= ery instance of a container, ..."?

"
It was unclear to me in section 3.5.1 whether the data resource identifier list encoding applies only to YANG lists, or to leaf-lists as well.

In particular, it wasn't clear to me how the "point&qu= ot; query parameter is to be encoded for insert before/after in leaf-lists.

Thanks,
Rob


On 11/01/2016 10:35, Ladislav Lhotka wrote:
Hi,

I have read the document and my comments are below. Overall, I think the
document is in a good shape, and I support its publication. My company
is working on an open-source implementation.

Lada

*** General comments

=C2=A0 =C2=A0 =C2=A0- RESTCONF separates the specification of= the target node (in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Request-URI) from new data (in the= message body). This allows
=C2=A0 =C2=A0 =C2=A0 =C2=A0for a more flexible handling of li= sts and their entries, but I
=C2=A0 =C2=A0 =C2=A0 =C2=A0am not sure whether the following = operations are permitted:
=C2=A0 =C2=A0 =C2=A0 =C2=A01. DELETE an entire list by specif= ying it as the target
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resource;
=C2=A0 =C2=A0 =C2=A0 =C2=A02. GET all list entries;
=C2=A0 =C2=A0 =C2=A0 =C2=A03. create multiple list entries in= one operation;
=C2=A0 =C2=A0 =C2=A0 =C2=A04. change a list key (e.g. via PAT= CH), for example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PATCH /restconf/data/examp= le-jukebox:jukebox/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If-Match: b8389233a4c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Content-Type: application/= yang.data+xml

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <album xmlns=3D"http://example.com/ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>Somethin= g Else</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </album>

*** Specific comments

**** Sec. 1
=C2=A0 =C2=A0 =C2=A0 - s/operational data/state data/ (also i= n several other places in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the text).
=C2=A0 =C2=A0 =C2=A0 - JSON reference should be RFC 7159, 715= 8 is obsoleted by it.
**** Sec. 1.2
=C2=A0 =C2=A0 =C2=A0 - HATEOAS acronym should be expanded at = the first occurence
**** Sec. 3.3.1
=C2=A0 =C2=A0 =C2=A0 - shouldn't the example have <juk= ebox> as the document element?
**** Sec. 3.5
=C2=A0 =C2=A0 =C2=A0 - first paragraph: leaf-list entries are= n't data resources? And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 shouldn't it in fact be "= ;Every instance of a container, ..."?
**** Sec. 3.5.1
=C2=A0 =C2=A0 =C2=A0 - 6th bullet: how can a key be missing?<= br> **** Sec. 3.6
=C2=A0 =C2=A0 =C2=A0 - last two paragraphs: what does "s= uccessfully invoked" mean?
**** Sec. 3.7
=C2=A0 =C2=A0 =C2=A0 - It is a bit weird that the response ha= s date "25 Apr 2012", but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the returned revision is "20= 15-06-04".
**** Sec. 4
=C2=A0 =C2=A0 =C2=A0 - table: POST also corresponds to invoki= ng an operation
**** Sec. 4.4.1
=C2=A0 =C2=A0 =C2=A0 - second paragraph: s/YANG definition/"ietf-restconf" module/
**** Sec. 4.5
=C2=A0 =C2=A0 =C2=A0 - What happens if the list key specified= in the Request-URI isn't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same as the key specified in = the message body?
**** Sec. 4.8.1
=C2=A0 =C2=A0 =C2=A0 - I don't understand what the defaul= t is: does "requested data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nodes" mean the target resou= rce? I would expect "all" to be the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 default.
**** Sec. 4.8.2
=C2=A0 =C2=A0 =C2=A0 - I don't understand how "depth= " interacts with "fields": if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "album" is the target r= esource, what is returned with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "depth=3D1&fields=3Dgenr= e;year"?
**** Sec. 4.8.3
=C2=A0 =C2=A0 =C2=A0 - Is this legal: "fields=3Djukebox(library/artist;playlist)/name"? **** Sec. 5.3 (also in 7.1)
=C2=A0 =C2=A0 =C2=A0 - "Response output content encoding= format is identified with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Accept header in the request.=C2= =A0 If is not specified, the request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 input encoding format is used.&qu= ot; This deviates from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics of HTTP Accept header. = RFC 7231: "A request without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any Accept header field implies t= hat the user agent will accept
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any media type in response."=
**** Sec. 6.4
=C2=A0 =C2=A0 =C2=A0 - example-mod should have "prefix&q= uot; statement

*** Typos etc.
=C2=A0 =C2=A0 =C2=A0- sec. 2.5, last paragraph: s/For when/Wh= en/
=C2=A0 =C2=A0 =C2=A0- sec. 4: The table is numbered (Table 1)= , other tables in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0document aren't
=C2=A0 =C2=A0 =C2=A0- the titles of sections 4.8.7-9 contain = non-breaking hyphen
=C2=A0 =C2=A0 =C2=A0 =C2=A0(U+2011) which is not rendered in = the table of contents


_______________________________________________
Netconf mailing list
Netconf@i= etf.org
https://www.ietf.org/mailman/listinfo/net= conf



--001a113fc384933867052c0e74e2-- From nobody Thu Feb 18 09:15:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C11B3128 for ; Thu, 18 Feb 2016 09:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PWNnjL92t4g for ; Thu, 18 Feb 2016 09:15:24 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB041B3118 for ; Thu, 18 Feb 2016 09:15:23 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id x1so32500107lbj.3 for ; Thu, 18 Feb 2016 09:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bK1MkHCS6P6gs9FRkww5GZbPqQsLSfBWKnaH3l6QNzg=; b=gi4szMHMVx1pfekYqBr74etb1fj74EfYKlIjvTGu6ro8i0xiDfxLdh4osMZiUH4H8t piAKix2JD57FX4GhJUXzOG2csQGoEyaLfpEjEvLY1A7iv9yaoLiNXJoC/fLDOj8S2SoB X19NRw4yABxq8N7+kkMlAaC+BcQXLO++c8nYGBTf+1DYk/7kSpxmns1BNWMZB0S/6W7h Im+m8SMHT23vkTXFnzlmx9UFMLSCNLuUcg0zAU533ynHZIxuygr/g2sfpIpw3cfYCCf7 BZhM1K5CazE9beA99CUvubo5F+uAtSOqUr6Bu+4K88S6YhQ+CwCwsMRCSTDo84+SeLR9 qDWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bK1MkHCS6P6gs9FRkww5GZbPqQsLSfBWKnaH3l6QNzg=; b=gNHAnfOQ7nVTy2x1XF6J5cAGI6XIVX+tdJCGVOHHTzm3Jpxd6xY81y070PcANiFeAA gdHoYT1wnBedttDtINH/q4Xu0XdXHKKKB63+0XLvN8nbnRbYw5xM4C6gi1evxtHDQBKq sC1pyUlq92I8RwWmta2r+j/mpEHnSw6J7c8mOOnz+hfCh7ziEao4fI/feaytc3X2be97 fQZ4goykDNt/zTzaZjR2UT6uCD7vvh/RP4jJouhexiLTB9PGfCbHcpteWZtV9JCtvCJt 7DXnLxsNgCnyWQaAUL1WdK/hWpDBWK9quWbO4hSq3J9VmMtXXZ98wq3eoF2SztHOLaIh qepg== X-Gm-Message-State: AG10YOQ83XJ/2ZAYNiBakTyga/wGwx5n94+iLe2QSIeB2PezQ6RroYU5+sm/9L41+WUVk0QYF+3tUXzpx7r3ng== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr3610831lbb.66.1455815721964; Thu, 18 Feb 2016 09:15:21 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 18 Feb 2016 09:15:21 -0800 (PST) In-Reply-To: <56C5869C.2030207@nic.cz> References: <56C5869C.2030207@nic.cz> Date: Thu, 18 Feb 2016 09:15:21 -0800 Message-ID: From: Andy Bierman To: =?UTF-8?B?UGF2ZWwgxaBww61yZWs=?= Content-Type: multipart/alternative; boundary=089e01161bf4f7762e052c0e82e2 Archived-At: Cc: Netconf Subject: Re: [Netconf] Permission inheritance in NACM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:15:25 -0000 --089e01161bf4f7762e052c0e82e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, NACM has not been updated to support RESTCONF. Eventually the NETCONF WG will produce an update and WG consensus will determine the answer to your question. My guess is that ancestor nodes of the target resource data node are treate= d the same as NETCONF where the operation=3D"none". (i.e., all ancestors nee= d to exist). Andy On Thu, Feb 18, 2016 at 12:53 AM, Pavel =C5=A0p=C3=ADrek wrote: > Hello, > I am currently working on implementation of NACM for RESTCONF and I would > like to ask if there is some kind of permission inheritance in Netconf > Access Control Module (RFC 6536). The procedure of access validation to > specific data node is described in paragraph 3.4.5. of RFC 6536. But it's > not quite clear if I should also consider rules controlling access to > parent data nodes. > > I checked implementation of NACM in libnetconf (nacm.c:1236), and it also > doesn't look like that parent nodes are processed there (or I am missing > something)... > > Thanks, > Pavel Spirek > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e01161bf4f7762e052c0e82e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

NACM has not been updated to suppor= t RESTCONF.
Eventually the NETCONF WG will produce an update and = WG consensus will
determine the answer to your question.

My guess is that ancestor nodes of the target resource dat= a node are treated
the same as NETCONF where the operation=3D&quo= t;none". =C2=A0(i.e., all ancestors need
to exist).


Andy


On Thu, Feb 18, 2016 at 12:53 AM, Pavel = =C5=A0p=C3=ADrek <pavel.spirek@nic.cz> wrote:
Hello,
I am currently working on implementation of NACM for RESTCONF and I would l= ike to ask if there is some kind of permission inheritance in Netconf Acces= s Control Module (RFC 6536). The procedure of access validation to specific= data node is described in paragraph 3.4.5. of RFC 6536. But it's not q= uite clear if I should also consider rules controlling access to parent dat= a nodes.

I checked implementation of NACM in libnetconf (nacm.c:1236), and it also d= oesn't look like that parent nodes are processed there (or I am missing= something)...

Thanks,
Pavel Spirek

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

--089e01161bf4f7762e052c0e82e2-- From nobody Thu Feb 18 10:10:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4B41B315E for ; Thu, 18 Feb 2016 10:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsThHCfJVnnW for ; Thu, 18 Feb 2016 10:10:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BDF1B3162 for ; Thu, 18 Feb 2016 10:10:06 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:5154:b3a0:9e5c:3d98] (unknown [IPv6:2a01:5e0:29:ffff:5154:b3a0:9e5c:3d98]) by mail.nic.cz (Postfix) with ESMTPSA id 641C2180D6E; Thu, 18 Feb 2016 19:10:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1455819004; bh=KbGFQS1jUiX093g4/4ivNEoKMLxUwiqP130NQedDXyE=; h=From:Date:To; b=xCH3APwLfYjTRJ6VoLco4EtHIpsVGz3lNo6YaMGW986wu17vxdrll/Gdwme6y+OLN KO2Nqvx0KCzaG95hgqx5kFSNKB7tEnjFv/PtAmr6gt9as8WVzOsEzNfLjehhr0m/6i hfPxi2f5HP5hGXyXJmd0N1Y7tdNuu9x9u9K7XL20= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 18 Feb 2016 19:10:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4536B87D-6935-49A7-B472-8D6AE3A21E7A@nic.cz> References: <56C5869C.2030207@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] Permission inheritance in NACM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:10:08 -0000 > On 18 Feb 2016, at 18:15, Andy Bierman wrote: >=20 > Hi, >=20 > NACM has not been updated to support RESTCONF. > Eventually the NETCONF WG will produce an update and WG consensus will > determine the answer to your question. >=20 > My guess is that ancestor nodes of the target resource data node are = treated > the same as NETCONF where the operation=3D"none". (i.e., all = ancestors need > to exist). How does it work in NETCONF? Is it possible for a client to have read = access to a leaf if it doesn't have read access to an ancestor = container? In terms of RFC 6536, does "path" match mean an exact match or prefix = match? Lada=20 >=20 >=20 > Andy >=20 >=20 > On Thu, Feb 18, 2016 at 12:53 AM, Pavel =C5=A0p=C3=ADrek = wrote: > Hello, > I am currently working on implementation of NACM for RESTCONF and I = would like to ask if there is some kind of permission inheritance in = Netconf Access Control Module (RFC 6536). The procedure of access = validation to specific data node is described in paragraph 3.4.5. of RFC = 6536. But it's not quite clear if I should also consider rules = controlling access to parent data nodes. >=20 > I checked implementation of NACM in libnetconf (nacm.c:1236), and it = also doesn't look like that parent nodes are processed there (or I am = missing something)... >=20 > Thanks, > Pavel Spirek >=20 > _______________________________________________ > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 18 10:28:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169481B30AD for ; Thu, 18 Feb 2016 10:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29d0_V0HCCnT for ; Thu, 18 Feb 2016 10:28:56 -0800 (PST) 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 BDA751B3082 for ; Thu, 18 Feb 2016 10:28:55 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id j78so38554715lfb.1 for ; Thu, 18 Feb 2016 10:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j2xjgV4ZHKn6LrsYam4mtkb9/nk25i6Ya1DZo7VyrGs=; b=xe9LMqD4LPwK/AQjjn+UjkfsRuH29HEsGWJUTqaJljxv2QixQNOBX9r/qoxrQWGMb/ SH1z1glDkH+DLt4jRmJsp6sAqmmyGzr1Z4CvWpNrMG2fJrH50VlTiEM+pQb1ByMlpLiR 99bB7QLDNNm0mIviC5Xm5vrimnDAgUPD/LNevPXec21/OOMYq3S7CWMeZ3Xly8bWaPt7 A7yjUT9g8jOzJgSZIBhtew2a/pnKsB5XDiVZX0cZ0hy+vIofMrcRZhudEPYGl6Zc9coy dLHVr6GP/iUpHqqi2DoQroiV9C/ShfCQbQ0J/dkaP4gksD4fZTcUNQtdk8W6WZ1U/Jqu eRvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j2xjgV4ZHKn6LrsYam4mtkb9/nk25i6Ya1DZo7VyrGs=; b=PyVCJo8kiobGVlpzpOiWJztvu3LhAcaik+x2IH4RWZLgONXf/HOQKNJlVu3hXRG7Nf PwYqEetNZYGRYJs7RC3njKZvzccEXn+Bu5kxpBqSQT1U67aHKMITuOfXLhT3EyuBbdcz c1DefNS1jvbaPLX+yuwmfxou+mgWrQ5p5whFFriPXhuAgTJLDpeZDFWsowmS15gZH3Mw yMewqJPw7bvWLBmxeeB6mZwxsPzbc4rIvi6/9yvVkN83Q+dCi2nkl0BkRznR10PaOBeg vSwz4KA9Xi5bNRsyqqPT+r3FiwOexIWTbIyw8Cd+wYMEEiInhHFXyzQjI0y+hRN9BoSy WBdw== X-Gm-Message-State: AG10YOSXTtbJGpaXmpAmXfFURRE17+cRjouGTIi3OwjMWqjWPuhcK8HvZROXOe7x1J34OIXd+Rw+Npn2fKC/+A== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr3739914lfb.131.1455820133859; Thu, 18 Feb 2016 10:28:53 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 18 Feb 2016 10:28:53 -0800 (PST) In-Reply-To: <4536B87D-6935-49A7-B472-8D6AE3A21E7A@nic.cz> References: <56C5869C.2030207@nic.cz> <4536B87D-6935-49A7-B472-8D6AE3A21E7A@nic.cz> Date: Thu, 18 Feb 2016 10:28:53 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11405936ef9ae2052c0f8929 Archived-At: Cc: Netconf Subject: Re: [Netconf] Permission inheritance in NACM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:28:58 -0000 --001a11405936ef9ae2052c0f8929 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2016 at 10:10 AM, Ladislav Lhotka wrote: > > > On 18 Feb 2016, at 18:15, Andy Bierman wrote: > > > > Hi, > > > > NACM has not been updated to support RESTCONF. > > Eventually the NETCONF WG will produce an update and WG consensus will > > determine the answer to your question. > > > > My guess is that ancestor nodes of the target resource data node are > treated > > the same as NETCONF where the operation=3D"none". (i.e., all ancestors > need > > to exist). > > How does it work in NETCONF? Is it possible for a client to have read > access to a leaf if it doesn't have read access to an ancestor container? > > It is not possible in NETCONF to retrieve data from within a subtree. Only top-level subtrees can be returned. I would expect RESTCONF to enforce GET access from the root to the target node. The operation=3D"none" applies to write operations. If the target is /X/Y then /X must exist, but no write access is checked for /X. Note that NACM w/RESTCONF does not work well with HTTP caching. The ETag and timestamp are associated with the data node, not each client's view of the data node. If the NACM rules change that affect node /X, this will change the resource representation received by specific clients. However the ETag and timestamp do not change. If the client uses If-None-Match then a 304 Not Modified is returned -- even though NACM changed the representation for a particular client (add and/or remove nodes from view) In terms of RFC 6536, does "path" match mean an exact match or prefix match= ? > exact match > > Lada > Andy > > > > > > > Andy > > > > > > On Thu, Feb 18, 2016 at 12:53 AM, Pavel =C5=A0p=C3=ADrek > wrote: > > Hello, > > I am currently working on implementation of NACM for RESTCONF and I > would like to ask if there is some kind of permission inheritance in > Netconf Access Control Module (RFC 6536). The procedure of access > validation to specific data node is described in paragraph 3.4.5. of RFC > 6536. But it's not quite clear if I should also consider rules controllin= g > access to parent data nodes. > > > > I checked implementation of NACM in libnetconf (nacm.c:1236), and it > also doesn't look like that parent nodes are processed there (or I am > missing something)... > > > > Thanks, > > Pavel Spirek > > > > _______________________________________________ > > 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, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11405936ef9ae2052c0f8929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 18, 2016 at 10:10 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 18 Feb 2016, at 18:15, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> NACM has not been updated to support RESTCONF.
> Eventually the NETCONF WG will produce an update and WG consensus will=
> determine the answer to your question.
>
> My guess is that ancestor nodes of the target resource data node are t= reated
> the same as NETCONF where the operation=3D"none".=C2=A0 (i.e= ., all ancestors need
> to exist).

How does it work in NETCONF? Is it possible for a client to have read acces= s to a leaf if it doesn't have read access to an ancestor container?

It is not possible in NETCONF to retri= eve data from within a subtree.
Only top-level subtrees can be re= turned.=C2=A0 I would expect RESTCONF to enforce GET access
from = the root to the target node.

The operation=3D"= ;none" applies to write operations.=C2=A0 If the target is /X/Y then /= X must exist,
but no write access is checked for /X.
Note that NACM w/RESTCONF does not work well with HTTP caching= .
The ETag and timestamp are associated with the data node, not e= ach client's
view of the data node.=C2=A0 If the NACM rules c= hange that affect node /X,
this will change the resource represen= tation received by specific clients.
However the ETag and timesta= mp do not change.=C2=A0 If the client uses If-None-Match
then a 3= 04 Not Modified is returned -- even though NACM changed the
repre= sentation for a particular client (add and/or remove nodes from view)
=


In terms of RFC 6536, does "path" match mean an exact match or pr= efix match?

exact match=C2=A0
=C2=A0

Lada


Andy
=C2= =A0

>
>
> Andy
>
>
> On Thu, Feb 18, 2016 at 12:53 AM, Pavel =C5=A0p=C3=ADrek <pavel.spirek@nic.cz> wrote:
> Hello,
> I am currently working on implementation of NACM for RESTCONF and I wo= uld like to ask if there is some kind of permission inheritance in Netconf = Access Control Module (RFC 6536). The procedure of access validation to spe= cific data node is described in paragraph 3.4.5. of RFC 6536. But it's = not quite clear if I should also consider rules controlling access to paren= t data nodes.
>
> I checked implementation of NACM in libnetconf (nacm.c:1236), and it a= lso doesn't look like that parent nodes are processed there (or I am mi= ssing something)...
>
> Thanks,
> Pavel Spirek
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br> >
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11405936ef9ae2052c0f8929-- From nobody Tue Feb 23 14:54:46 2016 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 CE6E31B35A6; Tue, 23 Feb 2016 14:54:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223225443.24350.10772.idtracker@ietfa.amsl.com> Date: Tue, 23 Feb 2016 14:54:43 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:54:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Alberto Gonzalez Prieto Eric Voit Ambika Prasad Tripathy Einar Nilsen-Nygaard Filename : draft-ietf-netconf-yang-push-01.txt Pages : 58 Date : 2016-02-23 Abstract: This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to a receiver per a subscription policy, without requiring additional client requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 26 08:23:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AB11ACD3E for ; Fri, 26 Feb 2016 08:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdEZxFI7U3cp for ; Fri, 26 Feb 2016 08:23:02 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9192C1ACD37 for ; Fri, 26 Feb 2016 08:23:02 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id s5so33534952qkd.0 for ; Fri, 26 Feb 2016 08:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=AsV86Tham7c74gAoqwizGK/Y3WwX0DmAP+8TPU+qoDc=; b=u+74Dpd7ZlSo8qYKinnpmcbZcAwXvGKNVrVZE86+sfwqbAOrTUP0pFPaSd/Hb51QXC h5sMzgOncXAzCdeZlxbAHZ8VXC8H1s3CXoIGaFZEBztfS5i0wAj4zofmtNkIF2H42J/e ZkHmV9e+UUFkUtoEBpAT0l+MyMX5xus6d/PSu5Eef2BQsl02HgTBmQMj5PaLM/hR9vOi 4pFCp8qTL7UZpHOrpCABG6xX1Uvlu+EmAGuofzMTm3SFRDxaKS5jHTaztcv+aErXi5Sj Ww3cPmCIlSOF3m3hjsesfgzzhr+jdQYdak4CBoQ8QF8UEfbvWUD/rSA0BW1eGgXwc6H9 qTTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=AsV86Tham7c74gAoqwizGK/Y3WwX0DmAP+8TPU+qoDc=; b=fhrcYCThjLxNYIl7T8EHUbxB19HtpJP/A0Kcim+i45zP4bNQRmRBeulzUPWA86SuEO D++AIVF7QxZd0pMp2uYNEIRBZZub0jhrKkVh3eMkxszbp+5ubSBzZ5FzgYX+6Ttur/k1 EMFjr8HB4oAtmJZBDGfT5FEdWkCn7PdRxPFeCeu5ZYOgCuay5+67Lk8A02f0GJ7LmnBB wE4H3s8iCc0u48M1iDRuSg2vupmEG9Zv/fj2WNLB6p9IXFNahLewDjOA5E58DX4fbgJ9 KFqKC+pohjelmeoRR/8QYc3W5gq5ywf0fdihowo6TMiCtobfWa+ziVWJwRALDXC7Q4eG zNsQ== X-Gm-Message-State: AD7BkJIXKWInle/6MD3AABYrZudqPfM32Okr4ljo1MXk5IBOcBqfNNzLWFmOA3GWJJH/WktwlSdxySZCNpTseQ== MIME-Version: 1.0 X-Received: by 10.55.74.86 with SMTP id x83mr2996290qka.89.1456503781769; Fri, 26 Feb 2016 08:23:01 -0800 (PST) Received: by 10.55.26.65 with HTTP; Fri, 26 Feb 2016 08:23:01 -0800 (PST) Date: Fri, 26 Feb 2016 10:23:01 -0600 Message-ID: From: Behcet Sarikaya To: netconf@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 16:23:03 -0000 Hi all, Does anyone have some example edit-config procedure with create operation? RFC 6241 has some good examples but none with create. If there is a draft, point it to me please. Regards, Behcet From nobody Fri Feb 26 15:42:47 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7DE1B3354 for ; Fri, 26 Feb 2016 15:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkSPiDNtuOg8 for ; Fri, 26 Feb 2016 15:42:45 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458611B3383 for ; Fri, 26 Feb 2016 15:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=706; q=dns/txt; s=iport; t=1456530165; x=1457739765; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BwjjYsaOvunXQoJ+N9H5PJg4hkPn/pCYNyfTgL1vwLs=; b=aaRNnoSF4M1A6nrqezZFbG6H99eyiwuSn7ls/XesKCD5w1L7ZOHvgFvp X17hsZLSPrufuFRlMGpkcUOdJKP365Vorw21bRLZWR759V4tRVrTKiU2L tv/SZfEG9RtzOyln0xSh5LipyYO0fDCQ6hiSs866U/2yayIpwRtVgGChy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgCX4tBW/4cNJK1egzqBRbg2ghMBD?= =?us-ascii?q?YFmh1I4FAEBAQEBAQFkHAuESIELAS1TJgEEG4gXn3meRAEBCAEBAQEBG4YSjSk?= =?us-ascii?q?FjWKJJgGNWIFQjSuOSAEeAQFCg2SIN34BAQE?= X-IronPort-AV: E=Sophos;i="5.22,505,1449532800"; d="scan'208";a="77307949" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2016 23:42:44 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1QNgiot031038 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 26 Feb 2016 23:42:44 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 17:42:43 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Fri, 26 Feb 2016 17:42:43 -0600 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: YANG Push (PubSub): new capabilities in draft-ietf-netconf-yang-push Thread-Index: AdFw71guZUbMdWMgRuWW3kJoLkgeKA== Date: Fri, 26 Feb 2016 23:42:43 +0000 Message-ID: <1d4d77ff0dae4366be50dc823f39773f@XCH-ALN-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Netconf] YANG Push (PubSub): new capabilities in draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:42:46 -0000 This week we uploaded a new version of the draft-ietf-netconf-yang-push.=A0= =A0 Updates include: * Refined RPC & Notification definitions * Multiple targeted YANG subtrees within a single subscription =A0=A0=A0 - includes custom filters for each target * Static YANG subscriptions: new capabilities =A0=A0=A0 - ability to push to multiple recipients =A0=A0=A0 - ability to designate egress interface/address/VRF * Preparation for integration with RFC5277-bis =A0=A0 =A0- alignment on object names in preparation for an upcoming RFC527= 7-bis draft proposal =A0=A0 =A0- inclusion of RFC5277 filters We look forward to your questions & feedback, - Alex, Eric, Alberto, Ambika, Einar From nobody Fri Feb 26 17:21:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AB41A009E for ; Fri, 26 Feb 2016 17:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn-LgoE7dCsq for ; Fri, 26 Feb 2016 17:21:15 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CBC1A0092 for ; Fri, 26 Feb 2016 17:21:15 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id yy13so59375605pab.3 for ; Fri, 26 Feb 2016 17:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=iNuwoioe6anUp0JnH//Q5PruIe02XxPV1XDlvUvhl2U=; b=ivBYpfppUt+/eGomVRTLov5qJYoMGX5+GXK3OtQ2HzphFF74F208pQPge/6D08qF04 Xlzzcv7IoaSmIxT0KCXvynFoR8jEBMLhpUozT4F/0RPAMjbfzgLXWvq/u9Vz66RKpHZY vfI1hhBvMwgL0/pRNscb0ATA9I968Di9VDr/ASXAyzSerdK4OidVw5m7IQtFtgv83FrO dJ5lZyDAl74z1p4meA61SnPyIDNCAc81UA1unjElQzMqicMlhxi6XZanmHsSNA+INyqU DLQ2qIxCqzPxFygBbx+mLY2LwGzzzvLP5p1jqvrL7yc/OhPo2bkwfiiV2Se7AX3KS9aU 1LNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=iNuwoioe6anUp0JnH//Q5PruIe02XxPV1XDlvUvhl2U=; b=dV5lKojYa18fUZrsVYqVQ/c0zGGiXD3pFFK0IFIf70m4E6fARF8PqoEIVvK7e0uNYK d9VeAbKUTX88yz1baKMvqduYwvPmhmj3ISkoGMlIHVPBKjR5k0jBauccbD+GbXMaQosH zh2lqsw5p0iezc7g+Wo4QDv65QgZvISjD1NKRsYuB4ISR5NF0fnmBQnLY0JOwkhiqD6L C8pYYCO4Yyx6YQfOHh7sACmc94el5DlDTXg54kA0yxMTfdb0ZAm+E+DGCKYE+EYdCLiA 2HzgxAqy+jggbl0/E9vb4BKduI81FeNdlA2RREuIdPR8N/iD7c3BzW5vWxef+S3QCfoV XQHw== X-Gm-Message-State: AD7BkJLOQjpSDQoK/ubiMefsOJhslbNDjmT/DfkE9bSNvLTRAWuOkZjhqxt+Xem6Exf2mA== X-Received: by 10.66.55.39 with SMTP id o7mr6187052pap.13.1456536075055; Fri, 26 Feb 2016 17:21:15 -0800 (PST) Received: from dhcp-171-71-145-111.cisco.com (dhcp-171-71-145-111.cisco.com. [171.71.145.111]) by smtp.gmail.com with ESMTPSA id ah10sm21984752pad.23.2016.02.26.17.21.13 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 17:21:13 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 26 Feb 2016 17:21:18 -0800 To: NETCONF Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Netconf] One or three drafts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 01:21:18 -0000 I am following up on the discussion in IETF 94 on the question of = whether we need one or three drafts for YANG push. One draft would mean = a merge of NETCONF and RESTCONF YANG push draft, while three drafts = would be a common draft, the second one for NETCONF specific part and = the third for the RESTCONF specific part. There was no preference for = just two drafts - one for NETCONF and one for RESTCONF with common parts = either duplicated or referenced. The vote in the room seemed to indicate = a tie for 1 or 3 drafts with no apparent winner. The authors indicated a preference to keep them as separate drafts, but = others in the room seemed to indicate that other drafts, like call home = and zero touch are doing it as a single draft. Can we have a discussion of whether folks would prefer to read and = follow YANG push as three separate drafts or would they prefer to see = them merged? Thanks. Mahesh & Mehmet. From nobody Sat Feb 27 08:18:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638311A8A44 for ; Sat, 27 Feb 2016 08:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79b9sYU1jAd6 for ; Sat, 27 Feb 2016 08:18:39 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81F91A8A4A for ; Sat, 27 Feb 2016 08:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XK8+vNg9+ZJ9tGpDp+5LmuXD3I7EArYrpKpCQNYrXrM=; b=J45nLVOQnvCV3b4CpdSGOiTsyesM2tXJltfmbseoVUek2+ebGdpOVdEgP/4oIlxcSg85LGFdRunti+wkPRe4Ut8lco/BdL3J/dNWDb61fnRd00BK0p3yrDIaD0n+X/1MdGRASseGI87wFg4IkDA5qA8J7nHJ20k/uqmkpF1yBfQ= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.84.85) by VI1PR07MB1630.eurprd07.prod.outlook.com (10.166.142.148) with Microsoft SMTP Server (TLS) id 15.1.415.20; Sat, 27 Feb 2016 16:18:17 +0000 Message-ID: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> From: t.petch To: Mahesh Jethanandani , NETCONF References: Date: Sat, 27 Feb 2016 16:14:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.84.85] X-ClientProxiedBy: AM2PR09CA0069.eurprd09.prod.outlook.com (25.160.228.165) To VI1PR07MB1630.eurprd07.prod.outlook.com (25.166.142.148) X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 2:wt739o5AlB1/DJyMofXmI6mYnSbqgi54FLGHuWX0i0HVPrbtY2Be5/epdezgd5cM5QSlaJ4AmYpArUm+R/+FDM5Ccz9na592ZFPr7x0cSA87aaf91ES0+01x4xSkgH2JyrOZrdTlgAs3eacWQATgkg==; 3:TdnIOY+qj9zdqQnN/5UPHJlpWfuRxidLJA4HuKEkhLmbMFVPsz77e8qpNAK0FgeUxQByO2HIq4piZPibUKNGCSAsQUMIzSDmAreb6RiQ0LZbb9/K80pEkOF6y6XEy/n7; 25:yBqgUFcgUWxAUZA4AAGqmtYlq7XHCdx/k7/lwXNtU+Sp6quH7Fwmquclr1TDyjnNQ43igu4ll33LGxbpB0PkZ6VcCsKklkk+IgPNQ6rSbWQd9fEhJKe4JZaKSzdK9g4CkiOXDRAhCBj0AWi4vDVGdlBg6Y0Z/J6L3ZjzImgGWr9jf1OSgEXLfObSAxaniRG3QU6tTglvF5C3QEUyVmUevORx96xzmDU/KupItj0KS0mfwARlApNkEWG5l0DnCMBRfZuQAEy+UFgrIL73iFCiJ8J5ZN/TVmqOU9gXYfpdxasI+2N3nJVNjPSI9g2A6OVgll6890MNdTwuH0L9G5nHoA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1630; X-MS-Office365-Filtering-Correlation-Id: f1f41d84-af4b-4557-08a9-08d33f919a3a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1630; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1630; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 4:iEeXe3gP+34fL1sFIPF/YOGvoxWFz/jeL9XcfIr0cGCdZ6xcM+ceU+GMRvZMQYeLAwzDuabfisSsJUHrK/APzusEAgEFLepvx3C3BQikKbv7nJJ6bosl41acq1CrWt/JVvxhxh+jh5nZYPb2wML1xiflUTAIDHqSo9rWgKrxpxV9NRjQ1k8ceBq0k4MNPwT9+zsQv7YJcp7uqyK2rxfB+My3Vr7L0Je2wMg44XxCxmqEMJIL0OFZmoo0palE7DHxYOL9UzkhqG/P5kP+Gc8JVOQvYThJVRBg4+22/bRziLRC3JLYuf23MoyiEyzr++rDn4PVINO1593Ab52nA+BslmB9wRuqva1z9dA9EewQANXPhfH1yDnIfhXaHyYCJP/L X-Forefront-PRVS: 086597191B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(1456003)(77096005)(5004730100002)(23756003)(586003)(14496001)(3846002)(6116002)(1096002)(87976001)(1556002)(76176999)(230700001)(86362001)(81816999)(107886002)(5001960100002)(50986999)(97736004)(81686999)(40100003)(122386002)(61296003)(42186005)(5008740100001)(33646002)(116806002)(50466002)(50226001)(44736004)(47776003)(44716002)(62236002)(92566002)(66066001)(2906002)(5001770100001)(84392002)(189998001)(19580405001)(19580395003)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1630; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1630; 23:22DwokAjoe268bC7Hq/wsyityd6Jyb1mZh4G9Ag?= =?iso-8859-1?Q?XyxH9CqcZH2im4/Iv9TlzulZWrlR0v3K6t4WJ2HxyI1Nkei3rmN5bG+nCS?= =?iso-8859-1?Q?w3e1+BDQdZhvn32H3fUx0lesWUFkc6oMy/skWfQVBioxPN6zrIIOa3DbE3?= =?iso-8859-1?Q?4B+DYZFai0RUJ0rmlDBWSRCb8NBkK2pjhYgQYdf+mmMs9h16IBq+m4DM3h?= =?iso-8859-1?Q?0zH6d2PsxEiNAelev+9CdJSlMqb12COgjyDrvWi0XiRF65TIAbXtQFROrf?= =?iso-8859-1?Q?apH91o/T3GqD73dh9rUhe41ugvlrOBUhASq0MAziHj5CqWbU9MKysemDZJ?= =?iso-8859-1?Q?bLT7N3Girg/NkQblU0Vdc0UDEXbkNOL5kAquwkxyGqBxbUpkPQ1FziJw0N?= =?iso-8859-1?Q?7nkvYMl5c8UBR3MvZci1gFbENojHmks7EhLEdSCxBYxFm1/DZrineuIxur?= =?iso-8859-1?Q?ux0eIkOMGiuNSqLjLP+ChV5mYMhCGXDT/ecM3QSfui8QB7oYYCBZ+sswJs?= =?iso-8859-1?Q?JdPJRpvkUGvgR1DiiPU+2zco7Atj7TEKkTVUzUVYX2LhtO2Xil4PlSkXQF?= =?iso-8859-1?Q?/QX9/43sGnoOmbj9975DQGRjzWtC37Ct40m2sNqgbHOn1Cfu5CjK/DeIuE?= =?iso-8859-1?Q?b4s7VVBjhwMmZO8FZFgYg2NDB62or2OcEnQ+zO6Y7tlqMNfxnBNGup9SQN?= =?iso-8859-1?Q?CVxwbKe0FBGeEmypZs9z12YEs7rCwIgW423NrCmKAG/AeBggbrJSTniI/0?= =?iso-8859-1?Q?Ge93BKqzW5Wv/8Ua/ESWhydOKA0R8j2SL5/rPsjWhSeTZ2IT4q7qvqTkjN?= =?iso-8859-1?Q?cXnQKOutI29L6UW18zm5xRvkoAc37HfG6Bp0ZoKhQNxCqe345mjLxg6XjF?= =?iso-8859-1?Q?MsBpVm9TLH3LX0nQ7zsXk4v2ZkVfFX3uIbIJ+7nZ/J/fzjRKrym/GVWpZQ?= =?iso-8859-1?Q?hbQTUFkAsujXe9OUTenoTspBLLSrmCrZ6FEGissVujPa3zo9G9k8Cw53KD?= =?iso-8859-1?Q?oWmiwpxF/7sDp67A5B2t7wUY+pt0iBT9v0RJUKY2Le+YkanvxqmC1TMf9S?= =?iso-8859-1?Q?vxxQa7kRuLkLoh6C4ypAStgWyOnkOHIl0zN93Pn0e03odOy8RD/twMWtDw?= =?iso-8859-1?Q?BuvmHfVTSRdtKq215N/K+YovoIPmwHtJv0rnoJZFV2JKjt1yAEjWz96z2a?= =?iso-8859-1?Q?Dg8FuQuWuZXUB6r5x8zuN65KMA6t2exYBzFeJjGmUNVuTkkNm2djPtgxTR?= =?iso-8859-1?Q?mcdFOBc604xRYmPhYr+lOc1YpCF3uHlB3NiGIRapvnCelk78Zb8rH0z/6w?= =?iso-8859-1?Q?4A=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 5:gz4xZLcQE2tlq/hlq/NNUygIie/p9EAluGpEI8cCJL3UgsuUFVRfC5KyazQ6d+Cq757pLBEyxqZ0iSrP4W71oIhH30p/pSdXGdkaG+dsR1izsQaeDpi/o/eB08twls5DPv5gx+K842Mo2hQPr3gobg==; 24:HWs/WkfkB7uUhNZG8WwfaXmVj61UNpL3cpNPTfd57dCpvOOdNHVMs+GZfPxyNsn8hS5tiB6e0524f2tDpUWUACuD2zKWKtJJZwMynEMbhx8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2016 16:18:17.7486 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1630 Archived-At: Subject: Re: [Netconf] One or three drafts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 16:18:41 -0000 ---- Original Message ----- From: "Mahesh Jethanandani" To: "NETCONF" Sent: Saturday, February 27, 2016 1:21 AM > I am following up on the discussion in IETF 94 on the question of whether we need one or three drafts for YANG push. One draft would mean a merge of NETCONF and RESTCONF YANG push draft, while three drafts would be a common draft, the second one for NETCONF specific part and the third for the RESTCONF specific part. There was no preference for just two drafts - one for NETCONF and one for RESTCONF with common parts either duplicated or referenced. The vote in the room seemed to indicate a tie for 1 or 3 drafts with no apparent winner. > > The authors indicated a preference to keep them as separate drafts, but others in the room seemed to indicate that other drafts, like call home and zero touch are doing it as a single draft. > > Can we have a discussion of whether folks would prefer to read and follow YANG push as three separate drafts or would they prefer to see them merged? I don't know, can we have a discussion:-) Well, assuming we can, I am for a merge into one I-D. Tom Petch > Thanks. > > Mahesh & Mehmet. > From nobody Sun Feb 28 09:31:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B911A878A for ; Sun, 28 Feb 2016 09:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW7Y3r8sqUKz for ; Sun, 28 Feb 2016 09:31:36 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD4C1A876C for ; Sun, 28 Feb 2016 09:31:35 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id of3so68645413lbc.1 for ; Sun, 28 Feb 2016 09:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=py0aPhhZoWuTBKOHHVrJbQO1UOIOFvfjgG5XYO3I1NI=; b=t7Nf5GxA/uUWnkOnOWcOEayEa6yFbDF+sTsDdEEqZS8oot/rM0qMQKApHjd1seaBo/ UcJoQKIl0UzBhynnG2Na4Qa99eEiXE/4oDnrE9mJ5fkmy/xbeY/u9j6AF84qxjMpUCYS 938QuPA56GROEKG5ftcOQmlJViuPPVCCCGfPl5Uw+9IZIgbNQu6t175t5B3PoitzqIfd 36hxGPmUPiIgr/zq31eoVkCtc48ExPi+T6SIGtRcLHU6LDbmkr6J9YpEHhO5JanEUOXL Lbw2tf+2eeDx0+x7sW6DrssH861RvYjhCbSIXsSRqY9TBc9v95Zf8PdADIXbKeaPm1pt 1Nww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=py0aPhhZoWuTBKOHHVrJbQO1UOIOFvfjgG5XYO3I1NI=; b=GYxwdv8o+gJu2FJH25CyRaJX+i4kruRmiIAAbRqGGddBWt0P4FuQslakVw2kunCCbN YMkElsVcWcqnu1cdT2hsbsh0lCbSeh+SwuIMsU5Fp4mI/lB6EBRaRKL34HfPPqkX84ff 2RVcQ6haeDJOSbn53qmfZcFjxUlSU2hczfgU9kevQo68yd8CHuu/BFcGGMiAt4m2i+DF 7G9hVKt9fuTRiZGCXTDhy+66aSuwMryrA9Yip1b4D4/imqafqZXo4Nh4dq1sd6UBVw6Q Lk6E5CczpEIgpqzoyzjz+e2StICQPtAaLmzD8hc+Z0+K6l0z9r28XdTpN3m+TEVKnvXo dNjw== X-Gm-Message-State: AD7BkJK5DAWXyDGiCmb3svhmaxPJi3/SaE6y9xHkPeDNOpROin0jX9inBzNGN8OapLJ2au7IL3LN9VHs9GX1iA== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr4014851lbc.145.1456680693544; Sun, 28 Feb 2016 09:31:33 -0800 (PST) Received: by 10.112.110.68 with HTTP; Sun, 28 Feb 2016 09:31:33 -0800 (PST) In-Reply-To: <001601d1558b$c9b3bd70$5d1b3850$@ndzh.com> References: <001601d1558b$c9b3bd70$5d1b3850$@ndzh.com> Date: Sun, 28 Feb 2016 09:31:33 -0800 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c36b364a5309052cd7e71d Archived-At: Cc: Netconf , jgs@bgp.nu Subject: Re: [Netconf] read-through comments on draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 17:31:40 -0000 --001a11c36b364a5309052cd7e71d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The co-authors are working on a new revision of RESTCONF. We are not adding any new features for I2RS. There will be a new section explaining how RESTCONF can be extended. It is expected that additional RFCs will be needed to support new functionality related to opstate or I2RS. Andy On Fri, Jan 22, 2016 at 7:11 PM, Susan Hares wrote: > Andy, Martin, Ken: > > > > My read through comments have 4 parts: status, minor issues, editorial, > and i2rs-related comments. The I2RS-related comments are only to show th= at > ephemeral state can be added incrementally to this design. I hope these > comments will help progress RESTCONF quickly! > > > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Section 1: Status: Almost Ready to be publish, minor issues/editorial ni= ts > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Section 2: Minor issues: > > +2.1 =E2=80=93 what other protocols than TLS are possible for HTTP for R= ESTCONF > > [Joe Clarke Fri 1/8/2016 2:10 PM also mentions] > > > > +3.4.1 - This is Edit Collision detection for the {+restconf}/data nodes > by the server for Patch entities > > may be useful for I2RS (see I2RS comments below). What i= s > not clear from the text is whether you can > > have a tree > > +--rw data-level-1 time-stamp, Entity-Tag > > +--rw data-level-2 Entity-Tag [no time > stamp] > > +--rw data-level 3 Time stamp [no > entity] > > +--rw data-level 4 Time-stamp, > Entity tag > > > > If you must a continuous line of ancestors with time-stam= p > (levels 1-3) to have level 4, then this must be explained. > > Likewise if you must have a continuous line of ancestors fo= r > Entity-Tag, then this must be explained. > > > > +3. Section 4.6 =E2=80=93 there is a plain patch, but no mention is made = of a more > complicated patch. Is this on purpose, or did you want to refer to > another draft? > > > > +4. List actions that apply to all list entries: GET, DELETE, sequence of > PATCHes for a list (multiple entries from Lada (+1 on Lada: Mon 1/11/2016 > 5:36 AM), > > > > +5 Application of multiple filters in order for Query plus start-time/sto= p > time. Is this possible? > > > > +6 =E2=80=93 Does Data timestamp and E-Tag apply to operational state dat= a? > > +--rw restconf > > +--rw data > > +--rw config-data > > +--ro oper-state-data > > +--rw operations > > > > +7: You do not mention leaf-lists (this is +1 on Lada Mon 1/1/2016 5:36AM > comment). > > > > +8: CAN RESTCONF and NETCONF both attach to a data store? > > If so the question regarding netconf lock (persist-id), and RESTCON= F > edit collisions > > Needs to be reference in section n3.4.1. If not, it needs to be > clearly stated > > (+1 Martin Bjorklund=E2=80=99s comment on revising locking 1/8/2016 = 9:45pm) > > (see Tom Petch=E2=80=99s comment A) on 1/22/2016 at 11:20am) > > > > +9: +1 on Security review that more needs to be in the security section. > > =C2=B7 It would be helpful to consider whether the I2RS extension= s > suggested below might break the data security of RESTCONF. I believe > RESTCONF will fulfill the I2RS protocol security requirements minus the > ephemeral state (not created yet). > > =C2=B7 Note that Tom Petch (comment A on 1/22/2016 at 11:20am) = =E2=80=93 asks > if =E2=80=9Cauthenticated NETCONF username [MUST] be associated with each > request=E2=80=9D. > > =C2=B7 NACM is clearly specified in order to allow some filtering= of > results, but the link to authenticated NETCONF user name is not as strong= ly > linked. Since I2RS has suggested NACM may prevent some DoS attacks, thi= s > may be useful. > > > > +10- +1 on (Rodney Cummings 1/11/2016 5:30pm) =E2=80=93 we should have a > capability that indicates if we can pull module schema if this is > optional. Security may restrict a full pull of the module schema if ther= e > is a module augmentation by a vendor that has security add-ons. > > > > +11 =E2=80=93 Since insert and point is required for PUT/POST on the serv= er, can > modules be designed that do not support it? The comment from Rodney > Cummings 1/11/2016 5:30pm] surprised me. Can this be explained or define= d > some-how? If modules do not support it for lists, then please explain th= e > error handling. > > > > +12 - +1 to Robert Wilton=E2=80=99s question on http 1.2? Section 2.1 sp= ecifies > http 1.1 [RFC7230]. Will RESTCONF run over HTTP 1.2? I did not find an= y > restrictions on http 1.1 pipelining. Does this mean that RESTCONF can > access different parts of a tree via two different sessions? What happe= ns > if overwrites =E2=80=93 Last one wins edit collisions =E2=80=93 unless yo= u have the model > timestamp and ETAG ID flags on? > > > > +13 - +1 on the question or edit ordering from Robert Wilton [1/19/2016 > 5:46am] > > > > +14 - +1 =E2=80=93 where netmod-opsstate-reqs fit into this document? It = would be > good to determine if the module that is =E2=80=9Cread-only=E2=80=9D can g= et a query such as > =E2=80=9Cop-state-only=E2=80=9D. It would be good to query for multiple= flags (op-state, > with-default, ephemeral). Have you considered how you will merge this i= n? > It would be good if these would be incremental upgrades. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Section 3: Editorial issues: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > #1 Multiple places /operational data/operational state data/ > > [+ to Lada: Mon 1/11/2016 5:36am concern, but different resolution] > > > > #2 p. 6: HATEOAS ( at least deserves an expansion, and a definition) sinc= e > it is the scheme you are not choosing. (+1 on Lada: Mon 1/11/2016 5:36 > AM), > > #3 p. 10: ABNF =E2=80=93 first time ABNF is used, it should be expanded. > > #4 p. 25 =E2=80=93 In section 3.6.3 in paragraph 2 > > /Using the =E2=80=9Creset=E2=80=9D operation/ Using the =E2=80=9Creset=E2= =80=9D operation from the example > in section 3.6 > > > > #5 p. 30 section 4.4.1 paragraph 2 > > from /The =E2=80=9Cinsert=E2=80=9D and the =E2=80=9Cpoint query parameter= s are supported by the > POST method > > for data store and data resource types, as specified in the yang > definition in section 8./ > > > > /The =E2=80=9Cinsert (section 4.8.4) and the =E2=80=9Cpoint=E2=80=9D (sec= tion 4.8.5) are supported > by the POST method > > for data store and data resource types, as specified in the yang > definition in section 8./ > > > > #6: [Lada=E2=80=99s comments] =3D +1 on most of Lada=E2=80=99s editorial = comments [Lada > Monday 1/10/2016 5:36am] > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Section 4 =E2=80=93 I2RS and ephemeral state. > > ----------------- > > #1 =E2=80=93 expanding the Query and PUT/PATCH to allow for ephemeral sta= te in > Data Store per node > > > > a) Expand Query=E2=80=99s =E2=80=9Ccontent=E2=80=9D and create a =E2= =80=9Cwith-ephemeral=E2=80=9D to allow > for query of Ephemeral state. Expanding > > b) Expand PUT content to allow ephemeral > > > > RESTCONF allows access via API to data (datastore) and operations. The > data store has > > Allows default data for a node. If one considers ephemeral to apply to = a > node, and > > Entries under it =E2=80=93 then the treatment of =E2=80=9Cdefault=E2=80= =9D (section 4.8.9) may be > useful as a template for ephemeral. > > > > Recently, I have reviewed BGP and found Session ephemeral state (BGP Flow > Specification, and > > BGP QoS SLA state) which terminates if peer goes down. There are two > types of ephemeral: reboot ephemeral and session ephemeral. Let me give > the example with packet forwarding filter (a filter) which can have two > types of ephemeral nodes: I2RS FB-RIB filter, BGP Flow Specification > filters, as well a configuration filter (ACL or > packet-reception-filter-Condition-Action rule). > > > > +--rw restconfig > > +--rw data > > +--rw configuration > > +--filter-list* [name] > > +--rw name > > +--rw Filter > > | +--value > > | +--rw default-value > > | +--rw config-store-value > > | +--rw ephemeral-reboot-value > > | +--rw ephemeral-session-value > > | +--rw value-type =E2=80=93 flag on what is in value > > | default, config-stored-value, > > | ephemeral-reboot-value, > > | ephemeral-session-value > > | +--rw precedence-order (default, different order) > > | (this provides either a precedence or different > order) > > +--ro oper-state > > +--ro Filter-1 > > | +--ro value-type =E2=80=93 type currently runing > > | +--ro pkt-match-count > > +--rw operations > > +--- > > > > The value =E2=80=93 could be set from default value, config-store value, > ephemeral-reboot-value, or ephemeral-session value. The =E2=80=9Cvalue-t= ype=E2=80=9D gives > the type set in the node. > > > > Expansion of command: > > =C2=B7 If we expand the Query concepts of =E2=80=9Ccontent (secti= on 4.8.1) or > create a =E2=80=9Cwith-ephemeral=E2=80=9D, you can utilize the Query to g= et specific > ephemeral state. > > =C2=B7 If you expand the concepts in PUT/Patch to allow to set th= e > ephemeral notes. > > > > #2- RESTCONF Collision handling vs. I2RS Collision handling > > =C2=B7 Timestamp and E-Tag =E2=80=93 provide the when and who > > =C2=B7 I2RS collision uses - when, who, and priority =E2=80=93 > > Since 1 user has 1 priority per session, I think > > we could simply link the =E2=80=9CE-Tag=E2=80=9D to a Priority table? > > =C2=B7 Alternatively, we could just create a third collision reso= urce > for I2RS. > > > > The reason for this discussion is to point out, we could just augment > existing RESTCONF to support I2RS requirements. > > > > > > #3 =E2=80=93 if you create an ephemeral data store rather than ephemeral = nodes, > will > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c36b364a5309052cd7e71d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


The co-authors are w= orking on a new revision of RESTCONF.
We are not adding any new f= eatures for I2RS.=C2=A0 There will be
a new section explaining ho= w RESTCONF can be extended.
It is expected that additional RFCs w= ill be needed to support
new functionality related to opstate or = I2RS.


Andy



= On Fri, Jan 22, 2016 at 7:11 PM, Susan Hares <shares@ndzh.com> wrote:

Andy, Martin, Ken:

=C2=A0

My read through comments have 4 parts: =C2=A0status, minor issues, edit= orial, and i2rs-related comments.=C2=A0 The I2RS-related comments are only = to show that ephemeral state can be added incrementally to this design.=C2= =A0 =C2=A0I hope these comments will help progress RESTCONF quickly!=

=C2=A0

Sue

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0

Section 1: =C2=A0Status: Almost Ready to be publish, min= or issues/editorial nits

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Section 2: Mi= nor issues:

+2.1 =E2=80=93 =C2=A0w= hat other protocols than TLS are possible for HTTP for RESTCONF

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[Joe Clarke Fri 1/8/2016 2:10 PM also mentions]=

=C2=A0

+3.4.1 - =C2=A0This is Edit Collision detection for the {+restconf}/d= ata nodes by the server for Patch entities

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0may be useful for I2RS (see I2RS comments below).= =C2=A0 What is not clear from the text is whether you can

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0have a tree

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw data-level-1 t= ime-stamp, Entity-Tag

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0+--rw data-level-2=C2=A0 Entity-Tag [no t= ime stamp]

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw data-level 3=C2=A0 Time stamp [n= o entity]

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw da= ta-level 4=C2=A0 Time-stamp, Entity tag

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If yo= u must a continuous line of ancestors with time-stamp (levels 1-3) to have = level 4, then this must be explained.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Likewise if you must have a continuous line of ancestors for Entity-= Tag, then this must be explained.

= =C2=A0

+3. Section 4.6 =E2=80=93 th= ere is a plain patch, but no mention is made of a more complicated patch. = =C2=A0=C2=A0Is this on purpose, or did you want to refer to another draft? =

=C2=A0

+4. List actions that apply to all list entries: GET, DELETE= , sequence of PATCHes for a list (multiple entries from Lada (+1 on Lada: M= on 1/11/2016 5:36 AM),

=C2= =A0

+5 Application of multiple filters in = order for Query plus start-time/stop time.=C2=A0 Is this possible? <= u>

=C2=A0

+6 =E2=80=93 Does Data timestamp and E-Tag apply to operational state = data?

=C2=A0+--rw restconf<= u>

=C2=A0=C2=A0=C2=A0=C2=A0 +--rw data

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0+--rw config-data

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro=C2=A0 oper-state-dat= a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-= -rw operations

=C2=A0

+7: You do not mention leaf-lists (this is +1 o= n Lada Mon 1/1/2016 5:36AM comment).

=C2=A0

+8: CAN RESTCONF and NETC= ONF both attach to a data store?

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0If so the question regarding netconf lo= ck (persist-id), and RESTCONF edit collisions

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Needs to be reference in section = n3.4.1.=C2=A0 If not, it needs to be clearly stated

=C2=A0=C2=A0=C2=A0=C2=A0 (+1 Martin Bjorklund=E2=80=99s co= mment on revising locking 1/8/2016 9:45pm) =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(see Tom Petch=E2=80=99s comme= nt A) on 1/22/2016 at 11:20am)

= =C2=A0

+9: +1 on Security review that = more needs to be in the security section.

=C2=B7=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 It would be helpful= to consider whether the I2RS extensions suggested below might break the da= ta security of RESTCONF.=C2=A0 I believe RESTCONF will fulfill the I2RS pro= tocol security requirements minus the ephemeral state (not created yet).

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note that Tom Petch (comment A on 1/22/2016 at 11:20am) =E2=80=93= asks if =E2=80=9Cauthenticated NETCONF username [MUST] be associated with = each request=E2=80=9D.=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 NACM is clearly specified in order= to allow some filtering of results, but the link to authenticated NETCONF = user name is not as strongly linked.=C2=A0 =C2=A0Since I2RS has suggested N= ACM may prevent some DoS attacks, this may be useful.

=C2=A0

+10- +1 = on (Rodney Cummings 1/11/2016 5:30pm) =E2=80=93 we should have a capability= that indicates if we can pull module schema if this is optional.=C2=A0 Sec= urity may restrict a full pull of the module schema if there is a module au= gmentation by a vendor that has security add-ons.

=C2=A0

+11 =E2=80= =93 Since insert and point is required for PUT/POST on the server, =C2=A0ca= n modules be designed that do not support it?=C2=A0 The comment from Rodney= Cummings 1/11/2016 5:30pm] surprised me.=C2=A0 Can this be explained or de= fined some-how?=C2=A0 If modules do not support it for lists, then please e= xplain the error handling.

= =C2=A0

+12 - +1 to Robert Wilton=E2=80=99s= question on http 1.2?=C2=A0 Section 2.1 specifies http 1.1 [RFC7230].=C2= =A0=C2=A0 Will RESTCONF run over HTTP 1.2?=C2=A0 I did not find any restric= tions on http 1.1 pipelining.=C2=A0 Does this mean that RESTCONF can access= different parts of a tree via two different sessions?=C2=A0=C2=A0 What hap= pens if overwrites =E2=80=93 Last one wins edit collisions =E2=80=93 unless= you have the model timestamp and ETAG ID flags on?

=C2=A0

+13 - +1 o= n the question or edit ordering from Robert Wilton [1/19/2016 5:46am]

=C2=A0

+14 - +1 =E2=80=93 where netmod-opsstate-reqs fit into this documen= t? It would be good to determine if the module that is =E2=80=9Cread-only= =E2=80=9D can get a query such as =E2=80=9Cop-state-only=E2=80=9D.=C2=A0=C2= =A0 It would be good to query for multiple flags (op-state, with-default, e= phemeral).=C2=A0=C2=A0 Have you considered how you will merge this in? It w= ould be good if these would be incremental upgrades.

=C2=A0

=3D=3D=3D= =3D=3D=3D=3D=3D=3D

=C2=A0=

Section 3: Editorial issues: <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

#1 Multiple places /operational data/operational state data/

[+ to Lada: Mon 1/11/2016 5:36am concern, b= ut different resolution]

= =C2=A0

#2 p. 6: HATEOAS ( at least deserve= s an expansion, and a definition) since it is the scheme you are not choosi= ng. =C2=A0=C2=A0(+1 on Lada: Mon 1/11/2016 5:36 AM),

#3 p. 10: ABNF =C2=A0=E2=80=93 first time ABNF is used, = it should be expanded. =C2=A0

#4 p.= 25 =E2=80=93 In section 3.6.3 in paragraph 2=C2=A0

/Using the =E2=80=9Creset=E2=80=9D operation/ Using the = =E2=80=9Creset=E2=80=9D operation from the example in section 3.6=

=C2=A0

#5 p. 30 section 4.4.1 paragraph 2

from /The =E2=80=9Cinsert=E2=80=9D and the =E2=80=9Cpoint query paramete= rs are supported by the POST method

for data store and data resource types, as specified in the yang definiti= on in section 8./

=C2=A0<= /u>

/The =E2=80=9Cinsert (section 4.8.4) and the = =E2=80=9Cpoint=E2=80=9D (section 4.8.5) are supported by the POST method

for data store and data resource typ= es, as specified in the yang definition in section 8./

=C2=A0

#6: [Lad= a=E2=80=99s comments] =3D +1 on most of Lada=E2=80=99s editorial comments [= Lada Monday 1/10/2016 5:36am]

<= /u>=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0

Section 4 =E2=80=93 I2RS and ephemeral state. =

-----------------

#1 =E2=80=93 expanding the Query and PUT/PATCH to allow for = ephemeral state in Data Store per node

=C2=A0

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Expand Query=E2=80=99s =E2=80=9Ccontent=E2=80=9D and create a =E2=80=9C= with-ephemeral=E2=80=9D to allow for query of Ephemeral state.=C2=A0 Expand= ing

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expa= nd PUT content to allow ephemeral

= =C2=A0

RESTCONF allows access via A= PI to data (datastore) and operations.=C2=A0 The data store has <= /u>

Allows default data for a node.=C2=A0 =C2=A0I= f one considers ephemeral to apply to a node, and

Entries under it =E2=80=93 then the treatment of =E2=80=9Cd= efault=E2=80=9D (section 4.8.9) may be useful as a template for ephemeral. =

=C2=A0

Recently, I have reviewed BGP and found Session ephemeral st= ate (BGP Flow Specification, and

B= GP QoS SLA state) which terminates if peer goes down.=C2=A0 There are two t= ypes of ephemeral: reboot ephemeral and session ephemeral.=C2=A0 Let me giv= e the example with packet forwarding filter (a filter) which can have two t= ypes of ephemeral nodes: I2RS FB-RIB filter, BGP Flow Specification filters= , as well a configuration filter (ACL or packet-reception-filter-Condition-= Action rule).

=C2=A0<= /p>

+--rw restconfig

=C2=A0=C2=A0=C2=A0 +--rw data

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--rw configuration<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0+--filter-list* [name]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw name

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0+--rw Filter

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0|=C2=A0 +--value=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C2=A0 +--rw default-value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0+--rw=C2=A0 config-store-value=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0| =C2=A0+--rw ephemeral-reboot-v= alue

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0+--r= w ephemeral-session-value

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|=C2=A0 +--rw value-type =E2=80=93 flag on what is in value=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0default, config-stored-value,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ephemeral-reboot-value,

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0ephemeral-sessio= n-value

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0 += --rw precedence-order (default, different order)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (this provide= s either a precedence or different order) =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--ro= =C2=A0 oper-state

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--ro = Filter-1

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0 +--ro v= alue-type =E2=80=93 type currently runing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C2=A0 +--ro pkt-match-count

=C2=A0=C2=A0=C2=A0=C2=A0+--rw operations

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+---<= u>

=C2=A0

The value =E2=80=93 could be set from default value, config-sto= re value, ephemeral-reboot-value, or ephemeral-session value.=C2=A0 The =E2= =80=9Cvalue-type=E2=80=9D gives the type set in the node.=C2=A0 <= /u>

=C2=A0

Expansion of command:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 If we expand the Query concepts of = =E2=80=9Ccontent (section 4.8.1) or create a =E2=80=9Cwith-ephemeral=E2=80= =9D, you can utilize the Query to get specific ephemeral state. <= /u>

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If you expand the concepts in PUT/Patch to allow to set the ephemeral not= es.

=C2=A0

#2- RESTCONF Collision handling =C2=A0vs. I2RS Collision h= andling

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Timestamp and E-Tag =E2=80=93 provide the when and who <= u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2RS collision uses - =C2=A0when, who, and priority =E2=80=93 =

Since 1 user has 1 priority = per session, I think

we co= uld simply link the =E2=80=9CE-Tag=E2=80=9D to a Priority table? =

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alternatively, we could just create a third collision resource for I2RS.<= u>

=C2=A0

The reason for this discussion is to point out, we could just a= ugment existing RESTCONF to support I2RS requirements.

=C2=A0

= =C2=A0

#3 =E2=80=93 if you create an ephem= eral data store rather than ephemeral nodes, will

=C2=A0

=C2= =A0


_____________________________________________= __
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a11c36b364a5309052cd7e71d-- From nobody Mon Feb 29 04:03:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5071B30EE; Mon, 29 Feb 2016 04:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95IaLxAwMimj; Mon, 29 Feb 2016 04:03:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A2B1B30EB; Mon, 29 Feb 2016 04:03:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJH94106; Mon, 29 Feb 2016 12:03:13 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Feb 2016 12:03:12 +0000 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.28]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Mon, 29 Feb 2016 20:02:43 +0800 From: Rohit pobbathi To: "netmod@ietf.org" , netconf Thread-Topic: Query regarding "list" subelement XML Mapping rule Thread-Index: AdFy6RQi2WJEZslUTw+Vm6iwhTjwdw== Importance: high X-Priority: 1 Date: Mon, 29 Feb 2016 12:02:42 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44C003F0@SZXEML561-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.210.230] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56D43382.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.28, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 33219d9447e8dc8f1c7eee6379e5fe94 Archived-At: Subject: [Netconf] Query regarding "list" subelement XML Mapping rule X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 12:03:20 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a query regarding "list" subelement XML Mapping rules - RFC 6020 Sec= tion 7.8.5. For clarity, I am using the "example-jukebox" YANG model (from RESTCONF dra= ft). +--rw jukebox! +--rw library | +--rw artist* [name] | | +--rw name string | | +--rw album* [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song* [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 Request from Client to Server: Foo Fighters Wasting Light =3D=3D=3D=3D=3D=3D> Request select= ion node order The selection nodes in above request are not in the same order as defined i= n the YANG model for "jukebox" module's "album" list. I assume this is allowed as per the RFC 6020 section 7.8.5's below paragrap= h: The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order. Please confirm if the above request's selection nodes order is valid = ? Response from Server to Client: Foo Fighters Wasting Light example-jukebox:alternative 2011 Wasting Light MP3 286 Rope MP3 259 For the above request, is it fine for the Server to encode the response wit= h list subelement order as per the defined YANG model ? OR Should the response follow the REQUEST's list subelement order ? Regards, Rohit P --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

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

   +--rw jukebox!

      +--rw library

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

      |  |  += --rw name     string

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

      |  |  =    +--rw name     string

      |  |  =    +--rw genre?   identityref

      |  |  =    +--rw year?    uint16

      |  |  =    +--rw admin

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

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

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

      |  |  =       +--rw name     =    string

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

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

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

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

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

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

 

Request from Client to Server:

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

       <get>

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

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

        &nbs= p;    <library>

        &nbs= p;      <artist>

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

        &nbs= p;        <album>

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

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

    &n= bsp;            = ;  <year/>

    &n= bsp;            = ;  <genre>

        &nbs= p;        </album>

        &nbs= p;      </artist>

        &nbs= p;    </library>

        &nbs= p;  </jukebox>

         <= ;/filter>

       </get>

     </rpc>  &nb= sp;  

 

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

 

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

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

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

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

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

   subelements a= re encoded in any order.

 

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

 

Response from Server to Client:

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

       <data>

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

        &nbs= p;  <library>

        &nbs= p;    <artist>

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

        &nbs= p;      <album>

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

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

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

    &n= bsp;            <= song>

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

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

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

    &n= bsp;            = ;</song>

    &n= bsp;            <= song>

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

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

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

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

        &nbs= p;      </album>

        &nbs= p;    </artist>

        &nbs= p;  </library>

         <= ;/jukebox>

       </data>

     </rpc-reply> &nb= sp;  

 

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

OR

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

 

Regards,

Rohit P

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C003F0SZXEML561MBSchi_--