From nobody Thu Oct 1 00:24:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE71B2B4F for ; Thu, 1 Oct 2015 00:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfwBfQusE4yw for ; Thu, 1 Oct 2015 00:24:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 912BE1B2B28 for ; Thu, 1 Oct 2015 00:24:53 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0C4771CC0686; Thu, 1 Oct 2015 09:24:51 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150930135222.GA25888@elstar.local> References: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <20150930135222.GA25888@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 01 Oct 2015 09:24:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 07:24:56 -0000 Juergen Schoenwaelder writes: > On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote: >> Hi Randy, >> >> thanks for the comments and proposed edits. Please see inline. >> >> Randy Presuhn writes: >> >> > Hi - >> > >> >>From: Ladislav Lhotka >> >>Sent: Sep 29, 2015 7:07 AM >> >>To: netmod@ietf.org >> >>Subject: [netmod] 6020bis - anydata >> >> >> >>Hi, >> >> >> >>I propose to expand the text in Sec. 7.10 as follows: >> >> >> >>OLD >> >> >> >> The "anydata" statement is used to represent an unknown set of nodes >> >> that can be modelled with YANG. An example of where this can be >> >> useful is a list of received notifications, where the exact >> >> notifications are not known as design time. >> >> >> >>NEW >> >> >> >> The "anydata" statement is used to represent an unknown set of nodes >> >> that can be modelled with YANG but for which the data model doesn't >> >> exist at module design time. >> > >> > "doesn't exist" would not be appropriate for the example you provide >> > below. It would be incorrect if some of the notifications in your >> > example had already been defined, even though "anydata" would still >> > be necessary to handle others not yet defined. >> >> Would "doesn't exist or cannot be determined at module design time" be better? >> > > What about this: > > The "anydata" statement is used to represent a set of nodes that can > be modelled with YANG but for which the data model is not known at > module design time. Fine by me. So here is an updated proposal: OLD The "anydata" statement is used to represent an unknown set of nodes that can be modelled with YANG. An example of where this can be useful is a list of received notifications, where the exact notifications are not known as design time. NEW The "anydata" statement is used to represent an unknown set of nodes that can be modelled with YANG but for which the data model is not known at module design time. It is possible, though not required, for the data model for "anydata" content to become known through protocol signalling or other means that are outside the scope of this document, as is the server and client behaviour. An example of where this can be useful is a list of received notifications, where the exact notifications are not known at module design time. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 1 00:33:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CC1B2B78 for ; Thu, 1 Oct 2015 00:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFgeEf6XenNW for ; Thu, 1 Oct 2015 00:33:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57411B2B75 for ; Thu, 1 Oct 2015 00:33:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6FAC3101F; Thu, 1 Oct 2015 09:33:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4615h4UuioTf; Thu, 1 Oct 2015 09:33:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Oct 2015 09:33:48 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B031C20053; Thu, 1 Oct 2015 09:33:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zx5--8KV7s6a; Thu, 1 Oct 2015 09:33:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4594620055; Thu, 1 Oct 2015 09:33:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 892D63779AF3; Thu, 1 Oct 2015 09:33:46 +0200 (CEST) Date: Thu, 1 Oct 2015 09:33:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151001073346.GA27679@elstar.local> Mail-Followup-To: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org References: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <20150930135222.GA25888@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 07:33:53 -0000 On Thu, Oct 01, 2015 at 09:24:52AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote: > >> Hi Randy, > >> > >> thanks for the comments and proposed edits. Please see inline. > >> > >> Randy Presuhn writes: > >> > >> > Hi - > >> > > >> >>From: Ladislav Lhotka > >> >>Sent: Sep 29, 2015 7:07 AM > >> >>To: netmod@ietf.org > >> >>Subject: [netmod] 6020bis - anydata > >> >> > >> >>Hi, > >> >> > >> >>I propose to expand the text in Sec. 7.10 as follows: > >> >> > >> >>OLD > >> >> > >> >> The "anydata" statement is used to represent an unknown set of nodes > >> >> that can be modelled with YANG. An example of where this can be > >> >> useful is a list of received notifications, where the exact > >> >> notifications are not known as design time. > >> >> > >> >>NEW > >> >> > >> >> The "anydata" statement is used to represent an unknown set of nodes > >> >> that can be modelled with YANG but for which the data model doesn't > >> >> exist at module design time. > >> > > >> > "doesn't exist" would not be appropriate for the example you provide > >> > below. It would be incorrect if some of the notifications in your > >> > example had already been defined, even though "anydata" would still > >> > be necessary to handle others not yet defined. > >> > >> Would "doesn't exist or cannot be determined at module design time" be better? > >> > > > > What about this: > > > > The "anydata" statement is used to represent a set of nodes that can > > be modelled with YANG but for which the data model is not known at > > module design time. > > Fine by me. So here is an updated proposal: > > OLD > > The "anydata" statement is used to represent an unknown set of nodes > that can be modelled with YANG. An example of where this can be > useful is a list of received notifications, where the exact > notifications are not known as design time. > > NEW > > The "anydata" statement is used to represent an unknown set of nodes > that can be modelled with YANG but for which the data model is not > known at module design time. It is possible, though not required, for > the data model for "anydata" content to become known through protocol > signalling or other means that are outside the scope of this > document, as is the server and client behaviour. > > An example of where this can be useful is a list of received > notifications, where the exact notifications are not known at module > design time. > While the proposed new text is longer and provides more explanation, which problem is the new text fixing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 1 01:29:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4601B2BD2 for ; Thu, 1 Oct 2015 01:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Cas66oWAcR for ; Thu, 1 Oct 2015 01:29:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237D01B2BD0 for ; Thu, 1 Oct 2015 01:29:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E55FB767; Thu, 1 Oct 2015 10:29:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VB6NBrFe_svI; Thu, 1 Oct 2015 10:29:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Oct 2015 10:29:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA3A220053; Thu, 1 Oct 2015 10:29:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6Nz0wUyO1E_l; Thu, 1 Oct 2015 10:29:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 555E920055; Thu, 1 Oct 2015 10:29:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6FCD33779BBB; Thu, 1 Oct 2015 10:29:27 +0200 (CEST) Date: Thu, 1 Oct 2015 10:29:26 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20151001082925.GA27800@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:29:34 -0000 On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: > > Again, let's tackle a hard issue before tomorrow's interim meeting - this time the definition of "applied configuration": > > https://github.com/netmod-wg/opstate-reqs/issues/4 > > Currently, draft-chairs-netmod-opstate-reqs has this definition: > > o applied configuration - this data represents the state that the > network element is actually in, i.e., that which is currently > being run by particular software modules (e.g., the BGP daemon), > or other systems within the device (e.g., a secondary control- > plane, or line card). > I think the phrase "represents the state that the network element is actually in" is what we so far call operational state. I think what people mean with applied configuration is way more narrow. Perhaps you mean 'configuration state' instead of 'state'. This also applies to the definition of 'intended configuration'. So here is a potential rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt o intended configuration - this data represents the configuration state that the network operator intends the system to be in. This data is colloquially referred to as the 'configuration' of the system. o applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). This rewrite does not really address the questions that make up issue #4. But let me again state that often the component consuming configuration state is not able to remember whether a piece of its state originated from a configuration subsystem or something else. An interface often only knows the set of addresses it has and it does not know where the addresses originating from (a command line tool, a configuration subsystem, a dhcp daemon, ...). And in order to understand what a device is doing, it is necessary to look at all the state (addresses in the example) of a component (an interface in the example). I think it is a requirement that it is easy to retrieve all operational state of a component. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 1 01:48:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2436A1B2BFB for ; Thu, 1 Oct 2015 01:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q8uUL8yDIOt for ; Thu, 1 Oct 2015 01:48:40 -0700 (PDT) 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 9DBDE1B2BFD for ; Thu, 1 Oct 2015 01:48:39 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:951c:262:c23:b759] (unknown [IPv6:2001:718:1a02:1:951c:262:c23:b759]) by mail.nic.cz (Postfix) with ESMTPSA id 10854181B98; Thu, 1 Oct 2015 10:48:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443689318; bh=o25fejq1MmQ7xJ3Eesb7Gw5B97FYUnBSsTLqa9EiyGo=; h=From:Date:To; b=CeIArsDbi1ofIs905ox8Zp55ZWNf6bXvPoFuuAROkeq12zMXvJn8iqxuUYCQwFqTm Qo0zNoSdGtO9UV+Gyg4Zo9bJw/DZ9ts2vKT/dCu6+0L4PMLkTD0z/5TnZzbsqGvdQT y3q13Dzx+eXEaOtwR6Gkd9wPLCLnsXTvanFX3pqw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151001073346.GA27679@elstar.local> Date: Thu, 1 Oct 2015 10:48:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <755B4708-42E5-4BC6-BC68-67DC2C231315@nic.cz> References: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <20150930135222.GA25888@elstar.local> <20151001073346.GA27679@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:48:42 -0000 > On 01 Oct 2015, at 09:33, Juergen Schoenwaelder = wrote: >=20 > On Thu, Oct 01, 2015 at 09:24:52AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote: >>>> Hi Randy, >>>>=20 >>>> thanks for the comments and proposed edits. Please see inline. >>>>=20 >>>> Randy Presuhn writes: >>>>=20 >>>>> Hi - >>>>>=20 >>>>>> From: Ladislav Lhotka >>>>>> Sent: Sep 29, 2015 7:07 AM >>>>>> To: netmod@ietf.org >>>>>> Subject: [netmod] 6020bis - anydata >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I propose to expand the text in Sec. 7.10 as follows: >>>>>>=20 >>>>>> OLD >>>>>>=20 >>>>>> The "anydata" statement is used to represent an unknown set of = nodes >>>>>> that can be modelled with YANG. An example of where this can be >>>>>> useful is a list of received notifications, where the exact >>>>>> notifications are not known as design time. >>>>>>=20 >>>>>> NEW >>>>>>=20 >>>>>> The "anydata" statement is used to represent an unknown set of = nodes >>>>>> that can be modelled with YANG but for which the data model = doesn't >>>>>> exist at module design time. >>>>>=20 >>>>> "doesn't exist" would not be appropriate for the example you = provide >>>>> below. It would be incorrect if some of the notifications in your >>>>> example had already been defined, even though "anydata" would = still >>>>> be necessary to handle others not yet defined. >>>>=20 >>>> Would "doesn't exist or cannot be determined at module design time" = be better? >>>>=20 >>>=20 >>> What about this: >>>=20 >>> The "anydata" statement is used to represent a set of nodes that = can >>> be modelled with YANG but for which the data model is not known at >>> module design time. >>=20 >> Fine by me. So here is an updated proposal: >>=20 >> OLD >>=20 >> The "anydata" statement is used to represent an unknown set of = nodes >> that can be modelled with YANG. An example of where this can be >> useful is a list of received notifications, where the exact >> notifications are not known as design time. >>=20 >> NEW >>=20 >> The "anydata" statement is used to represent an unknown set of = nodes >> that can be modelled with YANG but for which the data model is not >> known at module design time. It is possible, though not required, = for >> the data model for "anydata" content to become known through = protocol >> signalling or other means that are outside the scope of this >> document, as is the server and client behaviour. >>=20 >> An example of where this can be useful is a list of received >> notifications, where the exact notifications are not known at = module >> design time. >>=20 >=20 > While the proposed new text is longer and provides more explanation, > which problem is the new text fixing? It helps to make an argument that including a similar text that you = proposed in the yang-json document is equally useless. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 1 02:37:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B921A1A67 for ; Thu, 1 Oct 2015 02:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHXLRYBktkZk for ; Thu, 1 Oct 2015 02:37:55 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350641A0AF1 for ; Thu, 1 Oct 2015 02:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3600; q=dns/txt; s=iport; t=1443692275; x=1444901875; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tBj9uhANacz+G97M6o2Lj52fQ1YMlUxQ8vUo5YDRjzw=; b=msoB1gJz640d7pOqkJBnIgdWvG4S9JcAhBvohirHr/pg8C1mzrFJUZLz F1BywWwJezW9SEFrN4yEohhE5DE+JcCIKGiXvnAGKOg/RuB7j6cT9hm5D b9LX4yjzqDTdJ8WaIv/4CmtzWkshHr0gu3nsD/bsx+R200nhFGyPfm4b8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBABZ/gxW/xbLJq1eg3vAY4JDgzYCgX8BAQEBAQGBC4QkAQEBAwE4QAYLCw4KCRYPCQMCAQIBRQYBDAgBAYgiCA3LZwEBAQEBAQEBAQEBAQEBAQEBARYEhnOEfoUUhCwBBIc+hnWHRoUWgm+FD4FQhzaOXoNvY4FuVoE/PYorAQEB X-IronPort-AV: E=Sophos;i="5.17,616,1437436800"; d="scan'208";a="605470488" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2015 09:37:51 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t919bphg005667; Thu, 1 Oct 2015 09:37:51 GMT To: Kent Watsen , "netmod@ietf.org" References: <20151001082925.GA27800@elstar.local> From: Robert Wilton Message-ID: <560CFEEF.7010001@cisco.com> Date: Thu, 1 Oct 2015 10:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151001082925.GA27800@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:37:57 -0000 Hi Juergen, On 01/10/2015 09:29, Juergen Schoenwaelder wrote: > On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: >> Again, let's tackle a hard issue before tomorrow's interim meeting - this time the definition of "applied configuration": >> >> https://github.com/netmod-wg/opstate-reqs/issues/4 >> >> Currently, draft-chairs-netmod-opstate-reqs has this definition: >> >> o applied configuration - this data represents the state that the >> network element is actually in, i.e., that which is currently >> being run by particular software modules (e.g., the BGP daemon), >> or other systems within the device (e.g., a secondary control- >> plane, or line card). >> > I think the phrase "represents the state that the network element is > actually in" is what we so far call operational state. I think what > people mean with applied configuration is way more narrow. Perhaps you > mean 'configuration state' instead of 'state'. This also applies to > the definition of 'intended configuration'. So here is a potential > rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt > > o intended configuration - this data represents the configuration > state that the network operator intends the system to be in. > This data is colloquially referred to as the 'configuration' of > the system. Is this the configuration that the operator sent to the device, or the configuration that the device has accepted? In normal circumstance these would be the same, but they would differ if the configuration wasn't semantically valid and hence rejected by the system. If your agree that it is the latter then would it be beneficial for the description to include it? E.g. perhaps something along the lines of: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. > > o applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). This text looks OK to me, although I wonder if it wouldn't be better to not have the examples of system components, but I don't mind if they remain. > > This rewrite does not really address the questions that make up issue > #4. I think that is OK. I don't see that the other points necessary need to be addressed in the description. I think that it would be sufficient if they are expressed as requirements (or non requirements). > But let me again state that often the component consuming > configuration state is not able to remember whether a piece of its > state originated from a configuration subsystem or something else. An > interface often only knows the set of addresses it has and it does not > know where the addresses originating from (a command line tool, a > configuration subsystem, a dhcp daemon, ...). And in order to > understand what a device is doing, it is necessary to look at all the > state (addresses in the example) of a component (an interface in the > example). I think it is a requirement that it is easy to retrieve all > operational state of a component. I agree. Thanks, Rob > > /js > From nobody Thu Oct 1 02:48:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527FA1A1A9A for ; Thu, 1 Oct 2015 02:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIv9lnLMF1Ck for ; Thu, 1 Oct 2015 02:48:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC2B1A1A97 for ; Thu, 1 Oct 2015 02:48:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85BCE1084; Thu, 1 Oct 2015 11:48:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7wLJ86eOeQk2; Thu, 1 Oct 2015 11:48:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Oct 2015 11:48:23 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EC9E20053; Thu, 1 Oct 2015 11:48:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VpRXSVpjTKWX; Thu, 1 Oct 2015 11:48:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F67D2004E; Thu, 1 Oct 2015 11:48:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 13E903779D21; Thu, 1 Oct 2015 11:48:22 +0200 (CEST) Date: Thu, 1 Oct 2015 11:48:22 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151001094822.GB27958@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" References: <20151001082925.GA27800@elstar.local> <560CFEEF.7010001@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560CFEEF.7010001@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:48:29 -0000 On Thu, Oct 01, 2015 at 10:37:51AM +0100, Robert Wilton wrote: > Hi Juergen, > > On 01/10/2015 09:29, Juergen Schoenwaelder wrote: > >On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: > >>Again, let's tackle a hard issue before tomorrow's interim meeting - this > >>time the definition of "applied configuration": > >> > >>https://github.com/netmod-wg/opstate-reqs/issues/4 > >> > >>Currently, draft-chairs-netmod-opstate-reqs has this definition: > >> > >> o applied configuration - this data represents the state that the > >> network element is actually in, i.e., that which is currently > >> being run by particular software modules (e.g., the BGP daemon), > >> or other systems within the device (e.g., a secondary control- > >> plane, or line card). > >> > >I think the phrase "represents the state that the network element is > >actually in" is what we so far call operational state. I think what > >people mean with applied configuration is way more narrow. Perhaps you > >mean 'configuration state' instead of 'state'. This also applies to > >the definition of 'intended configuration'. So here is a potential > >rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt > > > > o intended configuration - this data represents the configuration > > state that the network operator intends the system to be in. > > This data is colloquially referred to as the 'configuration' of > > the system. > > Is this the configuration that the operator sent to the device, or the > configuration that the device has accepted? In normal circumstance > these would be the same, but they would differ if the configuration > wasn't semantically valid and hence rejected by the system. > > If your agree that it is the latter then would it be beneficial for the > description to include it? > > E.g. perhaps something along the lines of: > > intended configuration - this data represents the configuration > state that the network operator intends the system to be in, and that > has been accepted by the system as valid configuration. This data is > colloquially referred to as the 'configuration' of the system. Yes, I silently assumed that the configuration has gone through validation. > > o applied configuration - this data represents the configuration > > state that the network element is actually in, i.e., the > > configuration state which is currently being being used by system > > components (e.g., control plane daemons, operating system > > kernels, line cards). > This text looks OK to me, although I wonder if it wouldn't be better to > not have the examples of system components, but I don't mind if they remain. The examples were there in the original text but I factored them out into text that went into parenthesis. I think it is good to include the examples since we do have an open debate what 'applied' really means - is something applied if the kernel knows about it or is something applied if the kernel has communicated it all the way to a line card and the ASICs finally have taken note of it? I agree this is a very grey area and we probably need to add text below the definition of the term 'applied configuration' that acknowledges that this is grey area and the definition of applied configuration is fuzzy here by design. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 1 02:50:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B31A1A9B for ; Thu, 1 Oct 2015 02:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2uX_qZvk0L6 for ; Thu, 1 Oct 2015 02:50:12 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9034F1A1A9A for ; Thu, 1 Oct 2015 02:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15360; q=dns/txt; s=iport; t=1443693011; x=1444902611; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=/SHRWTIZZSfPZr/kQ28fnXZxHt0lJKKZCRbGMAtGP98=; b=gqpI7CVT1tvKQXuMyrb+sSKwSTkxtTKBiZZFhzENBmnGS7EDe+AdafI1 W4soSZ8maePOYhDRCT3TDLE8cWZyPJ0IsCO65tuFmFqBjwBPCjQjVpahL sFPkVx26WTmEraxV8cm6fuzSZ5IQQ4CHHFVHxoClRwybP+uNWpIUy7OGG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CcBADzAA1W/xbLJq1eglqCD8VuAoF/AQEBAQEBgQuEJQEBBHgBEAsOCgkWBAQHCQMCAQIBNBEGDQYCAQGIKst1AQEBAQEBAQECAQEBAQEBAQEBAQEXhnOEfoRCSweELAWHPoZ1hBODM40UgVCHNooIhFaDb2OCRIE/PTOIMSWBIgEBAQ X-IronPort-AV: E=Sophos;i="5.17,616,1437436800"; d="scan'208,217";a="605470718" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2015 09:50:09 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t919o9rR008392; Thu, 1 Oct 2015 09:50:09 GMT To: Mahesh Jethanandani References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> From: Robert Wilton Message-ID: <560D01D1.5000607@cisco.com> Date: Thu, 1 Oct 2015 10:50:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090306090700020309080302" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:50:14 -0000 This is a multi-part message in MIME format. --------------090306090700020309080302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 01/10/2015 00:55, Mahesh Jethanandani wrote: > One comment. > >> On Sep 30, 2015, at 8:02 AM, Robert Wilton > > wrote: >> >> Hi Kent, >> >> Just some quick comments inline ... >> >> On 30/09/2015 15:31, Kent Watsen wrote: >>> [As a contributor] >>> >>> >>> I find that the term "system" is a bit ambiguous in this context. >>> It is talking about the NMS, the server, or both together? >>> >>> [KENT] I believe that we're talking about the NETCONF/RESTCONF/ >>> server, specifically in how it processes update requests. >>> >>> >>> Anyway, I've tried to define them relative to the configuration >>> operations being performed. >>> >>> [KENT] Perhaps these could be collapsed if we use the terms >>> "a/synchronous server" ? >> >> Personally, I think that defining the operations is arguably more >> useful because it is feasible that you could have a server that >> supports both sync and async operations and allows the client to >> choose which semantics should be used for a particular request. >> >> >>> >>> >>> Synchronous configuration operation - A configuration request that >>> the server applies synchronously with respect to the client >>> request. Before the server replies back to the client indicating >>> the success or failure of the operation it MUST semantically >>> validate the contents of the request and update the intended >>> configuration of the target datastore. If the request is to the >>> running datastore then the configuration change MUST also be applied >>> in the system before the server replies back to the client. The >>> reply to the client indicates whether there are any semantic errors >>> or system errors from applying the configuration change. >>> >>> >>> [KENT] This generally matches my understanding, but here are some >>> thoughts to improve it: >>> >>> 1. I think the language "semantically validate" would exclude an >>> ephemeral datastore. We could put a qualifier on it, but I think it >>> can be removed entirely as each datastore already has its own >>> semantics around how it processes update requests. >> >> My aim here is potentially tied to the definition of intended config, >> were I am suggesting that the system has to at least have been >> checked that the request is well formed and any YANG constraints in >> the data model have been met, before it is accepted as intended >> config, otherwise it would be rejected. >> >> >>> >>> 2. I like how you call out the running datastore, but it is somewhat >>> NETCONF-specific. How about something like "If the request impacts >>> the intended configuration (see term), then..." >> >> Yes your text is better and I agree that we should avoid making the >> description NETCONF specific at all. >> >>> >>> 3. "applied in the system" seems too open ended, how about this: >>> "...MUST also be propagated to and processed by the operational >>> components of the server before..." ??? >> >> So my aim here was to tie it back to the definition of "applied >> configuration", but this could probably be expressed in a more direct >> way, e.g. perhaps ".... MUST update the applied configuration in the >> system before the server replies …" > > If I understand this correctly, we are still talking about “applied > configuration” as configuration that has been written to > datastore/hardware/line card etc. It does not imply that anything has > come out of it, including whether the configuration is usable. That > operating configuration (and I just introduced another term) will be > reflected by derived state. > > Is that true? Yes. Rather than operating configuration I would perhaps say the "observable system behaviour is reflected by derived state". E.g. if you were to change the MTU of an interface to a different value (that was say incompatible with a peer device) then the "applied configuration" for the MTU leaf would only tell you whether or not that MTU was actively being used by the system. It wouldn't tell you that an ISIS session on that interface had gone down due to the MTU incompatibility. That could only be observed by the changing of the derived state representing the status of the ISIS session (or an alarm). Thanks, Rob --------------090306090700020309080302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 01/10/2015 00:55, Mahesh Jethanandani wrote:
One comment.

On Sep 30, 2015, at 8:02 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
[As a contributor]


I find that the term "system" is a bit ambiguous in this context.  It is talking about the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> server, specifically in how it processes update requests.


Anyway, I've tried to define them relative to the configuration operations being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous server" ?

Personally, I think that defining the operations is arguably more useful because it is feasible that you could have a server that supports both sync and async operations and allows the client to choose which semantics should be used for a particular request.




Synchronous configuration operation - A configuration request that the server applies synchronously with respect to the client request.  Before the server replies back to the client indicating the success or failure of the operation it MUST semantically validate the contents of the request and update the intended configuration of the target datastore.  If the request is to the running datastore then the configuration change MUST also be applied in the system before the server replies back to the client.  The reply to the client indicates whether there are any semantic errors or system errors from applying the configuration change.


[KENT]  This generally matches my understanding, but here are some thoughts to improve it:

1. I think the language "semantically validate" would exclude an ephemeral datastore.  We could put a qualifier on it, but I think it can be removed entirely as each datastore already has its own semantics around how it processes update requests.

My aim here is potentially tied to the definition of intended config, were I am suggesting that the system has to at least have been checked that the request is well formed and any YANG constraints in the data model have been met, before it is accepted as intended config, otherwise it would be rejected.



2. I like how you call out the running datastore, but it is somewhat NETCONF-specific.  How about something like "If the request impacts the intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the description NETCONF specific at all.


3. "applied in the system" seems too open ended, how about this:  "...MUST also be propagated to and processed by the operational components of the server before..." ???

So my aim here was to tie it back to the definition of "applied configuration", but this could probably be expressed in a more direct way, e.g. perhaps ".... MUST update the applied configuration in the system before the server replies …"

If I understand this correctly, we are still talking about “applied configuration” as configuration that has been written to datastore/hardware/line card etc. It does not imply that anything has come out of it, including whether the configuration is usable. That operating configuration (and I just introduced another term) will be reflected by derived state.

Is that true?
Yes.

Rather than operating configuration I would perhaps say the "observable system behaviour is reflected by derived state".

E.g. if you were to change the MTU of an interface to a different value (that was say incompatible with a peer device) then the "applied configuration" for the MTU leaf would only tell you whether or not that MTU was actively being used by the system.   It wouldn't tell you that an ISIS session on that interface had gone down due to the MTU incompatibility.  That could only be observed by the changing of the derived state representing the status of the ISIS session (or an alarm).

Thanks,
Rob

--------------090306090700020309080302-- From nobody Thu Oct 1 02:58:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866611A1AB5 for ; Thu, 1 Oct 2015 02:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t_hlqHoraKK for ; Thu, 1 Oct 2015 02:58:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894EE1A1AAA for ; Thu, 1 Oct 2015 02:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3860; q=dns/txt; s=iport; t=1443693521; x=1444903121; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1aPXtMj74xTJxl1bZ93iYSuBZyrJ8OfTZYL3z6if5+s=; b=VumdMzlnLaLyFxrqmYaswH7tHdyrZJ27CzpKTFr789rGeArmUbLLBvbW 61lMqTF4P91SgfkKzF1WatWW/uA4xWMhwiYrxxLBmjjEIaASgKnjg2VpZ ilxy2Xy8UdJSEzlK+tizWvV+0op3UOzAuabY3TWNurZwiVyGPnhd0BgTM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAQAFAw1W/xbLJq1eg3u+WgENgXuCQ4M2AoFrFAEBAQEBAQGBCoQkAQEBAwE4QAYLCw4KCRYPCQMCAQIBRQYBDAgBAYgiCA3LZwEBAQEBAQEBAQEBAQEBAQEBARYEhnOEfoUUhCwBBIc+hnWHRoUWh36BUIc2jl6Dbx8BAUKBblaBPz2IZCWBIgEBAQ X-IronPort-AV: E=Sophos;i="5.17,616,1437436800"; d="scan'208";a="630070947" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 01 Oct 2015 09:58:38 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t919wbKm015069; Thu, 1 Oct 2015 09:58:38 GMT To: Kent Watsen , "netmod@ietf.org" References: <20151001082925.GA27800@elstar.local> <560CFEEF.7010001@cisco.com> <20151001094822.GB27958@elstar.local> From: Robert Wilton Message-ID: <560D03CD.4090104@cisco.com> Date: Thu, 1 Oct 2015 10:58:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151001094822.GB27958@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:58:43 -0000 On 01/10/2015 10:48, Juergen Schoenwaelder wrote: > On Thu, Oct 01, 2015 at 10:37:51AM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> On 01/10/2015 09:29, Juergen Schoenwaelder wrote: >>> On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: >>>> Again, let's tackle a hard issue before tomorrow's interim meeting - this >>>> time the definition of "applied configuration": >>>> >>>> https://github.com/netmod-wg/opstate-reqs/issues/4 >>>> >>>> Currently, draft-chairs-netmod-opstate-reqs has this definition: >>>> >>>> o applied configuration - this data represents the state that the >>>> network element is actually in, i.e., that which is currently >>>> being run by particular software modules (e.g., the BGP daemon), >>>> or other systems within the device (e.g., a secondary control- >>>> plane, or line card). >>>> >>> I think the phrase "represents the state that the network element is >>> actually in" is what we so far call operational state. I think what >>> people mean with applied configuration is way more narrow. Perhaps you >>> mean 'configuration state' instead of 'state'. This also applies to >>> the definition of 'intended configuration'. So here is a potential >>> rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt >>> >>> o intended configuration - this data represents the configuration >>> state that the network operator intends the system to be in. >>> This data is colloquially referred to as the 'configuration' of >>> the system. >> Is this the configuration that the operator sent to the device, or the >> configuration that the device has accepted? In normal circumstance >> these would be the same, but they would differ if the configuration >> wasn't semantically valid and hence rejected by the system. >> >> If your agree that it is the latter then would it be beneficial for the >> description to include it? >> >> E.g. perhaps something along the lines of: >> >> intended configuration - this data represents the configuration >> state that the network operator intends the system to be in, and that >> has been accepted by the system as valid configuration. This data is >> colloquially referred to as the 'configuration' of the system. > Yes, I silently assumed that the configuration has gone through > validation. > > >>> o applied configuration - this data represents the configuration >>> state that the network element is actually in, i.e., the >>> configuration state which is currently being being used by system >>> components (e.g., control plane daemons, operating system >>> kernels, line cards). >> This text looks OK to me, although I wonder if it wouldn't be better to >> not have the examples of system components, but I don't mind if they remain. > The examples were there in the original text but I factored them out > into text that went into parenthesis. I think it is good to include > the examples since we do have an open debate what 'applied' really > means - is something applied if the kernel knows about it or is > something applied if the kernel has communicated it all the way to a > line card and the ASICs finally have taken note of it? > I agree this is > a very grey area and we probably need to add text below the definition > of the term 'applied configuration' that acknowledges that this is > grey area and the definition of applied configuration is fuzzy here by > design. I agree. The definition of applied configuration should be tight enough that it is sufficient to be useful to the operators, but fuzzy enough that it is pragmatically feasible for the wide range of devices to actually comply with the definition. Thanks, Rob > > /js > From nobody Thu Oct 1 04:00:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07111A1B76 for ; Thu, 1 Oct 2015 04:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 RgefU8Uojsl2 for ; Thu, 1 Oct 2015 04:00:36 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan29.extendcp.co.uk [176.32.228.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD461A1B71 for ; Thu, 1 Oct 2015 04:00:35 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan5.hi.local) by mailscan-g70.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZhbbD-00071Q-J3; Thu, 01 Oct 2015 12:00:31 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZhbbC-0006Is-O3; Thu, 01 Oct 2015 12:00:31 +0100 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152] helo=[IPv6:::ffff:192.168.1.127]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1ZhbbB-00042E-0h; Thu, 01 Oct 2015 12:00:29 +0100 MIME-Version: 1.0 To: Robert Wilton , Kent Watsen , "netmod@ietf.org" From: Jonathan Hansford Date: Thu, 1 Oct 2015 12:03:16 +0100 Importance: normal X-Priority: 3 In-Reply-To: <560CFEEF.7010001@cisco.com> References: <20151001082925.GA27800@elstar.local> <560CFEEF.7010001@cisco.com> Content-Type: multipart/alternative; boundary="_53B5C4F6-077F-45D0-817D-75F0EF5646A2_" X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Message-Id: Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 11:00:39 -0000 --_53B5C4F6-077F-45D0-817D-75F0EF5646A2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The definition of intended configuration makes no reference to YANG. The ne= twork operator may be using multiple methods to configure aspects of the sy= stem, some of which may not be reflected in the YANG model. For the purpose= s of these discussions, is the intended configuration just that defined usi= ng the YANG model or all intended configuration? From: Robert Wilton Sent: 01 October 2015 10:38 To: Kent Watsen;netmod@ietf.org Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl= ied configuration" Hi Juergen, On 01/10/2015 09:29, Juergen Schoenwaelder wrote: > On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: >> Again, let's tackle a hard issue before tomorrow's interim meeting - thi= s time the definition of "applied configuration": >> >> https://github.com/netmod-wg/opstate-reqs/issues/4 >> >> Currently, draft-chairs-netmod-opstate-reqs has this definition: >> >> o applied configuration - this data represents the state that the >> network element is actually in, i.e., that which is currently >> being run by particular software modules (e.g., the BGP daemon), >> or other systems within the device (e.g., a secondary control- >> plane, or line card). >> > I think the phrase "represents the state that the network element is > actually in" is what we so far call operational state. I think what > people mean with applied configuration is way more narrow. Perhaps you > mean 'configuration state' instead of 'state'. This also applies to > the definition of 'intended configuration'. So here is a potential > rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt > > o intended configuration - this data represents the configuration > state that the network operator intends the system to be in. > This data is colloquially referred to as the 'configuration' of > the system. Is this the configuration that the operator sent to the device, or the=20 configuration that the device has accepted? In normal circumstance=20 these would be the same, but they would differ if the configuration=20 wasn't semantically valid and hence rejected by the system. If your agree that it is the latter then would it be beneficial for the=20 description to include it? E.g. perhaps something along the lines of: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. > > o applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). This text looks OK to me, although I wonder if it wouldn't be better to=20 not have the examples of system components, but I don't mind if they remain= . > > This rewrite does not really address the questions that make up issue > #4. I think that is OK. I don't see that the other points necessary need to=20 be addressed in the description. I think that it would be sufficient if=20 they are expressed as requirements (or non requirements). > But let me again state that often the component consuming > configuration state is not able to remember whether a piece of its > state originated from a configuration subsystem or something else. An > interface often only knows the set of addresses it has and it does not > know where the addresses originating from (a command line tool, a > configuration subsystem, a dhcp daemon, ...). And in order to > understand what a device is doing, it is necessary to look at all the > state (addresses in the example) of a component (an interface in the > example). I think it is a requirement that it is easy to retrieve all > operational state of a component. I agree. Thanks, Rob > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_53B5C4F6-077F-45D0-817D-75F0EF5646A2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

The defin= ition of intended configuration makes no reference to YANG. The network ope= rator may be using multiple methods to configure aspects of the system, som= e of which may not be reflected in the YANG model. For the purposes of thes= e discussions, is the intended configuration just that defined using the YA= NG model or all intended configuration?

 

=  


From: Robert Wilton
Sent: 01 October 20= 15 10:38
To: Kent Watsen;netmod@ietf.org
Subject: Re: [= netmod] opstate-reqs #4: Provide a tighter definition of"applied confi= guration"

 

 = ;

Hi Juergen,

=  

On 01/10/2015 09:29, Juergen Scho= enwaelder wrote:

> On Wed, Sep 30, 2015 at 03:58= :56PM +0000, Kent Watsen wrote:

>> Again, let= 's tackle a hard issue before tomorrow's interim meeting - this time the de= finition of "applied configuration":

>= > 

>> https://github.com/n= etmod-wg/opstate-reqs/issues/4

>> <= /o:p>

>> Currently, draft-chairs-netmod-opsta= te-reqs has this definition:

>> 

>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 applie= d configuration - this data represents the state that the

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 network element i= s actually in, i.e., that which is currently

>&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 being run by particular softwa= re modules (e.g., the BGP daemon),

>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or other systems within the device (e.= g., a secondary control-

>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 plane, or line card).

>= > 

> I think the phrase "= ;represents the state that the network element is

&= gt; actually in" is what we so far call operational state. I think wha= t

> people mean with applied configuration is wa= y more narrow. Perhaps you

> mean 'configuration= state' instead of 'state'. This also applies to

&g= t; the definition of 'intended configuration'. So here is a potential

> rewrite of the definitions in draft-chairs-netmod-o= pstate-reqs-00.txt

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 o intended configuration - this = data represents the configuration

>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 state that the network operator intends the system= to be in.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= This data is colloquially referred to as the 'configuration' of

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the system.

 

Is this the confi= guration that the operator sent to the device, or the

configuration that the device has accepted?=C2=A0 In normal circumstanc= e

these would be the same, but they would differ i= f the configuration

wasn't semantically valid and = hence rejected by the system.

 

=

If your agree that it is the latter then would it be b= eneficial for the

description to include it?

 

E.g. perhaps s= omething along the lines of:

 

<= p class=3DMsoNormal>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0intended configuration -= this data represents the configuration

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 state that the network operator intends the system to= be in, and that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has= been accepted by the system as valid configuration.=C2=A0 This data is

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 colloquially referred t= o as the 'configuration' of the system.

 =

 

 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 o applied configuration - this da= ta represents the configuration

>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 state that the network element is actually in, i.e., = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config= uration state which is currently being being used by system

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 components (e.g., control= plane daemons, operating system

>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 kernels, line cards).

This= text looks OK to me, although I wonder if it wouldn't be better to

not have the examples of system components, but I don't m= ind if they remain.

 

> 

> This rewrit= e does not really address the questions that make up issue

> #4.

I think that is OK.=C2=A0 I don't = see that the other points necessary need to

be add= ressed in the description.=C2=A0 I think that it would be sufficient if

they are expressed as requirements (or non requiremen= ts).

 

>= But let me again state that often the component consuming

> configuration state is not able to remember whether a piece of= its

> state originated from a configuration sub= system or something else.=C2=A0 An

> interface o= ften only knows the set of addresses it has and it does not

> know where the addresses originating from (a command line too= l, a

> configuration subsystem, a dhcp daemon, .= ..). And in order to

> understand what a device = is doing, it is necessary to look at all the

> s= tate (addresses in the example) of a component (an interface in the

> example). I think it is a requirement that it is easy= to retrieve all

> operational state of a compon= ent.

I agree.

 

Thanks,

Rob

 

 

> 

> /= js

> 

 

___________________________________= ____________

netmod mailing list

netmod@ietf.org

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

 

 

= --_53B5C4F6-077F-45D0-817D-75F0EF5646A2_-- From nobody Thu Oct 1 05:12:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0D61A7023 for ; Thu, 1 Oct 2015 05:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evNRGHDhnItQ for ; Thu, 1 Oct 2015 05:12:50 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646C91A6F30 for ; Thu, 1 Oct 2015 05:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15928; q=dns/txt; s=iport; t=1443701569; x=1444911169; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1hynZXMmaw1iNs123asinzW0/PVuziwSdR/WYftykoY=; b=EsoghOtwOi59cq8UBXMNrtqXI81OkVJJYfpqC/TcXFYayqToEPjwkwB2 7xLwuYNhg1yebAhDKYmbXa4cz1dEz2Q3xmkf6jvqi1XCIHAT5lrj4DAbo oJwdaRNeTDltgM4ZDZ9LFL0moxsb3VenTzopRW+7wo0B4PYnSVU2oghNi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DzBADrIQ1W/xbLJq1eglqBIW6DK7xAAQmCQ4JsSgKBfAEBAQEBAYELhCQBAQEDAQEBASBLCgYLCQIRBAEBAQkWCwICCQMCAQIBFSgIBgEMBgIBAYgiCA2ZZp0slEwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhH6FFIJpgUMFhz6GdYQTgzOFFoJvhQ+BUIc2jl6Db2OBblaBPz0ziXgBAQE X-IronPort-AV: E=Sophos;i="5.17,617,1437436800"; d="scan'208,217";a="605473278" 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; 01 Oct 2015 12:12:47 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t91CCkw4004692; Thu, 1 Oct 2015 12:12:47 GMT To: Jonathan Hansford , Kent Watsen , "netmod@ietf.org" References: <20151001082925.GA27800@elstar.local> <560CFEEF.7010001@cisco.com> From: Robert Wilton Message-ID: <560D233E.9030309@cisco.com> Date: Thu, 1 Oct 2015 13:12:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070300020001000802050709" Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 12:12:52 -0000 This is a multi-part message in MIME format. --------------070300020001000802050709 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I would presume that all the definitions and requirements can only be in the context of YANG and associated management protocols, otherwise the scope is too broad. Thanks, Rob On 01/10/2015 12:03, Jonathan Hansford wrote: > > The definition of intended configuration makes no reference to YANG. > The network operator may be using multiple methods to configure > aspects of the system, some of which may not be reflected in the YANG > model. For the purposes of these discussions, is the intended > configuration just that defined using the YANG model or all intended > configuration? > > > *From: *Robert Wilton > *Sent: *01 October 2015 10:38 > *To: *Kent Watsen;netmod@ietf.org > *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter definition > of"applied configuration" > > Hi Juergen, > > On 01/10/2015 09:29, Juergen Schoenwaelder wrote: > > > On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: > > >> Again, let's tackle a hard issue before tomorrow's interim meeting > - this time the definition of "applied configuration": > > >> > > >> https://github.com/netmod-wg/opstate-reqs/issues/4 > > >> > > >> Currently, draft-chairs-netmod-opstate-reqs has this definition: > > >> > > >> o applied configuration - this data represents the state that the > > >> network element is actually in, i.e., that which is currently > > >> being run by particular software modules (e.g., the BGP daemon), > > >> or other systems within the device (e.g., a secondary control- > > >> plane, or line card). > > >> > > > I think the phrase "represents the state that the network element is > > > actually in" is what we so far call operational state. I think what > > > people mean with applied configuration is way more narrow. Perhaps you > > > mean 'configuration state' instead of 'state'. This also applies to > > > the definition of 'intended configuration'. So here is a potential > > > rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt > > > > > > o intended configuration - this data represents the configuration > > > state that the network operator intends the system to be in. > > > This data is colloquially referred to as the 'configuration' of > > > the system. > > Is this the configuration that the operator sent to the device, or the > > configuration that the device has accepted? In normal circumstance > > these would be the same, but they would differ if the configuration > > wasn't semantically valid and hence rejected by the system. > > If your agree that it is the latter then would it be beneficial for the > > description to include it? > > E.g. perhaps something along the lines of: > > intended configuration - this data represents the configuration > > state that the network operator intends the system to be in, and > that > > has been accepted by the system as valid configuration. This > data is > > colloquially referred to as the 'configuration' of the system. > > > > > > o applied configuration - this data represents the configuration > > > state that the network element is actually in, i.e., the > > > configuration state which is currently being being used by system > > > components (e.g., control plane daemons, operating system > > > kernels, line cards). > > This text looks OK to me, although I wonder if it wouldn't be better to > > not have the examples of system components, but I don't mind if they > remain. > > > > > > This rewrite does not really address the questions that make up issue > > > #4. > > I think that is OK. I don't see that the other points necessary need to > > be addressed in the description. I think that it would be sufficient if > > they are expressed as requirements (or non requirements). > > > But let me again state that often the component consuming > > > configuration state is not able to remember whether a piece of its > > > state originated from a configuration subsystem or something else. An > > > interface often only knows the set of addresses it has and it does not > > > know where the addresses originating from (a command line tool, a > > > configuration subsystem, a dhcp daemon, ...). And in order to > > > understand what a device is doing, it is necessary to look at all the > > > state (addresses in the example) of a component (an interface in the > > > example). I think it is a requirement that it is easy to retrieve all > > > operational state of a component. > > I agree. > > Thanks, > > Rob > > > > > > /js > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > --------------070300020001000802050709 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I would presume that all the definitions and requirements can only be in the context of YANG and associated management protocols, otherwise the scope is too broad.

Thanks,
Rob

On 01/10/2015 12:03, Jonathan Hansford wrote:

The definition of intended configuration makes no reference to YANG. The network operator may be using multiple methods to configure aspects of the system, some of which may not be reflected in the YANG model. For the purposes of these discussions, is the intended configuration just that defined using the YANG model or all intended configuration?

 

 


From: Robert Wilton
Sent: 01 October 2015 10:38
To: Kent Watsen;netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

 

 

Hi Juergen,

 

On 01/10/2015 09:29, Juergen Schoenwaelder wrote:

> On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote:

>> Again, let's tackle a hard issue before tomorrow's interim meeting - this time the definition of "applied configuration":

>> 

>> https://github.com/netmod-wg/opstate-reqs/issues/4

>> 

>> Currently, draft-chairs-netmod-opstate-reqs has this definition:

>> 

>>     o  applied configuration - this data represents the state that the

>>        network element is actually in, i.e., that which is currently

>>        being run by particular software modules (e.g., the BGP daemon),

>>        or other systems within the device (e.g., a secondary control-

>>        plane, or line card).

>> 

> I think the phrase "represents the state that the network element is

> actually in" is what we so far call operational state. I think what

> people mean with applied configuration is way more narrow. Perhaps you

> mean 'configuration state' instead of 'state'. This also applies to

> the definition of 'intended configuration'. So here is a potential

> rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt

> 

>     o intended configuration - this data represents the configuration

>       state that the network operator intends the system to be in.

>       This data is colloquially referred to as the 'configuration' of

>       the system.

 

Is this the configuration that the operator sent to the device, or the

configuration that the device has accepted?  In normal circumstance

these would be the same, but they would differ if the configuration

wasn't semantically valid and hence rejected by the system.

 

If your agree that it is the latter then would it be beneficial for the

description to include it?

 

E.g. perhaps something along the lines of:

 

      intended configuration - this data represents the configuration

      state that the network operator intends the system to be in, and that

      has been accepted by the system as valid configuration.  This data is

      colloquially referred to as the 'configuration' of the system.

 

 

 

> 

>     o applied configuration - this data represents the configuration

>       state that the network element is actually in, i.e., the

>       configuration state which is currently being being used by system

>       components (e.g., control plane daemons, operating system

>       kernels, line cards).

This text looks OK to me, although I wonder if it wouldn't be better to

not have the examples of system components, but I don't mind if they remain.

 

> 

> This rewrite does not really address the questions that make up issue

> #4.

I think that is OK.  I don't see that the other points necessary need to

be addressed in the description.  I think that it would be sufficient if

they are expressed as requirements (or non requirements).

 

> But let me again state that often the component consuming

> configuration state is not able to remember whether a piece of its

> state originated from a configuration subsystem or something else.  An

> interface often only knows the set of addresses it has and it does not

> know where the addresses originating from (a command line tool, a

> configuration subsystem, a dhcp daemon, ...). And in order to

> understand what a device is doing, it is necessary to look at all the

> state (addresses in the example) of a component (an interface in the

> example). I think it is a requirement that it is easy to retrieve all

> operational state of a component.

I agree.

 

Thanks,

Rob

 

 

> 

> /js

> 

 

_______________________________________________

netmod mailing list

netmod@ietf.org

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

 

 


--------------070300020001000802050709-- From nobody Thu Oct 1 05:16:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93431A86EC for ; Thu, 1 Oct 2015 05:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 mH-BamWczy2U for ; Thu, 1 Oct 2015 05:16:14 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan27.extendcp.co.uk [176.32.228.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355A71A7023 for ; Thu, 1 Oct 2015 05:16:14 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan0.hi.local) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZhcmQ-00062C-5D; Thu, 01 Oct 2015 13:16:10 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan0.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZhcmO-0008Dv-DJ; Thu, 01 Oct 2015 13:16:09 +0100 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152] helo=[IPv6:::ffff:192.168.1.127]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1ZhcmM-0001lh-Uc; Thu, 01 Oct 2015 13:16:07 +0100 MIME-Version: 1.0 To: Robert Wilton , Kent Watsen , "netmod@ietf.org" From: Jonathan Hansford Date: Thu, 1 Oct 2015 13:18:54 +0100 Importance: normal X-Priority: 3 In-Reply-To: <560D233E.9030309@cisco.com> References: <20151001082925.GA27800@elstar.local> <560CFEEF.7010001@cisco.com> <560D233E.9030309@cisco.com> Content-Type: multipart/alternative; boundary="_19A6A916-A21F-4C19-A06B-7A1EF6C19100_" X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Message-Id: Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appliedconfiguration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 12:16:16 -0000 --_19A6A916-A21F-4C19-A06B-7A1EF6C19100_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It would be useful if that clarification were included up front for clarity= . Jonathan From: Robert Wilton Sent: 01 October 2015 13:12 To: Jonathan Hansford;Kent Watsen;netmod@ietf.org Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl= iedconfiguration" I would presume that all the definitions and requirements can only be in th= e context of YANG and associated management protocols, otherwise the scope = is too broad. Thanks, Rob On 01/10/2015 12:03, Jonathan Hansford wrote: The definition of intended configuration makes no reference to YANG. The ne= twork operator may be using multiple methods to configure aspects of the sy= stem, some of which may not be reflected in the YANG model. For the purpose= s of these discussions, is the intended configuration just that defined usi= ng the YANG model or all intended configuration? =C2=A0 =C2=A0 From: Robert Wilton Sent: 01 October 2015 10:38 To: Kent Watsen;netmod@ietf.org Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl= ied configuration" =C2=A0 =C2=A0 Hi Juergen, =C2=A0 On 01/10/2015 09:29, Juergen Schoenwaelder wrote: > On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote: >> Again, let's tackle a hard issue before tomorrow's interim meeting - thi= s time the definition of "applied configuration": >>=C2=A0 >> https://github.com/netmod-wg/opstate-reqs/issues/4 >>=C2=A0 >> Currently, draft-chairs-netmod-opstate-reqs has this definition: >>=C2=A0 >>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 applied configuration - this data repres= ents the state that the >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 network element is actually in= , i.e., that which is currently >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 being run by particular softwa= re modules (e.g., the BGP daemon), >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or other systems within the de= vice (e.g., a secondary control- >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 plane, or line card). >>=C2=A0 > I think the phrase "represents the state that the network element is > actually in" is what we so far call operational state. I think what > people mean with applied configuration is way more narrow. Perhaps you > mean 'configuration state' instead of 'state'. This also applies to > the definition of 'intended configuration'. So here is a potential > rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt >=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 o intended configuration - this data represents t= he configuration >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state that the network operator inten= ds the system to be in. >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This data is colloquially referred to= as the 'configuration' of >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the system. =C2=A0 Is this the configuration that the operator sent to the device, or the=20 configuration that the device has accepted?=C2=A0 In normal circumstance=20 these would be the same, but they would differ if the configuration=20 wasn't semantically valid and hence rejected by the system. =C2=A0 If your agree that it is the latter then would it be beneficial for the=20 description to include it? =C2=A0 E.g. perhaps something along the lines of: =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0intended configuration - this data represent= s the configuration =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state that the network operator intends the = system to be in, and that =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has been accepted by the system as valid con= figuration.=C2=A0 This data is =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 colloquially referred to as the 'configurati= on' of the system. =C2=A0 =C2=A0 =C2=A0 >=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 o applied configuration - this data represents th= e configuration >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state that the network element is act= ually in, i.e., the >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configuration state which is currentl= y being being used by system >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 components (e.g., control plane daemo= ns, operating system >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kernels, line cards). This text looks OK to me, although I wonder if it wouldn't be better to=20 not have the examples of system components, but I don't mind if they remain= . =C2=A0 >=C2=A0 > This rewrite does not really address the questions that make up issue > #4. I think that is OK.=C2=A0 I don't see that the other points necessary need = to=20 be addressed in the description.=C2=A0 I think that it would be sufficient = if=20 they are expressed as requirements (or non requirements). =C2=A0 > But let me again state that often the component consuming > configuration state is not able to remember whether a piece of its > state originated from a configuration subsystem or something else.=C2=A0 = An > interface often only knows the set of addresses it has and it does not > know where the addresses originating from (a command line tool, a > configuration subsystem, a dhcp daemon, ...). And in order to > understand what a device is doing, it is necessary to look at all the > state (addresses in the example) of a component (an interface in the > example). I think it is a requirement that it is easy to retrieve all > operational state of a component. I agree. =C2=A0 Thanks, Rob =C2=A0 =C2=A0 >=C2=A0 > /js >=C2=A0 =C2=A0 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod =C2=A0 =C2=A0 --_19A6A916-A21F-4C19-A06B-7A1EF6C19100_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

It would be useful if that clarification were included= up front for clarity.

 

Jonathan

&n= bsp;

 

=


From: Robert Wilton
S= ent: 01 October 2015 13:12
To: Jonathan Hansford;Kent Watsen;= netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a = tighter definition of"appliedconfiguration"

 

 

I would presume that all the definitions and req= uirements can only be in the context of YANG and associated management prot= ocols, otherwise the scope is too broad.

Thanks,
Rob<= /span>

On 01/10/2015 12:03, Jonathan Hansford wrote:=

The definition of intended configuration makes no reference = to YANG. The network operator may be using multiple methods to configure as= pects of the system, some of which may not be reflected in the YANG model. = For the purposes of these discussions, is the intended configuration just t= hat defined using the YANG model or all intended configuration?<= /p>

 

 


From: Robert= Wilton
Sent: 01 October 2015 10:38
To: Kent Watsen;netmod@ietf.org
Subject: <= /b>Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appli= ed configuration"

 =

 

Hi Juergen,=

 

On 01/10/2015 09:29= , Juergen Schoenwaelder wrote:

> On Wed, Sep 30,= 2015 at 03:58:56PM +0000, Kent Watsen wrote:

>&= gt; Again, let's tackle a hard issue before tomorrow's interim meeting - th= is time the definition of "applied configuration":

>> 

>> https://github.com/netmod-wg/= opstate-reqs/issues/4

>> 

>> Currently, draft-chairs-netmod-opstate-reqs has this= definition:

>> 

>>     o  applied configuration - this data= represents the state that the

>>  =       network element is actually in, i.e., that w= hich is currently

>>    &= nbsp;   being run by particular software modules (e.g., the BGP d= aemon),

>>      = ;  or other systems within the device (e.g., a secondary control-

<= p class=3DMsoNormal>>>        plan= e, or line card).

>> 

> I think the phrase "represents the state that the network e= lement is

> actually in" is what we so far = call operational state. I think what

> people me= an with applied configuration is way more narrow. Perhaps you

> mean 'configuration state' instead of 'state'. This also = applies to

> the definition of 'intended configu= ration'. So here is a potential

> rewrite of the= definitions in draft-chairs-netmod-opstate-reqs-00.txt

> 

>     o inte= nded configuration - this data represents the configuration

>       state that the network op= erator intends the system to be in.

>  = ;     This data is colloquially referred to as the 'con= figuration' of

>     &n= bsp; the system.

 

Is this the configuration that the operator sent to the device, or = the

configuration that the device has accepted?&nb= sp; In normal circumstance

these would be the same= , but they would differ if the configuration

wasn'= t semantically valid and hence rejected by the system.

 

If your agree that it is the = latter then would it be beneficial for the

descrip= tion to include it?

 

E.g. perhaps something along the lines of:

 

     &nb= sp;intended configuration - this data represents the configuration

      state that the network opera= tor intends the system to be in, and that

 &nb= sp;    has been accepted by the system as valid configuratio= n.  This data is

     = ; colloquially referred to as the 'configuration' of the system.=

 

 

 

> =

>     o applied configurati= on - this data represents the configuration

>&nb= sp;      state that the network element is actuall= y in, i.e., the

>     &= nbsp; configuration state which is currently being being used by system

=

>       components (e= .g., control plane daemons, operating system

>&n= bsp;      kernels, line cards).

This text looks OK to me, although I wonder if it wouldn't be better = to

not have the examples of system components, but= I don't mind if they remain.

 

=

> 

> This rewrite d= oes not really address the questions that make up issue

> #4.

I think that is OK.  I don't see= that the other points necessary need to

be addres= sed in the description.  I think that it would be sufficient if

they are expressed as requirements (or non requirements)= .

 

> Bu= t let me again state that often the component consuming

> configuration state is not able to remember whether a piece of it= s

> state originated from a configuration subsys= tem or something else.  An

> interface ofte= n only knows the set of addresses it has and it does not

> know where the addresses originating from (a command line tool, = a

> configuration subsystem, a dhcp daemon, ...)= . And in order to

> understand what a device is = doing, it is necessary to look at all the

> stat= e (addresses in the example) of a component (an interface in the

> example). I think it is a requirement that it is easy to= retrieve all

> operational state of a component= .

I agree.

 = ;

Thanks,

Rob

 

 

<= p class=3DMsoNormal>> 

> /js

> 

 

_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/lis= tinfo/netmod

 

 

 

 

 

= --_19A6A916-A21F-4C19-A06B-7A1EF6C19100_-- From nobody Thu Oct 1 05:27:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699951ACDF9 for ; Thu, 1 Oct 2015 05:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIVqrNBLJ3Dp for ; Thu, 1 Oct 2015 05:27:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E370E1ACCF8 for ; Thu, 1 Oct 2015 05:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12179; q=dns/txt; s=iport; t=1443702433; x=1444912033; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=yTKwOjPPB0yCgc+K5kwipO82nPcYQKJ1vW8Gkcy4wP4=; b=hNHmvC28NFtdSalgWHecPQ+V48zUtkFfCs3cwhFIceTVhNUF84EwyOQI fmgoUVJ0fvbF+OX4IpvyPAAtG3MTEs3BHKSoNDCmahxm3Owtlc7E69ilc VXGSzrycjrUo6phL3osmTk5/uS/EnFQtIIkwGqGwvyBXPeB5914jDISUR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBABVJQ1W/xbLJq1eglqBIW6/awEJgkOCbEoCgX0BAQEBAQGBC4QkAQEBAwEBAQFrEAsLDgoJJQ8CFjAGAQwGAgEBiCIIDctdAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZzhH6FFIQsBZV5hRaHfoFQhDaDACOSKmOCRIE/PTOJeAEBAQ X-IronPort-AV: E=Sophos;i="5.17,617,1437436800"; d="scan'208,217";a="605473509" 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; 01 Oct 2015 12:27:11 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t91CRAKK021859; Thu, 1 Oct 2015 12:27:10 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <560D269E.30002@cisco.com> Date: Thu, 1 Oct 2015 13:27:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040507070400010401020101" Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 12:27:15 -0000 This is a multi-part message in MIME format. --------------040507070400010401020101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 30/09/2015 16:58, Kent Watsen wrote: > > Again, let's tackle a hard issue before tomorrow's interim meeting – > this time the definition of "applied configuration": > > https://github.com/netmod-wg/opstate-reqs/issues/4 > > Currently, draft-chairs-netmod-opstate-reqs has this definition: > > o applied configuration - this data represents the state that the > network element is actually in, i.e., that which is currently > being run by particular software modules (e.g., the BGP daemon), > or other systems within the device (e.g., a secondary control- > plane, or line card). > > But, as Robert states in the issue: > > The definition of "applied configuration" is slightly vague, and there > seems to be multiple interpretations of it on the WG alias, and > hence a tighter specification of it would be useful. > Specifically for these three points: > In particular: > > - does it include support for templating (as per > openconfig-netmod-opstate-01 section 7.3.)? > - is it allowed to represent system created objects that have no > corresponding configuration? Requirement 1.D states D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. So, if this requirement statement stands as being valid (which I think it should) then that would imply that the answer for both the two issues above must be "no". The only question would be whether these need to be explicitly listed out? > - how does it relate to the state of the system after a > equivalent synchronous config commit (if at all)? Again, I think that definition of requirement 1.D, along with the proposed definition of synchronous configuration operation vs asynchronous configuration operation, will provide a sufficient answer to this question. I.e. that the state of the system after an asynchronous config operation must, when fully synchronized, be the same as the state of the system after an equivalent synchronous configuration operation completes and replies back. Thanks, Rob > > > Already Mahesh and Einar have posted comments on the GitHub issue > tracker. Please first read the comments posted there and then > continue the discussion here on the mailing list (not on the GitHub > issue tracker). > > PS: This issue is highly related to issue #5, which was also just > opened for discussion on the mailing list. > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------040507070400010401020101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 30/09/2015 16:58, Kent Watsen wrote:

Again, let's tackle a hard issue before tomorrow's interim meeting – this time the definition of "applied configuration":


Currently, draft-chairs-netmod-opstate-reqs has this definition:

   o  applied configuration - this data represents the state that the
      network element is actually in, i.e., that which is currently
      being run by particular software modules (e.g., the BGP daemon),
      or other systems within the device (e.g., a secondary control-
      plane, or line card).

But, as Robert states in the issue:

    The definition of "applied configuration" is slightly vague, and there
    seems to be multiple interpretations of it on the WG alias, and 
    hence a tighter specification of it would be useful.


Specifically for these three points:

    In particular:

      - does it include support for templating (as per openconfig-netmod-opstate-01 section 7.3.)?
      - is it allowed to represent system created objects that have no corresponding configuration?

Requirement 1.D states
     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

So, if this requirement statement stands as being valid (which I think it should) then that would imply that the answer for both the two issues above must be "no".  The only question would be whether these need to be explicitly listed out?


      - how does it relate to the state of the system after a equivalent synchronous config commit (if at all)?

Again, I think that definition of requirement 1.D, along with the proposed definition of synchronous configuration operation vs asynchronous configuration operation, will provide a sufficient answer to this question.  I.e. that the state of the system after an asynchronous config operation must, when fully synchronized, be the same as the state of the system after an equivalent synchronous configuration operation completes and replies back.

Thanks,
Rob




Already Mahesh and Einar have posted comments on the GitHub issue tracker.   Please first read the comments posted there and then continue the discussion here on the mailing list (not on the GitHub issue tracker).

PS: This issue is highly related to issue #5, which was also just opened for discussion on the mailing list.

Thanks,
Kent



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

--------------040507070400010401020101-- From nobody Thu Oct 1 05:51:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025891B2C7D for ; Thu, 1 Oct 2015 05:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5l9a009hOKy for ; Thu, 1 Oct 2015 05:51:10 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F151B2C7B for ; Thu, 1 Oct 2015 05:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1443703780; bh=SPIrEFBDfTK9vMTB48cVASy+kIjJqFe6Wrpl0VAooIc=; h=Subject:From:In-Reply-To:Date:References:To; b=LfOfdn9b4MUyFqhxr8Tqaq+1iaDYD1CX0E7BUd61tV5+g35gaBcEDtyKlDp7BkplD ZCJdfLETsQu3w7yxfIhB/DdKUMC14LHHFpnJy2UXrfffXx03E2aVnXHXnTazVz0MO0 RXKonbOaBGVNta24VkkDfPqK9H1Xo1R/a+vtaW4s= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com> Date: Thu, 1 Oct 2015 08:51:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CA99B60-931A-4EF2-9E77-2AD5A381931F@lucidvision.com> References: <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com> To: netmod WG X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 139, in=1723, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: Re: [netmod] Thursday Interim Meeting Agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 12:51:12 -0000 Sorry to reply to my own message, but I wanted to add one other = ask for today=E2=80=99s interim meeting. I thought this was obvious but some just pointed out that we should ask = that because of the lack of cross-posting of the issue tracker on GitHub, that people be asked to = explicitly visit and review the discussions there around the various issues so that we are prepared = to close down each issue today. I will not cross-post the issue discussions, but the link is = posted below so please go there ahead of the meeting later. Thanks! =E2=80=94Tom > On Sep 30, 2015:10:54 AM, at 10:54 AM, Nadeau Thomas = wrote: >=20 >=20 > After discussing a bit more with Kent, we wanted to slightly = amend=20 > the agenda for tomorrow to first start out with trying to wrap up the > discussion around the requirements. We will review the issues=20 > as they are listed on the NETMOD Github issue tracker and try to > come to conclusions about the open issues: >=20 > https://github.com/netmod-wg/opstate-reqs/issues >=20 > =E2=80=94Tom >=20 >=20 >=20 >> On Sep 29, 2015:3:53 PM, at 3:53 PM, Nadeau Thomas = wrote: >>=20 >>=20 >> After going over the plan with Kent, we would like to continue = the agenda from the >> last interim meeting on Thursday. That is to say, Kent will continue = with the comparison >> of solutions. =46rom last time and in parallel with this, the WG = discussion around the requirements=20 >> seems to be converging on a detailed level of refinement of the = requirements. We will >> recap the status here and goals. >>=20 >> The details of the meeting are here: >>=20 >>=20 >> The NETCONF Data Modeling Language (netmod) Working Group will hold a = virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am = PDT; 2pm GMT). >>=20 >> The title is =E2=80=9COpenconfig Solutions Discussion (continued)=E2=80= =9D. >>=20 >> The WebEx is: >>=20 >> Meeting number:640 686 530 >> Meeting password:1234 >> Audio connection: >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 640 686 530 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dmf12aa8d28a159614cb415f2f32dcbebf= >>=20 >>=20 >>=20 >> --Tom (as WG co-chair) >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 1 06:35:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE1D1A00BD for ; Thu, 1 Oct 2015 06:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkS1kakHWEeD for ; Thu, 1 Oct 2015 06:34:59 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E9A671A00B1 for ; Thu, 1 Oct 2015 06:34:58 -0700 (PDT) Received: (qmail 27807 invoked by uid 0); 1 Oct 2015 13:34:57 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 1 Oct 2015 13:34:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Pvan1r0032SSUrH01vaqrv; Thu, 01 Oct 2015 13:34:55 -0600 X-Authority-Analysis: v=2.1 cv=Zs1+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=5lJygRwiOn0A:10 a=T0ZuanxOAAAA:8 a=NEAV23lmAAAA:8 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=uxPYI2R_zt7Yl4oMbNgA:9 a=m35iNy4-f8nAmZKM:21 a=sXYvhs289S_ld8tD:21 a=QEXdDO2ut3YA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=9uUzcS5Nrb8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=obVw0vU7pUIAUPQ7gSEEXfuQZZlO6vRznTJVjRVlSnU=; b=U624uuNgZQI+XjLDhyR5UfTCJJG7Xq0ModS1KFUJsKQZuvz3w5RAiXpatIMnTPYCs4OTGPfHeJ6jykLxTqnFyga8d1Jd5nWrdT5E9TWqT3omGPVRD2RSq2CLOXfoQoxv; Received: from box313.bluehost.com ([69.89.31.113]:51852 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zhe0W-0006zc-GT; Thu, 01 Oct 2015 07:34:48 -0600 To: Nadeau Thomas , netmod WG References: <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com> <6CA99B60-931A-4EF2-9E77-2AD5A381931F@lucidvision.com> From: Lou Berger Message-ID: <560D3675.10403@labn.net> Date: Thu, 1 Oct 2015 09:34:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <6CA99B60-931A-4EF2-9E77-2AD5A381931F@lucidvision.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Thursday Interim Meeting Agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 13:35:00 -0000 Hi Tom, Not to push, but I'm still on clear where the requirements stand. Of the 7 requirements listed in the chairs requirements document, which do you believe have outstanding *consensus* issues and which do you think have been no issues? Is it fair to state that the requirements without issues reflect WG consensus? Thanks, Lou On 10/01/2015 08:51 AM, Nadeau Thomas wrote: > > Sorry to reply to my own message, but I wanted to add one other ask for today’s interim meeting. > I thought this was obvious but some just pointed out that we should ask that because of the lack of > cross-posting of the issue tracker on GitHub, that people be asked to explicitly visit and review > the discussions there around the various issues so that we are prepared to close down each issue > today. I will not cross-post the issue discussions, but the link is posted below so please go there > ahead of the meeting later. > > Thanks! > > —Tom > > >> On Sep 30, 2015:10:54 AM, at 10:54 AM, Nadeau Thomas wrote: >> >> >> After discussing a bit more with Kent, we wanted to slightly amend >> the agenda for tomorrow to first start out with trying to wrap up the >> discussion around the requirements. We will review the issues >> as they are listed on the NETMOD Github issue tracker and try to >> come to conclusions about the open issues: >> >> https://github.com/netmod-wg/opstate-reqs/issues >> >> —Tom >> >> >> >>> On Sep 29, 2015:3:53 PM, at 3:53 PM, Nadeau Thomas wrote: >>> >>> >>> After going over the plan with Kent, we would like to continue the agenda from the >>> last interim meeting on Thursday. That is to say, Kent will continue with the comparison >>> of solutions. From last time and in parallel with this, the WG discussion around the requirements >>> seems to be converging on a detailed level of refinement of the requirements. We will >>> recap the status here and goals. >>> >>> The details of the meeting are here: >>> >>> >>> The NETCONF Data Modeling Language (netmod) Working Group will hold a virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am PDT; 2pm GMT). >>> >>> The title is “Openconfig Solutions Discussion (continued)”. >>> >>> The WebEx is: >>> >>> Meeting number:640 686 530 >>> Meeting password:1234 >>> Audio connection: >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> Access code: 640 686 530 >>> Meeting link: https://ietf.webex.com/ietf/j.php?MTID=mf12aa8d28a159614cb415f2f32dcbebf >>> >>> >>> >>> --Tom (as WG co-chair) >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Oct 1 06:41:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6281A0173 for ; Thu, 1 Oct 2015 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3zjQSyDs0P9 for ; Thu, 1 Oct 2015 06:41:26 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CCC1A0161 for ; Thu, 1 Oct 2015 06:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7014; q=dns/txt; s=iport; t=1443706886; x=1444916486; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nfDXnbhEUDj9+rYFdtbW8WAVp9x9RHayMpwZJI2Sf/I=; b=Nzpwdya1rFtWLmcbHb1UrtqEQ8BCvHReA9WyZ9aG7QwT9LnlzTKKNMPm o6vXFRu8Rp4ua+AqwD8M+pnJajK1I51TuxwVHF63V12sCVLw11ya3T7uE 67QFurnjz6o5D+4RYAt4e3txu4kOs/+GL7Jtc6LG+PodJbncaEydd4fj8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKAQD0Ng1W/xbLJq1eglqBIW69bQENgXEBCYUvSgKBaRQBAQEBAQEBgQqEJQEBBAEBAWsKEQsOExYECwkDAgECARUwBgEMBgIBAYgqDctmAQEBAQEBAQEBAQEBAQEBAQEBFgSGc4N4gQaFFIQsAQSVeYUWh36BUIQ2gwAjkiofAQFCgkSBQDwziXgBAQE X-IronPort-AV: E=Sophos;i="5.17,617,1437436800"; d="scan'208,217";a="630074880" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 01 Oct 2015 13:41:23 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t91DfLP3006363; Thu, 1 Oct 2015 13:41:21 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Benoit Claise Message-ID: <560D3801.4050706@cisco.com> Date: Thu, 1 Oct 2015 15:41:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080604080308030008060803" Archived-At: Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 13:41:28 -0000 This is a multi-part message in MIME format. --------------080604080308030008060803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, Reading the discussion the issue 5, which is about C. The data model for the applied configuration is the same as the data model for the intended configuration (same leaves) .... and the discussion at https://github.com/netmod-wg/opstate-reqs/issues/5, I wonder if the intent behind that requirement is not what Phil Shafer mentioned (see post "opstate-reqs: terminology"): Would it be better to think of these values in three sets? A) values given explicitly by the user (== IC == running config) B) current values which use organization identical to (A) C) current values which are not organized identical to (A) I think the real key is that values which_can_ be organized by the data models used in (A)_should_ use identifical organization in (B). When I read openconfig, that seems to be their real requirement. It would be great if openconfig people could express their opinion. Regards, Benoit, as individual contributor, hopefully helping to make progress here > > It's time to tackle another issue, just before tomorrow's meeting, and > this time I'm picking a hard one: > > https://github.com/netmod-wg/opstate-reqs/issues/5 > > Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the > GitHub issue tracker. Please first read the comments posted there > and then continue the discussion here on the mailing list (not on the > GitHub issue tracker). > > Note that this issue is closely tied to the definition of "applied > configuration", which is exactly what issue #4 regards > (https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh > and Einar have posted comments on already. As these two issues (#4 > and #5) are so highly related, I'm going to simultaneously open the > other issue for discussion now as well. > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------080604080308030008060803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

Reading the discussion the issue 5, which is about

C. The data model for the applied configuration is the same as
the data model for the intended configuration (same leaves)
.... and the discussion at https://github.com/netmod-wg/opstate-reqs/issues/5, I wonder if the intent behind that requirement is not what Phil Shafer mentioned (see post "opstate-reqs: terminology"): 
Would it be better to think of these values in three sets?

A) values given explicitly by the user (== IC == running config)
B) current values which use organization identical to (A)
C) current values which are not organized identical to (A)

I think the real key is that values which _can_ be organized by the
data models used in (A) _should_ use identifical organization in (B).
When I read openconfig, that seems to be their real requirement.
It would be great if openconfig people could express their opinion.

Regards, Benoit, as individual contributor, hopefully helping to make progress here

It's time to tackle another issue, just before tomorrow's meeting, and this time I'm picking a hard one:


Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub issue tracker.    Please first read the comments posted there and then continue the discussion here on the mailing list (not on the GitHub issue tracker).

Note that this issue is closely tied to the definition of "applied configuration", which is exactly what issue #4 regards (https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh and Einar have posted comments on already.   As these two issues (#4 and #5) are so highly related, I'm going to simultaneously open the other issue for discussion now as well.

Thanks,
Kent



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

--------------080604080308030008060803-- From nobody Thu Oct 1 10:01:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3AE1A92B4 for ; Thu, 1 Oct 2015 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsbjFWHuLD3O for ; Thu, 1 Oct 2015 10:01:56 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F941B2DD6 for ; Thu, 1 Oct 2015 10:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1443718915; x=1444928515; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=7CFvvGIb2vkz01+7pBnFHmsAJz525/ysMqWKQO/IhWs=; b=W7Owv5HEVbmDQfAGxTBKZX8d87GoUz+FyJAyvJSRxqYMFrKkovgLPpF0 8r9iJp/Z3pUpNvaevlCm2vJrLkTHZIPteoDDM05TmbYBoOlmnroMXjOTG MYythcloJ0pcTySgw5g9kUkbGHiE9RlbET9MdYPsRlRpYteJBwpYcoyro Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DoBACqZQ1W/xbLJq1eiBTERwEBAQEBAYEAC4ROFUA2AgUWCwILAwIBAgFLDQgBAYgqp0+Pa5REAQEBBwIBH4EihVGMe4FDAQSHM4cAh0aNFIkGkk1jgkSBPz2KKwEBAQ X-IronPort-AV: E=Sophos;i="5.17,618,1437436800"; d="scan'208";a="607358339" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Oct 2015 17:01:53 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t91H1rn6010305 for ; Thu, 1 Oct 2015 17:01:53 GMT From: Robert Wilton To: "netmod@ietf.org" Message-ID: <560D6701.5030807@cisco.com> Date: Thu, 1 Oct 2015 18:01:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 17:01:57 -0000 To clarify what I failed to eloquently express in the interim meeting. I propose changing the text for requirement 1.D. This also removes the need to define what fully synchronized means. Old text for 1.D D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. Proposed text for 1.D: D. When the configuration change for any intended configuration leaf has been successfully applied to the system (i.e. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration leaf must match the intended configuration leaf. Rob From nobody Thu Oct 1 12:13:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DCA1B2E39 for ; Thu, 1 Oct 2015 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_BtLsL7anfQ for ; Thu, 1 Oct 2015 12:13:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61B1A88DE for ; Thu, 1 Oct 2015 12:13:52 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id B201E1AE074A; Thu, 1 Oct 2015 21:13:50 +0200 (CEST) Date: Thu, 01 Oct 2015 21:14:56 +0200 (CEST) Message-Id: <20151001.211456.179704460111267852.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <560D6701.5030807@cisco.com> References: <560D6701.5030807@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 19:13:54 -0000 Robert Wilton wrote: > To clarify what I failed to eloquently express in the interim meeting. > > I propose changing the text for requirement 1.D. This also removes the > need to define what fully synchronized means. > > > Old text for 1.D > D. For asynchronous systems, when fully synchronized, the data > in the applied configuration is the same as the data in the > intended configuration. > > > Proposed text for 1.D: > D. When the configuration change for any intended > configuration leaf has been successfully applied to the > system (i.e. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding applied > configuration leaf must match the intended configuration > leaf. I think this text is better. I suggest s/leaf/node/ in order to cover also lists, leaf-lists, and p-containers. /martin From nobody Thu Oct 1 15:27:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06C21A8AB2 for ; Thu, 1 Oct 2015 15:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wXUqzEaw5bJG for ; Thu, 1 Oct 2015 15:27:41 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 90ADF1A8AAA for ; Thu, 1 Oct 2015 15:27:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AargAdRfbvyYTsqURty3BmBD6Q1qHuO6tiHrAkl4x8zu4EbiJ0v5tqq/E/E4cYG9; 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.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZhmK7-0000bF-GH for netmod@ietf.org; Thu, 01 Oct 2015 18:27:35 -0400 Received: from 76.254.51.194 by webmail.earthlink.net with HTTP; Thu, 1 Oct 2015 18:27:35 -0400 Message-ID: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Thu, 1 Oct 2015 15:27:35 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed83e984cd8c9ab804634461f2188d3505350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Archived-At: Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:27:43 -0000 Hi - >From: Robert Wilton >Sent: Oct 1, 2015 10:01 AM >To: "netmod@ietf.org" >Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" > >To clarify what I failed to eloquently express in the interim meeting. > >I propose changing the text for requirement 1.D. This also removes the >need to define what fully synchronized means. > > >Old text for 1.D > D. For asynchronous systems, when fully synchronized, the data > in the applied configuration is the same as the data in the > intended configuration. > > >Proposed text for 1.D: > D. When the configuration change for any intended > configuration leaf has been successfully applied to the > system (i.e. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding applied > configuration leaf must match the intended configuration > leaf. Are "not failed" and "deferred due to absent hardware" the *only* possibilities? If not, then the "i.e." needs to be replaced with an "e.g." Randy From nobody Thu Oct 1 16:05:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB41A9039 for ; Thu, 1 Oct 2015 16:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ttUAQUyCJz_1 for ; Thu, 1 Oct 2015 16:05:32 -0700 (PDT) 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 EDFB21A9035 for ; Thu, 1 Oct 2015 16:05:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=H3QmEoVYTB98/yooqPePntrrcevcpPVZmI6pf6nnKF8KSYi8lckXbyespEu4nCmv; 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.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zhmuf-0005IV-2D for netmod@ietf.org; Thu, 01 Oct 2015 19:05:21 -0400 Received: from 76.254.51.194 by webmail.earthlink.net with HTTP; Thu, 1 Oct 2015 19:05:20 -0400 Message-ID: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Thu, 1 Oct 2015 16:05:20 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed24490d0c7f85e8a86dad80ddaa06442a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Archived-At: Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 23:05:33 -0000 Hi - >From: Ladislav Lhotka >Sent: Oct 1, 2015 12:24 AM >To: Juergen Schoenwaelder >Cc: Randy Presuhn , netmod@ietf.org >Subject: Re: [netmod] 6020bis - anydata ... >Fine by me. So here is an updated proposal: > >OLD > > The "anydata" statement is used to represent an unknown set of nodes > that can be modelled with YANG. An example of where this can be > useful is a list of received notifications, where the exact > notifications are not known as design time. > >NEW > > The "anydata" statement is used to represent an unknown set of nodes > that can be modelled with YANG but for which the data model is not > known at module design time. It is possible, though not required, for s/know/known/ > the data model for "anydata" content to become known through protocol > signalling or other means that are outside the scope of this > document, as is the server and client behaviour. I'd end the sentence at "document." The rest of the sentence doesn't really add anything. There's still a big lump under the carpet, but no one else appears concerned about it, so I'll desist from further comment. Randy From nobody Fri Oct 2 01:43:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0996E1ACEBF for ; Fri, 2 Oct 2015 01:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYAyihVlBiPA for ; Fri, 2 Oct 2015 01:43:25 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F6A1ACEBE for ; Fri, 2 Oct 2015 01:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1364; q=dns/txt; s=iport; t=1443775405; x=1444985005; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6SWcAtO2xnc4wHs+y73t963ODOsSNaBlCg5vmZuDiNs=; b=lcU0xrb2zKWAWxCN9dtAufN8lUsVEueELH/jtFjfXiVjLQvSCSu7VmqW siWRJyrU7xMc/w96Jbf/P3kRNjA0SKEWCu5lU9MOmgbno4+fGScESbvH5 sq3+EMTu5Xr1lmZNp1uOO0CYPQbUqMeC/G5m8g+Gh+KHNCZ08vcTsNUoL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DIAQCBQg5W/xbLJq1ehGm9egENh3QCgW4UAQEBAQEBAYEKhCUBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNBgIBAYgqy30BAQEBAQEBAQEBAQEBAQEBARuGc4R+hQ0HhCwBBIc0hwKHRogGhRCJC5JVHwEBQoJEgT89M4l4AQEB X-IronPort-AV: E=Sophos;i="5.17,622,1437436800"; d="scan'208";a="611972049" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Oct 2015 08:43:21 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t928hKtn004931; Fri, 2 Oct 2015 08:43:20 GMT To: Martin Bjorklund References: <560D6701.5030807@cisco.com> <20151001.211456.179704460111267852.mbj@tail-f.com> From: Robert Wilton Message-ID: <560E43A7.2060303@cisco.com> Date: Fri, 2 Oct 2015 09:43:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151001.211456.179704460111267852.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 08:43:27 -0000 On 01/10/2015 20:14, Martin Bjorklund wrote: > Robert Wilton wrote: >> To clarify what I failed to eloquently express in the interim meeting. >> >> I propose changing the text for requirement 1.D. This also removes the >> need to define what fully synchronized means. >> >> >> Old text for 1.D >> D. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. >> >> >> Proposed text for 1.D: >> D. When the configuration change for any intended >> configuration leaf has been successfully applied to the >> system (i.e. not failed, nor deferred due to absent hardware) >> then the existence and value of the corresponding applied >> configuration leaf must match the intended configuration >> leaf. > I think this text is better. I suggest s/leaf/node/ in order to cover > also lists, leaf-lists, and p-containers. Agreed. I had originally written it using node but changed it to leaf to because of the the text for 1.C: C. The data model for the applied configuration is the same as the data model for the intended configuration (same leaves) Thanks, Rob > > > /martin > . > From nobody Fri Oct 2 02:24:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9151AD0C2 for ; Fri, 2 Oct 2015 02:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqyYB4MvRPJW for ; Fri, 2 Oct 2015 02:24:21 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFA81AD0C1 for ; Fri, 2 Oct 2015 02:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2968; q=dns/txt; s=iport; t=1443777861; x=1444987461; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=C4cZkvdESxu3k1KDXhBhKmPrtNBR995VlMKEL23//tA=; b=RskqDWfFcp3MlgNGrUSEfkffwPtP13lTp2zQ0TWSBox6kV1u+Olrt2Rq J+zNGxI5DhZQNSE3IdrCHCm/GXKua+UFyCU+FI2UZJva2SRAO9B3Yia+H qxWoWHtd9549BJgy9F2p9R52z+6EfYfQMOlPzbuEkinjXFsvEaGP2Eehk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgBAB2TA5W/xbLJq1eg3tuv3kKhS9KAoIDAQEBAQEBgQuEJAEBAQMBAQEBNTYKEQsRBAEBAQkMCg8JAwIBAgEVKAgGAQwGAgEBF4gLCA3LWgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOEfoUUCoQiAQSHNIcCh0aNFokLklVjgkSBPz0ziXgBAQE X-IronPort-AV: E=Sophos;i="5.17,622,1437436800"; d="scan'208";a="605489867" 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; 02 Oct 2015 09:24:17 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t929OHqJ025274; Fri, 2 Oct 2015 09:24:17 GMT To: Randy Presuhn , "netmod@ietf.org" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> From: Robert Wilton Message-ID: <560E4D41.3070607@cisco.com> Date: Fri, 2 Oct 2015 10:24:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 09:24:26 -0000 Hi Randy, On 01/10/2015 23:27, Randy Presuhn wrote: > Hi - > >> From: Robert Wilton >> Sent: Oct 1, 2015 10:01 AM >> To: "netmod@ietf.org" >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" >> >> To clarify what I failed to eloquently express in the interim meeting. >> >> I propose changing the text for requirement 1.D. This also removes the >> need to define what fully synchronized means. >> >> >> Old text for 1.D >> D. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. >> >> >> Proposed text for 1.D: >> D. When the configuration change for any intended >> configuration leaf has been successfully applied to the >> system (i.e. not failed, nor deferred due to absent hardware) >> then the existence and value of the corresponding applied >> configuration leaf must match the intended configuration >> leaf. > Are "not failed" and "deferred due to absent hardware" the > *only* possibilities? If not, then the "i.e." needs to be > replaced with an "e.g." I'm not sure if it is the only possibility. Two other possible reason might be: - Configuration that cannot be applied because some dependent configuration hasn't been applied. (E.g. if you have configuration where an interface-ref couldn't be fulfilled because the referenced interface configuration hadn't been applied because either it had failed or been deferred due to absent hardware). But perhaps this would be classified as being one of the two cases above? - There is also the case the configuration is currently in the process of being applied. If it is agreed that github issue #2 (i.e. "Is there a requirement to indicate why intended config != applied cfg?") is a valid requirement, and I think that there might have been some support for this in the interim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configuration may not match the intended configuration. As such, changing from i.e. to e.g. seems like a good choice. So also taking into account Martin's suggestion the updated proposed text for 1.D would be: D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. Thanks, Rob > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Oct 2 07:11:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B669D1A1A6A for ; Fri, 2 Oct 2015 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExQIHQnrt1fJ for ; Fri, 2 Oct 2015 07:11:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B551A037C for ; Fri, 2 Oct 2015 07:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1443795007; bh=DRtb1C0QO4nbs+ooT3vQmEl5PFRaXEjHNhWbnvQyIVc=; h=From:Subject:Date:Cc:To; b=StXdTUUWE8yWYe0ZNgpqf0NFlLU0XWYkn/ljH+CyLs6cTTWP3f+32niAxKa3Y7ofK /ddDHUu0tsZa1aWtndULnuVvz1X3Q7xu60Hgmyq64Y0xf+y8r2JTeROPqnrlxmAaPG Mzx5ZlNYVkKjfvhkFkZIbYsJykSqmdlWC5CYf2MU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2015 10:11:30 -0400 Message-Id: <5540BC2C-F2CE-45F4-A52C-C4B4473FE3AF@lucidvision.com> To: netmod WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=8 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 140, in=1745, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: [netmod] Consensus to Adoption of draft-chairs-netmod-opstate-reqs-00 as a NETMOD WG Document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 14:11:39 -0000 NETMOD WG: After much discussion, The Chairs believe there is rough = consensus to move forward and adopt the base requirements as listed in = draft-chairs-netmod-opstate-reqs-00. We therefore believe it is appropriate now to adopt = draft-chairs-netmod-opstate-reqs-00 as=20 a NETMOD WG draft to capture these requirements as official WG items. We = as a WG need to=20 continue to refine some of the finer points in the document such as the = terminology,=20 but by in large, it is clear that the requirements as stated at present = are close enough at this point. The new draft will be published as = draft-ietf-netmod-opstate-reqs-00 shortly. We appreciate and thank all who contributed to the draft and = discussions for their patience and effort around this. Tom and Kent (NETMOD Co-chairs) From nobody Fri Oct 2 10:44:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133031B2FE5 for ; Fri, 2 Oct 2015 10:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnqZ0jgjs5gh for ; Fri, 2 Oct 2015 10:44:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BF81B2FE3 for ; Fri, 2 Oct 2015 10:44:33 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id A8E3A7E76A019; Fri, 2 Oct 2015 17:44:27 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t92HiP0S028680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Oct 2015 17:44:29 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 2 Oct 2015 13:44:23 -0400 From: "Sterne, Jason (Jason)" To: Robert Wilton , Randy Presuhn , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" Thread-Index: AQHQ/PQoKglVAxr7q0eHYXc0dXifl55YdwCg Date: Fri, 2 Oct 2015 17:44:23 +0000 Message-ID: References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> In-Reply-To: <560E4D41.3070607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 17:44:35 -0000 I agree with "e.g." rather than "i.e.". I'm sure there are lots of other e= xamples of situations where intended config and applied config don't match = when we consider the variety of systems out there that may use NETCONF/YANG= . We should include some of these examples in the draft (in some informati= onal section and have a reference/pointer to them just after the definition= ). Note that this updated definition for 1.D does not preclude the applied con= fig object from matching the intended *before* it has been applied. Do we = need to clarify that with some "conversely" clause or is that clear enough = when considering the other requirements ? We should also cleanly define "applied" (and provide illustrative examples = of when something is and is not applied). Should that be a separate email = thread ? Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton Sent: Friday, October 02, 2015 5:24 To: Randy Presuhn; netmod@ietf.org Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchro= nized" in "Requirement 1.D" Hi Randy, On 01/10/2015 23:27, Randy Presuhn wrote: > Hi - > >> From: Robert Wilton >> Sent: Oct 1, 2015 10:01 AM >> To: "netmod@ietf.org" >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchron= ized" in "Requirement 1.D" >> >> To clarify what I failed to eloquently express in the interim meeting. >> >> I propose changing the text for requirement 1.D. This also removes=20 >> the need to define what fully synchronized means. >> >> >> Old text for 1.D >> D. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. >> >> >> Proposed text for 1.D: >> D. When the configuration change for any intended >> configuration leaf has been successfully applied to the >> system (i.e. not failed, nor deferred due to absent hardware= ) >> then the existence and value of the corresponding applied >> configuration leaf must match the intended configuration >> leaf. > Are "not failed" and "deferred due to absent hardware" the > *only* possibilities? If not, then the "i.e." needs to be replaced=20 > with an "e.g." I'm not sure if it is the only possibility. Two other possible reason migh= t be: - Configuration that cannot be applied because some dependent configurati= on hasn't been applied. (E.g. if you have configuration where an interface= -ref couldn't be fulfilled because the referenced interface configuration h= adn't been applied because either it had failed or been deferred due to abs= ent hardware). But perhaps this would be classified as being one of the tw= o cases above? - There is also the case the configuration is currently in the process of= being applied. If it is agreed that github issue #2 (i.e. "Is there a requirement to indic= ate why intended config !=3D applied cfg?") is a valid requirement, and I t= hink that there might have been some support for this in the interim meetin= g yesterday, then I would hope that the final solution would enumerate the = reasons why the applied configuration may not match the intended configurat= ion. As such, changing from i.e. to e.g. seems like a good choice. So also taking into account Martin's suggestion the updated proposed text f= or 1.D would be: D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. Thanks, Rob > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Oct 2 11:11:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7A41B3081 for ; Fri, 2 Oct 2015 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st_PovCS4lNx for ; Fri, 2 Oct 2015 11:11:23 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 D2E351B307D for ; Fri, 2 Oct 2015 11:11:22 -0700 (PDT) Received: by lbos8 with SMTP id s8so30732745lbo.0 for ; Fri, 02 Oct 2015 11:11:21 -0700 (PDT) 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=cmXWOZRQOIV9QlITTI4wmDDjFDrbw8KOYTEYSV4Zx7A=; b=J+FA5eGvZtkDabjSRsFH3di9TNOl75uLjJ0+Ff82F3c+YRO+UvIGkmgfFbu3w32KQD syt++qaZhlnSZt0zGJAQAMzUvdWshlmNGdR1dMEc3p1D0WOxDFCi/XX4ETW+eTSiFpwX wyEYyDEvs6COD+3jmFDZcB5wLH0Eb+6zd7ykUn3K1OvAPyEFH1+X1jQ517m70WL2XMEc RtZmaiFBSYtHL04GOIwHXjWRxMLA0EFupnEDIBrA56P6JF1vHoDJufWCvU3bZklPmTqp PpfMX8ouUOxL+zHyA9exin3YroA4zAHRJtLzpQUETZ9ZJuPIU6VCgS/W4awMbeyjZXLC bYuQ== X-Gm-Message-State: ALoCoQmQRiVw8bP6KICSk0hVSUr96sCvop2r1BRE9psYRQ4pzW05WzpymidwJbBh6RkkBOdYWVD4 MIME-Version: 1.0 X-Received: by 10.112.160.138 with SMTP id xk10mr6025280lbb.119.1443809480839; Fri, 02 Oct 2015 11:11:20 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Fri, 2 Oct 2015 11:11:20 -0700 (PDT) In-Reply-To: References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> Date: Fri, 2 Oct 2015 11:11:20 -0700 Message-ID: From: Andy Bierman To: "Sterne, Jason (Jason)" Content-Type: multipart/alternative; boundary=001a11c38b903aae35052123176a Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 18:11:26 -0000 --001a11c38b903aae35052123176a Content-Type: text/plain; charset=UTF-8 Hi, What about the data models that do not follow 1D? - templates: the intended data model and applied data model are disjoint - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they will never have the same value - 'use-dhcp' corner-case: intended config just enables specific derived state to be used; disjoint data models Somebody asked an important question at the interim: Is the intent of this group to limit all YANG data models such that they conform to 1D? (IMO that is a non-starter) IMO requirement 1D presume that the solution involves separate objects in the YANG data model for intended and applied states, and therefore it is an invalid requirement. Only the 2 protocol-based solutions address this issue by using the same object identifier no matter which state is being queried. Andy On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) < jason.sterne@alcatel-lucent.com> wrote: > I agree with "e.g." rather than "i.e.". I'm sure there are lots of other > examples of situations where intended config and applied config don't match > when we consider the variety of systems out there that may use > NETCONF/YANG. We should include some of these examples in the draft (in > some informational section and have a reference/pointer to them just after > the definition). > > Note that this updated definition for 1.D does not preclude the applied > config object from matching the intended *before* it has been applied. Do > we need to clarify that with some "conversely" clause or is that clear > enough when considering the other requirements ? > > We should also cleanly define "applied" (and provide illustrative examples > of when something is and is not applied). Should that be a separate email > thread ? > > Jason > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton > Sent: Friday, October 02, 2015 5:24 > To: Randy Presuhn; netmod@ietf.org > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > Hi Randy, > > On 01/10/2015 23:27, Randy Presuhn wrote: > > Hi - > > > >> From: Robert Wilton > >> Sent: Oct 1, 2015 10:01 AM > >> To: "netmod@ietf.org" > >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > >> > >> To clarify what I failed to eloquently express in the interim meeting. > >> > >> I propose changing the text for requirement 1.D. This also removes > >> the need to define what fully synchronized means. > >> > >> > >> Old text for 1.D > >> D. For asynchronous systems, when fully synchronized, the data > >> in the applied configuration is the same as the data in the > >> intended configuration. > >> > >> > >> Proposed text for 1.D: > >> D. When the configuration change for any intended > >> configuration leaf has been successfully applied to the > >> system (i.e. not failed, nor deferred due to absent > hardware) > >> then the existence and value of the corresponding applied > >> configuration leaf must match the intended configuration > >> leaf. > > Are "not failed" and "deferred due to absent hardware" the > > *only* possibilities? If not, then the "i.e." needs to be replaced > > with an "e.g." > I'm not sure if it is the only possibility. Two other possible reason > might be: > - Configuration that cannot be applied because some dependent > configuration hasn't been applied. (E.g. if you have configuration where > an interface-ref couldn't be fulfilled because the referenced interface > configuration hadn't been applied because either it had failed or been > deferred due to absent hardware). But perhaps this would be classified as > being one of the two cases above? > - There is also the case the configuration is currently in the process > of being applied. > > If it is agreed that github issue #2 (i.e. "Is there a requirement to > indicate why intended config != applied cfg?") is a valid requirement, and > I think that there might have been some support for this in the interim > meeting yesterday, then I would hope that the final solution would > enumerate the reasons why the applied configuration may not match the > intended configuration. > > As such, changing from i.e. to e.g. seems like a good choice. > > So also taking into account Martin's suggestion the updated proposed text > for 1.D would be: > > D. When the configuration change for any intended > configuration node has been successfully applied to the > system (e.g. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding applied > configuration node must match the intended configuration > node. > > Thanks, > Rob > > > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c38b903aae35052123176a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

What about the data models that do = not follow 1D?

=C2=A0 - templates: the intended da= ta model and applied data model are disjoint
=C2=A0 - 'auto-d= uplex' corner-case: the intended and applied leaf are the same, but the= y
=C2=A0 =C2=A0 will never have the same value
=C2=A0 -= 'use-dhcp' corner-case: intended config just enables specific deri= ved state
=C2=A0 =C2=A0 =C2=A0to be used; disjoint data models

Somebody asked an important question at the interim:=
Is the intent of this group to limit all YANG data models such t= hat
they conform to 1D? (IMO that is a non-starter)
IMO requirement 1D presume that the solution involves separate<= /div>
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
<= div>

Andy

=
On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (= Jason) <jason.sterne@alcatel-lucent.com> wrote= :
I agree with "e.g." rather th= an "i.e.".=C2=A0 I'm sure there are lots of other examples of= situations where intended config and applied config don't match when w= e consider the variety of systems out there that may use NETCONF/YANG.=C2= =A0 We should include some of these examples in the draft (in some informat= ional section and have a reference/pointer to them just after the definitio= n).

Note that this updated definition for 1.D does not preclude the applied con= fig object from matching the intended *before* it has been applied.=C2=A0 D= o we need to clarify that with some "conversely" clause or is tha= t clear enough when considering the other requirements ?

We should also cleanly define "applied" (and provide illustrative= examples of when something is and is not applied).=C2=A0 Should that be a = separate email thread ?

Jason


-----Original Message-----
From: netmod [mailto:netmod-boun= ces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; netmod@ietf.org Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully sy= nchronized" in "Requirement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwilt= on@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org&q= uot; <netmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "ful= ly synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meet= ing.
>>
>> I propose changing the text for requirement 1.D. This also removes=
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 For asynchronous systems= , when fully synchronized, the data
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the applied conf= iguration is the same as the data in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended configurat= ion.
>>
>>
>> Proposed text for 1.D:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 When the configuration c= hange for any intended
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration leaf = has been successfully applied to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0system (i.e. not fa= iled, nor deferred due to absent hardware)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the existence = and value of the corresponding applied
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration leaf = must match the intended configuration
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf.
> Are "not failed" and "deferred due to absent hardware&q= uot; the
> *only* possibilities?=C2=A0 If not, then the "i.e." needs to= be replaced
> with an "e.g."
I'm not sure if it is the only possibility.=C2=A0 Two other possible re= ason might be:
=C2=A0 - Configuration that cannot be applied because some dependent config= uration hasn't been applied.=C2=A0 (E.g. if you have configuration wher= e an interface-ref couldn't be fulfilled because the referenced interfa= ce configuration hadn't been applied because either it had failed or be= en deferred due to absent hardware).=C2=A0 But perhaps this would be classi= fied as being one of the two cases above?
=C2=A0 - There is also the case the configuration is currently in the proce= ss of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to = indicate why intended config !=3D applied cfg?") is a valid requiremen= t, and I think that there might have been some support for this in the inte= rim meeting yesterday, then I would hope that the final solution would enum= erate the reasons why the applied configuration may not match the intended = configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed te= xt for 1.D would be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 When the configuration change for any = intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration node has been succe= ssfully applied to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 system (e.g. not failed, nor defe= rred due to absent hardware)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the existence and value of t= he corresponding applied
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration node must match the= intended configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node.

Thanks,
Rob


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

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

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

--001a11c38b903aae35052123176a-- From nobody Fri Oct 2 12:37:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA321A8775 for ; Fri, 2 Oct 2015 12:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqIt3xGTdr_T for ; Fri, 2 Oct 2015 12:37:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143411A8772 for ; Fri, 2 Oct 2015 12:37:22 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id E944222B14F6D; Fri, 2 Oct 2015 19:37:15 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t92JbHWR012438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Oct 2015 19:37:17 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 2 Oct 2015 15:37:17 -0400 From: "Sterne, Jason (Jason)" To: Andy Bierman Thread-Topic: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" Thread-Index: AQHQ/PQoKglVAxr7q0eHYXc0dXifl55YdwCggABNnwD//8aJYA== Date: Fri, 2 Oct 2015 19:37:16 +0000 Message-ID: References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CACCF88US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 19:37:26 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CACCF88US70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludCB0aGF0IHRoZSB3b3JkaW5nIGRvZXMgaW1wbHkgc2VwYXJhdGUgb2JqZWN0cyBp biB0aGUgWUFORyBkYXRhIG1vZGVsLiAgV2Ugc2hvdWxkIHRyeSB0byBhZGp1c3QgdGhlIHdvcmRp bmcgc28gdGhhdCBpdCBjb3VsZCBhcHBseSB0byBvdGhlciBzb2x1dGlvbnMgKGUuZy4gYXR0cmli dXRlcywgZGlmZmVyZW50IGRhdGFzdG9yZSwgZXRjKS4gICBQZXJoYXBzIHRoZSBmb2xsb3dpbmcg Pw0KDQpXaGVuIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZSBmb3IgYW55IGludGVuZGVkIGNvbmZp Z3VyYXRpb24gbm9kZSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgYXBwbGllZCB0byB0aGUgc3lzdGVt IChlLmcuIG5vdCBmYWlsZWQsIG5vciBkZWZlcnJlZCBkdWUgdG8gYWJzZW50IGhhcmR3YXJlKSB0 aGVuIHRoZSBleGlzdGVuY2UgYW5kIHZhbHVlIG9mIHRoZSBhcHBsaWVkIGVxdWl2YWxlbnQgb2Yg dGhlIG5vZGUgKHdoZXRoZXIgdGhhdCBiZSBhIGNvcnJlc3BvbmRpbmcgbm9kZSBpbiB0aGUgZGF0 YSBtb2RlbCwgYW4gYXR0cmlidXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgaW50ZW5kZWQgY29uZmln IG5vZGUsIHRoZSBjb25maWd1cmF0aW9uIG5vZGUgcmVhZCBmcm9tIGEgZGlmZmVyZW50IGRhdGFz dG9yZSBvciBjb250ZXh0LCBldGMpIG11c3QgbWF0Y2ggdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRp b24gbm9kZS4NCg0KVGVtcGxhdGVzOiAgUGVyaGFwcyB0ZW1wbGF0ZXMgKG5vdCBpbnN0YW5jZXMg b2YgdGhlIHRlbXBsYXRlLCBidXQgdGhlIHRlbXBsYXRlIGl0c2VsZikgYXJlIGFsd2F5cyBjb25z aWRlcmVkIGFzIOKAnGFwcGxpZWTigJ0gYXMgc29vbiBhcyB0aGV5IGFyZSBjb25maWd1cmVkID8N Cg0KQXV0by1kdXBsZXg6ICBUaGUgY29uZmlndXJlZCBkdXBsZXggc2V0dGluZyBhbmQgdGhlIG5l Z290aWF0ZWQgcmVzdWx0aW5nIG9wZXJhdGlvbmFsIHZhbHVlIGFyZSB0d28gc2VwYXJhdGUgYW5k IGluZGVwZW5kZW50IGxlYXZlcyBJTU8uICBUaGUgY29uZmlndXJlZCBkdXBsZXggc2V0dGluZyB3 aWxsIGhhdmUgYm90aCBhbiBpbnRlbmRlZCB2aWV3IGFuZCBhbiBhcHBsaWVkIHZpZXcgKHdoaWNo IGFyZSBzZXBhcmF0ZSBhbiBpbmRlcGVuZGVudCBmcm9tIHRoZSBuZWdvdGlhdGVkIGR1cGxleCku ICBFLmcuIEFkbWluRHVwbGV4IChpbnRlbmRlZCAmIGFwcGxpZWQpIGFuZCBPcGVyRHVwbGV4IChw dXJlIOKAmGRlcml2ZWTigJkgc3RhdGUpLg0KDQpJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUg dXNlLWRoY3AgZXhhbXBsZS4gIEJ1dCBtYXliZSBhcyBzb29uIGFzIHRoZSBzeXN0ZW0gaXMgYWN0 dWFsbHkg4oCcdXNpbmcgREhDUOKAnSBkb3duIG9uIHRoZSBsaW5lY2FyZHMgdGhlbiB0aGUgYXBw bGllZCB2YWx1ZSB3b3VsZCByZWZsZWN0IHRoYXQgPw0KDQpSZSBhbGwgZGF0YSBtb2RlbHMgY29u Zm9ybWluZyB0byAxRDogIElmIHRoZSBzb2x1dGlvbiBlbmRzIHVwIGJlaW5nIGluIHRoZSBwcm90 b2NvbHMgKGluc3RlYWQgb2YgdGhlIG1vZGVscykgdGhlbiB0aGVyZSBhcmUgbm8gcmVxdWlyZW1l bnRzIGZvciBtb2RlbHMuICBJZiB0aGUgc29sdXRpb24gZW5kcyB1cCBiZWluZyBpbiB0aGUgbW9k ZWxzIHRoZW4gSSBkb27igJl0IHRoaW5rIHdlIGNhbiBtYW5kYXRlIHRoYXQgKmFsbCogbW9kZWxz IGZvbGxvdyB0aGVzZSByZXF1aXJlbWVudHMuICBDb250cm9sbGVycy9jbGllbnRzIHdpbGwgaGF2 ZSB0byBiZSBhYmxlIHRvIG1hbmFnZSBzeXN0ZW1zIHRoYXQgaGF2ZSBhIG1peCBvZiDigJxvcHN0 YXRlIGNvbXBsaWFudOKAnSBtb2R1bGVzIGFuZCBub24gY29tcGxpYW50IG1vZHVsZXMuICBPcGVy YXRvcnMgd2hvIGFyZSBrZWVuIG9uIHRoZXNlIHJlcXVpcmVtZW50cyB3aWxsIGVuY291cmFnZSB0 aGVtIHRvIGJlIGFkb3B0ZWQgYnkgYXMgbWFueSBJRVRGIG1vZHVsZXMgYXMgcG9zc2libGUuDQoN CkltcGxlbWVudGF0aW9uIGZlYXNpYmlsaXR5ICYgaW1wYWN0cyBpcyBzb21ldGhpbmcgdGhhdCB3 ZeKAmWxsIG5lZWQgdG8gY29uc2lkZXIgYnV0IGZvciBub3cgSeKAmW0gdHJ5aW5nIHRvIGlnbm9y ZSB0aGF0IGFuZCBwdXJlbHkgY2xhcmlmeSB3aGF0IGlzIGJlaW5nIHJlcXVlc3RlZC4NCg0KSmFz b24NCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDAyLCAyMDE1IDE0OjExDQpUbzogU3Rlcm5lLCBKYXNvbiAoSmFz b24pDQpDYzogUm9iZXJ0IFdpbHRvbjsgUmFuZHkgUHJlc3VobjsgbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW25ldG1vZF0gb3BzdGF0ZS1yZXFzIGlzc3VlICMxIC0gRGVmaW5lL0NsYXJp ZnkgImZ1bGx5IHN5bmNocm9uaXplZCIgaW4gIlJlcXVpcmVtZW50IDEuRCINCg0KSGksDQoNCldo YXQgYWJvdXQgdGhlIGRhdGEgbW9kZWxzIHRoYXQgZG8gbm90IGZvbGxvdyAxRD8NCg0KICAtIHRl bXBsYXRlczogdGhlIGludGVuZGVkIGRhdGEgbW9kZWwgYW5kIGFwcGxpZWQgZGF0YSBtb2RlbCBh cmUgZGlzam9pbnQNCiAgLSAnYXV0by1kdXBsZXgnIGNvcm5lci1jYXNlOiB0aGUgaW50ZW5kZWQg YW5kIGFwcGxpZWQgbGVhZiBhcmUgdGhlIHNhbWUsIGJ1dCB0aGV5DQogICAgd2lsbCBuZXZlciBo YXZlIHRoZSBzYW1lIHZhbHVlDQogIC0gJ3VzZS1kaGNwJyBjb3JuZXItY2FzZTogaW50ZW5kZWQg Y29uZmlnIGp1c3QgZW5hYmxlcyBzcGVjaWZpYyBkZXJpdmVkIHN0YXRlDQogICAgIHRvIGJlIHVz ZWQ7IGRpc2pvaW50IGRhdGEgbW9kZWxzDQoNClNvbWVib2R5IGFza2VkIGFuIGltcG9ydGFudCBx dWVzdGlvbiBhdCB0aGUgaW50ZXJpbToNCklzIHRoZSBpbnRlbnQgb2YgdGhpcyBncm91cCB0byBs aW1pdCBhbGwgWUFORyBkYXRhIG1vZGVscyBzdWNoIHRoYXQNCnRoZXkgY29uZm9ybSB0byAxRD8g KElNTyB0aGF0IGlzIGEgbm9uLXN0YXJ0ZXIpDQoNCklNTyByZXF1aXJlbWVudCAxRCBwcmVzdW1l IHRoYXQgdGhlIHNvbHV0aW9uIGludm9sdmVzIHNlcGFyYXRlDQpvYmplY3RzIGluIHRoZSBZQU5H IGRhdGEgbW9kZWwgZm9yIGludGVuZGVkIGFuZCBhcHBsaWVkIHN0YXRlcywNCmFuZCB0aGVyZWZv cmUgaXQgaXMgYW4gaW52YWxpZCByZXF1aXJlbWVudC4NCg0KT25seSB0aGUgMiBwcm90b2NvbC1i YXNlZCBzb2x1dGlvbnMgYWRkcmVzcyB0aGlzIGlzc3VlIGJ5IHVzaW5nDQp0aGUgc2FtZSBvYmpl Y3QgaWRlbnRpZmllciBubyBtYXR0ZXIgd2hpY2ggc3RhdGUgaXMgYmVpbmcgcXVlcmllZC4NCg0K DQoNCkFuZHkNCg0KT24gRnJpLCBPY3QgMiwgMjAxNSBhdCAxMDo0NCBBTSwgU3Rlcm5lLCBKYXNv biAoSmFzb24pIDxqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpqYXNvbi5z dGVybmVAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggImUuZy4iIHJh dGhlciB0aGFuICJpLmUuIi4gIEknbSBzdXJlIHRoZXJlIGFyZSBsb3RzIG9mIG90aGVyIGV4YW1w bGVzIG9mIHNpdHVhdGlvbnMgd2hlcmUgaW50ZW5kZWQgY29uZmlnIGFuZCBhcHBsaWVkIGNvbmZp ZyBkb24ndCBtYXRjaCB3aGVuIHdlIGNvbnNpZGVyIHRoZSB2YXJpZXR5IG9mIHN5c3RlbXMgb3V0 IHRoZXJlIHRoYXQgbWF5IHVzZSBORVRDT05GL1lBTkcuICBXZSBzaG91bGQgaW5jbHVkZSBzb21l IG9mIHRoZXNlIGV4YW1wbGVzIGluIHRoZSBkcmFmdCAoaW4gc29tZSBpbmZvcm1hdGlvbmFsIHNl Y3Rpb24gYW5kIGhhdmUgYSByZWZlcmVuY2UvcG9pbnRlciB0byB0aGVtIGp1c3QgYWZ0ZXIgdGhl IGRlZmluaXRpb24pLg0KDQpOb3RlIHRoYXQgdGhpcyB1cGRhdGVkIGRlZmluaXRpb24gZm9yIDEu RCBkb2VzIG5vdCBwcmVjbHVkZSB0aGUgYXBwbGllZCBjb25maWcgb2JqZWN0IGZyb20gbWF0Y2hp bmcgdGhlIGludGVuZGVkICpiZWZvcmUqIGl0IGhhcyBiZWVuIGFwcGxpZWQuICBEbyB3ZSBuZWVk IHRvIGNsYXJpZnkgdGhhdCB3aXRoIHNvbWUgImNvbnZlcnNlbHkiIGNsYXVzZSBvciBpcyB0aGF0 IGNsZWFyIGVub3VnaCB3aGVuIGNvbnNpZGVyaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudHMgPw0K DQpXZSBzaG91bGQgYWxzbyBjbGVhbmx5IGRlZmluZSAiYXBwbGllZCIgKGFuZCBwcm92aWRlIGls bHVzdHJhdGl2ZSBleGFtcGxlcyBvZiB3aGVuIHNvbWV0aGluZyBpcyBhbmQgaXMgbm90IGFwcGxp ZWQpLiAgU2hvdWxkIHRoYXQgYmUgYSBzZXBhcmF0ZSBlbWFpbCB0aHJlYWQgPw0KDQpKYXNvbg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRt b2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDAyLCAyMDE1IDU6 MjQNClRvOiBSYW5keSBQcmVzdWhuOyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBvcHN0YXRlLXJlcXMgaXNzdWUgIzEgLSBEZWZp bmUvQ2xhcmlmeSAiZnVsbHkgc3luY2hyb25pemVkIiBpbiAiUmVxdWlyZW1lbnQgMS5EIg0KDQpI aSBSYW5keSwNCg0KT24gMDEvMTAvMjAxNSAyMzoyNywgUmFuZHkgUHJlc3VobiB3cm90ZToNCj4g SGkgLQ0KPg0KPj4gRnJvbTogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRv OnJ3aWx0b25AY2lzY28uY29tPj4NCj4+IFNlbnQ6IE9jdCAxLCAyMDE1IDEwOjAxIEFNDQo+PiBU bzogIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4+IFN1YmplY3Q6IFtuZXRtb2RdIG9wc3Rh dGUtcmVxcyBpc3N1ZSAjMSAtIERlZmluZS9DbGFyaWZ5ICJmdWxseSBzeW5jaHJvbml6ZWQiIGlu ICJSZXF1aXJlbWVudCAxLkQiDQo+Pg0KPj4gVG8gY2xhcmlmeSB3aGF0IEkgZmFpbGVkIHRvIGVs b3F1ZW50bHkgZXhwcmVzcyBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nLg0KPj4NCj4+IEkgcHJvcG9z ZSBjaGFuZ2luZyB0aGUgdGV4dCBmb3IgcmVxdWlyZW1lbnQgMS5ELiBUaGlzIGFsc28gcmVtb3Zl cw0KPj4gdGhlIG5lZWQgdG8gZGVmaW5lIHdoYXQgZnVsbHkgc3luY2hyb25pemVkIG1lYW5zLg0K Pj4NCj4+DQo+PiBPbGQgdGV4dCBmb3IgMS5EDQo+PiAgICAgICAgIEQuICBGb3IgYXN5bmNocm9u b3VzIHN5c3RlbXMsIHdoZW4gZnVsbHkgc3luY2hyb25pemVkLCB0aGUgZGF0YQ0KPj4gICAgICAg ICAgICAgaW4gdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBpcyB0aGUgc2FtZSBhcyB0aGUgZGF0 YSBpbiB0aGUNCj4+ICAgICAgICAgICAgIGludGVuZGVkIGNvbmZpZ3VyYXRpb24uDQo+Pg0KPj4N Cj4+IFByb3Bvc2VkIHRleHQgZm9yIDEuRDoNCj4+ICAgICAgICAgRC4gIFdoZW4gdGhlIGNvbmZp Z3VyYXRpb24gY2hhbmdlIGZvciBhbnkgaW50ZW5kZWQNCj4+ICAgICAgICAgICAgIGNvbmZpZ3Vy YXRpb24gbGVhZiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgYXBwbGllZCB0byB0aGUNCj4+ICAgICAg ICAgICAgIHN5c3RlbSAoaS5lLiBub3QgZmFpbGVkLCBub3IgZGVmZXJyZWQgZHVlIHRvIGFic2Vu dCBoYXJkd2FyZSkNCj4+ICAgICAgICAgICAgIHRoZW4gdGhlIGV4aXN0ZW5jZSBhbmQgdmFsdWUg b2YgdGhlIGNvcnJlc3BvbmRpbmcgYXBwbGllZA0KPj4gICAgICAgICAgICAgY29uZmlndXJhdGlv biBsZWFmIG11c3QgbWF0Y2ggdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24NCj4+ICAgICAgICAg ICAgIGxlYWYuDQo+IEFyZSAibm90IGZhaWxlZCIgYW5kICJkZWZlcnJlZCBkdWUgdG8gYWJzZW50 IGhhcmR3YXJlIiB0aGUNCj4gKm9ubHkqIHBvc3NpYmlsaXRpZXM/ICBJZiBub3QsIHRoZW4gdGhl ICJpLmUuIiBuZWVkcyB0byBiZSByZXBsYWNlZA0KPiB3aXRoIGFuICJlLmcuIg0KSSdtIG5vdCBz dXJlIGlmIGl0IGlzIHRoZSBvbmx5IHBvc3NpYmlsaXR5LiAgVHdvIG90aGVyIHBvc3NpYmxlIHJl YXNvbiBtaWdodCBiZToNCiAgLSBDb25maWd1cmF0aW9uIHRoYXQgY2Fubm90IGJlIGFwcGxpZWQg YmVjYXVzZSBzb21lIGRlcGVuZGVudCBjb25maWd1cmF0aW9uIGhhc24ndCBiZWVuIGFwcGxpZWQu ICAoRS5nLiBpZiB5b3UgaGF2ZSBjb25maWd1cmF0aW9uIHdoZXJlIGFuIGludGVyZmFjZS1yZWYg Y291bGRuJ3QgYmUgZnVsZmlsbGVkIGJlY2F1c2UgdGhlIHJlZmVyZW5jZWQgaW50ZXJmYWNlIGNv bmZpZ3VyYXRpb24gaGFkbid0IGJlZW4gYXBwbGllZCBiZWNhdXNlIGVpdGhlciBpdCBoYWQgZmFp bGVkIG9yIGJlZW4gZGVmZXJyZWQgZHVlIHRvIGFic2VudCBoYXJkd2FyZSkuICBCdXQgcGVyaGFw cyB0aGlzIHdvdWxkIGJlIGNsYXNzaWZpZWQgYXMgYmVpbmcgb25lIG9mIHRoZSB0d28gY2FzZXMg YWJvdmU/DQogIC0gVGhlcmUgaXMgYWxzbyB0aGUgY2FzZSB0aGUgY29uZmlndXJhdGlvbiBpcyBj dXJyZW50bHkgaW4gdGhlIHByb2Nlc3Mgb2YgYmVpbmcgYXBwbGllZC4NCg0KSWYgaXQgaXMgYWdy ZWVkIHRoYXQgZ2l0aHViIGlzc3VlICMyIChpLmUuICJJcyB0aGVyZSBhIHJlcXVpcmVtZW50IHRv IGluZGljYXRlIHdoeSBpbnRlbmRlZCBjb25maWcgIT0gYXBwbGllZCBjZmc/IikgaXMgYSB2YWxp ZCByZXF1aXJlbWVudCwgYW5kIEkgdGhpbmsgdGhhdCB0aGVyZSBtaWdodCBoYXZlIGJlZW4gc29t ZSBzdXBwb3J0IGZvciB0aGlzIGluIHRoZSBpbnRlcmltIG1lZXRpbmcgeWVzdGVyZGF5LCB0aGVu IEkgd291bGQgaG9wZSB0aGF0IHRoZSBmaW5hbCBzb2x1dGlvbiB3b3VsZCBlbnVtZXJhdGUgdGhl IHJlYXNvbnMgd2h5IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gbWF5IG5vdCBtYXRjaCB0aGUg aW50ZW5kZWQgY29uZmlndXJhdGlvbi4NCg0KQXMgc3VjaCwgY2hhbmdpbmcgZnJvbSBpLmUuIHRv IGUuZy4gc2VlbXMgbGlrZSBhIGdvb2QgY2hvaWNlLg0KDQpTbyBhbHNvIHRha2luZyBpbnRvIGFj Y291bnQgTWFydGluJ3Mgc3VnZ2VzdGlvbiB0aGUgdXBkYXRlZCBwcm9wb3NlZCB0ZXh0IGZvciAx LkQgd291bGQgYmU6DQoNCiAgICAgICAgRC4gIFdoZW4gdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdl IGZvciBhbnkgaW50ZW5kZWQNCiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gbm9kZSBoYXMgYmVl biBzdWNjZXNzZnVsbHkgYXBwbGllZCB0byB0aGUNCiAgICAgICAgICAgIHN5c3RlbSAoZS5nLiBu b3QgZmFpbGVkLCBub3IgZGVmZXJyZWQgZHVlIHRvIGFic2VudCBoYXJkd2FyZSkNCiAgICAgICAg ICAgIHRoZW4gdGhlIGV4aXN0ZW5jZSBhbmQgdmFsdWUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgYXBw bGllZA0KICAgICAgICAgICAgY29uZmlndXJhdGlvbiBub2RlIG11c3QgbWF0Y2ggdGhlIGludGVu ZGVkIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgICAgIG5vZGUuDQoNClRoYW5rcywNClJvYg0KDQoN Cj4NCj4gUmFuZHkNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4gLg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= --_000_A125E53CE190A749957C19483DC79F9F5CACCF88US70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1Mzg3Mzk5Mzk7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MDE2MDc1NTQgMjU3MDk2 OTEyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkdvb2QgcG9pbnQgdGhhdCB0aGUgd29yZGluZyBkb2VzIGltcGx5IHNlcGFyYXRlIG9iamVjdHMg aW4gdGhlIFlBTkcgZGF0YSBtb2RlbC4gJm5ic3A7V2Ugc2hvdWxkIHRyeSB0byBhZGp1c3QgdGhl IHdvcmRpbmcgc28gdGhhdCBpdCBjb3VsZCBhcHBseSB0byBvdGhlciBzb2x1dGlvbnMNCiAoZS5n LiBhdHRyaWJ1dGVzLCBkaWZmZXJlbnQgZGF0YXN0b3JlLCBldGMpLiZuYnNwOyAmbmJzcDtQZXJo YXBzIHRoZSBmb2xsb3dpbmcgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiB0aGUgY29uZmlndXJhdGlvbiBjaGFu Z2UgZm9yIGFueSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIG5vZGUgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IGFwcGxpZWQgdG8gdGhlIHN5c3RlbSAoZS5nLiBub3QgZmFpbGVkLCBub3IgZGVmZXJyZWQg ZHVlIHRvIGFic2VudCBoYXJkd2FyZSkNCiB0aGVuIHRoZSBleGlzdGVuY2UgYW5kIHZhbHVlIG9m IHRoZSBhcHBsaWVkIGVxdWl2YWxlbnQgb2YgdGhlIG5vZGUgKHdoZXRoZXIgdGhhdCBiZSBhIGNv cnJlc3BvbmRpbmcgbm9kZSBpbiB0aGUgZGF0YSBtb2RlbCwgYW4gYXR0cmlidXRlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgaW50ZW5kZWQgY29uZmlnIG5vZGUsIHRoZSBjb25maWd1cmF0aW9uIG5vZGUg cmVhZCBmcm9tIGEgZGlmZmVyZW50IGRhdGFzdG9yZSBvciBjb250ZXh0LCBldGMpIG11c3QNCiBt YXRjaCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBub2RlLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRlbXBsYXRl czombmJzcDsgUGVyaGFwcyB0ZW1wbGF0ZXMgKG5vdCBpbnN0YW5jZXMgb2YgdGhlIHRlbXBsYXRl LCBidXQgdGhlIHRlbXBsYXRlIGl0c2VsZikgYXJlIGFsd2F5cyBjb25zaWRlcmVkIGFzIOKAnGFw cGxpZWTigJ0gYXMgc29vbiBhcyB0aGV5IGFyZSBjb25maWd1cmVkID8mbmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QXV0by1kdXBsZXg6Jm5ic3A7IFRoZSBjb25maWd1cmVkIGR1cGxleCBzZXR0aW5nIGFuZCB0 aGUgbmVnb3RpYXRlZCByZXN1bHRpbmcgb3BlcmF0aW9uYWwgdmFsdWUgYXJlIHR3byBzZXBhcmF0 ZSBhbmQgaW5kZXBlbmRlbnQgbGVhdmVzIElNTy4mbmJzcDsgVGhlIGNvbmZpZ3VyZWQgZHVwbGV4 DQogc2V0dGluZyB3aWxsIGhhdmUgYm90aCBhbiBpbnRlbmRlZCB2aWV3IGFuZCBhbiBhcHBsaWVk IHZpZXcgKHdoaWNoIGFyZSBzZXBhcmF0ZSBhbiBpbmRlcGVuZGVudCBmcm9tIHRoZSBuZWdvdGlh dGVkIGR1cGxleCkuJm5ic3A7IEUuZy4gQWRtaW5EdXBsZXggKGludGVuZGVkICZhbXA7IGFwcGxp ZWQpIGFuZCBPcGVyRHVwbGV4IChwdXJlIOKAmGRlcml2ZWTigJkgc3RhdGUpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SeKAmW0gbm90IGZhbWlsaWFyIHdpdGggdGhlIHVzZS1kaGNwIGV4YW1wbGUuJm5ic3A7IEJ1dCBt YXliZSBhcyBzb29uIGFzIHRoZSBzeXN0ZW0gaXMgYWN0dWFsbHkg4oCcdXNpbmcgREhDUOKAnSBk b3duIG9uIHRoZSBsaW5lY2FyZHMgdGhlbiB0aGUgYXBwbGllZCB2YWx1ZSB3b3VsZCByZWZsZWN0 DQogdGhhdCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZSBhbGwgZGF0YSBtb2RlbHMgY29uZm9ybWluZyB0byAxRDom bmJzcDsgSWYgdGhlIHNvbHV0aW9uIGVuZHMgdXAgYmVpbmcgaW4gdGhlIHByb3RvY29scyAoaW5z dGVhZCBvZiB0aGUgbW9kZWxzKSB0aGVuIHRoZXJlIGFyZSBubyByZXF1aXJlbWVudHMgZm9yIG1v ZGVscy4mbmJzcDsgSWYNCiB0aGUgc29sdXRpb24gZW5kcyB1cCBiZWluZyBpbiB0aGUgbW9kZWxz IHRoZW4gSSBkb27igJl0IHRoaW5rIHdlIGNhbiBtYW5kYXRlIHRoYXQgKjxiPmFsbDwvYj4qIG1v ZGVscyBmb2xsb3cgdGhlc2UgcmVxdWlyZW1lbnRzLiZuYnNwOyBDb250cm9sbGVycy9jbGllbnRz IHdpbGwgaGF2ZSB0byBiZSBhYmxlIHRvIG1hbmFnZSBzeXN0ZW1zIHRoYXQgaGF2ZSBhIG1peCBv ZiDigJxvcHN0YXRlIGNvbXBsaWFudOKAnSBtb2R1bGVzIGFuZCBub24gY29tcGxpYW50IG1vZHVs ZXMuJm5ic3A7DQogT3BlcmF0b3JzIHdobyBhcmUga2VlbiBvbiB0aGVzZSByZXF1aXJlbWVudHMg d2lsbCBlbmNvdXJhZ2UgdGhlbSB0byBiZSBhZG9wdGVkIGJ5IGFzIG1hbnkgSUVURiBtb2R1bGVz IGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW1wbGVtZW50YXRpb24gZmVhc2liaWxpdHkgJmFtcDsg aW1wYWN0cyBpcyBzb21ldGhpbmcgdGhhdCB3ZeKAmWxsIG5lZWQgdG8gY29uc2lkZXIgYnV0IGZv ciBub3cgSeKAmW0gdHJ5aW5nIHRvIGlnbm9yZSB0aGF0IGFuZCBwdXJlbHkgY2xhcmlmeSB3aGF0 IGlzIGJlaW5nIHJlcXVlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphc29uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJp ZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBPY3RvYmVyIDAyLCAyMDE1IDE0OjExPGJyPg0KPGI+VG86PC9iPiBTdGVybmUsIEphc29u IChKYXNvbik8YnI+DQo8Yj5DYzo8L2I+IFJvYmVydCBXaWx0b247IFJhbmR5IFByZXN1aG47IG5l dG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gb3BzdGF0ZS1y ZXFzIGlzc3VlICMxIC0gRGVmaW5lL0NsYXJpZnkgJnF1b3Q7ZnVsbHkgc3luY2hyb25pemVkJnF1 b3Q7IGluICZxdW90O1JlcXVpcmVtZW50IDEuRCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFib3V0IHRoZSBkYXRhIG1vZGVscyB0aGF0IGRvIG5vdCBm b2xsb3cgMUQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAtIHRlbXBsYXRlczogdGhlIGludGVuZGVkIGRhdGEgbW9kZWwgYW5kIGFw cGxpZWQgZGF0YSBtb2RlbCBhcmUgZGlzam9pbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtICdhdXRvLWR1cGxleCcgY29ybmVyLWNh c2U6IHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZCBsZWFmIGFyZSB0aGUgc2FtZSwgYnV0IHRoZXk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgd2lsbCBuZXZlciBoYXZlIHRoZSBzYW1lIHZhbHVlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLSAndXNlLWRoY3AnIGNv cm5lci1jYXNlOiBpbnRlbmRlZCBjb25maWcganVzdCBlbmFibGVzIHNwZWNpZmljIGRlcml2ZWQg c3RhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gYmUgdXNlZDsgZGlzam9pbnQgZGF0YSBtb2RlbHM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZWJv ZHkgYXNrZWQgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIGF0IHRoZSBpbnRlcmltOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlIGludGVudCBv ZiB0aGlzIGdyb3VwIHRvIGxpbWl0IGFsbCBZQU5HIGRhdGEgbW9kZWxzIHN1Y2ggdGhhdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhleSBjb25m b3JtIHRvIDFEPyAoSU1PIHRoYXQgaXMgYSBub24tc3RhcnRlcik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PIHJlcXVpcmVtZW50IDFEIHBy ZXN1bWUgdGhhdCB0aGUgc29sdXRpb24gaW52b2x2ZXMgc2VwYXJhdGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9iamVjdHMgaW4gdGhlIFlBTkcg ZGF0YSBtb2RlbCBmb3IgaW50ZW5kZWQgYW5kIGFwcGxpZWQgc3RhdGVzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZXJlZm9yZSBpdCBp cyBhbiBpbnZhbGlkIHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pbmx5IHRoZSAyIHByb3RvY29sLWJhc2VkIHNvbHV0aW9u cyBhZGRyZXNzIHRoaXMgaXNzdWUgYnkgdXNpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBzYW1lIG9iamVjdCBpZGVudGlmaWVyIG5vIG1h dHRlciB3aGljaCBzdGF0ZSBpcyBiZWluZyBxdWVyaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDIsIDIwMTUgYXQgMTA6NDQgQU0sIFN0 ZXJuZSwgSmFzb24gKEphc29uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBhbGNh dGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNl bnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHdpdGggJnF1b3Q7ZS5nLiZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDtpLmUuJnF1 b3Q7LiZuYnNwOyBJJ20gc3VyZSB0aGVyZSBhcmUgbG90cyBvZiBvdGhlciBleGFtcGxlcyBvZiBz aXR1YXRpb25zIHdoZXJlIGludGVuZGVkIGNvbmZpZyBhbmQgYXBwbGllZCBjb25maWcgZG9uJ3Qg bWF0Y2ggd2hlbiB3ZSBjb25zaWRlciB0aGUgdmFyaWV0eSBvZiBzeXN0ZW1zIG91dCB0aGVyZSB0 aGF0IG1heSB1c2UgTkVUQ09ORi9ZQU5HLiZuYnNwOyBXZSBzaG91bGQNCiBpbmNsdWRlIHNvbWUg b2YgdGhlc2UgZXhhbXBsZXMgaW4gdGhlIGRyYWZ0IChpbiBzb21lIGluZm9ybWF0aW9uYWwgc2Vj dGlvbiBhbmQgaGF2ZSBhIHJlZmVyZW5jZS9wb2ludGVyIHRvIHRoZW0ganVzdCBhZnRlciB0aGUg ZGVmaW5pdGlvbikuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoaXMgdXBkYXRlZCBkZWZpbml0aW9u IGZvciAxLkQgZG9lcyBub3QgcHJlY2x1ZGUgdGhlIGFwcGxpZWQgY29uZmlnIG9iamVjdCBmcm9t IG1hdGNoaW5nIHRoZSBpbnRlbmRlZCAqYmVmb3JlKiBpdCBoYXMgYmVlbiBhcHBsaWVkLiZuYnNw OyBEbyB3ZSBuZWVkIHRvIGNsYXJpZnkgdGhhdCB3aXRoIHNvbWUgJnF1b3Q7Y29udmVyc2VseSZx dW90OyBjbGF1c2Ugb3IgaXMgdGhhdCBjbGVhciBlbm91Z2ggd2hlbiBjb25zaWRlcmluZyB0aGUg b3RoZXIgcmVxdWlyZW1lbnRzDQogPzxicj4NCjxicj4NCldlIHNob3VsZCBhbHNvIGNsZWFubHkg ZGVmaW5lICZxdW90O2FwcGxpZWQmcXVvdDsgKGFuZCBwcm92aWRlIGlsbHVzdHJhdGl2ZSBleGFt cGxlcyBvZiB3aGVuIHNvbWV0aGluZyBpcyBhbmQgaXMgbm90IGFwcGxpZWQpLiZuYnNwOyBTaG91 bGQgdGhhdCBiZSBhIHNlcGFyYXRlIGVtYWlsIHRocmVhZCA/PGJyPg0KPGJyPg0KSmFzb248YnI+ DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IG5ldG1v ZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbjxicj4NClNl bnQ6IEZyaWRheSwgT2N0b2JlciAwMiwgMjAxNSA1OjI0PGJyPg0KVG86IFJhbmR5IFByZXN1aG47 IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+ DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gb3BzdGF0ZS1yZXFzIGlzc3VlICMxIC0gRGVmaW5lL0Ns YXJpZnkgJnF1b3Q7ZnVsbHkgc3luY2hyb25pemVkJnF1b3Q7IGluICZxdW90O1JlcXVpcmVtZW50 IDEuRCZxdW90Ozxicj4NCjxicj4NCkhpIFJhbmR5LDxicj4NCjxicj4NCk9uIDAxLzEwLzIwMTUg MjM6MjcsIFJhbmR5IFByZXN1aG4gd3JvdGU6PGJyPg0KJmd0OyBIaSAtPGJyPg0KJmd0Ozxicj4N CiZndDsmZ3Q7IEZyb206IFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9u QGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IFNlbnQ6 IE9jdCAxLCAyMDE1IDEwOjAxIEFNPGJyPg0KJmd0OyZndDsgVG86ICZxdW90OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgU3ViamVjdDogW25ldG1vZF0gb3BzdGF0ZS1yZXFzIGlzc3VlICMxIC0gRGVmaW5l L0NsYXJpZnkgJnF1b3Q7ZnVsbHkgc3luY2hyb25pemVkJnF1b3Q7IGluICZxdW90O1JlcXVpcmVt ZW50IDEuRCZxdW90Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVG8gY2xhcmlmeSB3aGF0 IEkgZmFpbGVkIHRvIGVsb3F1ZW50bHkgZXhwcmVzcyBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBwcm9wb3NlIGNoYW5naW5nIHRoZSB0ZXh0IGZv ciByZXF1aXJlbWVudCAxLkQuIFRoaXMgYWxzbyByZW1vdmVzPGJyPg0KJmd0OyZndDsgdGhlIG5l ZWQgdG8gZGVmaW5lIHdoYXQgZnVsbHkgc3luY2hyb25pemVkIG1lYW5zLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbGQgdGV4dCBmb3IgMS5EPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RC4mbmJzcDsgRm9yIGFzeW5jaHJv bm91cyBzeXN0ZW1zLCB3aGVuIGZ1bGx5IHN5bmNocm9uaXplZCwgdGhlIGRhdGE8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luIHRo ZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgdGhlIHNhbWUgYXMgdGhlIGRhdGEgaW4gdGhlPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbnRlbmRlZCBjb25maWd1cmF0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBQcm9wb3NlZCB0ZXh0IGZvciAxLkQ6PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RC4mbmJzcDsgV2hlbiB0aGUgY29uZmlndXJhdGlvbiBj aGFuZ2UgZm9yIGFueSBpbnRlbmRlZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiBsZWFmIGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBhcHBsaWVkIHRvIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3lzdGVtIChpLmUuIG5vdCBmYWlsZWQsIG5v ciBkZWZlcnJlZCBkdWUgdG8gYWJzZW50IGhhcmR3YXJlKTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlbiB0aGUgZXhpc3RlbmNl IGFuZCB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmF0aW9u IGxlYWYgbXVzdCBtYXRjaCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbjxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZi48YnI+ DQomZ3Q7IEFyZSAmcXVvdDtub3QgZmFpbGVkJnF1b3Q7IGFuZCAmcXVvdDtkZWZlcnJlZCBkdWUg dG8gYWJzZW50IGhhcmR3YXJlJnF1b3Q7IHRoZTxicj4NCiZndDsgKm9ubHkqIHBvc3NpYmlsaXRp ZXM/Jm5ic3A7IElmIG5vdCwgdGhlbiB0aGUgJnF1b3Q7aS5lLiZxdW90OyBuZWVkcyB0byBiZSBy ZXBsYWNlZDxicj4NCiZndDsgd2l0aCBhbiAmcXVvdDtlLmcuJnF1b3Q7PGJyPg0KSSdtIG5vdCBz dXJlIGlmIGl0IGlzIHRoZSBvbmx5IHBvc3NpYmlsaXR5LiZuYnNwOyBUd28gb3RoZXIgcG9zc2li bGUgcmVhc29uIG1pZ2h0IGJlOjxicj4NCiZuYnNwOyAtIENvbmZpZ3VyYXRpb24gdGhhdCBjYW5u b3QgYmUgYXBwbGllZCBiZWNhdXNlIHNvbWUgZGVwZW5kZW50IGNvbmZpZ3VyYXRpb24gaGFzbid0 IGJlZW4gYXBwbGllZC4mbmJzcDsgKEUuZy4gaWYgeW91IGhhdmUgY29uZmlndXJhdGlvbiB3aGVy ZSBhbiBpbnRlcmZhY2UtcmVmIGNvdWxkbid0IGJlIGZ1bGZpbGxlZCBiZWNhdXNlIHRoZSByZWZl cmVuY2VkIGludGVyZmFjZSBjb25maWd1cmF0aW9uIGhhZG4ndCBiZWVuIGFwcGxpZWQgYmVjYXVz ZSBlaXRoZXINCiBpdCBoYWQgZmFpbGVkIG9yIGJlZW4gZGVmZXJyZWQgZHVlIHRvIGFic2VudCBo YXJkd2FyZSkuJm5ic3A7IEJ1dCBwZXJoYXBzIHRoaXMgd291bGQgYmUgY2xhc3NpZmllZCBhcyBi ZWluZyBvbmUgb2YgdGhlIHR3byBjYXNlcyBhYm92ZT88YnI+DQombmJzcDsgLSBUaGVyZSBpcyBh bHNvIHRoZSBjYXNlIHRoZSBjb25maWd1cmF0aW9uIGlzIGN1cnJlbnRseSBpbiB0aGUgcHJvY2Vz cyBvZiBiZWluZyBhcHBsaWVkLjxicj4NCjxicj4NCklmIGl0IGlzIGFncmVlZCB0aGF0IGdpdGh1 YiBpc3N1ZSAjMiAoaS5lLiAmcXVvdDtJcyB0aGVyZSBhIHJlcXVpcmVtZW50IHRvIGluZGljYXRl IHdoeSBpbnRlbmRlZCBjb25maWcgIT0gYXBwbGllZCBjZmc/JnF1b3Q7KSBpcyBhIHZhbGlkIHJl cXVpcmVtZW50LCBhbmQgSSB0aGluayB0aGF0IHRoZXJlIG1pZ2h0IGhhdmUgYmVlbiBzb21lIHN1 cHBvcnQgZm9yIHRoaXMgaW4gdGhlIGludGVyaW0gbWVldGluZyB5ZXN0ZXJkYXksIHRoZW4gSSB3 b3VsZCBob3BlIHRoYXQNCiB0aGUgZmluYWwgc29sdXRpb24gd291bGQgZW51bWVyYXRlIHRoZSBy ZWFzb25zIHdoeSB0aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIG1heSBub3QgbWF0Y2ggdGhlIGlu dGVuZGVkIGNvbmZpZ3VyYXRpb24uPGJyPg0KPGJyPg0KQXMgc3VjaCwgY2hhbmdpbmcgZnJvbSBp LmUuIHRvIGUuZy4gc2VlbXMgbGlrZSBhIGdvb2QgY2hvaWNlLjxicj4NCjxicj4NClNvIGFsc28g dGFraW5nIGludG8gYWNjb3VudCBNYXJ0aW4ncyBzdWdnZXN0aW9uIHRoZSB1cGRhdGVkIHByb3Bv c2VkIHRleHQgZm9yIDEuRCB3b3VsZCBiZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgRC4mbmJzcDsgV2hlbiB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2UgZm9yIGFueSBp bnRlbmRlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNv bmZpZ3VyYXRpb24gbm9kZSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgYXBwbGllZCB0byB0aGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzeXN0ZW0gKGUuZy4g bm90IGZhaWxlZCwgbm9yIGRlZmVycmVkIGR1ZSB0byBhYnNlbnQgaGFyZHdhcmUpPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlbiB0aGUgZXhpc3RlbmNl IGFuZCB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uZmlndXJhdGlvbiBub2RlIG11c3QgbWF0 Y2ggdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBub2RlLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSb2I8YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSYW5keTxicj4NCiZndDs8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBu ZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu b3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCiZndDsgLjxicj4N CiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1v ZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt b2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A125E53CE190A749957C19483DC79F9F5CACCF88US70TWXCHMBA11z_-- From nobody Fri Oct 2 12:59:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6021A887E for ; Fri, 2 Oct 2015 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a04LhISFdOli for ; Fri, 2 Oct 2015 12:59:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9540E1A8879 for ; Fri, 2 Oct 2015 12:59:48 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 26046A5C9A723; Fri, 2 Oct 2015 19:59:43 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t92Jxi79007304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Oct 2015 19:59:44 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 2 Oct 2015 15:59:44 -0400 From: "Sterne, Jason (Jason)" To: "Lisa (Yi) Huang" , "netmod@ietf.org" Thread-Topic: [netmod] ACL Model 03 - ACL Type should be mandatory Thread-Index: AQHQ9yE2yvAvmExmc0av6Oc3Yl9U6p5YqtoQ Date: Fri, 2 Oct 2015 19:59:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 19:59:52 -0000 Thanks Lisa. Are you also planning to split the acl-type into: ipv4-acl ipv6-acl eth-acl ? That matches how most ACLs are managed today and is also more in sync with = the ace-type choice statement. Regards, Jason -----Original Message----- From: Lisa (Yi) Huang [mailto:lyihuang@juniper.net]=20 Sent: Friday, September 25, 2015 12:35 To: Sterne, Jason (Jason); netmod@ietf.org Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory Jason, We investigate your proposal and will add acl-type as key to acl list in ou= r next version of draft. acl in the draft. list acl { key "acl-type acl-name"; ... Leaf acl-name {.} leaf acl-type {...} ... } Thanks, Lisa On 9/20/15, 1:23 PM, "netmod on behalf of Sterne, Jason (Jason)" wrote: >Hi all, > >I met with Dean at IETF93 and we agreed that I should send a specific=20 >proposal to the list for this. Here it is: > >----------------------------------------------------- >Replace the following current snippets from model-03: >----------------------------------------------------- > >list acl { > key "acl-name"; > ... >} > >leaf acl-type { > type acl-type; > description > "It is recommended to have an Access Control List with > uniform access list entries, all of the same type. When > this type is not explicitly specified, if vendor > implementation permits, the access control entries > in the list can be mixed, > by containing L2, L3 and L4 entries"; } > >identity ip-acl { > base acl:acl-base; > description > "IP Access Control List is a common name for lists that contain > layer 3 and/or layer 4 match conditions."; } > >identity eth-acl { > base acl:acl-base; > description > "Ethernet Access Control List is name for layer 2 Ethernet > technology Access Control List types, like 10/100/1000baseT or > WiFi Access Control List"; >} > >-------------------- >with the following: >-------------------- > >list acl { > key "acl-type acl-name"; > ... >} >(note this is similar construct to the routing model: > list routing-protocol {key "type name"... ) > >leaf acl-type { > type acl-type; > description > "Type of access control list. Indicates the primary intended > type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) > used in the list instance."; >} > >identity ipv4-acl { > base acl:acl-base; > description=20 > "ACL that primarily matches on fields from the IPv4 header > (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP=20 >destination > port). An acl of type ipv4-acl does not contain matches on fields in > the ethernet header or the IPv6 header."; } > >identity ipv6-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields from the IPv6 header > (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP=20 >destination > port). An acl of type ipv6-acl does not contain matches on fields in > the ethernet header or the IPv4 header."; } > =20 >identity eth-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields in the ethernet header. > An acl of type eth-acl does not contain matches on fields in > the IPv4 header, IPv6 header or layer 4 headers."; } > > >--------------------------------------- >Potential future augmentation of type: >---------------------------------------- > >For future mixed types vendors (or the ietf) could augment the=20 >acl-type-base with types like the following: > > identity mixed-l3-acl { > base "access-control-list:acl-type-base"; > description "ACL that contains a mix of entries that primarily=20 >match on fields > in IPv4 headers and entries that primarily match on fields in=20 >IPv6 headers. > Matching on layer 4 header fields may also exist in the list. > An acl of type mixed-l3-acl does not contain matches on fields in > the ethernet header."; > } >=20 > identity mixed-l2-l3-acl { > base "access-control-list:acl-type-base"; > description "ACL that contains a mix of entries that primarily=20 >match on fields > in ethernet headers, entries that primarily match on fields in=20 >IPv4 headers, > and entries that primarily match on fields in IPv6 headers. >Matching on layer 4 > header fields may also exist in the list."; > } > >Regards, >Jason > >-----Original Message----- >From: Sterne, Jason (Jason) >Sent: Sunday, July 19, 2015 12:58 >To: Sterne, Jason (Jason); netmod@ietf.org >Subject: RE: ACL Model 03 - ACL Type should be mandatory > >Given the data models below in some of the major implementations it=20 >also seems like we should also (re-)consider having the 'type' as part=20 >of the ACL key ("type name"). > >In all those cases below it looks like an operator can currently=20 >configure two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the=20 >same name/id via their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL=20 >called "my-acl"). > >How would those lists be read in a via the ietf ACL YANG=20 >modules ? We'd all have to mangle the names and reserve special=20 >names/prefix-chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them=20 >back to a NC client. I'm not sure if there is much of a disadvantage=20 >of just having type in the key (assuming it is mandatory as advocated belo= w). > >I also looked briefly at the Brocade YANG models on github. It looks=20 >like they have multiple lists as well for v4 vs v6 (and even or=20 >different types of normal vs extended ACLs - that could be handled by=20 >augmenting the type with a 'v4-extended' type for example). > >Regards, >Jason > >-----Original Message----- >From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne,=20 >Jason >(Jason) >Sent: Friday, July 17, 2015 23:35 >To: netmod@ietf.org >Subject: [netmod] ACL Model 03 - ACL Type should be mandatory > >Hi all, > >I think we need to revisit this discussion about how ACL type works in=20 >draft-ietf-netmod-acl-model-03. > >It should be mandatory and we should separate v4 from v6. Vendors can=20 >augment for future "mixed" types (or maybe we should make an if-feature=20 >for a "mixed" type now that means "anything goes"). > >We should follow existing common implementations for this in order to=20 >foster better adoption. > >Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of=20 >specifying the list: >ipv4 access-list >ipv6 access-list >=20 >Junos has separate lists for v4 and v6: >access-list ... >ipv6 access-list ... >=20 >ALU SR OS has separate lists for v4, v6 and mac: >config filter ip-filter >config filter ipv6-filter >config filter mac-filter >=20 >Huawei uses separate lists for v4 and v6: >acl number 3000 >acl ipv6 number 3000 > >Please see below with [>>JTS] > >Regards, >Jason > >-----Original Message----- >From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >Sent: Monday, June 01, 2015 17:00 >To: Nabil Michraf >Cc: netmod@ietf.org >Subject: Re: [netmod] mandatory ACL type (was "comments on=20 >acl-model-02") > >Hi, > > >That appears to be the current version on the data-tracker. >I agree with you that the access-control-list-type leaf should be=20 >mandatory. > >I noticed that the example in Figure 2 has an extra 'top' >container and the namespace for 'access-lists' is missing. > > >Andy > >On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf=20 > >wrote: >> Hi all, >> >> Can you please clarify if we are talking about=20 >> https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some=20 >> other draft? >> I just want to make sure I am looking at the right ACL model version. >> >> Thank you, >> Nabil >> >> On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair)=20 >> >> wrote: >>> >>> >>> >>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)" >>> wrote: >>> >>> >Hi guys, >>> > >>> >Extracting my comments about ACL type into its own thread. I saw=20 >>> >Martin also had some comments on this topic. >>> > >>> >The ACL type was mandatory in an older version of the draft and I=20 >>> >think we should put it back as mandatory. Implementations that=20 >>> >don't *need* that leaf value can work fine whether they get it=20 >>> >during ACL creation or not but some implementations need to know=20 >>> >the >>>type. >>> >>> We don=B9t want to make the ACL type mandatory because then we have to= =20 >>> a create a new type for every combination of match criteria. The=20 >>> model should support any combination of match criteria with typing=20 >>> optional to map to pre-existing implementations. This is a tradeoff=20 >>> between making the model backward compatible with existing=20 >>> implementations but make it flexible enough so that a new match=20 >>> criteria doesn=B9t require a new type. > >[>>JTS] We can just create a "mixed" (i.e. unspecified) type and put it=20 >under an if-feature. Existing implementations have a single type (and=20 >require knowing the type at list creation time). > >>> >>> > >>> >It would also be good to create separate identities for=20 >>> >IPv4-access-control-list and IPv6-access-control-list instead of=20 >>> >bundling them into IP-access-control-list. If we're separating into=20 >>> >types in the model it should be the 3 basic types in the base model: >>>v4, v6 and enet. >>> >>> A vendor specific augmentation/implementation could do this, but the=20 >>> model needs to support inclusion of ipv4 and ipv6 in the same acl. >>> I=B9m aware of outstanding customers requests for combining ipv4 rules= =20 >>> and ipv6 rules in the same acl, but most implementations have not=20 >>> caught up to this. When it comes to managing acls there shouldn=B9t=20 >>> be this distinction between IPv6 and IPv4. They are both IP addresses. > > >[>>JTS] Again - let's focus on capturing common existing=20 >implementations in these standard models (while also allowing for=20 >augmentation and flexibility). V4 and V6 are in separate lists today. =20 >A future mixed list can use the "mixed" type or invent a new "v4+v6" type. > >>> >>> > >>> >That would also help if we decide to put some constraints that=20 >>> >allow/disallow certain matching criteria when the type is a=20 >>> >specific value (e.g. don't allow a v6 address match in a v4 list). >>> > We'd have to be careful about how those constraints are=20 >>> >formulated though - especially if we want to allow augmentations of=20 >>> >the list-type for "mixed" ACLs. A new "mixed-v4-enet" type=20 >>> >(identity) would also need to use the destination-ipv4-network=20 >>> >matching criteria (can "when" or "must" logic be changed by an augment= ation ? >>>I'm not sure that works). >>> >>> Yes, would have to be careful, and defining constraints based on=20 >>>existing >>> implementations could be a very slippery slope. Vendors should be >>>able >>> to map to their implementations and/or have a proprietary =20 >>>augmentation that constrains things more according to >>> their implementation. Proprietary augmentations could be proposed, >>>and >>> reviewed for standardization. > > >[>>JTS] The draft doesn't have any constraints based on type so I=20 >suppose this point is moot. > >>> >>> thanks, >>> Dana >>> >>> > >>> >Regards, >>> >Jason >>> > >>> > >>> >_______________________________________________ >>> >netmod mailing list >>> >netmod@ietf.org >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Oct 2 13:07:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23EF1A92B4 for ; Fri, 2 Oct 2015 13:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD8a0XAEHYL3 for ; Fri, 2 Oct 2015 13:07:39 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 2260A1A90D4 for ; Fri, 2 Oct 2015 13:07:39 -0700 (PDT) Received: by laer8 with SMTP id r8so98353339lae.2 for ; Fri, 02 Oct 2015 13:07:37 -0700 (PDT) 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=cFLt7PZNm4t36V2n2ILHRS/84r8GErpxWfZxdBOqSK8=; b=cUFDdz76w+m9M7itUiuCkBpSDzF2JB1RFNfWeZZgUFnioRMRVcFNS6htc8BcZxbFap 1I2QOO0K7CQ+Nn1Ht1k6fJUCNxiwmXYPyIejUV2t+4HUk5vhzhiejIjYjy49iiYqYbIH rI8+FOt1alq3LuwSzH7lqo5nZ9RppzX/r8qz9xwnDqWwDzDYWUWZpvpv4Y6KK5Rppe5v N4X9pUunj9tShh0GORp1P4I7e/FY6ft8nUGcKsuPdYPE8sl8TdelH42TtOqsOraPVy9c 3t12Um21xmehaj0Ir1Ryc1GNb3b8Mz6iSJE2hNduZVtKP0klxKDuWdIy1QqWhLF9QdKs t29w== X-Gm-Message-State: ALoCoQnu4AITwUnUil9Xpl8nmf7Uur0DeAE+AS1R54UvW4xwT25Vnv0NXrpdI1lHxZ71FmLBgw+7 MIME-Version: 1.0 X-Received: by 10.25.218.205 with SMTP id r196mr4060109lfg.82.1443816457247; Fri, 02 Oct 2015 13:07:37 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Fri, 2 Oct 2015 13:07:37 -0700 (PDT) In-Reply-To: References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> Date: Fri, 2 Oct 2015 13:07:37 -0700 Message-ID: From: Andy Bierman To: "Sterne, Jason (Jason)" Content-Type: multipart/alternative; boundary=001a114021540e3b29052124b760 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:07:43 -0000 --001a114021540e3b29052124b760 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 2, 2015 at 12:37 PM, Sterne, Jason (Jason) < jason.sterne@alcatel-lucent.com> wrote: > Good point that the wording does imply separate objects in the YANG data > model. We should try to adjust the wording so that it could apply to oth= er > solutions (e.g. attributes, different datastore, etc). Perhaps the > following ? > > > > When the configuration change for any intended configuration node has bee= n > successfully applied to the system (e.g. not failed, nor deferred due to > absent hardware) then the existence and value of the applied equivalent o= f > the node (whether that be a corresponding node in the data model, an > attribute associated with the intended config node, the configuration nod= e > read from a different datastore or context, etc) must match the intended > configuration node. > > > > Templates: Perhaps templates (not instances of the template, but the > template itself) are always considered as =E2=80=9Capplied=E2=80=9D as so= on as they are > configured ? > > > > Auto-duplex: The configured duplex setting and the negotiated resulting > operational value are two separate and independent leaves IMO. The > configured duplex setting will have both an intended view and an applied > view (which are separate an independent from the negotiated duplex). E.g= . > AdminDuplex (intended & applied) and OperDuplex (pure =E2=80=98derived=E2= =80=99 state). > > > > I=E2=80=99m not familiar with the use-dhcp example. But maybe as soon as= the > system is actually =E2=80=9Cusing DHCP=E2=80=9D down on the linecards the= n the applied > value would reflect that ? > > > This is really a derivative of the template case. The data models are different for config=3Dtrue and config=3Dfalse. The config=3Dtrue knob does not match the operational state at all. E.g., set a boolean leaf to select DHCP instead of the config=3Dtrue IP addresses. Then use a different data model to read the DHCP Lease info and get the assigned IP address. This is similar to the admin-state/oper-state use-case. Only the description-stmt in the admin-state object says "go look at oper-state for the real value". Andy Re all data models conforming to 1D: If the solution ends up being in the > protocols (instead of the models) then there are no requirements for > models. If the solution ends up being in the models then I don=E2=80=99t= think we > can mandate that **all** models follow these requirements. > Controllers/clients will have to be able to manage systems that have a mi= x > of =E2=80=9Copstate compliant=E2=80=9D modules and non compliant modules.= Operators who > are keen on these requirements will encourage them to be adopted by as ma= ny > IETF modules as possible. > > > > Implementation feasibility & impacts is something that we=E2=80=99ll need= to > consider but for now I=E2=80=99m trying to ignore that and purely clarify= what is > being requested. > > > > Jason > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Friday, October 02, 2015 14:11 > *To:* Sterne, Jason (Jason) > *Cc:* Robert Wilton; Randy Presuhn; netmod@ietf.org > *Subject:* Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > > > Hi, > > > > What about the data models that do not follow 1D? > > > > - templates: the intended data model and applied data model are disjoin= t > > - 'auto-duplex' corner-case: the intended and applied leaf are the same= , > but they > > will never have the same value > > - 'use-dhcp' corner-case: intended config just enables specific derived > state > > to be used; disjoint data models > > > > Somebody asked an important question at the interim: > > Is the intent of this group to limit all YANG data models such that > > they conform to 1D? (IMO that is a non-starter) > > > > IMO requirement 1D presume that the solution involves separate > > objects in the YANG data model for intended and applied states, > > and therefore it is an invalid requirement. > > > > Only the 2 protocol-based solutions address this issue by using > > the same object identifier no matter which state is being queried. > > > > > > > > Andy > > > > On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) < > jason.sterne@alcatel-lucent.com> wrote: > > I agree with "e.g." rather than "i.e.". I'm sure there are lots of other > examples of situations where intended config and applied config don't mat= ch > when we consider the variety of systems out there that may use > NETCONF/YANG. We should include some of these examples in the draft (in > some informational section and have a reference/pointer to them just afte= r > the definition). > > Note that this updated definition for 1.D does not preclude the applied > config object from matching the intended *before* it has been applied. D= o > we need to clarify that with some "conversely" clause or is that clear > enough when considering the other requirements ? > > We should also cleanly define "applied" (and provide illustrative example= s > of when something is and is not applied). Should that be a separate emai= l > thread ? > > Jason > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton > Sent: Friday, October 02, 2015 5:24 > To: Randy Presuhn; netmod@ietf.org > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > Hi Randy, > > On 01/10/2015 23:27, Randy Presuhn wrote: > > Hi - > > > >> From: Robert Wilton > >> Sent: Oct 1, 2015 10:01 AM > >> To: "netmod@ietf.org" > >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > >> > >> To clarify what I failed to eloquently express in the interim meeting. > >> > >> I propose changing the text for requirement 1.D. This also removes > >> the need to define what fully synchronized means. > >> > >> > >> Old text for 1.D > >> D. For asynchronous systems, when fully synchronized, the dat= a > >> in the applied configuration is the same as the data in th= e > >> intended configuration. > >> > >> > >> Proposed text for 1.D: > >> D. When the configuration change for any intended > >> configuration leaf has been successfully applied to the > >> system (i.e. not failed, nor deferred due to absent > hardware) > >> then the existence and value of the corresponding applied > >> configuration leaf must match the intended configuration > >> leaf. > > Are "not failed" and "deferred due to absent hardware" the > > *only* possibilities? If not, then the "i.e." needs to be replaced > > with an "e.g." > I'm not sure if it is the only possibility. Two other possible reason > might be: > - Configuration that cannot be applied because some dependent > configuration hasn't been applied. (E.g. if you have configuration where > an interface-ref couldn't be fulfilled because the referenced interface > configuration hadn't been applied because either it had failed or been > deferred due to absent hardware). But perhaps this would be classified a= s > being one of the two cases above? > - There is also the case the configuration is currently in the process > of being applied. > > If it is agreed that github issue #2 (i.e. "Is there a requirement to > indicate why intended config !=3D applied cfg?") is a valid requirement, = and > I think that there might have been some support for this in the interim > meeting yesterday, then I would hope that the final solution would > enumerate the reasons why the applied configuration may not match the > intended configuration. > > As such, changing from i.e. to e.g. seems like a good choice. > > So also taking into account Martin's suggestion the updated proposed text > for 1.D would be: > > D. When the configuration change for any intended > configuration node has been successfully applied to the > system (e.g. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding applied > configuration node must match the intended configuration > node. > > Thanks, > Rob > > > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a114021540e3b29052124b760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 2, 2015 at 12:37 PM, Sterne, Jason (Jason) <= jason.sterne@alcatel-lucent.com> wrote:

Good point that the wordi= ng does imply separate objects in the YANG data model.=C2=A0 We should try = to adjust the wording so that it could apply to other solutions (e.g. attributes, different datastore, etc).=C2=A0 =C2=A0Perhaps the follo= wing ?

=C2=A0

When the configuration ch= ange for any intended configuration node has been successfully applied to t= he system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the applied equivalent of the node (whethe= r that be a corresponding node in the data model, an attribute associated w= ith the intended config node, the configuration node read from a different = datastore or context, etc) must match the intended configuration node.

=C2=A0

Templates:=C2=A0 Perhaps = templates (not instances of the template, but the template itself) are alwa= ys considered as =E2=80=9Capplied=E2=80=9D as soon as they are configured ?= =C2=A0

=C2=A0

Auto-duplex:=C2=A0 The co= nfigured duplex setting and the negotiated resulting operational value are = two separate and independent leaves IMO.=C2=A0 The configured duplex setting will have both an intended view and an applied view (which are sep= arate an independent from the negotiated duplex).=C2=A0 E.g. AdminDuplex (i= ntended & applied) and OperDuplex (pure =E2=80=98derived=E2=80=99 state= ).

=C2=A0

I=E2=80=99m not familiar = with the use-dhcp example.=C2=A0 But maybe as soon as the system is actuall= y =E2=80=9Cusing DHCP=E2=80=9D down on the linecards then the applied value= would reflect that ?

=C2=A0

<= /div>


This is really a= derivative of the template case.
The data models are different f= or config=3Dtrue and config=3Dfalse.

The config=3D= true knob does not match the operational state at all.
E.g., set = a boolean leaf to select DHCP instead of the config=3Dtrue IP addresses.
Then use a different data model to read the DHCP Lease info and get= the assigned IP address.
This is similar to the admin-state/oper= -state use-case.=C2=A0 Only the description-stmt
in the admin-sta= te object says "go look at oper-state for the real value".
<= div>

=C2=A0Andy


<= /div>

<= /span>

Re all data models confor= ming to 1D:=C2=A0 If the solution ends up being in the protocols (instead o= f the models) then there are no requirements for models.=C2=A0 If the solution ends up being in the models then I don=E2=80=99t think we can= mandate that *all* models follow these requirements.=C2=A0 Controll= ers/clients will have to be able to manage systems that have a mix of =E2= =80=9Copstate compliant=E2=80=9D modules and non compliant modules.=C2=A0 Operators who are keen on these requirements will encourage them to be ado= pted by as many IETF modules as possible.

=C2=A0

Implementation feasibilit= y & impacts is something that we=E2=80=99ll need to consider but for no= w I=E2=80=99m trying to ignore that and purely clarify what is being reques= ted.

=C2=A0

Jason

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Friday, October 02, 2015 14:11
To: Sterne, Jason (Jason)
Cc: Robert Wilton; Randy Presuhn; netmod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "f= ully synchronized" in "Requirement 1.D"=

=C2=A0

Hi,

=C2=A0

What about the data models that do not follow 1D?=

=C2=A0

=C2=A0 - templates: the intended data model and appl= ied data model are disjoint

=C2=A0 - 'auto-duplex' corner-case: the inte= nded and applied leaf are the same, but they

=C2=A0 =C2=A0 will never have the same value<= u>

=C2=A0 - 'use-dhcp' corner-case: intended co= nfig just enables specific derived state

=C2=A0 =C2=A0 =C2=A0to be used; disjoint data models=

=C2=A0

Somebody asked an important question at the interim:=

Is the intent of this group to limit all YANG data m= odels such that

they conform to 1D? (IMO that is a non-starter)

=C2=A0

IMO requirement 1D presume that the solution involve= s separate

objects in the YANG data model for intended and appl= ied states,

and therefore it is an invalid requirement.

=C2=A0

Only the 2 protocol-based solutions address this iss= ue by using

the same object identifier no matter which state is = being queried.

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jaso= n) <jason.sterne@alcatel-lucent.com> wrote:

I agree with "e.g." rather than "i.e.= ".=C2=A0 I'm sure there are lots of other examples of situations w= here intended config and applied config don't match when we consider th= e variety of systems out there that may use NETCONF/YANG.=C2=A0 We should include some of these examples in the draft (in some informational section= and have a reference/pointer to them just after the definition).

Note that this updated definition for 1.D does not preclude the applied con= fig object from matching the intended *before* it has been applied.=C2=A0 D= o we need to clarify that with some "conversely" clause or is tha= t clear enough when considering the other requirements ?

We should also cleanly define "applied" (and provide illustrative= examples of when something is and is not applied).=C2=A0 Should that be a = separate email thread ?

Jason


-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; net= mod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully sy= nchronized" in "Requirement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwilton@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "net= mod@ietf.org" <netmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "ful= ly synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meet= ing.
>>
>> I propose changing the text for requirement 1.D. This also removes=
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 For asynchronous systems= , when fully synchronized, the data
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the applied conf= iguration is the same as the data in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended configurat= ion.
>>
>>
>> Proposed text for 1.D:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 When the configuration c= hange for any intended
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration leaf = has been successfully applied to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0system (i.e. not fa= iled, nor deferred due to absent hardware)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the existence = and value of the corresponding applied
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration leaf = must match the intended configuration
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf.
> Are "not failed" and "deferred due to absent hardware&q= uot; the
> *only* possibilities?=C2=A0 If not, then the "i.e." needs to= be replaced
> with an "e.g."
I'm not sure if it is the only possibility.=C2=A0 Two other possible re= ason might be:
=C2=A0 - Configuration that cannot be applied because some dependent config= uration hasn't been applied.=C2=A0 (E.g. if you have configuration wher= e an interface-ref couldn't be fulfilled because the referenced interfa= ce configuration hadn't been applied because either it had failed or been deferred due to absent hardware).=C2=A0 But perhaps = this would be classified as being one of the two cases above?
=C2=A0 - There is also the case the configuration is currently in the proce= ss of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to = indicate why intended config !=3D applied cfg?") is a valid requiremen= t, and I think that there might have been some support for this in the inte= rim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configurati= on may not match the intended configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed te= xt for 1.D would be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 When the configuration change for any = intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration node has been succe= ssfully applied to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 system (e.g. not failed, nor defe= rred due to absent hardware)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the existence and value of t= he corresponding applied
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration node must match the= intended configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node.

Thanks,
Rob


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

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

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

=C2=A0


--001a114021540e3b29052124b760-- From nobody Fri Oct 2 13:08:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0051D1B2AB3 for ; Fri, 2 Oct 2015 13:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJtEic0Hjn6u for ; Fri, 2 Oct 2015 13:07:48 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538A31B2A06 for ; Fri, 2 Oct 2015 13:07:48 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id A64504CD5CD69 for ; Fri, 2 Oct 2015 20:07:42 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t92K7itO020693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Oct 2015 20:07:44 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 2 Oct 2015 16:07:44 -0400 From: "Sterne, Jason (Jason)" To: "Sterne, Jason (Jason)" , "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-acl-model-03: remove time-range and put input-interface behind an if-feature Thread-Index: AdDCSmd3mYKQXXKSQAekT07WIMveDA7AoRwA Date: Fri, 2 Oct 2015 20:07:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CACD0B7US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: [netmod] draft-ietf-netmod-acl-model-03: remove time-range and put input-interface behind an if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:07:57 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CACD0B7US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (splitting point (A) out of the "RE: [netmod] A few other misc. comments on= draft-ietf-netmod-acl-model-03" thread) Hi all, I'd propose we remove time-range from the model for a number of reasons: 1) I don't think we should build individual time-range functions all o= ver the place in individual modules (likely in slightly different ways). I= f we want time-range type functions then I think we should define that in a= more generic way that can apply to any configuration items and keep it out= of individual modules. 2) Maybe time range functions are more appropriate up in the client/co= ntroller layer anyways 3) This is not standard base functionality that is uniformly supported= in devices that use ACLs The remaining meta-data item (input-interface) should probably also be remo= ved (same reason #3 as above). At minimum it should an if-feature. Regards, Jason From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (J= ason) Sent: Sunday, July 19, 2015 13:43 To: netmod@ietf.org Subject: [netmod] A few other misc. comments on draft-ietf-netmod-acl-model= -03 Hi all, I brought up ACL types and ACE numerical IDs in other separate email thread= s. This one is for a set of other misc. comments (one functional, the rest= are more editorial). A) Please make the metadata optional with an if-feature (or make each of in= put-interface & time-range their own if-features - that is probably better)= . Or drop those out of the model and leave them to augmentations. If we= do keep input-interface in the model as an if-feature then: - should we import ietf-interfaces with just the prefix"if" ? That is the = prefix in the ietf-interfaces module and what is used in the routing model = for example. - shouldn't the input-interface be a leafref (e.g. if:interface-ref) ? [>>JTS] ...snip... --_000_A125E53CE190A749957C19483DC79F9F5CACD0B7US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(splitting point (A) out = of the “RE: [netmod] A few other misc. comments on   &= nbsp; draft-ietf-netmod-acl-model-03” thread)

 <= /p>

Hi all,=

 <= /p>

I’d propose we remo= ve time-range from the model for a number of reasons:

1) = ;     I don’t thi= nk we should build individual time-range functions all over the place in in= dividual modules (likely in slightly different ways).  If we want time-range type functions then I think we should define that in a mor= e generic way that can apply to any configuration items and keep it out of = individual modules.

2) = ;     Maybe time range = functions are more appropriate up in the client/controller layer anyways

3) = ;     This is not stand= ard base functionality that is uniformly supported in devices that use ACLs=

 <= /p>

The remaining meta-data i= tem (input-interface) should probably also be removed (same reason #3 as ab= ove).  At minimum it should an if-feature.

 <= /p>

Regards,

Jason

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (Jason)
Sent: Sunday, July 19, 2015 13:43
To: netmod@ietf.org
Subject: [netmod] A few other misc. comments on draft-ietf-netmod-ac= l-model-03

 

Hi all,

 

I brought up ACL types and ACE numerica= l IDs in other separate email threads.  This one is for a set of other= misc. comments (one functional, the rest are more editorial).

 

A) Please make the metadata optional wi= th an if-feature (or make each of input-interface & time-range their ow= n if-features – that is probably better).  Or drop those out of the model and leave them to augmentations.    If we do k= eep input-interface in the model as an if-feature then:

- should we import ietf-interfaces with= just the prefix"if" ?  That is the prefix in the ietf-inter= faces module and what is used in the routing model for example.<= /span>

- shouldn’t the input-interface b= e a leafref (e.g. if:interface-ref) ?

 

[>>JTS] …snip…

 

--_000_A125E53CE190A749957C19483DC79F9F5CACD0B7US70TWXCHMBA11z_-- From nobody Fri Oct 2 13:17:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73D1B2D0C for ; Fri, 2 Oct 2015 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s36VpGk77X_E for ; Fri, 2 Oct 2015 13:17:10 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140C51B2D09 for ; Fri, 2 Oct 2015 13:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22734; q=dns/txt; s=iport; t=1443817030; x=1445026630; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Z4khjs8J6CMOd/3Etig3zKsBY4DqT/kSaVhGwIt1n9M=; b=QuKfgZVI5iCfvJl7mO7bHrs0+pdPyN2zuXDfg56635pPNfd+6zlaXegY 0oWOzsnsE/G1Idh+O5xxBVyZmSCKs86ntcUgOBAbXW/gAfFmmpiVlcNpU 0W8gD6TtPFjByxIt2veR2Ynhd3zqabKDOPvW10RKImBQv581E2JNisCg+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DLAQDk5Q5W/xbLJq1eg3tuvgQBDYFxAQmFL0oCgW4UAQEBAQEBAYEKhCQBAQEDAQEBASBLCgEMBAkCEQQBAQEJDAoIAwICCQMCAQIBFR8JCAYNBgIBAReICwgNmWmdLJRBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R+hCoLBgFRBwYEgl+BQwWHNIcCh0aNF4FWhDiDAJJVHwEBQoJEgT89M4gwCBeBKQEBAQ X-IronPort-AV: E=Sophos;i="5.17,624,1437436800"; d="scan'208,217";a="630097788" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Oct 2015 20:17:06 +0000 Received: from [10.61.78.118] (ams3-vpn-dhcp3702.cisco.com [10.61.78.118]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t92KGq5X012954; Fri, 2 Oct 2015 20:16:52 GMT To: Andy Bierman , "Sterne, Jason (Jason)" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> From: Robert Wilton Message-ID: <560EE633.5060707@cisco.com> Date: Fri, 2 Oct 2015 21:16:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030407030801000207090103" Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:17:14 -0000 This is a multi-part message in MIME format. --------------030407030801000207090103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only used to indicate whether the configuration represented by the intended-cfg leaf has been applied. But it appears that my proposed text for 1D may have caused some confusion. Please see inline ... On 02/10/2015 19:11, Andy Bierman wrote: > Hi, > > What about the data models that do not follow 1D? > > - templates: the intended data model and applied data model are disjoint This came up towards the end of the interim, and my understanding is that it acceptable for any templating solution to have to adhere to that constraint above. > - 'auto-duplex' corner-case: the intended and applied leaf are the > same, but they > will never have the same value The intention is: - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be determined by auto-negotiation) - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by auto-negotiation) - related derived-state duplex-state leaf = "full" or "half" or "unknown" (always represents the actual duplex setting of the interface) > - 'use-dhcp' corner-case: intended config just enables specific > derived state > to be used; disjoint data models Similarly: - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP addresses) - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP addresses) - related derived-state IP address leaf = A.B.C.D (Primary IP address in use for the interface - if any). > > Somebody asked an important question at the interim: > Is the intent of this group to limit all YANG data models such that > they conform to 1D? (IMO that is a non-starter) It is not my intention that my proposed 1D text makes are constraint on the structure of YANG data models. > > IMO requirement 1D presume that the solution involves separate > objects in the YANG data model for intended and applied states, > and therefore it is an invalid requirement. That is not the intention of my phrasing, perhaps it needs further refinement? The intention is that a config node has two notional states in the data store, intended and applied. The aim is to tightly relate those two notional states as to when they are allowed to be the same or different. > > Only the 2 protocol-based solutions address this issue by using > the same object identifier no matter which state is being queried. I don't think that this requirement excludes any of the three solutions that have been proposed (or the use of attribute to return intended vs applied state metadata). Thanks, Rob > > > > Andy > > On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) > > wrote: > > I agree with "e.g." rather than "i.e.". I'm sure there are lots > of other examples of situations where intended config and applied > config don't match when we consider the variety of systems out > there that may use NETCONF/YANG. We should include some of these > examples in the draft (in some informational section and have a > reference/pointer to them just after the definition). > > Note that this updated definition for 1.D does not preclude the > applied config object from matching the intended *before* it has > been applied. Do we need to clarify that with some "conversely" > clause or is that clear enough when considering the other > requirements ? > > We should also cleanly define "applied" (and provide illustrative > examples of when something is and is not applied). Should that be > a separate email thread ? > > Jason > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org > ] On Behalf Of Robert Wilton > Sent: Friday, October 02, 2015 5:24 > To: Randy Presuhn; netmod@ietf.org > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify > "fully synchronized" in "Requirement 1.D" > > Hi Randy, > > On 01/10/2015 23:27, Randy Presuhn wrote: > > Hi - > > > >> From: Robert Wilton > > >> Sent: Oct 1, 2015 10:01 AM > >> To: "netmod@ietf.org " > > >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > >> > >> To clarify what I failed to eloquently express in the interim > meeting. > >> > >> I propose changing the text for requirement 1.D. This also removes > >> the need to define what fully synchronized means. > >> > >> > >> Old text for 1.D > >> D. For asynchronous systems, when fully synchronized, > the data > >> in the applied configuration is the same as the > data in the > >> intended configuration. > >> > >> > >> Proposed text for 1.D: > >> D. When the configuration change for any intended > >> configuration leaf has been successfully applied to the > >> system (i.e. not failed, nor deferred due to absent > hardware) > >> then the existence and value of the corresponding > applied > >> configuration leaf must match the intended > configuration > >> leaf. > > Are "not failed" and "deferred due to absent hardware" the > > *only* possibilities? If not, then the "i.e." needs to be replaced > > with an "e.g." > I'm not sure if it is the only possibility. Two other possible > reason might be: > - Configuration that cannot be applied because some dependent > configuration hasn't been applied. (E.g. if you have > configuration where an interface-ref couldn't be fulfilled because > the referenced interface configuration hadn't been applied because > either it had failed or been deferred due to absent hardware). > But perhaps this would be classified as being one of the two cases > above? > - There is also the case the configuration is currently in the > process of being applied. > > If it is agreed that github issue #2 (i.e. "Is there a requirement > to indicate why intended config != applied cfg?") is a valid > requirement, and I think that there might have been some support > for this in the interim meeting yesterday, then I would hope that > the final solution would enumerate the reasons why the applied > configuration may not match the intended configuration. > > As such, changing from i.e. to e.g. seems like a good choice. > > So also taking into account Martin's suggestion the updated > proposed text for 1.D would be: > > D. When the configuration change for any intended > configuration node has been successfully applied to the > system (e.g. not failed, nor deferred due to absent > hardware) > then the existence and value of the corresponding applied > configuration node must match the intended configuration > node. > > Thanks, > Rob > > > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------030407030801000207090103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only used to indicate whether the configuration represented by the intended-cfg leaf has been applied.

But it appears that my proposed text for 1D may have caused some confusion.  Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
Hi,

What about the data models that do not follow 1D?

  - templates: the intended data model and applied data model are disjoint

This came up towards the end of the interim, and my understanding is that it acceptable for any templating solution to have to adhere to that constraint above.


  - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they
    will never have the same value
The intention is:
  - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be determined by auto-negotiation)
  - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by auto-negotiation)
  - related derived-state duplex-state leaf = "full" or "half" or "unknown" (always represents the actual duplex setting of the interface)

  - 'use-dhcp' corner-case: intended config just enables specific derived state
     to be used; disjoint data models
Similarly:
  - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP addresses)
  - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP addresses)
  - related derived-state IP address leaf = A.B.C.D (Primary IP address in use for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refinement?

The intention is that a config node has two notional states in the data store, intended and applied.  The aim is to tightly relate those two notional states as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions that have been proposed (or the use of attribute to return intended vs applied state metadata).

Thanks,
Rob





Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
I agree with "e.g." rather than "i.e.".  I'm sure there are lots of other examples of situations where intended config and applied config don't match when we consider the variety of systems out there that may use NETCONF/YANG.  We should include some of these examples in the draft (in some informational section and have a reference/pointer to them just after the definition).

Note that this updated definition for 1.D does not preclude the applied config object from matching the intended *before* it has been applied.  Do we need to clarify that with some "conversely" clause or is that clear enough when considering the other requirements ?

We should also cleanly define "applied" (and provide illustrative examples of when something is and is not applied).  Should that be a separate email thread ?

Jason


-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; netmod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwilton@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org" <netmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meeting.
>>
>> I propose changing the text for requirement 1.D. This also removes
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>         D.  For asynchronous systems, when fully synchronized, the data
>>             in the applied configuration is the same as the data in the
>>             intended configuration.
>>
>>
>> Proposed text for 1.D:
>>         D.  When the configuration change for any intended
>>             configuration leaf has been successfully applied to the
>>             system (i.e. not failed, nor deferred due to absent hardware)
>>             then the existence and value of the corresponding applied
>>             configuration leaf must match the intended configuration
>>             leaf.
> Are "not failed" and "deferred due to absent hardware" the
> *only* possibilities?  If not, then the "i.e." needs to be replaced
> with an "e.g."
I'm not sure if it is the only possibility.  Two other possible reason might be:
  - Configuration that cannot be applied because some dependent configuration hasn't been applied.  (E.g. if you have configuration where an interface-ref couldn't be fulfilled because the referenced interface configuration hadn't been applied because either it had failed or been deferred due to absent hardware).  But perhaps this would be classified as being one of the two cases above?
  - There is also the case the configuration is currently in the process of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to indicate why intended config != applied cfg?") is a valid requirement, and I think that there might have been some support for this in the interim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configuration may not match the intended configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed text for 1.D would be:

        D.  When the configuration change for any intended
            configuration node has been successfully applied to the
            system (e.g. not failed, nor deferred due to absent hardware)
            then the existence and value of the corresponding applied
            configuration node must match the intended configuration
            node.

Thanks,
Rob


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

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

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


--------------030407030801000207090103-- From nobody Sat Oct 3 08:38:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABC41B2ABC for ; Sat, 3 Oct 2015 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqaIbfWG9HWK for ; Sat, 3 Oct 2015 08:38:53 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 D86721B2ABD for ; Sat, 3 Oct 2015 08:38:52 -0700 (PDT) Received: by labzv5 with SMTP id zv5so106396317lab.1 for ; Sat, 03 Oct 2015 08:38:51 -0700 (PDT) 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=udWdit4HRzZfilTC28wyRf4njf2Ss/Ulfglc4fOcedg=; b=GViBGxVGvK7q+L90mVtdCJEcbYbS1VKRF4ClkRpttaIy57cO5rgldJHe6teglT9Qhc fLK9Hu7n0cXCKW2Mpr6gT5MiH6YSxYB99WwBSKe9UrfJcMsuszmyPpsAcqD5KeuI6dhZ BHK1l8zPAppmjBIROb5x3SZKY50lkWaIjBmxQRZ/oGoAx+BSkH6gdkQnzkDzvsb0pjqe fuaSKDlJsh1inWX2qMiRXDaz1P7aJxIcmraZ7S8R20H6vZjZvZOohqu80zqQ/j0S6mWE AZoI9n2wvTVi0RX92XH/PcDqV4iAcPrZ66Qn3RqreH9/5hwH5Em+wdLCxZL8YS8fPjqy gYUQ== X-Gm-Message-State: ALoCoQn7vBdRL8MWUpitLmVVP2VnsHPPQbDTpcDKfufExNppDMJVkKybVC4LfVibOB3YHsJXYpK2 MIME-Version: 1.0 X-Received: by 10.112.132.100 with SMTP id ot4mr7582163lbb.37.1443886730793; Sat, 03 Oct 2015 08:38:50 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Sat, 3 Oct 2015 08:38:50 -0700 (PDT) In-Reply-To: <560EE633.5060707@cisco.com> References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> Date: Sat, 3 Oct 2015 08:38:50 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=047d7b34382eaf7272052135136a Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 15:38:57 -0000 --047d7b34382eaf7272052135136a Content-Type: text/plain; charset=UTF-8 Hi, So the applied leaf is being used as a complicated boolean? IMO your draft (using attributes similar to with-defaults=report-all-tagged, not containers) is the best compromise because: - the data models are not touched - no datastores are required - the same string is used to identify the data node no matter what state needs to be checked - client has to request the metadata somehow so no impact on clients that do not care about this issue - a single boolean attribute applied="true" is all that is really needed Andy On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton wrote: > Hi Andy, > > It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is > only used to indicate whether the configuration represented by the > intended-cfg leaf has been applied. > > But it appears that my proposed text for 1D may have caused some > confusion. Please see inline ... > > On 02/10/2015 19:11, Andy Bierman wrote: > > Hi, > > What about the data models that do not follow 1D? > > - templates: the intended data model and applied data model are disjoint > > > This came up towards the end of the interim, and my understanding is that > it acceptable for any templating solution to have to adhere to that > constraint above. > > > - 'auto-duplex' corner-case: the intended and applied leaf are the same, > but they > will never have the same value > > The intention is: > - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be > determined by auto-negotiation) > - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by > auto-negotiation) > - related derived-state duplex-state leaf = "full" or "half" or > "unknown" (always represents the actual duplex setting of the interface) > > - 'use-dhcp' corner-case: intended config just enables specific derived > state > to be used; disjoint data models > > Similarly: > - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned > IP addresses) > - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to > assign IP addresses) > - related derived-state IP address leaf = A.B.C.D (Primary IP address in > use for the interface - if any). > > > > Somebody asked an important question at the interim: > Is the intent of this group to limit all YANG data models such that > they conform to 1D? (IMO that is a non-starter) > > It is not my intention that my proposed 1D text makes are constraint on > the structure of YANG data models. > > > IMO requirement 1D presume that the solution involves separate > objects in the YANG data model for intended and applied states, > and therefore it is an invalid requirement. > > > That is not the intention of my phrasing, perhaps it needs further > refinement? > > The intention is that a config node has two notional states in the data > store, intended and applied. The aim is to tightly relate those two > notional states as to when they are allowed to be the same or different. > > > Only the 2 protocol-based solutions address this issue by using > the same object identifier no matter which state is being queried. > > I don't think that this requirement excludes any of the three solutions > that have been proposed (or the use of attribute to return intended vs > applied state metadata). > > Thanks, > Rob > > > > > > Andy > > On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) < > jason.sterne@alcatel-lucent.com> wrote: > >> I agree with "e.g." rather than "i.e.". I'm sure there are lots of other >> examples of situations where intended config and applied config don't match >> when we consider the variety of systems out there that may use >> NETCONF/YANG. We should include some of these examples in the draft (in >> some informational section and have a reference/pointer to them just after >> the definition). >> >> Note that this updated definition for 1.D does not preclude the applied >> config object from matching the intended *before* it has been applied. Do >> we need to clarify that with some "conversely" clause or is that clear >> enough when considering the other requirements ? >> >> We should also cleanly define "applied" (and provide illustrative >> examples of when something is and is not applied). Should that be a >> separate email thread ? >> >> Jason >> >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton >> Sent: Friday, October 02, 2015 5:24 >> To: Randy Presuhn; netmod@ietf.org >> Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully >> synchronized" in "Requirement 1.D" >> >> Hi Randy, >> >> On 01/10/2015 23:27, Randy Presuhn wrote: >> > Hi - >> > >> >> From: Robert Wilton < rwilton@cisco.com> >> >> Sent: Oct 1, 2015 10:01 AM >> >> To: "netmod@ietf.org" >> >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully >> synchronized" in "Requirement 1.D" >> >> >> >> To clarify what I failed to eloquently express in the interim meeting. >> >> >> >> I propose changing the text for requirement 1.D. This also removes >> >> the need to define what fully synchronized means. >> >> >> >> >> >> Old text for 1.D >> >> D. For asynchronous systems, when fully synchronized, the data >> >> in the applied configuration is the same as the data in the >> >> intended configuration. >> >> >> >> >> >> Proposed text for 1.D: >> >> D. When the configuration change for any intended >> >> configuration leaf has been successfully applied to the >> >> system (i.e. not failed, nor deferred due to absent >> hardware) >> >> then the existence and value of the corresponding applied >> >> configuration leaf must match the intended configuration >> >> leaf. >> > Are "not failed" and "deferred due to absent hardware" the >> > *only* possibilities? If not, then the "i.e." needs to be replaced >> > with an "e.g." >> I'm not sure if it is the only possibility. Two other possible reason >> might be: >> - Configuration that cannot be applied because some dependent >> configuration hasn't been applied. (E.g. if you have configuration where >> an interface-ref couldn't be fulfilled because the referenced interface >> configuration hadn't been applied because either it had failed or been >> deferred due to absent hardware). But perhaps this would be classified as >> being one of the two cases above? >> - There is also the case the configuration is currently in the process >> of being applied. >> >> If it is agreed that github issue #2 (i.e. "Is there a requirement to >> indicate why intended config != applied cfg?") is a valid requirement, and >> I think that there might have been some support for this in the interim >> meeting yesterday, then I would hope that the final solution would >> enumerate the reasons why the applied configuration may not match the >> intended configuration. >> >> As such, changing from i.e. to e.g. seems like a good choice. >> >> So also taking into account Martin's suggestion the updated proposed text >> for 1.D would be: >> >> D. When the configuration change for any intended >> configuration node has been successfully applied to the >> system (e.g. not failed, nor deferred due to absent hardware) >> then the existence and value of the corresponding applied >> configuration node must match the intended configuration >> node. >> >> Thanks, >> Rob >> >> >> > >> > Randy >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> > . >> > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > --047d7b34382eaf7272052135136a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

So the applied leaf is being used a= s a complicated boolean?

IMO your draft (using attributes similar to with-defaults=3Dreport-a= ll-tagged,
not containers) is the best compromise because:
<= div>
=C2=A0 =C2=A0- the data models are not touched
=C2=A0 =C2=A0- no datastores are required
=C2=A0 =C2=A0- the sam= e string is used to identify the data node no matter what
=C2=A0 = =C2=A0 =C2=A0state needs to be checked
=C2=A0 =C2=A0- client has = to request the metadata somehow so no impact
=C2=A0 =C2=A0 =C2=A0= on clients that do not care about this issue
=C2=A0 =C2=A0- a sin= gle boolean attribute applied=3D"true" is all that is really need= ed



Andy


On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <rwilton@cisco.c= om> wrote:
=20 =20 =20
Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only used to indicate whether the configuration represented by the intended-cfg leaf has been applied.

But it appears that my proposed text for 1D may have caused some confusion.=C2=A0 Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
=20
Hi,

What about the data models that do not follow 1D?

=C2=A0 - templates: the intended data model and applied data model are disjoint

This came up towards the end of the interim, and my understanding is that it acceptable for any templating solution to have to adhere to that constraint above.


=C2=A0 - 'auto-duplex' corner-case: the intended and a= pplied leaf are the same, but they
=C2=A0 =C2=A0 will never have the same value
The intention is:
=C2=A0 - intended-cfg duplex leaf =3D "auto" (i.e. operator w= ants duplex to be determined by auto-negotiation)
=C2=A0 - applied-cfg duplex leaf =3D "auto" (i.e. device will= determine duplex by auto-negotiation)
=C2=A0 - related derived-state duplex-state leaf =3D "full" o= r "half" or "unknown" (always represents the actual duplex setting of the interface)

=C2=A0 - 'use-dhcp' corner-case: intended config just = enables specific derived state
=C2=A0 =C2=A0 =C2=A0to be used; disjoint data models
Similarly:
=C2=A0 - intended-cfg use-dhcp leaf =3D "true" (i.e. operator= wants DHCP assigned IP addresses)
=C2=A0 - applied-cfg use-dhcp leaf =3D "true" (i.e. system is= using DHCP to assign IP addresses)
=C2=A0 - related derived-state IP address leaf =3D A.B.C.D (Primary IP address in use for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refinement?

The intention is that a config node has two notional states in the data store, intended and applied.=C2=A0 The aim is to tightly relate those two notional states as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions that have been proposed (or the use of attribute to return intended vs applied state metadata).

Thanks,
Rob





Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-luce= nt.com> wrote:
I agree with "e.g." rather than "i.e.".= =C2=A0 I'm sure there are lots of other examples of situations where intended config and applied config don't match when we consider the variety of systems out there that may use NETCONF/YANG.=C2=A0 We should include some of these example= s in the draft (in some informational section and have a reference/pointer to them just after the definition).

Note that this updated definition for 1.D does not preclude the applied config object from matching the intended *before* it has been applied.=C2=A0 Do we need to clarify that with some "conversely" clause or is = that clear enough when considering the other requirements ?

We should also cleanly define "applied" (and prov= ide illustrative examples of when something is and is not applied).=C2=A0 Should that be a separate email thread ?
Jason


-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; netmod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requ= irement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwilton@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org" <ne= tmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requ= irement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meeting.
>>
>> I propose changing the text for requirement 1.D. This also removes
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 For asyn= chronous systems, when fully synchronized, the data
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in = the applied configuration is the same as the data in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int= ended configuration.
>>
>>
>> Proposed text for 1.D:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D.=C2=A0 When the= configuration change for any intended
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0con= figuration leaf has been successfully applied to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sys= tem (i.e. not failed, nor deferred due to absent hardware)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the= n the existence and value of the corresponding applied
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0con= figuration leaf must match the intended configuration
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lea= f.
> Are "not failed" and "deferred due to a= bsent hardware" the
> *only* possibilities?=C2=A0 If not, then the "i.e= ." needs to be replaced
> with an "e.g."
I'm not sure if it is the only possibility.=C2=A0 Two o= ther possible reason might be:
=C2=A0 - Configuration that cannot be applied because some dependent configuration hasn't been applied.=C2=A0 (E.g= . if you have configuration where an interface-ref couldn't be fulfilled because the referenced interface configuration hadn't been applied because either it had failed or been deferred due to absent hardware).=C2=A0 But perhaps this would be classified as being one of the two cases above?
=C2=A0 - There is also the case the configuration is currently in the process of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to indicate why intended config !=3D applied cfg?") is a valid requirement, and I think that there might have been some support for this in the interim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configuration may not match the intended configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed text for 1.D would be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 When the configuration= change for any intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration nod= e has been successfully applied to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 system (e.g. not = failed, nor deferred due to absent hardware)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the existenc= e and value of the corresponding applied
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration nod= e must match the intended configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node.

Thanks,
Rob


>
> Randy
>
> _______________________________________________
> netmod mailing list
> n= etmod@ietf.org
> https://www.ietf.org/mailman/listin= fo/netmod
> .
>

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

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



--047d7b34382eaf7272052135136a-- From nobody Mon Oct 5 02:08:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050F31B4E7A for ; Mon, 5 Oct 2015 02:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JnEmS7XGTdF for ; Mon, 5 Oct 2015 02:08:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2E81B4E50 for ; Mon, 5 Oct 2015 02:08:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C22489D for ; Mon, 5 Oct 2015 11:08:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cHr--x3VjUD9 for ; Mon, 5 Oct 2015 11:08:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 5 Oct 2015 11:08:22 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA9BA20053 for ; Mon, 5 Oct 2015 11:08:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kae0wZQ73LUh; Mon, 5 Oct 2015 11:08:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3C602004E; Mon, 5 Oct 2015 11:08:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A4239377CFE8; Mon, 5 Oct 2015 11:08:19 +0200 (CEST) Date: Mon, 5 Oct 2015 11:08:18 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151005090818.GA37274@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] today's (2015-10-05) virtual interim on YANG 1.1 cancelled X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:08:28 -0000 Hi, I decided to cancel today's YANG 1.1 virtual interim meeting. Note that the YANG 1.1 specification https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07 is in WG last call until Monday October 12, 2015 at 13:00 CEST. You are encouraged to spent the hour gained today to review the document. We will likely use the YANG 1.1 virtual interim meeting on October 12 to go through the non-editorial issues that we track here: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/last-call-comments.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 5 02:16:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97691B4EB7 for ; Mon, 5 Oct 2015 02:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1azrblf4sF09 for ; Mon, 5 Oct 2015 02:16:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DD51B4EB5 for ; Mon, 5 Oct 2015 02:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5538; q=dns/txt; s=iport; t=1444036596; x=1445246196; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NOPkcoXpt5NVol3XxmP9prpM+295or4y1IHMIElihHU=; b=Gx5kNaUWzVnDgENNxwyEZRQAy57OMwHFc2kcSRw7SOnXWKb+P5W7LRH+ TvrCuR3MOMfwnQhEvtBPbUSik8+oBs0ICdevxwZonvMA0sAdsL9ZqHTF+ eTDbgol9+tGXF/lYYuwYbi89jHVvv0gszpoIjbvme3ONTxHKWsCaaIBIN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBAAxPxJW/xbLJq1UCYRpv3mGGgKBZBABAQEBAQEBgQqEJAEBAQQ4QBELEAUDCRYPCQMCAQIBRQcMBgIBAYgquysBAQEBAQUBAQEBAR2Gc4R+hDERUoQsAQSVfI0XiQ6SVTgrghEdgVU9M4g/AQEB X-IronPort-AV: E=Sophos;i="5.17,637,1437436800"; d="scan'208";a="612019485" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 05 Oct 2015 09:16:33 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t959GXgM004159; Mon, 5 Oct 2015 09:16:33 GMT To: netmod@ietf.org, j.schoenwaelder@jacobs-university.de References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local> <20150921082628.GA11184@elstar.local> <5602AE3A.9020902@cisco.com> From: Robert Wilton Message-ID: <56123FF1.6060004@cisco.com> Date: Mon, 5 Oct 2015 10:16:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5602AE3A.9020902@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:16:42 -0000 Hi Juergen, Did you get a chance to consider this proposed text for mandatory nodes at all? Thanks, Rob On 23/09/2015 14:50, Robert Wilton wrote: > Hi Juergen, > > On 21/09/2015 09:26, Juergen Schoenwaelder wrote: >> On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >>> >> Still some text needs to be written explaining that breaking old >> clients by adding new mandatory nodes is a no go. I did not ask to >> enumerate all situations where it is allowed, I am looking for text >> that clearly says what people have to look out for if they add >> mandatory nodes. > Would it be sufficient to just change the MUST NOT to SHOULD NOT and > then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which > seems to provide the explanation that you are requesting? > > E.g. something like: > > draft-ietf-netmod-rfc6020bis, section 7.17. The augment Statement > > From: > > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > To: > > If the target node is in another module, then nodes added by the > augmentation SHOULD NOT be mandatory nodes (see Section 3.1). The > safe scenarios to augment with mandatory nodes are described in > [draft-ietf-netmod-rfc6087bis] section 5.17.2. > > > For reference, I've also reproduced the text for > draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below: > > 5.17. Augment Statements > > The YANG "augment" statement is used to define a set of data > definition statements that will be added as child nodes of a target > data node. The module namespace for these data nodes will be the > augmenting module, not the augmented module. > > A top-level "augment" statement SHOULD NOT be used if the target data > node is in the same module or submodule as the evaluated "augment" > statement. The data definition statements SHOULD be added inline > instead. > > 5.17.1. Conditional Augment Statements > > The "augment" statement is often used together with the "when" > statement and/or "if-feature" statement to make the augmentation > conditional on some portion of the data model. > > The following example from [RFC7223] shows how a conditional > container called "ethernet" is added to the "interface" list only for > entries of the type "ethernetCsmacd". > > augment "/if:interfaces/if:interface" { > when "if:type = 'ianaift:ethernetCsmacd'"; > > container ethernet { > leaf duplex { > ... > } > } > } > > 5.17.2. Conditionally Mandatory Data Definition Statements > > YANG has very specific rules about how configuration data can be > updated in new releases of a module. These rules allow an "old > client" to continue interoperating with a "new server". > > If data nodes are added to an existing entry, the old client MUST NOT > be required to provide any mandatory parameters that were not in the > original module definition. > > It is possible to add conditional augment statements such that the > old client would not know about the new condition, and would not > specify the new condition. The conditional augment statement can > contain mandatory objects only if the condition is false unless > explicitly requested by the client. > > Only a conditional augment statement that uses the "when" statement > form of condition can be used in this manner. The YANG features > enabled on the server cannot be controlled by the client in any way, > so it is not safe to add mandatory augmenting data nodes based on the > "if-feature" statement. > > The XPath "when" statement condition MUST NOT reference data outside > of target data node because the client does not have any control over > this external data. > > In the following dummy example, it is OK to augment the "interface" > entry with "mandatory-leaf" because the augmentation depends on > support for "some-new-iftype". The old client does not know about > this type so it would never select this type, and therefore not be > adding a mandatory data node. > > module my-module { > ... > > identity some-new-iftype { > base iana:iana-interface-type; > } > > augment "/if:interfaces/if:interface" { > when "if:type = 'mymod:some-new-iftype'"; > > leaf mandatory-leaf { > mandatory true; > ... > } > } > } > > Note that this practice is safe only for creating data resources. It > is not safe for replacing or modifying resources if the client does > not know about the new condition. The YANG data model MUST be > packaged in a way that requires the client to be aware of the > mandatory data nodes if it is aware of the condition for this data. > In the example above, the "some-new-iftype" identity is defined in > the same module as the "mandatory-leaf" data definition statement. > > This practice is not safe for identities defined in a common module > such as "iana-if-type" because the client is not required to know > about "my-module" just because it knows about the "iana-if-type" > module. > > > > Rob > > >> >> /js >> > From nobody Mon Oct 5 02:32:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EE51B4EC3 for ; Mon, 5 Oct 2015 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHjelmynE6DZ for ; Mon, 5 Oct 2015 02:32:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE151B4EC4 for ; Mon, 5 Oct 2015 02:32:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7338D72F; Mon, 5 Oct 2015 11:32:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id L6wXMbCA-YyS; Mon, 5 Oct 2015 11:32:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Oct 2015 11:32:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAAC520057; Mon, 5 Oct 2015 11:32:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GyBfdyghcZcB; Mon, 5 Oct 2015 11:32:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC6B220053; Mon, 5 Oct 2015 11:32:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B189C377D0DD; Mon, 5 Oct 2015 11:32:09 +0200 (CEST) Date: Mon, 5 Oct 2015 11:32:09 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151005093208.GA37367@elstar.local> Mail-Followup-To: Robert Wilton , netmod@ietf.org References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local> <20150921082628.GA11184@elstar.local> <5602AE3A.9020902@cisco.com> <56123FF1.6060004@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56123FF1.6060004@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:32:18 -0000 Robert, I think this is listed as the first issue in our list of last call comments. /js On Mon, Oct 05, 2015 at 10:16:33AM +0100, Robert Wilton wrote: > Hi Juergen, > > Did you get a chance to consider this proposed text for mandatory nodes > at all? > > Thanks, > Rob > > > On 23/09/2015 14:50, Robert Wilton wrote: > >Hi Juergen, > > > >On 21/09/2015 09:26, Juergen Schoenwaelder wrote: > >>On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote: > >>>Juergen Schoenwaelder writes: > >>> > >>Still some text needs to be written explaining that breaking old > >>clients by adding new mandatory nodes is a no go. I did not ask to > >>enumerate all situations where it is allowed, I am looking for text > >>that clearly says what people have to look out for if they add > >>mandatory nodes. > >Would it be sufficient to just change the MUST NOT to SHOULD NOT and > >then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which > >seems to provide the explanation that you are requesting? > > > >E.g. something like: > > > >draft-ietf-netmod-rfc6020bis, section 7.17. The augment Statement > > > >From: > > > >If the target node is in another module, then nodes added by the > >augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > >To: > > > >If the target node is in another module, then nodes added by the > >augmentation SHOULD NOT be mandatory nodes (see Section 3.1). The > >safe scenarios to augment with mandatory nodes are described in > >[draft-ietf-netmod-rfc6087bis] section 5.17.2. > > > > > >For reference, I've also reproduced the text for > >draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below: > > > >5.17. Augment Statements > > > > The YANG "augment" statement is used to define a set of data > > definition statements that will be added as child nodes of a target > > data node. The module namespace for these data nodes will be the > > augmenting module, not the augmented module. > > > > A top-level "augment" statement SHOULD NOT be used if the target data > > node is in the same module or submodule as the evaluated "augment" > > statement. The data definition statements SHOULD be added inline > > instead. > > > >5.17.1. Conditional Augment Statements > > > > The "augment" statement is often used together with the "when" > > statement and/or "if-feature" statement to make the augmentation > > conditional on some portion of the data model. > > > > The following example from [RFC7223] shows how a conditional > > container called "ethernet" is added to the "interface" list only for > > entries of the type "ethernetCsmacd". > > > > augment "/if:interfaces/if:interface" { > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > container ethernet { > > leaf duplex { > > ... > > } > > } > > } > > > >5.17.2. Conditionally Mandatory Data Definition Statements > > > > YANG has very specific rules about how configuration data can be > > updated in new releases of a module. These rules allow an "old > > client" to continue interoperating with a "new server". > > > > If data nodes are added to an existing entry, the old client MUST NOT > > be required to provide any mandatory parameters that were not in the > > original module definition. > > > > It is possible to add conditional augment statements such that the > > old client would not know about the new condition, and would not > > specify the new condition. The conditional augment statement can > > contain mandatory objects only if the condition is false unless > > explicitly requested by the client. > > > > Only a conditional augment statement that uses the "when" statement > > form of condition can be used in this manner. The YANG features > > enabled on the server cannot be controlled by the client in any way, > > so it is not safe to add mandatory augmenting data nodes based on the > > "if-feature" statement. > > > > The XPath "when" statement condition MUST NOT reference data outside > > of target data node because the client does not have any control over > > this external data. > > > > In the following dummy example, it is OK to augment the "interface" > > entry with "mandatory-leaf" because the augmentation depends on > > support for "some-new-iftype". The old client does not know about > > this type so it would never select this type, and therefore not be > > adding a mandatory data node. > > > > module my-module { > > ... > > > > identity some-new-iftype { > > base iana:iana-interface-type; > > } > > > > augment "/if:interfaces/if:interface" { > > when "if:type = 'mymod:some-new-iftype'"; > > > > leaf mandatory-leaf { > > mandatory true; > > ... > > } > > } > > } > > > > Note that this practice is safe only for creating data resources. It > > is not safe for replacing or modifying resources if the client does > > not know about the new condition. The YANG data model MUST be > > packaged in a way that requires the client to be aware of the > > mandatory data nodes if it is aware of the condition for this data. > > In the example above, the "some-new-iftype" identity is defined in > > the same module as the "mandatory-leaf" data definition statement. > > > > This practice is not safe for identities defined in a common module > > such as "iana-if-type" because the client is not required to know > > about "my-module" just because it knows about the "iana-if-type" > > module. > > > > > > > >Rob > > > > > >> > >>/js > >> > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 5 02:46:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D317E1B4EE4 for ; Mon, 5 Oct 2015 02:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynNGKyB7e9_F for ; Mon, 5 Oct 2015 02:46:05 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A106C1B4EE3 for ; Mon, 5 Oct 2015 02:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6099; q=dns/txt; s=iport; t=1444038365; x=1445247965; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Ju7m0gpLp9jtbMTP9TdBe1js/v/9NYOetzF8b6T9eQ8=; b=RnxLms+ldx/nM0mW6e/5U3zBFEP8lJshxpy1QSAmWjMA9xiHEwlFond1 GuEJyQLzduYLSDaGIwIJrdkuMTd8h5g6yqY0Jxz8tP5o3JbtOTG+bp70M NOEjS5lX4pyPKFAVIPQ6xozKVxOogubgnEWbaIN1uJEoHrffE1w21ceSO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBABcRhJW/xbLJq1UCYRpv3mGGgKBZhABAQEBAQEBgQqEJAEBAQQ4QBELEAUDCRYPCQMCAQIBRRMGAgEBiCq7LwEBAQEGAQEBAR6Gc4R+hDERUoQsAQSSSYMzjReJDpJVOCuCER2BVT0ziD8BAQE X-IronPort-AV: E=Sophos;i="5.17,637,1437436800"; d="scan'208";a="630136019" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Oct 2015 09:46:03 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t959k2wm010092 for ; Mon, 5 Oct 2015 09:46:02 GMT To: netmod@ietf.org References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local> <20150921082628.GA11184@elstar.local> <5602AE3A.9020902@cisco.com> <56123FF1.6060004@cisco.com> <20151005093208.GA37367@elstar.local> From: Robert Wilton Message-ID: <561246DA.3050805@cisco.com> Date: Mon, 5 Oct 2015 10:46:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151005093208.GA37367@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:46:07 -0000 Thanks. Yes. I had missed that. Rob On 05/10/2015 10:32, Juergen Schoenwaelder wrote: > Robert, > > I think this is listed as the first issue in our list of last call > comments. > > /js > > On Mon, Oct 05, 2015 at 10:16:33AM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> Did you get a chance to consider this proposed text for mandatory nodes >> at all? >> >> Thanks, >> Rob >> >> >> On 23/09/2015 14:50, Robert Wilton wrote: >>> Hi Juergen, >>> >>> On 21/09/2015 09:26, Juergen Schoenwaelder wrote: >>>> On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote: >>>>> Juergen Schoenwaelder writes: >>>>> >>>> Still some text needs to be written explaining that breaking old >>>> clients by adding new mandatory nodes is a no go. I did not ask to >>>> enumerate all situations where it is allowed, I am looking for text >>>> that clearly says what people have to look out for if they add >>>> mandatory nodes. >>> Would it be sufficient to just change the MUST NOT to SHOULD NOT and >>> then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which >>> seems to provide the explanation that you are requesting? >>> >>> E.g. something like: >>> >>> draft-ietf-netmod-rfc6020bis, section 7.17. The augment Statement >>> >>> From: >>> >>> If the target node is in another module, then nodes added by the >>> augmentation MUST NOT be mandatory nodes (see Section 3.1). >>> >>> To: >>> >>> If the target node is in another module, then nodes added by the >>> augmentation SHOULD NOT be mandatory nodes (see Section 3.1). The >>> safe scenarios to augment with mandatory nodes are described in >>> [draft-ietf-netmod-rfc6087bis] section 5.17.2. >>> >>> >>> For reference, I've also reproduced the text for >>> draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below: >>> >>> 5.17. Augment Statements >>> >>> The YANG "augment" statement is used to define a set of data >>> definition statements that will be added as child nodes of a target >>> data node. The module namespace for these data nodes will be the >>> augmenting module, not the augmented module. >>> >>> A top-level "augment" statement SHOULD NOT be used if the target data >>> node is in the same module or submodule as the evaluated "augment" >>> statement. The data definition statements SHOULD be added inline >>> instead. >>> >>> 5.17.1. Conditional Augment Statements >>> >>> The "augment" statement is often used together with the "when" >>> statement and/or "if-feature" statement to make the augmentation >>> conditional on some portion of the data model. >>> >>> The following example from [RFC7223] shows how a conditional >>> container called "ethernet" is added to the "interface" list only for >>> entries of the type "ethernetCsmacd". >>> >>> augment "/if:interfaces/if:interface" { >>> when "if:type = 'ianaift:ethernetCsmacd'"; >>> >>> container ethernet { >>> leaf duplex { >>> ... >>> } >>> } >>> } >>> >>> 5.17.2. Conditionally Mandatory Data Definition Statements >>> >>> YANG has very specific rules about how configuration data can be >>> updated in new releases of a module. These rules allow an "old >>> client" to continue interoperating with a "new server". >>> >>> If data nodes are added to an existing entry, the old client MUST NOT >>> be required to provide any mandatory parameters that were not in the >>> original module definition. >>> >>> It is possible to add conditional augment statements such that the >>> old client would not know about the new condition, and would not >>> specify the new condition. The conditional augment statement can >>> contain mandatory objects only if the condition is false unless >>> explicitly requested by the client. >>> >>> Only a conditional augment statement that uses the "when" statement >>> form of condition can be used in this manner. The YANG features >>> enabled on the server cannot be controlled by the client in any way, >>> so it is not safe to add mandatory augmenting data nodes based on the >>> "if-feature" statement. >>> >>> The XPath "when" statement condition MUST NOT reference data outside >>> of target data node because the client does not have any control over >>> this external data. >>> >>> In the following dummy example, it is OK to augment the "interface" >>> entry with "mandatory-leaf" because the augmentation depends on >>> support for "some-new-iftype". The old client does not know about >>> this type so it would never select this type, and therefore not be >>> adding a mandatory data node. >>> >>> module my-module { >>> ... >>> >>> identity some-new-iftype { >>> base iana:iana-interface-type; >>> } >>> >>> augment "/if:interfaces/if:interface" { >>> when "if:type = 'mymod:some-new-iftype'"; >>> >>> leaf mandatory-leaf { >>> mandatory true; >>> ... >>> } >>> } >>> } >>> >>> Note that this practice is safe only for creating data resources. It >>> is not safe for replacing or modifying resources if the client does >>> not know about the new condition. The YANG data model MUST be >>> packaged in a way that requires the client to be aware of the >>> mandatory data nodes if it is aware of the condition for this data. >>> In the example above, the "some-new-iftype" identity is defined in >>> the same module as the "mandatory-leaf" data definition statement. >>> >>> This practice is not safe for identities defined in a common module >>> such as "iana-if-type" because the client is not required to know >>> about "my-module" just because it knows about the "iana-if-type" >>> module. >>> >>> >>> >>> Rob >>> >>> >>>> /js >>>> From nobody Mon Oct 5 02:48:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61771B4EE9 for ; Mon, 5 Oct 2015 02:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDiXM1cDxB-c for ; Mon, 5 Oct 2015 02:48:11 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD831B4EE7 for ; Mon, 5 Oct 2015 02:48:11 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BAE021CC0360; Mon, 5 Oct 2015 11:48:11 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 05 Oct 2015 11:48:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:48:13 -0000 Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Oct 1, 2015 12:24 AM >>To: Juergen Schoenwaelder >>Cc: Randy Presuhn , netmod@ietf.org >>Subject: Re: [netmod] 6020bis - anydata > ... >>Fine by me. So here is an updated proposal: >> >>OLD >> >> The "anydata" statement is used to represent an unknown set of nodes >> that can be modelled with YANG. An example of where this can be >> useful is a list of received notifications, where the exact >> notifications are not known as design time. >> >>NEW >> >> The "anydata" statement is used to represent an unknown set of nodes >> that can be modelled with YANG but for which the data model is not >> known at module design time. It is possible, though not required, for > > s/know/known/ > >> the data model for "anydata" content to become known through protocol >> signalling or other means that are outside the scope of this >> document, as is the server and client behaviour. > > I'd end the sentence at "document." The rest of the sentence doesn't > really add anything. > > There's still a big lump under the carpet, but no one else appears > concerned about it, so I'll desist from further comment. I am certainly concerned. The current definition of "anydata" ("an unknown set of nodes that can be modelled with YANG") is IMO insufficient because, for one, it doesn't even eliminate mixed content in XML, which can be modelled with YANG's "anyxml" statement. In my view, the idea behind "anydata" was that it would be possible to build a regular data (sub)tree from schema-less data. However, this seems to be difficult, at least on a server supporting both XML and JSON, and so benefits of "anydata" over "anyxml" are really questionable. Lada > > Randy > > _______________________________________________ > 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 Oct 5 02:57:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4256A1B4F08 for ; Mon, 5 Oct 2015 02:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY1zkl9qG2ww for ; Mon, 5 Oct 2015 02:57:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F821B4F06 for ; Mon, 5 Oct 2015 02:57:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CB5E38F1; Mon, 5 Oct 2015 11:57:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OvgaHjYIpWpJ; Mon, 5 Oct 2015 11:57:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Oct 2015 11:57:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF31D2004E; Mon, 5 Oct 2015 11:57:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8KjRnOJJDTql; Mon, 5 Oct 2015 11:57:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ECD720053; Mon, 5 Oct 2015 11:57:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 358DB377D148; Mon, 5 Oct 2015 11:57:11 +0200 (CEST) Date: Mon, 5 Oct 2015 11:57:11 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151005095710.GA37459@elstar.local> Mail-Followup-To: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org References: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:57:16 -0000 On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote: > I am certainly concerned. The current definition of "anydata" ("an > unknown set of nodes that can be modelled with YANG") is IMO > insufficient because, for one, it doesn't even eliminate mixed content > in XML, which can be modelled with YANG's "anyxml" statement. Good point. I think we should clarify that anyxml is excluded. > In my view, the idea behind "anydata" was that it would be possible to > build a regular data (sub)tree from schema-less data. However, this > seems to be difficult, at least on a server supporting both XML and > JSON, and so benefits of "anydata" over "anyxml" are really > questionable. I do not think anydata was driven by the idea to build a regular data (sub)tree from schema-less data. I think anydata works fine with both JSON and XML as long as the encoder has the data model, which seems to be a reasonable assumption for servers and perhaps also for data-model driven clients. The problem are any generic components in between clients and servers but that can also be seen as a problem of the encodings and not of anydata itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 5 04:32:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8931B1ABD3B for ; Mon, 5 Oct 2015 04:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh_n-s2s9w_l for ; Mon, 5 Oct 2015 04:32:46 -0700 (PDT) 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 5BD501ABD38 for ; Mon, 5 Oct 2015 04:32:46 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e57e:2dac:2c8a:323e] (unknown [IPv6:2001:718:1a02:1:e57e:2dac:2c8a:323e]) by mail.nic.cz (Postfix) with ESMTPSA id 61BD8181D8C; Mon, 5 Oct 2015 13:32:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444044764; bh=nWypkRZK+bYIy7MXwF9eJ5pEn9y1Qi+IC33iYTP2DJQ=; h=From:Date:To; b=j9NeKhlQGMQIGWKugsZBYHoj4pmPCDH5P20Bw7NeNmKdwTnd6eMdEw6a72dDWQoNs a9NeoMbX7bUiz+KtOqotTlfwrMMs0ZE6RvX5q4TYl3mU84uFZ6/KPl0yC1Y4bnGYhh XKJjOT4wAU14DhH9ARP3zCA/5PKeK17qwZUbn8e4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151005095710.GA37459@elstar.local> Date: Mon, 5 Oct 2015 13:32:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20151005095710.GA37459@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 11:32:48 -0000 > On 05 Oct 2015, at 11:57, Juergen Schoenwaelder = wrote: >=20 > On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote: >=20 >> I am certainly concerned. The current definition of "anydata" ("an >> unknown set of nodes that can be modelled with YANG") is IMO >> insufficient because, for one, it doesn't even eliminate mixed = content >> in XML, which can be modelled with YANG's "anyxml" statement. >=20 > Good point. I think we should clarify that anyxml is excluded. Then YANG extensions probably need to be excluded, too. >=20 >> In my view, the idea behind "anydata" was that it would be possible = to >> build a regular data (sub)tree from schema-less data. However, this >> seems to be difficult, at least on a server supporting both XML and >> JSON, and so benefits of "anydata" over "anyxml" are really >> questionable. >=20 > I do not think anydata was driven by the idea to build a regular data > (sub)tree from schema-less data. >=20 > I think anydata works fine with both JSON and XML as long as the > encoder has the data model, which seems to be a reasonable assumption If it is so, then what we really need is a standard mechanism that = allows for signalling the data model at run time. Without that, as Randy = pointed out, there is no way to make sure that the server and client use = the same data model for a particular =E2=80=9Canydata=E2=80=9D node, and = then the difference between =E2=80=9Canydata=E2=80=9D and =E2=80=9Canyxml=E2= =80=9D is no more interesting. All external means (or descriptions) that = may potentially provide =E2=80=9Clate binding=E2=80=9D of the data model = are applicable to =E2=80=9Canyxml=E2=80=9D as well. Lada > for servers and perhaps also for data-model driven clients. The > problem are any generic components in between clients and servers but > that can also be seen as a problem of the encodings and not of > anydata itself. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 5 04:44:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F741AC3BE for ; Mon, 5 Oct 2015 04:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwPmKvwvnSTR for ; Mon, 5 Oct 2015 04:44:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49051AC3DF for ; Mon, 5 Oct 2015 04:44:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6D33D787; Mon, 5 Oct 2015 13:44:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rY5zpSFFiDHM; Mon, 5 Oct 2015 13:44:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Oct 2015 13:44:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2386620053; Mon, 5 Oct 2015 13:44:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T7V_wXH2-PMM; Mon, 5 Oct 2015 13:44:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDE8C2004E; Mon, 5 Oct 2015 13:44:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 99E43377D388; Mon, 5 Oct 2015 13:44:15 +0200 (CEST) Date: Mon, 5 Oct 2015 13:44:15 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151005114415.GC37707@elstar.local> Mail-Followup-To: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org References: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20151005095710.GA37459@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 11:44:21 -0000 On Mon, Oct 05, 2015 at 01:32:46PM +0200, Ladislav Lhotka wrote: > > > On 05 Oct 2015, at 11:57, Juergen Schoenwaelder wrote: > > > > On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote: > > > >> I am certainly concerned. The current definition of "anydata" ("an > >> unknown set of nodes that can be modelled with YANG") is IMO > >> insufficient because, for one, it doesn't even eliminate mixed content > >> in XML, which can be modelled with YANG's "anyxml" statement. > > > > Good point. I think we should clarify that anyxml is excluded. > > Then YANG extensions probably need to be excluded, too. > > > > >> In my view, the idea behind "anydata" was that it would be possible to > >> build a regular data (sub)tree from schema-less data. However, this > >> seems to be difficult, at least on a server supporting both XML and > >> JSON, and so benefits of "anydata" over "anyxml" are really > >> questionable. > > > > I do not think anydata was driven by the idea to build a regular data > > (sub)tree from schema-less data. > > > > I think anydata works fine with both JSON and XML as long as the > > encoder has the data model, which seems to be a reasonable assumption > > If it is so, then what we really need is a standard mechanism that allows for signalling the data model at run time. Without that, as Randy pointed out, there is no way to make sure that the server and client use the same data model for a particular “anydata” node, and then the difference between “anydata” and “anyxml” is no more interesting. All external means (or descriptions) that may potentially provide “late binding” of the data model are applicable to “anyxml” as well. > XML uses namespace URIs to identify the data model, JSON uses module names to identify the data model. The only discussion point here is the level of uniqueness (and of course why we use two different data model identifiers - but it seems nobody except me or perhaps Randy cares). And no, anyxml was defined to be 'any XML' and anydata has been defined to be 'any data modeled in YANG' (without anyxml). This really has been settled, please read the archives if you are still unsure what the difference is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 5 05:23:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20B1AC442 for ; Mon, 5 Oct 2015 05:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhBWIU5KkkFF for ; Mon, 5 Oct 2015 05:23:31 -0700 (PDT) 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 D49681AC439 for ; Mon, 5 Oct 2015 05:23:30 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e57e:2dac:2c8a:323e] (unknown [IPv6:2001:718:1a02:1:e57e:2dac:2c8a:323e]) by mail.nic.cz (Postfix) with ESMTPSA id CD502181D69; Mon, 5 Oct 2015 14:23:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444047808; bh=fGa1TQwqoBpk4sKdPYHDJVfQd5Jzc9bUb7Fh5m5ZueI=; h=From:Date:To; b=hY76QSyW3clBRCMJ/3gJk2GusZevMSaFMXC+6g7bpXwEYL28R2ACY4mDF4Kr0RUek gfXVaOs+QyRBNjJ4YJdS4ovsW3Ij9zX/EX7XSyn0904vhLUmGDukMNqMtvkzWAeuvY lmDhcemghddquUJunRZct4ganYer9XmRT3mugTK4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151005114415.GC37707@elstar.local> Date: Mon, 5 Oct 2015 14:23:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9576596.1443740721090.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20151005095710.GA37459@elstar.local> <20151005114415.GC37707@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 12:23:33 -0000 > On 05 Oct 2015, at 13:44, Juergen Schoenwaelder = wrote: >=20 > On Mon, Oct 05, 2015 at 01:32:46PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder = wrote: >>>=20 >>> On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote: >>>=20 >>>> I am certainly concerned. The current definition of "anydata" ("an >>>> unknown set of nodes that can be modelled with YANG") is IMO >>>> insufficient because, for one, it doesn't even eliminate mixed = content >>>> in XML, which can be modelled with YANG's "anyxml" statement. >>>=20 >>> Good point. I think we should clarify that anyxml is excluded. >>=20 >> Then YANG extensions probably need to be excluded, too. >>=20 >>>=20 >>>> In my view, the idea behind "anydata" was that it would be possible = to >>>> build a regular data (sub)tree from schema-less data. However, this >>>> seems to be difficult, at least on a server supporting both XML and >>>> JSON, and so benefits of "anydata" over "anyxml" are really >>>> questionable. >>>=20 >>> I do not think anydata was driven by the idea to build a regular = data >>> (sub)tree from schema-less data. >>>=20 >>> I think anydata works fine with both JSON and XML as long as the >>> encoder has the data model, which seems to be a reasonable = assumption >>=20 >> If it is so, then what we really need is a standard mechanism that = allows for signalling the data model at run time. Without that, as Randy = pointed out, there is no way to make sure that the server and client use = the same data model for a particular =E2=80=9Canydata=E2=80=9D node, and = then the difference between =E2=80=9Canydata=E2=80=9D and =E2=80=9Canyxml=E2= =80=9D is no more interesting. All external means (or descriptions) that = may potentially provide =E2=80=9Clate binding=E2=80=9D of the data model = are applicable to =E2=80=9Canyxml=E2=80=9D as well. >>=20 >=20 > XML uses namespace URIs to identify the data model, JSON uses module Sorry, this is not true: A data model is identified by a set of YANG = modules with their exact revisions + features (+ deviations). A URI or = module name by itself doesn=E2=80=99t help if you don=E2=80=99t have the = rest. > names to identify the data model. The only discussion point here is > the level of uniqueness (and of course why we use two different data > model identifiers - but it seems nobody except me or perhaps Randy > cares). >=20 > And no, anyxml was defined to be 'any XML' and anydata has been > defined to be 'any data modeled in YANG' (without anyxml). This really > has been settled, please read the archives if you are still unsure > what the difference is. But the exclusion of anyxml wasn=E2=80=99t part of that discussion, was = it? And since you didn=E2=80=99t answer my comment about extensions, let = me put it differently: Are XML attributes allowed in XML-encoded anydata = contents? Randy talks about =E2=80=9Ca big lump under the carpet=E2=80=9D, so = maybe I am not alone in thinking that the concept of anydata needs to be = clarified or reconsidered - and WGLC is the last chance to do it. I tried to formulate a clarification but it turned out to be = unacceptable, and its relaxed form useless, as you rightly pointed out. = So can somebody propose a better definition of anydata? =20 Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 5 08:35:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC921B316C for ; Mon, 5 Oct 2015 08:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wktg-Z7DeJBa for ; Mon, 5 Oct 2015 08:35:18 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F571AD21C for ; Mon, 5 Oct 2015 08:35:18 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-70-561298b449cc Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.82.27359.4B892165; Mon, 5 Oct 2015 17:35:16 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Mon, 5 Oct 2015 17:35:15 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <561298B3.1040105@ericsson.com> Date: Mon, 5 Oct 2015 17:35:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvje6WGUJhBs/75SzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpv+T6wFd/krbiy/wd7A+Ieji5GTQ0LARGLS3W3sELaYxIV7 69lAbCGBo4wSTTNZuhi5gOw1jBIPzyxnBUmICKhLzNwJUcQmYCQxtf88C4gtLCAvcablMlic V0BbYvLya2A2i4CKxPbl78F6RQViJHp+bYCqEZQ4OfMJWC+zgIXEzPnnGSFseYntb+cwQxyh IfHwwl/WCYx8s5C0zELSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgSF1cMtv gx2ML587HmIU4GBU4uFVyBQME2JNLCuuzD3EKM3BoiTO28z0IFRIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY2Lwcb/pTYu+XtL7kFB8ccnzqyJNPzrZC1QWT8js3+rc8l7H5VqE4af/u/7P r13Ia1r97rj6u8yFZ7nOO+Xs+vBDwpx5oYIGx1X1JFtm2bu7Z9d67SuecS1pYrTvjMr4xjCN C1m/2WelsRYsZLrV78bf+v6YBcvn9Y5SvKWKTHynn74z//Z5ghJLcUaioRZzUXEiAJMJNtcK AgAA Archived-At: Subject: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:35:20 -0000 Hello, What do the mandatory statements mean in the following model ? choice scen8 { // Embedded choices with multiple mandatory cases; invalid scenario case A { choice subChoiceA { mandatory true; case A { leaf scen8-num1 { type uint8; } } case B { leaf scen8-num2 { type uint8; } } } } case B { choice subChoiceB { mandatory true; case A { leaf scen8-num1 { type uint8; } } case B { leaf scen8-num2 { type uint8; } } } } } Answers: A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid. A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model? Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-( As the very least we SHOULD prohibit mandatory/default on the inside choice. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Oct 5 09:27:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888BE1A1ABC for ; Mon, 5 Oct 2015 09:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C0e5gxvul-P for ; Mon, 5 Oct 2015 09:27:09 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 4F64A1A1B19 for ; Mon, 5 Oct 2015 09:26:11 -0700 (PDT) Received: by laag4 with SMTP id g4so2096088laa.2 for ; Mon, 05 Oct 2015 09:26:09 -0700 (PDT) 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=OcUJHTakJJGnk0igivsvDnCBjWFTFlU4sMcZVg8VH18=; b=NkkmMcCT7Prd6stHX0HfOUXppEkGmqTPI2buWRe+dZPNxM01vOuzCoK5DczjhmOLSC 40cix9ZYUO+7y3s9EWvWvDz7dBQ6JOI8Gb+8PRN3ve1fEoEAr70X2klAhlozvhJydXok wGDX6I1dy2yfAVF5OFB8wLsPalmSQAYDbfY+WraHItGYwd2NWSUk4jXGL/Naq8biKCHS 9drf+NfjpmGQSY8TEIjLAO5zc9A3+NxRP74IuES77559CvhZ3aUebqjRGtQKHR1FHrYC eltEF6kD/dmXZue0ObxWM5RsZ4bVBZ8JTruoqtdCw7Qd8YrhdCkZkK6tdkuzuNyCl5tP e75g== X-Gm-Message-State: ALoCoQnKElS5B7RcBZ7ztSY1mM4l8GOGFeR+LNZc+mLQgUAuaBvuf6HhY8oaqgOq96l+zTjbckS5 MIME-Version: 1.0 X-Received: by 10.112.167.70 with SMTP id zm6mr8506653lbb.33.1444062369555; Mon, 05 Oct 2015 09:26:09 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 5 Oct 2015 09:26:09 -0700 (PDT) In-Reply-To: <561298B3.1040105@ericsson.com> References: <561298B3.1040105@ericsson.com> Date: Mon, 5 Oct 2015 09:26:09 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11c26a1892338505215df857 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 16:27:11 -0000 --001a11c26a1892338505215df857 Content-Type: text/plain; charset=UTF-8 Hi, It looks like neither 'mandatory' or 'default' has any effect in this situation. If the nested choices had sibling nodes then these statements would be relevant. Then selecting the sibling would cause the mandatory or default choice to have meaning. Andy On Mon, Oct 5, 2015 at 8:35 AM, Balazs Lengyel wrote: > Hello, > What do the mandatory statements mean in the following model ? > > choice scen8 { // Embedded choices with multiple mandatory > cases; invalid scenario > case A { > choice subChoiceA { > mandatory true; > case A { > leaf scen8-num1 { type uint8; } > } > case B { > leaf scen8-num2 { type uint8; } > } > } > } > case B { > choice subChoiceB { > mandatory true; > case A { > leaf scen8-num1 { type uint8; } > } > case B { > leaf scen8-num2 { type uint8; } > } > } > } > } > > Answers: > A1) They mean nothing because the case around subChoiceA/B might not > exist, in which case its underlying statements are not valid. > A2) They mean that one case from both subChoiceA AND subchoiceB must exist > leading to two cases in choice scen8 which is not allowed, hence this is an > invalid model? > > Generally I find choices embedded in choices to be so complicated that > IMHO they SHOULD be immediately prohibited. If you think about all the > variants of embedded choices with mandatory and default placed on some or a > bunch of them, even understanding what they mean becomes a headache. BAD > !!!! In the beginning YANG was about easy-understanding. However these > combinations are unclear even after repeatedly reading the RFC :-( > As the very least we SHOULD prohibit mandatory/default on the inside > choice. > > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c26a1892338505215df857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It looks like neither 'mandator= y' or 'default' has any effect in
this situation.=C2= =A0 If the nested choices had sibling nodes
then these statements= would be relevant.=C2=A0 Then selecting the
sibling would cause = the mandatory or default choice to have meaning.

<= br>
Andy


On Mon, Oct 5, 2015 at 8:35 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
What do the mandatory statements mean in the following model ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice scen8 {=C2=A0 // Embedded c= hoices with multiple mandatory cases; invalid scenario
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case A {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice= subChoiceA {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0case A {
=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=A0leaf scen8-num1 { type uint8; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0case B {
=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=A0leaf scen8-num2 { type uint8; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=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=A0case B {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice= subChoiceB {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0case A {
=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=A0leaf scen8-num1 { type uint8; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0case B {
=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=A0leaf scen8-num2 { type uint8; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=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}

Answers:
A1) They mean nothing because the case around subChoiceA/B might not exist,= in which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must exist = leading to two cases in choice scen8 which is not allowed, hence this is an= invalid model?

Generally I find choices embedded in choices to be so complicated that IMHO= they SHOULD be immediately prohibited. If you think about all the variants= of embedded choices with mandatory and default placed on some or a bunch o= f them, even understanding what they mean becomes a headache. BAD !!!! In t= he beginning YANG was about easy-understanding. However these combinations = are unclear even after repeatedly reading the RFC :-(
=C2=A0As the very least we SHOULD prohibit mandatory/default on the inside = choice.

regards Balazs

--
Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ema= il: Balazs= .Lengyel@ericsson.com

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

--001a11c26a1892338505215df857-- From nobody Mon Oct 5 10:13:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280A91A1B0B for ; Mon, 5 Oct 2015 10:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya4gfl7zprCF for ; Mon, 5 Oct 2015 10:13:13 -0700 (PDT) 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 EF5671A7012 for ; Mon, 5 Oct 2015 10:13:12 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 8AC5F181A18; Mon, 5 Oct 2015 19:13:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444065191; bh=l4668CqDXQJsj2BKO4SdYT5V872fQhuNTFxkkq9NbuU=; h=From:Date:To; b=Pv2bPFggLprf/g2avOlpxryG13VF8RTiT7aWKeVvWpWZQEgtpO3fN4U2XdDDYyL3M Kha2jEWCzaufKHdokVqgbZie7KUea0A7aU/8Y79WTJx6YqlPjV2hSKUkbnPcshDrBR SLLcONtoZGUohdYkKvQRtAJ+DZdZZ4qeU7uVesAQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <561298B3.1040105@ericsson.com> Date: Mon, 5 Oct 2015 19:13:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> References: <561298B3.1040105@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:13:14 -0000 > On 05 Oct 2015, at 17:35, Balazs Lengyel = wrote: >=20 > Hello, > What do the mandatory statements mean in the following model ? >=20 > choice scen8 { // Embedded choices with multiple mandatory = cases; invalid scenario > case A { > choice subChoiceA { > mandatory true; > case A { > leaf scen8-num1 { type uint8; } > } > case B { > leaf scen8-num2 { type uint8; } > } > } > } > case B { > choice subChoiceB { > mandatory true; > case A { > leaf scen8-num1 { type uint8; } > } > case B { > leaf scen8-num2 { type uint8; } > } > } > } > } >=20 > Answers: > A1) They mean nothing because the case around subChoiceA/B might not = exist, in which case its underlying statements are not valid. > A2) They mean that one case from both subChoiceA AND subchoiceB must = exist leading to two cases in choice scen8 which is not allowed, hence = this is an invalid model? In the first place, it should be an error because of colliding names - = all the leaves defined in sub-cases have the same parent. However, pyang = doesn't flag it as an error. >=20 > Generally I find choices embedded in choices to be so complicated that = IMHO they SHOULD be immediately prohibited. If you think about all the = variants of embedded choices with mandatory and default placed on some = or a bunch of them, even understanding what they mean becomes a = headache. BAD !!!! In the beginning YANG was about easy-understanding. = However these combinations are unclear even after repeatedly reading the = RFC :-( Yes, it is quite complicated. Normally, such embedded choices shouldn't = be needed but they can happen if, e.g. the internal choices are defined = in groupings. > As the very least we SHOULD prohibit mandatory/default on the inside = choice. I think it would be better to ignore them (and tools may issue a = warning). Lada=20 >=20 > regards Balazs >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=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 Oct 5 11:00:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2C1B31F4 for ; Mon, 5 Oct 2015 11:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.11 X-Spam-Level: X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GvivKWGaFN2 for ; Mon, 5 Oct 2015 11:00:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F72C1B31EA for ; Mon, 5 Oct 2015 11:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5822; q=dns/txt; s=iport; t=1444068034; x=1445277634; h=from:to:subject:date:message-id:mime-version; bh=zPhOSiFY3CSkPOEm4XiwoIoiJ4WB2xRYmqngwxLtTsg=; b=JYpO973YQJtqZQH434pdkLywl9VKsyWkgwIK9fqiSTSxFQnba6aGmNiE q6OkvGfSdaprnw1/nNMJdx2ApNIGsDB9dHt41orDNvfqGjD6L3vMK8Ugq bTmySuzdbvtiFTgYwErafeOrPEne2CbSxet5Ef7iFTcsAMltAg75me0ty M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BQBUuhJW/4MNJK1egyeBSL93h1I8EAEBAQEBAQF/C4QraAYdAYEAJwQuiBOZWaQIAQEBAQYBAQEBAQEBG4ZzghCLGoEUBYcthwmEE4MzAY0WgVaEOI0PiEY4K4QCh2cEP4EGAQEB X-IronPort-AV: E=Sophos;i="5.17,639,1437436800"; d="scan'208,217";a="194695414" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 05 Oct 2015 18:00:33 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t95I0XZ5009473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Oct 2015 18:00:33 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 13:00:32 -0500 Received: from xhc-rcd-x04.cisco.com (173.37.183.78) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 13:00:32 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.162]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 13:00:32 -0500 From: "Andrew McLachlan (amclachl)" To: "netmod@ietf.org" Thread-Topic: Interim Meetings info. Thread-Index: AQHQ/5e6CSkNGJFNJkC6cX8W/gyCwg== Date: Mon, 5 Oct 2015 18:00:32 +0000 Message-ID: <3F7D6C63-4E07-4830-A2B7-C0143CD3B804@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.141] Content-Type: multipart/alternative; boundary="_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Interim Meetings info. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:00:37 -0000 --_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All A quick update on the format for NETMOD interim meetings, including the fre= quency and meeting management. Cheers Andrew, Benoit, Kent and Tom Frequency of meetings Fortnightly / bi-weekly on Thursday's at 7am PST for 2 hours. Please note, if there is no requirement for us to meet then we don't. No me= etings for the sake of a meetings. Meetings do not have to run for the full 2 hours. Agenda Publishing Agenda to be posted to the mailing list 7days before the next interim meeti= ng. Meeting method / Note Taking Currently we are using webex, which seems to work, so lets leave that as is= unless there is major objection which would also need to be accompanied by= a replacement solution. Note taking - Etherpad also seems to work, so as with webex, unless there i= s an objection coupled with solution we should continue. Minutes As interim meetings increase overhead, we need to keep admin to a minimum a= nd use modern tools/methods. It is therefore suggested that the minutes are keep as summaries of the dis= cussion for each point discussed, rather than an entire back and forth of t= he conversation. In the notes we should indicate the time we discussed each= point, so this can be used to fast-forward to a point in a webex recording= . Summary Since the goal of having interim meetings is to speed things up in the WG, = we need to ensure these meetings are focused and responsive. Upcoming Meetings (next few months schedule) Oct 15 - 1st bi-weekly meeting Oct 29 - 2nd bi-weekly meeting (maybe cancelled due to travel needs) Nov -- - two meetings at conference Nov 12 - 3rd bi-weekly meeting Nov 26 - cancelled (Thanksgiving holiday in US) Dec 10 - 4th bi-weekly meeting Dec 24 - cancelled (Christmas eve) Jan 7 - 5th bi-weekly meeting Jan 21 - 6th bi-weekly meeting --_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <50CB957F4D05F44880B66B78122C902D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Dear All

A quick update on the format for NETMOD interim meetings, i= ncluding the frequency and meeting management.

Cheers

Andrew, Benoit, Kent and Tom


Frequency of meetings

Fortnightly / bi-weekly on Thursday's at 7am PST for 2 hours.
Please note, if there is no requirement for us to meet then we don't. No me= etings for the sake of a meetings.
Meetings do not have to run for the full 2 hours.

Agenda Publishing

Agenda to be posted to the mailing list 7days before the next interim meeti= ng.

Meeting method / Note Taking

Currently we are using webex, which seems to work, so lets leave that as is= unless there is major objection which would also need to be accompanied by= a replacement solution.

Note taking - Etherpad also seems to work, so as with webex, unless there i= s an objection coupled with solution we should continue.

Minutes

As interim meetings increase overhead, we need to keep admin to a minimum a= nd use modern tools/methods.

It is therefore suggested that the minutes are keep as summaries of the dis= cussion for each point discussed, rather than an entire back and forth of t= he conversation. In the notes we should indicate the time we discussed= each point, so this can be used to fast-forward to a point in a webex recording.

Summary

Since the goal of having interim meetings is to speed things up in the WG, = we need to ensure these meetings are focused and responsive.





Upcoming Meetings (next few mon= ths schedule)

Oct 15
- 1st bi-weekly meeting
Oct 29
- 2nd bi-weekly meeting (maybe cancelled due to travel needs)
Nov --
- two meetings at conference
Nov 12
- 3rd bi-weekly meeting
Nov 26
- cancelled (Thanksgiving holiday in US)
Dec 10
- 4th bi-weekly meeting
Dec 24
- cancelled (Christmas eve)
Jan 7
- 5th bi-weekly meeting
Jan 21
- 6th bi-weekly meeting

--_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_-- From nobody Mon Oct 5 11:00:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CD1B31FF for ; Mon, 5 Oct 2015 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fV19sdqN3-r for ; Mon, 5 Oct 2015 11:00:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908191B31F4 for ; Mon, 5 Oct 2015 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5822; q=dns/txt; s=iport; t=1444068052; x=1445277652; h=from:to:subject:date:message-id:mime-version; bh=wBJhXKIVJFBOwXztu9mh4ecn3I9FEqkB6dsnnxy6VzU=; b=TG5IfKs3E8czM83/ltRxDIdx/qlsDMFm/fydHMlAfwLr4chWEK90CJH6 YUaQnflxB44skmJm8anUlV8gTeZC6J315HYzMJGX86WiTCH3s0uuDY2KL Q5gOKvftz2Qhl1Ulvz0fUgw4if7MixPL6A6j6QODY22Wp2euKc1+YJnvK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BQBUuhJW/5ldJa1egyeBSL93h1I8EAEBAQEBAQF/C4QraAYdAYEAJwQuiBOZWaQIAQEBAQYBAQEBAQEBG4ZzghCLGoEUBYcthwmEE4MzAY0WgVaEOI0PiEY4K4QCh2cEP4EGAQEB X-IronPort-AV: E=Sophos;i="5.17,639,1437436800"; d="scan'208,217";a="194695589" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 05 Oct 2015 18:00:51 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t95I0p1s004438 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Oct 2015 18:00:51 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 13:00:51 -0500 Received: from xhc-aln-x01.cisco.com (173.36.12.75) by xch-aln-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 13:00:51 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.162]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 13:00:51 -0500 From: "Andrew McLachlan (amclachl)" To: "netmod@ietf.org" Thread-Topic: Interim Meetings info. Thread-Index: AQHQ/5fF8XW34pMoMESSYkRlKK0LeA== Date: Mon, 5 Oct 2015 18:00:50 +0000 Message-ID: <3F7D6C63-4E07-4830-A2B7-C0143CD3B804@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.13] Content-Type: multipart/alternative; boundary="_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Interim Meetings info. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:00:55 -0000 --_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All A quick update on the format for NETMOD interim meetings, including the fre= quency and meeting management. Cheers Andrew, Benoit, Kent and Tom Frequency of meetings Fortnightly / bi-weekly on Thursday's at 7am PST for 2 hours. Please note, if there is no requirement for us to meet then we don't. No me= etings for the sake of a meetings. Meetings do not have to run for the full 2 hours. Agenda Publishing Agenda to be posted to the mailing list 7days before the next interim meeti= ng. Meeting method / Note Taking Currently we are using webex, which seems to work, so lets leave that as is= unless there is major objection which would also need to be accompanied by= a replacement solution. Note taking - Etherpad also seems to work, so as with webex, unless there i= s an objection coupled with solution we should continue. Minutes As interim meetings increase overhead, we need to keep admin to a minimum a= nd use modern tools/methods. It is therefore suggested that the minutes are keep as summaries of the dis= cussion for each point discussed, rather than an entire back and forth of t= he conversation. In the notes we should indicate the time we discussed each= point, so this can be used to fast-forward to a point in a webex recording= . Summary Since the goal of having interim meetings is to speed things up in the WG, = we need to ensure these meetings are focused and responsive. Upcoming Meetings (next few months schedule) Oct 15 - 1st bi-weekly meeting Oct 29 - 2nd bi-weekly meeting (maybe cancelled due to travel needs) Nov -- - two meetings at conference Nov 12 - 3rd bi-weekly meeting Nov 26 - cancelled (Thanksgiving holiday in US) Dec 10 - 4th bi-weekly meeting Dec 24 - cancelled (Christmas eve) Jan 7 - 5th bi-weekly meeting Jan 21 - 6th bi-weekly meeting --_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <70593D8349794C4FA5D568CD55475E5C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Dear All

A quick update on the format for NETMOD interim meetings, i= ncluding the frequency and meeting management.

Cheers

Andrew, Benoit, Kent and Tom


Frequency of meetings

Fortnightly / bi-weekly on Thursday's at 7am PST for 2 hours.
Please note, if there is no requirement for us to meet then we don't. No me= etings for the sake of a meetings.
Meetings do not have to run for the full 2 hours.

Agenda Publishing

Agenda to be posted to the mailing list 7days before the next interim meeti= ng.

Meeting method / Note Taking

Currently we are using webex, which seems to work, so lets leave that as is= unless there is major objection which would also need to be accompanied by= a replacement solution.

Note taking - Etherpad also seems to work, so as with webex, unless there i= s an objection coupled with solution we should continue.

Minutes

As interim meetings increase overhead, we need to keep admin to a minimum a= nd use modern tools/methods.

It is therefore suggested that the minutes are keep as summaries of the dis= cussion for each point discussed, rather than an entire back and forth of t= he conversation. In the notes we should indicate the time we discussed= each point, so this can be used to fast-forward to a point in a webex recording.

Summary

Since the goal of having interim meetings is to speed things up in the WG, = we need to ensure these meetings are focused and responsive.





Upcoming Meetings (next few mon= ths schedule)

Oct 15
- 1st bi-weekly meeting
Oct 29
- 2nd bi-weekly meeting (maybe cancelled due to travel needs)
Nov --
- two meetings at conference
Nov 12
- 3rd bi-weekly meeting
Nov 26
- cancelled (Thanksgiving holiday in US)
Dec 10
- 4th bi-weekly meeting
Dec 24
- cancelled (Christmas eve)
Jan 7
- 5th bi-weekly meeting
Jan 21
- 6th bi-weekly meeting

--_000_3F7D6C634E074830A2B7C0143CD3B804ciscocom_-- From nobody Mon Oct 5 13:46:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87251B4FFE for ; Mon, 5 Oct 2015 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zWtKzdOLgUh for ; Mon, 5 Oct 2015 13:46:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C4A1B4FFD for ; Mon, 5 Oct 2015 13:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2813; q=dns/txt; s=iport; t=1444078005; x=1445287605; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ETPnR9l9v0HeFG21i31V+Onkw/nWQ1sbm1lTRULB1RE=; b=nCrow8by7XdaSIQHndc6qnFEfJdJvJy/OjYzgGlbNrzkTSLe7m5kcpw4 Edv9DTd2JmSyLWfGcg0SZoycHixKM7ZosiMvtznEQ5keFIAyNBQQ5bvlE 2AX2XiiDHYh8WWAF1etYaGaFXLneefdr/VENuiiHheRvM+R9DAQJbfYmZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADAgAo4RJW/4wNJK1bA4MnVG4Gvg8BDYFaFwqFL0oCgTY4FAEBAQEBAQGBCoQkAQEBBAEBATc0CwwCBAEWAgEEAQEBChQJIgwLFAkJAQQBDQUIiCYNvg0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJBJIRANDIMGgRQFlXwBjmyEOJFmg28fAQFCgkSBPnGHOYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,640,1437436800"; d="scan'208";a="32877183" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 05 Oct 2015 20:46:44 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t95Kkiqn012464 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 20:46:44 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 15:46:43 -0500 Received: from xhc-aln-x05.cisco.com (173.36.12.79) by xch-aln-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 15:46:43 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.194]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 15:46:43 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Ladislav Lhotka" Thread-Topic: anydata interaction with yang-patch and edit config (RE: [netmod] 6020bis - anydata) Thread-Index: AdD/rtYeC7MxkH5QS1+dT1UUHD/W2A== Date: Mon, 5 Oct 2015 20:46:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.84.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: [netmod] anydata interaction with yang-patch and edit config (RE: 6020bis - anydata) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 20:46:50 -0000 Hi, I have two quick questions with regards to anydata - related to the topic o= f the thread, but concerning a separate topic. =20 (1) How does yang-patch interact with anydata? In particular, could you ap= ply a yang-patch edit to a data node within the anydata? (While the module= may not have been known at design time, it will be known at run time - so = presume yes.) (2) How about edit-config? Can you use edit config to apply operations to = nodes within the anydata, or just to the blob as a whole? (Again, I would = assume you can, as the nodes will be known at run time.) =20 Thanks --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Wednesday, September 30, 2015 6:52 AM To: Ladislav Lhotka Cc: Randy Presuhn ; netmod@ietf.org Subject: Re: [netmod] 6020bis - anydata On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote: > Hi Randy, >=20 > thanks for the comments and proposed edits. Please see inline. >=20 > Randy Presuhn writes: >=20 > > Hi - > > > >>From: Ladislav Lhotka > >>Sent: Sep 29, 2015 7:07 AM > >>To: netmod@ietf.org > >>Subject: [netmod] 6020bis - anydata > >> > >>Hi, > >> > >>I propose to expand the text in Sec. 7.10 as follows: > >> > >>OLD > >> > >> The "anydata" statement is used to represent an unknown set of nodes > >> that can be modelled with YANG. An example of where this can be > >> useful is a list of received notifications, where the exact > >> notifications are not known as design time. > >> > >>NEW > >> > >> The "anydata" statement is used to represent an unknown set of nodes > >> that can be modelled with YANG but for which the data model doesn't > >> exist at module design time. > > > > "doesn't exist" would not be appropriate for the example you provide=20 > > below. It would be incorrect if some of the notifications in your=20 > > example had already been defined, even though "anydata" would still=20 > > be necessary to handle others not yet defined. >=20 > Would "doesn't exist or cannot be determined at module design time" be be= tter? > What about this: The "anydata" statement is used to represent a set of nodes that can be modelled with YANG but for which the data model is not known at module design time. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 5 14:19:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153FF1B503A for ; Mon, 5 Oct 2015 14:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqlW2uO_q6Da for ; Mon, 5 Oct 2015 14:19:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A979D1B5039 for ; Mon, 5 Oct 2015 14:19:39 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A2091AE009B; Mon, 5 Oct 2015 23:19:38 +0200 (CEST) Date: Mon, 05 Oct 2015 23:21:23 +0200 (CEST) Message-Id: <20151005.232123.755931242325159302.mbj@tail-f.com> To: alex@cisco.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: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] anydata interaction with yang-patch and edit config X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 21:19:41 -0000 "Alexander Clemm (alex)" wrote: > Hi, > > I have two quick questions with regards to anydata - related to the > topic of the thread, but concerning a separate topic. > > (1) How does yang-patch interact with anydata? In particular, could > you apply a yang-patch edit to a data node within the anydata? (While > the module may not have been known at design time, it will be known at > run time - so presume yes.) > > (2) How about edit-config? Can you use edit config to apply > operations to nodes within the anydata, or just to the blob as a > whole? (Again, I would assume you can, as the nodes will be known at > run time.) The current text says: An anydata node is treated as an opaque chunk of data. This data can be modified in its entirety only. So the answer to both questions are "no". I don't think that the module necessarily must be known at run-time. /martin From nobody Mon Oct 5 14:22:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2241B504B for ; Mon, 5 Oct 2015 14:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNxTep3wSb1H for ; Mon, 5 Oct 2015 14:22:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954481B5049 for ; Mon, 5 Oct 2015 14:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1428; q=dns/txt; s=iport; t=1444080129; x=1445289729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5D9YaTBBB3gxx9l6SJiqaXSijwKouWaWP8y3DJ27dxI=; b=C8REEbl/GAiImHBtXbvmcO7l4QycAtAIlTIDtBBp0A2T2eEVuFqQ2LbG clNVfGOo0rsWbl5I/lVlgcPAZqudO8z6I8b9sgPifUnaBTcfcoeu5WLOt UnC7kYr75WE7y57PN89JagYhlmm9uy/gM221hq0D3Wv2xhTmdAx8M/lqD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgDA6RJW/51dJa1egyeBQga+DgENgVqGGgKBODgUAQEBAQEBAYEKhCQBAQEEOj8MBAIBCA4CAQQBAQEKFAkHMhQJCAIEDgUIiCa+IQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLcYRcMQcGgxKBFAEElXwBqHkfAQFChAJxhzmBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,640,1437436800"; d="scan'208";a="32832680" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2015 21:21:57 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t95LLvtP010313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 21:21:57 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 16:21:57 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 16:21:57 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.194]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 16:21:57 -0500 From: "Alexander Clemm (alex)" To: Martin Bjorklund Thread-Topic: [netmod] anydata interaction with yang-patch and edit config Thread-Index: AQHQ/7OLd8TZakBY10GOJmMRoxUcsJ5dZ9mw Date: Mon, 5 Oct 2015 21:21:56 +0000 Message-ID: References: <20151005.232123.755931242325159302.mbj@tail-f.com> In-Reply-To: <20151005.232123.755931242325159302.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.84.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "randy_presuhn@mindspring.com" , "netmod@ietf.org" Subject: Re: [netmod] anydata interaction with yang-patch and edit config X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 21:22:11 -0000 Thanks, Martin, this is very clear.=20 (Too bad actually - I could see applications for this.)=20 --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Monday, October 05, 2015 2:21 PM To: Alexander Clemm (alex) Cc: j.schoenwaelder@jacobs-university.de; lhotka@nic.cz; randy_presuhn@mind= spring.com; netmod@ietf.org Subject: Re: [netmod] anydata interaction with yang-patch and edit config "Alexander Clemm (alex)" wrote: > Hi, >=20 > I have two quick questions with regards to anydata - related to the=20 > topic of the thread, but concerning a separate topic. >=20 > (1) How does yang-patch interact with anydata? In particular, could=20 > you apply a yang-patch edit to a data node within the anydata? (While=20 > the module may not have been known at design time, it will be known at=20 > run time - so presume yes.) >=20 > (2) How about edit-config? Can you use edit config to apply=20 > operations to nodes within the anydata, or just to the blob as a=20 > whole? (Again, I would assume you can, as the nodes will be known at=20 > run time.) The current text says: An anydata node is treated as an opaque chunk of data. This data can be modified in its entirety only. So the answer to both questions are "no". I don't think that the module necessarily must be known at run-time. /martin From nobody Mon Oct 5 14:26:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B841B505F for ; Mon, 5 Oct 2015 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9AOc_u2Yoxw for ; Mon, 5 Oct 2015 14:26:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E72E1B505D for ; Mon, 5 Oct 2015 14:26:15 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E64B1AE009B; Mon, 5 Oct 2015 23:26:14 +0200 (CEST) Date: Mon, 05 Oct 2015 23:27:59 +0200 (CEST) Message-Id: <20151005.232759.1501001908345671517.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: <20151005.232123.755931242325159302.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: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] anydata interaction with yang-patch and edit config X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 21:26:16 -0000 "Alexander Clemm (alex)" wrote: > Thanks, Martin, this is very clear. > > (Too bad actually - I could see applications for this.) As you noted, this would require the server to know the data models. Do you have some use case in mind where this would be useful? /martin > > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, October 05, 2015 2:21 PM > To: Alexander Clemm (alex) > Cc: j.schoenwaelder@jacobs-university.de; lhotka@nic.cz; randy_presuhn@mindspring.com; netmod@ietf.org > Subject: Re: [netmod] anydata interaction with yang-patch and edit config > > "Alexander Clemm (alex)" wrote: > > Hi, > > > > I have two quick questions with regards to anydata - related to the > > topic of the thread, but concerning a separate topic. > > > > (1) How does yang-patch interact with anydata? In particular, could > > you apply a yang-patch edit to a data node within the anydata? (While > > the module may not have been known at design time, it will be known at > > run time - so presume yes.) > > > > (2) How about edit-config? Can you use edit config to apply > > operations to nodes within the anydata, or just to the blob as a > > whole? (Again, I would assume you can, as the nodes will be known at > > run time.) > > The current text says: > > An anydata node is treated as an opaque chunk of data. This data > can be modified in its entirety only. > > > So the answer to both questions are "no". > > I don't think that the module necessarily must be known at run-time. > > > /martin > From nobody Mon Oct 5 17:40:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC301A893F for ; Mon, 5 Oct 2015 17:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id magwi_eFKmZj for ; Mon, 5 Oct 2015 17:40:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3641A8939 for ; Mon, 5 Oct 2015 17:40:08 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 6 Oct 2015 00:40:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 00:40:05 +0000 From: Kent Watsen To: Andy Bierman , Robert Wilton Thread-Topic: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" Thread-Index: AQHQ/Jhe+wzAtH4+rEyfclxfJZTKW55X7weAgACLuoCAAAeIAIAAIxGAgAFEqACAA3jPAA== Date: Tue, 6 Oct 2015 00:40:05 +0000 Message-ID: References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:/DipTieOP6Y7Isd4kn6uJsVIDGo3bojpt45ohdZGqUWB09CxeV49ZxHdENFBzcLZugO6LrwA7E7VrY8iqFbz9KLriFnUJ2UCbkk3TisXKS7IrTmaDtwG9vGalVD0XhpbIqrB8pMtR3GlJBkVfTQOEA==; 24:Sve9elJUz/kGApy0U1ib9zcUvKWb+YmbZsEbap09ujneP+S4mC9zcSl+o9FHaqz0XPkDHiNoB00QSv41B7VW/ahX21d+uc0VRZLfvHQELO0=; 20:u3sI8gyRYksRDLCjqDX0cxEPlep5Q/4YjygnFx+G91yNqI8uQpcj4xTxdW+1LaJ3AsfwbHyP1hIz/L9piZDZ/w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(13464003)(199003)(57704003)(377454003)(5383002)(164054003)(479174004)(51444003)(24454002)(40100003)(15975445007)(106116001)(10400500002)(5002640100001)(46102003)(106356001)(92566002)(19580395003)(86362001)(102836002)(19580405001)(99286002)(16236675004)(189998001)(87936001)(11100500001)(5007970100001)(122556002)(50986999)(5001920100001)(76176999)(2900100001)(2950100001)(36756003)(54356999)(5890100001)(97736004)(81156007)(66066001)(19617315012)(101416001)(4001350100001)(105586002)(5001960100002)(64706001)(5001770100001)(83506001)(5008740100001)(93886004)(5004730100002)(7059030)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2388A3FE46FCkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 00:40:05.1668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 00:40:14 -0000 --_000_D2388A3FE46FCkwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This issue appears to have become more like issue #5 =96 should we mark thi= s one a duplicate of the other? As for this, what does it mean? > > - templates: the intended data model and applied data model are disjo= int > > This came up towards the end of the interim, and my understanding is that= it > acceptable for any templating solution to have to adhere to that constrai= nt above. Specifically, would this imply that the flattening of the template would ha= ve to now take place at each operational component in the system =96 as opp= osed to being flattened by a centralized component (e.g., in the control pl= ane). If so, then I think it might add significant costs to the servers, = as then *all* downstream components would have to know how to flatten templ= ates. Related to this, how do we handle the case where the downstream component's= native data model is different. For instance, imagine a mixed IP/optical = router that has subtended ROADM and optical amplifiers attached. So, when = the control plane sends the config to the ROADM, it first converts it to th= e ROADM's native data model. For this case, in order to present the applie= d config with the same data model, would the control plane have to perform = the reverse mapping? Kent // as a contributor From: Andy Bierman > Date: Saturday, October 3, 2015 at 11:38 AM To: Robert Wilton > Cc: Randy Presuhn >, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchro= nized" in "Requirement 1.D" Hi, So the applied leaf is being used as a complicated boolean? IMO your draft (using attributes similar to with-defaults=3Dreport-all-tagg= ed, not containers) is the best compromise because: - the data models are not touched - no datastores are required - the same string is used to identify the data node no matter what state needs to be checked - client has to request the metadata somehow so no impact on clients that do not care about this issue - a single boolean attribute applied=3D"true" is all that is really need= ed Andy On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton > wrote: Hi Andy, It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is = only used to indicate whether the configuration represented by the intended= -cfg leaf has been applied. But it appears that my proposed text for 1D may have caused some confusion.= Please see inline ... On 02/10/2015 19:11, Andy Bierman wrote: Hi, What about the data models that do not follow 1D? - templates: the intended data model and applied data model are disjoint This came up towards the end of the interim, and my understanding is that i= t acceptable for any templating solution to have to adhere to that constrai= nt above. - 'auto-duplex' corner-case: the intended and applied leaf are the same, = but they will never have the same value The intention is: - intended-cfg duplex leaf =3D "auto" (i.e. operator wants duplex to be d= etermined by auto-negotiation) - applied-cfg duplex leaf =3D "auto" (i.e. device will determine duplex b= y auto-negotiation) - related derived-state duplex-state leaf =3D "full" or "half" or "unknow= n" (always represents the actual duplex setting of the interface) - 'use-dhcp' corner-case: intended config just enables specific derived s= tate to be used; disjoint data models Similarly: - intended-cfg use-dhcp leaf =3D "true" (i.e. operator wants DHCP assigne= d IP addresses) - applied-cfg use-dhcp leaf =3D "true" (i.e. system is using DHCP to assi= gn IP addresses) - related derived-state IP address leaf =3D A.B.C.D (Primary IP address i= n use for the interface - if any). Somebody asked an important question at the interim: Is the intent of this group to limit all YANG data models such that they conform to 1D? (IMO that is a non-starter) It is not my intention that my proposed 1D text makes are constraint on the= structure of YANG data models. IMO requirement 1D presume that the solution involves separate objects in the YANG data model for intended and applied states, and therefore it is an invalid requirement. That is not the intention of my phrasing, perhaps it needs further refineme= nt? The intention is that a config node has two notional states in the data sto= re, intended and applied. The aim is to tightly relate those two notional = states as to when they are allowed to be the same or different. Only the 2 protocol-based solutions address this issue by using the same object identifier no matter which state is being queried. I don't think that this requirement excludes any of the three solutions tha= t have been proposed (or the use of attribute to return intended vs applied= state metadata). Thanks, Rob Andy On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote: I agree with "e.g." rather than "i.e.". I'm sure there are lots of other e= xamples of situations where intended config and applied config don't match = when we consider the variety of systems out there that may use NETCONF/YANG= . We should include some of these examples in the draft (in some informati= onal section and have a reference/pointer to them just after the definition= ). Note that this updated definition for 1.D does not preclude the applied con= fig object from matching the intended *before* it has been applied. Do we = need to clarify that with some "conversely" clause or is that clear enough = when considering the other requirements ? We should also cleanly define "applied" (and provide illustrative examples = of when something is and is not applied). Should that be a separate email = thread ? Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton Sent: Friday, October 02, 2015 5:24 To: Randy Presuhn; netmod@ietf.org Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchro= nized" in "Requirement 1.D" Hi Randy, On 01/10/2015 23:27, Randy Presuhn wrote: > Hi - > >> From: Robert Wilton <rwilton@cisco.com> >> Sent: Oct 1, 2015 10:01 AM >> To: "netmod@ietf.org" > >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchron= ized" in "Requirement 1.D" >> >> To clarify what I failed to eloquently express in the interim meeting. >> >> I propose changing the text for requirement 1.D. This also removes >> the need to define what fully synchronized means. >> >> >> Old text for 1.D >> D. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. >> >> >> Proposed text for 1.D: >> D. When the configuration change for any intended >> configuration leaf has been successfully applied to the >> system (i.e. not failed, nor deferred due to absent hardware= ) >> then the existence and value of the corresponding applied >> configuration leaf must match the intended configuration >> leaf. > Are "not failed" and "deferred due to absent hardware" the > *only* possibilities? If not, then the "i.e." needs to be replaced > with an "e.g." I'm not sure if it is the only possibility. Two other possible reason migh= t be: - Configuration that cannot be applied because some dependent configurati= on hasn't been applied. (E.g. if you have configuration where an interface= -ref couldn't be fulfilled because the referenced interface configuration h= adn't been applied because either it had failed or been deferred due to abs= ent hardware). But perhaps this would be classified as being one of the tw= o cases above? - There is also the case the configuration is currently in the process of= being applied. If it is agreed that github issue #2 (i.e. "Is there a requirement to indic= ate why intended config !=3D applied cfg?") is a valid requirement, and I t= hink that there might have been some support for this in the interim meetin= g yesterday, then I would hope that the final solution would enumerate the = reasons why the applied configuration may not match the intended configurat= ion. As such, changing from i.e. to e.g. seems like a good choice. So also taking into account Martin's suggestion the updated proposed text f= or 1.D would be: D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. Thanks, Rob > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D2388A3FE46FCkwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <03E90B8619120A45856EB411FFC592D3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

This issue appears to have become more like issue #5 =96 should we mark thi= s one a duplicate of the other?

As for this, what does it mean?

> >   - templates: the in= tended data model and applied data model are disjoint
> 
> This came up towards the end of= the interim, and my understanding is that it 
> acceptable for any templating s= olution to have to adhere to that constraint above.
 
Specifically, would this imply that the flattening of the template would ha= ve to now take place at each operational component in the system =96 as opp= osed to being flattened by a centralized component (e.g., in the control pl= ane).   If so, then I think it might add significant costs to the servers, as then *all* downstream components = would have to know how to flatten templates.

Related to this, how do we handle the case where the downstream component's= native data model is different.  For instance, imagine a mixed IP/opt= ical router that has subtended ROADM and optical amplifiers attached.  = ;So, when the control plane sends the config to the ROADM, it first converts it to the ROADM's native data model.  = ;For this case, in order to present the applied config with the same data m= odel, would the control plane have to perform the reverse mapping?


Kent   // as a contributor




From: Andy Bierman <andy@yumaworks.com>
Date: Saturday, October 3, 2015 at = 11:38 AM
To: Robert Wilton <rwilton@cisco.com>
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, &q= uot;netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = issue #1 - Define/Clarify "fully synchronized" in "Requireme= nt 1.D"

Hi,

So the applied leaf is being used as a complicated boolean?

IMO your draft (using attributes similar to with-defaults=3Dreport-all= -tagged,
not containers) is the best compromise because:

   - the data models are not touched
   - no datastores are required
   - the same string is used to identify the data node no ma= tter what
     state needs to be checked
   - client has to request the metadata somehow so no impact=
     on clients that do not care about this issue
   - a single boolean attribute applied=3D"true" i= s all that is really needed



Andy



On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <rwilton@cisco.co= m> wrote:
Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is = only used to indicate whether the configuration represented by the intended= -cfg leaf has been applied.

But it appears that my proposed text for 1D may have caused some confusion.=   Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
Hi,

What about the data models that do not follow 1D?

  - templates: the intended data model and applied data model are= disjoint

This came up towards the end of the interim, and my understanding is that i= t acceptable for any templating solution to have to adhere to that constrai= nt above.


  - 'auto-duplex' corner-case: the intended and applied leaf are = the same, but they
    will never have the same value
The intention is:
  - intended-cfg duplex leaf =3D "auto" (i.e. operator wants= duplex to be determined by auto-negotiation)
  - applied-cfg duplex leaf =3D "auto" (i.e. device will det= ermine duplex by auto-negotiation)
  - related derived-state duplex-state leaf =3D "full" or &q= uot;half" or "unknown" (always represents the actual duplex = setting of the interface)

  - 'use-dhcp' corner-case: intended config just enables specific= derived state
     to be used; disjoint data models
Similarly:
  - intended-cfg use-dhcp leaf =3D "true" (i.e. operator wan= ts DHCP assigned IP addresses)
  - applied-cfg use-dhcp leaf =3D "true" (i.e. system is usi= ng DHCP to assign IP addresses)
  - related derived-state IP address leaf =3D A.B.C.D (Primary IP addr= ess in use for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the= structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refineme= nt?

The intention is that a config node has two notional states in the data sto= re, intended and applied.  The aim is to tightly relate those two noti= onal states as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions tha= t have been proposed (or the use of attribute to return intended vs applied= state metadata).

Thanks,
Rob





Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (= Jason) <jaso= n.sterne@alcatel-lucent.com> wrote:
I agree with "e.g." rather than "i.e.".  I'm sure = there are lots of other examples of situations where intended config and ap= plied config don't match when we consider the variety of systems out there = that may use NETCONF/YANG.  We should include some of these examples in the draft (in some informational section and have a reference/= pointer to them just after the definition).

Note that this updated definition for 1.D does not preclude the applied con= fig object from matching the intended *before* it has been applied.  D= o we need to clarify that with some "conversely" clause or is tha= t clear enough when considering the other requirements ?

We should also cleanly define "applied" (and provide illustrative= examples of when something is and is not applied).  Should that be a = separate email thread ?

Jason


-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; net= mod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully sy= nchronized" in "Requirement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwi= lton@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "net= mod@ietf.org" <netmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "ful= ly synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meet= ing.
>>
>> I propose changing the text for requirement 1.D. This also removes=
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>         D.  For asynchronous systems= , when fully synchronized, the data
>>             in the applied conf= iguration is the same as the data in the
>>             intended configurat= ion.
>>
>>
>> Proposed text for 1.D:
>>         D.  When the configuration c= hange for any intended
>>             configuration leaf = has been successfully applied to the
>>             system (i.e. not fa= iled, nor deferred due to absent hardware)
>>             then the existence = and value of the corresponding applied
>>             configuration leaf = must match the intended configuration
>>             leaf.
> Are "not failed" and "deferred due to absent hardware&q= uot; the
> *only* possibilities?  If not, then the "i.e." needs to= be replaced
> with an "e.g."
I'm not sure if it is the only possibility.  Two other possible reason= might be:
  - Configuration that cannot be applied because some dependent config= uration hasn't been applied.  (E.g. if you have configuration where an= interface-ref couldn't be fulfilled because the referenced interface confi= guration hadn't been applied because either it had failed or been deferred due to absent hardware).  But perhaps = this would be classified as being one of the two cases above?
  - There is also the case the configuration is currently in the proce= ss of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to = indicate why intended config !=3D applied cfg?") is a valid requiremen= t, and I think that there might have been some support for this in the inte= rim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configurati= on may not match the intended configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed text f= or 1.D would be:

        D.  When the configuration change for any = intended
            configuration node has been succe= ssfully applied to the
            system (e.g. not failed, nor defe= rred due to absent hardware)
            then the existence and value of t= he corresponding applied
            configuration node must match the= intended configuration
            node.

Thanks,
Rob


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

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

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



 --_000_D2388A3FE46FCkwatsenjunipernet_-- From nobody Mon Oct 5 17:52:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D034E1A89A2 for ; Mon, 5 Oct 2015 17:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhGlTfFYO35o for ; Mon, 5 Oct 2015 17:52:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3A71A89A0 for ; Mon, 5 Oct 2015 17:52:16 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 6 Oct 2015 00:52:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 00:52:13 +0000 From: Kent Watsen To: Robert Wilton , Mahesh Jethanandani Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAA== Date: Tue, 6 Oct 2015 00:52:13 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> In-Reply-To: <560D01D1.5000607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:J3pagy3oS3aziBFKmwzVIu0UtLR8u7SR8fjJV5B+lN6VnFWth70+QYwJ9I2Xfn6iVopdvmVPPMkeBtxasoh83kTwu9GrMp8j7eIQzZXB8dxXuv+9BdGLPuddjDn4p3dftM2mjjdieYrh3IkbnBiJvA==; 24:40Bwn6xYQptmSYJEmHpMqZGEV/r2N6ovEYcHiL3zRke0PzJRV/eaZ0JtEtYfg19yL+P5aUYiPyoOx14Jylrc2/yBx8k6tysAzFhEB8w7bCQ=; 20:zjVw2+/gsxbmJAwySXSsv8i+0CXrrBJ0O7pBkzrKC8klGKFWq8TUEC2G1A1WCrT2DErtaR8XqT9d7YdVfbx9+w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(199003)(52314003)(164054003)(51444003)(479174004)(189002)(4001350100001)(5001770100001)(5008740100001)(2950100001)(11100500001)(5002640100001)(105586002)(64706001)(5004730100002)(40100003)(5007970100001)(122556002)(10400500002)(93886004)(36756003)(19580405001)(5001960100002)(92566002)(19580395003)(99286002)(102836002)(106116001)(66066001)(97736004)(189998001)(81156007)(106356001)(86362001)(46102003)(101416001)(16236675004)(54356999)(87936001)(83506001)(76176999)(2900100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2389326E4737kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 00:52:13.6310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 00:52:21 -0000 --_000_D2389326E4737kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rob, Can you take all the comments from this thread to update the proposed defin= itions for "synchronous server" and "asynchronous server" terms? Thanks, Kent From: Robert Wilton > Date: Thursday, October 1, 2015 at 5:50 AM To: Mahesh Jethanandani > Cc: Kent Watsen >, "netmod@= ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) On 01/10/2015 00:55, Mahesh Jethanandani wrote: One comment. On Sep 30, 2015, at 8:02 AM, Robert Wilton > wrote: Hi Kent, Just some quick comments inline ... On 30/09/2015 15:31, Kent Watsen wrote: [As a contributor] I find that the term "system" is a bit ambiguous in this context. It is ta= lking about the NMS, the server, or both together? [KENT] I believe that we're talking about the NETCONF/RESTCONF/ server= , specifically in how it processes update requests. Anyway, I've tried to define them relative to the configuration operations = being performed. [KENT] Perhaps these could be collapsed if we use the terms "a/synchronous = server" ? Personally, I think that defining the operations is arguably more useful be= cause it is feasible that you could have a server that supports both sync a= nd async operations and allows the client to choose which semantics should = be used for a particular request. Synchronous configuration operation - A configuration request that the serv= er applies synchronously with respect to the client request. Before the se= rver replies back to the client indicating the success or failure of the op= eration it MUST semantically validate the contents of the request and updat= e the intended configuration of the target datastore. If the request is to= the running datastore then the configuration change MUST also be applied i= n the system before the server replies back to the client. The reply to th= e client indicates whether there are any semantic errors or system errors f= rom applying the configuration change. [KENT] This generally matches my understanding, but here are some thoughts= to improve it: 1. I think the language "semantically validate" would exclude an ephemeral = datastore. We could put a qualifier on it, but I think it can be removed e= ntirely as each datastore already has its own semantics around how it proce= sses update requests. My aim here is potentially tied to the definition of intended config, were = I am suggesting that the system has to at least have been checked that the = request is well formed and any YANG constraints in the data model have been= met, before it is accepted as intended config, otherwise it would be rejec= ted. 2. I like how you call out the running datastore, but it is somewhat NETCON= F-specific. How about something like "If the request impacts the intended = configuration (see term), then..." Yes your text is better and I agree that we should avoid making the descrip= tion NETCONF specific at all. 3. "applied in the system" seems too open ended, how about this: "...MUST = also be propagated to and processed by the operational components of the se= rver before..." ??? So my aim here was to tie it back to the definition of "applied configurati= on", but this could probably be expressed in a more direct way, e.g. perhap= s ".... MUST update the applied configuration in the system before the serv= er replies =85" If I understand this correctly, we are still talking about =93applied confi= guration=94 as configuration that has been written to datastore/hardware/li= ne card etc. It does not imply that anything has come out of it, including = whether the configuration is usable. That operating configuration (and I ju= st introduced another term) will be reflected by derived state. Is that true? Yes. Rather than operating configuration I would perhaps say the "observable sys= tem behaviour is reflected by derived state". E.g. if you were to change the MTU of an interface to a different value (th= at was say incompatible with a peer device) then the "applied configuration= " for the MTU leaf would only tell you whether or not that MTU was actively= being used by the system. It wouldn't tell you that an ISIS session on t= hat interface had gone down due to the MTU incompatibility. That could onl= y be observed by the changing of the derived state representing the status = of the ISIS session (or an alarm). Thanks, Rob --_000_D2389326E4737kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4FE66FEE0EFE884CABF789A0A815503A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Rob,

Can you take all the comments from this thread to update the proposed = definitions for "synchronous server" and "asynchronous serve= r" terms?

Thanks,
Kent

From: Robert Wilton <rwilton@cisco.com>
Date: Thursday, October 1, 2015 at = 5:50 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)



On 01/10/2015 00:55, Mahesh Jethanandani wro= te:
One comment.

On Sep 30, 2015, at 8:02 AM, Robert Wilton <rwilton@cisco.= com> wrote:

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
[As a contributor]


I find that the term &= quot;system" is a bit ambiguous in this context.  It is talking a= bout the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> = server, specifically in how it processes update requests.


Anyway, I've tried to = define them relative to the configuration operations being performed.

[KENT] Perhaps= these could be collapsed if we use the terms "a/synchronous server&qu= ot; ?

Personally, I think that defining the operations is arguably more useful be= cause it is feasible that you could have a server that supports both sync a= nd async operations and allows the client to choose which semantics should = be used for a particular request.




Synchronous configuration operation - A configuration request that the serv= er applies synchronously with respect to the client request.  Before t= he server replies back to the client indicating the success or failure of t= he operation it MUST semantically validate the contents of the request and update the intended configuration of the t= arget datastore.  If the request is to the running datastore then the = configuration change MUST also be applied in the system before the server r= eplies back to the client.  The reply to the client indicates whether there are any semantic errors or system er= rors from applying the configuration change.


[KENT]  This generally matches my understanding, but h= ere are some thoughts to improve it:

1. I think the language "semantically validate" w= ould exclude an ephemeral datastore.  We could put a qualifier on it, = but I think it can be removed entirely as each datastore already has its ow= n semantics around how it processes update requests.

My aim here is potentially tied to the definition of intended config, were = I am suggesting that the system has to at least have been checked that the = request is well formed and any YANG constraints in the data model have been= met, before it is accepted as intended config, otherwise it would be rejected.



2. I like how you call out the running datastore, but it is= somewhat NETCONF-specific.  How about something like "If the req= uest impacts the intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the descrip= tion NETCONF specific at all.


3. "applied in the system" seems too open ended, = how about this:  "...MUST also be propagated to and processed by = the operational components of the server before..." ???

So my aim here was to tie it back to the definition of "applied config= uration", but this could probably be expressed in a more direct way, e= .g. perhaps ".... MUST update the applied configuration in the system = before the server replies =85"

If I understand this correctly, we are still talking about =93applied confi= guration=94 as configuration that has been written to datastore/hardware/li= ne card etc. It does not imply that anything has come out of it, including = whether the configuration is usable. That operating configuration (and I just introduced another term) will be = reflected by derived state.

Is that true?
Yes.

Rather than operating configuration I would perhaps say the "observabl= e system behaviour is reflected by derived state".

E.g. if you were to change the MTU of an interface to a different value (th= at was say incompatible with a peer device) then the "applied configur= ation" for the MTU leaf would only tell you whether or not that MTU wa= s actively being used by the system.   It wouldn't tell you that an ISIS session on that interface had gone down due= to the MTU incompatibility.  That could only be observed by the chang= ing of the derived state representing the status of the ISIS session (or an= alarm).

Thanks,
Rob

 --_000_D2389326E4737kwatsenjunipernet_-- From nobody Tue Oct 6 00:23:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F41A909D for ; Tue, 6 Oct 2015 00:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDIGLW4iC9ZG for ; Tue, 6 Oct 2015 00:22:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFDC1B3879 for ; Tue, 6 Oct 2015 00:20:11 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 08FAB1CC0183; Tue, 6 Oct 2015 09:20:11 +0200 (CEST) From: Ladislav Lhotka To: "Alexander Clemm \(alex\)" , Martin Bjorklund In-Reply-To: References: <20151005.232123.755931242325159302.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 06 Oct 2015 09:20:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "randy_presuhn@mindspring.com" , "netmod@ietf.org" Subject: Re: [netmod] anydata interaction with yang-patch and edit config X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 07:23:00 -0000 "Alexander Clemm (alex)" writes: > Thanks, Martin, this is very clear. > > (Too bad actually - I could see applications for this.) Making this possible for anydata would be a useful improvement over anyxml but that would require the server to be able to parse data submitted in any supported encoding into the same data tree representation as "normal" data nodes. Lada > > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, October 05, 2015 2:21 PM > To: Alexander Clemm (alex) > Cc: j.schoenwaelder@jacobs-university.de; lhotka@nic.cz; randy_presuhn@mindspring.com; netmod@ietf.org > Subject: Re: [netmod] anydata interaction with yang-patch and edit config > > "Alexander Clemm (alex)" wrote: >> Hi, >> >> I have two quick questions with regards to anydata - related to the >> topic of the thread, but concerning a separate topic. >> >> (1) How does yang-patch interact with anydata? In particular, could >> you apply a yang-patch edit to a data node within the anydata? (While >> the module may not have been known at design time, it will be known at >> run time - so presume yes.) >> >> (2) How about edit-config? Can you use edit config to apply >> operations to nodes within the anydata, or just to the blob as a >> whole? (Again, I would assume you can, as the nodes will be known at >> run time.) > > The current text says: > > An anydata node is treated as an opaque chunk of data. This data > can be modified in its entirety only. > > > So the answer to both questions are "no". > > I don't think that the module necessarily must be known at run-time. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 6 00:38:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB561B399D for ; Tue, 6 Oct 2015 00:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZQz2w-t4GOo for ; Tue, 6 Oct 2015 00:38:53 -0700 (PDT) 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 C29E91B39A1 for ; Tue, 6 Oct 2015 00:38:52 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-69-56137a8a47be Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.7C.05274.A8A73165; Tue, 6 Oct 2015 09:38:51 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 09:38:50 +0200 To: Ladislav Lhotka References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> From: Balazs Lengyel Message-ID: <56137A8A.7000202@ericsson.com> Date: Tue, 6 Oct 2015 09:38:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+JvjW53lXCYwaF7zBYXVs1ls5h/sZHV gcljyZKfTB6bLt9hDGCK4rJJSc3JLEst0rdL4Mp4t3k7e8FdyYpnK5YwNzB2C3YxcnBICJhI vD1i0cXICWSKSVy4t56ti5GLQ0jgKKPE7cv/GEFqhATWMEo0OYDUCAvoSGx48YgZxBYRUJa4 OOEnC0RJtMSueYwgYWYBdYk7px6zgdhsAkYSU/vPs4DYvALaEh2fN7KC2CwCKhJL7+wDqxcV iJHo+bWBDaJGUOLkzCdg9ZwCVhL3Xk5jBhnPLGAv8WBrGcR4eYntb+eAXSAkoCHx8MJf1gmM grOQdM9C6JiFpGMBI/MqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAgPbjlt+oOxstvHA8x CnAwKvHwPvgkFCbEmlhWXJl7iFGag0VJnLeZ6UGokEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BsbCo4rTnrM9ql32Nbjka+ExvpjzF76IrljxMfEb95qbzn9VD23v/bZFv3DrWeMjR+9tqX81 k/PerTey3RM+MVR3yLbO2/fo8cH47hJ/voXPf6a+tiq7v5E/2EvpU9w9hbmOd7SCfnAmH2At NN6S7v/qy/OWk+/kzpzOXcf79NO8hXGvTve3yxjMU2Ipzkg01GIuKk4EAKyLY/AzAgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 07:38:54 -0000 Hello, Thanks for the comments. I WANT some clarification of this issue in te RFC. Preferably prohibiting scenarios instead of explaining all the complexities :-( The very least we should say in 6087: avoid embedded choices. regards Balazs On 2015-10-05 19:13, Ladislav Lhotka wrote: >> On 05 Oct 2015, at 17:35, Balazs Lengyel wrote: >> >> Hello, >> What do the mandatory statements mean in the following model ? >> >> choice scen8 { // Embedded choices with multiple mandatory cases; invalid scenario >> case A { >> choice subChoiceA { >> mandatory true; >> case A { >> leaf scen8-num1 { type uint8; } >> } >> case B { >> leaf scen8-num2 { type uint8; } >> } >> } >> } >> case B { >> choice subChoiceB { >> mandatory true; >> case A { >> leaf scen8-num1 { type uint8; } >> } >> case B { >> leaf scen8-num2 { type uint8; } >> } >> } >> } >> } >> >> Answers: >> A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid. >> A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model? > In the first place, it should be an error because of colliding names - all the leaves defined in sub-cases have the same parent. However, pyang doesn't flag it as an error. > >> Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-( > Yes, it is quite complicated. Normally, such embedded choices shouldn't be needed but they can happen if, e.g. the internal choices are defined in groupings. > >> As the very least we SHOULD prohibit mandatory/default on the inside choice. > I think it would be better to ignore them (and tools may issue a warning). > > Lada > >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 00:56:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904431B3A94 for ; Tue, 6 Oct 2015 00:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUay1XQHxg61 for ; Tue, 6 Oct 2015 00:56:28 -0700 (PDT) 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 848101B3A9C for ; Tue, 6 Oct 2015 00:56:28 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c19:bfa1:31a8:ebc0] (unknown [IPv6:2a01:5e0:29:ffff:6c19:bfa1:31a8:ebc0]) by mail.nic.cz (Postfix) with ESMTPSA id 725E8181462; Tue, 6 Oct 2015 09:56:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444118186; bh=FTQ0ox8acvsJUtuarCNN+XtvnH23sI7rxzmQRW3onfw=; h=From:Date:To; b=RwcBwE9fXQJ26VQfBWCdgoBG12VR4zZDDnH7IYB7iugHdRvG4mAg3w9yRYQc5v3YG utr0QXhBE3hdQNonfuITqm9jaT3rfVWGwkdUFGHbvXot5j0HA/36mrVgoICxemErKS XhHI1yi6QUGVG4RyuT6Jx/twzW07Jl8V9L7DRSwc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <56137A8A.7000202@ericsson.com> Date: Tue, 6 Oct 2015 09:56:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A7D8F7D-B662-4EF8-8F4E-CC078145C52F@nic.cz> References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 07:56:30 -0000 > On 06 Oct 2015, at 09:38, Balazs Lengyel = wrote: >=20 > Hello, > Thanks for the comments. > I WANT some clarification of this issue in te RFC. Preferably = prohibiting scenarios instead of explaining all the complexities :-( Interestingly, choice was not allowed as a short-hand case statement in = YANG 1.0 but it has been added in YANG 1.1 - see issue Y29: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-30 Lada > The very least we should say in 6087: avoid embedded choices. > regards Balazs >=20 > On 2015-10-05 19:13, Ladislav Lhotka wrote: >>> On 05 Oct 2015, at 17:35, Balazs Lengyel = wrote: >>>=20 >>> Hello, >>> What do the mandatory statements mean in the following model ? >>>=20 >>> choice scen8 { // Embedded choices with multiple = mandatory cases; invalid scenario >>> case A { >>> choice subChoiceA { >>> mandatory true; >>> case A { >>> leaf scen8-num1 { type uint8; } >>> } >>> case B { >>> leaf scen8-num2 { type uint8; } >>> } >>> } >>> } >>> case B { >>> choice subChoiceB { >>> mandatory true; >>> case A { >>> leaf scen8-num1 { type uint8; } >>> } >>> case B { >>> leaf scen8-num2 { type uint8; } >>> } >>> } >>> } >>> } >>>=20 >>> Answers: >>> A1) They mean nothing because the case around subChoiceA/B might not = exist, in which case its underlying statements are not valid. >>> A2) They mean that one case from both subChoiceA AND subchoiceB must = exist leading to two cases in choice scen8 which is not allowed, hence = this is an invalid model? >> In the first place, it should be an error because of colliding names = - all the leaves defined in sub-cases have the same parent. However, = pyang doesn't flag it as an error. >>=20 >>> Generally I find choices embedded in choices to be so complicated = that IMHO they SHOULD be immediately prohibited. If you think about all = the variants of embedded choices with mandatory and default placed on = some or a bunch of them, even understanding what they mean becomes a = headache. BAD !!!! In the beginning YANG was about easy-understanding. = However these combinations are unclear even after repeatedly reading the = RFC :-( >> Yes, it is quite complicated. Normally, such embedded choices = shouldn't be needed but they can happen if, e.g. the internal choices = are defined in groupings. >>=20 >>> As the very least we SHOULD prohibit mandatory/default on the inside = choice. >> I think it would be better to ignore them (and tools may issue a = warning). >>=20 >> Lada >>=20 >>> regards Balazs >>>=20 >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 6 01:03:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02761B3B13 for ; Tue, 6 Oct 2015 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXbc3_EsViz9 for ; Tue, 6 Oct 2015 01:03:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8986E1ACE5D for ; Tue, 6 Oct 2015 01:03:28 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-53-5613804e9495 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.62.17026.E4083165; Tue, 6 Oct 2015 10:03:26 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 10:03:25 +0200 To: Ladislav Lhotka References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <4A7D8F7D-B662-4EF8-8F4E-CC078145C52F@nic.cz> From: Balazs Lengyel Message-ID: <5613804D.20709@ericsson.com> Date: Tue, 6 Oct 2015 10:03:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4A7D8F7D-B662-4EF8-8F4E-CC078145C52F@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvja5fg3CYwbXtWhYXVs1ls5h/sZHV gcljyZKfTB6bLt9hDGCK4rJJSc3JLEst0rdL4Mr4enoNc8FspYofrZENjO/Fuxg5OCQETCTu TZLtYuQEMsUkLtxbz9bFyMUhJHCUUeLMhonsEM4aRonj344xg1QJC+hIbHjxCMwWEVCWuDjh JwtE0WpGiUU3HzGBJJgF1CXunHrMBmKzCRhJTO0/zwJi8wpoSvyY/ZwdxGYRUJFomvGbFcQW FYiR6Pm1gQ2iRlDi5MwnYPWcAlYSTVemMoJcyixgL/FgaxnEeHmJ7W/ngN0gJKAh8fDCX9YJ jIKzkHTPQuiYhaRjASPzKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAUD245bfuDsbVrx0P MQpwMCrx8D74JBQmxJpYVlyZe4hRmoNFSZy3helBqJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQZG3mhlPo3LDh66aYXz13tlGVyQmXZpb+dfyaBmq92yhx6qpBsaTn5Tpa0rHPewoyHlyFwO dlNuOZWnXz9FGrXnH5z1+KPvob2ZEx5OrKrkNf+j3hFcMVdYRVX3GvspSemXb3bMX/vl3MLH uX9YZBjeFXSLiL7ner7BcKV+fcZJj56Vxe9ZPHYosRRnJBpqMRcVJwIAdo7SPDYCAAA= Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 08:03:30 -0000 The embedded choice is clearly a case of over-complicating YANG. It was a poor choice to allow such cases. Sorry :-) couldn't resist. But seriously, one reason we wanted to design a new modeling language instead of reusing e.g. XSD was because XSD is too complicated, and then we get embedded choice ? Balazs On 2015-10-06 09:56, Ladislav Lhotka wrote: >> On 06 Oct 2015, at 09:38, Balazs Lengyel wrote: >> >> Hello, >> Thanks for the comments. >> I WANT some clarification of this issue in te RFC. Preferably prohibiting scenarios instead of explaining all the complexities :-( > Interestingly, choice was not allowed as a short-hand case statement in YANG 1.0 but it has been added in YANG 1.1 - see issue Y29: > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-30 > > Lada > >> The very least we should say in 6087: avoid embedded choices. >> regards Balazs >> >> On 2015-10-05 19:13, Ladislav Lhotka wrote: >>>> On 05 Oct 2015, at 17:35, Balazs Lengyel wrote: >>>> >>>> Hello, >>>> What do the mandatory statements mean in the following model ? >>>> >>>> choice scen8 { // Embedded choices with multiple mandatory cases; invalid scenario >>>> case A { >>>> choice subChoiceA { >>>> mandatory true; >>>> case A { >>>> leaf scen8-num1 { type uint8; } >>>> } >>>> case B { >>>> leaf scen8-num2 { type uint8; } >>>> } >>>> } >>>> } >>>> case B { >>>> choice subChoiceB { >>>> mandatory true; >>>> case A { >>>> leaf scen8-num1 { type uint8; } >>>> } >>>> case B { >>>> leaf scen8-num2 { type uint8; } >>>> } >>>> } >>>> } >>>> } >>>> >>>> Answers: >>>> A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid. >>>> A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model? >>> In the first place, it should be an error because of colliding names - all the leaves defined in sub-cases have the same parent. However, pyang doesn't flag it as an error. >>> >>>> Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-( >>> Yes, it is quite complicated. Normally, such embedded choices shouldn't be needed but they can happen if, e.g. the internal choices are defined in groupings. >>> >>>> As the very least we SHOULD prohibit mandatory/default on the inside choice. >>> I think it would be better to ignore them (and tools may issue a warning). >>> >>> Lada >>> >>>> regards Balazs >>>> >>>> -- >>>> Balazs Lengyel Ericsson Hungary Ltd. >>>> Senior Specialist >>>> ECN: 831 7320 >>>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 02:22:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42611B3E6D for ; Tue, 6 Oct 2015 02:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxTroknZkHZl for ; Tue, 6 Oct 2015 02:22:06 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2121B3E68 for ; Tue, 6 Oct 2015 02:22:06 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 3EEDAC4175C6; Tue, 6 Oct 2015 11:22:05 +0200 (CEST) To: Balazs Lengyel , Ladislav Lhotka References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> From: Jernej Tuljak Message-ID: <561392BA.4060304@mg-soft.si> Date: Tue, 6 Oct 2015 11:22:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56137A8A.7000202@ericsson.com> Content-Type: multipart/alternative; boundary="------------090509060301080700040503" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:22:09 -0000 This is a multi-part message in MIME format. --------------090509060301080700040503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Balazs Lengyel je 6.10.2015 ob 9:38 napisal: > Hello, > Thanks for the comments. > I WANT some clarification of this issue in te RFC. Your mandatory constraints will never be enforced, due to 7.9.4.: The behavior of the constraint depends on the type of the choice's closest ancestor node in the schema tree which is not a non-presence container (seeSection 7.5.1 ): o If this ancestor is a case node, the constraint is enforced if any other node from the case exists. o Otherwise, it is enforced if the ancestor node exists. First bullet. Clear enough, IMO. Augmentation could change that, though. BTW, do these bullets cover 1.1? The case node is no longer required due to shorthand choice. Note how the text assumes a case node. Jernej > Preferably prohibiting scenarios instead of explaining all the > complexities :-( > The very least we should say in 6087: avoid embedded choices. > regards Balazs > > On 2015-10-05 19:13, Ladislav Lhotka wrote: >>> On 05 Oct 2015, at 17:35, Balazs Lengyel >>> wrote: >>> >>> Hello, >>> What do the mandatory statements mean in the following model ? >>> >>> choice scen8 { // Embedded choices with multiple >>> mandatory cases; invalid scenario >>> case A { >>> choice subChoiceA { >>> mandatory true; >>> case A { >>> leaf scen8-num1 { type uint8; } >>> } >>> case B { >>> leaf scen8-num2 { type uint8; } >>> } >>> } >>> } >>> case B { >>> choice subChoiceB { >>> mandatory true; >>> case A { >>> leaf scen8-num1 { type uint8; } >>> } >>> case B { >>> leaf scen8-num2 { type uint8; } >>> } >>> } >>> } >>> } >>> >>> Answers: >>> A1) They mean nothing because the case around subChoiceA/B might not >>> exist, in which case its underlying statements are not valid. >>> A2) They mean that one case from both subChoiceA AND subchoiceB must >>> exist leading to two cases in choice scen8 which is not allowed, >>> hence this is an invalid model? >> In the first place, it should be an error because of colliding names >> - all the leaves defined in sub-cases have the same parent. However, >> pyang doesn't flag it as an error. >> >>> Generally I find choices embedded in choices to be so complicated >>> that IMHO they SHOULD be immediately prohibited. If you think about >>> all the variants of embedded choices with mandatory and default >>> placed on some or a bunch of them, even understanding what they mean >>> becomes a headache. BAD !!!! In the beginning YANG was about >>> easy-understanding. However these combinations are unclear even >>> after repeatedly reading the RFC :-( >> Yes, it is quite complicated. Normally, such embedded choices >> shouldn't be needed but they can happen if, e.g. the internal choices >> are defined in groupings. >> >>> As the very least we SHOULD prohibit mandatory/default on the inside >>> choice. >> I think it would be better to ignore them (and tools may issue a >> warning). >> >> Lada >> >>> regards Balazs >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > --------------090509060301080700040503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Balazs Lengyel je 6.10.2015 ob 9:38 napisal:
Hello,
Thanks for the comments.
I WANT some clarification of this issue in te RFC.

Your mandatory constraints will never be enforced, due to 7.9.4.:
   The behavior of the constraint depends on the type of the choice's
   closest ancestor node in the schema tree which is not a non-presence
   container (see Section 7.5.1):

   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.
First bullet. Clear enough, IMO. Augmentation could change that, though.

BTW, do these bullets cover 1.1? The case node is no longer required due to shorthand choice. Note how the text assumes a case node.

Jernej

Preferably prohibiting scenarios instead of explaining all the complexities :-(
The very least we should say in 6087: avoid embedded choices.
regards Balazs

On 2015-10-05 19:13, Ladislav Lhotka wrote:
On 05 Oct 2015, at 17:35, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,
What do the mandatory statements mean in the following model ?

           choice scen8 {  // Embedded choices with multiple mandatory cases; invalid scenario
               case A {
                   choice subChoiceA {
                       mandatory true;
                       case A {
                           leaf scen8-num1 { type uint8; }
                       }
                       case B {
                           leaf scen8-num2 { type uint8; }
                       }
                   }
               }
               case B {
                   choice subChoiceB {
                       mandatory true;
                       case A {
                           leaf scen8-num1 { type uint8; }
                       }
                       case B {
                           leaf scen8-num2 { type uint8; }
                       }
                   }
               }
           }

Answers:
A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model?
In the first place, it should be an error because of colliding names - all the leaves defined in sub-cases have the same parent. However, pyang doesn't flag it as an error.

Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-(
Yes, it is quite complicated. Normally, such embedded choices shouldn't be needed but they can happen if, e.g. the internal choices are defined in groupings.

As the very least we SHOULD prohibit mandatory/default on the inside choice.
I think it would be better to ignore them (and tools may issue a warning).

Lada

regards Balazs

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

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







--------------090509060301080700040503-- From nobody Tue Oct 6 02:24:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA71B3E82 for ; Tue, 6 Oct 2015 02:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzzC5VNR4-xd for ; Tue, 6 Oct 2015 02:24:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA421B3E7F for ; Tue, 6 Oct 2015 02:24:13 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-14-5613933b5bb5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.BF.27359.B3393165; Tue, 6 Oct 2015 11:24:11 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 11:24:11 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <5613933B.1080202@ericsson.com> Date: Tue, 6 Oct 2015 11:24:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvja71ZOEwg4dT9C3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsnl1QWLOSt2TjzI1sB4l6WLkZNDQsBE4uXx88wQtpjEhXvr 2UBsIYGjjBJvXsl2MXIB2WsYJZ4euArWICKgLjFzJ0QRm4CRxNT+82BxYQFZiQ07brKD2LwC 2hLLLv8Ai7MIqEjs3LWfCcQWFYiR6Pm1gQ2iRlDi5MwnYDXMAhYSM+efZ4Sw5SW2v53DDHGE hsTDC39ZJzDyzULSMgtJyywkLQsYmVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBAbUwS2/ DXYwvnzueIhRgINRiYf3wSehMCHWxLLiytxDjNIcLErivM1MD0KFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MDKEuJVv8vmx0iC7SWrjjl3NXAuWWMmbfC27v+JoxrX5W7e5BTR+ut1+az1L YGbStNRJSz4b/uBQUdqnn7Ndjk/rb4rjcbNVtdN5ZiX+fV8smTTvVumn/giBny7qM56sO9n3 yI7NNcL2BBvn9T4t7c4Z75K9nqcpr6n0Sy+59sBjx6SGnjAzZiWW4oxEQy3mouJEAHCMFNwJ AgAA Archived-At: Subject: [netmod] Choice corer cases 2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:24:15 -0000 Hello, Some more corner cases for embedded choices, with my solutions in them. How an average operator or even model implementer would figure these out is anyone's guess. regards Balazs choice scen9 { case A { choice subChoiceA { mandatory true; // this mandatory has absolutely no effect as the case A above might not exist case A { leaf scen12-num1 { type uint8; default 1; } // this default has absolutely no effect // if the leaf exists it has a value if you delete it the whole choice scen9 becomes empty } case B { leaf scen12-num2 { type uint8; } } } } case B { leaf scen12-num1 { type uint8; } } } -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 02:25:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2AD1B3E8C for ; Tue, 6 Oct 2015 02:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5TlOedW3LlN for ; Tue, 6 Oct 2015 02:25:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD1201B3E8B for ; Tue, 6 Oct 2015 02:25:15 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 97ED81AE0454; Tue, 6 Oct 2015 11:25:13 +0200 (CEST) Date: Tue, 06 Oct 2015 11:25:13 +0200 (CEST) Message-Id: <20151006.112513.1689468224041909052.mbj@tail-f.com> To: jernejt@mg-soft.si From: Martin Bjorklund In-Reply-To: <561392BA.4060304@mg-soft.si> References: <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <561392BA.4060304@mg-soft.si> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:25:17 -0000 Jernej Tuljak wrote: > Balazs Lengyel je 6.10.2015 ob 9:38 napisal: > > Hello, > > Thanks for the comments. > > I WANT some clarification of this issue in te RFC. > > Your mandatory constraints will never be enforced, due to 7.9.4.: > > The behavior of the constraint depends on the type of the choice's > closest ancestor node in the schema tree which is not a non-presence > container (seeSection 7.5.1 > ): > > o If this ancestor is a case node, the constraint is enforced if any > other node from the case exists. > > o Otherwise, it is enforced if the ancestor node exists. > > First bullet. Clear enough, IMO. Augmentation could change that, > though. > > BTW, do these bullets cover 1.1? The case node is no longer required > due to shorthand choice. Note how the text assumes a case node. Note that a case *node* always exists, even if the shorthand syntax is used. /martin > > Jernej > > > Preferably prohibiting scenarios instead of explaining all the > > complexities :-( > > The very least we should say in 6087: avoid embedded choices. > > regards Balazs > > > > On 2015-10-05 19:13, Ladislav Lhotka wrote: > >>> On 05 Oct 2015, at 17:35, Balazs Lengyel > >>> wrote: > >>> > >>> Hello, > >>> What do the mandatory statements mean in the following model ? > >>> > >>> choice scen8 { // Embedded choices with multiple mandatory > >>> cases; invalid scenario > >>> case A { > >>> choice subChoiceA { > >>> mandatory true; > >>> case A { > >>> leaf scen8-num1 { type uint8; } > >>> } > >>> case B { > >>> leaf scen8-num2 { type uint8; } > >>> } > >>> } > >>> } > >>> case B { > >>> choice subChoiceB { > >>> mandatory true; > >>> case A { > >>> leaf scen8-num1 { type uint8; } > >>> } > >>> case B { > >>> leaf scen8-num2 { type uint8; } > >>> } > >>> } > >>> } > >>> } > >>> > >>> Answers: > >>> A1) They mean nothing because the case around subChoiceA/B might not > >>> exist, in which case its underlying statements are not valid. > >>> A2) They mean that one case from both subChoiceA AND subchoiceB must > >>> exist leading to two cases in choice scen8 which is not allowed, hence > >>> this is an invalid model? > >> In the first place, it should be an error because of colliding names - > >> all the leaves defined in sub-cases have the same parent. However, > >> pyang doesn't flag it as an error. > >> > >>> Generally I find choices embedded in choices to be so complicated that > >>> IMHO they SHOULD be immediately prohibited. If you think about all the > >>> variants of embedded choices with mandatory and default placed on some > >>> or a bunch of them, even understanding what they mean becomes a > >>> headache. BAD !!!! In the beginning YANG was about > >>> easy-understanding. However these combinations are unclear even after > >>> repeatedly reading the RFC :-( > >> Yes, it is quite complicated. Normally, such embedded choices > >> shouldn't be needed but they can happen if, e.g. the internal choices > >> are defined in groupings. > >> > >>> As the very least we SHOULD prohibit mandatory/default on the inside > >>> choice. > >> I think it would be better to ignore them (and tools may issue a > >> warning). > >> > >> Lada > >> > >>> regards Balazs > >>> > >>> -- > >>> Balazs Lengyel Ericsson Hungary Ltd. > >>> Senior Specialist > >>> ECN: 831 7320 > >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > > From nobody Tue Oct 6 02:25:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067131B3E93 for ; Tue, 6 Oct 2015 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpaqWlECjwyo for ; Tue, 6 Oct 2015 02:25:43 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFB1B3E94 for ; Tue, 6 Oct 2015 02:25:42 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 0103AC4175C6; Tue, 6 Oct 2015 11:25:42 +0200 (CEST) To: Balazs Lengyel , Ladislav Lhotka References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <561392BA.4060304@mg-soft.si> From: Jernej Tuljak Message-ID: <56139393.2030108@mg-soft.si> Date: Tue, 6 Oct 2015 11:25:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561392BA.4060304@mg-soft.si> Content-Type: multipart/alternative; boundary="------------090905040709010109000302" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:25:45 -0000 This is a multi-part message in MIME format. --------------090905040709010109000302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Jernej Tuljak je 6.10.2015 ob 11:22 napisal: > Balazs Lengyel je 6.10.2015 ob 9:38 napisal: >> Hello, >> Thanks for the comments. >> I WANT some clarification of this issue in te RFC. > > Your mandatory constraints will never be enforced, due to 7.9.4.: > The behavior of the constraint depends on the type of the choice's > closest ancestor node in the schema tree which is not a non-presence > container (seeSection 7.5.1 ): > > o If this ancestor is a case node, the constraint is enforced if any > other node from the case exists. > > o Otherwise, it is enforced if the ancestor node exists. > First bullet. Clear enough, IMO. Augmentation could change that, though. > > BTW, do these bullets cover 1.1? The case node is no longer required > due to shorthand choice. Note how the text assumes a case node. Just ignore the last two sentences. Its covered. Jernej > > Jernej > >> Preferably prohibiting scenarios instead of explaining all the >> complexities :-( >> The very least we should say in 6087: avoid embedded choices. >> regards Balazs >> >> On 2015-10-05 19:13, Ladislav Lhotka wrote: >>>> On 05 Oct 2015, at 17:35, Balazs Lengyel >>>> wrote: >>>> >>>> Hello, >>>> What do the mandatory statements mean in the following model ? >>>> >>>> choice scen8 { // Embedded choices with multiple >>>> mandatory cases; invalid scenario >>>> case A { >>>> choice subChoiceA { >>>> mandatory true; >>>> case A { >>>> leaf scen8-num1 { type uint8; } >>>> } >>>> case B { >>>> leaf scen8-num2 { type uint8; } >>>> } >>>> } >>>> } >>>> case B { >>>> choice subChoiceB { >>>> mandatory true; >>>> case A { >>>> leaf scen8-num1 { type uint8; } >>>> } >>>> case B { >>>> leaf scen8-num2 { type uint8; } >>>> } >>>> } >>>> } >>>> } >>>> >>>> Answers: >>>> A1) They mean nothing because the case around subChoiceA/B might >>>> not exist, in which case its underlying statements are not valid. >>>> A2) They mean that one case from both subChoiceA AND subchoiceB >>>> must exist leading to two cases in choice scen8 which is not >>>> allowed, hence this is an invalid model? >>> In the first place, it should be an error because of colliding names >>> - all the leaves defined in sub-cases have the same parent. However, >>> pyang doesn't flag it as an error. >>> >>>> Generally I find choices embedded in choices to be so complicated >>>> that IMHO they SHOULD be immediately prohibited. If you think about >>>> all the variants of embedded choices with mandatory and default >>>> placed on some or a bunch of them, even understanding what they >>>> mean becomes a headache. BAD !!!! In the beginning YANG was about >>>> easy-understanding. However these combinations are unclear even >>>> after repeatedly reading the RFC :-( >>> Yes, it is quite complicated. Normally, such embedded choices >>> shouldn't be needed but they can happen if, e.g. the internal >>> choices are defined in groupings. >>> >>>> As the very least we SHOULD prohibit mandatory/default on the >>>> inside choice. >>> I think it would be better to ignore them (and tools may issue a >>> warning). >>> >>> Lada >>> >>>> regards Balazs >>>> >>>> -- >>>> Balazs Lengyel Ericsson Hungary Ltd. >>>> Senior Specialist >>>> ECN: 831 7320 >>>> Mobile: +36-70-330-7909 email: >>>> Balazs.Lengyel@ericsson.com >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------090905040709010109000302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Jernej Tuljak je 6.10.2015 ob 11:22 napisal:
Balazs Lengyel je 6.10.2015 ob 9:38 napisal:
Hello,
Thanks for the comments.
I WANT some clarification of this issue in te RFC.

Your mandatory constraints will never be enforced, due to 7.9.4.:
   The behavior of the constraint depends on the type of the choice's
   closest ancestor node in the schema tree which is not a non-presence
   container (see Section 7.5.1):

   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.
First bullet. Clear enough, IMO. Augmentation could change that, though.

BTW, do these bullets cover 1.1? The case node is no longer required due to shorthand choice. Note how the text assumes a case node.

Just ignore the last two sentences. Its covered.

Jernej


Jernej

Preferably prohibiting scenarios instead of explaining all the complexities :-(
The very least we should say in 6087: avoid embedded choices.
regards Balazs

On 2015-10-05 19:13, Ladislav Lhotka wrote:
On 05 Oct 2015, at 17:35, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,
What do the mandatory statements mean in the following model ?

           choice scen8 {  // Embedded choices with multiple mandatory cases; invalid scenario
               case A {
                   choice subChoiceA {
                       mandatory true;
                       case A {
                           leaf scen8-num1 { type uint8; }
                       }
                       case B {
                           leaf scen8-num2 { type uint8; }
                       }
                   }
               }
               case B {
                   choice subChoiceB {
                       mandatory true;
                       case A {
                           leaf scen8-num1 { type uint8; }
                       }
                       case B {
                           leaf scen8-num2 { type uint8; }
                       }
                   }
               }
           }

Answers:
A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model?
In the first place, it should be an error because of colliding names - all the leaves defined in sub-cases have the same parent. However, pyang doesn't flag it as an error.

Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-(
Yes, it is quite complicated. Normally, such embedded choices shouldn't be needed but they can happen if, e.g. the internal choices are defined in groupings.

As the very least we SHOULD prohibit mandatory/default on the inside choice.
I think it would be better to ignore them (and tools may issue a warning).

Lada

regards Balazs

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

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









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

--------------090905040709010109000302-- From nobody Tue Oct 6 02:27:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450201B3EA7 for ; Tue, 6 Oct 2015 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTj4FxZkGJQD for ; Tue, 6 Oct 2015 02:27:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BE01B3EA5 for ; Tue, 6 Oct 2015 02:27:07 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-97-561393e9f352 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.24.17026.9E393165; Tue, 6 Oct 2015 11:27:05 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 11:27:05 +0200 To: "netmod@ietf.org" References: <5613933B.1080202@ericsson.com> From: Balazs Lengyel Message-ID: <561393E9.2070706@ericsson.com> Date: Tue, 6 Oct 2015 11:27:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5613933B.1080202@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RvflZOEwg8cHNCzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuHfX5gLGrgrDlz4wd7AOIGti5GTQ0LAROJB6zIWCFtM4sK9 9UBxLg4hgaOMEmu67jBBOGsYJRYvnccEUiUsoCWxatsCsG4RAXWJmTvXg9lCAtoSS/s2s4PY bAJGElP7z4NN5QWKTzvZD2azCKhI/Dw1E8wWFYiR6Pm1gQ2iRlDi5MwnQHEODk4BHYmTn4tA TGYBe4kHW8tAKpgF5CW2v53DDLFJQ+Lhhb+sExgFZiFpnoXQMQtJxwJG5lWMosWpxcW56UbG eqlFmcnFxfl5enmpJZsYgeF3cMtv3R2Mq187HmIU4GBU4uF98EkoTIg1say4MvcQozQHi5I4 bwvTg1AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOHv9E6vWbJB+4j8NqkkrUnTzaz9v52q VJb2ayyJ/+Uh37ZA+ZXIzdXrNx9prNCV338w8l+Zxb67z+P2nP+1wl869vZvRdWt6/a23i8s Wh7L9qWH7XDc5KrTK9iEr/7U4xEWkX67h1VDfMsM2bS5vz89Uf9o7bkucldk1xWepsanPffk jM97bVBiKc5INNRiLipOBACvf/u8IAIAAA== Archived-At: Subject: Re: [netmod] Choice corer cases 2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:27:09 -0000 Having statements default/mandatory in the model that seem to mean something, but practically have no effect is most confusing. Balazsd On 2015-10-06 11:24, Balazs Lengyel wrote: > Hello, > Some more corner cases for embedded choices, with my solutions in > them. How an average operator or even model implementer would figure > these out is anyone's guess. regards Balazs > > choice scen9 { > case A { > choice subChoiceA { > mandatory true; // this mandatory has > absolutely no effect as the case A above might not exist > case A { > leaf scen12-num1 { type uint8; default 1; > } // this default has absolutely no effect > // if the leaf exists it has a > value if you delete it the whole choice scen9 becomes empty > } > case B { > leaf scen12-num2 { type uint8; } > } > } > } > case B { > leaf scen12-num1 { type uint8; } > } > } > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 02:32:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83FC1A9111 for ; Tue, 6 Oct 2015 02:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHHIiKWBpf-H for ; Tue, 6 Oct 2015 02:32:21 -0700 (PDT) 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 7E1B71A910E for ; Tue, 6 Oct 2015 02:32:20 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-ce-561395226b88 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.A4.05274.22593165; Tue, 6 Oct 2015 11:32:18 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 11:32:17 +0200 To: Martin Bjorklund , References: <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <561392BA.4060304@mg-soft.si> <20151006.112513.1689468224041909052.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <56139522.5070402@ericsson.com> Date: Tue, 6 Oct 2015 11:32:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006.112513.1689468224041909052.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvja7SVOEwgzPrDC0O/9rDbHFh1Vw2 i+7uZ+wW8y82sjqweCxZ8pPJ4+OM9awemy7fYfTY+GsxSwBLFJdNSmpOZllqkb5dAlfG+d2r WQoOqlZMPb2ApYFxnVQXIyeHhICJxOxD69khbDGJC/fWs4HYQgJHGSUeL1fuYuQCstcwSvRP f8oMkhAW0JHY8OIRmC0iYC3xrfUoK0TRBkaJ1c8usoIkmAXUJFb/uwZWxCZgJDG1/zwLiM0r oC2xbPIRoA0cHCwCKhKXm7xAwqICMRI9vzawQZQISpyc+QSsnFPAUWLbikuMIOXMAvYSD7aW QUyXl9j+dg4zxJ0aEg8v/GWdwCg4C0n3LISOWUg6FjAyr2IULU4tTspNNzLWSy3KTC4uzs/T y0st2cQIDOmDW36r7mC8/MbxEKMAB6MSD++DT0JhQqyJZcWVuYcYpTlYlMR5m5kehAoJpCeW pGanphakFsUXleakFh9iZOLglGpg5P449YrL1IL0jOXaO/5q1flO69gu83HJlWUOp85oXn/D /GLyn8+fhV792vltGcfcLv2aPydkGx68NThdtZW3mvNCnmLxvF9LxWri1SOXK6/uPR23bn2x s1/xhVvdL1pf3fezrK/8Ka/Q3dyUJqQs/K/U7aVZ7TlNZoklhwq0OXKd3TYukAgOVWIpzkg0 1GIuKk4EABvwsG9KAgAA Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:32:22 -0000 Hello Martin, Does this mean the mandatory does have an effect, resulting in an invalid model according to A2? regards Balazs On 2015-10-06 11:25, Martin Bjorklund wrote: > Jernej Tuljak wrote: >> Balazs Lengyel je 6.10.2015 ob 9:38 napisal: >>> Hello, >>> Thanks for the comments. >>> I WANT some clarification of this issue in te RFC. >> Your mandatory constraints will never be enforced, due to 7.9.4.: >> >> The behavior of the constraint depends on the type of the choice's >> closest ancestor node in the schema tree which is not a non-presence >> container (seeSection 7.5.1 >> ): >> >> o If this ancestor is a case node, the constraint is enforced if any >> other node from the case exists. >> >> o Otherwise, it is enforced if the ancestor node exists. >> >> First bullet. Clear enough, IMO. Augmentation could change that, >> though. >> >> BTW, do these bullets cover 1.1? The case node is no longer required >> due to shorthand choice. Note how the text assumes a case node. > Note that a case *node* always exists, even if the shorthand syntax is > used. > > > /martin > > > >> Jernej >> >>> Preferably prohibiting scenarios instead of explaining all the >>> complexities :-( >>> The very least we should say in 6087: avoid embedded choices. >>> regards Balazs >>> >>> On 2015-10-05 19:13, Ladislav Lhotka wrote: >>>>> On 05 Oct 2015, at 17:35, Balazs Lengyel >>>>> wrote: >>>>> >>>>> Hello, >>>>> What do the mandatory statements mean in the following model ? >>>>> >>>>> choice scen8 { // Embedded choices with multiple mandatory >>>>> cases; invalid scenario >>>>> case A { >>>>> choice subChoiceA { >>>>> mandatory true; >>>>> case A { >>>>> leaf scen8-num1 { type uint8; } >>>>> } >>>>> case B { >>>>> leaf scen8-num2 { type uint8; } >>>>> } >>>>> } >>>>> } >>>>> case B { >>>>> choice subChoiceB { >>>>> mandatory true; >>>>> case A { >>>>> leaf scen8-num1 { type uint8; } >>>>> } >>>>> case B { >>>>> leaf scen8-num2 { type uint8; } >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> Answers: >>>>> A1) They mean nothing because the case around subChoiceA/B might not >>>>> exist, in which case its underlying statements are not valid. >>>>> A2) They mean that one case from both subChoiceA AND subchoiceB must >>>>> exist leading to two cases in choice scen8 which is not allowed, hence >>>>> this is an invalid model? >>>> In the first place, it should be an error because of colliding names - >>>> all the leaves defined in sub-cases have the same parent. However, >>>> pyang doesn't flag it as an error. >>>> >>>>> Generally I find choices embedded in choices to be so complicated that >>>>> IMHO they SHOULD be immediately prohibited. If you think about all the >>>>> variants of embedded choices with mandatory and default placed on some >>>>> or a bunch of them, even understanding what they mean becomes a >>>>> headache. BAD !!!! In the beginning YANG was about >>>>> easy-understanding. However these combinations are unclear even after >>>>> repeatedly reading the RFC :-( >>>> Yes, it is quite complicated. Normally, such embedded choices >>>> shouldn't be needed but they can happen if, e.g. the internal choices >>>> are defined in groupings. >>>> >>>>> As the very least we SHOULD prohibit mandatory/default on the inside >>>>> choice. >>>> I think it would be better to ignore them (and tools may issue a >>>> warning). >>>> >>>> Lada >>>> >>>>> regards Balazs >>>>> >>>>> -- >>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>> Senior Specialist >>>>> ECN: 831 7320 >>>>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 02:35:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9B91AD0C0 for ; Tue, 6 Oct 2015 02:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAg6u8Imxvb7 for ; Tue, 6 Oct 2015 02:34:57 -0700 (PDT) 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 7283F1A9117 for ; Tue, 6 Oct 2015 02:34:57 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:48e5:f1a7:475e:23a5] (unknown [IPv6:2a01:5e0:29:ffff:48e5:f1a7:475e:23a5]) by mail.nic.cz (Postfix) with ESMTPSA id 07A4618036B; Tue, 6 Oct 2015 11:34:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444124096; bh=svGTNAmDaHRSx5nRA+LDSOXxQaR4u8c7oVs78GKT+0k=; h=From:Date:To; b=Om0/pQPQ9QlssK5+kOtAKCH+N+zvZ6hLtXoJnE+8K/4THTtXQ2n6gCLq9hWbESTE0 Nk5Bz1/nnFHyqtco1FlhSoZ1PlfrDVNB7Itp1CCaUs2wTdneA39itTFockQdoJJsK5 wINbcLabzmk0LjNeIwcjZ0Z+x7L5TYIEhdhBL6wg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <561393E9.2070706@ericsson.com> Date: Tue, 6 Oct 2015 11:34:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BAF6C03-B703-430D-9ABE-4D8C02A9C6CE@nic.cz> References: <5613933B.1080202@ericsson.com> <561393E9.2070706@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corer cases 2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:34:59 -0000 > On 06 Oct 2015, at 11:27, Balazs Lengyel = wrote: >=20 > Having statements default/mandatory in the model that seem to mean = something, but practically have no effect is most confusing. They do have an effect but only in some contexts: - default on a leaf(-list) inside a case applies when the case is = designated as default, - mandatory applies if some nodes from that case exist. The latter condition requires that no two cases contain data nodes of = the same name - in your example, if "scen12-num1" is present, it is = impossible to determine whether it comes from case A/A or B. So this = should be an error. Lada > Balazsd >=20 > On 2015-10-06 11:24, Balazs Lengyel wrote: >> Hello, >> Some more corner cases for embedded choices, with my solutions in = them. How an average operator or even model implementer would figure = these out is anyone's guess. regards Balazs >>=20 >> choice scen9 { >> case A { >> choice subChoiceA { >> mandatory true; // this mandatory has = absolutely no effect as the case A above might not exist >> case A { >> leaf scen12-num1 { type uint8; default 1; } = // this default has absolutely no effect >> // if the leaf exists it has a = value if you delete it the whole choice scen9 becomes empty >> } >> case B { >> leaf scen12-num2 { type uint8; } >> } >> } >> } >> case B { >> leaf scen12-num1 { type uint8; } >> } >> } >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 6 02:38:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1711B3287 for ; Tue, 6 Oct 2015 02:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ8YGNKjEUtA for ; Tue, 6 Oct 2015 02:38:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD731B3EBB for ; Tue, 6 Oct 2015 02:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47992; q=dns/txt; s=iport; t=1444124296; x=1445333896; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=shr8ng/yh6G8l61tjHZ94RJhshj/f7O22Tb4He5Oc20=; b=SUL/N0Kse8bnBreaJR/TfYteIzjcv/mD4lIiTS5OjSd1f31pZ1vsAOOR QEGvFOUBQzCEholqcTLj15FEVH0TGM51Wybq2QAKsh11XwENAQ9NgLoNX 5svpTj3vonbg32D5Yg94KFN4ot9ZUFuQnbNmtAUWE3l1AFB5yBCqbdp3i o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMAQBilRNW/xbLJq1UCoJagSFuviIBDYFXAxcBCYUvSgKBbxQBAQEBAQEBgQqEJAEBAQMBAQEBF1QKAQUHBAsOAwMBAQEBCQwKAQEGBwkDAgECARUfCQgGDQYCAQEXhWGCKggNvkcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzg3iBBoQqBgUGAQY6EQcGBIQkBYc1hwSHS4gHhRCBV4Q5gwAjiXOEWYNvHwEBQoJEgT89M4Z3CBeBKQEBAQ X-IronPort-AV: E=Sophos;i="5.17,643,1437436800"; d="scan'208,217";a="612040170" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 06 Oct 2015 09:38:12 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t969cBqQ007778; Tue, 6 Oct 2015 09:38:11 GMT To: Kent Watsen References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> From: Robert Wilton Message-ID: <56139683.9010909@cisco.com> Date: Tue, 6 Oct 2015 10:38:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040104040109020506070909" Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:38:21 -0000 This is a multi-part message in MIME format. --------------040104040109020506070909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, On 06/10/2015 01:40, Kent Watsen wrote: > > This issue appears to have become more like issue #5 – should we mark > this one a duplicate of the other? I suggest that we can just finalize on the text being discussed to replace 1.D and then resolve issue #1. Jason had proposed this text: When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the applied equivalent of the node (whether that be a corresponding node in the data model, an attribute associated with the intended config node, the configuration node read from a different datastore or context, etc) must match the intended configuration node. Or perhaps this slightly briefer alternative is better?: D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding, possibly notional, applied configuration node must match the intended configuration node. > > As for this, what does it mean? > > > > - templates: the intended data model and applied data model are > disjoint > > > > This came up towards the end of the interim, and my understanding is > that it > > acceptable for any templating solution to have to adhere to that > constraint above. > Specifically, would this imply that the flattening of the template > would have to now take place at each operational component in the > system – as opposed to being flattened by a centralized component > (e.g., in the control plane). If so, then I think it might add > significant costs to the servers, as then *all* downstream components > would have to know how to flatten templates. Not necessarily. I see this as meaning that YANG templates should be solved as a separate YANG extension/draft. draft-ietf-l3sm-l3vpn-service-model uses a concept of adhoc templating. It would be good if templating could be handled in a consistent, and ideally generic way. In terms of the opstate requirements I think that it would probably require that for any solution: - if the template itself was expressed as configuration then the template itself would have both intended and corresponding applied configuration nodes. - any expanded template written to the configuration space would have both intended configuration and applied configuration nodes. I think that there are possible solutions to how templating could work with a centralized configuration component if the configuration component is able to send the expanded template to the downstream components without writing the expanded template to the configuration datastore. Such an solution (possibly modelled on the with-defaults extension) would also potentially be able to provide separate views of the configuration data that shows both the compressed and expanded views of the configuration data. > > Related to this, how do we handle the case where the downstream > component's native data model is different. For instance, imagine a > mixed IP/optical router that has subtended ROADM and optical > amplifiers attached. So, when the control plane sends the config to > the ROADM, it first converts it to the ROADM's native data model. For > this case, in order to present the applied config with the same data > model, would the control plane have to perform the reverse mapping? Yes, I think so. Or, if the server knows what is in the config update that is being sent to the ROADM, then it could track the status of config update, and then mark the associated configuration nodes as being applied when the ROADM has indicated that it has fully completed the config request. Rob > > > Kent // as a contributor > > > > > From: Andy Bierman > > Date: Saturday, October 3, 2015 at 11:38 AM > To: Robert Wilton > > Cc: Randy Presuhn >, "netmod@ietf.org > " > > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > Hi, > > So the applied leaf is being used as a complicated boolean? > > IMO your draft (using attributes similar to > with-defaults=report-all-tagged, > not containers) is the best compromise because: > > - the data models are not touched > - no datastores are required > - the same string is used to identify the data node no matter what > state needs to be checked > - client has to request the metadata somehow so no impact > on clients that do not care about this issue > - a single boolean attribute applied="true" is all that is really > needed > > > > Andy > > > > On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton > wrote: > > Hi Andy, > > It was clarified by Rob Shakir in the meeting that the applied-cfg > leaf is only used to indicate whether the configuration > represented by the intended-cfg leaf has been applied. > > But it appears that my proposed text for 1D may have caused some > confusion. Please see inline ... > > On 02/10/2015 19:11, Andy Bierman wrote: >> Hi, >> >> What about the data models that do not follow 1D? >> >> - templates: the intended data model and applied data model are >> disjoint > > This came up towards the end of the interim, and my understanding > is that it acceptable for any templating solution to have to > adhere to that constraint above. > > >> - 'auto-duplex' corner-case: the intended and applied leaf are >> the same, but they >> will never have the same value > The intention is: > - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex > to be determined by auto-negotiation) > - applied-cfg duplex leaf = "auto" (i.e. device will determine > duplex by auto-negotiation) > - related derived-state duplex-state leaf = "full" or "half" or > "unknown" (always represents the actual duplex setting of the > interface) > >> - 'use-dhcp' corner-case: intended config just enables specific >> derived state >> to be used; disjoint data models > Similarly: > - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP > assigned IP addresses) > - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP > to assign IP addresses) > - related derived-state IP address leaf = A.B.C.D (Primary IP > address in use for the interface - if any). > > >> >> Somebody asked an important question at the interim: >> Is the intent of this group to limit all YANG data models such that >> they conform to 1D? (IMO that is a non-starter) > It is not my intention that my proposed 1D text makes are > constraint on the structure of YANG data models. > >> >> IMO requirement 1D presume that the solution involves separate >> objects in the YANG data model for intended and applied states, >> and therefore it is an invalid requirement. > > That is not the intention of my phrasing, perhaps it needs further > refinement? > > The intention is that a config node has two notional states in the > data store, intended and applied. The aim is to tightly relate > those two notional states as to when they are allowed to be the > same or different. > >> >> Only the 2 protocol-based solutions address this issue by using >> the same object identifier no matter which state is being queried. > I don't think that this requirement excludes any of the three > solutions that have been proposed (or the use of attribute to > return intended vs applied state metadata). > > Thanks, > Rob > > >> >> >> >> Andy >> >> On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) >> > > wrote: >> >> I agree with "e.g." rather than "i.e.". I'm sure there are >> lots of other examples of situations where intended config >> and applied config don't match when we consider the variety >> of systems out there that may use NETCONF/YANG. We should >> include some of these examples in the draft (in some >> informational section and have a reference/pointer to them >> just after the definition). >> >> Note that this updated definition for 1.D does not preclude >> the applied config object from matching the intended *before* >> it has been applied. Do we need to clarify that with some >> "conversely" clause or is that clear enough when considering >> the other requirements ? >> >> We should also cleanly define "applied" (and provide >> illustrative examples of when something is and is not >> applied). Should that be a separate email thread ? >> >> Jason >> >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org >> ] On Behalf Of Robert Wilton >> Sent: Friday, October 02, 2015 5:24 >> To: Randy Presuhn; netmod@ietf.org >> Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify >> "fully synchronized" in "Requirement 1.D" >> >> Hi Randy, >> >> On 01/10/2015 23:27, Randy Presuhn wrote: >> > Hi - >> > >> >> From: Robert Wilton > > >> >> Sent: Oct 1, 2015 10:01 AM >> >> To: "netmod@ietf.org " >> > >> >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify >> "fully synchronized" in "Requirement 1.D" >> >> >> >> To clarify what I failed to eloquently express in the >> interim meeting. >> >> >> >> I propose changing the text for requirement 1.D. This also >> removes >> >> the need to define what fully synchronized means. >> >> >> >> >> >> Old text for 1.D >> >> D. For asynchronous systems, when fully >> synchronized, the data >> >> in the applied configuration is the same as >> the data in the >> >> intended configuration. >> >> >> >> >> >> Proposed text for 1.D: >> >> D. When the configuration change for any intended >> >> configuration leaf has been successfully >> applied to the >> >> system (i.e. not failed, nor deferred due to >> absent hardware) >> >> then the existence and value of the >> corresponding applied >> >> configuration leaf must match the intended >> configuration >> >> leaf. >> > Are "not failed" and "deferred due to absent hardware" the >> > *only* possibilities? If not, then the "i.e." needs to be >> replaced >> > with an "e.g." >> I'm not sure if it is the only possibility. Two other >> possible reason might be: >> - Configuration that cannot be applied because some >> dependent configuration hasn't been applied. (E.g. if you >> have configuration where an interface-ref couldn't be >> fulfilled because the referenced interface configuration >> hadn't been applied because either it had failed or been >> deferred due to absent hardware). But perhaps this would be >> classified as being one of the two cases above? >> - There is also the case the configuration is currently in >> the process of being applied. >> >> If it is agreed that github issue #2 (i.e. "Is there a >> requirement to indicate why intended config != applied cfg?") >> is a valid requirement, and I think that there might have >> been some support for this in the interim meeting yesterday, >> then I would hope that the final solution would enumerate the >> reasons why the applied configuration may not match the >> intended configuration. >> >> As such, changing from i.e. to e.g. seems like a good choice. >> >> So also taking into account Martin's suggestion the updated >> proposed text for 1.D would be: >> >> D. When the configuration change for any intended >> configuration node has been successfully applied >> to the >> system (e.g. not failed, nor deferred due to >> absent hardware) >> then the existence and value of the corresponding >> applied >> configuration node must match the intended >> configuration >> node. >> >> Thanks, >> Rob >> >> >> > >> > Randy >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> > . >> > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > --------------040104040109020506070909 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Kent,

On 06/10/2015 01:40, Kent Watsen wrote:

This issue appears to have become more like issue #5 – should we mark this one a duplicate of the other?

I suggest that we can just finalize on the text being discussed to replace 1.D and then resolve issue #1.

Jason had proposed this text:

When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the applied equivalent of the node (whether that be a corresponding node in the data model, an attribute associated with the intended config node, the configuration node read from a different datastore or context, etc) must match the intended configuration node.

Or perhaps this slightly briefer alternative is better?:

        D.  When the configuration change for any intended
            configuration node has been successfully applied to the
            system (e.g. not failed, nor deferred due to absent hardware)
            then the existence and value of the corresponding, possibly
            notional, applied configuration node must match the intended
            configuration node.


As for this, what does it mean?

> >   - templates: the intended data model and applied data model are disjoint
> 
> This came up towards the end of the interim, and my understanding is that it 
> acceptable for any templating solution to have to adhere to that constraint above.
 
Specifically, would this imply that the flattening of the template would have to now take place at each operational component in the system – as opposed to being flattened by a centralized component (e.g., in the control plane).   If so, then I think it might add significant costs to the servers, as then *all* downstream components would have to know how to flatten templates.
Not necessarily.  I see this as meaning that YANG templates should be solved as a separate YANG extension/draft. draft-ietf-l3sm-l3vpn-service-model uses a concept of adhoc templating.  It would be good if templating could be handled in a consistent, and ideally generic way.

In terms of the opstate requirements I think that it would probably require that for any solution:
 - if the template itself was expressed as configuration then the template itself would have both intended and corresponding applied configuration nodes.
 - any expanded template written to the configuration space would have both intended configuration and applied configuration nodes.

I think that there are possible solutions to how templating could work with a centralized configuration component if the configuration component is able to send the expanded template to the downstream components without writing the expanded template to the configuration datastore.  Such an solution (possibly modelled on the with-defaults extension) would also potentially be able to provide separate views of the configuration data that shows both the compressed and expanded views of the configuration data.


Related to this, how do we handle the case where the downstream component's native data model is different.  For instance, imagine a mixed IP/optical router that has subtended ROADM and optical amplifiers attached.  So, when the control plane sends the config to the ROADM, it first converts it to the ROADM's native data model.  For this case, in order to present the applied config with the same data model, would the control plane have to perform the reverse mapping?
Yes, I think so.

Or, if the server knows what is in the config update that is being sent to the ROADM, then it could track the status of config update, and then mark the associated configuration nodes as being applied when the ROADM has indicated that it has fully completed the config request.

Rob




Kent   // as a contributor




From: Andy Bierman <andy@yumaworks.com>
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton <rwilton@cisco.com>
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi,

So the applied leaf is being used as a complicated boolean?

IMO your draft (using attributes similar to with-defaults=report-all-tagged,
not containers) is the best compromise because:

   - the data models are not touched
   - no datastores are required
   - the same string is used to identify the data node no matter what
     state needs to be checked
   - client has to request the metadata somehow so no impact
     on clients that do not care about this issue
   - a single boolean attribute applied="true" is all that is really needed



Andy



On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only used to indicate whether the configuration represented by the intended-cfg leaf has been applied.

But it appears that my proposed text for 1D may have caused some confusion.  Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
Hi,

What about the data models that do not follow 1D?

  - templates: the intended data model and applied data model are disjoint

This came up towards the end of the interim, and my understanding is that it acceptable for any templating solution to have to adhere to that constraint above.


  - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they
    will never have the same value
The intention is:
  - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be determined by auto-negotiation)
  - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by auto-negotiation)
  - related derived-state duplex-state leaf = "full" or "half" or "unknown" (always represents the actual duplex setting of the interface)

  - 'use-dhcp' corner-case: intended config just enables specific derived state
     to be used; disjoint data models
Similarly:
  - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP addresses)
  - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP addresses)
  - related derived-state IP address leaf = A.B.C.D (Primary IP address in use for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refinement?

The intention is that a config node has two notional states in the data store, intended and applied.  The aim is to tightly relate those two notional states as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions that have been proposed (or the use of attribute to return intended vs applied state metadata).

Thanks,
Rob





Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
I agree with "e.g." rather than "i.e.".  I'm sure there are lots of other examples of situations where intended config and applied config don't match when we consider the variety of systems out there that may use NETCONF/YANG.  We should include some of these examples in the draft (in some informational section and have a reference/pointer to them just after the definition).

Note that this updated definition for 1.D does not preclude the applied config object from matching the intended *before* it has been applied.  Do we need to clarify that with some "conversely" clause or is that clear enough when considering the other requirements ?

We should also cleanly define "applied" (and provide illustrative examples of when something is and is not applied).  Should that be a separate email thread ?

Jason


-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; netmod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi Randy,

On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwilton@cisco.com>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org" <netmod@ietf.org>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the interim meeting.
>>
>> I propose changing the text for requirement 1.D. This also removes
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>>         D.  For asynchronous systems, when fully synchronized, the data
>>             in the applied configuration is the same as the data in the
>>             intended configuration.
>>
>>
>> Proposed text for 1.D:
>>         D.  When the configuration change for any intended
>>             configuration leaf has been successfully applied to the
>>             system (i.e. not failed, nor deferred due to absent hardware)
>>             then the existence and value of the corresponding applied
>>             configuration leaf must match the intended configuration
>>             leaf.
> Are "not failed" and "deferred due to absent hardware" the
> *only* possibilities?  If not, then the "i.e." needs to be replaced
> with an "e.g."
I'm not sure if it is the only possibility.  Two other possible reason might be:
  - Configuration that cannot be applied because some dependent configuration hasn't been applied.  (E.g. if you have configuration where an interface-ref couldn't be fulfilled because the referenced interface configuration hadn't been applied because either it had failed or been deferred due to absent hardware).  But perhaps this would be classified as being one of the two cases above?
  - There is also the case the configuration is currently in the process of being applied.

If it is agreed that github issue #2 (i.e. "Is there a requirement to indicate why intended config != applied cfg?") is a valid requirement, and I think that there might have been some support for this in the interim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configuration may not match the intended configuration.

As such, changing from i.e. to e.g. seems like a good choice.

So also taking into account Martin's suggestion the updated proposed text for 1.D would be:

        D.  When the configuration change for any intended
            configuration node has been successfully applied to the
            system (e.g. not failed, nor deferred due to absent hardware)
            then the existence and value of the corresponding applied
            configuration node must match the intended configuration
            node.

Thanks,
Rob


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

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

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

--------------040104040109020506070909-- From nobody Tue Oct 6 02:48:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCA1B3ECF for ; Tue, 6 Oct 2015 02:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zthm9znKMdsB for ; Tue, 6 Oct 2015 02:48:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C831B3ECE for ; Tue, 6 Oct 2015 02:48:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E77B1FCE; Tue, 6 Oct 2015 11:48:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fecUiSP1JT2T; Tue, 6 Oct 2015 11:48:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Oct 2015 11:48:13 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 112B620057; Tue, 6 Oct 2015 11:48:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J5OwJZq3XoX1; Tue, 6 Oct 2015 11:48:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F73920054; Tue, 6 Oct 2015 11:48:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 263EA377DF6A; Tue, 6 Oct 2015 11:48:08 +0200 (CEST) Date: Tue, 6 Oct 2015 11:48:08 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20151006094806.GB39891@elstar.local> Mail-Followup-To: Balazs Lengyel , Ladislav Lhotka , "netmod@ietf.org" References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <4A7D8F7D-B662-4EF8-8F4E-CC078145C52F@nic.cz> <5613804D.20709@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5613804D.20709@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:48:17 -0000 On Tue, Oct 06, 2015 at 10:03:25AM +0200, Balazs Lengyel wrote: > The embedded choice is clearly a case of over-complicating YANG. It was > a poor choice to allow such cases. > Sorry :-) couldn't resist. > > But seriously, one reason we wanted to design a new modeling language > instead of reusing e.g. XSD was because XSD is too complicated, and then > we get embedded choice ? I think embedded choices were in YANG 1 and hence this is not a new issue specific to YANG 1.1. Please correct me if I am wrong. I am personally fine with embedded choices if the semantics are well defined so that implementations interpret them the same way. Have you tested different tools? /js PS: It is possible to write obfuscated code in almost all languages; I think the question is more whether the regular common use of the language is intuitive. A good language IMHO follows a set of simple general rules; attempts to rule out constructions that some people find obscure can turn a set of simple general rules into a complicated collection of special case constructions that make language maintenance and implementation a nightmare. -- 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 Oct 6 02:57:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361501B3EEE for ; Tue, 6 Oct 2015 02:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_6Pi2LjZkE0 for ; Tue, 6 Oct 2015 02:57:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE2F1B3EE5 for ; Tue, 6 Oct 2015 02:57:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-24-56139afaef9e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.0A.29154.AFA93165; Tue, 6 Oct 2015 11:57:14 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 11:57:14 +0200 To: Ladislav Lhotka , "netmod@ietf.org" References: <561298B3.1040105@ericsson.com> <627189A4-7205-4E3A-9CD8-4E4AF54B105B@nic.cz> <56137A8A.7000202@ericsson.com> <4A7D8F7D-B662-4EF8-8F4E-CC078145C52F@nic.cz> <5613804D.20709@ericsson.com> <20151006094806.GB39891@elstar.local> From: Balazs Lengyel Message-ID: <56139AFA.2080801@ericsson.com> Date: Tue, 6 Oct 2015 11:57:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006094806.GB39891@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje6vWcJhBg3vNSwurJrLZjH/YiOr A5PHkiU/mTw2Xb7DGMAUxWWTkpqTWZZapG+XwJXxcv0VpoJG3or3F2YwNzC2cHUxcnJICJhI fDswhRHCFpO4cG89WxcjF4eQwFFGies/VrJDOGsYJZ6vfsoOUiUsoCOx4cUjZhBbRMBD4nr/ RUaIoo+MEse/LQYbxSZgJDG1/zwLiM0roC3x6/ZvNhCbRUBFYt25U2A1ogIxEj2/NrBB1AhK nJz5BKyeE6h3xpRFQAs4OJgF7CUebC0DCTMLyEtsfzsHbK+QgIbEwwt/WScwCsxC0j0LoWMW ko4FjMyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQLD8uCW31Y7GA8+dzzEKMDBqMTD++CT UJgQa2JZcWXuIUZpDhYlcd5mpgehQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhnWasUbF5g 3mQgWpbV2x74tM00u0bjywbr+RWy9usiZybLZeXZrONR+LWf3bXL46PZ5On/Vpz5xH+i3pYn +ceKMwo/zS1XL/4fH2I5Y23mcb3at0K987+qLdvy5+os57dtkQ3ap4KU0o9+tcz81/zwwKln bxbYOlV1bzhutvb9oVOR6i0uGfeVWIozEg21mIuKEwGrCX5fLAIAAA== Archived-At: Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:57:18 -0000 Hello, At least for naming conflicts within the deeper cases pyang and yangdump work differently. Neither of them gave me a warning that some of my mandatory/default statements have no effect. regards Balazs On 2015-10-06 11:48, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 10:03:25AM +0200, Balazs Lengyel wrote: >> The embedded choice is clearly a case of over-complicating YANG. It was >> a poor choice to allow such cases. >> Sorry :-) couldn't resist. >> >> But seriously, one reason we wanted to design a new modeling language >> instead of reusing e.g. XSD was because XSD is too complicated, and then >> we get embedded choice ? > I think embedded choices were in YANG 1 and hence this is not a new > issue specific to YANG 1.1. Please correct me if I am wrong. > > I am personally fine with embedded choices if the semantics are well > defined so that implementations interpret them the same way. Have you > tested different tools? > > /js > > PS: It is possible to write obfuscated code in almost all languages; I > think the question is more whether the regular common use of the > language is intuitive. A good language IMHO follows a set of > simple general rules; attempts to rule out constructions that some > people find obscure can turn a set of simple general rules into a > complicated collection of special case constructions that make > language maintenance and implementation a nightmare. > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 03:05:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180F61B3F04 for ; Tue, 6 Oct 2015 03:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPpWSaaZs6QO for ; Tue, 6 Oct 2015 03:05:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4C51B3F01 for ; Tue, 6 Oct 2015 03:05:13 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id E37421AE0454; Tue, 6 Oct 2015 12:05:11 +0200 (CEST) Date: Tue, 06 Oct 2015 12:05:11 +0200 (CEST) Message-Id: <20151006.120511.1868289601223634801.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <5613933B.1080202@ericsson.com> References: <5613933B.1080202@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Choice corer cases 2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 10:05:15 -0000 Balazs Lengyel wrote: > Hello, > Some more corner cases for embedded choices, with my solutions in > them. How an average operator or even model implementer would figure > these out is anyone's guess. regards Balazs > > choice scen9 { > case A { > choice subChoiceA { > mandatory true; // this mandatory has absolutely no > effect as the case A above might not exist > case A { > leaf scen12-num1 { type uint8; default 1; } // this > default has absolutely no effect > // if the leaf exists it has a value if > you delete it the whole choice scen9 > becomes empty > } > case B { > leaf scen12-num2 { type uint8; } > } > } > } > case B { > leaf scen12-num1 { type uint8; } > } > } Note that this is similar to a simple choice: choice x { case a { leaf foo { type int32; default 42; } } } /martin From nobody Tue Oct 6 03:12:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43581B3F18 for ; Tue, 6 Oct 2015 03:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA21OEl6q13t for ; Tue, 6 Oct 2015 03:12:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1E1B3F15 for ; Tue, 6 Oct 2015 03:12:32 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DB671AE0454; Tue, 6 Oct 2015 12:12:31 +0200 (CEST) Date: Tue, 06 Oct 2015 12:12:31 +0200 (CEST) Message-Id: <20151006.121231.1007819349416818738.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <56139AFA.2080801@ericsson.com> References: <5613804D.20709@ericsson.com> <20151006094806.GB39891@elstar.local> <56139AFA.2080801@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 10:12:34 -0000 Balazs Lengyel wrote: > Hello, > At least for naming conflicts within the deeper cases pyang and > yangdump work differently. Tools may have bugs ;-) The pyang bug was fixed some time ago. > Neither of them gave me a warning that some of my mandatory/default > statements have no effect. I don't think it is correct to say that they don't have effect. As Jernej pointed out, augmentations may add nodes to the case, so that if the augmented node is created, the original leaf's default value is in effect. /martin > regards Balazs > > On 2015-10-06 11:48, Juergen Schoenwaelder wrote: > > On Tue, Oct 06, 2015 at 10:03:25AM +0200, Balazs Lengyel wrote: > >> The embedded choice is clearly a case of over-complicating YANG. It > >> was > >> a poor choice to allow such cases. > >> Sorry :-) couldn't resist. > >> > >> But seriously, one reason we wanted to design a new modeling language > >> instead of reusing e.g. XSD was because XSD is too complicated, and > >> then > >> we get embedded choice ? > > I think embedded choices were in YANG 1 and hence this is not a new > > issue specific to YANG 1.1. Please correct me if I am wrong. > > > > I am personally fine with embedded choices if the semantics are well > > defined so that implementations interpret them the same way. Have you > > tested different tools? > > > > /js > > > > PS: It is possible to write obfuscated code in almost all languages; I > > think the question is more whether the regular common use of the > > language is intuitive. A good language IMHO follows a set of > > simple general rules; attempts to rule out constructions that some > > people find obscure can turn a set of simple general rules into a > > complicated collection of special case constructions that make > > language maintenance and implementation a nightmare. > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Oct 6 04:47:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83971B3FDC for ; Tue, 6 Oct 2015 04:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLTjb0wz2YfZ for ; Tue, 6 Oct 2015 04:47:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C97C1B3FDD for ; Tue, 6 Oct 2015 04:47:45 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-fb-5613b4dfd30f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.3D.27359.FD4B3165; Tue, 6 Oct 2015 13:47:43 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 13:47:42 +0200 To: Martin Bjorklund References: <5613804D.20709@ericsson.com> <20151006094806.GB39891@elstar.local> <56139AFA.2080801@ericsson.com> <20151006.121231.1007819349416818738.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <5613B4DF.4020007@ericsson.com> Date: Tue, 6 Oct 2015 13:47:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006.121231.1007819349416818738.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje79LcJhBhve61hcWDWXzaK7+xm7 xfyLjawOzB5Llvxk8th0+Q6jx8Zfi1kCmKO4bFJSczLLUov07RK4Mi5cOc1U8FeoovHdDJYG xvt8XYycHBICJhKvthxihLDFJC7cW8/WxcjFISRwlFFi0fFbLBDOGkaJ/+vfMIFUCQvoSGx4 8YgZxBYRUJV4snMtVNEKRonG/yfYQBLMAmoSq/9dAytiEzCSmNp/ngXE5hXQltj3ch9QDQcH i4CKxL5bmSBhUYEYiZ5fG9ggSgQlTs58AlbOKeAosefmPnaQcmYBe4kHW8sgpstLbH87B2y6 kICGxMMLf1knMArOQtI9C6FjFpKOBYzMqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECA/jg lt8GOxhfPnc8xCjAwajEw/vgk1CYEGtiWXFl7iFGaQ4WJXHeZqYHoUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYtZbc6XA6v8i46PSHwjfC50Xfz8yytXd94NNW4Lnn8Ftm7kdRd9XjjQ48 2cNzpjUtxf7H7xr2XQuM2lTvmj68YXg+/Mfb+38u/81fGLKibkbqL5tHkrP4/vTVaIZach6Z VHbIaxen+22+uFff1t6zOD55gbmsSLLf9xOzHJaf3RkxJcWTfc+1v0osxRmJhlrMRcWJAC9x 51VBAgAA Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Choice corner Cases -1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 11:47:48 -0000 So you say the augmenting module modifies how the augmented module works. This sounds like a side effect, that will only be understood by gurus. Balazs On 2015-10-06 12:12, Martin Bjorklund wrote: > Neither of them gave me a warning that some of my mandatory/default > statements have no effect. > I don't think it is correct to say that they don't have effect. As > Jernej pointed out, augmentations may add nodes to the case, so that > if the augmented node is created, the original leaf's default value is > in effect. > > > /martin > > >> regards Balazs >> >> On 2015-10-06 11:48, Juergen Schoenwaelder wrote: >>> On Tue, Oct 06, 2015 at 10:03:25AM +0200, Balazs Lengyel wrote: >>>> The embedded choice is clearly a case of over-complicating YANG. It >>>> was >>>> a poor choice to allow such cases. >>>> Sorry :-) couldn't resist. >>>> >>>> But seriously, one reason we wanted to design a new modeling language >>>> instead of reusing e.g. XSD was because XSD is too complicated, and >>>> then >>>> we get embedded choice ? >>> I think embedded choices were in YANG 1 and hence this is not a new >>> issue specific to YANG 1.1. Please correct me if I am wrong. >>> >>> I am personally fine with embedded choices if the semantics are well >>> defined so that implementations interpret them the same way. Have you >>> tested different tools? >>> >>> /js >>> >>> PS: It is possible to write obfuscated code in almost all languages; I >>> think the question is more whether the regular common use of the >>> language is intuitive. A good language IMHO follows a set of >>> simple general rules; attempts to rule out constructions that some >>> people find obscure can turn a set of simple general rules into a >>> complicated collection of special case constructions that make >>> language maintenance and implementation a nightmare. >>> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 05:32:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A341B404A for ; Tue, 6 Oct 2015 05:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11sD3VdYHBAa for ; Tue, 6 Oct 2015 05:32:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713461B4048 for ; Tue, 6 Oct 2015 05:32:28 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-80-5613bf5a52d1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.89.17026.A5FB3165; Tue, 6 Oct 2015 14:32:26 +0200 (CEST) Received: from [147.214.120.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.248.2; Tue, 6 Oct 2015 14:32:26 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <5613BF5A.7010300@ericsson.com> Date: Tue, 6 Oct 2015 14:32:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+JvjW7UfuEwg2NztS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtv20ywFp1kqPnV+Z21gXM7cxcjBISFgInFyjk0XIyeQKSZx 4d56ti5GLg4hgaOMEru+dLFAOGsYJXae3MkOUiUioC4xcydIFScHm4CRxNT+8ywgtrCAmsT+ 008ZQWxeAW2JU63vwGwWARWJzzufgtWLCsRI9PzawAZRIyhxcuYTsF5mAQuJmfPPM0LY8hLb 385hBrGFBDQkHl74yzqBkW8WkpZZSFpmIWlZwMi8ilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwpA5u+a27g3H1a8dDjAIcjEo8vA8+CYUJsSaWFVfmHmKU5mBREudtYXoQKiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxgVfx4vQDIhOZOH1sorwW/eIozDWO7Gj5cHHxhsLIXTc35f58 Gxg2/9vxBQHGv+8Lz9/678/Ndz1GqYmzp11Qe3t/u+3ayw3b/4mwpi/YEqXucil2CtPe61K7 98ql6U2aO1FvW+HSvuAi/wgXT0NVPZHdvRn+l5Icumbv5rHriZeyiC55/KVViaU4I9FQi7mo OBEApHnUYQoCAAA= Archived-At: Subject: [netmod] unique for non-existing leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 12:32:29 -0000 Hello, How is the list's unique statement evaluated/enforced if some of the leafs specified in the unique statement don't exist in the data tree. list mylist { unique att1; leaf att1 {} } att1 is not mandatory. Can I have two list entries where att1 does not exist? What if when or choice is the reason why the leaf does not exist? Is this described in the RFC? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 6 05:50:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6261A038D for ; Tue, 6 Oct 2015 05:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IEQWyeHEn2C for ; Tue, 6 Oct 2015 05:50:56 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB8E1A0262 for ; Tue, 6 Oct 2015 05:50:55 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id A129AC4175D0; Tue, 6 Oct 2015 14:50:54 +0200 (CEST) To: Balazs Lengyel , "netmod@ietf.org" References: <5613BF5A.7010300@ericsson.com> From: Jernej Tuljak Message-ID: <5613C3AB.1080608@mg-soft.si> Date: Tue, 6 Oct 2015 14:50:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5613BF5A.7010300@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] unique for non-existing leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 12:50:58 -0000 Balazs Lengyel je 6.10.2015 ob 14:32 napisal: > Hello, > How is the list's unique statement evaluated/enforced if some of the > leafs specified in the unique statement don't exist in the data tree. > > list mylist { > unique att1; > leaf att1 {} > } > > att1 is not mandatory. Can I have two list entries where att1 does not > exist? > > What if when or choice is the reason why the leaf does not exist? > > Is this described in the RFC? 7.8.3. The "unique" constraint specifies that the combined values of all the leaf instances specified in the argument string, including leafs with default values, MUST be unique within all list entry instances in which all referenced leafs exist. The constraint is enforced according to the rules in Section 8. Note the "instances in which all referenced leafs exist". Jernej > > regards Balazs > From nobody Tue Oct 6 06:59:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D811ACC91 for ; Tue, 6 Oct 2015 06:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDnWjOdF7UJ1 for ; Tue, 6 Oct 2015 06:59:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD611ACC83 for ; Tue, 6 Oct 2015 06:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24876; q=dns/txt; s=iport; t=1444139972; x=1445349572; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+0bR4UAIDXX2eApGTJdyMrUEc2T0boO+aPm8h4nuGoc=; b=MxqSXP3vfIZ81S6ALJvM7ambDG9vSmmAWYcm0gUmSGpp8ug3zHQ3Rnm+ 4Y+eITE07akrNoRMvWgQBAqbT2S+c1cY0YV/YbZb6lp12vDu4VMVsMSZe kw8SCycu3nRb6hUprX0UvQfJiElW5ZGzwGYt+3pfblcniNXDXs2of8yxX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBABk0xNW/xbLJq1eglqCD8AMhhoCgX4BAQEBAQGBC4QkAQEBBHgBEAsOAwMBAgEJFgEDBAcJAwIBAgEPJQkIBg0GAgEBiBUDEroWDYR2AQEBAQEBAQECAQEBAQEBAQEBAQEXhnODeIEGglCBcjoRB4QuBYdAhnmEFIM3iySBc4FXhzmKFn+DWoNvY4JEgT89M4Z4JYEiAQEB X-IronPort-AV: E=Sophos;i="5.17,644,1437436800"; d="scan'208,217";a="607441551" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 06 Oct 2015 13:59:29 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t96DxTiD002893; Tue, 6 Oct 2015 13:59:29 GMT To: Kent Watsen References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> From: Robert Wilton Message-ID: <5613D3C1.3020903@cisco.com> Date: Tue, 6 Oct 2015 14:59:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109040102010900090206" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 13:59:35 -0000 This is a multi-part message in MIME format. --------------060109040102010900090206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST update the server's intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous system - Client/server interactions that process all configuration requests as synchronous configuration operations (see term). Asynchronous system - Client/server interactions that process all configuration requests as asynchronous configuration operations (see term). Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Thanks, Rob On 06/10/2015 01:52, Kent Watsen wrote: > > Rob, > > Can you take all the comments from this thread to update the proposed > definitions for "synchronous server" and "asynchronous server" terms? > > Thanks, > Kent > > From: Robert Wilton > > Date: Thursday, October 1, 2015 at 5:50 AM > To: Mahesh Jethanandani > > Cc: Kent Watsen >, > "netmod@ietf.org " > > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous > vs asynchronous (esp. wrt intended and applied) > > > > On 01/10/2015 00:55, Mahesh Jethanandani wrote: >> One comment. >> >>> On Sep 30, 2015, at 8:02 AM, Robert Wilton >> > wrote: >>> >>> Hi Kent, >>> >>> Just some quick comments inline ... >>> >>> On 30/09/2015 15:31, Kent Watsen wrote: >>>> [As a contributor] >>>> >>>> >>>> I find that the term "system" is a bit ambiguous in this context. >>>> It is talking about the NMS, the server, or both together? >>>> >>>> [KENT] I believe that we're talking about the >>>> NETCONF/RESTCONF/ server, specifically in how it processes >>>> update requests. >>>> >>>> >>>> Anyway, I've tried to define them relative to the configuration >>>> operations being performed. >>>> >>>> [KENT] Perhaps these could be collapsed if we use the terms >>>> "a/synchronous server" ? >>> >>> Personally, I think that defining the operations is arguably more >>> useful because it is feasible that you could have a server that >>> supports both sync and async operations and allows the client to >>> choose which semantics should be used for a particular request. >>> >>> >>>> >>>> >>>> Synchronous configuration operation - A configuration request that >>>> the server applies synchronously with respect to the client >>>> request. Before the server replies back to the client indicating >>>> the success or failure of the operation it MUST semantically >>>> validate the contents of the request and update the intended >>>> configuration of the target datastore. If the request is to the >>>> running datastore then the configuration change MUST also be >>>> applied in the system before the server replies back to the >>>> client. The reply to the client indicates whether there are any >>>> semantic errors or system errors from applying the configuration >>>> change. >>>> >>>> >>>> [KENT] This generally matches my understanding, but here are some >>>> thoughts to improve it: >>>> >>>> 1. I think the language "semantically validate" would exclude an >>>> ephemeral datastore. We could put a qualifier on it, but I think >>>> it can be removed entirely as each datastore already has its own >>>> semantics around how it processes update requests. >>> >>> My aim here is potentially tied to the definition of intended >>> config, were I am suggesting that the system has to at least have >>> been checked that the request is well formed and any YANG >>> constraints in the data model have been met, before it is accepted >>> as intended config, otherwise it would be rejected. >>> >>> >>>> >>>> 2. I like how you call out the running datastore, but it is >>>> somewhat NETCONF-specific. How about something like "If the >>>> request impacts the intended configuration (see term), then..." >>> >>> Yes your text is better and I agree that we should avoid making the >>> description NETCONF specific at all. >>> >>>> >>>> 3. "applied in the system" seems too open ended, how about this: >>>> "...MUST also be propagated to and processed by the operational >>>> components of the server before..." ??? >>> >>> So my aim here was to tie it back to the definition of "applied >>> configuration", but this could probably be expressed in a more >>> direct way, e.g. perhaps ".... MUST update the applied configuration >>> in the system before the server replies …" >> >> If I understand this correctly, we are still talking about “applied >> configuration” as configuration that has been written to >> datastore/hardware/line card etc. It does not imply that anything has >> come out of it, including whether the configuration is usable. That >> operating configuration (and I just introduced another term) will be >> reflected by derived state. >> >> Is that true? > Yes. > > Rather than operating configuration I would perhaps say the > "observable system behaviour is reflected by derived state". > > E.g. if you were to change the MTU of an interface to a different > value (that was say incompatible with a peer device) then the "applied > configuration" for the MTU leaf would only tell you whether or not > that MTU was actively being used by the system. It wouldn't tell you > that an ISIS session on that interface had gone down due to the MTU > incompatibility. That could only be observed by the changing of the > derived state representing the status of the ISIS session (or an alarm). > > Thanks, > Rob > --------------060109040102010900090206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Kent,

Feeding in the various input, I think that this is the best refinement that I've come up with:

Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request.  The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client.  The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change.

Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request.  The server SHOULD ensure that the request is valid, and MUST update the server's intended configuration (see term) before replying to the client indicating whether the request will be processed.  The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server.  The reply to the client only indicates whether there are any errors in the original request.

Synchronous system -  Client/server interactions that process all configuration requests as synchronous configuration operations (see term).

Asynchronous system - Client/server interactions that process all configuration requests as asynchronous configuration operations (see term).

Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration.

Thanks,
Rob


On 06/10/2015 01:52, Kent Watsen wrote:

Rob,

Can you take all the comments from this thread to update the proposed definitions for "synchronous server" and "asynchronous server" terms?

Thanks,
Kent

From: Robert Wilton <rwilton@cisco.com>
Date: Thursday, October 1, 2015 at 5:50 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)



On 01/10/2015 00:55, Mahesh Jethanandani wrote:
One comment.

On Sep 30, 2015, at 8:02 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
[As a contributor]


I find that the term "system" is a bit ambiguous in this context.  It is talking about the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> server, specifically in how it processes update requests.


Anyway, I've tried to define them relative to the configuration operations being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous server" ?

Personally, I think that defining the operations is arguably more useful because it is feasible that you could have a server that supports both sync and async operations and allows the client to choose which semantics should be used for a particular request.




Synchronous configuration operation - A configuration request that the server applies synchronously with respect to the client request.  Before the server replies back to the client indicating the success or failure of the operation it MUST semantically validate the contents of the request and update the intended configuration of the target datastore.  If the request is to the running datastore then the configuration change MUST also be applied in the system before the server replies back to the client.  The reply to the client indicates whether there are any semantic errors or system errors from applying the configuration change.


[KENT]  This generally matches my understanding, but here are some thoughts to improve it:

1. I think the language "semantically validate" would exclude an ephemeral datastore.  We could put a qualifier on it, but I think it can be removed entirely as each datastore already has its own semantics around how it processes update requests.

My aim here is potentially tied to the definition of intended config, were I am suggesting that the system has to at least have been checked that the request is well formed and any YANG constraints in the data model have been met, before it is accepted as intended config, otherwise it would be rejected.



2. I like how you call out the running datastore, but it is somewhat NETCONF-specific.  How about something like "If the request impacts the intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the description NETCONF specific at all.


3. "applied in the system" seems too open ended, how about this:  "...MUST also be propagated to and processed by the operational components of the server before..." ???

So my aim here was to tie it back to the definition of "applied configuration", but this could probably be expressed in a more direct way, e.g. perhaps ".... MUST update the applied configuration in the system before the server replies …"

If I understand this correctly, we are still talking about “applied configuration” as configuration that has been written to datastore/hardware/line card etc. It does not imply that anything has come out of it, including whether the configuration is usable. That operating configuration (and I just introduced another term) will be reflected by derived state.

Is that true?
Yes.

Rather than operating configuration I would perhaps say the "observable system behaviour is reflected by derived state".

E.g. if you were to change the MTU of an interface to a different value (that was say incompatible with a peer device) then the "applied configuration" for the MTU leaf would only tell you whether or not that MTU was actively being used by the system.   It wouldn't tell you that an ISIS session on that interface had gone down due to the MTU incompatibility.  That could only be observed by the changing of the derived state representing the status of the ISIS session (or an alarm).

Thanks,
Rob

--------------060109040102010900090206-- From nobody Tue Oct 6 09:01:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F023C1ACD46 for ; Tue, 6 Oct 2015 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzk0jEZjI9gE for ; Tue, 6 Oct 2015 09:01:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1E11A92EC for ; Tue, 6 Oct 2015 09:01:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 15A128DF; Tue, 6 Oct 2015 18:01:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jsF8Mw2qnJXn; Tue, 6 Oct 2015 18:01:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Oct 2015 18:01:43 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EB1320053; Tue, 6 Oct 2015 18:01:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cBTyge4N0NwZ; Tue, 6 Oct 2015 18:01:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDB462004E; Tue, 6 Oct 2015 18:01:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8574B37AC987; Tue, 6 Oct 2015 18:01:38 +0200 (CEST) Date: Tue, 6 Oct 2015 18:01:38 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151006160138.GA50204@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , Randy Presuhn , "netmod@ietf.org" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> <56139683.9010909@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <56139683.9010909@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 16:01:48 -0000 On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote: > Hi Kent, > > On 06/10/2015 01:40, Kent Watsen wrote: > > > >This issue appears to have become more like issue #5 – should we mark > >this one a duplicate of the other? > > I suggest that we can just finalize on the text being discussed to > replace 1.D and then resolve issue #1. > > Jason had proposed this text: > > When the configuration change for any intended configuration node has > been successfully applied to the system (e.g. not failed, nor deferred > due to absent hardware) then the existence and value of the applied > equivalent of the node (whether that be a corresponding node in the data > model, an attribute associated with the intended config node, the > configuration node read from a different datastore or context, etc) must > match the intended configuration node. I have no clue what "an attribute associated with the intended config node" or "the configuration node read from a different datastore or context" or "etc". means. What exactly is an "applied equivalent of the node"? > Or perhaps this slightly briefer alternative is better?: > > D. When the configuration change for any intended > configuration node has been successfully applied to the > system (e.g. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding, possibly > notional, applied configuration node must match the intended > configuration node. What is the purpose of the phrase "possibly notional"? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 6 09:16:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159FC1ACD6F for ; Tue, 6 Oct 2015 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fh46iMsxS1s for ; Tue, 6 Oct 2015 09:16:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB801A914F for ; Tue, 6 Oct 2015 09:16:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EB033102C; Tue, 6 Oct 2015 18:16:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yYZ06Dfbuota; Tue, 6 Oct 2015 18:16:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Oct 2015 18:16:40 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A25A120067; Tue, 6 Oct 2015 18:16:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cCZo1lFS04ZT; Tue, 6 Oct 2015 18:16:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BA9920055; Tue, 6 Oct 2015 18:16:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A8AEB37AC9DC; Tue, 6 Oct 2015 18:16:37 +0200 (CEST) Date: Tue, 6 Oct 2015 18:16:36 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151006161634.GB50204@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5613D3C1.3020903@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 16:16:45 -0000 On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: > Hi Kent, > > Feeding in the various input, I think that this is the best refinement > that I've come up with: > > Synchronous configuration operation - A configuration request to update > the running configuration of a server that is applied synchronously with > respect to the client request. The server SHOULD ensure that the > request is valid, and MUST fully effect the configuration change to all > impacted components in the server, updating both the server's intended > and applied configuration (see terms), before replying to the client. > The reply to the client indicates whether there are any errors in the > request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? > Asynchronous configuration operation - A configuration request to update > the running configuration of a server that is applied asynchronously > with respect to the client request. The server SHOULD ensure that the > request is valid, and MUST update the server's intended configuration > (see term) before replying to the client indicating whether the request > will be processed. The server's applied configuration state (see term) > is updated after the configuration change has been fully effected to all > impacted components in the server. The reply to the client only > indicates whether there are any errors in the original request. > Synchronous system - Client/server interactions that process all > configuration requests as synchronous configuration operations (see term). I think "synchronous system" is misleading, perhaps "synchronous configuration server". The definitions talk about how a server processes requests, they are silent about clients: Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. > Asynchronous system - Client/server interactions that process all > configuration requests as asynchronous configuration operations (see term). Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. > Any further comments? > > Based on the feedback from Andy and others, it seems that the prevailing > view is that existing NETCONF and RESTCONF should be regarded as being > asynchronous in their behaviour in that the config nodes in the running > datastore only represent the intended configuration and not the applied > configuration. Depends on the definition of applied configuration - where is the latest version of it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 6 10:02:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A671ACEF2 for ; Tue, 6 Oct 2015 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmGyfsuJ9v6L for ; Tue, 6 Oct 2015 10:01:56 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 1A07A1ACEE8 for ; Tue, 6 Oct 2015 10:01:55 -0700 (PDT) Received: by labzv5 with SMTP id zv5so148351124lab.1 for ; Tue, 06 Oct 2015 10:01:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eOAcMfFYPUQDez9/Kdj87T6yEL6nMZNZvAAOZ8YkJU8=; b=nA7PVOKvNbIzTnuX5sMBFBn2OKJ1EVp67eTrKhc3/+rYrSJStldJtQ+qIdtX55dURJ bXBUiSTdxxGVok3bdA5pFZyfiLtgvaqNkq2YH1Vle/RgjiNhXPV2TgwxfISzr4jUT1Ki WODBEmlEVAPwAg1fP71eWk9ba7cYl8AQGTZ6oIjWloYHCXmJsVpQxG9S84LqrQrxH2sa bPO2S29lqeVeNvdCzwDy1jSJYigdrlPWcZXZJSl/NQE3kGuptGh7ZTfPHdSKFHWeZw3h vFTXStwkUpDjsFwJ+pacZuSgjaOQmsfZYT1+/a5qiyxGRochi1bWgtB3gfWHsuVKNbCG 9kDw== X-Gm-Message-State: ALoCoQndSUCRgzl5iwDYkEZwk1D1iMx+hYqEwa88KOtYDxsaikBFjfoA9w4tw/UtMXs9EtOeLps4 MIME-Version: 1.0 X-Received: by 10.112.13.36 with SMTP id e4mr2153124lbc.33.1444150913214; Tue, 06 Oct 2015 10:01:53 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 6 Oct 2015 10:01:53 -0700 (PDT) In-Reply-To: <20151006161634.GB50204@elstar.local> References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> Date: Tue, 6 Oct 2015 10:01:53 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Robert Wilton , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3efc82f4c00052172969a Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 17:02:00 -0000 --001a11c3efc82f4c00052172969a Content-Type: text/plain; charset=UTF-8 On Tue, Oct 6, 2015 at 9:16 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: > > Hi Kent, > > > > Feeding in the various input, I think that this is the best refinement > > that I've come up with: > > > > Synchronous configuration operation - A configuration request to update > > the running configuration of a server that is applied synchronously with > > respect to the client request. The server SHOULD ensure that the > > request is valid, and MUST fully effect the configuration change to all > > impacted components in the server, updating both the server's intended > > and applied configuration (see terms), before replying to the client. > > The reply to the client indicates whether there are any errors in the > > request or errors from applying the configuration change. > > What does "SHOULD ensure that the request is valid" mean? RFC 6020 > says: > > When datastore processing is complete, the final contents MUST obey > all validation constraints. This validation processing is performed > at differing times according to the datastore. If the datastore is > or , these constraints MUST be enforced at the > end of the or operation. If the > datastore is , the constraint enforcement is delayed > until a or operation. > > Are we talking about datastore validation or validation of a request? > If the former, are we watering down a MUST to a SHOULD? > > > Asynchronous configuration operation - A configuration request to update > > the running configuration of a server that is applied asynchronously > > with respect to the client request. The server SHOULD ensure that the > > request is valid, and MUST update the server's intended configuration > > (see term) before replying to the client indicating whether the request > > will be processed. The server's applied configuration state (see term) > > is updated after the configuration change has been fully effected to all > > impacted components in the server. The reply to the client only > > indicates whether there are any errors in the original request. > > > Synchronous system - Client/server interactions that process all > > configuration requests as synchronous configuration operations (see > term). > > I think "synchronous system" is misleading, perhaps "synchronous > configuration server". The definitions talk about how a server > processes requests, they are silent about clients: > > Synchronous configuration server - a configuration server that > processes all configuration operations as synchronous configuration > operations. > > > Asynchronous system - Client/server interactions that process all > > configuration requests as asynchronous configuration operations (see > term). > > Asynchronous configuration server - a configuration server that > processes all configuration operations as asynchronous configuration > operations. > > And I would not be surprised if we also need this sooner or later: > > Mixed configuration server - a configuration server that processes > some configuration operations as synchronous configuration > operations and some configuration operations as asynchronous > configuration operations. > > As I already commented, this is how servers works today. The data model details, server design, sub-system design, ASIC design, etc. can all factor into whether or not the config is applied when is returned for the edit or commit. It is also unwise to assume that the server can determine the applied state for every possible leaf. > > Any further comments? > > > > Based on the feedback from Andy and others, it seems that the prevailing > > view is that existing NETCONF and RESTCONF should be regarded as being > > asynchronous in their behaviour in that the config nodes in the running > > datastore only represent the intended configuration and not the applied > > configuration. > > Depends on the definition of applied configuration - where is the latest > version of it? > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c3efc82f4c00052172969a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 6, 2015 at 9:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilt= on wrote:
> Hi Kent,
>
> Feeding in the various input, I think that this is the best refinement=
> that I've come up with:
>
> Synchronous configuration operation - A configuration request to updat= e
> the running configuration of a server that is applied synchronously wi= th
> respect to the client request.=C2=A0 The server SHOULD ensure that the=
> request is valid, and MUST fully effect the configuration change to al= l
> impacted components in the server, updating both the server's inte= nded
> and applied configuration (see terms), before replying to the client.<= br> > The reply to the client indicates whether there are any errors in the<= br> > request or errors from applying the configuration change.

What does "SHOULD ensure that the request is valid" mean? RFC 602= 0
says:

=C2=A0 =C2=A0When datastore processing is complete, the final contents MUST= obey
=C2=A0 =C2=A0all validation constraints.=C2=A0 This validation processing i= s performed
=C2=A0 =C2=A0at differing times according to the datastore.=C2=A0 If the da= tastore is
=C2=A0 =C2=A0<running/> or <startup/>, these constraints MUST b= e enforced at the
=C2=A0 =C2=A0end of the <edit-config> or <copy-config> operatio= n.=C2=A0 If the
=C2=A0 =C2=A0datastore is <candidate/>, the constraint enforcement is= delayed
=C2=A0 =C2=A0until a <commit> or <validate> operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?

> Asynchronous configuration operation - A configuration request to upda= te
> the running configuration of a server that is applied asynchronously > with respect to the client request.=C2=A0 The server SHOULD ensure tha= t the
> request is valid, and MUST update the server's intended configurat= ion
> (see term) before replying to the client indicating whether the reques= t
> will be processed.=C2=A0 The server's applied configuration state = (see term)
> is updated after the configuration change has been fully effected to a= ll
> impacted components in the server.=C2=A0 The reply to the client only<= br> > indicates whether there are any errors in the original request.

> Synchronous system -=C2=A0 Client/server interactions that process all=
> configuration requests as synchronous configuration operations (see te= rm).

I think "synchronous system" is misleading, perhaps "synchro= nous
configuration server". The definitions talk about how a server
processes requests, they are silent about clients:

=C2=A0 Synchronous configuration server - a configuration server that
=C2=A0 processes all configuration operations as synchronous configuration<= br> =C2=A0 operations.

> Asynchronous system - Client/server interactions that process all
> configuration requests as asynchronous configuration operations (see t= erm).

=C2=A0 Asynchronous configuration server - a configuration server that
=C2=A0 processes all configuration operations as asynchronous configuration=
=C2=A0 operations.

And I would not be surprised if we also need this sooner or later:

=C2=A0 Mixed configuration server - a configuration server that processes =C2=A0 some configuration operations as synchronous configuration
=C2=A0 operations and some configuration operations as asynchronous
=C2=A0 configuration operations.


As I already commented, this is how se= rvers works today.
The data model details, server design, sub-sys= tem design, ASIC design, etc.
can all factor into whether or not = the config is applied
when <ok/> is returned for the edit o= r commit.

It is also unwise to assume that the ser= ver can determine the applied
state for every possible leaf.


=C2=A0
> Any further comments?
>
> Based on the feedback from Andy and others, it seems that the prevaili= ng
> view is that existing NETCONF and RESTCONF should be regarded as being=
> asynchronous in their behaviour in that the config nodes in the runnin= g
> datastore only represent the intended configuration and not the applie= d
> configuration.

Depends on the definition of applied configuration - where is the latest version of it?

/js



Andy

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

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

--001a11c3efc82f4c00052172969a-- From nobody Tue Oct 6 11:08:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A811A6F22 for ; Tue, 6 Oct 2015 11:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQDY-F3SkHxv for ; Tue, 6 Oct 2015 11:08:43 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC31AD2F6 for ; Tue, 6 Oct 2015 11:04:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=c6bNosz+7MyNiXr1iuH9Z0SKTdeAd1P0d1PJgWx50U2Xsd0GkV1RMw28umrqgJLi; 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.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZjWb7-0005t0-VV for netmod@ietf.org; Tue, 06 Oct 2015 14:04:21 -0400 Received: from 76.254.50.246 by webmail.earthlink.net with HTTP; Tue, 6 Oct 2015 14:04:21 -0400 Message-ID: <13584075.1444154661881.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Tue, 6 Oct 2015 11:04:21 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edea2c1705b9f178754989372d79834843350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 18:08:45 -0000 Hi - > From: Andy Bierman > Sent: Oct 6, 2015 10:01 AM > To: Juergen Schoenwaelder , Robert Wilton , Kent Watsen , "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) ... > > And I would not be surprised if we also need this sooner or later: > > > > Mixed configuration server - a configuration server that processes > > some configuration operations as synchronous configuration > > operations and some configuration operations as asynchronous > > configuration operations. > > As I already commented, this is how servers works today. > The data model details, server design, sub-system design, > ASIC design, etc.can all factor into whether or not the > config is applied when is returned for the edit or > commit. Agreed. Realistically, the semantic of is merely that the data has passed whatever checks the server applies and has been successfully committed to the appropriate data store. (If the system is built around a model of eventual consistency, even that might be a bit dicey.) It's risky to assume anything more than that in situations involving anything like subagent / extensibility technologies, and positively foolhardy if proxy or translation middleware is in the picture. > It is also unwise to assume that the server can determine > the applied state for every possible leaf. Yes, but even when it *can*, is it worth modeling? I think this discussion needs to be grounded in what is operationally significant. For example, in one system I'm familiar with a configuration change would be validated, committed to storage, the hardware reconfiguration sequence queued for execution, and acknowledged. The hardware reconfiguration involved reprogramming FPGAs, so there'd be a race condition between acknowledgement of the request and when the hardware would actually start doing whatever was requested. That delay was, at most, milliseconds. - Did the server know this was happening? Of course. - Would it have been possible to expose this "asynchronous" state transition via a management interface. Sure. - Would that be worthwhile to model or implement? I don't think so. Randy From nobody Tue Oct 6 13:00:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9C21B3240 for ; Tue, 6 Oct 2015 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsiDJYUrce7T for ; Tue, 6 Oct 2015 13:00:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CC01AD376 for ; Tue, 6 Oct 2015 13:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2194; q=dns/txt; s=iport; t=1444161633; x=1445371233; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=L4MdWQCyj93tzYt1yU8XmnnTaT+Qy9t3LuCs/aPtdPs=; b=lnkfRhviUQel7Zzg7mR4nvegeM7BCXMM/0OOd8c1vpaCh5li0gOjgjVQ B9C77kzUKSVM6qEO0PdF/OwjEnjFRpjhUoy1ddj7HFWGFvkbioTxI2GN2 Oo1guwih2vKxB4Wb3XtJI+AJr0+1+krIHbnx3Ztf/v9kDwxewrc5H4QOq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAQBbJxRW/xbLJq1eww8BDYFag0SCVgKBdRQBAQEBAQEBgQqEJQEBBA4VDwEFLRMRCw4KAgIFFgsCAgkDAgECAUUGAQwIAQEXiBOsHJQ1AQEBAQEBAQMBAQEBAQEcgSKFUYR+hRSCaYFFAQSHNYcEh0uNF4FXhzkjkjsfAQFCgkSBPz2IcQEBAQ X-IronPort-AV: E=Sophos;i="5.17,645,1437436800"; d="scan'208";a="630164875" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 06 Oct 2015 20:00:31 +0000 Received: from [10.61.98.162] (dhcp-10-61-98-162.cisco.com [10.61.98.162]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t96K0VBV026661; Tue, 6 Oct 2015 20:00:31 GMT To: Kent Watsen , Randy Presuhn , "netmod@ietf.org" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> <56139683.9010909@cisco.com> <20151006160138.GA50204@elstar.local> From: Robert Wilton Message-ID: <5614285E.8060305@cisco.com> Date: Tue, 6 Oct 2015 21:00:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006160138.GA50204@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 20:00:35 -0000 Hi Juergen, On 06/10/2015 17:01, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote: >> Hi Kent, >> >> On 06/10/2015 01:40, Kent Watsen wrote: >>> This issue appears to have become more like issue #5 – should we mark >>> this one a duplicate of the other? >> I suggest that we can just finalize on the text being discussed to >> replace 1.D and then resolve issue #1. >> >> Jason had proposed this text: >> >> When the configuration change for any intended configuration node has >> been successfully applied to the system (e.g. not failed, nor deferred >> due to absent hardware) then the existence and value of the applied >> equivalent of the node (whether that be a corresponding node in the data >> model, an attribute associated with the intended config node, the >> configuration node read from a different datastore or context, etc) must >> match the intended configuration node. > I have no clue what "an attribute associated with the intended config > node" or "the configuration node read from a different datastore or > context" or "etc". means. What exactly is an "applied equivalent of > the node"? > >> Or perhaps this slightly briefer alternative is better?: >> >> D. When the configuration change for any intended >> configuration node has been successfully applied to the >> system (e.g. not failed, nor deferred due to absent hardware) >> then the existence and value of the corresponding, possibly >> notional, applied configuration node must match the intended >> configuration node. > What is the purpose of the phrase "possibly notional"? There was a concern that my previous text, i.e. as above but without "possibly notional", implied that applied configuration had to be actually represented as real data nodes in a YANG schema, which would disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and draft-wilton-netmod-intf-ext-yang-00. On balance, my preference is to exclude the "possibly notional" phrase if the text is sufficiently clear without it. Thanks, Rob > > /js > From nobody Tue Oct 6 13:42:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1D1B3307 for ; Tue, 6 Oct 2015 13:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YXrkan-Nqgk for ; Tue, 6 Oct 2015 13:42:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5221B3305 for ; Tue, 6 Oct 2015 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5786; q=dns/txt; s=iport; t=1444164159; x=1445373759; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=z+LotB82r+vHiD7e7uC3qP5sV2f9X60h5V5HJ3WuZLo=; b=FPcjO4mmVbTTF3K2vrM80mSB5DSoOgAtqTTusU8czUK++e/FOEgdiHhJ bcJIdA5GYlWB/fmLaUI3G8Beb5So7GgvkGVfJXW+v4RLTCtp5v+R/QEWi tGyXbQKFGPfodKUOWwrHMDVM1F3K7opMbvKQ1aSHIuYspvU0WynctmUtF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CcBABtMRRW/xbLJq1exHeDRIJWAoIJAQEBAQEBgQuEJAEBAQMBOEARCw4KCRYECwkDAgECAUUGAQwIAQGIIgjAVwEBAQEBAQEDAQEBAQEBHIZzhH6EQlKELgEElgSNF4FXhzmKFohIY4JEgT89hyolgSIBAQE X-IronPort-AV: E=Sophos;i="5.17,645,1437436800"; d="scan'208";a="607446791" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 06 Oct 2015 20:42:37 +0000 Received: from [10.61.98.162] (dhcp-10-61-98-162.cisco.com [10.61.98.162]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t96KgbWo026763; Tue, 6 Oct 2015 20:42:37 GMT To: Kent Watsen , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> From: Robert Wilton Message-ID: <5614323D.5000507@cisco.com> Date: Tue, 6 Oct 2015 21:42:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006161634.GB50204@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 20:42:43 -0000 Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: >> Hi Kent, >> >> Feeding in the various input, I think that this is the best refinement >> that I've come up with: >> >> Synchronous configuration operation - A configuration request to update >> the running configuration of a server that is applied synchronously with >> respect to the client request. The server SHOULD ensure that the >> request is valid, and MUST fully effect the configuration change to all >> impacted components in the server, updating both the server's intended >> and applied configuration (see terms), before replying to the client. >> The reply to the client indicates whether there are any errors in the >> request or errors from applying the configuration change. > What does "SHOULD ensure that the request is valid" mean? RFC 6020 > says: > > When datastore processing is complete, the final contents MUST obey > all validation constraints. This validation processing is performed > at differing times according to the datastore. If the datastore is > or , these constraints MUST be enforced at the > end of the or operation. If the > datastore is , the constraint enforcement is delayed > until a or operation. > > Are we talking about datastore validation or validation of a request? > If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... > >> Asynchronous configuration operation - A configuration request to update >> the running configuration of a server that is applied asynchronously >> with respect to the client request. The server SHOULD ensure that the >> request is valid, and MUST update the server's intended configuration >> (see term) before replying to the client indicating whether the request >> will be processed. The server's applied configuration state (see term) >> is updated after the configuration change has been fully effected to all >> impacted components in the server. The reply to the client only >> indicates whether there are any errors in the original request. >> Synchronous system - Client/server interactions that process all >> configuration requests as synchronous configuration operations (see term). > I think "synchronous system" is misleading, perhaps "synchronous > configuration server". The definitions talk about how a server > processes requests, they are silent about clients: I agree. Some of the requirement text would probably need to be tweaked to accommodate this. > > Synchronous configuration server - a configuration server that > processes all configuration operations as synchronous configuration > operations. > >> Asynchronous system - Client/server interactions that process all >> configuration requests as asynchronous configuration operations (see term). > Asynchronous configuration server - a configuration server that > processes all configuration operations as asynchronous configuration > operations. > > And I would not be surprised if we also need this sooner or later: > > Mixed configuration server - a configuration server that processes > some configuration operations as synchronous configuration > operations and some configuration operations as asynchronous > configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. > >> Any further comments? >> >> Based on the feedback from Andy and others, it seems that the prevailing >> view is that existing NETCONF and RESTCONF should be regarded as being >> asynchronous in their behaviour in that the config nodes in the running >> datastore only represent the intended configuration and not the applied >> configuration. > Depends on the definition of applied configuration - where is the latest > version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? Thanks, Rob > > /js > From nobody Tue Oct 6 13:54:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2F1B331E for ; Tue, 6 Oct 2015 13:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0w6vJjSqPln for ; Tue, 6 Oct 2015 13:54:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA3F1B3308 for ; Tue, 6 Oct 2015 13:54:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E507AACA; Tue, 6 Oct 2015 22:54:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A4g8s0V4Ygvo; Tue, 6 Oct 2015 22:54:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Oct 2015 22:54:10 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A668420053; Tue, 6 Oct 2015 22:54:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g8Ldt3HCvzA1; Tue, 6 Oct 2015 22:54:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF7A22004E; Tue, 6 Oct 2015 22:54:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1DF2437ACCF8; Tue, 6 Oct 2015 22:54:07 +0200 (CEST) Date: Tue, 6 Oct 2015 22:54:07 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151006205407.GA50666@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , Randy Presuhn , "netmod@ietf.org" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> <56139683.9010909@cisco.com> <20151006160138.GA50204@elstar.local> <5614285E.8060305@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <5614285E.8060305@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 20:54:15 -0000 On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote: > Hi Juergen, > > On 06/10/2015 17:01, Juergen Schoenwaelder wrote: > >On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote: > >>Hi Kent, > >> > >>On 06/10/2015 01:40, Kent Watsen wrote: > >>>This issue appears to have become more like issue #5 – should we mark > >>>this one a duplicate of the other? > >>I suggest that we can just finalize on the text being discussed to > >>replace 1.D and then resolve issue #1. > >> > >>Jason had proposed this text: > >> > >>When the configuration change for any intended configuration node has > >>been successfully applied to the system (e.g. not failed, nor deferred > >>due to absent hardware) then the existence and value of the applied > >>equivalent of the node (whether that be a corresponding node in the data > >>model, an attribute associated with the intended config node, the > >>configuration node read from a different datastore or context, etc) must > >>match the intended configuration node. > >I have no clue what "an attribute associated with the intended config > >node" or "the configuration node read from a different datastore or > >context" or "etc". means. What exactly is an "applied equivalent of > >the node"? > > > >>Or perhaps this slightly briefer alternative is better?: > >> > >> D. When the configuration change for any intended > >> configuration node has been successfully applied to the > >> system (e.g. not failed, nor deferred due to absent hardware) > >> then the existence and value of the corresponding, possibly > >> notional, applied configuration node must match the intended > >> configuration node. > >What is the purpose of the phrase "possibly notional"? > There was a concern that my previous text, i.e. as above but without > "possibly notional", implied that applied configuration had to be > actually represented as real data nodes in a YANG schema, which would > disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and > draft-wilton-netmod-intf-ext-yang-00. > > On balance, my preference is to exclude the "possibly notional" phrase > if the text is sufficiently clear without it. My understanding is that draft-kwatsen-netmod-opstate-00 proposes to represent applied config as nodes in a different datastore, so there is no need for 'possibly notational'. I do not understand why draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean draft-wilton-netmod-opstate-yang-00? I do have major concerns about this particular proposal since it changes the YANG data encoding fundamentally. There was another proposal to use attributes, which is also not without problems but it is likely a bit less painful. But again, it all depends on the final definition of what applied config really is. So where is the latest version and how far are we with agreeing on it? Yet another way to look at this is to expose not the applied config in addition to the intended config (I have been told configs can be really large) but instead expose lets say a yang patch that says how the applied config differs form the running config. Having to retrieve two large configs just to diff them locally seems to a potentially expensive exercise, in particular if the difference is often small. I think Randy mentioned something like this before and no there is no I-D. But even with this approach, the definition without "possibly notational' would hold; you would just not expose the applied config entirely but instead a patch that allows to calculate it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 6 14:25:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882751B3364 for ; Tue, 6 Oct 2015 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyORJ0xpKZU9 for ; Tue, 6 Oct 2015 14:25:35 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 5D3731A00E3 for ; Tue, 6 Oct 2015 14:25:34 -0700 (PDT) Received: by lacdq7 with SMTP id dq7so9571903lac.2 for ; Tue, 06 Oct 2015 14:25:32 -0700 (PDT) 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=/FbW+OXiZhgdyInRKyEHLKpEn2V1/dZjACViXoJhQ9A=; b=UaB8kYOew+7ecsV0oTGbQSjZIdO7RzJfa5Td9svG/T5LAfbgfCBIqyjk2BOfHJxUyG SzjCZQ0bNsqaOi1CJ2h7nPUQOdczlTOd7NCz/kIMmC+RSHZAdE9giP3n8Wi2TUYukrFe Ur9y4qKbYKmYTSqaeaOJYVR3qhwq6vcERUGrFZIO+P59y+wrJqGbGdkJ80YZPCA+IMMR Y3RGVVltZ0B9X0W5QzwoT/lEwUiRi7vvB71psFLr3IxtiK0SN1BM+1SsjVvroFApSXF6 mPIQ1xbxi46J44kknS5CW3zzHCpe2+FB4xZbMr8djUNl9Ne3oduqgrEvT8j2XzP9zwxz /bPA== X-Gm-Message-State: ALoCoQkj1nx88J8NQLcMmHmCrcgmHXPP0t2NBEIuqFb3qxhCfu0onyvAzILo2gjQ2wKLYlUFXaY5 MIME-Version: 1.0 X-Received: by 10.112.200.229 with SMTP id jv5mr15753319lbc.123.1444166732526; Tue, 06 Oct 2015 14:25:32 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 6 Oct 2015 14:25:32 -0700 (PDT) In-Reply-To: <5614323D.5000507@cisco.com> References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> Date: Tue, 6 Oct 2015 14:25:32 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c2665016d71a0521764564 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 21:25:38 -0000 --001a11c2665016d71a0521764564 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 6, 2015 at 1:42 PM, Robert Wilton wrote: > Hi Juergen, > > On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > >> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: >> >>> Hi Kent, >>> >>> Feeding in the various input, I think that this is the best refinement >>> that I've come up with: >>> >>> Synchronous configuration operation - A configuration request to update >>> the running configuration of a server that is applied synchronously with >>> respect to the client request. The server SHOULD ensure that the >>> request is valid, and MUST fully effect the configuration change to all >>> impacted components in the server, updating both the server's intended >>> and applied configuration (see terms), before replying to the client. >>> The reply to the client indicates whether there are any errors in the >>> request or errors from applying the configuration change. >>> >> What does "SHOULD ensure that the request is valid" mean? RFC 6020 >> says: >> >> When datastore processing is complete, the final contents MUST obey >> all validation constraints. This validation processing is performed >> at differing times according to the datastore. If the datastore is >> or , these constraints MUST be enforced at the >> end of the or operation. If the >> datastore is , the constraint enforcement is delayed >> until a or operation. >> >> Are we talking about datastore validation or validation of a request? >> If the former, are we watering down a MUST to a SHOULD? >> > Really it is datastore validation, particularly for an async request where > the intended config nodes are updated before replying. I'm not > intentionally trying to water down a MUST to a SHOULD, but Kent had > concerns that my previous description using "semantically validate" would > exclude an ephemeral datastore, so I was trying to water down the > description and also describe the behaviour in a way that isn't specific to > either RESTCONF/NETCONF or datastores. > > I have been thinking about I2RS validation, and it there might be good reasons to say SHOULD instead of MUST (wrt/ ephemeral datastore anyway). The server instrumentation can do a better job than the server at deciding how to prune bad config. It may be much faster to have the server do syntax validation but not YANG constraint validation. The instrumentation examines the ephemeral datastore to apply what it can. The rest gets ignored. This may be too sloppy for standards, but I2RS is supposed to be fast. Andy Perhaps, the start of sentence could simply be changed to: > > The server MUST fully effect the configuration change to all > impacted components in the server ... > > > And equivalently for the asynchronous case below: > > The server MUST update the server's intended configuration ... > > > > >> Asynchronous configuration operation - A configuration request to update >>> the running configuration of a server that is applied asynchronously >>> with respect to the client request. The server SHOULD ensure that the >>> request is valid, and MUST update the server's intended configuration >>> (see term) before replying to the client indicating whether the request >>> will be processed. The server's applied configuration state (see term) >>> is updated after the configuration change has been fully effected to all >>> impacted components in the server. The reply to the client only >>> indicates whether there are any errors in the original request. >>> Synchronous system - Client/server interactions that process all >>> configuration requests as synchronous configuration operations (see >>> term). >>> >> I think "synchronous system" is misleading, perhaps "synchronous >> configuration server". The definitions talk about how a server >> processes requests, they are silent about clients: >> > I agree. Some of the requirement text would probably need to be tweaked > to accommodate this. > > >> Synchronous configuration server - a configuration server that >> processes all configuration operations as synchronous configuration >> operations. >> >> Asynchronous system - Client/server interactions that process all >>> configuration requests as asynchronous configuration operations (see >>> term). >>> >> Asynchronous configuration server - a configuration server that >> processes all configuration operations as asynchronous configuration >> operations. >> >> And I would not be surprised if we also need this sooner or later: >> >> Mixed configuration server - a configuration server that processes >> some configuration operations as synchronous configuration >> operations and some configuration operations as asynchronous >> configuration operations. >> > Yes, I would expect that clients may want to define the expected > behaviour, potentially on a per request basis. > > >> Any further comments? >>> >>> Based on the feedback from Andy and others, it seems that the prevailing >>> view is that existing NETCONF and RESTCONF should be regarded as being >>> asynchronous in their behaviour in that the config nodes in the running >>> datastore only represent the intended configuration and not the applied >>> configuration. >>> >> Depends on the definition of applied configuration - where is the latest >> version of it? >> > The last proposed text for intended/applied is as below: > > intended configuration - this data represents the configuration > state that the network operator intends the system to be in, and that > has been accepted by the system as valid configuration. This data is > colloquially referred to as the 'configuration' of the system. > > applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). > > From Thursday's interim meeting, Rob Shakir clarified that the desired > intention is that applied configuration should mean that the configuration > is fully applied everywhere. I don't know if that means that the > definition of applied configuration should be strengthened, or if it is > sufficient? > > Thanks, > Rob > > >> /js >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2665016d71a0521764564 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 6, 2015 at 1:42 PM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best refinement
that I've come up with:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with respect to the client request.=C2=A0 The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to all
impacted components in the server, updating both the server's intended<= br> and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RFC 602= 0
says:

=C2=A0 =C2=A0 When datastore processing is complete, the final contents MUS= T obey
=C2=A0 =C2=A0 all validation constraints.=C2=A0 This validation processing = is performed
=C2=A0 =C2=A0 at differing times according to the datastore.=C2=A0 If the d= atastore is
=C2=A0 =C2=A0 <running/> or <startup/>, these constraints MUST = be enforced at the
=C2=A0 =C2=A0 end of the <edit-config> or <copy-config> operati= on.=C2=A0 If the
=C2=A0 =C2=A0 datastore is <candidate/>, the constraint enforcement i= s delayed
=C2=A0 =C2=A0 until a <commit> or <validate> operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request where = the intended config nodes are updated before replying. I'm not intentio= nally trying to water down a MUST to a SHOULD, but Kent had concerns that m= y previous description using "semantically validate" would exclud= e an ephemeral datastore, so I was trying to water down the description and= also describe the behaviour in a way that isn't specific to either RES= TCONF/NETCONF or datastores.



I have been thinking ab= out I2RS validation, and it there might be good reasons
to say SH= OULD instead of MUST (wrt/ ephemeral datastore anyway).

The server instrumentation can do a better job than the server at
deciding how to prune bad config.=C2=A0 It may be much faster to hav= e the server
do syntax validation but not YANG constraint validat= ion.=C2=A0 The instrumentation
examines the ephemeral datastore t= o apply what it can. The rest gets ignored.
This may be too slopp= y for standards, but I2RS is supposed to be fast.

=
Andy

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...


And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...




Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously
with respect to the client request.=C2=A0 The server SHOULD ensure that the=
request is valid, and MUST update the server's intended configuration (see term) before replying to the client indicating whether the request
will be processed.=C2=A0 The server's applied configuration state (see = term)
is updated after the configuration change has been fully effected to all impacted components in the server.=C2=A0 The reply to the client only
indicates whether there are any errors in the original request.
Synchronous system -=C2=A0 Client/server interactions that process all
configuration requests as synchronous configuration operations (see term).<= br>
I think "synchronous system" is misleading, perhaps "synchro= nous
configuration server". The definitions talk about how a server
processes requests, they are silent about clients:
I agree.=C2=A0 Some of the requirement text would probably need to be tweak= ed to accommodate this.


=C2=A0 =C2=A0Synchronous configuration server - a configuration server that=
=C2=A0 =C2=A0processes all configuration operations as synchronous configur= ation
=C2=A0 =C2=A0operations.

Asynchronous system - Client/server interactions that process all
configuration requests as asynchronous configuration operations (see term).=
=C2=A0 =C2=A0Asynchronous configuration server - a configuration server tha= t
=C2=A0 =C2=A0processes all configuration operations as asynchronous configu= ration
=C2=A0 =C2=A0operations.

And I would not be surprised if we also need this sooner or later:

=C2=A0 =C2=A0Mixed configuration server - a configuration server that proce= sses
=C2=A0 =C2=A0some configuration operations as synchronous configuration
=C2=A0 =C2=A0operations and some configuration operations as asynchronous =C2=A0 =C2=A0configuration operations.
Yes, I would expect that clients may want to define the expected behaviour,= potentially on a per request basis.


Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being
asynchronous in their behaviour in that the config nodes in the running
datastore only represent the intended configuration and not the applied
configuration.
Depends on the definition of applied configuration - where is the latest version of it?
The last proposed text for intended/applied is as below:

=C2=A0 =C2=A0 =C2=A0 intended configuration - this data represents the conf= iguration
=C2=A0 =C2=A0 =C2=A0 state that the network operator intends the system to = be in, and that
=C2=A0 =C2=A0 =C2=A0 has been accepted by the system as valid configuration= .=C2=A0 This data is
=C2=A0 =C2=A0 =C2=A0 colloquially referred to as the 'configuration'= ; of the system.

=C2=A0 =C2=A0 =C2=A0applied configuration - this data represents the config= uration
=C2=A0 =C2=A0 =C2=A0 state that the network element is actually in, i.e., t= he
=C2=A0 =C2=A0 =C2=A0 configuration state which is currently being being use= d by system
=C2=A0 =C2=A0 =C2=A0 components (e.g., control plane daemons, operating sys= tem
=C2=A0 =C2=A0 =C2=A0 kernels, line cards).

>From Thursday's interim meeting, Rob Shakir clarified that the desired = intention is that applied configuration should mean that the configuration = is fully applied everywhere.=C2=A0 I don't know if that means that the = definition of applied configuration should be strengthened, or if it is suf= ficient?

Thanks,
Rob


/js


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

--001a11c2665016d71a0521764564-- From nobody Tue Oct 6 14:50:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791021B33A0 for ; Tue, 6 Oct 2015 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xsNNgCby0R-j for ; Tue, 6 Oct 2015 14:50:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D941B339E for ; Tue, 6 Oct 2015 14:50:29 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 6 Oct 2015 21:50:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 21:50:08 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: presentations at netmod 94 Thread-Index: AQHRAID3ElIN5bzw8kuUkN76v6gHQA== Date: Tue, 6 Oct 2015 21:50:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:ehJGCB8bQ2jifzDoqpBJUNaViAbQuixBXI9Nk4elmLqZJFb7uyIRD8Hrb48RIMOfPYEBUrxdTH2hb/c2+KrVrd1xxyMQ6D+666PJPplJPb97teKwaiyM/T3GzJvGO3WPUxku6vA9cadXWWI/pn2otA==; 24:lFtfoBJNGMEUftwddeZ1jozhaSHj7Yzs5YifdRqkSddcYFmrh0SONfcniH+qW5AWWZwfyHpwRhWUekDrWsU48f1LQq+OmI8DjIxjccb/PV4=; 20:Fie5xofTgwSjp7ZPNaBz5twnJCVR56AH/qxvJFCEa3UwCRELZYZeGku592k2k32biqnmgbBehOuhvd2nuIXydQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(189002)(164054003)(199003)(46102003)(2501003)(106116001)(97736004)(2351001)(5001960100002)(66066001)(92566002)(106356001)(107886002)(99286002)(102836002)(189998001)(81156007)(110136002)(50986999)(450100001)(83506001)(101416001)(229853001)(87936001)(16236675004)(54356999)(2900100001)(86362001)(5002640100001)(4001350100001)(105586002)(11100500001)(5008740100001)(5004730100002)(64706001)(36756003)(40100003)(5007970100001)(122556002)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D239BA4CE50C5kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 21:50:07.7762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: [netmod] presentations at netmod 94 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 21:50:34 -0000 --_000_D239BA4CE50C5kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [co-chair hat on] Hi All, We're beginning to put together the agenda for IETF 94 meetings. This time= we have significantly more time than in recent meetings, and thus can fit = more presentations and/or have longer discussions. If you are interested= in presenting at NETMOD 94, and I have not written you privately already, = please respond to this email (privately, not to list) regarding your reques= t: - name of draft - presenter - how much time desired Thanks, Kent --_000_D239BA4CE50C5kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <876E20C0BAF43F4C91058C9C1774FB2E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

[co-chair hat on]

Hi All,

We're beginning to put together the agenda for IETF 94 meetings.  = ;This time we have significantly more time than in recent meetings, and thu= s can fit more presentations and/or have longer discussions.    I= f you are interested in presenting at NETMOD 94, and I have not written you privately already, please respond to this email= (privately, not to list) regarding your request:

  - name of draft
  - presenter
  - how much time desired

Thanks,
Kent

--_000_D239BA4CE50C5kwatsenjunipernet_-- From nobody Wed Oct 7 06:25:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A421A6FFF; Wed, 7 Oct 2015 06:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkRCiji_il50; Wed, 7 Oct 2015 06:25:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEE21A6F42; Wed, 7 Oct 2015 06:25:36 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007132536.23489.85188.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 06:25:36 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 13:25:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-06.txt Pages : 20 Date : 2015-10-07 Abstract: This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 7 06:32:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E6C1A887C for ; Wed, 7 Oct 2015 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikEb7dtN1k_G for ; Wed, 7 Oct 2015 06:31:45 -0700 (PDT) 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 6D2E61A8825 for ; Wed, 7 Oct 2015 06:31:45 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:6117:a08b:81d3:b135] (unknown [IPv6:2001:718:1a02:1:6117:a08b:81d3:b135]) by mail.nic.cz (Postfix) with ESMTPSA id EFCDC18184B for ; Wed, 7 Oct 2015 15:31:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1444224704; bh=A4vIi2MOxfACX1aLKPq0WaA4fqO1PtZx8WS15IoPxEY=; h=From:Date:To; b=oaD60M65krftuWXa2ZGe2Fkcr6bPmJjWpcpTaONSgy5Hfmwe1AcARpCEo2/fGEVyO pjkaa7cJLcJxw9W93ohe6X1GrvU33bGkYRmofzWBtvunBHyBSAUDX44aJd34xc9QuA HyFvOAVM5ZydZb8yPZuKKQ/aEtsbkttjKeDGtals= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2015 15:31:44 +0200 References: <20151007132536.23489.13312.idtracker@ietfa.amsl.com> To: NETMOD WG Message-Id: <8AD6FA86-4B34-46E0-B5A9-BA10E9DB41D0@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 13:31:47 -0000 Hi, since the WGLC is over, I posted a new revision of this document. = Compared to -05, there are no technical changes, just minor text = modifications and one or two new examples, mainly based on Martin's = review. Lada > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Date: 7 October 2015 at 15:25:36 GMT+2 > To: "Ladislav Lhotka" , "Ladislav Lhotka" = > Subject: New Version Notification for = draft-ietf-netmod-yang-json-06.txt >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-json-06.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-json > Revision: 06 > Title: JSON Encoding of Data Modeled with YANG > Document date: 2015-10-07 > Group: netmod > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-json-06 >=20 > Abstract: > This document defines encoding rules for representing configuration, > state data, RPC operation or action input and output parameters, and > notifications defined using YANG as JavaScript Object Notation = (JSON) > text. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Oct 7 10:37:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4E71A6F9E for ; Wed, 7 Oct 2015 10:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pkUpJcBH6H3T for ; Wed, 7 Oct 2015 10:37:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331D71A6F6F for ; Wed, 7 Oct 2015 10:37:52 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB540.namprd05.prod.outlook.com (10.141.73.27) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 7 Oct 2015 17:37:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 7 Oct 2015 17:37:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) with mapi id 15.01.0293.007; Wed, 7 Oct 2015 17:37:36 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) Thread-Index: AQHRASbaC+/4nTaWn0y+FO1fJ8P2lw== Date: Wed, 7 Oct 2015 17:37:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:p72YG6iJi5ZntGM0ZBoRga3W3axebnK3AE9oos8/sLS1WeIrPh7vNbep/vKDVVwDUEDtWOeBTBXPnGvnA7ljJRcSnqLLBxCsyVhZyBBxU/ZMA3cL/GrabxOxwLpUVHO/YtxdCIfGOYy5/WhWqMEPXQ==; 24:u9o6si0ISSL8dnSOc71Cz6lYAnioXZ6zJf/XfhHYCew7BQ6UKYbqes7qMV0HUOQ83nQi/9B/iMJtsnjCUWB7eBjhTYe7yz9HfxmIRtVXqbw=; 20:5sgIhVqNCT+x4iuw3H5XaA3Xfum/JpTlhlK15HCSAZnmniBHZ+oQPnh6/SPpTY0A31ej6IkPV+eZaH0V7p5kpQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5423002)(189002)(199003)(110136002)(5007970100001)(99286002)(102836002)(36756003)(106116001)(86362001)(107886002)(66066001)(105586002)(87936001)(5008740100001)(189998001)(15975445007)(450100001)(5001960100002)(229853001)(5004730100002)(11100500001)(92566002)(2501003)(64706001)(5002640100001)(106356001)(10400500002)(2900100001)(16236675004)(2351001)(54356999)(81156007)(122556002)(40100003)(19580395003)(4001350100001)(50986999)(230783001)(101416001)(83506001)(97736004)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D23AD09DE5518kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2015 17:37:36.1312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB540; 2:tj6z7D0jT7Q3oaEQT5K8nHKlFq4FHSkuKbEaoo+Db+5RPMDPoNH7VCAeJ8rkDRbktNoFc5spXEdf3spW4mBRN8krK1luqUjJ1d12ySqs1VcQnBiC5FPgBjhJNGAUiHn7OuySnY6fHHZZ5K5Sy+kDyhXBlCQt78lE0s1Gby963B8=; 23:8S8kG2o+eVM0djlb+1lcm70cSOAV4rWZTo1myIxBNpyhdydpCNNeV76bQ+P6UAi4Urheu7+baXsDVexxdLjM1w95VKF9PRih8xKCY2e3nRTVBx59fhqTnLJVEsbNCcohdAXwCuU/4U13BW34puHIRfGPtW5ATV4nP85Wp6l8UYNToEsQKWXUgZQwOXd7xVUq X-OriginatorOrg: juniper.net Archived-At: Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 17:37:56 -0000 --_000_D23AD09DE5518kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a notice to start a NETMOD WG last call for the document: Defining and Using Metadata with YANG http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 Please indicate your support by Thursday October 22, 2015 at 9PM EDT. We are not only interested in receiving defect reports, we are equally interested in statements of the form: * I have reviewed draft-ietf-netmod-yang-metadata-02 and I found no issue= s * I have implemented the data model in draft-ietf-netmod-yang-metadata-02 * I am implementing the data model in draft-ietf-netmod-yang-metadata-02 * I am considering to implement the data model in draft-ietf-netmod-yang-= metadata-02 Of course, these are merely suggestions, folks can provide comments in any form that suits them. This is the second Last Call for this document, the first call being last J= une. Kent // as co-chair --_000_D23AD09DE5518kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <73863ED0A0A9884098B82012251A9781@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

This is a notice to start a NETMOD= WG last call for the document:

Defining and Using Metadata with YANG
http= ://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02

Please indicate your support by Thursday = October 22, 2015 at 9PM EDT.
We are not only interested in receiving d= efect reports, we are equally
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-yang-metadata-02 and I found no = issues
  * I have implemented the data model in draft-ietf-netmod-yang-m= etadata-02
  * I am implementing the data model in draft-ietf-netmod-yang-me= tadata-02
  * I am considering to implement the data model in draft-ietf-ne= tmod-yang-metadata-02

Of course, these are merely suggestions, folks can provide comments in= any
form that suits them.

This is the second Last Call for this doc= ument, the first call being last June.

Kent  // as co-chair

--_000_D23AD09DE5518kwatsenjunipernet_-- From nobody Wed Oct 7 18:31:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FB61B31F1 for ; Wed, 7 Oct 2015 18:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VajeP8WOYkhM for ; Wed, 7 Oct 2015 18:31:48 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE141B31F0 for ; Wed, 7 Oct 2015 18:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444267814; bh=U8tvNy6CVOfwHxRq/14Ve7UkVNjJGU+bLlMEwizcUA8=; h=From:Subject:Date:Cc:To; b=oRSLMx9o4tPccchIJ9utnscnBnvjMq1WCMgLyWh7eZk5zJRTtiGevTYVV5Z00XxSf 0wdO2KbieXrTu4HJMHINEF5gm7IamZzACCxOt8Xa1FhxxzZoSDDGE6kzAJuuxpotgx utzleQUNbYv8ifCKXamFVG/Tf+1nGby/NR4RKIsQ= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: multipart/alternative; boundary="Apple-Mail=_6B2F26B1-26F9-47B5-B353-A82D92D02AE1" Date: Wed, 7 Oct 2015 21:30:13 -0400 Message-Id: <0C07CD94-18A1-4CCE-A8F6-E0C623680DC9@lucidvision.com> To: "netmod@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=18 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 146, in=1808, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@tools.ietf.org Subject: [netmod] IPR Poll for draft-ietf-netmod-yang-metadata-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 01:31:50 -0000 --Apple-Mail=_6B2F26B1-26F9-47B5-B353-A82D92D02AE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETMOD WG: This mail starts the IPR poll on draft-ietf-netmod-yang-metadata-02. Are you aware of any IPR that applies to = draft-ietf-netmod-yang-metadata-02? If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to = this email explicitly regardless of whether or not you are aware of any = relevant IPR. The response needs to be sent to the NETMOD WG mailing list. The = document will not advance to the next stage until a response has been received = from each author and contributor. If you are on the NETMOD WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any = IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Kent and Tom, NETMOD WG Chairs --Apple-Mail=_6B2F26B1-26F9-47B5-B353-A82D92D02AE1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
NETMOD WG:

This mail starts the IPR poll on draft-ietf-netmod-yang-metadata-02.

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

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

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

Thank you,

Kent and Tom, NETMOD WG Chairs


--Apple-Mail=_6B2F26B1-26F9-47B5-B353-A82D92D02AE1-- From nobody Thu Oct 8 04:48:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972A81B32AB; Thu, 8 Oct 2015 04:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdkLmohsP9tv; Thu, 8 Oct 2015 04:48:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081B51A876F; Thu, 8 Oct 2015 04:48:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCG40195; Thu, 08 Oct 2015 11:48:21 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 8 Oct 2015 12:48:18 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.178]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 19:48:07 +0800 From: Yangang To: "netmod@ietf.org" , "netconf@ietf.org" , "Zhangxianping (A)" Thread-Topic: One questions about the RESTCONF. Thread-Index: AQHRAb8yGCsQfAqJY0qmQPPXIMxByg== Date: Thu, 8 Oct 2015 11:48:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] One questions about the RESTCONF. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 11:48:26 -0000 Hi, All: Recently, I try to use RESTCONF to support some functions. But I get one is= sue. Maybe somebody can help me to make it clear. It is about how to use the "augment", there is one example in RFC6020, and = it is clear. But maybe there is a little confused in RESTCONF draft. >From the example in RFC6020, the namespace http://example.com/schema/interf= aces, container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } Then, in namespace http://example.com/schema/ds0, we have: import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType=3D'ds0'"; leaf ds0ChannelNumber { type ChannelNumber; } } A corresponding netconf XML instance example: 1 Flintstone Inc Ethernet A562 ethernetCsmacd 1500 2 Flintstone Inc DS0 ds0 1 About the RESTCONF, my problems are: 1. In the GET operation, how to support it, we have download the GET two ti= mes? To get "http://example.com/schema/interfaces" and "http://example.com/= schema/ds0" separately? Or something I missed to get all information in one= request. 2. In the PUT operation. The question is same, how to set the namespace, ma= y I change the MTU and ChannelNumber together? Maybe I miss some important operation, can somebody provide a example? Thanks Yangang. From nobody Thu Oct 8 09:40:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ACC1A9233 for ; Thu, 8 Oct 2015 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmQa-ZlaVQae for ; Thu, 8 Oct 2015 09:40:34 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 214831A9138 for ; Thu, 8 Oct 2015 09:40:31 -0700 (PDT) Received: by lbwr8 with SMTP id r8so53166912lbw.2 for ; Thu, 08 Oct 2015 09:40:29 -0700 (PDT) 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=4NLIZgGuArIjkh8Ui3PLbxn6NnhZ05v4GVDYpkkYILI=; b=e4nJInaL1O8vkyN88YRGPMN8tgup0XoaN1RpiRCnHFGtK/c7xcXESpTj+TChfGgAYO KgaPF0opoYn3yIcQ9/l905zN2fmnB9b6ME01DXOG+zZI1bIoFmKq0aPIfgPXmknc2IxB SBoidM8jdt/HL5HD8+DK5C2eRjZuuvcvKjuzU8kIy8gNE8akRjdk7gzKMSwBK6c0aNt+ ZRq7SntSKvBrKaE4m8UBiroNYBojs9dIFtJSrx0qvyDRsuIHb/WMIFReAz2rs8a09sAB FrixhDSwKJvb63K+di3vTLOF4alJuLpM+1UX5rh/q7Olo6FWWR19Ab8fL0wUyL2E6Nn1 1owg== X-Gm-Message-State: ALoCoQngrTIcwWSkkYgAE0X0Y1ptaNPRf0k7VFnq1V4LIOjl0hoIkW2jYNRkX2W6VNpwwy+s5/ep MIME-Version: 1.0 X-Received: by 10.25.218.205 with SMTP id r196mr2751107lfg.82.1444322429227; Thu, 08 Oct 2015 09:40:29 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 8 Oct 2015 09:40:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Oct 2015 09:40:29 -0700 Message-ID: From: Andy Bierman To: Yangang Content-Type: multipart/alternative; boundary=001a1140215455eb7805219a8530 Archived-At: Cc: "Zhangxianping \(A\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] One questions about the RESTCONF. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:40:36 -0000 --001a1140215455eb7805219a8530 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 4:48 AM, Yangang wrote: > Hi, All: > > Recently, I try to use RESTCONF to support some functions. But I get one > issue. Maybe somebody can help me to make it clear. > > It is about how to use the "augment", there is one example in RFC6020, and > it is clear. But maybe there is a little confused in RESTCONF draft. > > >From the example in RFC6020, the namespace > http://example.com/schema/interfaces, > > container interfaces { > list ifEntry { > key "ifIndex"; > leaf ifIndex { > type uint32; > } > leaf ifDescr { > type string; > } > leaf ifType { > type iana:IfType; > } > leaf ifMtu { > type int32; > } > } > } > > Then, in namespace http://example.com/schema/ds0, we have: > > import interface-module { > prefix "if"; > } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ds0ChannelNumber { > type ChannelNumber; > } > } > > A corresponding netconf XML instance example: > > > > 1 > Flintstone Inc Ethernet A562 > ethernetCsmacd > 1500 > > > 2 > Flintstone Inc DS0 > ds0 > 1 > > > > About the RESTCONF, my problems are: > > 1. In the GET operation, how to support it, we have download the GET two > times? To get "http://example.com/schema/interfaces" and " > http://example.com/schema/ds0" separately? Or something I missed to get > all information in one request. > > You don't get namespaces, you get subtrees. The "fields" parameter is available to select multiple disjoint subtrees in one request. 2. In the PUT operation. The question is same, how to set the namespace, > may I change the MTU and ChannelNumber together? > > You would use PATCH for that, not PUT. Either YANG Patch or a plain patch on the interface entry would allow multiple descendant nodes to be changed at once. > Maybe I miss some important operation, can somebody provide a example? > > Thanks > Yangang. > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1140215455eb7805219a8530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 8, 2015 at 4:48 AM, Yangang <yangang@huawei.com>= wrote:
Hi, All:

Recently, I try to use RESTCONF to support some functions. But I get one is= sue. Maybe somebody can help me to make it clear.

It is about how to use the "augment", there is one example in RFC= 6020, and it is clear. But maybe there is a little confused in RESTCONF dra= ft.

>From the example in RFC6020, the namespace http://example.co= m/schema/interfaces,

=C2=A0container interfaces {
=C2=A0 =C2=A0 =C2=A0list ifEntry {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "ifIndex";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifIndex {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifDescr {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifType {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type iana:IfType;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifMtu {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }
=C2=A0}

=C2=A0Then, in namespace http://example.com/schema/ds0, we have:
=C2=A0import interface-module {
=C2=A0 =C2=A0 =C2=A0prefix "if";
=C2=A0}

=C2=A0augment "/if:interfaces/if:ifEntry" {
=C2=A0 =C2=A0 =C2=A0when "if:ifType=3D'ds0'";
=C2=A0 =C2=A0 =C2=A0leaf ds0ChannelNumber {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type ChannelNumber;
=C2=A0 =C2=A0 =C2=A0}
=C2=A0}

=C2=A0A corresponding netconf XML instance example:

=C2=A0<interfaces xmlns=3D"http://example.com/schema/int= erfaces" xmlns:ds0=3D"http://example.com/schema/ds0&q= uot;>
=C2=A0 =C2=A0<ifEntry>
=C2=A0 =C2=A0 =C2=A0<ifIndex>1</ifIndex>
=C2=A0 =C2=A0 =C2=A0<ifDescr>Flintstone Inc Ethernet A562</ifDescr= >
=C2=A0 =C2=A0 =C2=A0<ifType>ethernetCsmacd</ifType>
=C2=A0 =C2=A0 =C2=A0<ifMtu>1500</ifMtu>
=C2=A0 =C2=A0</ifEntry>
=C2=A0 =C2=A0<ifEntry>
=C2=A0 =C2=A0 =C2=A0<ifIndex>2</ifIndex>
=C2=A0 =C2=A0 =C2=A0<ifDescr>Flintstone Inc DS0</ifDescr>
=C2=A0 =C2=A0 =C2=A0<ifType>ds0</ifType>
=C2=A0 =C2=A0 =C2=A0<ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber&= gt;
=C2=A0 =C2=A0</ifEntry>
=C2=A0</interfaces>

About the RESTCONF, my problems are:

1. In the GET operation, how to support it, we have download the GET two ti= mes? To get "http://example.com/schema/interfaces"= and "http://example.com/schema/ds0" separately? Or somet= hing I missed to get all information in one request.


You don't get namespaces, you get = subtrees.
The "fields" parameter is available to select= multiple disjoint
subtrees in one request.

<= div>
2. In the PUT operation. The question is same, how to set the namespace, ma= y I change the MTU and ChannelNumber together?


You would use PATCH for that, not PUT.=
Either YANG Patch or a plain patch on the interface entry
<= div>would allow multiple descendant nodes to be changed at once.
=
=C2=A0
Maybe I miss some important operation, can somebody provide a example?

Thanks
Yangang.

Andy
=C2=A0

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

--001a1140215455eb7805219a8530-- From nobody Fri Oct 9 01:13:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E881A8839; Fri, 9 Oct 2015 01:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb2KAWjziAlF; Fri, 9 Oct 2015 01:13:12 -0700 (PDT) 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 C9AD71A8835; Fri, 9 Oct 2015 01:13:10 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1c2:d14c:7ffc:4360] (unknown [IPv6:2001:718:1a02:1:1c2:d14c:7ffc:4360]) by mail.nic.cz (Postfix) with ESMTPSA id E477E181899; Fri, 9 Oct 2015 10:13:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444378388; bh=GMmxRAvTU4m57gPSKSeMb89a/eIPAzzkpwd4ifGhzuA=; h=From:Date:To; b=TwFxGJ/EF8q4apW837kf3wimQtcHVXNM2JkIXFJOxP+qLT1OAxk7jGe/3G448s7ik pT7MyaQDCBFFWaznlDFKQT0RC7H3f8adeGgTcBJeJLIgYknG2xW8CuvsQzLwJZjzDm 3w7RgoADO+xw9faJZ6Vm8YiGBUyel6gvVx0NSTyQ= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> Date: Fri, 9 Oct 2015 10:13:09 +0200 To: i2rs@ietf.org, NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 08:13:13 -0000 Hi, I am sorry for cross-posting but I think it is high time to decide the = relationship between the data models in i2rs-rib-data-model and = netmod-routing-cfg I-Ds because they clearly target the same management = data in a router. I can see three possible scenarios: 1. The i2rs-rib module will be modified to augment = ietf-routing/ietf-ipv[46]-unicast-routing. 2. The scope of ietf-routing will be changed so that it would address = only host routing and simple routers. The modelling work for advanced = routers will be done elsewhere. 3. The work on netmod-routing-cfg will be stopped. Opinions? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 9 02:05:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363031B2C5A; Fri, 9 Oct 2015 02:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUlsT5LwOj_v; Fri, 9 Oct 2015 02:05:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3B21AD151; Fri, 9 Oct 2015 02:04:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCH38783; Fri, 09 Oct 2015 09:04:14 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 9 Oct 2015 10:04:12 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.178]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Fri, 9 Oct 2015 17:04:02 +0800 From: Yangang To: Andy Bierman Thread-Topic: [netmod] One questions about the RESTCONF. Thread-Index: AQHRAb8yGCsQfAqJY0qmQPPXIMxByp5hRnqAgAGXWfA= Date: Fri, 9 Oct 2015 09:04:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.212] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Zhangxianping \(A\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: [netmod] =?utf-8?b?562U5aSNOiAgT25lIHF1ZXN0aW9ucyBhYm91dCB0aGUg?= =?utf-8?q?RESTCONF=2E?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 09:05:06 -0000 --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFuZHk6DQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KSSB3cml0ZSBhbiBSRVNU Q09ORiBzYW1wbGUgY29kZSwgY291bGQgeW91IGNoZWNrIHdoaWNoIG9wdGlvbiBpcyBnb29kLg0K DQpUaGUgbW9kdWxlIGlzIHN0aWxsIHRoYXQgZXhhbXBsZSBvbiB0aGUgbGFzdCBtYWlsLg0KDQpF eGFtcGxlIDENClRoZSBSZXF1ZXN0Og0KR0VUIC9yZXN0Y29uZi9kYXRhL2ludGVyZmFjZS1tb2R1 bGU6aW50ZXJmYWNlcw0KSFRUUC8xLjENCkhvc3Q6IGV4YW1wbGUuY29tDQpBY2NlcHQ6IGFwcGxp Y2F0aW9uL3lhbmcuZGF0YSt4bWwNCg0KRm9yIHRoZSBhYm92ZSByZXF1ZXN0LCB3aGljaCByZXNw b25zZSBpcyBjb3JyZWN0PyBSZXNwb25zZSAxIG9yIFJlc3BvbnNlIDI/DQpSZXNwb25zZSAxDQpI VFRQLzEuMSAyMDAgT0sNCkRhdGU6IE1vbiwgMjMgQXByIDIwMTIgMTc6MDI6NDAgR01UDQpTZXJ2 ZXI6IGV4YW1wbGUtc2VydmVyDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSt4 bWwNCkNhY2hlLUNvbnRyb2w6IG5vLWNhY2hlDQpQcmFnbWE6IG5vLWNhY2hlDQpFVGFnOiBhNzRl ZWZjOTkzYTJiDQpMYXN0LU1vZGlmaWVkOiBNb24sIDIzIEFwciAyMDEyIDExOjAyOjE0IEdNVA0K DQo8aW50ZXJmYWNlcyB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2Vz IiB4bWxuczpkczA9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvZHMwIj4NCiAgIDxpZkVudHJ5 Pg0KICAgICA8aWZJbmRleD4xPC9pZkluZGV4Pg0KICAgICA8aWZEZXNjcj5GbGludHN0b25lIElu YyBFdGhlcm5ldCBBNTYyPC9pZkRlc2NyPg0KICAgICA8aWZUeXBlPmV0aGVybmV0Q3NtYWNkPC9p ZlR5cGU+DQogICAgIDxpZk10dT4xNTAwPC9pZk10dT4NCiAgIDwvaWZFbnRyeT4NCiAgIDxpZkVu dHJ5Pg0KICAgICA8aWZJbmRleD4yPC9pZkluZGV4Pg0KICAgICA8aWZEZXNjcj5GbGludHN0b25l IEluYyBEUzA8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZHMwPC9pZlR5cGU+DQogICAgIDxkczA6 ZHMwQ2hhbm5lbE51bWJlcj4xPC9kczA6ZHMwQ2hhbm5lbE51bWJlcj4NCiAgIDwvaWZFbnRyeT4N CiA8L2ludGVyZmFjZXM+DQoNClJlc3BvbnNlIDINCkhUVFAvMS4xIDIwMCBPSw0KRGF0ZTogTW9u LCAyMyBBcHIgMjAxMiAxNzowMjo0MCBHTVQNClNlcnZlcjogZXhhbXBsZS1zZXJ2ZXINCkNvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KQ2FjaGUtQ29udHJvbDogbm8tY2Fj aGUNClByYWdtYTogbm8tY2FjaGUNCkVUYWc6IGE3NGVlZmM5OTNhMmINCkxhc3QtTW9kaWZpZWQ6 IE1vbiwgMjMgQXByIDIwMTIgMTE6MDI6MTQgR01UDQoNCjxpbnRlcmZhY2VzIHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiPg0KICAgPGlmRW50cnk+DQogICAgIDxp ZkluZGV4PjE8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIEV0aGVybmV0 IEE1NjI8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZXRoZXJuZXRDc21hY2Q8L2lmVHlwZT4NCiAg ICAgPGlmTXR1PjE1MDA8L2lmTXR1Pg0KICAgPC9pZkVudHJ5Pg0KICAgPGlmRW50cnk+DQogICAg IDxpZkluZGV4PjI8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIERTMDwv aWZEZXNjcj4NCiAgICAgPGlmVHlwZT5kczA8L2lmVHlwZT4NCiAgIDwvaWZFbnRyeT4NCiA8L2lu dGVyZmFjZXM+DQoNCg0KRXhhbXBsZSAyDQpJZiB3ZSB3YW50IHRvIGdldCBlbGVtZW50cyBvZiBp ZkVudHJ5KGlmSW5kZXgsIGlmRGVzY3IsIGlmVHlwZSwgaWZNVFUpIGFuZCBhdWdtZW50IGVsZW1l bnQg4oCYZHMwQ2hhbm5lbE51bWJlcuKAmSwgd2hpY2ggUmVxdWVzdCBpcyBjb3JyZWN0PyBSZXF1 ZXN0IDEsUmVxdWVzdCAyIG9yIFJlcXVlc3QgMz8NClJlcXVlc3QgMToNCkdFVCAvcmVzdGNvbmYv ZGF0YS9kczAtbW9kdWxlOmludGVyZmFjZXMNCkhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbQ0K QWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLmRhdGEreG1sDQoNClJlcXVlc3QgMjoNCkdFVCAvcmVz dGNvbmYvZGF0YS9pbnRlcmZhY2VzLW1vZHVsZTppbnRlcmZhY2VzDQpIVFRQLzEuMQ0KSG9zdDog ZXhhbXBsZS5jb20NCkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KDQpSZXF1ZXN0 IDM6DQpHRVQgL3Jlc3Rjb25mL2RhdGE/ZmllbGRzPWludGVyZmFjZXMtbW9kdWxlOmludGVyZmFj ZXM7ZHMwLW1vZHVsZTpkczBDaGFubmVsTnVtYmVyDQpIVFRQLzEuMQ0KSG9zdDogZXhhbXBsZS5j b20NCkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KDQpUaGFua3MNCllhbmdhbmcN Cg0K5Y+R5Lu25Lq6OiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQrl j5HpgIHml7bpl7Q6IDIwMTXlubQxMOaciDnml6UgMDo0MA0K5pS25Lu25Lq6OiBZYW5nYW5nDQrm ioTpgIE6IG5ldG1vZEBpZXRmLm9yZzsgbmV0Y29uZkBpZXRmLm9yZzsgWmhhbmd4aWFucGluZyAo QSkNCuS4u+mimDogUmU6IFtuZXRtb2RdIE9uZSBxdWVzdGlvbnMgYWJvdXQgdGhlIFJFU1RDT05G Lg0KDQoNCg0KT24gVGh1LCBPY3QgOCwgMjAxNSBhdCA0OjQ4IEFNLCBZYW5nYW5nIDx5YW5nYW5n QGh1YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksIEFsbDoN Cg0KUmVjZW50bHksIEkgdHJ5IHRvIHVzZSBSRVNUQ09ORiB0byBzdXBwb3J0IHNvbWUgZnVuY3Rp b25zLiBCdXQgSSBnZXQgb25lIGlzc3VlLiBNYXliZSBzb21lYm9keSBjYW4gaGVscCBtZSB0byBt YWtlIGl0IGNsZWFyLg0KDQpJdCBpcyBhYm91dCBob3cgdG8gdXNlIHRoZSAiYXVnbWVudCIsIHRo ZXJlIGlzIG9uZSBleGFtcGxlIGluIFJGQzYwMjAsIGFuZCBpdCBpcyBjbGVhci4gQnV0IG1heWJl IHRoZXJlIGlzIGEgbGl0dGxlIGNvbmZ1c2VkIGluIFJFU1RDT05GIGRyYWZ0Lg0KDQo+RnJvbSB0 aGUgZXhhbXBsZSBpbiBSRkM2MDIwLCB0aGUgbmFtZXNwYWNlIGh0dHA6Ly9leGFtcGxlLmNvbS9z Y2hlbWEvaW50ZXJmYWNlcywNCg0KIGNvbnRhaW5lciBpbnRlcmZhY2VzIHsNCiAgICAgbGlzdCBp ZkVudHJ5IHsNCiAgICAgICAgIGtleSAiaWZJbmRleCI7DQogICAgICAgICBsZWFmIGlmSW5kZXgg ew0KICAgICAgICAgICAgIHR5cGUgdWludDMyOw0KICAgICAgICAgfQ0KICAgICAgICAgbGVhZiBp ZkRlc2NyIHsNCiAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICAgIH0NCiAgICAgICAg IGxlYWYgaWZUeXBlIHsNCiAgICAgICAgICAgICB0eXBlIGlhbmE6SWZUeXBlOw0KICAgICAgICAg fQ0KICAgICAgICAgbGVhZiBpZk10dSB7DQogICAgICAgICAgICAgdHlwZSBpbnQzMjsNCiAgICAg ICAgIH0NCiAgICB9DQogfQ0KDQogVGhlbiwgaW4gbmFtZXNwYWNlIGh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvZHMwLCB3ZSBoYXZlOg0KDQogaW1wb3J0IGludGVyZmFjZS1tb2R1bGUgew0KICAg ICBwcmVmaXggImlmIjsNCiB9DQoNCiBhdWdtZW50ICIvaWY6aW50ZXJmYWNlcy9pZjppZkVudHJ5 IiB7DQogICAgIHdoZW4gImlmOmlmVHlwZT0nZHMwJyI7DQogICAgIGxlYWYgZHMwQ2hhbm5lbE51 bWJlciB7DQogICAgICAgICB0eXBlIENoYW5uZWxOdW1iZXI7DQogICAgIH0NCiB9DQoNCiBBIGNv cnJlc3BvbmRpbmcgbmV0Y29uZiBYTUwgaW5zdGFuY2UgZXhhbXBsZToNCg0KIDxpbnRlcmZhY2Vz IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiIHhtbG5zOmRzMD0i aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiPg0KICAgPGlmRW50cnk+DQogICAgIDxpZklu ZGV4PjE8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1 NjI8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZXRoZXJuZXRDc21hY2Q8L2lmVHlwZT4NCiAgICAg PGlmTXR1PjE1MDA8L2lmTXR1Pg0KICAgPC9pZkVudHJ5Pg0KICAgPGlmRW50cnk+DQogICAgIDxp ZkluZGV4PjI8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIERTMDwvaWZE ZXNjcj4NCiAgICAgPGlmVHlwZT5kczA8L2lmVHlwZT4NCiAgICAgPGRzMDpkczBDaGFubmVsTnVt YmVyPjE8L2RzMDpkczBDaGFubmVsTnVtYmVyPg0KICAgPC9pZkVudHJ5Pg0KIDwvaW50ZXJmYWNl cz4NCg0KQWJvdXQgdGhlIFJFU1RDT05GLCBteSBwcm9ibGVtcyBhcmU6DQoNCjEuIEluIHRoZSBH RVQgb3BlcmF0aW9uLCBob3cgdG8gc3VwcG9ydCBpdCwgd2UgaGF2ZSBkb3dubG9hZCB0aGUgR0VU IHR3byB0aW1lcz8gVG8gZ2V0ICJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMi IGFuZCAiaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiIHNlcGFyYXRlbHk/IE9yIHNvbWV0 aGluZyBJIG1pc3NlZCB0byBnZXQgYWxsIGluZm9ybWF0aW9uIGluIG9uZSByZXF1ZXN0Lg0KDQpZ b3UgZG9uJ3QgZ2V0IG5hbWVzcGFjZXMsIHlvdSBnZXQgc3VidHJlZXMuDQpUaGUgImZpZWxkcyIg cGFyYW1ldGVyIGlzIGF2YWlsYWJsZSB0byBzZWxlY3QgbXVsdGlwbGUgZGlzam9pbnQNCnN1YnRy ZWVzIGluIG9uZSByZXF1ZXN0Lg0KDQoNCjIuIEluIHRoZSBQVVQgb3BlcmF0aW9uLiBUaGUgcXVl c3Rpb24gaXMgc2FtZSwgaG93IHRvIHNldCB0aGUgbmFtZXNwYWNlLCBtYXkgSSBjaGFuZ2UgdGhl IE1UVSBhbmQgQ2hhbm5lbE51bWJlciB0b2dldGhlcj8NCg0KWW91IHdvdWxkIHVzZSBQQVRDSCBm b3IgdGhhdCwgbm90IFBVVC4NCkVpdGhlciBZQU5HIFBhdGNoIG9yIGEgcGxhaW4gcGF0Y2ggb24g dGhlIGludGVyZmFjZSBlbnRyeQ0Kd291bGQgYWxsb3cgbXVsdGlwbGUgZGVzY2VuZGFudCBub2Rl cyB0byBiZSBjaGFuZ2VkIGF0IG9uY2UuDQoNCg0KTWF5YmUgSSBtaXNzIHNvbWUgaW1wb3J0YW50 IG9wZXJhdGlvbiwgY2FuIHNvbWVib2R5IHByb3ZpZGUgYSBleGFtcGxlPw0KDQpUaGFua3MNCllh bmdhbmcuDQoNCkFuZHkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KDQo= --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpLCBBbmR5OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj5JIHdyaXRlIGFuIFJF U1RDT05GIHNhbXBsZSBjb2RlLCBjb3VsZCB5b3UgY2hlY2sgd2hpY2ggb3B0aW9uIGlzIGdvb2Qu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBtb2R1bGUgaXMg c3RpbGwgdGhhdCBleGFtcGxlIG9uIHRoZSBsYXN0IG1haWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj5F eGFtcGxlIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoZSBSZXF1ZXN0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5H RVQgL3Jlc3Rjb25mL2RhdGEvaW50ZXJmYWNlLW1vZHVsZTppbnRlcmZhY2VzDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SFRU UC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SG9zdDogZXhhbXBsZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWNjZXB0OiBhcHBsaWNhdGlvbi95 YW5nLmRhdGEmIzQzO3htbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcw QzAiPkZvciB0aGUgYWJvdmUgcmVxdWVzdCwgd2hpY2ggcmVzcG9uc2UgaXMgY29ycmVjdD8gUmVz cG9uc2UgMSBvciBSZXNwb25zZSAyPzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlJl c3BvbnNlIDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMSAyMDAgT0s8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+RGF0ZTogTW9uLCAyMyBBcHIgMjAxMiAxNzowMjo0MCBHTVQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VydmVyOiBl eGFtcGxlLXNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Db250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSYj NDM7eG1sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkNhY2hlLUNvbnRyb2w6IG5vLWNhY2hlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlByYWdtYTogbm8tY2Fj aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+RVRhZzogYTc0ZWVmYzk5M2EyYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MYXN0LU1vZGlmaWVkOiBNb24sIDIz IEFwciAyMDEyIDExOjAyOjE0IEdNVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0O2ludGVyZmFjZXMg eG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2Vz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzPC9h PiZxdW90OyB4bWxuczpkczA9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVt YS9kczAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMDwvYT4m cXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0O2lmSW5kZXgmZ3Q7MSZsdDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDtpZkRlc2NyJmd0O0ZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjIm bHQ7L2lmRGVzY3ImZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0 aGVybmV0Q3NtYWNkJmx0Oy9pZlR5cGUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 aWZNdHUmZ3Q7MTUwMCZsdDsvaWZNdHUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRy eSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0O2lmRW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7aWZJbmRleCZndDsyJmx0Oy9pZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRzdG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkczA6ZHMwQ2hhbm5lbE51bWJlciZndDsx Jmx0Oy9kczA6ZHMwQ2hhbm5lbE51bWJlciZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVu dHJ5Jmd0Ozxicj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMDA3MEMwIj5SZXNwb25zZSAyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SFRUUC8xLjEgMjAwIE9LPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhdGU6IE1vbiwgMjMgQXByIDIwMTIgMTc6 MDI6NDAgR01UPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlcnZlcjogZXhhbXBsZS1zZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi95YW5nLmRhdGEmIzQzO3htbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DYWNoZS1Db250cm9sOiBuby1j YWNoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5QcmFnbWE6IG5vLWNhY2hlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkVUYWc6IGE3NGVlZmM5OTNhMmI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+TGFzdC1Nb2RpZmllZDogTW9uLCAyMyBBcHIgMjAxMiAxMTowMjoxNCBHTVQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZsdDtpbnRlcmZhY2VzIHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvaW50ZXJmYWNlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFtcGxl LmNvbS9zY2hlbWEvaW50ZXJmYWNlczwvYT4mcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZs dDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmSW5kZXgmZ3Q7MSZs dDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtpZkRlc2NyJmd0O0Zs aW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjImbHQ7L2lmRGVzY3ImZ3Q7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0aGVybmV0Q3NtYWNkJmx0Oy9pZlR5cGUmZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZNdHUmZ3Q7MTUwMCZsdDsvaWZNdHUmZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRyeSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0O2lm RW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZJbmRleCZndDsyJmx0Oy9p ZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRz dG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVu dHJ5Jmd0Ozxicj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj5FeGFtcGxlIDI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMwMDcwQzAiPklmIHdlIHdhbnQgdG8gZ2V0IGVsZW1lbnRzIG9mIGlmRW50cnkoaWZJbmRl eCwgaWZEZXNjciwgaWZUeXBlLCBpZk1UVSkgYW5kIGF1Z21lbnQgZWxlbWVudA0KPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj7igJg8c3BhbiBsYW5nPSJFTi1VUyI+ZHMwQ2hhbm5l bE51bWJlcjwvc3Bhbj7igJk8c3BhbiBsYW5nPSJFTi1VUyI+LCB3aGljaCBSZXF1ZXN0IGlzIGNv cnJlY3Q/IFJlcXVlc3QgMSxSZXF1ZXN0IDIgb3IgUmVxdWVzdCAzPzxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPlJlcXVlc3QgMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R0VUIC9yZXN0Y29uZi9kYXRhL2Rz MC1tb2R1bGU6aW50ZXJmYWNlcyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3N0OiBleGFtcGxl LmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5BY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSYjNDM7eG1sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+UmVxdWVzdCAyOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HRVQgL3Jl c3Rjb25mL2RhdGEvaW50ZXJmYWNlcy1tb2R1bGU6aW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Ib3N0OiBleGFtcGxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuZGF0 YSYjNDM7eG1sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+UmVxdWVzdCAzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HRVQgL3Jl c3Rjb25mL2RhdGE/ZmllbGRzPWludGVyZmFjZXMtbW9kdWxlOmludGVyZmFjZXM7ZHMwLW1vZHVs ZTpkczBDaGFubmVsTnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhUVFAvMS4xPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvc3Q6IGV4YW1wbGUuY29t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhJiM0Mzt4bWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQ7Y29sb3I6IzFGNDk3RCI+WWFuZ2FuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gQW5keSBCaWVy bWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxh bmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+OTwvc3Bhbj7ml6U8c3Bh biBsYW5nPSJFTi1VUyI+IDA6NDA8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0i RU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gWWFuZ2FuZzxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBuZXRtb2RAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmc7IFpoYW5neGlhbnBpbmcgKEEp PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0bW9kXSBPbmUgcXVlc3Rpb25zIGFib3V0IHRoZSBSRVNU Q09ORi48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBPY3QgOCwgMjAxNSBhdCA0OjQ4 IEFNLCBZYW5nYW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWFuZ2FuZ0BodWF3ZWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+eWFuZ2FuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksIEFsbDo8YnI+DQo8YnI+DQpSZWNlbnRseSwgSSB0 cnkgdG8gdXNlIFJFU1RDT05GIHRvIHN1cHBvcnQgc29tZSBmdW5jdGlvbnMuIEJ1dCBJIGdldCBv bmUgaXNzdWUuIE1heWJlIHNvbWVib2R5IGNhbiBoZWxwIG1lIHRvIG1ha2UgaXQgY2xlYXIuPGJy Pg0KPGJyPg0KSXQgaXMgYWJvdXQgaG93IHRvIHVzZSB0aGUgJnF1b3Q7YXVnbWVudCZxdW90Oywg dGhlcmUgaXMgb25lIGV4YW1wbGUgaW4gUkZDNjAyMCwgYW5kIGl0IGlzIGNsZWFyLiBCdXQgbWF5 YmUgdGhlcmUgaXMgYSBsaXR0bGUgY29uZnVzZWQgaW4gUkVTVENPTkYgZHJhZnQuPGJyPg0KPGJy Pg0KJmd0O0Zyb20gdGhlIGV4YW1wbGUgaW4gUkZDNjAyMCwgdGhlIG5hbWVzcGFjZSA8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvaW50ZXJmYWNlczwvYT4sPGJyPg0KPGJyPg0KJm5i c3A7Y29udGFpbmVyIGludGVyZmFjZXMgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7bGlzdCBp ZkVudHJ5IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2V5ICZxdW90 O2lmSW5kZXgmcXVvdDs7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xl YWYgaWZJbmRleCB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7dHlwZSB1aW50MzI7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO308YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZiBpZkRlc2Ny IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 eXBlIHN0cmluZzs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGlmVHlwZSB7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBpYW5hOklm VHlwZTs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGlmTXR1IHs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGludDMyOzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJy Pg0KJm5ic3A7fTxicj4NCjxicj4NCiZuYnNwO1RoZW4sIGluIG5hbWVzcGFjZSA8YSBocmVmPSJo dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvZHMwPC9hPiwgd2UgaGF2ZTo8YnI+DQo8YnI+DQombmJzcDtpbXBvcnQg aW50ZXJmYWNlLW1vZHVsZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtwcmVmaXggJnF1b3Q7 aWYmcXVvdDs7PGJyPg0KJm5ic3A7fTxicj4NCjxicj4NCiZuYnNwO2F1Z21lbnQgJnF1b3Q7L2lm OmludGVyZmFjZXMvaWY6aWZFbnRyeSZxdW90OyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt3 aGVuICZxdW90O2lmOmlmVHlwZT0nZHMwJyZxdW90Ozs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw O2xlYWYgZHMwQ2hhbm5lbE51bWJlciB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3R5cGUgQ2hhbm5lbE51bWJlcjs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO308YnI+ DQombmJzcDt9PGJyPg0KPGJyPg0KJm5ic3A7QSBjb3JyZXNwb25kaW5nIG5ldGNvbmYgWE1MIGlu c3RhbmNlIGV4YW1wbGU6PGJyPg0KPGJyPg0KJm5ic3A7Jmx0O2ludGVyZmFjZXMgeG1sbnM9JnF1 b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzPC9hPiZxdW90OyB4 bWxuczpkczA9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMDwvYT4mcXVvdDsmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O2lmSW5kZXgmZ3Q7MSZsdDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyZsdDtpZkRlc2NyJmd0O0ZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjImbHQ7L2lmRGVz Y3ImZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0aGVybmV0Q3Nt YWNkJmx0Oy9pZlR5cGUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZNdHUmZ3Q7 MTUwMCZsdDsvaWZNdHUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRyeSZndDs8YnI+ DQombmJzcDsgJm5ic3A7Jmx0O2lmRW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7aWZJbmRleCZndDsyJmx0Oy9pZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRzdG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkczA6ZHMwQ2hhbm5lbE51bWJlciZndDsxJmx0Oy9kczA6 ZHMwQ2hhbm5lbE51bWJlciZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVudHJ5Jmd0Ozxi cj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8YnI+DQo8YnI+DQpBYm91dCB0aGUgUkVTVENP TkYsIG15IHByb2JsZW1zIGFyZTo8YnI+DQo8YnI+DQoxLiBJbiB0aGUgR0VUIG9wZXJhdGlvbiwg aG93IHRvIHN1cHBvcnQgaXQsIHdlIGhhdmUgZG93bmxvYWQgdGhlIEdFVCB0d28gdGltZXM/IFRv IGdldCAmcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXM8L2E+ JnF1b3Q7IGFuZCAmcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvZHMwPC9hPiZxdW90Ow0K IHNlcGFyYXRlbHk/IE9yIHNvbWV0aGluZyBJIG1pc3NlZCB0byBnZXQgYWxsIGluZm9ybWF0aW9u IGluIG9uZSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PllvdSBkb24ndCBnZXQgbmFtZXNwYWNlcywgeW91IGdldCBzdWJ0cmVlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhlICZxdW90O2ZpZWxkcyZxdW90OyBwYXJhbWV0ZXIgaXMgYXZhaWxhYmxlIHRv IHNlbGVjdCBtdWx0aXBsZSBkaXNqb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWJ0cmVlcyBp biBvbmUgcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjIuIEluIHRoZSBQVVQgb3BlcmF0aW9uLiBUaGUgcXVlc3Rpb24gaXMgc2Ft ZSwgaG93IHRvIHNldCB0aGUgbmFtZXNwYWNlLCBtYXkgSSBjaGFuZ2UgdGhlIE1UVSBhbmQgQ2hh bm5lbE51bWJlciB0b2dldGhlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ugd291bGQgdXNlIFBBVENIIGZvciB0aGF0LCBub3QgUFVU LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FaXRoZXIgWUFORyBQYXRjaCBvciBhIHBsYWluIHBhdGNo IG9uIHRoZSBpbnRlcmZhY2UgZW50cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d291bGQgYWxsb3cg bXVsdGlwbGUgZGVzY2VuZGFudCBub2RlcyB0byBiZSBjaGFuZ2VkIGF0IG9uY2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TWF5YmUgSSBtaXNzIHNvbWUgaW1wb3J0YW50IG9wZXJhdGlvbiwg Y2FuIHNvbWVib2R5IHByb3ZpZGUgYSBleGFtcGxlPzxicj4NCjxicj4NClRoYW5rczxicj4NCllh bmdhbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_-- From nobody Fri Oct 9 06:00:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545981B3C52; Fri, 9 Oct 2015 06:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_HJuRfSDkwA; Fri, 9 Oct 2015 06:00:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFB91B3C53; Fri, 9 Oct 2015 06:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1444395610; x=1445605210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wsPHNLel0ZcRRujFOWrgQc+0cBz2v4GyzZk3w9plpwU=; b=O1QoKOj0+FFmwg7Z7PWlXqXwkwb/TL3TnoLpPHRBCjCFaYYJKLDvZod/ lbm1LK3P5OMDLHzHEKpnXxwjnO3A9x3d837yTm5bwDws46k5hWFHHmLMk M0C1OzQYsFgFLle0IumUzyWAXrl1cqoFLpKr58XpVJv3WR0FGnfzJfiDX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AhAgCruRdW/49dJa1egyZUbga9WwENgVoXCoJyggo1SgIcgS04FAEBAQEBAQGBCoQnAQEEAQEBIBE6BAcQAgEIGgImAgICJQsVEAIEAQ0FiC4Nrw6UFwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKT4UNB4JpgUUFlhIBjRmbfx8BAUKEAnGGZIEGAQEB X-IronPort-AV: E=Sophos;i="5.17,657,1437436800"; d="scan'208";a="196326494" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2015 13:00:09 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t99D09fG021502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2015 13:00:09 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 9 Oct 2015 08:00:06 -0500 Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 9 Oct 2015 08:00:06 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 08:00:08 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "i2rs@ietf.org" , "NETMOD WG" Thread-Topic: [netmod] rib-data-model and routing-cfg Thread-Index: AQHRAmpn2WDjXB7SH0yyXI3vdDB1jJ5jMMMA Date: Fri, 9 Oct 2015 13:00:08 +0000 Message-ID: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> In-Reply-To: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.28] Content-Type: text/plain; charset="utf-8" Content-ID: <56B9385C80123946AA490DB40F3FC673@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 13:00:12 -0000 SGkgTGFkYSwgDQpJMlJTIGlzIG5vdCBjaGFydGVyZWQgdG8gZG8gdGhlIGJhc2UgbW9kZWxzLiBU aGVyZSBhcmUgb3RoZXIgcm91dGluZw0KbW9kZWxzIHRoYXQgcmVmZXJlbmNlIHJvdXRpbmctY2Zn IGFuZCBldmVuIGluLXByb2dyZXNzIGltcGxlbWVudGF0aW9ucy4NCg0KT24gMTAvOS8xNSwgNDox MyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KPkhpLA0K Pg0KPkkgYW0gc29ycnkgZm9yIGNyb3NzLXBvc3RpbmcgYnV0IEkgdGhpbmsgaXQgaXMgaGlnaCB0 aW1lIHRvIGRlY2lkZSB0aGUNCj5yZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZGF0YSBtb2RlbHMg aW4gaTJycy1yaWItZGF0YS1tb2RlbCBhbmQNCj5uZXRtb2Qtcm91dGluZy1jZmcgSS1EcyBiZWNh dXNlIHRoZXkgY2xlYXJseSB0YXJnZXQgdGhlIHNhbWUgbWFuYWdlbWVudA0KPmRhdGEgaW4gYSBy b3V0ZXIuIEkgY2FuIHNlZSB0aHJlZSBwb3NzaWJsZSBzY2VuYXJpb3M6DQo+DQo+MS4gVGhlIGky cnMtcmliIG1vZHVsZSB3aWxsIGJlIG1vZGlmaWVkIHRvIGF1Z21lbnQNCj5pZXRmLXJvdXRpbmcv aWV0Zi1pcHZbNDZdLXVuaWNhc3Qtcm91dGluZy4NCg0KVGhpcyB3b3VsZCBzZWVtIHRvIGJlIHRo ZSBvYnZpb3VzIGNob2ljZS4NCg0KPg0KPjIuIFRoZSBzY29wZSBvZiBpZXRmLXJvdXRpbmcgd2ls bCBiZSBjaGFuZ2VkIHNvIHRoYXQgaXQgd291bGQgYWRkcmVzcw0KPm9ubHkgaG9zdCByb3V0aW5n IGFuZCBzaW1wbGUgcm91dGVycy4gVGhlIG1vZGVsbGluZyB3b3JrIGZvciBhZHZhbmNlZA0KPnJv dXRlcnMgd2lsbCBiZSBkb25lIGVsc2V3aGVyZS4NCj4NCj4zLiBUaGUgd29yayBvbiBuZXRtb2Qt cm91dGluZy1jZmcgd2lsbCBiZSBzdG9wcGVkLg0KDQpBIGZvdXJ0aCBvcHRpb24gd291bGQgYmUg Zm9yIG1lIHRvIHRha2Ugb3ZlciBvd25lcnNoaXAsIG1vdmUgdGhlIHdvcmsgdG8NCnRoZSBSVEcg V0csIGFuZCB3ZeKAmWQgcmVjcnVpdCBzb21lIHN0cm9uZyBhdXRob3JzL3Jldmlld2VycyBmcm9t IG9wZXJhdG9ycw0KYW5kIG90aGVyIHZlbmRvcnMgKGludm9sdmluZyB0aGUgQURzIGluIHNlbGVj dGlvbikuDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KPg0KPk9waW5pb25zPw0KPg0KPlRoYW5rcywg TGFkYQ0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6 IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Fri Oct 9 06:39:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8961D1B3E35; Fri, 9 Oct 2015 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwgzUpEOGmn6; Fri, 9 Oct 2015 06:39:51 -0700 (PDT) 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 68E391B3E33; Fri, 9 Oct 2015 06:39:50 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1c2:d14c:7ffc:4360] (unknown [IPv6:2001:718:1a02:1:1c2:d14c:7ffc:4360]) by mail.nic.cz (Postfix) with ESMTPSA id 8D7D91810CF; Fri, 9 Oct 2015 15:39:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444397988; bh=KX4luHfdkolbOkkZbA98waNpGjlaHqefDc89puml5mw=; h=From:Date:To; b=F70naQLptFxwbJA1lDFzOXeX/qqb/EPtVS3X1vckqusLpYEt03QspZu11WMJHAuv2 abUH1CZBIXow4UmGuIoEBz1tAJZbB/hfzUnVA0u0YJTHBhvpGn9qpjI2gbTQD6wpiq EQFpmXAd0/ZcNhiOlTtLngtkodxVhSHAsjx/7NvU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Oct 2015 15:39:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 13:39:53 -0000 > On 09 Oct 2015, at 15:00, Acee Lindem (acee) wrote: >=20 > Hi Lada,=20 > I2RS is not chartered to do the base models. There are other routing > models that reference routing-cfg and even in-progress = implementations. Of course, I am aware of them. However, assuming that changes resulting = from I2RS operation will be available for inspection as state data to = NETCONF/RESTCONF clients, and vice versa, it's important that the those = routing data models and I2RS data models remain compatible and = coordinated. A data model for RIBs should IMO be developed simultaneously for both = purposes, and common parts implemented as groupings so as to be reusable = without copying-and-pasting.=20 >=20 > On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" > wrote: >=20 >> Hi, >>=20 >> I am sorry for cross-posting but I think it is high time to decide = the >> relationship between the data models in i2rs-rib-data-model and >> netmod-routing-cfg I-Ds because they clearly target the same = management >> data in a router. I can see three possible scenarios: >>=20 >> 1. The i2rs-rib module will be modified to augment >> ietf-routing/ietf-ipv[46]-unicast-routing. >=20 > This would seem to be the obvious choice. I agree, and so far it can be done quite easily. >=20 >>=20 >> 2. The scope of ietf-routing will be changed so that it would address >> only host routing and simple routers. The modelling work for advanced >> routers will be done elsewhere. >>=20 >> 3. The work on netmod-routing-cfg will be stopped. >=20 > A fourth option would be for me to take over ownership, move the work = to > the RTG WG, and we=E2=80=99d recruit some strong authors/reviewers = from operators > and other vendors (involving the ADs in selection). Yes, that's what I meant. Thanks, Lada >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> Opinions? >>=20 >> Thanks, Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 9 13:16:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B131B2D13; Fri, 9 Oct 2015 13:16:41 -0700 (PDT) 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 iuaLvyiQE_lf; Fri, 9 Oct 2015 13:16:40 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 494421B2D02; Fri, 9 Oct 2015 13:16:40 -0700 (PDT) Received: by qgew37 with SMTP id w37so19926311qge.0; Fri, 09 Oct 2015 13:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=4Z5AptrcMmhpupMV4AmdgsZqPkJJKYaLEiNJG8+jpi4=; b=rm3YQMFpPk6DOBYvmbyMmKnyIXTvgyz+/78spCPLWzVQ1q3xviBkq0K8R8N7PIWkNW JztlCP1kXe6zXhxYgPTUi70m8LAMEpbI7eP5sfh26ka6y/CkIh8pw8ldu2Xbka/XomZd yYOzJGSLly/MFhA8nKu27ZRjPio/BKyAIo0pUssxNk5i8YEKWvR4QZu74aGG+uxeH6dO IG8vGElSZTpSFuKSdcF1Z+aKrPMgAecCB3pfixFPJax8yYKDZENHi6EM1Ep7muIu1+qQ sPdMSSuTniQ6Xc3Wrzp5+ba9S+NAQdl4v203qIuw1Csze44op99S01Nfw49yguy8o0/V s6Sw== MIME-Version: 1.0 X-Received: by 10.140.18.240 with SMTP id 103mr18164653qgf.31.1444421799511; Fri, 09 Oct 2015 13:16:39 -0700 (PDT) Received: by 10.233.216.194 with HTTP; Fri, 9 Oct 2015 13:16:39 -0700 (PDT) In-Reply-To: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> Date: Fri, 9 Oct 2015 15:16:39 -0500 Message-ID: From: Behcet Sarikaya To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] [i2rs] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 20:16:41 -0000 On Fri, Oct 9, 2015 at 8:39 AM, Ladislav Lhotka wrote: > >> On 09 Oct 2015, at 15:00, Acee Lindem (acee) wrote: >> >> Hi Lada, >> I2RS is not chartered to do the base models. There are other routing >> models that reference routing-cfg and even in-progress implementations. > > Of course, I am aware of them. However, assuming that changes resulting f= rom I2RS operation will be available for inspection as state data to NETCON= F/RESTCONF clients, and vice versa, it's important that the those routing d= ata models and I2RS data models remain compatible and coordinated. > > A data model for RIBs should IMO be developed simultaneously for both pur= poses, and common parts implemented as groupings so as to be reusable witho= ut copying-and-pasting. > >> >> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >> wrote: >> >>> Hi, >>> >>> I am sorry for cross-posting but I think it is high time to decide the >>> relationship between the data models in i2rs-rib-data-model and >>> netmod-routing-cfg I-Ds because they clearly target the same management >>> data in a router. I can see three possible scenarios: >>> >>> 1. The i2rs-rib module will be modified to augment >>> ietf-routing/ietf-ipv[46]-unicast-routing. >> >> This would seem to be the obvious choice. > > I agree, and so far it can be done quite easily. > >> >>> >>> 2. The scope of ietf-routing will be changed so that it would address >>> only host routing and simple routers. The modelling work for advanced >>> routers will be done elsewhere. >>> >>> 3. The work on netmod-routing-cfg will be stopped. >> >> A fourth option would be for me to take over ownership, move the work to >> the RTG WG, and we=E2=80=99d recruit some strong authors/reviewers from = operators >> and other vendors (involving the ADs in selection). > You mean i2rs-rib-data-model? Regards, Behcet > Yes, that's what I meant. > > Thanks, Lada > >> >> Thanks, >> Acee >> >> >>> >>> Opinions? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Oct 9 14:03:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4711ACDA2 for ; Fri, 9 Oct 2015 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcQOi9vKEhBY for ; Fri, 9 Oct 2015 14:03:42 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8BC1B4C33 for ; Fri, 9 Oct 2015 14:03:41 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA07463 for ; Fri, 9 Oct 2015 17:03:40 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t99L3dWI067380 for ; Fri, 9 Oct 2015 17:03:40 -0400 (EDT) (envelope-from reid@mainfs.snmp.com) Message-Id: <201510092103.t99L3dWI067380@mainfs.snmp.com> To: netmod@ietf.org Date: Fri, 09 Oct 2015 17:03:39 -0400 From: David Reid Archived-At: Subject: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 21:03:44 -0000 I'm reviewing 6020bis since it is in working group last call. I see a new requirement that a server MUST NOT implement more than one revision of a module. I understand that supporting more than one revision can cause problems, but I expect that it will happen in practice. I know it happens sometimes with MIBs in SNMP. I think MUST NOT is too strong. -David Reid From nobody Fri Oct 9 14:09:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA81B4C59 for ; Fri, 9 Oct 2015 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFzz_JncGrA3 for ; Fri, 9 Oct 2015 14:09:54 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 542561B4C82 for ; Fri, 9 Oct 2015 14:09:50 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA07775 for ; Fri, 9 Oct 2015 17:09:30 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t99L9URf067463 for ; Fri, 9 Oct 2015 17:09:30 -0400 (EDT) (envelope-from reid@mainfs.snmp.com) Message-Id: <201510092109.t99L9URf067463@mainfs.snmp.com> To: netmod@ietf.org Date: Fri, 09 Oct 2015 17:09:30 -0400 From: David Reid Archived-At: Subject: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 21:09:55 -0000 section 6.3.1 states: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 14), the entire unknown-statement MAY be ignored by the compiler. If a YANG parser does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 14), the entire unknown-statement MAY be ignored by the parser. Note that even in this case the semantics associated with the extension still apply (as if they were part of a description statement). I assume the repetitive wording is not intentional. -David Reid From nobody Mon Oct 12 00:59:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D981A8752; Mon, 12 Oct 2015 00:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omycmSfUcJoF; Mon, 12 Oct 2015 00:58:55 -0700 (PDT) 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 65A231A8739; Mon, 12 Oct 2015 00:58:55 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E4F8F1818DB; Mon, 12 Oct 2015 09:58:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444636733; bh=GDH/li0X0ohFuJUpdBPmMRYiJ//bhKiwDT5WN0j4BYA=; h=From:Date:To; b=aVYJiDu9OcEJo//IrVcNEDBPmnFbgQllSeRlRfoLMvyu1xuHsLgL0f3EkGvRofo+e eiNnS2z1c2qKJqdVmS+3nbKWKmhZLalRqmhcIJFsDW6suI+Gdi2x6XekI8+ioXUV5d tRbaUPwr+AP0hJ920ojnGnbOfN8pm2DCmyZIBuCk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 12 Oct 2015 09:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <661ACA66-0E88-4574-864C-23DFFC8F670A@nic.cz> References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] [i2rs] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 07:58:57 -0000 > On 09 Oct 2015, at 22:16, Behcet Sarikaya = wrote: >=20 > On Fri, Oct 9, 2015 at 8:39 AM, Ladislav Lhotka wrote: >>=20 >>> On 09 Oct 2015, at 15:00, Acee Lindem (acee) wrote: >>>=20 >>> Hi Lada, >>> I2RS is not chartered to do the base models. There are other routing >>> models that reference routing-cfg and even in-progress = implementations. >>=20 >> Of course, I am aware of them. However, assuming that changes = resulting from I2RS operation will be available for inspection as state = data to NETCONF/RESTCONF clients, and vice versa, it's important that = the those routing data models and I2RS data models remain compatible and = coordinated. >>=20 >> A data model for RIBs should IMO be developed simultaneously for both = purposes, and common parts implemented as groupings so as to be reusable = without copying-and-pasting. >>=20 >>>=20 >>> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >>> wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I am sorry for cross-posting but I think it is high time to decide = the >>>> relationship between the data models in i2rs-rib-data-model and >>>> netmod-routing-cfg I-Ds because they clearly target the same = management >>>> data in a router. I can see three possible scenarios: >>>>=20 >>>> 1. The i2rs-rib module will be modified to augment >>>> ietf-routing/ietf-ipv[46]-unicast-routing. >>>=20 >>> This would seem to be the obvious choice. >>=20 >> I agree, and so far it can be done quite easily. >>=20 >>>=20 >>>>=20 >>>> 2. The scope of ietf-routing will be changed so that it would = address >>>> only host routing and simple routers. The modelling work for = advanced >>>> routers will be done elsewhere. >>>>=20 >>>> 3. The work on netmod-routing-cfg will be stopped. >>>=20 >>> A fourth option would be for me to take over ownership, move the = work to >>> the RTG WG, and we=E2=80=99d recruit some strong authors/reviewers = from operators >>> and other vendors (involving the ADs in selection). >>=20 >=20 > You mean i2rs-rib-data-model? We are talking about a bigger picture, and i2rs-rib-data-model is a part = of it. Lada >=20 > Regards, >=20 > Behcet >> Yes, that's what I meant. >>=20 >> Thanks, Lada >>=20 >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>>>=20 >>>> Opinions? >>>>=20 >>>> Thanks, Lada >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 12 01:15:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D901A87D9 for ; Mon, 12 Oct 2015 01:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LwjrfvQD0_n for ; Mon, 12 Oct 2015 01:15:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D24061A87CD for ; Mon, 12 Oct 2015 01:15:33 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FBD11AE0482; Mon, 12 Oct 2015 10:15:32 +0200 (CEST) Date: Mon, 12 Oct 2015 10:15:30 +0200 (CEST) Message-Id: <20151012.101530.501164857988635132.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201510092109.t99L9URf067463@mainfs.snmp.com> References: <201510092109.t99L9URf067463@mainfs.snmp.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 08:15:35 -0000 David Reid wrote: > section 6.3.1 states: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 14), > the entire unknown-statement MAY be ignored by the compiler. > > If a YANG parser does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 14), > the entire unknown-statement MAY be ignored by the parser. Note that > even in this case the semantics associated with the extension still > apply (as if they were part of a description statement). > > I assume the repetitive wording is not intentional. Right; the first paragraph should be removed. Thanks for spotting this! /martin From nobody Mon Oct 12 03:42:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EF11ACD5D for ; Mon, 12 Oct 2015 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsMAFe6S38PG for ; Mon, 12 Oct 2015 03:42:30 -0700 (PDT) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903761ACD5A for ; Mon, 12 Oct 2015 03:42:30 -0700 (PDT) Received: from jva2tc217.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-5.webex.com [64.68.121.240]) by sjmda10.webex.com (Postfix) with ESMTP id 5E4B6349E for ; Mon, 12 Oct 2015 10:42:30 +0000 (GMT) Received: from jva2tc217.webex.com (localhost [127.0.0.1]) by jva2tc217.webex.com (Postfix) with ESMTP id 21786118D for ; Mon, 12 Oct 2015 10:42:30 +0000 (GMT) Date: Mon, 12 Oct 2015 10:42:30 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <52632770.820.1444646550135.JavaMail.nobody@jva2tc217.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_818_273530204.1444646550134" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 10:42:32 -0000 ------=_Part_818_273530204.1444646550134 Content-Type: multipart/Alternative; boundary="----=_Part_819_1607134048.1444646550134" ------=_Part_819_1607134048.1444646550134 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCk1vbmRheSwgT2N0b2JlciAxMiwgMjAxNQo1 OjAwIHBtICB8ICBFdXJvcGUgU3VtbWVyIFRpbWUgKEJlcmxpbiwgR01UKzAyOjAwKSAgfCAgMSBo cgoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tY2I3ZGRhNjg1MTg2Njk1ZTJkZDYyMjdmZjdhN2FjMzgKTWVldGluZyBudW1iZXI6IDY0 OCAyMDUgNzk5Ck1lZXRpbmcgcGFzc3dvcmQ6IGFaZFVWODVECgoNCkpPSU4gQlkgUEhPTkUNCjEt ODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjQ4 IDIwNSA3OTkKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogCmh0dHA6Ly93d3cud2Vi ZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmDQoNCgpBZGQgdGhpcyBtZWV0aW5n IHRvIHlvdXIgY2FsZW5kYXI6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE PW02NTQ4YzZmZWQ5OWYxMThmZTdkZGI3NzVhNmQ1NzUyOQ0KDQoKQ2FuJ3Qgam9pbiB0aGUgbWVl dGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9t YwoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi4K ------=_Part_819_1607134048.1444646550134 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+TW9u ZGF5LCBPY3RvYmVyIDEyLCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD41OjAwIHBtJm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwO0V1cm9wZSBTdW1tZXIgVGltZSAoQmVybGluLCBHTVQrMDI6MDApJm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwOzEgaHIKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0i d2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0 ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1jYjdkZGE2ODUxODY2OTVl MmRkNjIyN2ZmN2E3YWMzOCIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtm b250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVl dGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0 YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJw YWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCQk8dGQ+NjQ4IDIwNSA3OTkKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcg cGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+YVpkVVY4NUQ8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+ PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2Fs bC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFy Z2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNjZXNz IGNvZGU6Jm5ic3A7NjQ4IDIwNSA3OTk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48 dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtjb2xvcjoj MDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwvdGQ+PC90cj48L3Rh YmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9 ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHls ZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW02NTQ4YzZmZWQ5OWYxMThmZTdkZGI3NzVhNmQ1NzUyOSIgc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBt ZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRy IHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZv bnQtc2l6ZTogMTNweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAg ICBDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAgIAk8YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNw eDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsiPgog ICAgICAgIAlDb250YWN0IHN1cHBvcnQuPC9hPgoJCTwvdGQ+CiAgICA8L3RyPgo8L3RhYmxlPgo8 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjEw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGU+CgkJCQkJCQk8dHI+CgkJ CQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTJweDtjb2xvcjogI0EwQTBBMDsiPgoJCQkJCQkJ CQlJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQk8L3RkPgoJCQk8 L3RyPgoJCTwvdGFibGU+Cgk8L3RkPgogICA8L3RyPgo8L3RhYmxlPgoKPC9ib2R5Pg== ------=_Part_819_1607134048.1444646550134-- ------=_Part_818_273530204.1444646550134 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MTAxMlQxNzAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUxMDEyVDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQ0NjQ2NTUwClVJRDpkNjQ3NDEwOS1l NGZiLTQ2MGYtOGE3My0yMmJiYmNiNWM5ZGEKRFRTVEFNUDoyMDE1MTAxMlQxNTAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWRlNjY1YWQzMTBiNDlkMjZmMDg4YjEyYmNhYmRkNDVhXG5NZWV0aW5n IG51bWJlcjogNjQ4IDIwNSA3OTlcbk1lZXRpbmcgcGFzc3dvcmQ6IGFaZFVWODVEXG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0OCAyMDUgNzk5XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1kZTY2NWFkMzEwYjQ5ZDI2ZjA4OGIxMmJjYWJkZDQ1YSI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0OCAyMDUgNzk5PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YVpkVVY4NUQ8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ4IDIwNSA3OTk8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= ------=_Part_818_273530204.1444646550134-- From nobody Mon Oct 12 03:45:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E770A1ACD78 for ; Mon, 12 Oct 2015 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I6H4-nPzRDp for ; Mon, 12 Oct 2015 03:45:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAF61ACD71 for ; Mon, 12 Oct 2015 03:45:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 279A3E75 for ; Mon, 12 Oct 2015 12:45:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P2gPZbnL-1OD for ; Mon, 12 Oct 2015 12:45:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 12 Oct 2015 12:45:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA7720056 for ; Mon, 12 Oct 2015 12:45:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hhm6Kv8fg9iy; Mon, 12 Oct 2015 12:45:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F361720054; Mon, 12 Oct 2015 12:45:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E660737B13BC; Mon, 12 Oct 2015 12:45:50 +0200 (CEST) Date: Mon, 12 Oct 2015 12:45:50 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151012104550.GA63542@elstar.local> Mail-Followup-To: netmod@ietf.org References: <52632770.820.1444646550135.JavaMail.nobody@jva2tc217.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52632770.820.1444646550135.JavaMail.nobody@jva2tc217.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 10:45:57 -0000 Hi, we will use this etherpad to take notes: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-10-12?useMonospaceFont=true /js On Mon, Oct 12, 2015 at 10:42:30AM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Monday, October 12, 2015 > 5:00 pm | Europe Summer Time (Berlin, GMT+02:00) | 1 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=mcb7dda685186695e2dd6227ff7a7ac38 > Meeting number: 648 205 799 > Meeting password: aZdUV85D > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 648 205 799 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m6548c6fed99f118fe7ddb775a6d57529 > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 12 07:16:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082DA1B32F1 for ; Mon, 12 Oct 2015 07:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6tiBkzSWAOP for ; Mon, 12 Oct 2015 07:16:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CAA661B32CC for ; Mon, 12 Oct 2015 07:15:59 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0464E1CC00D9; Mon, 12 Oct 2015 16:16:00 +0200 (CEST) From: Ladislav Lhotka To: Nadeau Thomas , "netmod\@ietf.org" In-Reply-To: <0C07CD94-18A1-4CCE-A8F6-E0C623680DC9@lucidvision.com> References: <0C07CD94-18A1-4CCE-A8F6-E0C623680DC9@lucidvision.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 12 Oct 2015 16:15:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod-chairs@tools.ietf.org Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-yang-metadata-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:16:06 -0000 Hi, I am not aware of any IPR applicable to this draft. Lada Nadeau Thomas writes: > NETMOD WG: > > This mail starts the IPR poll on draft-ietf-netmod-yang-metadata-02. > > Are you aware of any IPR that applies to draft-ietf-netmod-yang-metadata-02? > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs > 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to this > email explicitly regardless of whether or not you are aware of any relevant IPR. > The response needs to be sent to the NETMOD WG mailing list. The document > will not advance to the next stage until a response has been received from each > author and contributor. > > If you are on the NETMOD WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any IPR that > has not yet been disclosed in conformance with IETF rules. > > Thank you, > > Kent and Tom, NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 12 07:43:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7FF1B33E0 for ; Mon, 12 Oct 2015 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M16SVOsYDJcj for ; Mon, 12 Oct 2015 07:43:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A8B1B33DE for ; Mon, 12 Oct 2015 07:43:22 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-f2-561b5ac7a075 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F6.B1.26730.7CA5B165; Mon, 12 Oct 2015 09:01:27 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 10:43:21 -0400 From: Scott Mansfield To: "netmod@ietf.org" Thread-Topic: Updates to draft-mansfield-netmod-uml-to-yang Thread-Index: AdEE+pLlCt6QidUcSq27gvo/sEr0IA== Date: Mon, 12 Oct 2015 14:43:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558644BC301ACeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXRPiO7xKOkwg7urjCzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvfuW2wFJ5wqru68wdrAuM2qi5GTQ0LARKJ/4U9mCFtM4sK9 9WxdjFwcQgJHGSWar+1khnCWM0r0vljIClLFBtSxddd0RhBbREBdYuZOkA5ODmEBM4nVt1ez dDFyAMWtJd4+SoQw9SQ+z1UFqWARUJV4e3M12BReAV+JIyv3MIHYjEB7v59aA2YzC4hL3Hoy nwniHgGJJXvOQ90mKvHy8T9WCFtJYtLSc6wg45kF8iVmn3GCGCkocXLmE5YJjEKzkEyahVA1 C0kVRImOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chwEyMw5I9JsDnuYFzw yfIQowAHoxIPb0K2VJgQa2JZcWXuIUZpDhYlcd55M+6HCgmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamCUqT+t9uqA+MbHGoE3uGxunimSW3gk8UX9zL2T/X/c9XM1uunweX6FpGJ6/K+5Jiq1 n/xLRE+fL9VfZiV1TW9hqlp7147ohaqvuOVPbqouX3XTwHn71y9WO6+1+/jdelsmf+bekXhO wRtlv4pzNdR2/ywSnMNndiO7olcubEf1yeLJm7TizjQrsRRnJBpqMRcVJwIAkC79r1oCAAA= Archived-At: Subject: [netmod] Updates to draft-mansfield-netmod-uml-to-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:43:24 -0000 --_000_EF35EE4B92789843B1DECBC0E24558644BC301ACeusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The uml-to-yang internet draft has been updated to add more details and bet= ter examples of the mappings between uml artefacts and YANG. Some highlights... - Much more detail included in the Mapping tables for Object Class= es, Attributes, Associations, Interfaces, Operations, Operations Parameters= , and Notifications. - Information on Mapping considerations (Mapping Issues) restructu= red and more information provided for types. - Pointer to new work on YANG packages added to suggest the creati= on of mapping rules for packages. - UML recursion information expanded and moved to a section called= Mapping Patterns - Added information on meta-information about the support and cond= ition of artefacts. This adds the ability to know if an artefact is: M - M= andatory, O - Optional, C - Conditional, CM, Conditional-Mandatory, or C= O - Conditional-Optional. There will be a short presentation/status update at the Yokohama meeting. Thank You! -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E24558644BC301ACeusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The uml-to-yang internet draft has been updated to a= dd more details and better examples of the mappings between uml artefacts a= nd YANG.

 

Some highlights…

-     &= nbsp;    Much more detail included in the Mapping tables for= Object Classes, Attributes, Associations, Interfaces, Operations, Operatio= ns Parameters, and Notifications.

-     &= nbsp;    Information on Mapping considerations (Mapping Issu= es) restructured and more information provided for types.

-     &= nbsp;    Pointer to new work on YANG packages added to sugge= st the creation of mapping rules for packages.

-     &= nbsp;    UML recursion information expanded and moved to a s= ection called Mapping Patterns

-     &= nbsp;    Added information on meta-information about the sup= port and condition of artefacts.  This adds the ability to know if an = artefact is: M - Mandatory, O - Optional, C - Conditional, CM,   = Conditional-Mandatory, or  CO - Conditional-Optional.

 

There will be a short presentation/status update at = the Yokohama meeting.

Thank You!

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_EF35EE4B92789843B1DECBC0E24558644BC301ACeusaamb105erics_-- From nobody Mon Oct 12 07:44:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349FA1B33FE for ; Mon, 12 Oct 2015 07:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eAdvYVFKliC for ; Mon, 12 Oct 2015 07:44:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FC41B3400 for ; Mon, 12 Oct 2015 07:44:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4BF0B100C for ; Mon, 12 Oct 2015 16:44:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Yubn1uYbAfiI for ; Mon, 12 Oct 2015 16:44:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 12 Oct 2015 16:44:35 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5699820056 for ; Mon, 12 Oct 2015 16:44:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZSP7oDHFM0nU; Mon, 12 Oct 2015 16:44:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A74920055; Mon, 12 Oct 2015 16:44:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4DC6537B1685; Mon, 12 Oct 2015 16:44:32 +0200 (CEST) Date: Mon, 12 Oct 2015 16:44:31 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151012144431.GA64068@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:44:46 -0000 Hi, I have read through draft-ietf-netmod-rfc6020bis-07 (except section 9. Built-In Types). Overall, the document is in a good shape. I spotted a number of editorial issues or a number of issues where we could try to seek a clearer separation of NETCONF specifics. (I plan to read section 9 as well but I assume this is less important since there likely are not many changes from RFC 6020 in this part.) I am indicating the paper number below for each comment/suggestion. * p8: s/XML has been/XML have been/ s/how the data model/how a data model/ s/represented in/encoded in/ * p9: s/names means/names mean/ * p11: s/the module faithfully/a module faithfully/ I am also wondering why we use device and server. It seems we use these terms interchangeably. If so, for clarity, I would suggest to use a single term, that is s/device/server/ and perhaps explicitly state that unless stated otherwise server means a server providing access to a YANG defined data tree. * p12/p13 We import 7 terms from RFC 6241. Would it make sense to copy the necessary text in order to avoid a too strict binding to RFC 6241? In particular, 'client' and 'server' means NETCONF client and server if we import from RFC 6241 but this may be a bit narrow given that we have RESTCONF as well. In an ideal world, we would factor out core architectural concepts but the best we can do is likely to define core concepts inline, pointing out where they are the same. The idea is to loosen the coupling to RFC 6241. Example: OLD o datastore: an instantiated data tree NEW o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. [Matches the definition in RFC 6241.] * p13 Does the term 'mandatory node' really deserve its own subsection? I understand that there are references to section 3.1 but would reference to section 3 not work as well? * p13 s/used for other/used with other/ * p14 s/encoded in NETCONF operations/encoded on-the-wire/ * p14 s/of NETCONF data models/of data models for network management protocols such as NETCONF,/ And I suggest to remove the following sentence since it is not really needed. The data models described by YANG are designed to be easily operated upon by NETCONF operations. * p15 s/read-only access/read-only access [RFC6643]/ * p15 I am not sure why the last paragraph in section 4.1 is needed. In the first setence, I would remove 'Like NETCONF' and in the second sentence I am not sure what we are saying given that there is NACM. I would definitely remove the second sentence and if the first should be kept, I would likely move it up since it is a fairly general statement. But I think removing the whole paragraph is the simplest solution since it is not essential. * p13 Would it make sense to add a sentence right at the beginning of section 4 stating that section 4 is intended to provide orientation for the first time reader but that section 4 is not normative? * p15 With the previous in mind, I suggest to remove "This progressive approach handles the inter-related nature of YANG concepts and statements. A detailed description of YANG statements and syntax begins in Section 7." from the text right below 4.2. Note that Section 7 is actually Section 6 (but Section 5 has also important normative content). * p16 s/four types of nodes/four types of data nodes/ * p16 Perhaps simplify: OLD A leaf instance contains simple data like an integer or a string. It has exactly one value of a particular type and no child nodes. NEW A leaf data node has exactly one value of a particular type and no child nodes. * p16-p25 Should this be 'XML Encoding Example' instead "NETCONF XML Example'? This does not seem to be NETCONF specific. * p25 s/XML representation/XML encoding/ * p25 s/operations' names/operations' name/ * p25 s/node in the data hierarchy/data node/ * p28 Start section 5 by saying that this section defined language concepts and that it is normative, e.g. This normative section defines core language concepts. * p29 s/its contents are unchanged/its content is unchanged/ * p37 s/following shows valid data/following XML encoding shows valid data/ * p35 I think there should be a citation of I-D.ietf-netconf-yang-library where this module first appears. * p46 The text concerning module names is a repetition from section 5.1. To avoid introducing inconsistencies, perhaps replace the repeated text with a reference to section 5.1? * p49 Is the text in section 7.1.3 correct when it says all identifiers defined by the module? I mean, schema node identifiers are namespaced by module names and their prefixes. And data node identifiers are using the namespace in the XML encoding. Here is an attempt of a rewrite: The "namespace" statement defines the XML namespace that all data node identifiers defined by the module are qualified by in the XML encoding. Data node identifiers defined inside a grouping are an exception q(see Section 7.13 for details). The argument to the "namespace" statement is the URI of the namespace. * p53 Another repetition of the module/submodule name requirements, does it make sense to avoid repetition? * p61 Should the text in 7.5.4.1 and 7.5.4.2 say explicitly that we talk about NETCONF when we refer to ? Or should the text try to be more generic, saying that the respective fields will be carried in error message in protocols that use YANG? It is actually somewhat opaque what an error-app-tag is or how it should be used. * p63 Should the last paragraph in 7.5.7 be factored out into its own subsection titled "NETCONF and Operations"? The text is not really anymore about XML encoding (which may be used with RESTCONF). Or the text is actually about the encoding but should be written to simply state that non-presence containers can be pruned in encodings (without restricting this to NETCONF). * p67 Similar to the comment for p63. Perhaps the right way is to phrase this in such a way that is simply says leaf nodes containing a default value may not be present in the XML encoding. Simply remove NETCONF or specifics. * p72 s/an unspecified order/an order determined by the system/ Note that a description clause may actually define how the system has to order elements and hence 'unspecified order' seems wrong. * p97 The text in 7.14 talks about NETCONF specifics, namely the element and the "rpcOperation" substitution group. Perhaps move this down into a specific section defining the mapping of YANG RPCs to NETCONF s. * p100 The XML encoding text starts with detailing NETCONF specifics. Would it make sense to separate the XML encoding of the rpc and its input/output from the specifics how the RPCs fit into NETCONF's system? * p102 The XML encoding section again mixes XML encoding of the node hierarchy with NETCONF specifics how an action is invoked using NETCONF's system. I suggest to factor this into two different sections. * p105 Again, the proposal is to separate the XML encoding of notifications from the details how notifications work with RFC 5277. * p120 The text in section 7.21.1 talks about NETCONF specific operations. Is this actually necessary? Can the purpose of the config statement not be described by referring to general concepts such as configuration datastores instead of using protocol specific operations? * p123 Is there a special reason why the text uses 'notification instance data tree' instead of just 'notification data tree'? * p123 "All leaf data values MUST match the type constraints..." may be read as 'all data nodes that contain values' or 'all instantiations of nodes defined by the leaf statement'. * p192 The Acknowledgements section may need some updates. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 12 11:09:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB61ACDE0 for ; Mon, 12 Oct 2015 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Opdqby0DRa6 for ; Mon, 12 Oct 2015 11:09:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91541ACDE7 for ; Mon, 12 Oct 2015 11:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7361; q=dns/txt; s=iport; t=1444673344; x=1445882944; h=from:to:subject:date:message-id:mime-version; bh=ezVhNsTXoxUZhPeJ2flYGMdBn9OLvZI4nn5wWdZta0g=; b=Rq8nw/IZa8/611ZOiDds4lygJRvlkMbfGdgGutZq255wDXL0EonkD37w pj0MyJU6J0muvOyTSQ4iXVsBV1QDg7RIKF4ufjQ12stiWMW00GtZCsXqM kXVGvaVAGaYcsf9UOSYbRDtXxf/cDy9YL+rlkP7gsdv7l2KmkVOe2ceXX I=; X-Files: WebEx_Meeting.ics, ATT00001.txt : 3783, 170 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAADT9htW/4kNJK1DFwODJlRuBoQVuWkOdgVfFwyCcIIKNUqBODgUAQEBAQEBAYEKhCgBBAEBAWMIHQE0BAwMJQskAwEDEw4NiBMNO5swlSSOGQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOCEIQrAYMLKQspB4MBgRQFlhMBgk2BYWqIAZwCAR8BQ4IRDRCBBU9xAYVqgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,674,1437436800"; d="ics'?txt'?scan'208";a="197172984" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 12 Oct 2015 18:09:04 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9CI93U7022073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Oct 2015 18:09:04 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Oct 2015 13:08:51 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.000; Mon, 12 Oct 2015 13:08:51 -0500 From: "Andrew McLachlan (amclachl)" To: netmod WG Thread-Topic: [netmod] Thursday Interim Meeting Webex 15th Oct 2015 Thread-Index: AQHRBRkMQ/Vcpyagd0yNcE595hvHrg== Date: Mon, 12 Oct 2015 18:08:51 +0000 Message-ID: <0FEA3B3C-ACBE-42C2-BEEC-480C9CD41A29@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.81.213] Content-Type: multipart/mixed; boundary="_003_0FEA3B3CACBE42C2BEEC480C9CD41A29ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Thursday Interim Meeting Webex 15th Oct 2015 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 18:09:06 -0000 --_003_0FEA3B3CACBE42C2BEEC480C9CD41A29ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Continuation of last weeks discussion, with a goal of closing down the foll= owing issues around https://datatracker.ietf.org/doc/draft-openconfig-netmo= d-opstate/ Finalize terminology: - distributed - transactional - synchronous - asynchronous - applied The details of the meeting are here: The NETCONF Data Modeling Language (netmod) Working Group will hold a virtu= al interim meeting on Thursday, October 1, 2015 at 10am EDT (7am PDT; 2pm G= MT). The title is =93Openconfig Solutions Discussion (continued)=94. The WebEx is: Meeting number:640 686 530 Meeting password:1234 Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 686 530 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm7bb8ad80c4b668fd792= 46323c80c8246 --_003_0FEA3B3CACBE42C2BEEC480C9CD41A29ciscocom_ Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3783; creation-date="Mon, 12 Oct 2015 18:08:51 GMT"; modification-date="Mon, 12 Oct 2015 18:08:51 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJORVRNT0QgV29ya2lu ZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTpNQUlMVE86bmV0bW9kLWNo YWlyc0B0b29scy5pZXRmLm9yZwpPUkdBTklaRVI7Q049IndlYmV4IjpNQUlMVE86bWVzc2VuZ2Vy QHdlYmV4LmNvbQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTEwMTVUMTAwMDAwCkRU RU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTEwMTVUMTIxMDAwCkxPQ0FUSU9OOmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0NDQ2NzMxMzEKVUlE OmVkNTIwYzAzLTI5ZjgtNDIyYy1iZjg3LThjOTY4MmRlNjJmMwpEVFNUQU1QOjIwMTUxMDE1VDE0 MDAwMFoKREVTQ1JJUFRJT046XG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tN2JiOGFkODBjNGI2NjhmZDc5MjQ2MzIzYzgwYzgy NDZcbk1lZXRpbmcgbnVtYmVyOiA2NDAgNjg2IDUzMFxuTWVldGluZyBwYXNzd29yZDogMTIzNFxu XG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJl ciAoVVMvQ2FuYWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh bmFkYSlcbkFjY2VzcyBjb2RlOiA2NDAgNjg2IDUzMFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0 cmljdGlvbnM6IFxuaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJl OlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3VsZCBpbmZv cm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3UgaW50ZW5k IHRvIHJlY29yZCB0aGUgbWVldGluZy5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1sOgk8 Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9IkFyaWFsIj4gJm5ic3A7PEJSPkhvc3Qga2V5OiAxMTkwODA8L0ZPTlQ+Jm5ic3A7PEJS PiZuYnNwOzxCUj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJ CQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tN2JiOGFkODBj NGI2NjhmZDc5MjQ2MzIzYzgwYzgyNDYiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBG QUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0 cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj42NDAgNjg2IDUzMDwvRk9OVD4J CQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05U PjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjEy MzQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0i QVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFS SUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkg cGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0 cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29k ZTogNjQwIDY4NiA1MzA8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4 LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9 IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZP TlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9 IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRp bmc/PC9GT05UPgk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9O VCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48 L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXpl PSIxIiBGQUNFPSJhcmlhbCI+SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlz IFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1 cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJs ZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5k ZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0aGUgbWVldGlu Zy48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOk9wZW5jb25maWcgU29sdXRpb25zIERpc2N1c3Npb24g KGNvbnRpbnVlZCkKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJNClRSSUdHRVI6 LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6 VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_003_0FEA3B3CACBE42C2BEEC480C9CD41A29ciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=170; creation-date="Mon, 12 Oct 2015 18:08:51 GMT"; modification-date="Mon, 12 Oct 2015 18:08:51 GMT" Content-ID: Content-Transfer-Encoding: base64 DQoNCg0KDQoJLS1Ub20gKGFzIFdHIGNvLWNoYWlyKQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_003_0FEA3B3CACBE42C2BEEC480C9CD41A29ciscocom_-- From nobody Mon Oct 12 13:43:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABCD1B363B for ; Mon, 12 Oct 2015 13:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFHy8IKIJC9z for ; Mon, 12 Oct 2015 13:43:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2931B2D57 for ; Mon, 12 Oct 2015 13:43:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F28BEA3 for ; Mon, 12 Oct 2015 22:43:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8poY1nOq2IWw for ; Mon, 12 Oct 2015 22:43:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 12 Oct 2015 22:43:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B950720053 for ; Mon, 12 Oct 2015 22:43:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JX5eRv5waMeH; Mon, 12 Oct 2015 22:43:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1436B2004E; Mon, 12 Oct 2015 22:43:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E05FD37B1A55; Mon, 12 Oct 2015 22:43:05 +0200 (CEST) Date: Mon, 12 Oct 2015 22:43:05 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151012204305.GA64773@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-10-12 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 20:43:15 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-10-12 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="netmod-2015-10-12-minutes.txt" X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit ============================================================= NETCONF Data Modeling Language WG (netmod) 22nd YANG 1.1 Virtual Interim Monday, October 12th, 2015, 17:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants AB = Andy Bierman DR = Dan Romascanu JB = James Bensley JS = Juergen Schoenwaelder KW = Kent Watsen LL = Ladislav Lhotka MB = Martin Björklund RW = Robert Wilton SM = Scott Mansfield * VRFY mandatory nodes in augments (Y26 related) https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU MB: I am not convinced we should change MUST NOT to SHOULD NOT. RW: This comes up in practice and the MUST NOT partially conflicts with RFC 6087bis. MB: I understand the use case but tools would not be able to interpret a SHOULD reliably. RW: Would a tool not be able to generate a suitable warning? RW: Within IETF, peer review should catch bad uses. Companies will receive customer feedback. LL: In some cases, modules are designed to make mandatory augments safe. Conclusion: We go with SHOULD NOT and we move the text from RFC 6087bis into the YANG 1.1 specification to avoid a dependency on RFC 6087bis. * OPEN when statement context clarification https://mailarchive.ietf.org/arch/msg/netmod/_Ab-__IOsGj7FOv_OEJmfX0wG_8 MB: I think I recall that we arrived on the mailing list at some text we agreed to. MB: I can summarize the final proposal check it on the mailing list. Action: MB will send the conclusions to the mailing list for verification. * VRFY module name uniqueness https://mailarchive.ietf.org/arch/msg/netconf/CyWQQU9FnyJJG88j81VE8Q2Nh8U MB: I tend to agree with Randy that we really want MUST but it is difficult to achieve this without a central registry. MB: Perhaps state that within a server module names MUST be unique. KW: This is already implied by the YANG library. Conclusion: State that module names MUST be unique within a server. The SHOULD be globally unique does not change. * VRFY anydata clarification https://mailarchive.ietf.org/arch/msg/netmod/qiAkN9QA0SrjHV82W3HQEYUI-VI Also note Lada's comment that anydata should exclude anyxml from the "unknown set of nodes that can be modeled with YANG". Lada later asked whether anydata can have attributes in the XML encoding. (Not sure I got this right, Lada please correct me.) MB: Exclusion of anyxml is fine. JS: I agree. LL: What about attributes? MB: Attributes are not tied to data nodes. LL: What about extensions? LL: If there is no data model and you receive attributes, is this legal or not? MB: I think it should be legal to have attributes in the anydata content if we allow attributes on data nodes. Conclusion: Add text to exclude anyxml but leave the rest of the wording as is. * OPEN more than one revision of a module https://mailarchive.ietf.org/arch/msg/netmod/sBVhgKtO7Pjsd1GzybqNe3DtVSo MB: Unclear what the question is. Is it about advertising multiple revisions in situations where modules got extended? Action: MB to followup on the mailing trying to figure out what is behind this question. * OPEN choices corner cases Balazs asked a couple of questions concerning nested choices on the list. Is there anything concrete to be done for YANG 1.1? LL: I do not think that any changes are needed. This can get tricky but it is not a specification problem. LL: Perhaps discuss in the guidelines document some of the cases that were brought up on the list? MB: Make sure the text covers Balazs first example (I will take a look). AB: I did not agree with any of Balazs' requests for changes. Conclusion: Nothing to be done in YANG 1.1, perhaps good to discuss examples further in the guidelines documents, LL will take a look. * AOB MB: YANG 1.1 has a dependency of YANG library. JS: I can contact the NETCONF chairs to check the status and the process forward. AB: There was one issue with modules with import without revisions. MB: Is this a question concerning YANG library or does this affect YANG 1.1? AB: It is a question concerning YANG library. MB: In hindsight, I think we should have used the JSON instance identifier notation in XML as well. AB: I will look into the YANG library so that we can get things out. --k1lZvvs/B4yU6o8G-- From nobody Mon Oct 12 22:59:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07571B38AD; Mon, 12 Oct 2015 22:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.392 X-Spam-Level: **** X-Spam-Status: No, score=4.392 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUEhwndPnwqn; Mon, 12 Oct 2015 22:59:46 -0700 (PDT) Received: from tsinghua.org.cn (unknown [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8181B38AB; Mon, 12 Oct 2015 22:59:43 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06C7VgQSmhxW07wRAw==.25450S2; Tue, 13 Oct 2015 13:44:01 +0800 (CST) From: "Aijun Wang" To: , References: In-Reply-To: Date: Tue, 13 Oct 2015 13:58:56 +0800 Message-ID: <004a01d1057c$47e02310$d7a06930$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01D105BF.56036310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEFapt5Fqf1Bn2CSemDcxAR3HYI/AAEY6Rw Content-Language: zh-cn X-CM-TRANSID: Z0GX06C7VgQSmhxW07wRAw==.25450S2 X-Coremail-Antispam: 1U3129KBjvJXoWxury7Gry5Kr47Jr4kZw1DKFg_yoW5Gw18pa 45WrW5trnYya45Cr1fZ3WUA3WrZ3s8t395CFnxCw1jyay5XFyIgw4UKr1rZFW7Ary8JwsY vrWUZ3sxX3W5JrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Gr0_Xr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JUAb18UUUUU= Archived-At: Subject: [netmod] Tunnel Design Philosophy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 05:59:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01D105BF.56036310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, RTGWGer and NETMODer: Here I want to ask for advices from any expert that is familiar with the usages and designs of various tunnel technologies that are wide deployed within the network. What is the principle and philosophy about the design of Yang Model for these tunnel technologies? Currently, there are several drafts that has touches this area, but there are some confusions about their designs, for example: 1. Can we organize these tunnel related-Yang models under one common tree? 2. What is the relationship between the tunnel related-Yang model and the interface Yang Model? Our opinion is that Yang Model is one design tool/language used to standard the interface between the service provider and device(Device Yang Model), and between the service provider and their customer(Service Yang Model), then the design of them should from top to down, find the general aspects of every model branch first and augment them with specific technology later. This seems more common to all the Model/Object design language. So, for above two questions, we recommend to design one general tunnel-related Yang model that augments from the interface Yang model, and expand to it to cover the various specific tunnel technologies. Doing so has the following benefits: 1. we can focus first the common characteristic of tunnel technology, especially the static tunnel technologies(dynamic tunnel for example MPLS-TE tunnel is the exception) 2. the appearance of the tunnel on router/switch are all one kind of interface. If it augments from the interface tunnel, it can inherit many variables of the interface Yang model.(several drafts have shown their overlapping design of these variables.) So, how about your opinion and the reason to do them? Wish can hear more valuable suggestions on the design of the Tunnel-related Yang Model. Current available drafts about the Tunnel -related Yang Model are bellows: 1. https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-v6-tunnel-yang-00 2. http://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/ 3. http://datatracker.ietf.org/doc/draft-wilton-netmod-intf-vlan-yang/ 4. http://datatracker.ietf.org/doc/draft-liu-rtgwg-ipipv4-tunnel-yang/ 5. http://datatracker.ietf.org/doc/draft-li-rtgwg-utunnel-yang/ 6. https://tools.ietf.org/id/draft-ietf-teas-yang-te-00.txt( This draft is one exception, and seems can't be generalized with other five drafts) Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line ------=_NextPart_000_004B_01D105BF.56036310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, RTGWGer = and NETMODer:

 

Here I want to ask for advices from any expert that is = familiar with the usages and designs of various tunnel technologies that = are wide deployed within the network.

What is the principle and = philosophy about the design of Yang Model for these tunnel = technologies?

 

Currently, there are several drafts that has touches this = area, but there are some confusions about their designs, for = example:

1. = Can we organize these tunnel related-Yang models under one common = tree?

2. = What is the relationship between the tunnel related-Yang model and the = interface Yang Model?

 

Our opinion is that Yang Model is one design tool/language = used to standard the interface between the service provider and = device(Device Yang Model), and between the service provider and their = customer(Service Yang Model), then the design of them should from top to = down, find the general aspects of every model branch first and augment = them with specific technology later. This seems more common to all the = Model/Object design language.

 

So, for above two questions, we = recommend to design one general tunnel-related Yang model that augments = from the interface Yang model, and expand to it to cover the various = specific tunnel technologies. Doing so has the following = benefits:

1. we can focus first the common characteristic of tunnel = technology, especially the static tunnel technologies(dynamic tunnel for = example MPLS-TE tunnel is the exception)

2. the appearance of the tunnel on = router/switch are all one kind of interface. If it augments from the = interface tunnel, it can inherit many variables of the interface Yang = model.(several drafts have shown their overlapping design of these = variables.)

 

So, how about your opinion and the reason to do = them?

Wish = can hear more valuable suggestions on the design of the Tunnel-related = Yang Model.

 

Current available drafts about the Tunnel –related = Yang Model are bellows:

1. https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-v6-tunnel-yan= g-00

2. http://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/

3. http://datatracker.ietf.org/doc/draft-wilton-netmod-intf-vlan-yang/

4. http://datatracker.ietf.org/doc/draft-liu-rtgwg-ipipv4-tunnel-yang/

5. htt= p://datatracker.ietf.org/doc/draft-li-rtgwg-utunnel-yang/<= /span>

6. https:/= /tools.ietf.org/id/draft-ietf-teas-yang-te-00.txt( This draft is one exception, and seems can’t be = generalized with other five drafts)

 

Best = Regards.

 

 

Aijun = Wang

 =

China = Telecom Corporation Limited Beijing Research Ins= titute 

Intelligent= Network Product Line

 

 

 

------=_NextPart_000_004B_01D105BF.56036310-- From nobody Tue Oct 13 01:03:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1B31B3B06 for ; Tue, 13 Oct 2015 01:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHu1wRk2KZ2V for ; Tue, 13 Oct 2015 01:03:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C071B3AAB for ; Tue, 13 Oct 2015 01:03:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 04A3FAC2 for ; Tue, 13 Oct 2015 10:02:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g2CTd-erYy0d for ; Tue, 13 Oct 2015 10:02:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 13 Oct 2015 10:02:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D454F20054 for ; Tue, 13 Oct 2015 10:02:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iNJDKfz4-1uS; Tue, 13 Oct 2015 10:02:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CA0520053; Tue, 13 Oct 2015 10:02:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CAE2437B1F89; Tue, 13 Oct 2015 10:02:54 +0200 (CEST) Date: Tue, 13 Oct 2015 10:02:54 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151013080254.GA65823@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 08:03:03 -0000 Hi, here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I have finish now a complete review of the document. The most important bug I spotted is likely that section 9.4.6 is empty. /js * p126 OLD Some types have a lexical representation that depends on the XML context in which they occur. These types do not have a canonical form. NEW Some types have a lexical representation that depends on the encoding, e.g., the XML context in which they occur. These types do not have a canonical form. Well, it turns out that there are XML encoding specifics in several of the following sections. Perhaps instead stated upfront that the section 9 describes the types and they XML encoding and noting that other encodings may use different rules. Perhaps also stating that the canonical representation is also used for constraint evaluation purposes. OLD When a NETCONF server sends data, it MUST be in the canonical form. NEW When a server sends data encoded in XML, it MUST use the canonical form defined in this section. Other encodings may introduce alternate representations. Note, however, that values in the data tree are conceptually stored in the canonical representation as defined in this section. In particular, any XPath expression evaluations are done using the canonical form. * p127 s/XML instance documents/XML encoding/ * p131 s/XML instance documents/XML encoding/ * p132 The section 9.4.6 (modifier statement) is empty and needs to be filled in. * p137 Y25-02 says: Keep the auto-numbering procedure for enums and bits and add an explicit warning that inserting enum or bits definitions or reordering enum or bits definitions violates section 10 and causes interoperability problems unless explicit value assignments are used. Has this been implemented? I did not find such a statement. * p139 s/A binary can/A binary type can/ * p139 s/are encoded/are encoded in XML/ * p141 s/is encoded/is encoded in XML/ * p146 s/is encoded/is encoded in XML/ * p148 The text stating that a value is consecutively against each member type does not seem to be 100% true for the JSON mapping since JSON says the JSON type information is taken into account. So we either change the JSON specification or we rewrite this text in RFC 6020 to allow different member type selection styles by making this statement specific to the XML encoding: In the XML encoding, the value representing a union data type... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 01:13:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B750C1B3A52 for ; Tue, 13 Oct 2015 01:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLCMkCLXdpny for ; Tue, 13 Oct 2015 01:12:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A561B3981 for ; Tue, 13 Oct 2015 01:12:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4F0C3FDA for ; Tue, 13 Oct 2015 10:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id flRDXg5ozimM for ; Tue, 13 Oct 2015 10:12:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 13 Oct 2015 10:12:54 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F6822004E for ; Tue, 13 Oct 2015 10:12:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id S9GPoDOJHwRs; Tue, 13 Oct 2015 10:12:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F44220053; Tue, 13 Oct 2015 10:12:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A93E37B1FD1; Tue, 13 Oct 2015 10:12:51 +0200 (CEST) Date: Tue, 13 Oct 2015 10:12:51 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20151013081249.GB65823@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] yang 1.1 status and next steps X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 08:12:58 -0000 Hi, the 1st WG last call has finished. There could have been more reviews but I understand that reading close to 200 pages is something that people find difficult to sign up for. Yesterday, we had a virtual interim meeting to go through issues that were raised. We have resolved several of them (see the issues marked VRFY in the meeting minutes). We try to resolve the others on the list until the I-D cutoff next Monday. The goal is to have a version by the cutoff time that addresses all comments raised during the 1st WG last call. Since the comments raised were minor, we will not do separate verification calls on each comment. Instead, WG members are expected to review minutes and to comment on the resolution once the next update of the YANG 1.1 I-D is out. Once the update of the YANG 1.1 is out (target next Monday), we will give people some time to review the edits while producing the document writeup. The goal is to hand YANG 1.1 over to Benoit before the NETMOD meeting in Yokohama. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 01:48:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71F61A1A9C for ; Tue, 13 Oct 2015 01:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpa2HaIL5Mlc for ; Tue, 13 Oct 2015 01:48:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697F81A1A9A for ; Tue, 13 Oct 2015 01:48:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 322F9FD4; Tue, 13 Oct 2015 10:48:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RmGT8Y3WYN2D; Tue, 13 Oct 2015 10:48:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 10:48:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BFE20054; Tue, 13 Oct 2015 10:48:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dQopxXJ1W2cz; Tue, 13 Oct 2015 10:48:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9212420053; Tue, 13 Oct 2015 10:48:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 893C937B2181; Tue, 13 Oct 2015 10:48:14 +0200 (CEST) Date: Tue, 13 Oct 2015 10:48:14 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151013084814.GA66064@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5614323D.5000507@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 08:48:21 -0000 On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: > Hi Juergen, > > On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > >On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: > >>Hi Kent, > >> > >>Feeding in the various input, I think that this is the best refinement > >>that I've come up with: > >> > >>Synchronous configuration operation - A configuration request to update > >>the running configuration of a server that is applied synchronously with > >>respect to the client request. The server SHOULD ensure that the > >>request is valid, and MUST fully effect the configuration change to all > >>impacted components in the server, updating both the server's intended > >>and applied configuration (see terms), before replying to the client. > >>The reply to the client indicates whether there are any errors in the > >>request or errors from applying the configuration change. > >What does "SHOULD ensure that the request is valid" mean? RFC 6020 > >says: > > > > When datastore processing is complete, the final contents MUST obey > > all validation constraints. This validation processing is performed > > at differing times according to the datastore. If the datastore is > > or , these constraints MUST be enforced at the > > end of the or operation. If the > > datastore is , the constraint enforcement is delayed > > until a or operation. > > > >Are we talking about datastore validation or validation of a request? > >If the former, are we watering down a MUST to a SHOULD? > Really it is datastore validation, particularly for an async request > where the intended config nodes are updated before replying. I'm not > intentionally trying to water down a MUST to a SHOULD, but Kent had > concerns that my previous description using "semantically validate" > would exclude an ephemeral datastore, so I was trying to water down the > description and also describe the behaviour in a way that isn't specific > to either RESTCONF/NETCONF or datastores. > > Perhaps, the start of sentence could simply be changed to: > > The server MUST fully effect the configuration change to all > impacted components in the server ... > > And equivalently for the asynchronous case below: > > The server MUST update the server's intended configuration ... > Works for me. Sometimes less is more. > >And I would not be surprised if we also need this sooner or later: > > > > Mixed configuration server - a configuration server that processes > > some configuration operations as synchronous configuration > > operations and some configuration operations as asynchronous > > configuration operations. > Yes, I would expect that clients may want to define the expected > behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. > >>Any further comments? > >> > >>Based on the feedback from Andy and others, it seems that the prevailing > >>view is that existing NETCONF and RESTCONF should be regarded as being > >>asynchronous in their behaviour in that the config nodes in the running > >>datastore only represent the intended configuration and not the applied > >>configuration. > >Depends on the definition of applied configuration - where is the latest > >version of it? > The last proposed text for intended/applied is as below: > > intended configuration - this data represents the configuration > state that the network operator intends the system to be in, and > that > has been accepted by the system as valid configuration. This > data is > colloquially referred to as the 'configuration' of the system. > > applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. > From Thursday's interim meeting, Rob Shakir clarified that the desired > intention is that applied configuration should mean that the > configuration is fully applied everywhere. I don't know if that means > that the definition of applied configuration should be strengthened, or > if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 01:51:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA41A1ADD for ; Tue, 13 Oct 2015 01:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G29DvSDPP2n9 for ; Tue, 13 Oct 2015 01:51:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D431A1ADF for ; Tue, 13 Oct 2015 01:51:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7479EFD4; Tue, 13 Oct 2015 10:51:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UytTQvCrdqmg; Tue, 13 Oct 2015 10:51:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 10:51:54 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4857420053; Tue, 13 Oct 2015 10:51:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id haL0KdziU9uJ; Tue, 13 Oct 2015 10:51:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 108E82004E; Tue, 13 Oct 2015 10:51:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06CE537B21AC; Tue, 13 Oct 2015 10:51:52 +0200 (CEST) Date: Tue, 13 Oct 2015 10:51:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151013085152.GB66064@elstar.local> Mail-Followup-To: Andy Bierman , Robert Wilton , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 08:51:58 -0000 On Tue, Oct 06, 2015 at 02:25:32PM -0700, Andy Bierman wrote: > >> What does "SHOULD ensure that the request is valid" mean? RFC 6020 > >> says: > >> > >> When datastore processing is complete, the final contents MUST obey > >> all validation constraints. This validation processing is performed > >> at differing times according to the datastore. If the datastore is > >> or , these constraints MUST be enforced at the > >> end of the or operation. If the > >> datastore is , the constraint enforcement is delayed > >> until a or operation. > >> > >> Are we talking about datastore validation or validation of a request? > >> If the former, are we watering down a MUST to a SHOULD? > >> > > Really it is datastore validation, particularly for an async request where > > the intended config nodes are updated before replying. I'm not > > intentionally trying to water down a MUST to a SHOULD, but Kent had > > concerns that my previous description using "semantically validate" would > > exclude an ephemeral datastore, so I was trying to water down the > > description and also describe the behaviour in a way that isn't specific to > > either RESTCONF/NETCONF or datastores. > > I have been thinking about I2RS validation, and it there might be good > reasons to say SHOULD instead of MUST (wrt/ ephemeral datastore anyway). Ephemeral config is a different dimension that is yet to be worked out. That said, RFC 6020 is quite clear what is expected from a configuration datastore in terms of validation and we should not change that. > The server instrumentation can do a better job than the server at > deciding how to prune bad config. It may be much faster to have the > server do syntax validation but not YANG constraint validation. The > instrumentation examines the ephemeral datastore to apply what it > can. The rest gets ignored. This may be too sloppy for standards, > but I2RS is supposed to be fast. Again, this is an ephemeral state issue. Do we bundle ephemeral state into the open config discussion? I guess we need to do this but then we also have a more complex set of players in this discussion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 02:45:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8621A87AF for ; Tue, 13 Oct 2015 02:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xv6oJOMHdxc for ; Tue, 13 Oct 2015 02:45:33 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE61A87BE for ; Tue, 13 Oct 2015 02:45:32 -0700 (PDT) Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id 722731CC0096; Tue, 13 Oct 2015 11:45:34 +0200 (CEST) From: Ladislav Lhotka To: David Reid , netmod@ietf.org In-Reply-To: <201510092109.t99L9URf067463@mainfs.snmp.com> References: <201510092109.t99L9URf067463@mainfs.snmp.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 13 Oct 2015 11:45:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 09:45:35 -0000 David Reid writes: > section 6.3.1 states: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 14), > the entire unknown-statement MAY be ignored by the compiler. > > If a YANG parser does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 14), > the entire unknown-statement MAY be ignored by the parser. Note Implications of this statement are still not clear to me. Let's say some protocol introduces an extension that is critical for that protocol. Does the above sentence mean that an implementation of that protocol MAY ignore the extension if it happens to use a parser that doesn't support it? Lada > that even in this case the semantics associated with the extension > still apply (as if they were part of a description statement). > > I assume the repetitive wording is not intentional. > > -David Reid > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 03:01:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4651A0032 for ; Tue, 13 Oct 2015 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5-DoZTF9cUL for ; Tue, 13 Oct 2015 03:01:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC411A0027 for ; Tue, 13 Oct 2015 03:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2891; q=dns/txt; s=iport; t=1444730487; x=1445940087; h=to:from:subject:message-id:date:mime-version; bh=2lL1jRzt4WSFj+5VMPikmZtCBsldXLRs8QbcL8FfuyA=; b=MNphwsnEunOr2gPfmbPvruGh0LiI+e/NGOPQD+o8Cys+/OkM3APkKZJ8 E45nAkTgz4tSIJXE2us9iHGLV8/vL9TjNdneEhHL84BK0FnUX11Z5ov0t 3rspXeLHgNUrpnq9N0zr+HhWkn6COC2JMPjmsQfytstdxAVKg2AFNdeQ9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBgBj1RxW/xbLJq1dvlWGCoMTggqDCwEBAQEBAYEAC4RQVSAdFgsCCwMCAQIBSw0IAQGIKp0Pj3GTWwEBCAEBAQEehnWMe4FFBZYWjRqJE5J1Y4QDPYckAQEB X-IronPort-AV: E=Sophos;i="5.17,677,1437436800"; d="scan'208,217";a="605703942" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2015 10:01:25 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9DA1Pvn007949 for ; Tue, 13 Oct 2015 10:01:25 GMT To: "netmod@ietf.org" From: Robert Wilton Message-ID: <561CD668.6050401@cisco.com> Date: Tue, 13 Oct 2015 11:01:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070202040802020107070001" Archived-At: Subject: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:01:29 -0000 This is a multi-part message in MIME format. --------------070202040802020107070001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I was looking the Yang 1.1 ABNF Grammar, and noticed various places where the rules are specified as the directive "a string that matches the rule XXX", e.g. yang-version-arg-str = < a string that matches the rule yang-version-arg > yang-version-arg = "1" It was slightly unclear to me exactly what is meant by this. Am I right in understanding that the only valid text that would match yang-version-arg-str would be the 3 character sequence *"1"*, or is it more nuanced that this? I.e. I presume that there is a good reason why these rules aren't just specified as the following: yang-version-arg-str = DQUOTE yang-version-arg DQUOTE Thanks, Rob --------------070202040802020107070001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I was looking the Yang 1.1 ABNF Grammar, and noticed various places where the rules are specified as the directive "a string that matches the rule XXX", e.g. 

   yang-version-arg-str = < a string that matches the rule
                           yang-version-arg >

   yang-version-arg    = "1"

It was slightly unclear to me exactly what is meant by this.

Am I right in understanding that the only valid text that would match yang-version-arg-str would be the 3 character sequence "1", or is it more nuanced that this?

I.e. I presume that there is a good reason why these rules aren't just specified as the following:
  
yang-version-arg-str = DQUOTE yang-version-arg DQUOTE

Thanks,
Rob

--------------070202040802020107070001-- From nobody Tue Oct 13 03:09:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6631A21AD for ; Tue, 13 Oct 2015 03:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4sbyWZDXhag for ; Tue, 13 Oct 2015 03:08:58 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E4A931A1BE6 for ; Tue, 13 Oct 2015 03:07:14 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 5FB52C4175DA; Tue, 13 Oct 2015 12:07:13 +0200 (CEST) To: Robert Wilton , "netmod@ietf.org" References: <561CD668.6050401@cisco.com> From: Jernej Tuljak Message-ID: <561CD7D0.9040008@mg-soft.si> Date: Tue, 13 Oct 2015 12:07:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561CD668.6050401@cisco.com> Content-Type: multipart/alternative; boundary="------------000603090905010503020306" Archived-At: Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:09:03 -0000 This is a multi-part message in MIME format. --------------000603090905010503020306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Robert Wilton je 13.10.2015 ob 12:01 napisal: > Hi, > > I was looking the Yang 1.1 ABNF Grammar, and noticed various places > where the rules are specified as the directive "a string that matches > the rule XXX", e.g. > > yang-version-arg-str = < a string that matches the rule > yang-version-arg > > > yang-version-arg = "1" > > It was slightly unclear to me exactly what is meant by this. > > Am I right in understanding that the only valid text that would match > yang-version-arg-str would be the 3 character sequence *"1"*, or is it > more nuanced that this? > > I.e. I presume that there is a good reason why these rules aren't just > specified as the following: > > yang-version-arg-str = DQUOTE yang-version-arg DQUOTE The reason are probably YANG quotation rules. The "string that matches" is a dequoted string without any "+" or quotes, so the grammar rules don't have to handle those explicitly. Jernej > > Thanks, > Rob > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000603090905010503020306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Robert Wilton je 13.10.2015 ob 12:01 napisal:
Hi,

I was looking the Yang 1.1 ABNF Grammar, and noticed various places where the rules are specified as the directive "a string that matches the rule XXX", e.g. 

   yang-version-arg-str = < a string that matches the rule
                           yang-version-arg >

   yang-version-arg    = "1"

It was slightly unclear to me exactly what is meant by this.

Am I right in understanding that the only valid text that would match yang-version-arg-str would be the 3 character sequence "1", or is it more nuanced that this?

I.e. I presume that there is a good reason why these rules aren't just specified as the following:
  
yang-version-arg-str = DQUOTE yang-version-arg DQUOTE

The reason are probably YANG quotation rules. The "string that matches" is a dequoted string without any "+" or quotes, so the grammar rules don't have to handle those explicitly.

Jernej


Thanks,
Rob



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

--------------000603090905010503020306-- From nobody Tue Oct 13 03:17:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B801A1BE9 for ; Tue, 13 Oct 2015 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt8ghfiG7m61 for ; Tue, 13 Oct 2015 03:17:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 839081A1BDC for ; Tue, 13 Oct 2015 03:17:52 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BFE01AE0478; Tue, 13 Oct 2015 12:17:50 +0200 (CEST) Date: Tue, 13 Oct 2015 12:17:49 +0200 (CEST) Message-Id: <20151013.121749.1289164634073433213.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <561CD668.6050401@cisco.com> References: <561CD668.6050401@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:17:53 -0000 Robert Wilton wrote: > Hi, > > I was looking the Yang 1.1 ABNF Grammar, and noticed various places > where the rules are specified as the directive "a string that matches > the rule XXX", e.g. > > yang-version-arg-str = < a string that matches the rule > yang-version-arg > > > yang-version-arg = "1" > > > It was slightly unclear to me exactly what is meant by this. > > Am I right in understanding that the only valid text that would match > yang-version-arg-str would be the 3 character sequence *"1"* No. > or is it > more nuanced that this? Yes. First of all the abnf-rule yang-version-arg = "1" matches a single character 1 (not three characters). Next, YANG has a very regular syntax that all statements follow: statement = keyword [argument] (";" / "{" *statement "}") The argument in this rule is a string. A string in YANG can be specified in several ways: unqouted, e.g.: foo quoted, e.g.: 'foo' or "foo" concatenated, e.g: "f" + "oo" This cannot be expressed directly in ABNF. So when the YANG grammar says "a string that matches the rule..." it means that the "expanded" string matches the rule. So e.g., this is all legal: config false; config "false"; config 'f' + "alse"; /martin From nobody Tue Oct 13 03:18:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FE41A1C06 for ; Tue, 13 Oct 2015 03:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIweY-0POYeS for ; Tue, 13 Oct 2015 03:17:54 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99221A1BDC for ; Tue, 13 Oct 2015 03:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5141; q=dns/txt; s=iport; t=1444731474; x=1445941074; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=9HhXfGx6/jUfJP5venxu1UUheVjjypdBLVw2sQkYNW8=; b=Dwun0E1zq09U93cyZkGQhHnPmLUuhJiNAzRPHliWUsYu0FVjlpUw/AD7 Hd9ZSEO7fMHFoCmXW57kQ0Qthf9J9nX01LiMMk5mJngNS8OQqY5WSTpMd fE3AZEMaoLBhoU94FB49OQxgkiXVSoGmVNbznL9MHjNgc1bDgQ+XcT4Ie U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiBgB52RxW/xbLJq1dg3puv3cXAQmCcoIKNUoCgXoRAQEBAQEBAYEKhCcBAQQBAQFrCgEQCxgJFg8JAwIBAgEVMAYNBgIBAYgqDcBUAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZ1hH6FDQeELgWWFo0aiROSdTcshAM9M4ZxAQEB X-IronPort-AV: E=Sophos;i="5.17,677,1437436800"; d="scan'208,217";a="612186487" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Oct 2015 10:17:51 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9DAHptm017421; Tue, 13 Oct 2015 10:17:51 GMT To: Jernej Tuljak References: <561CD668.6050401@cisco.com> <561CD7D0.9040008@mg-soft.si> From: Robert Wilton Message-ID: <561CDA42.5090305@cisco.com> Date: Tue, 13 Oct 2015 11:17:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561CD7D0.9040008@mg-soft.si> Content-Type: multipart/alternative; boundary="------------070805040504080109070500" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:17:56 -0000 This is a multi-part message in MIME format. --------------070805040504080109070500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Jernej, Thanks for the explanation, that along with looking at section 6.1.2/6.1.3 makes this clear. Cheers, Rob On 13/10/2015 11:07, Jernej Tuljak wrote: > Robert Wilton je 13.10.2015 ob 12:01 napisal: >> Hi, >> >> I was looking the Yang 1.1 ABNF Grammar, and noticed various places >> where the rules are specified as the directive "a string that matches >> the rule XXX", e.g. >> >> yang-version-arg-str = < a string that matches the rule >> yang-version-arg > >> >> yang-version-arg = "1" >> >> It was slightly unclear to me exactly what is meant by this. >> >> Am I right in understanding that the only valid text that would match >> yang-version-arg-str would be the 3 character sequence *"1"*, or is >> it more nuanced that this? >> >> I.e. I presume that there is a good reason why these rules aren't >> just specified as the following: >> >> yang-version-arg-str = DQUOTE yang-version-arg DQUOTE > > The reason are probably YANG quotation rules. The "string that > matches" is a dequoted string without any "+" or quotes, so the > grammar rules don't have to handle those explicitly. > > Jernej > >> >> Thanks, >> Rob >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > --------------070805040504080109070500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Jernej,

Thanks for the explanation, that along with looking at section 6.1.2/6.1.3 makes this clear.

Cheers,
Rob


On 13/10/2015 11:07, Jernej Tuljak wrote:
Robert Wilton je 13.10.2015 ob 12:01 napisal:
Hi,

I was looking the Yang 1.1 ABNF Grammar, and noticed various places where the rules are specified as the directive "a string that matches the rule XXX", e.g. 

   yang-version-arg-str = < a string that matches the rule
                           yang-version-arg >

   yang-version-arg    = "1"

It was slightly unclear to me exactly what is meant by this.

Am I right in understanding that the only valid text that would match yang-version-arg-str would be the 3 character sequence "1", or is it more nuanced that this?

I.e. I presume that there is a good reason why these rules aren't just specified as the following:
  
yang-version-arg-str = DQUOTE yang-version-arg DQUOTE

The reason are probably YANG quotation rules. The "string that matches" is a dequoted string without any "+" or quotes, so the grammar rules don't have to handle those explicitly.

Jernej


Thanks,
Rob



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


--------------070805040504080109070500-- From nobody Tue Oct 13 03:19:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FDF1A1BE9 for ; Tue, 13 Oct 2015 03:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaXkSVYhKoCL for ; Tue, 13 Oct 2015 03:19:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8750F1A1BDC for ; Tue, 13 Oct 2015 03:19:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 54D9E93B; Tue, 13 Oct 2015 12:19:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s1OdlIN3_m8g; Tue, 13 Oct 2015 12:19:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 12:19:39 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6774720053; Tue, 13 Oct 2015 12:19:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eVaDXG7Toh4q; Tue, 13 Oct 2015 12:19:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 625C22004E; Tue, 13 Oct 2015 12:19:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2D43C37B2311; Tue, 13 Oct 2015 12:19:35 +0200 (CEST) Date: Tue, 13 Oct 2015 12:19:35 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151013101935.GA66308@elstar.local> Mail-Followup-To: Ladislav Lhotka , David Reid , netmod@ietf.org References: <201510092109.t99L9URf067463@mainfs.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:19:43 -0000 On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > David Reid writes: > > > section 6.3.1 states: > > > > If a YANG compiler does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 14), > > the entire unknown-statement MAY be ignored by the compiler. > > > > If a YANG parser does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 14), > > the entire unknown-statement MAY be ignored by the parser. Note > > Implications of this statement are still not clear to me. Let's say some > protocol introduces an extension that is critical for that > protocol. Does the above sentence mean that an implementation of that > protocol MAY ignore the extension if it happens to use a parser that > doesn't support it? > > Lada > > > that even in this case the semantics associated with the extension > > still apply (as if they were part of a description statement). > > Did you read the following sentence: [...] Note that even in this case the semantics associated with the extension still apply (as if they were part of a description statement). I think it answers your question with a 'no'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 03:28:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1870F1A6EDE for ; Tue, 13 Oct 2015 03:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGcpHgMMja7j for ; Tue, 13 Oct 2015 03:28:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 998681A6EDB for ; Tue, 13 Oct 2015 03:28:41 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A0EB1AE0478; Tue, 13 Oct 2015 12:28:40 +0200 (CEST) Date: Tue, 13 Oct 2015 12:28:39 +0200 (CEST) Message-Id: <20151013.122839.1096197054234709257.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151013101935.GA66308@elstar.local> References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:28:43 -0000 Juergen Schoenwaelder wrote: > On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > > David Reid writes: > > > > > section 6.3.1 states: > > > > > > If a YANG compiler does not support a particular extension, which > > > appears in a YANG module as an unknown-statement (see Section 14), > > > the entire unknown-statement MAY be ignored by the compiler. > > > > > > If a YANG parser does not support a particular extension, which > > > appears in a YANG module as an unknown-statement (see Section 14), > > > the entire unknown-statement MAY be ignored by the parser. Note > > > > Implications of this statement are still not clear to me. Let's say some > > protocol introduces an extension that is critical for that > > protocol. Does the above sentence mean that an implementation of that > > protocol MAY ignore the extension if it happens to use a parser that > > doesn't support it? > > > > Lada > > > > > that even in this case the semantics associated with the extension > > > still apply (as if they were part of a description statement). > > > > > Did you read the following sentence: > > [...] Note that > even in this case the semantics associated with the extension still > apply (as if they were part of a description statement). But also note that the semantics associated with the extension can define a protocol negotiation mechanism that triggers the protocol behavior only when both peers agree it should be triggered. /martin > I think it answers your question with a 'no'. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Oct 13 03:31:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6451A88BF for ; Tue, 13 Oct 2015 03:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zcr6RYb468Y for ; Tue, 13 Oct 2015 03:31:01 -0700 (PDT) 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 E237C1A1BDA for ; Tue, 13 Oct 2015 03:31:00 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840] (unknown [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840]) by mail.nic.cz (Postfix) with ESMTPSA id 3DFFF18135B; Tue, 13 Oct 2015 12:30:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444732259; bh=JuOFWxIaUJv5ldt3/2Y7wdRKS0HPnbyHxgDV45jz5U4=; h=From:Date:To; b=Kuf4qEcm7sK8AVHvZ4YZ3r0LiYh3OHufje8XAhiEJEOaJGw9umwG1wtVgZm79YFXr 3pblzeaKIbAdSelCr7ZW+alRImDNEkSdAIJSCNWb+SVn8Il90Qp0iZQZz7akMKk8us /PQo4s5DOhfAfrP0cyM6+e1TXJfzJ4Bd2d0+0VwU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151013101935.GA66308@elstar.local> Date: Tue, 13 Oct 2015 12:30:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:31:02 -0000 > On 13 Oct 2015, at 12:19, Juergen Schoenwaelder = wrote: >=20 > On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: >> David Reid writes: >>=20 >>> section 6.3.1 states: >>>=20 >>> If a YANG compiler does not support a particular extension, which =20= >>> appears in a YANG module as an unknown-statement (see Section 14), >>> the entire unknown-statement MAY be ignored by the compiler. >>>=20 >>> If a YANG parser does not support a particular extension, which >>> appears in a YANG module as an unknown-statement (see Section 14), >>> the entire unknown-statement MAY be ignored by the parser. Note >>=20 >> Implications of this statement are still not clear to me. Let's say = some >> protocol introduces an extension that is critical for that >> protocol. Does the above sentence mean that an implementation of that >> protocol MAY ignore the extension if it happens to use a parser that >> doesn't support it? >>=20 >> Lada >>=20 >>> that even in this case the semantics associated with the extension >>> still apply (as if they were part of a description statement). >>>=20 >=20 > Did you read the following sentence: >=20 > [...] Note that > even in this case the semantics associated with the extension still > apply (as if they were part of a description statement). Well, if the parser ignores the extension statement, then the = application has no way to find out that the extension is present to be = able to apply its semantics. > I think it answers your question with a 'no'. Specifying behaviour of a YANG parser using 2119 keywords YANG parser = doesn't make much sense to me, because it all depends on the purpose of = the application that uses the parser. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 03:42:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94D71A9102 for ; Tue, 13 Oct 2015 03:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdVaUTEfkIax for ; Tue, 13 Oct 2015 03:42:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388E61A908E for ; Tue, 13 Oct 2015 03:42:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 03B58FDA; Tue, 13 Oct 2015 12:42:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id agtXhPq01y-X; Tue, 13 Oct 2015 12:42:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 12:42:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E645F20053; Tue, 13 Oct 2015 12:42:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2ssv9vyhog60; Tue, 13 Oct 2015 12:42:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B88852004E; Tue, 13 Oct 2015 12:42:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B273D37B2574; Tue, 13 Oct 2015 12:42:46 +0200 (CEST) Date: Tue, 13 Oct 2015 12:42:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151013104246.GC66442@elstar.local> Mail-Followup-To: Ladislav Lhotka , David Reid , netmod@ietf.org References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:42:51 -0000 On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > > > On 13 Oct 2015, at 12:19, Juergen Schoenwaelder wrote: > > > > On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > >> David Reid writes: > >> > >>> section 6.3.1 states: > >>> > >>> If a YANG compiler does not support a particular extension, which > >>> appears in a YANG module as an unknown-statement (see Section 14), > >>> the entire unknown-statement MAY be ignored by the compiler. > >>> > >>> If a YANG parser does not support a particular extension, which > >>> appears in a YANG module as an unknown-statement (see Section 14), > >>> the entire unknown-statement MAY be ignored by the parser. Note > >> > >> Implications of this statement are still not clear to me. Let's say some > >> protocol introduces an extension that is critical for that > >> protocol. Does the above sentence mean that an implementation of that > >> protocol MAY ignore the extension if it happens to use a parser that > >> doesn't support it? > >> > >> Lada > >> > >>> that even in this case the semantics associated with the extension > >>> still apply (as if they were part of a description statement). > >>> > > > > Did you read the following sentence: > > > > [...] Note that > > even in this case the semantics associated with the extension still > > apply (as if they were part of a description statement). > > Well, if the parser ignores the extension statement, then the application has no way to find out that the extension is present to be able to apply its semantics. > Description statements have always to be taken into account. > > I think it answers your question with a 'no'. > > Specifying behaviour of a YANG parser using 2119 keywords YANG parser doesn't make much sense to me, because it all depends on the purpose of the application that uses the parser. > I do not get your point. The text says a parser may skip over an extension it does not know how to process and it says the semantics still apply as if they were part of a description statement. What is the problem with this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 04:01:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAC91A9170 for ; Tue, 13 Oct 2015 04:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHudGGU9ahIg for ; Tue, 13 Oct 2015 04:01:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43CF1A916C for ; Tue, 13 Oct 2015 04:01:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8C47F56; Tue, 13 Oct 2015 13:01:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DqkAGZDp35v3; Tue, 13 Oct 2015 13:01:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 13:01:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1776920078; Tue, 13 Oct 2015 13:01:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JX8D8S4_mxHB; Tue, 13 Oct 2015 13:01:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A97520062; Tue, 13 Oct 2015 13:01:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BEDF237B25A8; Tue, 13 Oct 2015 13:01:00 +0200 (CEST) Date: Tue, 13 Oct 2015 13:01:00 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20151013110100.GD66442@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 11:01:35 -0000 On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote: > > This is a notice to start a NETMOD WG last call for the document: > > Defining and Using Metadata with YANG > http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 > > Please indicate your support by Thursday October 22, 2015 at 9PM EDT. > We are not only interested in receiving defect reports, we are equally > interested in statements of the form: > I am concerned about this text: Annotations modify the schema of datastores and/or management protocol messages, and may also change their semantics. Therefore, due care has to be exercised when introducing annotations in network management systems in order to avoid interoperability problems and software failures. I think we should actually very clearly discourage annotations that modify the schema of datastores and/or management protocol messages instead of assuming all annotations are free to do so. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 05:25:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED671B2FD4 for ; Tue, 13 Oct 2015 05:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTiE_Cfvy9RX for ; Tue, 13 Oct 2015 05:25:31 -0700 (PDT) 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 CF20A1B2FC7 for ; Tue, 13 Oct 2015 05:25:30 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-92-561cf838537d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 05.25.05274.838FC165; Tue, 13 Oct 2015 14:25:28 +0200 (CEST) Received: from [159.107.197.236] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Tue, 13 Oct 2015 14:25:28 +0200 To: Martin Bjorklund , "netmod@ietf.org" References: <561CEA2C.4030600@ericsson.com> <20151013.133037.916630538697038960.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <561CF838.3090308@ericsson.com> Date: Tue, 13 Oct 2015 14:25:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013.133037.916630538697038960.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvja7FD5kwgyMPTCy6u5+xW8y/2Mjq wOSxZMlPJo+NvxazBDBFcdmkpOZklqUW6dslcGWcPdzCWnCdveL/jy62BsbbrF2MnBwSAiYS Ny5+h7LFJC7cW8/WxcjFISRwlFFiefdSJghnLaPEq3nLwaqEBbQkzi+eB2aLCHhJdN6/wAhi CwkkSsy+twwsziZgJDG1/zxLFyMHB6+AtsSGDwIgJouAqsSKBj+QClGBGIn3m1aBdfIKCEqc nPmEBcTmFHCQWHjgOitIObOAvcSDrWUgYWYBeYntb+cwQyzSkHh44S/rBEaBWUi6ZyF0zELS sYCReRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYEAe3PJbdQfj5TeOhxgFOBiVeHgXpMqE CbEmlhVX5h5ilOZgURLnbWZ6ECokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMd9ZiXPZpBle C+9YlK73EJ57Tyd190P/JKH2mboTDxcta7T5b1h1t/FFkelKgV9TZV6t+Zadxhlt8mH/38u8 9/2/Ju4729XsfeiUfc7rG/wzlhqvM5z6J0m981fSgTp+v8Xf9qkdXnZt56qbFXWLZeULDn5f xDLn7qV5Ymd+b2q+XL+IbbGi8AwlluKMREMt5qLiRABR7NDQKQIAAA== Archived-At: Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 12:25:34 -0000 Hello Martin, I agree that A1 is what follows the spirit of YANG, but then IMHO you should change/correct 8.2.1 in YANG because that implies A2 and error. regards Balazs On 2015-10-13 13:30, Martin Bjorklund wrote: > Balazs Lengyel wrote: >> Hello Martin, >> If I had a model >> >> leaf a {type boolean;} >> leaf b { >> when a >> type int8; >> } >> >> if "a" is false and then you get an edit config with: set b=5 ; set a=true >> What should be the result? >> A1) this should succeed as at commit time the "when" will be true. > yes. > >> A2) this should fail as at parsing (as described in 8.2.1 of the YANG >> RFC) the when is false - yet. This would also mean that you need 2 >> edit-configs to set b=5. >> regards Balazs > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Oct 13 05:40:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73961B3005 for ; Tue, 13 Oct 2015 05:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV913EzNz2nv for ; Tue, 13 Oct 2015 05:40:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4E781B3001 for ; Tue, 13 Oct 2015 05:40:08 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 254421AE0478 for ; Tue, 13 Oct 2015 14:40:07 +0200 (CEST) Date: Tue, 13 Oct 2015 14:40:06 +0200 (CEST) Message-Id: <20151013.144006.150295709503416602.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 12:40:10 -0000 Hi, As discussed in the meeting yesterday, here is the proposed text to cover the when context node and accessible tree issue: Changed text in 7.25.1: The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o If the "when" statement is a child of an "augment" statement, the= n the context node is the augment's target node in the data tree, i= f the target node is a data node. Otherwise, the context node is the closest ancestor node to the target node that is also a data node. If no such node exists, the context node is the root node.= The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the= nodes added by the "augment" statement. o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node. If no such node exists, the context node is the root node.= The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the= nodes added by the "uses", "choice", or "case" statement. o If the "when" statement is a child of any other data definition statement, the accessible tree is tentatively altered during the processing of the XPath expression by replacing all instances of the data node for which the "when" statement is defined with a single dummy node with the same name, but with no value and no children. If no such instance exists, the dummy node is tentatively created. The context node is this dummy node. /martin Ladislav Lhotka wrote: > Randy Presuhn writes: > = > > Hi - > > > >>From: Martin Bjorklund > >>Sent: Sep 28, 2015 3:15 AM > >>To: jernejt@mg-soft.si > >>Cc: netmod@ietf.org > >>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.t= xt > > ... > >>Ok; the intention was "replace if it exists, and create otherwise" > >>(i.e., "replace" as in NETCONF edit operation). We can make this > >>explicit: > >> > >>NEW: > >> > >>- If the "when" statement is a child of any other data definition > >> statement, the accessible tree is tentatively altered during the > >> processing of the XPath expression by replacing all instances of = the > >> data node for which the "when" statement is defined with a single= > >> dummy node with the same name, but with no value and no children.= > >> If no instances of the data node exists, the dummy node is create= d. > >> The context node is this dummy node. > > > > A standard should avoid prescribing a specific implementation > > strategy, and should instead limit itself to describing what > > the observable behaviours of the relevant interfaces must be. > = > "when" statement relies on XPath but in some situations context for > XPath evaluation is not properly defined. The proposed solution to > Issue=A0Y18 tries to alleviate this problem by defining tentative > manipulations to XML infoset that provide the necessary context. > = > I am not particularly happy with this solution but still it is IMO > better than hand-waving. I think "when" statement is a problematic > inovation over standard XML schema languages because it defies > grammar-based validation. > = > Lada > = > > > > Randy > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = > -- = > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Oct 13 05:40:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AD61A6FE2 for ; Tue, 13 Oct 2015 05:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC8huCnJTFm6 for ; Tue, 13 Oct 2015 05:40:52 -0700 (PDT) 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 F32D91B3006 for ; Tue, 13 Oct 2015 05:40:51 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840] (unknown [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840]) by mail.nic.cz (Postfix) with ESMTPSA id 98C7D1816EC; Tue, 13 Oct 2015 14:40:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444740050; bh=ukQGkpqwgb2RwlNJzkbQt3Q/HvbXhdpggWsCK+hV2nI=; h=From:Date:To; b=raImtBvZeYTE/bYvdSb/0pTfwOC3wcm95+Z44/PrU3Zi4eYhS9bBVq/41c82MHJ6s fYEu0i5VR2sl1Kdbl77Vx0pAa7gKqAWQpYci8JuDE8xBUbtnCz8tQ1Wc1rGTx107ku eCrjWW5gVUZNyckaLN2Qrlz46GoT7z30+dz80U0o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151013104246.GC66442@elstar.local> Date: Tue, 13 Oct 2015 14:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 12:40:58 -0000 > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder = wrote: >=20 > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: >>>> David Reid writes: >>>>=20 >>>>> section 6.3.1 states: >>>>>=20 >>>>> If a YANG compiler does not support a particular extension, which = =20 >>>>> appears in a YANG module as an unknown-statement (see Section = 14), >>>>> the entire unknown-statement MAY be ignored by the compiler. >>>>>=20 >>>>> If a YANG parser does not support a particular extension, which >>>>> appears in a YANG module as an unknown-statement (see Section = 14), >>>>> the entire unknown-statement MAY be ignored by the parser. Note >>>>=20 >>>> Implications of this statement are still not clear to me. Let's say = some >>>> protocol introduces an extension that is critical for that >>>> protocol. Does the above sentence mean that an implementation of = that >>>> protocol MAY ignore the extension if it happens to use a parser = that >>>> doesn't support it? >>>>=20 >>>> Lada >>>>=20 >>>>> that even in this case the semantics associated with the = extension >>>>> still apply (as if they were part of a description statement). >>>>>=20 >>>=20 >>> Did you read the following sentence: >>>=20 >>> [...] Note that >>> even in this case the semantics associated with the extension still >>> apply (as if they were part of a description statement). >>=20 >> Well, if the parser ignores the extension statement, then the = application has no way to find out that the extension is present to be = able to apply its semantics. >>=20 >=20 > Description statements have always to be taken into account. This is a different thing. Such a description would be a substatement to = the "extension" (built-in) statement that defines the extension. In = order to apply the semantics in appropriate places, an application must = see where the extension statement is actually *used*. This is only = possible if the underlying parser provides this information.=20 >=20 >>> I think it answers your question with a 'no'. >>=20 >> Specifying behaviour of a YANG parser using 2119 keywords YANG parser = doesn't make much sense to me, because it all depends on the purpose of = the application that uses the parser. >>=20 >=20 > I do not get your point. The text says a parser may skip over an > extension it does not know how to process and it says the semantics > still apply as if they were part of a description statement. What > is the problem with this? If a protocol requires an extension to be honoured, then there is no = excuse for the parser to ignore it. But the sentence I am objecting to = says "MAY ignore" without any qualification. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 06:00:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE141A802A for ; Tue, 13 Oct 2015 06:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYcDUIxtfyBR for ; Tue, 13 Oct 2015 06:00:15 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2441A7D82 for ; Tue, 13 Oct 2015 06:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8553; q=dns/txt; s=iport; t=1444741215; x=1445950815; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=XI1xic04t8/2QwDksGWdVrCYZv/DrqDk0ZD6ybWC+9A=; b=BRE1rkvZIRQLu2726SDvmJAw4tiTj5OaIKwcsTzN8QoGIqUHD3Tcm9J9 7LrwzAsKpsVB/m73F67dnIgxhI1PgmQNwXArnnCb0dfkulPsDA2YPNVNG AcHtOiadE/sfVv0PTVZ2KLOe95d3u2smTs4wFGaiORXLk+5DQFbIQ4Lod Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBQD0/xxW/xbLJq1exGKDEzKBWH8CghABAQEBAQGBC4QmAQEBAwE4QBELDgoJFgQLCQMCAQIBRQYBDAgBAYgiCMETAQEBAQEBBAEBAQEBARyGdYN4gQaEQlKELgEEhzqHBYdXiAmFEYFYhzuKLYRZg29jghEdFoE/PYVdJYEiAQEB X-IronPort-AV: E=Sophos;i="5.17,678,1437436800"; d="scan'208";a="607584779" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Oct 2015 13:00:04 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9DD04pw004307; Tue, 13 Oct 2015 13:00:04 GMT To: Kent Watsen , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> From: Robert Wilton Message-ID: <561D0048.5070106@cisco.com> Date: Tue, 13 Oct 2015 13:59:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013084814.GA66064@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:00:17 -0000 Hi, On 13/10/2015 09:48, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> On 06/10/2015 17:16, Juergen Schoenwaelder wrote: >>> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: >>>> Hi Kent, >>>> >>>> Feeding in the various input, I think that this is the best refinement >>>> that I've come up with: >>>> >>>> Synchronous configuration operation - A configuration request to update >>>> the running configuration of a server that is applied synchronously with >>>> respect to the client request. The server SHOULD ensure that the >>>> request is valid, and MUST fully effect the configuration change to all >>>> impacted components in the server, updating both the server's intended >>>> and applied configuration (see terms), before replying to the client. >>>> The reply to the client indicates whether there are any errors in the >>>> request or errors from applying the configuration change. >>> What does "SHOULD ensure that the request is valid" mean? RFC 6020 >>> says: >>> >>> When datastore processing is complete, the final contents MUST obey >>> all validation constraints. This validation processing is performed >>> at differing times according to the datastore. If the datastore is >>> or , these constraints MUST be enforced at the >>> end of the or operation. If the >>> datastore is , the constraint enforcement is delayed >>> until a or operation. >>> >>> Are we talking about datastore validation or validation of a request? >>> If the former, are we watering down a MUST to a SHOULD? >> Really it is datastore validation, particularly for an async request >> where the intended config nodes are updated before replying. I'm not >> intentionally trying to water down a MUST to a SHOULD, but Kent had >> concerns that my previous description using "semantically validate" >> would exclude an ephemeral datastore, so I was trying to water down the >> description and also describe the behaviour in a way that isn't specific >> to either RESTCONF/NETCONF or datastores. >> >> Perhaps, the start of sentence could simply be changed to: >> >> The server MUST fully effect the configuration change to all >> impacted components in the server ... >> >> And equivalently for the asynchronous case below: >> >> The server MUST update the server's intended configuration ... >> > Works for me. Sometimes less is more. > >>> And I would not be surprised if we also need this sooner or later: >>> >>> Mixed configuration server - a configuration server that processes >>> some configuration operations as synchronous configuration >>> operations and some configuration operations as asynchronous >>> configuration operations. >> Yes, I would expect that clients may want to define the expected >> behaviour, potentially on a per request basis. > I doubt that servers will offer clients to choose; I am more with Andy > that in real systems, depending on the data model, certain parts of a > data model may be synchronous while others may be asynchronous. I think that the question regarding synchronous vs asynchronous is really about what a client can usefully do with that information. If a client knows that a request is synchronous then it doesn't have to poll or check whether the configuration has been applied. Unless it gets told in the reply that some configuration failed, it should be able to assume that all the configuration has been successfully applied and it can proceed to the next step (if any) in provisioning a service. If a client knows that a request is asynchronous then it has to poll (or rely on a notification) to determine when the configuration has been applied. If, when it polls, parts of the config are applied and parts of it are not then it might be able to continue with some provisioning tasks but have to wait before it can continue with other parts of the provisioning. If a server is a hybrid (where I define a hybrid server as one that replies somewhere between when a sync or async server would), then I would expect that a client would end up treating this the same as an asynchronous server. I.e. it would expect to query to find out which parts of the configuration are applied and which are not. But I agree that existing NC servers are potentially neither exactly synchronous or asynchronous in their behaviour and hence my trying to labelling them as such may be a mistake. Hence, perhaps it would be better to classify servers as one of sync, async, hybrid? > >>>> Any further comments? >>>> >>>> Based on the feedback from Andy and others, it seems that the prevailing >>>> view is that existing NETCONF and RESTCONF should be regarded as being >>>> asynchronous in their behaviour in that the config nodes in the running >>>> datastore only represent the intended configuration and not the applied >>>> configuration. >>> Depends on the definition of applied configuration - where is the latest >>> version of it? >> The last proposed text for intended/applied is as below: >> >> intended configuration - this data represents the configuration >> state that the network operator intends the system to be in, and >> that >> has been accepted by the system as valid configuration. This >> data is >> colloquially referred to as the 'configuration' of the system. >> >> applied configuration - this data represents the configuration >> state that the network element is actually in, i.e., the >> configuration state which is currently being being used by system >> components (e.g., control plane daemons, operating system >> kernels, line cards). > Well, sometimes the config goes to a control plane daemon and then to > the OS kernel and finally to the line cards. This definition leaves > some room what an applied configuration is (which is IMHO needed if > you want to have something implementable) and hence a NC server can > either be considered synchronous or asynchronous. Yes, I understand your concern about having something implementable, but equally I think that the operators want a definition that is strong enough that they can usefully use it. I also think that it is better to have a reasonably tight definition so that the implementers know what they should be aiming for, even if it isn't 100% achievable in all scenarios. If we provide a definition of a hybrid server (i.e. somewhere between sync and async) then we could still have a tight definition of applied config, but aren't forcing any change in semantics to existing NC/RC servers since we just define their behaviour as being somewhere between an async and sync response. > >> From Thursday's interim meeting, Rob Shakir clarified that the desired >> intention is that applied configuration should mean that the >> configuration is fully applied everywhere. I don't know if that means >> that the definition of applied configuration should be strengthened, or >> if it is sufficient? > As said before, an OS kernel usually does not track where resource > parameters were coming from. (An interface has a set of IP addresses > and the kernel usually does not know which addresses were coming from > a configuration daemon, a dhcp daemon, a tunneling daemon, a command > line utility, ...) The same may be true for line card. So in order to > implement a very tight definition, one has to either 'guess' which > 'subset' of operational state can be related 'somehow' to the intended > config and then report the result of the guess work as applied config > or one would have to to change daemons/kernels/linecards to have a > tracking number or something like that. Inferring the applied config state from the operation state is one way of doing this. An alternative way is for the NC/RC server to maintain separate internal state for intended vs applied cfg nodes. Then the NC/RC server would update the applied cfg node when the internal IPC to program that configuration had completed for all affected subsystems. > > Anyway, as long as a regular NC/RC server does not have to pay a price > for this applied config idea, I have no real problem with this since I > am sure the market will sort this out. Agreed. Rob > > /js > From nobody Tue Oct 13 06:09:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAF11AC44B for ; Tue, 13 Oct 2015 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l9p-X0ejxk2 for ; Tue, 13 Oct 2015 06:09:37 -0700 (PDT) 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 B619E1ACC8F for ; Tue, 13 Oct 2015 06:09:37 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840] (unknown [IPv6:2a01:5e0:29:ffff:fc32:4fbc:9e1d:4840]) by mail.nic.cz (Postfix) with ESMTPSA id 6793C1816CF; Tue, 13 Oct 2015 15:09:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444741775; bh=yEujhKFRUVGsvhbIwW6SPRVvUjzIJWYaRRMgb15Ij08=; h=From:Date:To; b=hz1nNQoaUZ/p68mD+pTcJ9sg4MY/R0nKrDoKcJtWtnBhOTyFIRdRsCfUG8qzTmaLD qfwOi9mRjHm2eaE7iLa1um6tPtCMSLTzKqP+yn8UI8hAFt7AvQ8+mqt34SQVMqQ70R ydQPC+XSY6yfA/LQQvODnTXwb8hOtvZcfAaLRot8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151013110100.GD66442@elstar.local> Date: Tue, 13 Oct 2015 15:09:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> References: <20151013110100.GD66442@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:09:40 -0000 > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder = wrote: >=20 > On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote: >>=20 >> This is a notice to start a NETMOD WG last call for the document: >>=20 >> Defining and Using Metadata with YANG >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 >>=20 >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT. >> We are not only interested in receiving defect reports, we are = equally >> interested in statements of the form: >>=20 >=20 > I am concerned about this text: >=20 > Annotations modify the schema of datastores and/or management > protocol messages, and may also change their semantics. Therefore, > due care has to be exercised when introducing annotations in > network management systems in order to avoid interoperability > problems and software failures. >=20 > I think we should actually very clearly discourage annotations that > modify the schema of datastores and/or management protocol messages > instead of assuming all annotations are free to do so. Annotations modify the schemas by definition because otherwise XML = attributes, and objects in JSON encoding whose names start with "@", are = not allowed. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 06:15:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810381ACD15 for ; Tue, 13 Oct 2015 06:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KRUPIShuR42 for ; Tue, 13 Oct 2015 06:15:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1131ACD12 for ; Tue, 13 Oct 2015 06:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5708; q=dns/txt; s=iport; t=1444742114; x=1445951714; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8ovDDdeVY0DsWq0wIqOYUJaw2sNEJY8Igw2FBpOolDA=; b=keAxJq9n+MXoeIlv/7Zse6NNAQURssFBsjRVzlysJLM2d3i7KhofwrjF osk2CvdjqjvEBND0wXcBwy1LUmz1E/naT6tPoYQXRwWaDc8+7SDT1MdM0 rI/D5/XHoPwHdVQrgbwnWtRSlMjEj1ZKseNZpxwGWEXtVrdG0FQtZ7uLd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQCyAh1W/xbLJq1ewnsBDYFagxMygVh/AoF8FAEBAQEBAQF/C4QnAQEEDhUPAQUtJAsYAgIFIQICDwJGBg0IAQEXiBOtNpNgAQEBAQEBBAEBAQEBHYEihVOEfoUUgmmBRQWHOocFh1eNGoFYhzsjigqISB8BAUKCRIE/PYckAQEB X-IronPort-AV: E=Sophos;i="5.17,678,1437436800"; d="scan'208";a="630303428" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 Oct 2015 13:15:12 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9DDFCsr000453 for ; Tue, 13 Oct 2015 13:15:12 GMT To: "netmod@ietf.org" References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com> <560EE633.5060707@cisco.com> <56139683.9010909@cisco.com> <20151006160138.GA50204@elstar.local> <5614285E.8060305@cisco.com> <20151006205407.GA50666@elstar.local> From: Robert Wilton Message-ID: <561D03D3.90403@cisco.com> Date: Tue, 13 Oct 2015 14:14:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151006205407.GA50666@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:15:16 -0000 In an attempt to try and close on some of the proposed requirement text before Thursday's interim meeting. Does anyone have any outstanding objections on using this proposed text for Requirement 1.D, or is it sufficiently clear to update the draft, and resolve issue 1? OLD text for Requirement 1: 1. Ability to interact with both intended and applied configuration A. The ability to ask the operational components of a system (e.g., line cards) for the configuration that they are currently using. This is the "applied configuration". B. Applied configuration is read-only C. The data model for the applied configuration is the same as the data model for the intended configuration (same leaves) D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. NEW text (as above, changing 1.D only): 1. Ability to interact with both intended and applied configuration A. The ability to ask the operational components of a system (e.g., line cards) for the configuration that they are currently using. This is the "applied configuration". B. Applied configuration is read-only C. The data model for the applied configuration is the same as the data model for the intended configuration (same leaves) D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. Thanks, Rob On 06/10/2015 21:54, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> On 06/10/2015 17:01, Juergen Schoenwaelder wrote: >>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote: >>>> Hi Kent, >>>> >>>> On 06/10/2015 01:40, Kent Watsen wrote: >>>>> This issue appears to have become more like issue #5 – should we mark >>>>> this one a duplicate of the other? >>>> I suggest that we can just finalize on the text being discussed to >>>> replace 1.D and then resolve issue #1. >>>> >>>> Jason had proposed this text: >>>> >>>> When the configuration change for any intended configuration node has >>>> been successfully applied to the system (e.g. not failed, nor deferred >>>> due to absent hardware) then the existence and value of the applied >>>> equivalent of the node (whether that be a corresponding node in the data >>>> model, an attribute associated with the intended config node, the >>>> configuration node read from a different datastore or context, etc) must >>>> match the intended configuration node. >>> I have no clue what "an attribute associated with the intended config >>> node" or "the configuration node read from a different datastore or >>> context" or "etc". means. What exactly is an "applied equivalent of >>> the node"? >>> >>>> Or perhaps this slightly briefer alternative is better?: >>>> >>>> D. When the configuration change for any intended >>>> configuration node has been successfully applied to the >>>> system (e.g. not failed, nor deferred due to absent hardware) >>>> then the existence and value of the corresponding, possibly >>>> notional, applied configuration node must match the intended >>>> configuration node. >>> What is the purpose of the phrase "possibly notional"? >> There was a concern that my previous text, i.e. as above but without >> "possibly notional", implied that applied configuration had to be >> actually represented as real data nodes in a YANG schema, which would >> disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and >> draft-wilton-netmod-intf-ext-yang-00. >> >> On balance, my preference is to exclude the "possibly notional" phrase >> if the text is sufficiently clear without it. > My understanding is that draft-kwatsen-netmod-opstate-00 proposes to > represent applied config as nodes in a different datastore, so there > is no need for 'possibly notational'. I do not understand why > draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean > draft-wilton-netmod-opstate-yang-00? I do have major concerns about > this particular proposal since it changes the YANG data encoding > fundamentally. There was another proposal to use attributes, which is > also not without problems but it is likely a bit less painful. But > again, it all depends on the final definition of what applied config > really is. So where is the latest version and how far are we with > agreeing on it? > > Yet another way to look at this is to expose not the applied config in > addition to the intended config (I have been told configs can be > really large) but instead expose lets say a yang patch that says how > the applied config differs form the running config. Having to retrieve > two large configs just to diff them locally seems to a potentially > expensive exercise, in particular if the difference is often small. I > think Randy mentioned something like this before and no there is no > I-D. But even with this approach, the definition without "possibly > notational' would hold; you would just not expose the applied config > entirely but instead a patch that allows to calculate it. > > /js > From nobody Tue Oct 13 06:29:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3131B3B57 for ; Tue, 13 Oct 2015 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_2KSyu_rQdx for ; Tue, 13 Oct 2015 06:29:23 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47DD1B3B51 for ; Tue, 13 Oct 2015 06:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5417; q=dns/txt; s=iport; t=1444742963; x=1445952563; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=dWgu/PPlkZZWPpXQoiFdHthu7SVDwq4IOQg3uvhyV4Q=; b=DJlfwQg1KKGOzwxHEFIgLGZWFxjY5tUOZ7R+g2hYToR8+59k4qYb26FA XDAPC31uxxXpwoZyJ0RBPJmt0Bkkd94DAaSpZ/EUYyj7p6Mo4Tt2Z/vS8 t0/9970DVHvRu8xhk0TtG8OEVNsThV19GLsABN6/l3toLsAwG525JpID8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgBBBh1W/xbLJq1eglmBIW6+EwENgVoXAQmCcoIKNUoCgXcUAQEBAQEBAYEKhCcBAQQBAQFrChELDgoJFgQLCQMCAQIBFTAGAQwGAgEBiCoNwREBAQEBAQEBAQEBAQEBAQEBAQEBARQEhnWEfoUUhC4FlhaFGYgBgViEOoMBI5JSHwEBQoJEgT89M4ZxAQEB X-IronPort-AV: E=Sophos;i="5.17,678,1437436800"; d="scan'208,217,223";a="612190306" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Oct 2015 13:29:20 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9DDTKd3003512; Tue, 13 Oct 2015 13:29:20 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <561D0724.1030602@cisco.com> Date: Tue, 13 Oct 2015 14:29:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020006090006060006080706" Archived-At: Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:29:24 -0000 This is a multi-part message in MIME format. --------------020006090006060006080706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit From the interim meeting two weeks ago, it was clarified that the schema of the intended configuration nodes are expected to be the same as the schema of the applied configuration nodes so that clients can easily relate between the two. I think that the requirement text for 1.C and the proposed updated text for 1.D makes this reasonable clear. Hence, is issue 5 now at the state where is can be closed as not being a requirement? Or is there something further that needs to be discussed first? Thanks, Rob On 30/09/2015 16:44, Kent Watsen wrote: > > It's time to tackle another issue, just before tomorrow's meeting, and > this time I'm picking a hard one: > > https://github.com/netmod-wg/opstate-reqs/issues/5 > > Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the > GitHub issue tracker. Please first read the comments posted there > and then continue the discussion here on the mailing list (not on the > GitHub issue tracker). > > Note that this issue is closely tied to the definition of "applied > configuration", which is exactly what issue #4 regards > (https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh > and Einar have posted comments on already. As these two issues (#4 > and #5) are so highly related, I'm going to simultaneously open the > other issue for discussion now as well. > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------020006090006060006080706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit From the interim meeting two weeks ago, it was clarified that the schema of the intended configuration nodes are expected to be the same as the schema of the applied configuration nodes so that clients can easily relate between the two.

I think that the requirement text for 1.C and the proposed updated text for 1.D makes this reasonable clear.

Hence, is issue 5 now at the state where is can be closed as not being a requirement?  Or is there something further that needs to be discussed first?

Thanks,
Rob


On 30/09/2015 16:44, Kent Watsen wrote:

It's time to tackle another issue, just before tomorrow's meeting, and this time I'm picking a hard one:


Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub issue tracker.    Please first read the comments posted there and then continue the discussion here on the mailing list (not on the GitHub issue tracker).

Note that this issue is closely tied to the definition of "applied configuration", which is exactly what issue #4 regards (https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh and Einar have posted comments on already.   As these two issues (#4 and #5) are so highly related, I'm going to simultaneously open the other issue for discussion now as well.

Thanks,
Kent



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

--------------020006090006060006080706-- From nobody Tue Oct 13 07:01:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA28F1ACD6F for ; Tue, 13 Oct 2015 07:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcu6i1E7tudA for ; Tue, 13 Oct 2015 07:01:24 -0700 (PDT) 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 044471B4112 for ; Tue, 13 Oct 2015 07:01:24 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id A41961818BD for ; Tue, 13 Oct 2015 16:01:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444744882; bh=iSAV9tfe4E2Ymgd7QbP5L5lxXhS0bg3Xw7U43nzUZUw=; h=From:Date:To; b=W3OTa28v5oPheSLsE6CG5pJifeDniY3LC+kxOvdYC1ly9hk0C2F/c6w4LNM08iKpG BqCJyMQjEilDgFGtI8PJHfpmrlieQVUzf1i58dUCVT5JcP6i30SqgKyLA4QqyZnS0C m3vkqYyUZotv9t8eFiELMGiSiZHwmdrRfBFxnp38= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz> Date: Tue, 13 Oct 2015 16:01:22 +0200 To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] nested choices X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:01:26 -0000 Hi, my action item from yesterday's interim was to check whether some = updates to 6020bis are needed in order to address the corner cases = presented by Balazs: - = https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk - = https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk I would propose this minor change to sec. 7.9.3: OLD The default case is only important when considering the default values of nodes under the cases. NEW The default case is only important when considering the default contents of nodes under the cases (default values of leafs and leaf-lists, or default cases of nested choices). Otherwise, I believe the text in 7.9.4 is sufficiently clear about when = a "mandatory" statement on a case applies. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 07:08:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA711B424F for ; Tue, 13 Oct 2015 07:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9X9Bs1gh0GB for ; Tue, 13 Oct 2015 07:08:16 -0700 (PDT) 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 18E8A1B4249 for ; Tue, 13 Oct 2015 07:08:16 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id BBB9E181734 for ; Tue, 13 Oct 2015 16:08:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444745294; bh=P08NS+ZNoz3pxPbuhOmOGQ3H+yHdHBjEPm7mhh7okN8=; h=From:Date:To; b=SjihrcPgwdbVR4m4DtAViC3B8zESJdp+Iu6rYhGvwlBxCbKgsgXoU5zexpGQW6jnK SxGc4KAQc8pdBioIfIL7w9ZcAVnyqc0/Xg5ToAW6XQTZGt0PIg4Wq8U9N8iMEU0SFu cQgS6j2EQ7Xe0g7myYlja9it+oYriOFUxCBaoMuY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz> Date: Tue, 13 Oct 2015 16:08:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz> To: NETMOD WG X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] nested choices X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:08:17 -0000 > On 13 Oct 2015, at 16:01, Ladislav Lhotka wrote: >=20 > Hi, >=20 > my action item from yesterday's interim was to check whether some = updates to 6020bis are needed in order to address the corner cases = presented by Balazs: >=20 > - = https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk > - = https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk >=20 > I would propose this minor change to sec. 7.9.3: >=20 > OLD >=20 > The default case is only important when considering the default > values of nodes under the cases. >=20 > NEW >=20 > The default case is only important when considering the default > contents of nodes under the cases (default values of leafs and > leaf-lists, or default cases of nested choices). And perhaps also fifth paragraph in sec. 7.9.3: OLD Default values for child nodes under a case are =E2=80=A6 NEW The "default" statement on child nodes of a case is =E2=80=A6 Lada >=20 > Otherwise, I believe the text in 7.9.4 is sufficiently clear about = when a "mandatory" statement on a case applies. >=20 > Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 07:15:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DDA1B42E0 for ; Tue, 13 Oct 2015 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Ex6wHfpXc7 for ; Tue, 13 Oct 2015 07:15:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 461C71B42F9 for ; Tue, 13 Oct 2015 07:15:32 -0700 (PDT) Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id CCB851CC00D9; Tue, 13 Oct 2015 16:15:34 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20151012144431.GA64068@elstar.local> References: <20151012144431.GA64068@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 13 Oct 2015 16:15:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:15:37 -0000 Juergen Schoenwaelder writes: > Hi, > > I have read through draft-ietf-netmod-rfc6020bis-07 (except section 9. > Built-In Types). Overall, the document is in a good shape. I spotted a > number of editorial issues or a number of issues where we could try to > seek a clearer separation of NETCONF specifics. (I plan to read > section 9 as well but I assume this is less important since there > likely are not many changes from RFC 6020 in this part.) > > I am indicating the paper number below for each comment/suggestion. > > * p8: > > s/XML has been/XML have been/ And right after that: s/propsed/proposed/ Lada > > s/how the data model/how a data model/ > > s/represented in/encoded in/ > > * p9: > > s/names means/names mean/ > > * p11: > > s/the module faithfully/a module faithfully/ > > I am also wondering why we use device and server. It seems we use > these terms interchangeably. If so, for clarity, I would suggest to > use a single term, that is s/device/server/ and perhaps explicitly > state that unless stated otherwise server means a server providing > access to a YANG defined data tree. > > * p12/p13 > > We import 7 terms from RFC 6241. Would it make sense to copy the > necessary text in order to avoid a too strict binding to RFC 6241? > In particular, 'client' and 'server' means NETCONF client and server > if we import from RFC 6241 but this may be a bit narrow given that > we have RESTCONF as well. In an ideal world, we would factor out > core architectural concepts but the best we can do is likely to > define core concepts inline, pointing out where they are the same. > The idea is to loosen the coupling to RFC 6241. Example: > > OLD > > o datastore: an instantiated data tree > > NEW > > o datastore: A conceptual place to store and access information. > A datastore might be implemented, for example, using files, a > database, flash memory locations, or combinations thereof. > [Matches the definition in RFC 6241.] > > * p13 > > Does the term 'mandatory node' really deserve its own subsection? I > understand that there are references to section 3.1 but would > reference to section 3 not work as well? > > * p13 > > s/used for other/used with other/ > > * p14 > > s/encoded in NETCONF operations/encoded on-the-wire/ > > * p14 > > s/of NETCONF data models/of data models for network management > protocols such as NETCONF,/ > > And I suggest to remove the following sentence since it is not > really needed. > > The data models described by YANG are designed to be easily > operated upon by NETCONF operations. > > * p15 > > s/read-only access/read-only access [RFC6643]/ > > * p15 > > I am not sure why the last paragraph in section 4.1 is needed. In > the first setence, I would remove 'Like NETCONF' and in the second > sentence I am not sure what we are saying given that there is NACM. > I would definitely remove the second sentence and if the first > should be kept, I would likely move it up since it is a fairly > general statement. But I think removing the whole paragraph is the > simplest solution since it is not essential. > > * p13 > > Would it make sense to add a sentence right at the beginning of > section 4 stating that section 4 is intended to provide orientation > for the first time reader but that section 4 is not normative? > > * p15 > > With the previous in mind, I suggest to remove "This progressive > approach handles the inter-related nature of YANG concepts and > statements. A detailed description of YANG statements and syntax > begins in Section 7." from the text right below 4.2. Note that > Section 7 is actually Section 6 (but Section 5 has also important > normative content). > > * p16 > > s/four types of nodes/four types of data nodes/ > > * p16 > > Perhaps simplify: > > OLD > > A leaf instance contains simple data like an integer or a string. It > has exactly one value of a particular type and no child nodes. > > NEW > > A leaf data node has exactly one value of a particular type and no > child nodes. > > * p16-p25 > > Should this be 'XML Encoding Example' instead "NETCONF XML Example'? > This does not seem to be NETCONF specific. > > * p25 > > s/XML representation/XML encoding/ > > * p25 > > s/operations' names/operations' name/ > > * p25 > > s/node in the data hierarchy/data node/ > > * p28 > > Start section 5 by saying that this section defined language > concepts and that it is normative, e.g. > > This normative section defines core language concepts. > > * p29 > > s/its contents are unchanged/its content is unchanged/ > > * p37 > > s/following shows valid data/following XML encoding shows valid data/ > > * p35 > > I think there should be a citation of I-D.ietf-netconf-yang-library > where this module first appears. > > * p46 > > The text concerning module names is a repetition from section 5.1. > To avoid introducing inconsistencies, perhaps replace the repeated > text with a reference to section 5.1? > > * p49 > > Is the text in section 7.1.3 correct when it says all identifiers > defined by the module? I mean, schema node identifiers are > namespaced by module names and their prefixes. And data node > identifiers are using the namespace in the XML encoding. Here is > an attempt of a rewrite: > > The "namespace" statement defines the XML namespace that all data > node identifiers defined by the module are qualified by in the > XML encoding. Data node identifiers defined inside a grouping are > an exception q(see Section 7.13 for details). The argument to > the "namespace" statement is the URI of the namespace. > > * p53 > > Another repetition of the module/submodule name requirements, does > it make sense to avoid repetition? > > * p61 > > Should the text in 7.5.4.1 and 7.5.4.2 say explicitly that we talk > about NETCONF when we refer to ? Or should the text try > to be more generic, saying that the respective fields will be > carried in error message in protocols that use YANG? It is actually > somewhat opaque what an error-app-tag is or how it should be used. > > * p63 > > Should the last paragraph in 7.5.7 be factored out into its own > subsection titled "NETCONF and Operations"? The > text is not really anymore about XML encoding (which may be used > with RESTCONF). Or the text is actually about the encoding but > should be written to simply state that non-presence containers can > be pruned in encodings (without restricting this to NETCONF). > > * p67 > > Similar to the comment for p63. Perhaps the right way is to phrase > this in such a way that is simply says leaf nodes containing a > default value may not be present in the XML encoding. Simply remove > NETCONF or specifics. > > * p72 > > s/an unspecified order/an order determined by the system/ > > Note that a description clause may actually define how the system > has to order elements and hence 'unspecified order' seems wrong. > > * p97 > > The text in 7.14 talks about NETCONF specifics, namely the > element and the "rpcOperation" substitution group. Perhaps move this > down into a specific section defining the mapping of YANG RPCs to > NETCONF s. > > * p100 > > The XML encoding text starts with detailing NETCONF specifics. > Would it make sense to separate the XML encoding of the rpc and its > input/output from the specifics how the RPCs fit into NETCONF's > system? > > * p102 > > The XML encoding section again mixes XML encoding of the node > hierarchy with NETCONF specifics how an action is invoked using > NETCONF's system. I suggest to factor this into two different > sections. > > * p105 > > Again, the proposal is to separate the XML encoding of notifications > from the details how notifications work with RFC 5277. > > * p120 > > The text in section 7.21.1 talks about NETCONF specific operations. > Is this actually necessary? Can the purpose of the config statement > not be described by referring to general concepts such as > configuration datastores instead of using protocol specific > operations? > > * p123 > > Is there a special reason why the text uses 'notification instance > data tree' instead of just 'notification data tree'? > > * p123 > > "All leaf data values MUST match the type constraints..." may be > read as 'all data nodes that contain values' or 'all instantiations > of nodes defined by the leaf statement'. > > * p192 > > The Acknowledgements section may need some updates. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 07:32:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B831B4418 for ; Tue, 13 Oct 2015 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX7XAIbxYRph for ; Tue, 13 Oct 2015 07:32:34 -0700 (PDT) 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 CFF701B4417 for ; Tue, 13 Oct 2015 07:32:33 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id ED673180D6F for ; Tue, 13 Oct 2015 16:32:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444746752; bh=A0ixB9Z9t2wsypn0HxadJ647RoOUS9AJw7UjgwUcxpU=; h=From:Date:To; b=QRJ1Rq0z8Bah44QXfe9Ygf9xfG/+1M9AaIBUbtdSDxUIsAFNG8LFPZwuSI6IMWWsd E6vmhb3cI0vWmHCc9X/BYdcquiHcQ7EN7WFiKUSkQOeaJaB/9a3FDhQtkhgJ1O9hLP FTRp7+ky3TUhhNk1p/OVdytohf0/Jd+YVKHgLtAQ= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 13 Oct 2015 16:32:31 +0200 To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] 6020bis - sec. 5.6.4 comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:32:35 -0000 Hi, regarding $subj: - What about extensions? Do modules defining them have to be = implemented? That is, is "default-revision" true or false for such=20 modules? - Third paragraph: OLD This is regardless of if module B is imported by revision or not. NEW If module B is imported by revision, the corresponding = "revision-date" statement is ignored. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 08:21:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EB61B32FC; Tue, 13 Oct 2015 08:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXsVMG-o43hU; Tue, 13 Oct 2015 08:21:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336351B46DE; Tue, 13 Oct 2015 08:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1444749654; x=1445959254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=80jwaM68mSdPypeimEECDoDNSlBdPsx6bWnp2x0SPiQ=; b=Eii3TyAfxaiq6jbBH2gl6tr5Tcdbu0u42RH84iwv9m6ZHp/gyuYzC6nl v6XuCJH5PHPRfrJu4yygRzKV/EBjE8tM+kJDF3rtt8820SqH8VLwtjrZi pHhVy+fw19mqDQWeGMGLShYu8+IKswhobFKIMqEpkUaLw5LMIo/LIfFX7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B2AgD9Hx1W/4gNJK1egyZUYA4Gvg0BDYFaFwqCcoIKNUoCHIEkOBQBAQEBAQEBgQqEJwEBBAEBASAROgQHEAIBCBgCAiYCAgIlCxUQAgQBDQWILg2uAZNgAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIopRhQ0HgmmBRQWWFgGNGZwHAR8BAUKEAnGFKiUcgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,678,1437436800"; d="scan'208";a="35305018" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 13 Oct 2015 15:20:53 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9DFKrac030734 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2015 15:20:53 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 10:20:39 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Tue, 13 Oct 2015 10:20:39 -0500 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , Ladislav Lhotka , "i2rs@ietf.org" , NETMOD WG Thread-Topic: [netmod] rib-data-model and routing-cfg Thread-Index: AQHRAmpn2WDjXB7SH0yyXI3vdDB1jJ5jMMMAgAZwt4A= Date: Tue, 13 Oct 2015 15:20:39 +0000 Message-ID: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Routing YANG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 15:21:24 -0000 SGkgTGFkYSwgTkVUTU9ELCANCg0KU28gSSB0aGluayB3ZSBzaG91bGQgbW92ZSBmb3J3YXJkIHRo aXMgaWV0Zi1ydGctY2ZnIHNvIHRoYXQgaXQgY2FuIGJlDQphdWdtZW50ZWQgYW5kIG90aGVyIHdv cmsgY2FuIG1vdmUgZm9yd2FyZC4gV2UgYXJlIHN0aWxsIGluIGRpc2FncmVlbWVudA0Kd2l0aCBy ZXNwZWN0IHRvIHJvdXRpbmctaW5zdGFuY2UvaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24uDQoNCiAg ICAtIFdlIGZlZWwgdGhlIElQdjQvSVB2NiBpbnRlcmZhY2VzIHNob3VsZCByZWZlcmVuY2UgdGhl DQpyb3V0aW5nLWluc3RhbmNlIGluIHRoZWlyIGNvbmZpZyBzdGF0ZS4gVGhpcyBpcyBjb25zaXN0 ZW50IHdpdGgNCmRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDEudHh0Lg0KICAg IC0gWW91IGZlZWwgdGhhdCB0aGUgcm91dGluZy1pbnN0YW5jZSBzaG91bGQgaGF2ZSBhIGxpc3Qg b2YgbGVhZi1yZWbigJlzDQp0byB0aGUgaW50ZXJmYWNlLiBZb3UgYmVsaWV2ZSB0aGUgbGVhZi1y ZWYgcHJvdmlkZXMgYSBsZXZlbCBvZiB2YWxpZGF0aW9uDQpkdWUgdG8gdGhlIGZhY3QgdGhhdCBy ZWZlcmVuY2VzIGNhbiBiZSBjb25maW5lZCB0byByb3V0aW5nLWluc3RhbmNlDQpyZWZlcmVuY2Vz LiBIb3dldmVyLCBoZXJldG9mb3JlLCBubyBtb2RlbHMgYXJlIHJlZmVyZW5jaW5nIHRoZSBpbnRl cmZhY2UNCmxlYWYtcmVmcyBpbiB0aGUgbGlzdC4NCg0KT3RoZXIgdGhhbiB0aGUgUm91dGluZyBZ QU5HIERlc2lnbiBUZWFtIGhhdmluZyBjaG9zZW4gdGhlIGZpcnN0IG9wdGlvbiAtDQphcmUgdGhl cmUgYW55IG90aGVyIG9waW5pb25zPw0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDEwLzkvMTUsIDk6 MDAgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKSINCjxuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+ SGkgTGFkYSwgDQo+STJSUyBpcyBub3QgY2hhcnRlcmVkIHRvIGRvIHRoZSBiYXNlIG1vZGVscy4g VGhlcmUgYXJlIG90aGVyIHJvdXRpbmcNCj5tb2RlbHMgdGhhdCByZWZlcmVuY2Ugcm91dGluZy1j ZmcgYW5kIGV2ZW4gaW4tcHJvZ3Jlc3MgaW1wbGVtZW50YXRpb25zLg0KPg0KPk9uIDEwLzkvMTUs IDQ6MTMgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj48bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPg0K Pj5IaSwNCj4+DQo+PkkgYW0gc29ycnkgZm9yIGNyb3NzLXBvc3RpbmcgYnV0IEkgdGhpbmsgaXQg aXMgaGlnaCB0aW1lIHRvIGRlY2lkZSB0aGUNCj4+cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGRh dGEgbW9kZWxzIGluIGkycnMtcmliLWRhdGEtbW9kZWwgYW5kDQo+Pm5ldG1vZC1yb3V0aW5nLWNm ZyBJLURzIGJlY2F1c2UgdGhleSBjbGVhcmx5IHRhcmdldCB0aGUgc2FtZSBtYW5hZ2VtZW50DQo+ PmRhdGEgaW4gYSByb3V0ZXIuIEkgY2FuIHNlZSB0aHJlZSBwb3NzaWJsZSBzY2VuYXJpb3M6DQo+ Pg0KPj4xLiBUaGUgaTJycy1yaWIgbW9kdWxlIHdpbGwgYmUgbW9kaWZpZWQgdG8gYXVnbWVudA0K Pj5pZXRmLXJvdXRpbmcvaWV0Zi1pcHZbNDZdLXVuaWNhc3Qtcm91dGluZy4NCj4NCj5UaGlzIHdv dWxkIHNlZW0gdG8gYmUgdGhlIG9idmlvdXMgY2hvaWNlLg0KPg0KPj4NCj4+Mi4gVGhlIHNjb3Bl IG9mIGlldGYtcm91dGluZyB3aWxsIGJlIGNoYW5nZWQgc28gdGhhdCBpdCB3b3VsZCBhZGRyZXNz DQo+Pm9ubHkgaG9zdCByb3V0aW5nIGFuZCBzaW1wbGUgcm91dGVycy4gVGhlIG1vZGVsbGluZyB3 b3JrIGZvciBhZHZhbmNlZA0KPj5yb3V0ZXJzIHdpbGwgYmUgZG9uZSBlbHNld2hlcmUuDQo+Pg0K Pj4zLiBUaGUgd29yayBvbiBuZXRtb2Qtcm91dGluZy1jZmcgd2lsbCBiZSBzdG9wcGVkLg0KPg0K PkEgZm91cnRoIG9wdGlvbiB3b3VsZCBiZSBmb3IgbWUgdG8gdGFrZSBvdmVyIG93bmVyc2hpcCwg bW92ZSB0aGUgd29yayB0bw0KPnRoZSBSVEcgV0csIGFuZCB3ZeKAmWQgcmVjcnVpdCBzb21lIHN0 cm9uZyBhdXRob3JzL3Jldmlld2VycyBmcm9tIG9wZXJhdG9ycw0KPmFuZCBvdGhlciB2ZW5kb3Jz IChpbnZvbHZpbmcgdGhlIEFEcyBpbiBzZWxlY3Rpb24pLg0KPg0KPlRoYW5rcywNCj5BY2VlIA0K Pg0KPg0KPj4NCj4+T3BpbmlvbnM/DQo+Pg0KPj5UaGFua3MsIExhZGENCj4+DQo+Pi0tDQo+Pkxh ZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+DQo+ Pg0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pm5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+bmV0bW9kQGlldGYub3JnDQo+Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+ bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCg0K From nobody Tue Oct 13 08:26:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2478D1B470A for ; Tue, 13 Oct 2015 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8sa8Yb5DpfR for ; Tue, 13 Oct 2015 08:26:22 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 86D941B4707 for ; Tue, 13 Oct 2015 08:26:22 -0700 (PDT) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id E9B76243B4C; Tue, 13 Oct 2015 17:26:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1444749980; bh=pzukfsK+v8sCAsIisbKZIBsNT3kEgpk+s1JXigF1sjQ=; h=Subject:To:References:From:Date:In-Reply-To; b=uNDM52jRnfjxpyV733wYtBcnxKFc3rbFcKYh/VAogOK7fuMdZ8WoZi5bgr4U86f9n +3qRjl50OuqmN4uGR6QhdQmVLqPekzFqwj/6lc/P73YgQUQLILOapsXzMcB9zs9sAm GVHau7tF9cxZHTYHcNnn1t1BRtQbMBsMAulcNMyM= To: Kent Watsen , "netmod@ietf.org" References: From: Robert Varga Message-ID: <561D229B.4050900@hq.sk> Date: Tue, 13 Oct 2015 17:26:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080206080007080800070305" Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 15:26:25 -0000 This is a multi-part message in MIME format. --------------080206080007080800070305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/07/2015 07:37 PM, Kent Watsen wrote: > > This is a notice to start a NETMOD WG last call for the document: > > Defining and Using Metadata with YANG > http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 > I have read the document, and coming in without the previous discussions, md:annotation instances feel like aspects (from aspect-oriented programming) being attached to pre-defined models to address a cross-cutting concern. Unfortunately it seems it lacks an equivalent of pointcut specification, e.g. a machine-readable definition where/when a particular annotation is valid. This makes annotations disconnected from the YANG metamodel, which is not desirable for systems strictly based on the metamodel, as each instance of an annotation will require hand-written code. My question is whether it would make sense to define some sort of (optional) pointcut specification to be carried within the md:annotation statement (such as an explicit list of data nodes, or a 'when' statement or similar)? That would allow us to bind some/most md:annotation instances automagically to the metamodel, reducing the need to hand-code their semantics. Thanks, Robert --------------080206080007080800070305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 10/07/2015 07:37 PM, Kent Watsen wrote:

This is a notice to start a NETMOD WG last call for the document:

Defining and Using Metadata with YANG


I have read the document, and coming in without the previous discussions, md:annotation instances feel like aspects (from aspect-oriented programming) being attached to pre-defined models to address a cross-cutting concern. Unfortunately it seems it lacks an equivalent of pointcut specification, e.g. a machine-readable definition where/when a particular annotation is valid.

This makes annotations disconnected from the YANG metamodel, which is not desirable for systems strictly based on the metamodel, as each instance of an annotation will require hand-written code.

My question is whether it would make sense to define some sort of (optional) pointcut specification to be carried within the md:annotation statement (such as an explicit list of data nodes, or a 'when' statement or similar)?

That would allow us to bind some/most md:annotation instances automagically to the metamodel, reducing the need to hand-code their semantics.

Thanks,
Robert
--------------080206080007080800070305-- From nobody Tue Oct 13 09:19:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995CA1B4832 for ; Tue, 13 Oct 2015 09:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JOnsnCCBAbK for ; Tue, 13 Oct 2015 09:19:48 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 B30071B4831 for ; Tue, 13 Oct 2015 09:19:47 -0700 (PDT) Received: by lbbk10 with SMTP id k10so26926224lbb.0 for ; Tue, 13 Oct 2015 09:19:46 -0700 (PDT) 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=vs2LsqWV6HMWc5mHq7kZQl9rfBWrveODu+avUaXqjYY=; b=Frgt3F52kdNJ2Qee9lc3PdMXfwUOIcJ3w7s28KjK3ojeiEyQFh6MgcF0Q4vE1vdEfd /LP9ZTA74EftMxRi0+SJFzS4L6gwRQ2BwTDHFnriITy9+vs6Fwt+BRImiJI5wcR53UE+ s58VyAQHkK3A6ZY7useKgsN8vx91NehaKnehPJqSUg2r20502bYLjdG5GHgGjXrmrMfA 1ZR6ZLechw4Ym9VYCP2IyC8VyPgCAgMLhEwyDVBWdcPn7tzy7FWaQuEDv3Y771mjNW6C tGD3RX0Uph+FHov5d+Hd6wxQHIDFFEGyHu7tw8fliBSrwitxbgDrujZgVozTpDv3TgM8 w6lg== X-Gm-Message-State: ALoCoQm4DOOK4qWJIR+DpUxQyg+hiaFGh1liheAUQnwXArFm55MIXRjnslqHqMd/YI9Nf2jKh0wd MIME-Version: 1.0 X-Received: by 10.112.181.71 with SMTP id du7mr15268758lbc.37.1444753185903; Tue, 13 Oct 2015 09:19:45 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 13 Oct 2015 09:19:45 -0700 (PDT) In-Reply-To: References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> Date: Tue, 13 Oct 2015 09:19:45 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3715c6f3a9e0521fed0a8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:19:50 -0000 --001a11c3715c6f3a9e0521fed0a8 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka wrote: > > > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > >> > >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > >>>> David Reid writes: > >>>> > >>>>> section 6.3.1 states: > >>>>> > >>>>> If a YANG compiler does not support a particular extension, which > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > >>>>> the entire unknown-statement MAY be ignored by the compiler. > >>>>> > >>>>> If a YANG parser does not support a particular extension, which > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > >>>>> the entire unknown-statement MAY be ignored by the parser. Note > >>>> > >>>> Implications of this statement are still not clear to me. Let's say > some > >>>> protocol introduces an extension that is critical for that > >>>> protocol. Does the above sentence mean that an implementation of that > >>>> protocol MAY ignore the extension if it happens to use a parser that > >>>> doesn't support it? > >>>> > >>>> Lada > >>>> > >>>>> that even in this case the semantics associated with the extension > >>>>> still apply (as if they were part of a description statement). > >>>>> > >>> > >>> Did you read the following sentence: > >>> > >>> [...] Note that > >>> even in this case the semantics associated with the extension still > >>> apply (as if they were part of a description statement). > >> > >> Well, if the parser ignores the extension statement, then the > application has no way to find out that the extension is present to be able > to apply its semantics. > >> > > > > Description statements have always to be taken into account. > > This is a different thing. Such a description would be a substatement to > the "extension" (built-in) statement that defines the extension. In order > to apply the semantics in appropriate places, an application must see where > the extension statement is actually *used*. This is only possible if the > underlying parser provides this information. > > > > >>> I think it answers your question with a 'no'. > >> > >> Specifying behaviour of a YANG parser using 2119 keywords YANG parser > doesn't make much sense to me, because it all depends on the purpose of the > application that uses the parser. > >> > > > > I do not get your point. The text says a parser may skip over an > > extension it does not know how to process and it says the semantics > > still apply as if they were part of a description statement. What > > is the problem with this? > > If a protocol requires an extension to be honoured, then there is no > excuse for the parser to ignore it. But the sentence I am objecting to says > "MAY ignore" without any qualification. > > I do not want to change YANG wrt/ MAY skip over. We have been over this many times. Conformance to YANG for the extension: NONE This includes syntax and semantics. It makes no sense at all (Lada is right) to say the extension semantics apply. They only apply if the tool supports the extension. Conformance to the extension is a different matter. A generic YANG tool that is NOT claiming conformance to a particular external language statement can completely ignore that statement. Lada > > Andy > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c3715c6f3a9e0521fed0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Oct 2015, at 12:42, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
>
> On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote:
>>
>>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univer= sity.de> wrote:
>>>
>>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrot= e:
>>>> David Reid <reid@snmp.= com> writes:
>>>>
>>>>> section 6.3.1 states:
>>>>>
>>>>>=C2=A0 If a YANG compiler does not support a particular= extension, which
>>>>>=C2=A0 appears in a YANG module as an unknown-statement= (see Section 14),
>>>>>=C2=A0 the entire unknown-statement MAY be ignored by t= he compiler.
>>>>>
>>>>>=C2=A0 If a YANG parser does not support a particular e= xtension, which
>>>>>=C2=A0 appears in a YANG module as an unknown-statement= (see Section 14),
>>>>>=C2=A0 the entire unknown-statement MAY be ignored by t= he parser.=C2=A0 Note
>>>>
>>>> Implications of this statement are still not clear to me. = Let's say some
>>>> protocol introduces an extension that is critical for that=
>>>> protocol. Does the above sentence mean that an implementat= ion of that
>>>> protocol MAY ignore the extension if it happens to use a p= arser that
>>>> doesn't support it?
>>>>
>>>> Lada
>>>>
>>>>>=C2=A0 that even in this case the semantics associated = with the extension
>>>>>=C2=A0 still apply (as if they were part of a descripti= on statement).
>>>>>
>>>
>>> Did you read the following sentence:
>>>
>>>=C2=A0 [...] Note that
>>>=C2=A0 even in this case the semantics associated with the exte= nsion still
>>>=C2=A0 apply (as if they were part of a description statement).=
>>
>> Well, if the parser ignores the extension statement, then the appl= ication has no way to find out that the extension is present to be able to = apply its semantics.
>>
>
> Description statements have always to be taken into account.

This is a different thing. Such a description would be a substatement to th= e "extension" (built-in) statement that defines the extension. In= order to apply the semantics in appropriate places, an application must se= e where the extension statement is actually *used*. This is only possible i= f the underlying parser provides this information.

>
>>> I think it answers your question with a 'no'.
>>
>> Specifying behaviour of a YANG parser using 2119 keywords YANG par= ser doesn't make much sense to me, because it all depends on the purpos= e of the application that uses the parser.
>>
>
> I do not get your point. The text says a parser may skip over an
> extension it does not know how to process and it says the semantics > still apply as if they were part of a description statement. What
> is the problem with this?

If a protocol requires an extension to be honoured, then there is no excuse= for the parser to ignore it. But the sentence I am objecting to says "= ;MAY ignore" without any qualification.


I do not want to change YANG wrt/ MAY = skip over.
We have been over this many times.

Conformance to YANG for the extension: NONE
This includ= es syntax and semantics.=C2=A0 It makes no sense at all (Lada is right)
to say the extension semantics apply.=C2=A0 They only apply if the t= ool supports
the extension.=C2=A0 Conformance to the extension is= a different matter.

A generic YANG tool that is N= OT claiming conformance to a particular
external language stateme= nt can completely ignore that statement.


Lada


Andy
=C2=A0
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>

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




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

--001a11c3715c6f3a9e0521fed0a8-- From nobody Tue Oct 13 09:30:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7181B4862; Tue, 13 Oct 2015 09:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhHRVGcUXATo; Tue, 13 Oct 2015 09:30:13 -0700 (PDT) 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 CD50D1B4861; Tue, 13 Oct 2015 09:30:12 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id 09DB3180A4C; Tue, 13 Oct 2015 18:30:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444753811; bh=EKj9yh0A07ijJhVQYFF46oFYFlhma2MGE47FPpEtodQ=; h=From:Date:To; b=EHRoPfbDwyYBMPZptbOq80Z9xwkqM9uxU3E/0Heuaapd5qA7gyAFZvNbhLmOyIpc6 Ucip9GEEaoiPBRC5Vomo7uz646Q95kvYRNGVBFcOjCBf5KQUXhYvJhwiLW03brgT56 87/eBuGpWzdaDvQyCN/x1DEjr9V1kf4LsePkpjkU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 13 Oct 2015 18:30:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Routing YANG , "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:30:15 -0000 > On 13 Oct 2015, at 17:20, Acee Lindem (acee) wrote: >=20 > Hi Lada, NETMOD,=20 >=20 > So I think we should move forward this ietf-rtg-cfg so that it can be > augmented and other work can move forward. We are still in = disagreement > with respect to routing-instance/interface configuration. >=20 > - We feel the IPv4/IPv6 interfaces should reference the > routing-instance in their config state. This is consistent with > draft-rtgyangdt-rtgwg-device-model-01.txt. > - You feel that the routing-instance should have a list of = leaf-ref=E2=80=99s > to the interface. You believe the leaf-ref provides a level of = validation > due to the fact that references can be confined to routing-instance > references. However, heretofore, no models are referencing the = interface > leaf-refs in the list. True, these models (ietf-isis, for instance) use leafrefs with = "if:interface-ref" type. However, such leafrefs are under-constrained = because they can be configured to refer to: - interfaces of any layer, including physical interfaces, VLAN trunks = etc. - interfaces assigned to any routing instance. I believe in all these cases the choice has to be limited to (1) L3 = interfaces, and (2) belonging to "own" routing instance. These = constraints will have to be checked in server code somehow - I would = prefer to have them represented in the data model. But if nobody shares this concern with me, I am not going to block the = document on this issue. Lada=20 >=20 > Other than the Routing YANG Design Team having chosen the first option = - > are there any other opinions? >=20 > Thanks, > Acee >=20 > On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)" > wrote: >=20 >> Hi Lada,=20 >> I2RS is not chartered to do the base models. There are other routing >> models that reference routing-cfg and even in-progress = implementations. >>=20 >> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >> wrote: >>=20 >>> Hi, >>>=20 >>> I am sorry for cross-posting but I think it is high time to decide = the >>> relationship between the data models in i2rs-rib-data-model and >>> netmod-routing-cfg I-Ds because they clearly target the same = management >>> data in a router. I can see three possible scenarios: >>>=20 >>> 1. The i2rs-rib module will be modified to augment >>> ietf-routing/ietf-ipv[46]-unicast-routing. >>=20 >> This would seem to be the obvious choice. >>=20 >>>=20 >>> 2. The scope of ietf-routing will be changed so that it would = address >>> only host routing and simple routers. The modelling work for = advanced >>> routers will be done elsewhere. >>>=20 >>> 3. The work on netmod-routing-cfg will be stopped. >>=20 >> A fourth option would be for me to take over ownership, move the work = to >> the RTG WG, and we=E2=80=99d recruit some strong authors/reviewers = from operators >> and other vendors (involving the ADs in selection). >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >>>=20 >>> Opinions? >>>=20 >>> Thanks, Lada >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 09:42:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDE71B4ABA for ; Tue, 13 Oct 2015 09:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpS5CM9gTEoj for ; Tue, 13 Oct 2015 09:42:11 -0700 (PDT) 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 CE0511B4AAE for ; Tue, 13 Oct 2015 09:42:10 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id 64141181419; Tue, 13 Oct 2015 18:42:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444754529; bh=NESF5yE/EWFlkofDJV9of+SZmn2KvdYen3an+oO2wRo=; h=From:Date:To; b=M2djeUX9xF82mbNJwGi4Msfam9MclTNpaEEmiNJ3qVp+WWMPObJajVpg3Pv/yhE+G LVelKtJlIwJHhW3K5/atuKRwAMw+3bo9C3SLMNc4Xh5miuZ91JrCfQBDjNUa85x9t4 EHMd/QvFnz82hzziTb+1GgOrGFhDkIl8mFvY/kKM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 13 Oct 2015 18:42:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <95CE90E9-0040-4348-B446-A1DAF309337B@nic.cz> References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:42:12 -0000 > On 13 Oct 2015, at 18:19, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder = wrote: > > > > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > >> > >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder = wrote: > >>> > >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > >>>> David Reid writes: > >>>> > >>>>> section 6.3.1 states: > >>>>> > >>>>> If a YANG compiler does not support a particular extension, = which > >>>>> appears in a YANG module as an unknown-statement (see Section = 14), > >>>>> the entire unknown-statement MAY be ignored by the compiler. > >>>>> > >>>>> If a YANG parser does not support a particular extension, which > >>>>> appears in a YANG module as an unknown-statement (see Section = 14), > >>>>> the entire unknown-statement MAY be ignored by the parser. = Note > >>>> > >>>> Implications of this statement are still not clear to me. Let's = say some > >>>> protocol introduces an extension that is critical for that > >>>> protocol. Does the above sentence mean that an implementation of = that > >>>> protocol MAY ignore the extension if it happens to use a parser = that > >>>> doesn't support it? > >>>> > >>>> Lada > >>>> > >>>>> that even in this case the semantics associated with the = extension > >>>>> still apply (as if they were part of a description statement). > >>>>> > >>> > >>> Did you read the following sentence: > >>> > >>> [...] Note that > >>> even in this case the semantics associated with the extension = still > >>> apply (as if they were part of a description statement). > >> > >> Well, if the parser ignores the extension statement, then the = application has no way to find out that the extension is present to be = able to apply its semantics. > >> > > > > Description statements have always to be taken into account. >=20 > This is a different thing. Such a description would be a substatement = to the "extension" (built-in) statement that defines the extension. In = order to apply the semantics in appropriate places, an application must = see where the extension statement is actually *used*. This is only = possible if the underlying parser provides this information. >=20 > > > >>> I think it answers your question with a 'no'. > >> > >> Specifying behaviour of a YANG parser using 2119 keywords YANG = parser doesn't make much sense to me, because it all depends on the = purpose of the application that uses the parser. > >> > > > > I do not get your point. The text says a parser may skip over an > > extension it does not know how to process and it says the semantics > > still apply as if they were part of a description statement. What > > is the problem with this? >=20 > If a protocol requires an extension to be honoured, then there is no = excuse for the parser to ignore it. But the sentence I am objecting to = says "MAY ignore" without any qualification. >=20 >=20 > I do not want to change YANG wrt/ MAY skip over. > We have been over this many times. >=20 > Conformance to YANG for the extension: NONE > This includes syntax and semantics. It makes no sense at all (Lada is = right) > to say the extension semantics apply. They only apply if the tool = supports > the extension. Conformance to the extension is a different matter. >=20 > A generic YANG tool that is NOT claiming conformance to a particular > external language statement can completely ignore that statement. Right, but this is something very different! The current formulation in = 6020bis (a parser MAY ignore) effectively undermines the possibility to = specify strict conformance rules wrt a certain extension in other = documents. Lada >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 09:53:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD0B1B4BBF for ; Tue, 13 Oct 2015 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK2TiSiM5mU5 for ; Tue, 13 Oct 2015 09:53:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 5B84E1B4BC4 for ; Tue, 13 Oct 2015 09:53:49 -0700 (PDT) Received: by lbwr8 with SMTP id r8so27552671lbw.2 for ; Tue, 13 Oct 2015 09:53:47 -0700 (PDT) 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=efqN9lT7T6NhQDjkl4xh+60R8ocg1AqynObM5YfqNb4=; b=WUOvU5suVRoCF4v0DtKgCUl1pxTNHKhPhQu/cmZXbl65xM2qNti0SkWHPSxLTbmHKb yluKVIFVfOpDP0OL0wq1+OSfTc//Wy1jUnqRcpHwOACuxLZufKKs+VAC/YRFm8rol5WH eLVlt2VJd9i6F4ZVWG2iH0N+X40nnDtIODvUM0/j5UZ+OT2CcJFyvQv5u6Fg53QnCJ42 2D0jZxN/JVPvTdUMJoOkFEqxJa3+inBOF7/KH2LQXoszE1kBshYUJjEy/y/xksKFOkp1 rB34eC/w3sKwxdwr6T5Bw2vFFuWKGzXgWNxIJqr46PZbZVyblON/bCrCUlesH6BlTPGG PQiw== X-Gm-Message-State: ALoCoQljXEBQMvYRRVH6CZ2v3gSn4scn8aX5UY1LNOVeGIfhq+f04OxCVEyLcVWQXJ+U+kzNe32p MIME-Version: 1.0 X-Received: by 10.112.160.138 with SMTP id xk10mr15465192lbb.119.1444755227465; Tue, 13 Oct 2015 09:53:47 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 13 Oct 2015 09:53:47 -0700 (PDT) In-Reply-To: <95CE90E9-0040-4348-B446-A1DAF309337B@nic.cz> References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> <95CE90E9-0040-4348-B446-A1DAF309337B@nic.cz> Date: Tue, 13 Oct 2015 09:53:47 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c38b901f003b0521ff4aa3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:53:52 -0000 --001a11c38b901f003b0521ff4aa3 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2015 at 9:42 AM, Ladislav Lhotka wrote: > > > On 13 Oct 2015, at 18:19, Andy Bierman wrote: > > > > > > > > On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka wrote: > > > > > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > > >> > > >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > >>> > > >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > > >>>> David Reid writes: > > >>>> > > >>>>> section 6.3.1 states: > > >>>>> > > >>>>> If a YANG compiler does not support a particular extension, which > > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > > >>>>> the entire unknown-statement MAY be ignored by the compiler. > > >>>>> > > >>>>> If a YANG parser does not support a particular extension, which > > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > > >>>>> the entire unknown-statement MAY be ignored by the parser. Note > > >>>> > > >>>> Implications of this statement are still not clear to me. Let's say > some > > >>>> protocol introduces an extension that is critical for that > > >>>> protocol. Does the above sentence mean that an implementation of > that > > >>>> protocol MAY ignore the extension if it happens to use a parser that > > >>>> doesn't support it? > > >>>> > > >>>> Lada > > >>>> > > >>>>> that even in this case the semantics associated with the extension > > >>>>> still apply (as if they were part of a description statement). > > >>>>> > > >>> > > >>> Did you read the following sentence: > > >>> > > >>> [...] Note that > > >>> even in this case the semantics associated with the extension still > > >>> apply (as if they were part of a description statement). > > >> > > >> Well, if the parser ignores the extension statement, then the > application has no way to find out that the extension is present to be able > to apply its semantics. > > >> > > > > > > Description statements have always to be taken into account. > > > > This is a different thing. Such a description would be a substatement to > the "extension" (built-in) statement that defines the extension. In order > to apply the semantics in appropriate places, an application must see where > the extension statement is actually *used*. This is only possible if the > underlying parser provides this information. > > > > > > > >>> I think it answers your question with a 'no'. > > >> > > >> Specifying behaviour of a YANG parser using 2119 keywords YANG parser > doesn't make much sense to me, because it all depends on the purpose of the > application that uses the parser. > > >> > > > > > > I do not get your point. The text says a parser may skip over an > > > extension it does not know how to process and it says the semantics > > > still apply as if they were part of a description statement. What > > > is the problem with this? > > > > If a protocol requires an extension to be honoured, then there is no > excuse for the parser to ignore it. But the sentence I am objecting to says > "MAY ignore" without any qualification. > > > > > > I do not want to change YANG wrt/ MAY skip over. > > We have been over this many times. > > > > Conformance to YANG for the extension: NONE > > This includes syntax and semantics. It makes no sense at all (Lada is > right) > > to say the extension semantics apply. They only apply if the tool > supports > > the extension. Conformance to the extension is a different matter. > > > > A generic YANG tool that is NOT claiming conformance to a particular > > external language statement can completely ignore that statement. > > Right, but this is something very different! The current formulation in > 6020bis (a parser MAY ignore) effectively undermines the possibility to > specify strict conformance rules wrt a certain extension in other documents. > > Good. IMO external statements are not part of YANG. External statements should not be used in a way that requires interoperability between 2 or more entities. It should be completely out of scope wrt/ YANG conformance. I strongly object to changing this part of YANG. It is critical that conformance to YANG does not include any external statement semantics at all. A server MUST be able to parse all the tokens in a YANG module. That is all that is required for external statements. Since YANG extensions MUST NOT alter the syntax and semantics of real YANG statements, a tool that only supports the official YANG language statements can safely ignore all external statements.. Lada > > Andy > > > > > > Lada > > > > > > Andy > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c38b901f003b0521ff4aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 13, 2015 at 9:42 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Oct 2015, at 18:19, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
> >
> > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote:<= br> > >>
> >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de> wrote:
> >>>
> >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka= wrote:
> >>>> David Reid <reid@= snmp.com> writes:
> >>>>
> >>>>> section 6.3.1 states:
> >>>>>
> >>>>>=C2=A0 If a YANG compiler does not support a parti= cular extension, which
> >>>>>=C2=A0 appears in a YANG module as an unknown-stat= ement (see Section 14),
> >>>>>=C2=A0 the entire unknown-statement MAY be ignored= by the compiler.
> >>>>>
> >>>>>=C2=A0 If a YANG parser does not support a particu= lar extension, which
> >>>>>=C2=A0 appears in a YANG module as an unknown-stat= ement (see Section 14),
> >>>>>=C2=A0 the entire unknown-statement MAY be ignored= by the parser.=C2=A0 Note
> >>>>
> >>>> Implications of this statement are still not clear to= me. Let's say some
> >>>> protocol introduces an extension that is critical for= that
> >>>> protocol. Does the above sentence mean that an implem= entation of that
> >>>> protocol MAY ignore the extension if it happens to us= e a parser that
> >>>> doesn't support it?
> >>>>
> >>>> Lada
> >>>>
> >>>>>=C2=A0 that even in this case the semantics associ= ated with the extension
> >>>>>=C2=A0 still apply (as if they were part of a desc= ription statement).
> >>>>>
> >>>
> >>> Did you read the following sentence:
> >>>
> >>>=C2=A0 [...] Note that
> >>>=C2=A0 even in this case the semantics associated with the= extension still
> >>>=C2=A0 apply (as if they were part of a description statem= ent).
> >>
> >> Well, if the parser ignores the extension statement, then the= application has no way to find out that the extension is present to be abl= e to apply its semantics.
> >>
> >
> > Description statements have always to be taken into account.
>
> This is a different thing. Such a description would be a substatement = to the "extension" (built-in) statement that defines the extensio= n. In order to apply the semantics in appropriate places, an application mu= st see where the extension statement is actually *used*. This is only possi= ble if the underlying parser provides this information.
>
> >
> >>> I think it answers your question with a 'no'.
> >>
> >> Specifying behaviour of a YANG parser using 2119 keywords YAN= G parser doesn't make much sense to me, because it all depends on the p= urpose of the application that uses the parser.
> >>
> >
> > I do not get your point. The text says a parser may skip over an<= br> > > extension it does not know how to process and it says the semanti= cs
> > still apply as if they were part of a description statement. What=
> > is the problem with this?
>
> If a protocol requires an extension to be honoured, then there is no e= xcuse for the parser to ignore it. But the sentence I am objecting to says = "MAY ignore" without any qualification.
>
>
> I do not want to change YANG wrt/ MAY skip over.
> We have been over this many times.
>
> Conformance to YANG for the extension: NONE
> This includes syntax and semantics.=C2=A0 It makes no sense at all (La= da is right)
> to say the extension semantics apply.=C2=A0 They only apply if the too= l supports
> the extension.=C2=A0 Conformance to the extension is a different matte= r.
>
> A generic YANG tool that is NOT claiming conformance to a particular > external language statement can completely ignore that statement.

Right, but this is something very different! The current formulation in 602= 0bis (a parser MAY ignore) effectively undermines the possibility to specif= y strict conformance rules wrt a certain extension in other documents.



Good.

IMO external statements are not part of YANG.

<= div>External statements should not be used in a way that requires
interoperability between 2 or more entities.=C2=A0 It should be completely=
out of scope wrt/ YANG conformance.

I s= trongly object to changing this part of YANG.
It is critical that= conformance to YANG does not include any
external statement sema= ntics at all.

A server MUST be able to parse all t= he tokens in a YANG module.
That is all that is required for exte= rnal statements.=C2=A0 Since YANG extensions
MUST NOT alter the s= yntax and semantics of real
YANG statements, a tool that only sup= ports the official YANG language
statements can safely ignore all= external statements..




Lada


Andy
=C2=A0
>
>
> Lada
>
>
> Andy
>
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c38b901f003b0521ff4aa3-- From nobody Tue Oct 13 09:55:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0081B4BC4 for ; Tue, 13 Oct 2015 09:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cT0QWwWAOip for ; Tue, 13 Oct 2015 09:55:13 -0700 (PDT) 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 328171B4BC1 for ; Tue, 13 Oct 2015 09:55:12 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id 4F3DB180881; Tue, 13 Oct 2015 18:55:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444755311; bh=SuiFsCJRsqNgtwmsviMWkuYzEw1DKFrFk5iUaKez+Rs=; h=From:Date:To; b=bgVeCX2cGQfi7gMipwvcxpDbKQzvlT+2t8MTCgleIKXBg25aYj3afbxvk6DW/8Fpq w4AZPWr7M/AFh753NLla+a1mI2CIqG7/ulaKvxyWPiMgQMdhVv4W9zB2zdqZUBtjhz EiIaqiOB97FjmZeaeZVh7nGIQwfy7dtxF4pxHubw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <561D229B.4050900@hq.sk> Date: Tue, 13 Oct 2015 18:55:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37759FA0-E653-4810-B50E-B8F214D01606@nic.cz> References: <561D229B.4050900@hq.sk> To: Robert Varga X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:55:14 -0000 Hi Robert, > On 13 Oct 2015, at 17:26, Robert Varga wrote: >=20 > On 10/07/2015 07:37 PM, Kent Watsen wrote: >>=20 >> This is a notice to start a NETMOD WG last call for the document: >>=20 >> Defining and Using Metadata with YANG >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 >>=20 >=20 > I have read the document, and coming in without the previous = discussions, md:annotation instances feel like aspects (from = aspect-oriented programming) being attached to pre-defined models to = address a cross-cutting concern. Unfortunately it seems it lacks an = equivalent of pointcut specification, e.g. a machine-readable definition = where/when a particular annotation is valid. >=20 > This makes annotations disconnected from the YANG metamodel, which is = not desirable for systems strictly based on the metamodel, as each = instance of an annotation will require hand-written code. >=20 > My question is whether it would make sense to define some sort of = (optional) pointcut specification to be carried within the md:annotation = statement (such as an explicit list of data nodes, or a 'when' statement = or similar)? The easiest way would be to define "annotation" as a first-class data = node. However: - YANG was deliberately designed to avoid using XML attributes in the = same way as XML schema languages, - IMO this can't be done through an extension. With must or when it would be difficult to determine the context node. Lada >=20 > That would allow us to bind some/most md:annotation instances = automagically to the metamodel, reducing the need to hand-code their = semantics. >=20 > Thanks, > Robert > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 10:13:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6F01A0187 for ; Tue, 13 Oct 2015 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q12thoBByVYi for ; Tue, 13 Oct 2015 10:13:41 -0700 (PDT) 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 AE2CD1A0180 for ; Tue, 13 Oct 2015 10:13:40 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5] (unknown [IPv6:2a01:5e0:29:ffff:6c23:3ee3:ca1:cdc5]) by mail.nic.cz (Postfix) with ESMTPSA id 99867180C29; Tue, 13 Oct 2015 19:13:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444756418; bh=CWxvaMN4ZHi7UMf1HUTkn78o7I2qvwY3upA4ASNRZmo=; h=From:Date:To; b=PWBb8UNt/N7IudrkXC+0ilr6FSUsGd3vcjWtgKk5BhlJyk/jnoJbOGU2TUpYP1mRK G2Oj0XAJbkzf9XVhbwkd4ncXzw8xGsk43aeF7qLzdOQ2n9oZoOmWOjfHyXwzPGXGgl yetvV4C9YkScd/GckDrJJwlB5hZC5o7Qxs7Q2Hns= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 13 Oct 2015 19:13:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> <95CE90E9-0040-4348-B446-A1DAF309337B@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 17:13:43 -0000 > On 13 Oct 2015, at 18:53, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Oct 13, 2015 at 9:42 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Oct 2015, at 18:19, Andy Bierman wrote: > > > > > > > > On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka = wrote: > > > > > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder = wrote: > > > > > > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > > >> > > >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder = wrote: > > >>> > > >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > > >>>> David Reid writes: > > >>>> > > >>>>> section 6.3.1 states: > > >>>>> > > >>>>> If a YANG compiler does not support a particular extension, = which > > >>>>> appears in a YANG module as an unknown-statement (see Section = 14), > > >>>>> the entire unknown-statement MAY be ignored by the compiler. > > >>>>> > > >>>>> If a YANG parser does not support a particular extension, = which > > >>>>> appears in a YANG module as an unknown-statement (see Section = 14), > > >>>>> the entire unknown-statement MAY be ignored by the parser. = Note > > >>>> > > >>>> Implications of this statement are still not clear to me. Let's = say some > > >>>> protocol introduces an extension that is critical for that > > >>>> protocol. Does the above sentence mean that an implementation = of that > > >>>> protocol MAY ignore the extension if it happens to use a parser = that > > >>>> doesn't support it? > > >>>> > > >>>> Lada > > >>>> > > >>>>> that even in this case the semantics associated with the = extension > > >>>>> still apply (as if they were part of a description = statement). > > >>>>> > > >>> > > >>> Did you read the following sentence: > > >>> > > >>> [...] Note that > > >>> even in this case the semantics associated with the extension = still > > >>> apply (as if they were part of a description statement). > > >> > > >> Well, if the parser ignores the extension statement, then the = application has no way to find out that the extension is present to be = able to apply its semantics. > > >> > > > > > > Description statements have always to be taken into account. > > > > This is a different thing. Such a description would be a = substatement to the "extension" (built-in) statement that defines the = extension. In order to apply the semantics in appropriate places, an = application must see where the extension statement is actually *used*. = This is only possible if the underlying parser provides this = information. > > > > > > > >>> I think it answers your question with a 'no'. > > >> > > >> Specifying behaviour of a YANG parser using 2119 keywords YANG = parser doesn't make much sense to me, because it all depends on the = purpose of the application that uses the parser. > > >> > > > > > > I do not get your point. The text says a parser may skip over an > > > extension it does not know how to process and it says the = semantics > > > still apply as if they were part of a description statement. What > > > is the problem with this? > > > > If a protocol requires an extension to be honoured, then there is no = excuse for the parser to ignore it. But the sentence I am objecting to = says "MAY ignore" without any qualification. > > > > > > I do not want to change YANG wrt/ MAY skip over. > > We have been over this many times. > > > > Conformance to YANG for the extension: NONE > > This includes syntax and semantics. It makes no sense at all (Lada = is right) > > to say the extension semantics apply. They only apply if the tool = supports > > the extension. Conformance to the extension is a different matter. > > > > A generic YANG tool that is NOT claiming conformance to a particular > > external language statement can completely ignore that statement. >=20 > Right, but this is something very different! The current formulation = in 6020bis (a parser MAY ignore) effectively undermines the possibility = to specify strict conformance rules wrt a certain extension in other = documents. >=20 >=20 >=20 > Good. >=20 > IMO external statements are not part of YANG. >=20 > External statements should not be used in a way that requires > interoperability between 2 or more entities. It should be completely > out of scope wrt/ YANG conformance. If YANG conformance means "Is this a valid YANG data model or not?", = then I think there is no ambiguity in 6020bis. IMO, the question is = whether management protocols or other applications using YANG may define = extensions with specific conformance rules, such as "Any implementation = of protocol X MUST support extension Y." Other software that doesn't = implement protocol X is then free to ignore extension Y, of course. The YANG spec should IMO say that conformance wrt extensions is out of = scope. Lada >=20 > I strongly object to changing this part of YANG. > It is critical that conformance to YANG does not include any > external statement semantics at all. >=20 > A server MUST be able to parse all the tokens in a YANG module. > That is all that is required for external statements. Since YANG = extensions > MUST NOT alter the syntax and semantics of real > YANG statements, a tool that only supports the official YANG language > statements can safely ignore all external statements.. >=20 >=20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > Lada > > > > > > Andy > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > > Fax: +49 421 200 3103 > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 13 11:25:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FCE1A1A1D; Tue, 13 Oct 2015 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42tDxfHugH7v; Tue, 13 Oct 2015 11:25:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99A51A0439; Tue, 13 Oct 2015 11:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5690; q=dns/txt; s=iport; t=1444760734; x=1445970334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pVu00i/w5YXJQZfO4SD1H/eJxw0fJNcuLZe0W/5n+lA=; b=K2dX6L1IiG7CUB/9xVxCAn+rFQBLEqSJeiTXGf6mKPSsxkoR3LE9tn2+ 1wfDvFkNA0XIwJgmb2qLkJt4uVfOsvq9iF1iIdx+o+zs4KpeGOZ7KG9WT lpo6nv7+8w6Q23ZDAZJIAaSyqlBPb+YU9UH0d0I6tsHSMtSxpZqIdQDDd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZAgAoSx1W/5xdJa1egyZUbga+DQENgVoXCoJyggo1SgIcgS04FAEBAQEBAQGBCoQmAQEBAwEBAQEgEToEBxACAQgYAgImAgICJQsVEAIEDgWIJggNrluTRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKUYQ0DhgYGweCaYFFBZYWAY0ZnAcBHwEBQoQCcYUoAh4HHIEGAQEB X-IronPort-AV: E=Sophos;i="5.17,679,1437436800"; d="scan'208";a="197041838" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 13 Oct 2015 18:25:33 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9DIPXdb014402 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2015 18:25:33 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 13:25:19 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Tue, 13 Oct 2015 13:25:19 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka Thread-Topic: [netmod] rib-data-model and routing-cfg Thread-Index: AQHRAmpn2WDjXB7SH0yyXI3vdDB1jJ5jMMMAgAZwt4CAAFZcgP//3TyA Date: Tue, 13 Oct 2015 18:25:19 +0000 Message-ID: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Routing YANG , "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 18:25:35 -0000 DQoNCk9uIDEwLzEzLzE1LCAxMjozMCBQTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMu Y3o+IHdyb3RlOg0KDQo+DQo+PiBPbiAxMyBPY3QgMjAxNSwgYXQgMTc6MjAsIEFjZWUgTGluZGVt IChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBMYWRhLCBORVRNT0Qs DQo+PiANCj4+IFNvIEkgdGhpbmsgd2Ugc2hvdWxkIG1vdmUgZm9yd2FyZCB0aGlzIGlldGYtcnRn LWNmZyBzbyB0aGF0IGl0IGNhbiBiZQ0KPj4gYXVnbWVudGVkIGFuZCBvdGhlciB3b3JrIGNhbiBt b3ZlIGZvcndhcmQuIFdlIGFyZSBzdGlsbCBpbiBkaXNhZ3JlZW1lbnQNCj4+IHdpdGggcmVzcGVj dCB0byByb3V0aW5nLWluc3RhbmNlL2ludGVyZmFjZSBjb25maWd1cmF0aW9uLg0KPj4gDQo+PiAg ICAtIFdlIGZlZWwgdGhlIElQdjQvSVB2NiBpbnRlcmZhY2VzIHNob3VsZCByZWZlcmVuY2UgdGhl DQo+PiByb3V0aW5nLWluc3RhbmNlIGluIHRoZWlyIGNvbmZpZyBzdGF0ZS4gVGhpcyBpcyBjb25z aXN0ZW50IHdpdGgNCj4+IGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDEudHh0 Lg0KPj4gICAgLSBZb3UgZmVlbCB0aGF0IHRoZSByb3V0aW5nLWluc3RhbmNlIHNob3VsZCBoYXZl IGEgbGlzdCBvZiBsZWFmLXJlZuKAmXMNCj4+IHRvIHRoZSBpbnRlcmZhY2UuIFlvdSBiZWxpZXZl IHRoZSBsZWFmLXJlZiBwcm92aWRlcyBhIGxldmVsIG9mDQo+PnZhbGlkYXRpb24NCj4+IGR1ZSB0 byB0aGUgZmFjdCB0aGF0IHJlZmVyZW5jZXMgY2FuIGJlIGNvbmZpbmVkIHRvIHJvdXRpbmctaW5z dGFuY2UNCj4+IHJlZmVyZW5jZXMuIEhvd2V2ZXIsIGhlcmV0b2ZvcmUsIG5vIG1vZGVscyBhcmUg cmVmZXJlbmNpbmcgdGhlIGludGVyZmFjZQ0KPj4gbGVhZi1yZWZzIGluIHRoZSBsaXN0Lg0KPg0K PlRydWUsIHRoZXNlIG1vZGVscyAoaWV0Zi1pc2lzLCBmb3IgaW5zdGFuY2UpIHVzZSBsZWFmcmVm cyB3aXRoDQo+ImlmOmludGVyZmFjZS1yZWYiIHR5cGUuIEhvd2V2ZXIsIHN1Y2ggbGVhZnJlZnMg YXJlIHVuZGVyLWNvbnN0cmFpbmVkDQo+YmVjYXVzZSB0aGV5IGNhbiBiZSBjb25maWd1cmVkIHRv IHJlZmVyIHRvOg0KPg0KPi0gaW50ZXJmYWNlcyBvZiBhbnkgbGF5ZXIsIGluY2x1ZGluZyBwaHlz aWNhbCBpbnRlcmZhY2VzLCBWTEFOIHRydW5rcyBldGMuDQoNCkFjdHVhbGx5LCBwdXR0aW5nIHRo ZSByb3V0aW5nLWluc3RhbmNlIHJlZmVyZW5jZSBpbiB0aGUgSVB2NCBhbmQgSVB2Ng0KaW50ZXJm YWNlIG1vZGVscyAoaS5lLiwgUkZDIDcyNzcpIGNvbnN0cmFpbnMgdGhlIHJlZmVyZW5jZSB0byBs YXllciAzIG1vcmUNCmVmZmVjdGl2ZWx5IHRoYW4gdGhlIGxpc3Qgb2YgbGVhZi1yZWZzLg0KDQo+ DQo+LSBpbnRlcmZhY2VzIGFzc2lnbmVkIHRvIGFueSByb3V0aW5nIGluc3RhbmNlLg0KDQpCdXQg dGhlIGxpc3Qgb2YgbGVhZi1yZWZzIGRvZXNu4oCZdCBpbnN1cmUgYW4gSVB2NCBpbnRlcmZhY2Ug b3IgSVB2Ng0KaW50ZXJmYWNlIGlzbuKAmXQgaW5jbHVkZWQgYnkgYSBzaW5nbGUgcm91dGluZy1p bnN0YW5jZS4NCg0KPg0KPkkgYmVsaWV2ZSBpbiBhbGwgdGhlc2UgY2FzZXMgdGhlIGNob2ljZSBo YXMgdG8gYmUgbGltaXRlZCB0byAoMSkgTDMNCj5pbnRlcmZhY2VzLCBhbmQgKDIpIGJlbG9uZ2lu ZyB0byAib3duIiByb3V0aW5nIGluc3RhbmNlLiBUaGVzZQ0KPmNvbnN0cmFpbnRzIHdpbGwgaGF2 ZSB0byBiZSBjaGVja2VkIGluIHNlcnZlciBjb2RlIHNvbWVob3cgLSBJIHdvdWxkDQo+cHJlZmVy IHRvIGhhdmUgdGhlbSByZXByZXNlbnRlZCBpbiB0aGUgZGF0YSBtb2RlbC4NCj4NCj5CdXQgaWYg bm9ib2R5IHNoYXJlcyB0aGlzIGNvbmNlcm4gd2l0aCBtZSwgSSBhbSBub3QgZ29pbmcgdG8gYmxv Y2sgdGhlDQo+ZG9jdW1lbnQgb24gdGhpcyBpc3N1ZS4NCg0KSeKAmWQgYWxzbyBiZSBpbnRlcmVz dGVkIGlmIGFueW9uZSBzaGFyZXMgdGhpcyBjb25jZXJuLg0KDQpUaGFua3MsDQpBY2VlIA0KDQoN Cj4NCj5MYWRhIA0KPg0KPj4gDQo+PiBPdGhlciB0aGFuIHRoZSBSb3V0aW5nIFlBTkcgRGVzaWdu IFRlYW0gaGF2aW5nIGNob3NlbiB0aGUgZmlyc3Qgb3B0aW9uIC0NCj4+IGFyZSB0aGVyZSBhbnkg b3RoZXIgb3BpbmlvbnM/DQo+PiANCj4+IFRoYW5rcywNCj4+IEFjZWUNCj4+IA0KPj4gT24gMTAv OS8xNSwgOTowMCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gKGFjZWUpIg0K Pj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhY2VlQGNpc2NvLmNvbT4g d3JvdGU6DQo+PiANCj4+PiBIaSBMYWRhLCANCj4+PiBJMlJTIGlzIG5vdCBjaGFydGVyZWQgdG8g ZG8gdGhlIGJhc2UgbW9kZWxzLiBUaGVyZSBhcmUgb3RoZXIgcm91dGluZw0KPj4+IG1vZGVscyB0 aGF0IHJlZmVyZW5jZSByb3V0aW5nLWNmZyBhbmQgZXZlbiBpbi1wcm9ncmVzcyBpbXBsZW1lbnRh dGlvbnMuDQo+Pj4gDQo+Pj4gT24gMTAvOS8xNSwgNDoxMyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgTGFkaXNsYXYgTGhvdGthIg0KPj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpLA0KPj4+PiANCj4+Pj4g SSBhbSBzb3JyeSBmb3IgY3Jvc3MtcG9zdGluZyBidXQgSSB0aGluayBpdCBpcyBoaWdoIHRpbWUg dG8gZGVjaWRlIHRoZQ0KPj4+PiByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZGF0YSBtb2RlbHMg aW4gaTJycy1yaWItZGF0YS1tb2RlbCBhbmQNCj4+Pj4gbmV0bW9kLXJvdXRpbmctY2ZnIEktRHMg YmVjYXVzZSB0aGV5IGNsZWFybHkgdGFyZ2V0IHRoZSBzYW1lDQo+Pj4+bWFuYWdlbWVudA0KPj4+ PiBkYXRhIGluIGEgcm91dGVyLiBJIGNhbiBzZWUgdGhyZWUgcG9zc2libGUgc2NlbmFyaW9zOg0K Pj4+PiANCj4+Pj4gMS4gVGhlIGkycnMtcmliIG1vZHVsZSB3aWxsIGJlIG1vZGlmaWVkIHRvIGF1 Z21lbnQNCj4+Pj4gaWV0Zi1yb3V0aW5nL2lldGYtaXB2WzQ2XS11bmljYXN0LXJvdXRpbmcuDQo+ Pj4gDQo+Pj4gVGhpcyB3b3VsZCBzZWVtIHRvIGJlIHRoZSBvYnZpb3VzIGNob2ljZS4NCj4+PiAN Cj4+Pj4gDQo+Pj4+IDIuIFRoZSBzY29wZSBvZiBpZXRmLXJvdXRpbmcgd2lsbCBiZSBjaGFuZ2Vk IHNvIHRoYXQgaXQgd291bGQgYWRkcmVzcw0KPj4+PiBvbmx5IGhvc3Qgcm91dGluZyBhbmQgc2lt cGxlIHJvdXRlcnMuIFRoZSBtb2RlbGxpbmcgd29yayBmb3IgYWR2YW5jZWQNCj4+Pj4gcm91dGVy cyB3aWxsIGJlIGRvbmUgZWxzZXdoZXJlLg0KPj4+PiANCj4+Pj4gMy4gVGhlIHdvcmsgb24gbmV0 bW9kLXJvdXRpbmctY2ZnIHdpbGwgYmUgc3RvcHBlZC4NCj4+PiANCj4+PiBBIGZvdXJ0aCBvcHRp b24gd291bGQgYmUgZm9yIG1lIHRvIHRha2Ugb3ZlciBvd25lcnNoaXAsIG1vdmUgdGhlIHdvcmsN Cj4+PnRvDQo+Pj4gdGhlIFJURyBXRywgYW5kIHdl4oCZZCByZWNydWl0IHNvbWUgc3Ryb25nIGF1 dGhvcnMvcmV2aWV3ZXJzIGZyb20NCj4+Pm9wZXJhdG9ycw0KPj4+IGFuZCBvdGhlciB2ZW5kb3Jz IChpbnZvbHZpbmcgdGhlIEFEcyBpbiBzZWxlY3Rpb24pLg0KPj4+IA0KPj4+IFRoYW5rcywNCj4+ PiBBY2VlIA0KPj4+IA0KPj4+IA0KPj4+PiANCj4+Pj4gT3BpbmlvbnM/DQo+Pj4+IA0KPj4+PiBU aGFua3MsIExhZGENCj4+Pj4gDQo+Pj4+IC0tDQo+Pj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklD IExhYnMNCj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4gDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGth LCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQoNCg== From nobody Tue Oct 13 12:13:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE361A88F9 for ; Tue, 13 Oct 2015 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r7ss2A4irkN for ; Tue, 13 Oct 2015 12:13:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A7B1A8893 for ; Tue, 13 Oct 2015 12:13:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 149BB948; Tue, 13 Oct 2015 21:13:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gmWS4ZJL2bqP; Tue, 13 Oct 2015 21:13:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 21:13:54 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 210F120053; Tue, 13 Oct 2015 21:13:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 48i90Qp9gZgF; Tue, 13 Oct 2015 21:13:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 925642004E; Tue, 13 Oct 2015 21:13:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5DD9737B2B9C; Tue, 13 Oct 2015 21:13:51 +0200 (CEST) Date: Tue, 13 Oct 2015 21:13:50 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20151013191348.GB67325@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" References: <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561D0048.5070106@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561D0048.5070106@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 19:13:58 -0000 On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote: > >As said before, an OS kernel usually does not track where resource > >parameters were coming from. (An interface has a set of IP addresses > >and the kernel usually does not know which addresses were coming from > >a configuration daemon, a dhcp daemon, a tunneling daemon, a command > >line utility, ...) The same may be true for line card. So in order to > >implement a very tight definition, one has to either 'guess' which > >'subset' of operational state can be related 'somehow' to the intended > >config and then report the result of the guess work as applied config > >or one would have to to change daemons/kernels/linecards to have a > >tracking number or something like that. > > Inferring the applied config state from the operation state is one way > of doing this. > > An alternative way is for the NC/RC server to maintain separate internal > state for intended vs applied cfg nodes. Then the NC/RC server would > update the applied cfg node when the internal IPC to program that > configuration had completed for all affected subsystems. But the reality is that the NC/RC won't know. I invoke a system call to tell the kernel what I want changed. The kernel sometimes says OK before all components have been finally updated. The problem remains to define what exactly applied config is. So are we only talking about implementations that do not initiate the 'IPC' immediately or that initiate the 'IPC' but may not wait for a completion of the 'IPC'? Since this all sounds somewhat academic, do we have operational evidence that NC/RC implementations do exhibit significant delays between ACKing a config change and the config change becoming communicated to the subsystems affected? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 12:23:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B21A894A for ; Tue, 13 Oct 2015 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7kw4kRyFLah for ; Tue, 13 Oct 2015 12:23:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5BA1A8949 for ; Tue, 13 Oct 2015 12:23:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58288948; Tue, 13 Oct 2015 21:23:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oVDmC9AT65M1; Tue, 13 Oct 2015 21:23:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 21:23:40 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AC3620053; Tue, 13 Oct 2015 21:23:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ej6JJ8iB5FQn; Tue, 13 Oct 2015 21:23:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A5082004E; Tue, 13 Oct 2015 21:23:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5407737B2C09; Tue, 13 Oct 2015 21:23:38 +0200 (CEST) Date: Tue, 13 Oct 2015 21:23:37 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151013192337.GC67325@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" References: <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 19:23:45 -0000 On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote: > > > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder wrote: > > > > On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote: > >> > >> This is a notice to start a NETMOD WG last call for the document: > >> > >> Defining and Using Metadata with YANG > >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 > >> > >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT. > >> We are not only interested in receiving defect reports, we are equally > >> interested in statements of the form: > >> > > > > I am concerned about this text: > > > > Annotations modify the schema of datastores and/or management > > protocol messages, and may also change their semantics. Therefore, > > due care has to be exercised when introducing annotations in > > network management systems in order to avoid interoperability > > problems and software failures. > > > > I think we should actually very clearly discourage annotations that > > modify the schema of datastores and/or management protocol messages > > instead of assuming all annotations are free to do so. > > Annotations modify the schemas by definition because otherwise XML attributes, and objects in JSON encoding whose names start with "@", are not allowed. > For me, the schema of a datastore is the YANG data model. I do not want annotations that change the YANG data model of a datastore. Perhaps you mean something different but then the text allows multiple interpretations and hence it is problematic. Annotations should add metadata but I think metadata must not change the semantics of the data model itself. I am also concerned if metadata changes the semantics of protocol messages. I am not interested in standards-track mechanisms that at the end increase the chances of interoperability problems and software failures. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 12:55:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399C1A89E9 for ; Tue, 13 Oct 2015 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuu-zLei27zI for ; Tue, 13 Oct 2015 12:55:41 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E92F61A8980 for ; Tue, 13 Oct 2015 12:55:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ogq5gakPP6vPVp2zbbVJg7rHdMhLEenthVLIep0/YolUXScqjdK/ob4yZJyU4FDn; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zm5fY-0006bw-L4 for netmod@ietf.org; Tue, 13 Oct 2015 15:55:32 -0400 Received: from 76.254.55.129 by webmail.earthlink.net with HTTP; Tue, 13 Oct 2015 15:55:32 -0400 Message-ID: <3515254.1444766132543.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Tue, 13 Oct 2015 12:55:32 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edcdc5cfc244ef5a29c423d34ca399ff47350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 19:55:42 -0000 Hi - >From: David Reid >Sent: Oct 9, 2015 2:03 PM >To: netmod@ietf.org >Subject: [netmod] 6020bis more than one revision of a module > >I'm reviewing 6020bis since it is in working group last call. >I see a new requirement that a server MUST NOT implement >more than one revision of a module. I understand that supporting >more than one revision can cause problems, but I expect that >it will happen in practice. I know it happens sometimes with >MIBs in SNMP. I think MUST NOT is too strong. I've encountered the same phenomenon in the SNMP universe, so if I expected Netconf to used as a replacement for SNMP I'd have the same concern. Randy From nobody Tue Oct 13 13:06:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE01E1A8A52 for ; Tue, 13 Oct 2015 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhojDZPPi7uy for ; Tue, 13 Oct 2015 13:06:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DE51A8A48 for ; Tue, 13 Oct 2015 13:06:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 06B9B8FF; Tue, 13 Oct 2015 22:06:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id y0t48ef1SxUc; Tue, 13 Oct 2015 22:06:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Oct 2015 22:06:38 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 188D920053; Tue, 13 Oct 2015 22:06:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F72iEHprCZrR; Tue, 13 Oct 2015 22:06:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA1E12004E; Tue, 13 Oct 2015 22:06:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 56FBF37B2CA9; Tue, 13 Oct 2015 22:06:36 +0200 (CEST) Date: Tue, 13 Oct 2015 22:06:35 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20151013200635.GA67510@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <3515254.1444766132543.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3515254.1444766132543.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:06:43 -0000 On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote: > Hi - > > >From: David Reid > >Sent: Oct 9, 2015 2:03 PM > >To: netmod@ietf.org > >Subject: [netmod] 6020bis more than one revision of a module > > > >I'm reviewing 6020bis since it is in working group last call. > >I see a new requirement that a server MUST NOT implement > >more than one revision of a module. I understand that supporting > >more than one revision can cause problems, but I expect that > >it will happen in practice. I know it happens sometimes with > >MIBs in SNMP. I think MUST NOT is too strong. > > I've encountered the same phenomenon in the SNMP universe, > so if I expected Netconf to used as a replacement for SNMP > I'd have the same concern. > Perhaps you can detail what it means to support multiple revisions of a module at the same time. Are you saying YANG needs a way to slice modules such that for example interface ethernet0 can support revision X of an Ethernet data model while interface ethernet1 supports revision Y of an Ethernet data model? If so, support for per resource data model revision is not really part of YANG nor is it really part of NETCONF I think. (Note that YANG does support mechanisms such as features that allow to design data models in a way that they can be backwards compatible.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Oct 13 13:22:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96B1A8A97 for ; Tue, 13 Oct 2015 13:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RmC7khKa7TPi for ; Tue, 13 Oct 2015 13:22:34 -0700 (PDT) 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 9D1631A8A78 for ; Tue, 13 Oct 2015 13:22:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Z6Zl5EDDWPktPiMY6UDzIPy8iLWJwSVXzZaCsvTaYESqqHumcZdJNoA68IzgOpTD; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zm65c-0006p3-VK for netmod@ietf.org; Tue, 13 Oct 2015 16:22:28 -0400 Received: from 76.254.55.129 by webmail.earthlink.net with HTTP; Tue, 13 Oct 2015 16:22:28 -0400 Message-ID: <2221448.1444767748892.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Tue, 13 Oct 2015 13:22:28 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edd814f3f3cbba8ab5d2c34559ee74f7ef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:22:36 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Oct 13, 2015 1:06 PM >To: Randy Presuhn >Cc: netmod@ietf.org >Subject: Re: [netmod] 6020bis more than one revision of a module > >On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote: >> Hi - >> >> >From: David Reid >> >Sent: Oct 9, 2015 2:03 PM >> >To: netmod@ietf.org >> >Subject: [netmod] 6020bis more than one revision of a module >> > >> >I'm reviewing 6020bis since it is in working group last call. >> >I see a new requirement that a server MUST NOT implement >> >more than one revision of a module. I understand that supporting >> >more than one revision can cause problems, but I expect that >> >it will happen in practice. I know it happens sometimes with >> >MIBs in SNMP. I think MUST NOT is too strong. >> >> I've encountered the same phenomenon in the SNMP universe, >> so if I expected Netconf to used as a replacement for SNMP >> I'd have the same concern. >> > >Perhaps you can detail what it means to support multiple revisions of >a module at the same time. Are you saying YANG needs a way to slice >modules such that for example interface ethernet0 can support revision >X of an Ethernet data model while interface ethernet1 supports >revision Y of an Ethernet data model? This is a fairly typical situation. >If so, support for per resource >data model revision is not really part of YANG nor is it really part >of NETCONF I think. Yes. I continue to consider this a fundamental deficiency, but recognize that there seems to be little interest in the WG in doing anything about it. >(Note that YANG does support mechanisms such as >features that allow to design data models in a way that they can be >backwards compatible.) That's adequate for device management, particularly for single-vendor closed boxes, but not for configuration management, and especially not for configuration management of open systems. Again, I recognize that I hold a minority viewpoint, and the WG has chosen a different path. Randy From nobody Tue Oct 13 15:07:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701621A6F52 for ; Tue, 13 Oct 2015 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZVXVGAE-XfJ for ; Tue, 13 Oct 2015 15:07:43 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 6A4F41A6F87 for ; Tue, 13 Oct 2015 15:07:42 -0700 (PDT) Received: by lbwr8 with SMTP id r8so33665921lbw.2 for ; Tue, 13 Oct 2015 15:07:40 -0700 (PDT) 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=6DZ8vPh+EmV42LGuRB8IVLaF8IuimAUxYlk+2njsqU8=; b=dwe2Pm2I8So6v4wvdLIBCNdV86YocFMbsXhv7kvu8XCyGKCk1jBdxl9+vWltHp4PGG nBvkYhKTg045dcTs8oQAGm0Qwwcd6CKAC1M9rGwdsO8T0SkT+gpqA/2EnmBwdnJd690c VrB/8rLy1mFvryB5e0wgVEuWC5Em8bpyHflzicolYRPijhx4CMV9Jccy3FS8lgCiR42D 9tq9/+U0Nbt1ubf24QXTmMW9NGRgqTeat/afw0q4lzXntIouhlBhyXV6bn6BG8+FQOI1 kpoltyHnWoogiX4iZMSyoF/mKf4WkD51CRtPv9Z11GN/McqtwzCl5p1se/XFFLvQLivp 2f4Q== X-Gm-Message-State: ALoCoQnbAwETZgCG/wy9vh517OQkjzyDdJ4BwMJLD/owH36l9IDPd6esMM6gTQrCBtwwQOgLi+Hw MIME-Version: 1.0 X-Received: by 10.112.181.71 with SMTP id du7mr15917886lbc.37.1444774060384; Tue, 13 Oct 2015 15:07:40 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 13 Oct 2015 15:07:40 -0700 (PDT) In-Reply-To: <2221448.1444767748892.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <2221448.1444767748892.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Tue, 13 Oct 2015 15:07:40 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c3715ca68359052203acaf Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:07:46 -0000 --001a11c3715ca68359052203acaf Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2015 at 1:22 PM, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Oct 13, 2015 1:06 PM > >To: Randy Presuhn > >Cc: netmod@ietf.org > >Subject: Re: [netmod] 6020bis more than one revision of a module > > > >On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote: > >> Hi - > >> > >> >From: David Reid > >> >Sent: Oct 9, 2015 2:03 PM > >> >To: netmod@ietf.org > >> >Subject: [netmod] 6020bis more than one revision of a module > >> > > >> >I'm reviewing 6020bis since it is in working group last call. > >> >I see a new requirement that a server MUST NOT implement > >> >more than one revision of a module. I understand that supporting > >> >more than one revision can cause problems, but I expect that > >> >it will happen in practice. I know it happens sometimes with > >> >MIBs in SNMP. I think MUST NOT is too strong. > >> > >> I've encountered the same phenomenon in the SNMP universe, > >> so if I expected Netconf to used as a replacement for SNMP > >> I'd have the same concern. > >> > > > >Perhaps you can detail what it means to support multiple revisions of > >a module at the same time. Are you saying YANG needs a way to slice > >modules such that for example interface ethernet0 can support revision > >X of an Ethernet data model while interface ethernet1 supports > >revision Y of an Ethernet data model? > > This is a fairly typical situation. > > >If so, support for per resource > >data model revision is not really part of YANG nor is it really part > >of NETCONF I think. > > Yes. I continue to consider this a fundamental deficiency, but > recognize that there seems to be little interest in the WG in > doing anything about it. > > >(Note that YANG does support mechanisms such as > >features that allow to design data models in a way that they can be > >backwards compatible.) > > That's adequate for device management, particularly for > single-vendor closed boxes, but not for configuration management, > and especially not for configuration management of open systems. > Again, I recognize that I hold a minority viewpoint, and the WG > has chosen a different path. > > This is a common situation, but not really a feature. The foo-knob range is increased from 1 - 10 to 1 - 20. Some new cards support 1 - 20 and some other cards only support 1 - 10. There seems to be 3 solutions, none of which are very good: 1) document everything: return lots of instance-level conformance information and expect the client to sort it out 2) Advertise the newer version and let the client figure out that some instances only allow 1 - 10 3) Advertise the older version and let the client figure out that some instances allow 1 - 20. YANG says to do (3). This seems most correct to me. > Randy > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c3715ca68359052203acaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 13, 2015 at 1:22 PM, Randy Presuhn <randy_presu= hn@mindspring.com> wrote:
H= i -

>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
>Sent: Oct 13, 2015 1:06 PM
>To: Randy Presuhn <r= andy_presuhn@mindspring.com>
>Cc: netmod@ietf.org
>Subject: Re: [netmod] 6020bis more than one revision of a module
>
>On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote:
>> Hi -
>>
>> >From: David Reid <reid@snm= p.com>
>> >Sent: Oct 9, 2015 2:03 PM
>> >To: netmod@ietf.org
>> >Subject: [netmod] 6020bis more than one revision of a module >> >
>> >I'm reviewing 6020bis since it is in working group last ca= ll.
>> >I see a new requirement that a server MUST NOT implement
>> >more than one revision of a module. I understand that supporti= ng
>> >more than one revision can cause problems, but I expect that >> >it will happen in practice. I know it happens sometimes with >> >MIBs in SNMP. I think MUST NOT is too strong.
>>
>> I've encountered the same phenomenon in the SNMP universe,
>> so if I expected Netconf to used as a replacement for SNMP
>> I'd have the same concern.
>>
>
>Perhaps you can detail what it means to support multiple revisions of >a module at the same time. Are you saying YANG needs a way to slice
>modules such that for example interface ethernet0 can support revision<= br> >X of an Ethernet data model while interface ethernet1 supports
>revision Y of an Ethernet data model?

This is a fairly typical situation.

>If so, support for per resource
>data model revision is not really part of YANG nor is it really part >of NETCONF I think.

Yes.=C2=A0 I continue to consider this a fundamental deficiency, but
recognize that there seems to be little interest in the WG in
doing anything about it.

>(Note that YANG does support mechanisms such as
>features that allow to design data models in a way that they can be
>backwards compatible.)

That's adequate for device management, particularly for
single-vendor closed boxes, but not for configuration management,
and especially not for configuration management of open systems.
Again, I recognize that I hold a minority viewpoint, and the WG
has chosen a different path.


This is a common situation, but not re= ally a feature.
The foo-knob range is increased from 1 - 10 to 1 = - 20.
Some new cards support 1 - 20 and some other cards only sup= port 1 - 10.

There seems to be 3 solutions, none o= f which are very good:

1) document everything: ret= urn lots of
instance-level conformance information and expect the= client
to sort it out

2) Advertise the = newer version and let the client figure out
that some instances o= nly allow 1 - 10

3) Advertise the older version an= d let the client figure out
that some instances allow 1 - 20.


YANG says to do (3).
This se= ems most correct to me.



<= div>=C2=A0
Randy

Andy
=C2=A0

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

--001a11c3715ca68359052203acaf-- From nobody Tue Oct 13 15:24:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BC1A1A8F for ; Tue, 13 Oct 2015 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ssKP0RKLAHd for ; Tue, 13 Oct 2015 15:24:38 -0700 (PDT) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (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 F0AB51AC3AE for ; Tue, 13 Oct 2015 15:23:21 -0700 (PDT) Received: by lfaz124 with SMTP id z124so3176876lfa.1 for ; Tue, 13 Oct 2015 15:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=P0+YwzfG+cj6gjwr4FWxjcGl/Hx+RUUTBQPlBmdosIk=; b=Blh5RAdAx+1KlGPChzwMQYM4geWQFa1140l4bnbn5ThwQ/81xZtTv2MeNUT2vq/SxW 3/OheNHueaKLktQIicHlDvIoVchF537aU/K6oIxOhOvte/Os4D2KinJzBrtpTkYZuA0j +cBQavn/5Sl0uuRKVD3xtAbG+TCF88k+hfw1z2kYLC1zmP2KL9HgbD13Ril+MaxB7hCm kmFOh5YsjPK1u7b1cIqR4MyM0CePJpUoFnmviEFbfAuQbLD2vJ5P+3qSYCvHWhP+LP8L 9vvpXdRjSHYIOJde++rHcRgr+yWwlm/mlsoJehXx+IHRM8rcG97OsNTmrxfOCP/DyAbj G8aw== X-Gm-Message-State: ALoCoQlzA+9uXTi8PdaioboafMSnAXo98Gi9psL1UUSUQU3eiirpi5p28p8A4jzJnNZhosFkl8nK MIME-Version: 1.0 X-Received: by 10.25.155.75 with SMTP id d72mr10582379lfe.33.1444774999705; Tue, 13 Oct 2015 15:23:19 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 13 Oct 2015 15:23:19 -0700 (PDT) In-Reply-To: <20151013191348.GB67325@elstar.local> References: <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561D0048.5070106@cisco.com> <20151013191348.GB67325@elstar.local> Date: Tue, 13 Oct 2015 15:23:19 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Robert Wilton , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11401bd2a37591052203e45d Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:24:41 -0000 --001a11401bd2a37591052203e45d Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote: > > >As said before, an OS kernel usually does not track where resource > > >parameters were coming from. (An interface has a set of IP addresses > > >and the kernel usually does not know which addresses were coming from > > >a configuration daemon, a dhcp daemon, a tunneling daemon, a command > > >line utility, ...) The same may be true for line card. So in order to > > >implement a very tight definition, one has to either 'guess' which > > >'subset' of operational state can be related 'somehow' to the intended > > >config and then report the result of the guess work as applied config > > >or one would have to to change daemons/kernels/linecards to have a > > >tracking number or something like that. > > > > Inferring the applied config state from the operation state is one way > > of doing this. > > > > An alternative way is for the NC/RC server to maintain separate internal > > state for intended vs applied cfg nodes. Then the NC/RC server would > > update the applied cfg node when the internal IPC to program that > > configuration had completed for all affected subsystems. > > But the reality is that the NC/RC won't know. I invoke a system call > to tell the kernel what I want changed. The kernel sometimes says OK > before all components have been finally updated. The problem remains > to define what exactly applied config is. So are we only talking about > implementations that do not initiate the 'IPC' immediately or that > initiate the 'IPC' but may not wait for a completion of the 'IPC'? > > I agree -- even closed system code can be layered such that the server does not know if the command has been fully applied or not. > Since this all sounds somewhat academic, do we have operational > evidence that NC/RC implementations do exhibit significant delays > between ACKing a config change and the config change becoming > communicated to the subsystems affected? > > I have asked this question several times, but no answer so far. It certainly depends on the data models and the implementation. How slow is slow enough so that retrieving a lot of meta-data is worthwhile? 5 sec? 5 min? 5 hours? Nobody seems to know. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11401bd2a37591052203e45d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wi= lton wrote:
> >As said before, an OS kernel usually does not track where resource=
> >parameters were coming from. (An interface has a set of IP address= es
> >and the kernel usually does not know which addresses were coming f= rom
> >a configuration daemon, a dhcp daemon, a tunneling daemon, a comma= nd
> >line utility, ...) The same may be true for line card. So in order= to
> >implement a very tight definition, one has to either 'guess= 9; which
> >'subset' of operational state can be related 'somehow&= #39; to the intended
> >config and then report the result of the guess work as applied con= fig
> >or one would have to to change daemons/kernels/linecards to have a=
> >tracking number or something like that.
>
> Inferring the applied config state from the operation state is one way=
> of doing this.
>
> An alternative way is for the NC/RC server to maintain separate intern= al
> state for intended vs applied cfg nodes.=C2=A0 Then the NC/RC server w= ould
> update the applied cfg node when the internal IPC to program that
> configuration had completed for all affected subsystems.

But the reality is that the NC/RC won't know. I invoke a system call to tell the kernel what I want changed. The kernel sometimes says OK
before all components have been finally updated. The problem remains
to define what exactly applied config is. So are we only talking about
implementations that do not initiate the 'IPC' immediately or that<= br> initiate the 'IPC' but may not wait for a completion of the 'IP= C'?


I agree -- even closed system code can= be layered such that the
server does not know if the command has= been fully applied or not.

=C2=A0
Since this all sounds somewhat academic, do we have operational
evidence that NC/RC implementations do exhibit significant delays
between ACKing a config change and the config change becoming
communicated to the subsystems affected?


I have asked this question several times, but no ans= wer so far.
It certainly depends on the data models and the imple= mentation.
How slow is slow enough so that retrieving a lot of me= ta-data is worthwhile?=C2=A0
5 sec? 5 min? 5 hours?=C2=A0 Nobody = seems to know.


=C2=A0
/js


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

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

--001a11401bd2a37591052203e45d-- From nobody Tue Oct 13 20:52:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4FA1B2AF0 for ; Tue, 13 Oct 2015 20:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdNDeehByub4 for ; Tue, 13 Oct 2015 20:52:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1BD1B2AEF for ; Tue, 13 Oct 2015 20:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8380; q=dns/txt; s=iport; t=1444794774; x=1446004374; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2Tfery1iyqorTZUbhiEO/0RiToFrbhBrmec18ZMB9o8=; b=S4n+rCNwks0AUq2b3rPAgiska+h1BEKzILLGVDq+n1zMg+3PFKFnaZy+ C0dkfvbfG10MNddKAD9f2+O8H5gxCstFrhTEGGFjiLbhzHYh+sYOfCnTx I1Wq+V2NXjV7Ic2Mj+euu8msGhQ6yZPvnp+pSz5JOSUCPrnhkZgqshxus E=; X-Files: ATT00001.txt : 136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AwBL0B1W/5hdJa1egllNVG4GvgsOgVoXAQmCcoIKNUoCgUQ4FAEBAQEBAQF/C4QmAQEBBAEBASpBGwIBCBUQIQIlCxsBBgMBAQQTCAEFiCANwlIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnWEfoQ7AQE1IoIuT4ExBZYWAYJNgWGIZIFflkGDbgEfAUOEAnEBhTA6gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="txt'?scan'208,217";a="40878889" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 14 Oct 2015 03:52:53 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9E3qrYr012786 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Oct 2015 03:52:53 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 22:52:39 -0500 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.000; Tue, 13 Oct 2015 22:52:39 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wAAbwTg Date: Wed, 14 Oct 2015 03:52:39 +0000 Message-ID: <7a7ad667428641688a61540057aa13e1@XCH-ALN-013.cisco.com> References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> In-Reply-To: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/mixed; boundary="_004_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] FW: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 03:52:56 -0000 --_004_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_ Content-Type: multipart/alternative; boundary="_000_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_" --_000_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding to NETMOD as people might be interested... From: Eric Voit, October 13, 2015 11:37 PM There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forwarding to NETMOD a= s people might be interested…

 

From: Eric Voi= t, October 13, 2015 11:37 PM

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

· =     proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

· =     provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

· =     provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_-- --_004_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Wed, 14 Oct 2015 03:37:17 GMT"; modification-date="Wed, 14 Oct 2015 03:37:17 GMT" Content-ID: <177A0E6C42C94C4B83E281B08CB6CE39@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_7a7ad667428641688a61540057aa13e1XCHALN013ciscocom_-- From nobody Wed Oct 14 02:25:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFFD1A0383 for ; Wed, 14 Oct 2015 02:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pwvibFeIiUd for ; Wed, 14 Oct 2015 02:25:47 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B281B2CFC for ; Wed, 14 Oct 2015 02:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10539; q=dns/txt; s=iport; t=1444814747; x=1446024347; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=rtojND//Gw852/8jR9Q2/6nlZU8LLp4ImfecQ01qQto=; b=CtHJB8VPdv0WlbYBl/hICPx5zsbs9/0lDmM8muvPABZrSArpq7h1CsLI SxVTOj2nZ0kvqLzaR/8tELCABdAdt39zZH9Iv9qItPq+iq871gEMtGC1Z jrgVFyfCurWSPTElEaLce0ATEUKaULIo0pNMmGERJztIAK17cuBhlRiLZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AwAgBpHx5W/xbLJq1eglmCD7lhhCEBDYFagxOCCn8CgW8UAQEBAQEBAYEKhCcBAQRnEQEQCw4KCRYPCQMCAQIBRQYNBgIBAYgqwnMBAQEBAQEBAQEBAQEBAQEBAQEBGYZ2hH6FDQeELgWWFYgJhRKJE5J3HwEBQoQDPTOGbwEBAQ X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208,217";a="630324236" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Oct 2015 09:25:27 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9E9PRsb007490; Wed, 14 Oct 2015 09:25:27 GMT To: Martin Bjorklund References: <561CD668.6050401@cisco.com> <20151013.121749.1289164634073433213.mbj@tail-f.com> From: Robert Wilton Message-ID: <561E1F74.5050809@cisco.com> Date: Wed, 14 Oct 2015 10:25:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013.121749.1289164634073433213.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------030902050909030508030609" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:25:50 -0000 This is a multi-part message in MIME format. --------------030902050909030508030609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, I was looking at the YANG ABNF grammar a bit more last night (to see how hard it would be to write a parser for it) and I had a couple more observations. Apologies that this is after the WG last call ... 1. [Trivial] The indentation of the range statement in 9.3.5 looks wrong. 9.3.5. Usage Example typedef my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } I presume that it should be: 9.3.5. Usage Example typedef my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } 2. The description of yang-char (around page 186) doesn't seem to be quite accurate (relative to description of legal characters in 6. YANG Syntax), and given that it excludes character values outside the unicode range. ;; any Unicode character including tab, carriage return, and line ;; feed, but excluding the other C0 control characters, the surrogate ;; blocks, and the noncharacters. yang-char = %x9 / %xA / %xD / %x20-D7FF / ... Should this be: ;; any Unicode or IOS/IEC 10646 character including tab, carriage return, and line ;; feed, but excluding the other C0 control characters, the surrogate ;; blocks, and the noncharacters. yang-char = %x9 / %xA / %xD / %x20-D7FF / 3. There are lots of comments where "these stmts can appear in any order", e.g. linkageStmts = ;; these stmts can appear in any order *importStmt *includeStmt Am I right in interpreting that there can be any number of import and include statements and they can be interleaved in any arbitrary order? E.g. this specific example (but not in the general case) could equally have been written *(importStmt / includeStmt). Thanks, Rob On 13/10/2015 11:17, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi, >> >> I was looking the Yang 1.1 ABNF Grammar, and noticed various places >> where the rules are specified as the directive "a string that matches >> the rule XXX", e.g. >> >> yang-version-arg-str = < a string that matches the rule >> yang-version-arg > >> >> yang-version-arg = "1" >> >> >> It was slightly unclear to me exactly what is meant by this. >> >> Am I right in understanding that the only valid text that would match >> yang-version-arg-str would be the 3 character sequence *"1"* > No. > >> or is it >> more nuanced that this? > Yes. > > First of all the abnf-rule > > yang-version-arg = "1" > > matches a single character 1 (not three characters). > > Next, YANG has a very regular syntax that all statements follow: > > statement = keyword [argument] (";" / "{" *statement "}") > > The argument in this rule is a string. A string in YANG can be > specified in several ways: > > unqouted, e.g.: foo > quoted, e.g.: 'foo' or "foo" > concatenated, e.g: "f" + "oo" > > This cannot be expressed directly in ABNF. So when the YANG grammar > says "a string that matches the rule..." it means that the "expanded" > string matches the rule. > > So e.g., this is all legal: > > config false; > config "false"; > config 'f' + "alse"; > > > /martin > . > --------------030902050909030508030609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Martin,

I was looking at the YANG ABNF grammar a bit more last night (to see how hard it would be to write a parser for it) and I had a couple more observations.  Apologies that this is after the WG last call ...

1. [Trivial] The indentation of the range statement in 9.3.5 looks wrong.

9.3.5.  Usage Example

     typedef my-decimal {
       type decimal64 {
         fraction-digits 2;
           range "1 .. 3.14 | 10 | 20..max";
       }
     }

I presume that it should be:

9.3.5.  Usage Example

     typedef my-decimal {
       type decimal64 {
         fraction-digits 2;
         range "1 .. 3.14 | 10 | 20..max";
       }
     }


2.  The description of yang-char (around page 186) doesn't seem to be quite accurate (relative to description of legal characters in 6. YANG Syntax), and given that it excludes character values outside the unicode range.
   ;; any Unicode character including tab, carriage return, and line
   ;; feed, but excluding the other C0 control characters, the surrogate
   ;; blocks, and the noncharacters.
   yang-char = %x9 / %xA / %xD / %x20-D7FF /
   ...

Should this be:
   ;; any Unicode or IOS/IEC 10646 character including tab, carriage return, and line
   ;; feed, but excluding the other C0 control characters, the surrogate
   ;; blocks, and the noncharacters.
   yang-char = %x9 / %xA / %xD / %x20-D7FF /


3. There are lots of comments where "these stmts can appear in any order", e.g.

   linkageStmts       = ;; these stmts can appear in any order
                         *importStmt
                         *includeStmt

Am I right in interpreting that there can be any number of import and include statements and they can be interleaved in any arbitrary order?  E.g. this specific example (but not in the general case) could equally have been written *(importStmt / includeStmt).

Thanks,
Rob


On 13/10/2015 11:17, Martin Bjorklund wrote:
Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I was looking the Yang 1.1 ABNF Grammar, and noticed various places
where the rules are specified as the directive "a string that matches
the rule XXX", e.g.

   yang-version-arg-str = < a string that matches the rule
                           yang-version-arg >

   yang-version-arg    = "1"


It was slightly unclear to me exactly what is meant by this.

Am I right in understanding that the only valid text that would match
yang-version-arg-str would be the 3 character sequence *"1"*

No.


or is it
more nuanced that this?

Yes.

First of all the abnf-rule

  yang-version-arg = "1"

matches a single character 1 (not three characters).

Next, YANG has a very regular syntax that all statements follow:

     statement = keyword [argument] (";" / "{" *statement "}")

The argument in this rule is a string.  A string in YANG can be
specified in several ways:

   unqouted, e.g.:    foo
   quoted, e.g.:      'foo' or "foo"
   concatenated, e.g: "f" + "oo"

This cannot be expressed directly in ABNF.  So when the YANG grammar
says "a string that matches the rule..." it means that the "expanded"
string matches the rule.

So e.g., this is all legal:

    config false;
    config "false";
    config 'f' + "alse";


/martin
.

--------------030902050909030508030609-- From nobody Wed Oct 14 07:01:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587791A6FBC for ; Wed, 14 Oct 2015 07:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2CiD0Wnf8cT for ; Wed, 14 Oct 2015 07:01:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BB1421A8753 for ; Wed, 14 Oct 2015 07:01:15 -0700 (PDT) Received: from localhost (unknown [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 60EFE1CC00D9; Wed, 14 Oct 2015 16:01:18 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20151013192337.GC67325@elstar.local> References: <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> <20151013192337.GC67325@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 14 Oct 2015 16:01:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:01:19 -0000 Juergen Schoenwaelder writes: > On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote: >> >> > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder wrote: >> > >> > On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote: >> >> >> >> This is a notice to start a NETMOD WG last call for the document: >> >> >> >> Defining and Using Metadata with YANG >> >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 >> >> >> >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT. >> >> We are not only interested in receiving defect reports, we are equally >> >> interested in statements of the form: >> >> >> > >> > I am concerned about this text: >> > >> > Annotations modify the schema of datastores and/or management >> > protocol messages, and may also change their semantics. Therefore, >> > due care has to be exercised when introducing annotations in >> > network management systems in order to avoid interoperability >> > problems and software failures. >> > >> > I think we should actually very clearly discourage annotations that >> > modify the schema of datastores and/or management protocol messages >> > instead of assuming all annotations are free to do so. >> >> Annotations modify the schemas by definition because otherwise XML attributes, and objects in JSON encoding whose names start with "@", are not allowed. >> > > For me, the schema of a datastore is the YANG data model. I do not > want annotations that change the YANG data model of a datastore. > Perhaps you mean something different but then the text allows multiple > interpretations and hence it is problematic. It depends on the definition of "schema". In any case, annotations add some extra information that possibly might be persistent. FWIW, a RELAX NG schema generated for datastore + annotation is different from the one that's for datastore only. > > Annotations should add metadata but I think metadata must not change > the semantics of the data model itself. I am also concerned if > metadata changes the semantics of protocol messages. I am not Some annotations that are of this sort, such as "inactive", have already been discussed. The text you cited tries to explain possible pitfalls of such annotations, but my understanding of the consensus so far has been that it is not desirable to limit annotations to "benign" ones. I guess the considerations are similar to extensions in general: certain annotations may be a mandatory part of a protocol but is has to be said in the protocol spec. This is essentially what was done for NETCONF, and a special extension was used for defining the annotations (XML attributes). Lada > interested in standards-track mechanisms that at the end increase the > chances of interoperability problems and software failures. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Oct 14 07:41:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948951A8A75 for ; Wed, 14 Oct 2015 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWVS5FXXo1qv for ; Wed, 14 Oct 2015 07:41:07 -0700 (PDT) Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D785B1A8A4C for ; Wed, 14 Oct 2015 07:41:06 -0700 (PDT) From: Maxim Klyus To: "netmod@ietf.org" Thread-Topic: Yang based host IP subsystem configuration for dynamic QoS management and service chaining purpose Thread-Index: AdEGiDLqWDO6MzgAQ1GIOckNsKRBRwABfstQ Date: Wed, 14 Oct 2015 14:41:04 +0000 Message-ID: <11D8792D50CD7F46BFBA62E9E61D5A3AEF1B97E3@umaildb5.netcracker.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_11D8792D50CD7F46BFBA62E9E61D5A3AEF1B97E3umaildb5netcrac_" MIME-Version: 1.0 Archived-At: Cc: Anton Petrov Subject: Re: [netmod] Yang based host IP subsystem configuration for dynamic QoS management and service chaining purpose X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:41:11 -0000 --_000_11D8792D50CD7F46BFBA62E9E61D5A3AEF1B97E3umaildb5netcrac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Netmod, Homenet and MIF. We are looking for a proper place to discuss attached materials within IETF= . So I would like to say sorry we have to send this letter across several IET= F WGs simultaneously. The latest trends show that IP services are getting decoupled from the trad= itional Service Provider (SP) networks. Subscriber can get a lot of service= s from the 3rd party content providers typically delivered over public netw= orks, P2P services are also becoming more and more popular and the main pro= blem how to achieve service chaining and delivery with proper QoS. We would like to propose to use Yang for exchange between Subscriber's Devi= ce and Service Provider's. The Yang-modeled data is transferred over NetCon= f protocol from end-user device activation/management software towards a se= rvice agent software residing in Subscriber's Device. This approach allows = Service Provider to identify subscriber uniquely and his QoS requirements w= ithin the network with multiple IP interfaces on Subscriber's Devices. Mult= iple IP interfaces will be used for service distinction and delivery within= SP network. Host applications will be divided by application groups and bo= unded to a specific IP interface. Short solution description: 1) When connecting to the network, Subscriber's Device gets an IP address t= hrough DHCP and IP of SP's headend device management server through a DHCP = option. Alternative option is manual configuration of these IP settings; Se= rvice Agent Software installed on Subscriber's Device makes AAA request to = Service Provider's configuration management headend software. Based on requ= est SP can uniquely identify subscriber and subscriber's QoS requirements. = In case Device was authorized successfully, it gets a new IP interface (Tu= nnel or Loopback) and additional configuration parameters (e.g., routing, Q= oS). SP network also will be reconfigured dynamically to meet appropriate s= ervice delivery KPIs , however static SP environment configuration also pos= sible with fixed QoS and bandwidth for each interface based on predefined I= P pool. 2) Different application groups can originate service requests from differe= nt Host IP addresses. Service will be delivered to specific IP addresses wi= th appropriate additional handling within SP network and quality of service= . Subscriber's device can periodically send application-group QoS modificat= ion requests to allocate more/less priority or/and bandwidth for existing a= pplication groups within SP network. Benefits and Applicability: - SP don't need to know anything about external services locat= ed outside their network (Internet services, 3rd party content providers). = Service identification will be based on local Service Provider IP addresses= . - QoS configuration will be delivered dynamically based on sub= scriber needs. - SP don't need to make any dramatic updates for existing envi= ronment to identify services, because traffic identification and handling w= ill be based on IP stack only. P.S. Authors are looking forward to developing this approach further. The a= uthors have already tested the approach using manual settings Potential next steps include: - developing a Host Agent prototype; - developing a Headend's NETCONF/YANG adapter; - collaboration with a carrier to arrange a lab trial; - contributing the code to the open source community. If you have any kind of questions please feel free to contact us directly K= lyus@netcracker.com, petrov@netcracker.com Best Regards, Maxim Klyus ________________________________ The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons= or entities other than the intended recipient is prohibited. If you receiv= ed this in error, please contact the sender and delete the material from an= y computer. --_000_11D8792D50CD7F46BFBA62E9E61D5A3AEF1B97E3umaildb5netcrac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Netmod, Homenet and MIF.

 

We are looking for a proper pla= ce to discuss attached materials within IETF.

So I would like to say sorry we= have to send this letter across several IETF WGs simultaneously.

 

The latest trends show that IP = services are getting decoupled from the traditional Service Provider (SP) n= etworks. Subscriber can get a lot of services from the 3rd party content pr= oviders typically delivered over public networks, P2P services are also becoming more and more popular and the mai= n problem how to achieve service chaining and delivery with proper QoS.

We would like to propose to use= Yang for exchange between Subscriber’s Device and Service Provider&#= 8217;s. The Yang-modeled data is transferred over NetConf protocol from end= -user device activation/management software towards a service agent software residing in Subscriber’s Device. This appro= ach allows Service Provider to identify subscriber uniquely and his QoS req= uirements within the network with multiple IP interfaces on Subscriber̵= 7;s Devices. Multiple IP interfaces will be used for service distinction and delivery within SP network. Host applicat= ions will be divided by application groups and bounded to a specific IP int= erface.

 

Short solution description:

 

1) When connecting to the netwo= rk, Subscriber’s Device gets an IP address through DHCP and IP of SP&= #8217;s headend device management server through a DHCP option. Alternative= option is manual configuration of these IP settings; Service Agent Software installed on Subscriber’s Device makes AAA re= quest to Service Provider’s configuration management headend software= . Based on request SP can uniquely identify subscriber and subscriber’= ;s QoS requirements.  In case Device was authorized successfully, it gets a new IP interface (Tunnel or Loopback) and addition= al configuration parameters (e.g., routing, QoS). SP network also will be r= econfigured dynamically to meet appropriate service delivery KPIs , ho= wever static SP environment configuration also possible with fixed QoS and bandwidth for each interface based on pre= defined IP pool.

 

2) Different application groups= can originate service requests from different Host IP addresses. Service w= ill be delivered to specific IP addresses with appropriate additional handl= ing within SP network and quality of service. Subscriber’s device can periodically send application-group= QoS modification requests to allocate more/less priority or/and bandwidth = for existing application groups within SP network.

 

Benefits and Applicability:

 

-     =          SP don’t need to kno= w anything about external services located outside their network (Internet = services, 3rd party content providers). Service identification will be base= d on local Service Provider IP addresses.

 

-     =          QoS configuration will be = delivered dynamically based on subscriber needs.

 

-     =          SP don’t need to mak= e any dramatic updates for existing environment to identify services, becau= se traffic identification and handling will be based on IP stack only.=

 

 

P.S. Authors are looking forwar= d to developing this approach further. The authors have already tested the = approach using manual settings

Potential next steps include:

- developing a Host Agent proto= type;

- developing a Headend's NETCON= F/YANG adapter;

- collaboration with a carrier = to arrange a lab trial;

- contributing the code to the = open source community.

 

If you have any kind of questio= ns please feel free to contact us directly Klyus@netcracker.com, petrov@netcracker.com

 

Best Regards,

Ma= xim Klyus

 

=  

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer.  

--_000_11D8792D50CD7F46BFBA62E9E61D5A3AEF1B97E3umaildb5netcrac_-- From nobody Wed Oct 14 07:49:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481851A9110 for ; Wed, 14 Oct 2015 07:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3B_siHPTQWT for ; Wed, 14 Oct 2015 07:49:14 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4A1A9112 for ; Wed, 14 Oct 2015 07:49:09 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA08613; Wed, 14 Oct 2015 10:49:06 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t9EEn2F7078513; Wed, 14 Oct 2015 10:49:05 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201510141449.t9EEn2F7078513@mainfs.snmp.com> To: Randy Presuhn From: David Reid In-reply-to: Your message of Tue, 13 Oct 2015 12:55:32 -0700. <3515254.1444766132543.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Wed, 14 Oct 2015 10:49:02 -0400 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:49:18 -0000 > >I'm reviewing 6020bis since it is in working group last call. > >I see a new requirement that a server MUST NOT implement > >more than one revision of a module. I understand that supporting > >more than one revision can cause problems, but I expect that > >it will happen in practice. I know it happens sometimes with > >MIBs in SNMP. I think MUST NOT is too strong. > > I've encountered the same phenomenon in the SNMP universe, > so if I expected Netconf to used as a replacement for SNMP > I'd have the same concern. > > Randy Here is the situation I face. We put a netconf server in our SNMP Master agent. Using the MIB to YANG conversion rules from RFC 6643 we can provide read-only access (or read-write in a non-standard way) via netconf and yang to all of the MIB data. We have existing customers using different revisions of the same MIB module in different subagents. If they convert those MIB modules to YANG modules and access the information via netconf, it would violate the proposed rule. -David Reid From nobody Wed Oct 14 07:52:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53011A90EF for ; Wed, 14 Oct 2015 07:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrwI4W1DKSRY for ; Wed, 14 Oct 2015 07:52:12 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DABE1A90D5 for ; Wed, 14 Oct 2015 07:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19991; q=dns/txt; s=iport; t=1444834329; x=1446043929; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=sTSNbTJzZ2OrL4Av7gkR/3Fvk0R9wdwOynd85gCnnvU=; b=iLNBsO1uTMD483+/E365W/dPqLO6ctpDsLIM9ykTllwWE1+dMD0JNR+M EkZfPMS/o7Y9PDX0rkGq6k0eyn8DMrb6Hjr36S5qzHuyi719kBNAlh1FQ 9B9NjxeZ9kFSQoBNLtMpZ76fXeYWZOJdZ8jnz3MJ/ejGvVj8GQcbCaPmF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyAgDYax5W/xbLJq1bA4N6br0iAQ2BWhcBCYJyggo1SgKBeRQBAQEBAQEBgQqEJgEBAQMBAQEBIEsGBAYJAgkCEAgJFgQEAwICCQMCAQIBCQwfEQYBDAYCAQGIIggNkhGdNpNBAQEBAQEBAQMBAQEBAQEBAQEZBIZyhH6EQjsXEoJXgUUFlhWICYUSgViHO4ovhFmDbx8BAUKCER0WgT89M4ZvAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208,217";a="612216461" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Oct 2015 14:51:47 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9EEplYU023132; Wed, 14 Oct 2015 14:51:47 GMT To: Andy Bierman , Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" References: <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561D0048.5070106@cisco.com> <20151013191348.GB67325@elstar.local> From: Robert Wilton Message-ID: <561E6BF7.9040002@cisco.com> Date: Wed, 14 Oct 2015 15:51:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020403040700060601070709" Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:52:16 -0000 This is a multi-part message in MIME format. --------------020403040700060601070709 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 13/10/2015 23:23, Andy Bierman wrote: > > > On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder > > wrote: > > On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote: > > >As said before, an OS kernel usually does not track where resource > > >parameters were coming from. (An interface has a set of IP > addresses > > >and the kernel usually does not know which addresses were > coming from > > >a configuration daemon, a dhcp daemon, a tunneling daemon, a > command > > >line utility, ...) The same may be true for line card. So in > order to > > >implement a very tight definition, one has to either 'guess' which > > >'subset' of operational state can be related 'somehow' to the > intended > > >config and then report the result of the guess work as applied > config > > >or one would have to to change daemons/kernels/linecards to have a > > >tracking number or something like that. > > > > Inferring the applied config state from the operation state is > one way > > of doing this. > > > > An alternative way is for the NC/RC server to maintain separate > internal > > state for intended vs applied cfg nodes. Then the NC/RC server > would > > update the applied cfg node when the internal IPC to program that > > configuration had completed for all affected subsystems. > > But the reality is that the NC/RC won't know. I invoke a system call > to tell the kernel what I want changed. The kernel sometimes says OK > before all components have been finally updated. The problem remains > to define what exactly applied config is. > > So are we only talking about > implementations that do not initiate the 'IPC' immediately or that > initiate the 'IPC' but may not wait for a completion of the 'IPC'? > In essence, yes, that is my opinion. > > > I agree -- even closed system code can be layered such that the > server does not know if the command has been fully applied or not. I'm not sure whether it really matters whether the configuration is fully applied in this scenario. The server can only do the best that it can and mark the config as being applied once it thinks that it has been. To me the key question is what can the NMS observe. If after querying (or being notified) that the configuration has been applied it can detect that configuration isn't fully in effect then I could imagine that might be raised as an issue. Personally, I don't mind if the description of the applied configuration is defined as something like "as far as possible the configuration has been applied everywhere." But equally, I believe that the previously proposed descriptions (below) are good enough for the requirements draft. intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). So, is this text above acceptable, or does it need to be refined? > > Since this all sounds somewhat academic, do we have operational > evidence that NC/RC implementations do exhibit significant delays > between ACKing a config change and the config change becoming > communicated to the subsystems affected? > I don't have any operational evidence for NC, but I do for directly equivalent CLI configuration commits: For some of the larger routers, the configuration files can be over 1M lines long, potentially programming 100K+ interfaces/sub-interfaces, all of which can take 10's of minutes to apply the configuration depending on the configuration complexity and feature set. Today, the NC reply would be near the end of applying that configuration, but it is depends on the affected subsystems. Some subsystems process the configuration synchronously, some asynchronously, and for some it is a combination of the both (but normally with the bulk of it being synchronous). The time for one of those asynchronous subsystems processing a config change could be several minutes, e.g if the membership of a LAG interface was changed to add physical member interfaces on a new linecard. I.e. the side effect of a 1 line configuration change could result in the programmatic equivalent of 100,000's lines of configuration to be sent to a linecard. > > I have asked this question several times, but no answer so far. > It certainly depends on the data models and the implementation. > How slow is slow enough so that retrieving a lot of meta-data is > worthwhile? > 5 sec? 5 min? 5 hours? Nobody seems to know. OK, I don't know, but my guess would be 5 sec or less, on the following premise: - the large data centre providers and service providers want to be able to re-configure and optimize their networks on the fly in a similar way that virtual servers can be spun up/down today. - for such systems where lots of independent services may be being provisioned/unprovisioned it is easier for the management clients to program the configuration changes in an asynchronous fashion, by streaming config updates to the network elements. I.e. ideally the client does not want an NC server to block on each config change, it wants them to be processed concurrently, with the guarantee that the config updates are logically applied in order. - as soon as config is handled in an async fashion the client needs a way to determine when the configuration has actually been applied, so that it knows whether a particular service has been configured and is ready for the next stage of provisioning. Perhaps your question could also be asked in tomorrow's interim? Thanks, Rob > > > /js > > > > Andy > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------020403040700060601070709 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 13/10/2015 23:23, Andy Bierman wrote:


On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote:
> >As said before, an OS kernel usually does not track where resource
> >parameters were coming from. (An interface has a set of IP addresses
> >and the kernel usually does not know which addresses were coming from
> >a configuration daemon, a dhcp daemon, a tunneling daemon, a command
> >line utility, ...) The same may be true for line card. So in order to
> >implement a very tight definition, one has to either 'guess' which
> >'subset' of operational state can be related 'somehow' to the intended
> >config and then report the result of the guess work as applied config
> >or one would have to to change daemons/kernels/linecards to have a
> >tracking number or something like that.
>
> Inferring the applied config state from the operation state is one way
> of doing this.
>
> An alternative way is for the NC/RC server to maintain separate internal
> state for intended vs applied cfg nodes.  Then the NC/RC server would
> update the applied cfg node when the internal IPC to program that
> configuration had completed for all affected subsystems.

But the reality is that the NC/RC won't know. I invoke a system call
to tell the kernel what I want changed. The kernel sometimes says OK
before all components have been finally updated. The problem remains
to define what exactly applied config is.

So are we only talking about
implementations that do not initiate the 'IPC' immediately or that
initiate the 'IPC' but may not wait for a completion of the 'IPC'?
In essence, yes, that is my opinion.



I agree -- even closed system code can be layered such that the
server does not know if the command has been fully applied or not.

I'm not sure whether it really matters whether the configuration is fully applied in this scenario.  The server can only do the best that it can and mark the config as being applied once it thinks that it has been. 

To me the key question is what can the NMS observe.  If after querying (or being notified) that the configuration has been applied it can detect that configuration isn't fully in effect then I could imagine that might be raised as an issue.

Personally, I don't mind if the description of the applied configuration is defined as something like "as far as possible the configuration has been applied everywhere."  But equally, I believe that the previously proposed descriptions (below) are good enough for the requirements draft.


      intended configuration - this data represents the configuration
      state that the network operator intends the system to be in, and that
      has been accepted by the system as valid configuration.  This data is
      colloquially referred to as the 'configuration' of the system.

     applied configuration - this data represents the configuration
      state that the network element is actually in, i.e., the
      configuration state which is currently being being used by system
      components (e.g., control plane daemons, operating system
      kernels, line cards).

So, is this text above acceptable, or does it need to be refined?


 
Since this all sounds somewhat academic, do we have operational
evidence that NC/RC implementations do exhibit significant delays
between ACKing a config change and the config change becoming
communicated to the subsystems affected?

I don't have any operational evidence for NC, but I do for directly equivalent CLI configuration commits:

For some of the larger routers, the configuration files can be over 1M lines long, potentially programming 100K+ interfaces/sub-interfaces, all of which can take 10's of minutes to apply the configuration depending on the configuration complexity and feature set.
 
Today, the NC reply would be near the end of applying that configuration, but it is depends on the affected subsystems.  Some subsystems process the configuration synchronously, some asynchronously, and for some it is a combination of the both (but normally with the bulk of it being synchronous).

The time for one of those asynchronous subsystems processing a config change could be several minutes, e.g if the membership of a LAG interface was changed to add physical member interfaces on a new linecard.  I.e. the side effect of a 1 line configuration change could result in the programmatic equivalent of 100,000's lines of configuration to be sent to a linecard.


I have asked this question several times, but no answer so far.
It certainly depends on the data models and the implementation.
How slow is slow enough so that retrieving a lot of meta-data is worthwhile? 
5 sec? 5 min? 5 hours?  Nobody seems to know.
OK, I don't know, but my guess would be 5 sec or less, on the following premise:

 - the large data centre providers and service providers want to be able to re-configure and optimize their networks on the fly in a similar way that virtual servers can be spun up/down today.

 - for such systems where lots of independent services may be being provisioned/unprovisioned it is easier for the management clients to program the configuration changes in an asynchronous fashion, by streaming config updates to the network elements.  I.e. ideally the client does not want an NC server to block on each config change, it wants them to be processed concurrently, with the guarantee that the config updates are logically applied in order.

 - as soon as config is handled in an async fashion the client needs a way to determine when the configuration has actually been applied, so that it knows whether a particular service has been configured and is ready for the next stage of provisioning.

Perhaps your question could also be asked in tomorrow's interim?

Thanks,
Rob



 
/js


Andy
 

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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


--------------020403040700060601070709-- From nobody Wed Oct 14 07:59:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDF1A914B for ; Wed, 14 Oct 2015 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRh0ldiOOtiV for ; Wed, 14 Oct 2015 07:59:32 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F551A9149 for ; Wed, 14 Oct 2015 07:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7559; q=dns/txt; s=iport; t=1444834772; x=1446044372; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=cI+FrKnXfo65h6zbUrVp/pE4cq2LV+LjWekpMekp5b0=; b=QcqfNvm3uAxUwntrVcStPQy6HrSfwPIi3rgtt67BZgv7eUK7fkERuHE8 rFX7nA9w4vmInB2nECNde8HzkTeEf8wnQWBfuSNs8mWBzJQCQDMbJUBx6 TBqTIf3mrN7W7xDQBUuBeohdCEHVhVO4i6tzPjgykTIvT7nrO9n8neokV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AwAgD9bB5W/xbLJq1ewgoBDYFagxMygVh/AoF5FAEBAQEBAQF/C4QnAQEEOEARCxgJFgQLCQMCAQIBRQYNCAEBiCrDHAEBAQEBAQQBAQEBHoZ2g3iBBoRCUoQuAQSWFYgJhRKBWIc7ii+ISB8BAUKCER0WgT89hVslgSIBAQE X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208";a="612216539" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Oct 2015 14:59:30 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9EExT3f024526 for ; Wed, 14 Oct 2015 14:59:29 GMT To: "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> From: Robert Wilton Message-ID: <561E6DC5.1080402@cisco.com> Date: Wed, 14 Oct 2015 15:59:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013084814.GA66064@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:59:35 -0000 Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: > On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> On 06/10/2015 17:16, Juergen Schoenwaelder wrote: >>> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: >>>> Hi Kent, >>>> >>>> Feeding in the various input, I think that this is the best refinement >>>> that I've come up with: >>>> >>>> Synchronous configuration operation - A configuration request to update >>>> the running configuration of a server that is applied synchronously with >>>> respect to the client request. The server SHOULD ensure that the >>>> request is valid, and MUST fully effect the configuration change to all >>>> impacted components in the server, updating both the server's intended >>>> and applied configuration (see terms), before replying to the client. >>>> The reply to the client indicates whether there are any errors in the >>>> request or errors from applying the configuration change. >>> What does "SHOULD ensure that the request is valid" mean? RFC 6020 >>> says: >>> >>> When datastore processing is complete, the final contents MUST obey >>> all validation constraints. This validation processing is performed >>> at differing times according to the datastore. If the datastore is >>> or , these constraints MUST be enforced at the >>> end of the or operation. If the >>> datastore is , the constraint enforcement is delayed >>> until a or operation. >>> >>> Are we talking about datastore validation or validation of a request? >>> If the former, are we watering down a MUST to a SHOULD? >> Really it is datastore validation, particularly for an async request >> where the intended config nodes are updated before replying. I'm not >> intentionally trying to water down a MUST to a SHOULD, but Kent had >> concerns that my previous description using "semantically validate" >> would exclude an ephemeral datastore, so I was trying to water down the >> description and also describe the behaviour in a way that isn't specific >> to either RESTCONF/NETCONF or datastores. >> >> Perhaps, the start of sentence could simply be changed to: >> >> The server MUST fully effect the configuration change to all >> impacted components in the server ... >> >> And equivalently for the asynchronous case below: >> >> The server MUST update the server's intended configuration ... >> > Works for me. Sometimes less is more. > >>> And I would not be surprised if we also need this sooner or later: >>> >>> Mixed configuration server - a configuration server that processes >>> some configuration operations as synchronous configuration >>> operations and some configuration operations as asynchronous >>> configuration operations. >> Yes, I would expect that clients may want to define the expected >> behaviour, potentially on a per request basis. > I doubt that servers will offer clients to choose; I am more with Andy > that in real systems, depending on the data model, certain parts of a > data model may be synchronous while others may be asynchronous. > >>>> Any further comments? >>>> >>>> Based on the feedback from Andy and others, it seems that the prevailing >>>> view is that existing NETCONF and RESTCONF should be regarded as being >>>> asynchronous in their behaviour in that the config nodes in the running >>>> datastore only represent the intended configuration and not the applied >>>> configuration. >>> Depends on the definition of applied configuration - where is the latest >>> version of it? >> The last proposed text for intended/applied is as below: >> >> intended configuration - this data represents the configuration >> state that the network operator intends the system to be in, and >> that >> has been accepted by the system as valid configuration. This >> data is >> colloquially referred to as the 'configuration' of the system. >> >> applied configuration - this data represents the configuration >> state that the network element is actually in, i.e., the >> configuration state which is currently being being used by system >> components (e.g., control plane daemons, operating system >> kernels, line cards). > Well, sometimes the config goes to a control plane daemon and then to > the OS kernel and finally to the line cards. This definition leaves > some room what an applied configuration is (which is IMHO needed if > you want to have something implementable) and hence a NC server can > either be considered synchronous or asynchronous. > >> From Thursday's interim meeting, Rob Shakir clarified that the desired >> intention is that applied configuration should mean that the >> configuration is fully applied everywhere. I don't know if that means >> that the definition of applied configuration should be strengthened, or >> if it is sufficient? > As said before, an OS kernel usually does not track where resource > parameters were coming from. (An interface has a set of IP addresses > and the kernel usually does not know which addresses were coming from > a configuration daemon, a dhcp daemon, a tunneling daemon, a command > line utility, ...) The same may be true for line card. So in order to > implement a very tight definition, one has to either 'guess' which > 'subset' of operational state can be related 'somehow' to the intended > config and then report the result of the guess work as applied config > or one would have to to change daemons/kernels/linecards to have a > tracking number or something like that. > > Anyway, as long as a regular NC/RC server does not have to pay a price > for this applied config idea, I have no real problem with this since I > am sure the market will sort this out. > > /js > From nobody Wed Oct 14 08:24:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C4D1AC415 for ; Wed, 14 Oct 2015 08:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aLrOERMisbe for ; Wed, 14 Oct 2015 08:24:28 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3E79C1AC3FE for ; Wed, 14 Oct 2015 08:24:27 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA11603; Wed, 14 Oct 2015 11:24:23 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t9EFOIMt079084; Wed, 14 Oct 2015 11:24:19 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201510141524.t9EFOIMt079084@mainfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Tue, 13 Oct 2015 15:07:40 -0700. Date: Wed, 14 Oct 2015 11:24:18 -0400 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:24:30 -0000 > There seems to be 3 solutions, none of which are very good: > > 1) document everything: return lots of > instance-level conformance information and expect the client > to sort it out > > 2) Advertise the newer version and let the client figure out > that some instances only allow 1 - 10 > > 3) Advertise the older version and let the client figure out > that some instances allow 1 - 20. > > > YANG says to do (3). Where does YANG tell which version the server should advertise? -David Reid From nobody Wed Oct 14 08:25:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052551AC422 for ; Wed, 14 Oct 2015 08:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2bahorqz5qg for ; Wed, 14 Oct 2015 08:25:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332D11A916C for ; Wed, 14 Oct 2015 08:25:38 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 15:25:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 15:25:35 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Robert Wilton" Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAG+SAA= Date: Wed, 14 Oct 2015 15:25:35 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> In-Reply-To: <20151013084814.GA66064@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:kXtqVXO5ZYnH14k5+o+w8QuNj6y1Oej1x5swn/KE3VfU9+lKQWPrHX4qXhous5gvz5HAE5mOdCuLcw05zm4PbKUMB+15AGyJlZHOV4ug2LYJnACqp/2h159QYKSxsQ5J0MLcDYyB1mv5NVyhqPHcbw==; 24:Ufu/8x+X/vSxoC4d6t+gmrsU4LtE3aigCju166kT0UIQ5ug1kTm/8qvDP0DnXVzCrQg1XHHhA/Dh5ZSMeXAiL7nR6hcPX6uvjd2eZ0ZghH0=; 20:dt3Cr7ncW+y3v+A/U0G7tHst3Lkv6CRJtnwmYAqfX8G4yAVyXcQmDqAiNCVvKI5jJaEOJI5iW14st4yFlShveA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52314003)(122556002)(81156007)(64706001)(4001350100001)(11100500001)(40100003)(99286002)(92566002)(2950100001)(102836002)(5008740100001)(93886004)(5007970100001)(5001770100001)(5002640100001)(46102003)(10400500002)(106116001)(105586002)(2900100001)(106356001)(5001960100002)(5004730100002)(101416001)(86362001)(97736004)(76176999)(189998001)(50986999)(54356999)(36756003)(66066001)(87936001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1293AE164376EC4D883AD4D62527D0DA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 15:25:35.6832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:25:42 -0000 >Anyway, as long as a regular NC/RC server does not have to pay a price >for this applied config idea, I have no real problem with this since I >am sure the market will sort this out. This goes to the solution - that it should allow servers to opt-in to support applied config. I have also been thinking about market response. It is a bit frustrating to even think that solution might not be widely popular, but the reality is that I don't see how it can be widely implemented - and so maybe it will only be popular for datacenter operators? Kent // as a contributor From nobody Wed Oct 14 08:33:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3161AC442 for ; Wed, 14 Oct 2015 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDXv93VLXF9W for ; Wed, 14 Oct 2015 08:33:45 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 327C01AC7E7 for ; Wed, 14 Oct 2015 08:33:43 -0700 (PDT) Received: by lbbck17 with SMTP id ck17so49441924lbb.1 for ; Wed, 14 Oct 2015 08:33:41 -0700 (PDT) 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=vD9UCCwwHsDu7SdZJNCdyClkqqPc4ex1PsyE2Ux0bDA=; b=CenLHyhKdYc3cGfdI3mUyJPLn8c+YGGaid+FR3Ev0FsAGGzsjg6rxYyLyvPMVBJjwj 3WxVvQ/L+K2mIwE08Mk1fMoINN0DXYzICwo3fipQknV+s4KahfKinrKuryF2g2DDdtL1 s7ObMYzFJM7CykalkbLGKbL8m0W0JQaMYxuyObH6SurcbcMaqRwLhMq8J8ZvCkfOKhSy 5/2EXH8zdlQINwgEgZmorYXxTKDnBLMG1SC8iF1irjC/viLGeDPcADLMKLcCttjDjkMX WihIxBemWnxrFSp50NRPgy+FT0bMxKRkMhUgDK7Oru95JCKfy17dEgb5lhd3RVocvYwz DWZQ== X-Gm-Message-State: ALoCoQn3/gwIreGIupO/iLeOAP91bJtDnwQMLUIjBFNJZrXvRUs3LUO77XQu6sfn3ME6tDKp2bpS MIME-Version: 1.0 X-Received: by 10.112.161.168 with SMTP id xt8mr973709lbb.88.1444836821365; Wed, 14 Oct 2015 08:33:41 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Wed, 14 Oct 2015 08:33:41 -0700 (PDT) In-Reply-To: <201510141524.t9EFOIMt079084@mainfs.snmp.com> References: <201510141524.t9EFOIMt079084@mainfs.snmp.com> Date: Wed, 14 Oct 2015 08:33:41 -0700 Message-ID: From: Andy Bierman To: David Reid Content-Type: multipart/alternative; boundary=001a11c3cb367f135b0522124938 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] 6020bis more than one revision of a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:33:49 -0000 --001a11c3cb367f135b0522124938 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 8:24 AM, David Reid wrote: > > There seems to be 3 solutions, none of which are very good: > > > > 1) document everything: return lots of > > instance-level conformance information and expect the client > > to sort it out > > > > 2) Advertise the newer version and let the client figure out > > that some instances only allow 1 - 10 > > > > 3) Advertise the older version and let the client figure out > > that some instances allow 1 - 20. > > > > > > YANG says to do (3). > > Where does YANG tell which version the server should advertise? > > Not sure but advertising range 1 - 10 is safe since all instances support that. Presumably, the reason we advertise capabilities is so the client will only try operations that it thinks the server supports. The downside for inaccuracy is either (2) false advertising or (3) under-advertising -David Reid > > Andy --001a11c3cb367f135b0522124938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 14, 2015 at 8:24 AM, David Reid <reid@snmp.com> = wrote:
> There seems to be 3 solutions= , none of which are very good:
>
> 1) document everything: return lots of
> instance-level conformance information and expect the client
> to sort it out
>
> 2) Advertise the newer version and let the client figure out
> that some instances only allow 1 - 10
>
> 3) Advertise the older version and let the client figure out
> that some instances allow 1 - 20.
>
>
> YANG says to do (3).

Where does YANG tell which version the server should advertise?



Not sure but advertising range 1 - 10= is safe since all instances support that.

Presuma= bly, the reason we advertise capabilities is so the client will
o= nly try operations that it thinks the server supports.=C2=A0 The downside
for inaccuracy is either (2) false advertising or (3) under-advert= ising


-David Reid


Andy<= /div>

--001a11c3cb367f135b0522124938-- From nobody Wed Oct 14 10:11:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989FA1ACECB for ; Wed, 14 Oct 2015 10:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjNQB6-6cvu1 for ; Wed, 14 Oct 2015 10:11:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1530E1ACEC9 for ; Wed, 14 Oct 2015 10:11:45 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 091BD1AE044D; Wed, 14 Oct 2015 19:11:43 +0200 (CEST) Date: Wed, 14 Oct 2015 19:14:52 +0200 (CEST) Message-Id: <20151014.191452.1508719715698664237.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <561E1F74.5050809@cisco.com> References: <561CD668.6050401@cisco.com> <20151013.121749.1289164634073433213.mbj@tail-f.com> <561E1F74.5050809@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 17:11:46 -0000 Robert Wilton wrote: > Hi Martin, > > I was looking at the YANG ABNF grammar a bit more last night (to see > how hard it would be to write a parser for it) and I had a couple more > observations. Apologies that this is after the WG last call ... > > 1. [Trivial] The indentation of the range statement in 9.3.5 looks > wrong. > > 9.3.5. Usage Example > > typedef my-decimal { > type decimal64 { > fraction-digits 2; > range "1 .. 3.14 | 10 | 20..max"; > } > } > > > I presume that it should be: > > 9.3.5. Usage Example > > typedef my-decimal { > type decimal64 { > fraction-digits 2; > range "1 .. 3.14 | 10 | 20..max"; > } > } Fixed. > 2. The description of yang-char (around page 186) doesn't seem to be > quite accurate (relative to description of legal characters in 6. YANG > Syntax), and given that it excludes character values outside the > unicode range. Hmm, which characters are outside the unicode range? > ;; any Unicode character including tab, carriage return, and line > ;; feed, but excluding the other C0 control characters, the surrogate > ;; blocks, and the noncharacters. > yang-char = %x9 / %xA / %xD / %x20-D7FF / > ... > > > Should this be: > > ;; any Unicode or IOS/IEC 10646 character including tab, carriage return, > ;; and line > ;; feed, but excluding the other C0 control characters, the surrogate > ;; blocks, and the noncharacters. > yang-char = %x9 / %xA / %xD / %x20-D7FF / I think this would be ok. > 3. There are lots of comments where "these stmts can appear in any > order", e.g. > > linkageStmts = ;; these stmts can appear in any order > *importStmt > *includeStmt > > Am I right in interpreting that there can be any number of import and > include statements and they can be interleaved in any arbitrary > order? Yes. > E.g. this specific example (but not in the general case) could equally > have been written *(importStmt / includeStmt). Well, the grammar defines the canonical order. With the alternative rule above, the canonical order would be different. /martin From nobody Wed Oct 14 10:25:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91761ACED4 for ; Wed, 14 Oct 2015 10:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgizNq442UY9 for ; Wed, 14 Oct 2015 10:25:48 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7E71A88C6 for ; Wed, 14 Oct 2015 10:25:48 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id C3D2D1AE044D; Wed, 14 Oct 2015 19:25:47 +0200 (CEST) Date: Wed, 14 Oct 2015 19:28:57 +0200 (CEST) Message-Id: <20151014.192857.1892050522806470333.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis - sec. 5.6.4 comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 17:25:49 -0000 Ladislav Lhotka wrote: > Hi, > > regarding $subj: > > - What about extensions? Do modules defining them have to be > implemented? That is, is "default-revision" true or false for such > modules? The "default-revision" leaf doesn't exist in ietf-yang-libary. I will remove the note about aligning with ietf-yang-libary, and do: OLD: If a server implements a module A that imports a module C without specifying the revision date of module C, and the server does not implement C (e.g., if C only defines some typedefs), the server MUST list module C in the "/modules/module" list from "ietf-yang-library", and it MUST set the leaf "default-revision" to "true" for this module. NEW: If a server implements a module A that imports a module C without specifying the revision date of module C, and the server does not implement C (e.g., if C only defines some typedefs), the server MUST list module C in the "/modules/module" list from "ietf-yang-library", and it MUST set the leaf "conformance" to "import" for this module. > - Third paragraph: > > OLD > > This is regardless of if module B is imported by revision or not. > > NEW > > If module B is imported by revision, the corresponding "revision-date" > statement is ignored. I think your proposed text can be misunderstood. The "revision-date" statement is not ignored; typedefs etc. will be taken from the specified revision. /martin From nobody Wed Oct 14 10:39:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071EA1ACF1B for ; Wed, 14 Oct 2015 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc1CBBEXzrso for ; Wed, 14 Oct 2015 10:39:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127861ACD81 for ; Wed, 14 Oct 2015 10:39:39 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.300.14; Wed, 14 Oct 2015 17:39:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 17:39:37 +0000 From: Kent Watsen To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #4 (was #6: clarify impact of synchronous vs asynchronous) Thread-Index: AQHRBqdL0l29eNaqtkyfhrPfqyfSDw== Date: Wed, 14 Oct 2015 17:39:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:kySJPq5Y/Vvgmi/mlKyiCR/dwmJod9uAq3EABt20PhPl+clz89ywFDxspNOrjJ16G627ydQw2+pW00Zq2svJsnpP1SxP3RUJaJSwPb0Jyj5zjNUNMHi788qU3e1JtjUaFXJfo6qbfYZvhi0svm+pKw==; 24:/7tAjg/4fwCNjodd3f0yqQLYwFc4/jTUTNlUJJeEdzLrwL6IyEM24N10OBOhI9Bs4hgSkSnV4s2iztfs6ASMTI6LpYrNw9FSSsDRyv5sSt4=; 20:dTNA7hquV2vJM36P4I6gpLQGB7klagX0J90bSkbxKiRAdIleexLA/NUzGH0NzGaJFXcJthrGgqu6oVtCmHwrZg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(2501003)(189998001)(107886002)(101416001)(87936001)(5002640100001)(86362001)(97736004)(81156007)(54356999)(5004730100002)(122556002)(11100500001)(50986999)(5001770100001)(4001350100001)(2900100001)(5001960100002)(102836002)(5008740100001)(5007970100001)(92566002)(40100003)(16236675004)(10400500002)(36756003)(66066001)(83506001)(64706001)(106356001)(99286002)(105586002)(106116001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D24400E9E6E19kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 17:39:36.8682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Subject: Re: [netmod] opstate-reqs #4 (was #6: clarify impact of synchronous vs asynchronous) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 17:39:42 -0000 --_000_D24400E9E6E19kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert writes: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). So, is this text above acceptable, or does it need to be refined? [hat on] The discussion on these terms should happen on the opstate-reqs #4 thread. = Renaming subject line to reflect that. [hat off] Jonathan Hansford made a suggestion to somehow clarify that the intended an= d applied configurations were limited to YANG-defined configuration data. = Maybe we could do this to both terms: - this data represents the configuration... + YANG-defined data representing the configuration... Also, Juergen wrote: ...we probably need to add text below the definition of the term 'applied configuration' that acknowledges that this is grey area and the definition of applied configuration is fuzzy here by design. So, perhaps something like this? The system's ability to report applied configuration accurately may be limited in some cases, such as when the the configuration goes through an intermediate layer without an ability to inspect the lower layer. Kent --_000_D24400E9E6E19kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4AC8D97CF7F1604BBAAFB11457E27FB6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Robert writes:

      intended configuration - this data represent= s the configuration
      state that the network operator intends the = system to be in, and that
      has been accepted by the system as valid con= figuration.  This data is
      colloquially referred to as the 'configurati= on' of the system.

     applied configuration - this data represents the c= onfiguration
      state that the network element is actually i= n, i.e., the
      configuration state which is currently being= being used by system
      components (e.g., control plane daemons, ope= rating system
      kernels, line cards).

      So, is this text above acceptable, or does it need to = be refined?


[hat on]

The discussion on these terms should happen on the opstate-reqs #4 thread. =  Renaming subject line to reflect that.

[hat off] 

Jonathan Hansford made a suggesti= on to somehow clarify that the intended and applied configurations were lim= ited to YANG-defined configuration data.  Maybe we could do this to bo= th terms:

- this da= ta represents the configuration...
+ YANG-defined data representing the configuration...


Also, Juergen wrote:

...we = probably need to add text below the definition
of the= term 'applied configuration' that acknowledges that this is
grey a= rea and the definition of applied configuration is fuzzy here by
design= .

So, perhaps something like this?

The sy= stem's ability to report applied configuration accurately may be
limite= d in some cases, such as when the the configuration goes through
an int= ermediate layer without an ability to inspect the lower layer.


Kent

--_000_D24400E9E6E19kwatsenjunipernet_-- From nobody Wed Oct 14 11:00:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959AB1AC3E7 for ; Wed, 14 Oct 2015 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QFWid3FkzXQI for ; Wed, 14 Oct 2015 11:00:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFDC1AD0C6 for ; Wed, 14 Oct 2015 11:00:52 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 18:00:48 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 18:00:48 +0000 From: Kent Watsen To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" Thread-Index: AQHQ+5jp1v6hLihUyE+oXDRPZo9RIJ5WkcoAgBSIcwA= Date: Wed, 14 Oct 2015 18:00:48 +0000 Message-ID: References: <560D269E.30002@cisco.com> In-Reply-To: <560D269E.30002@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:5vZ506OLhgAVlo/GfUx6am9RoLURUi2SIomLHT/5V1exFgXbt5Dl9Xct6RCz4dnKYKH5eXO7wGvsvv3GRpkqQSA83vZRAVYpWKZVAx5cFlU4/vD8R2CPITyqAoicCJzrlBbLoRGqdu4zFDcIpDJ0Xw==; 24:DsZc7SfjRBfK8nq7ZC0dBbOkr1hIKcWJWPSocl0ZHsyjMkS8Cs+/8i1aiCGU50Wb8kY5agLf3S0Fv10mRmZnE6b/atZ+k9uJVOvcZsj8huM=; 20:FTnMmfPDyRYQAKEKgk9JIfseJtCAaNxWLybKq13tk04jk/N1QZRdVfvMxesKV5FO5q1WlvJdyt0WfxQ50R665g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; 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)(520078)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(51444003)(76104003)(189002)(122556002)(99286002)(81156007)(64706001)(4001350100001)(11100500001)(40100003)(2501003)(92566002)(2950100001)(5008740100001)(5007970100001)(5002640100001)(5001770100001)(46102003)(16236675004)(102836002)(107886002)(10400500002)(106116001)(2900100001)(106356001)(105586002)(5001960100002)(5004730100002)(101416001)(86362001)(76176999)(189998001)(97736004)(50986999)(54356999)(36756003)(66066001)(87936001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D24407B3E6E5Akwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 18:00:48.2243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 18:00:55 -0000 --_000_D24407B3E6E5Akwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Robert for bringing the discussion back to the github issues. Robert writes: > In particular: > - does it include support for templating (as per openconfig-netmod-ops= tate-01 section 7.3.)? > - is it allowed to represent system created objects that have no corre= sponding configuration? > > Requirement 1.D states D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. > > So, if this requirement statement stands as being valid (which I think it= should) then that would imply that the answer for both the two issues abov= e must be "no". The only question would be whether these need to be explic= itly listed out? [KENT] so I think I have to (begrudgingly) agree with your logic. I have= heard the operators state that they want the intended/applied comparison t= o be drop-dead simple. To that end, it would not be possible to flatten te= mplates or apply defaults, or make any other change - it needs to be as clo= se as possible to a carbon-copy of the original intended configuration (whe= re deviations are allowed only for cases like a missing line-card). To thi= s end, yes, I think that we could tack on a statement like the following: That is, the intended configuration is a subset of the applied configuration where omissions are only due to when the configuration cannot be applied (e.g., a missing line-card). What do you think? >> - how does it relate to the state of the system after a equivalent sync= hronous config commit (if at all)? >> > Again, I think that definition of requirement 1.D, along with the propose= d definition of synchronous configuration operation vs asynchronous configu= ration operation, will provide a sufficient answer to this question. I.e. = that the state of the system after an asynchronous config operation must, w= hen fully synchronized, be the same as the state of the system after an equ= ivalent synchronous configuration operation completes and replies back. [KENT] I agree with this, but I think it impacts issue #6 more so than issu= e #4 - right? Thanks, Kent --_000_D24407B3E6E5Akwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Thank you Robert for bringing the discussion back to the github issues= .

Robert writes:

> In particular:
>    - does it include support for templating (as per ope= nconfig-netmod-opstate-01 section 7.3.)?
>    - is it allowed to represent system created objects that = have no corresponding configuration?
>
> Requirement 1.D states
>Does anyone have any outstanding objections on using this proposed text
>for Requirement 1.D, or is it sufficiently clear to update the draft,
>and resolve issue 1?
>
>OLD text for Requirement 1:
>
>    1.  Ability to interact with both intended and applied configuration
>
>        A.  The ability to ask the operational components of a system
>            (e.g., line cards) for the configuration that they are
>            currently using.  This is the "applied configuration".
>
>        B.  Applied configuration is read-only
>
>        C.  The data model for the applied configuration is the same as
>            the data model for the intended configuration (same leaves)
>
>        D.  For asynchronous systems, when fully synchronized, the data
>            in the applied configuration is the same as the data in the
>            intended configuration.
>
>
>NEW text (as above, changing 1.D only):
>
>    1.  Ability to interact with both intended and applied configuration
>
>        A.  The ability to ask the operational components of a system
>            (e.g., line cards) for the configuration that they are
>            currently using.  This is the "applied configuration".
>
>        B.  Applied configuration is read-only
>
>        C.  The data model for the applied configuration is the same as
>            the data model for the intended configuration (same leaves)
>
>        D.  When the configuration change for any intended configuration
>            node has been successfully applied to the system (e.g. not
>            failed, nor deferred due to absent hardware) then the
>            existence and value of the corresponding applied
>            configuration node must match the intended configuration
>            node.
>
>
>Thanks,
>Rob
>
>
>On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
>> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
>>> Hi Juergen,
>>>
>>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
>>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
>>>>> Hi Kent,
>>>>>
>>>>> On 06/10/2015 01:40, Kent Watsen wrote:
>>>>>> This issue appears to have become more like issue #5 =AD should we
>>>>>>mark
>>>>>> this one a duplicate of the other?
>>>>> I suggest that we can just finalize on the text being discussed to
>>>>> replace 1.D and then resolve issue #1.
>>>>>
>>>>> Jason had proposed this text:
>>>>>
>>>>> When the configuration change for any intended configuration node has
>>>>> been successfully applied to the system (e.g. not failed, nor
>>>>>deferred
>>>>> due to absent hardware) then the existence and value of the applied
>>>>> equivalent of the node (whether that be a corresponding node in the
>>>>>data
>>>>> model, an attribute associated with the intended config node, the
>>>>> configuration node read from a different datastore or context, etc)
>>>>>must
>>>>> match the intended configuration node.
>>>> I have no clue what "an attribute associated with the intended config
>>>> node" or "the configuration node read from a different datastore or
>>>> context" or "etc". means. What exactly is an "applied equivalent of
>>>> the node"?
>>>>
>>>>> Or perhaps this slightly briefer alternative is better?:
>>>>>
>>>>>          D.  When the configuration change for any intended
>>>>>              configuration node has been successfully applied to the
>>>>>              system (e.g. not failed, nor deferred due to absent
>>>>>hardware)
>>>>>              then the existence and value of the corresponding,
>>>>>possibly
>>>>>              notional, applied configuration node must match the
>>>>>intended
>>>>>              configuration node.
>>>> What is the purpose of the phrase "possibly notional"?
>>> There was a concern that my previous text, i.e. as above but without
>>> "possibly notional", implied that applied configuration had to be
>>> actually represented as real data nodes in a YANG schema, which would
>>> disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and
>>> draft-wilton-netmod-intf-ext-yang-00.
>>>
>>> On balance, my preference is to exclude the "possibly notional" phrase
>>> if the text is sufficiently clear without it.
>> My understanding is that draft-kwatsen-netmod-opstate-00 proposes to
>> represent applied config as nodes in a different datastore, so there
>> is no need for 'possibly notational'. I do not understand why
>> draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean
>> draft-wilton-netmod-opstate-yang-00? I do have major concerns about
>> this particular proposal since it changes the YANG data encoding
>> fundamentally. There was another proposal to use attributes, which is
>> also not without problems but it is likely a bit less painful. But
>> again, it all depends on the final definition of what applied config
>> really is. So where is the latest version and how far are we with
>> agreeing on it?
>>
>> Yet another way to look at this is to expose not the applied config in
>> addition to the intended config (I have been told configs can be
>> really large) but instead expose lets say a yang patch that says how
>> the applied config differs form the running config. Having to retrieve
>> two large configs just to diff them locally seems to a potentially
>> expensive exercise, in particular if the difference is often small.  I
>> think Randy mentioned something like this before and no there is no
>> I-D. But even with this approach, the definition without "possibly
>> notational' would hold; you would just not expose the applied config
>> entirely but instead a patch that allows to calculate it.
>>
>> /js
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 14 11:14:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AA1AD2DF for ; Wed, 14 Oct 2015 11:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UtePipsFLtS8 for ; Wed, 14 Oct 2015 11:14:29 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60E81AD289 for ; Wed, 14 Oct 2015 11:14:28 -0700 (PDT)
Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB393.namprd05.prod.outlook.com (10.141.75.24) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 18:14:10 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 18:14:09 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 18:14:09 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Thread-Index: AQHQ+5bVY+r8w1658UewPXEWKgfK555pfxgAgAGe5gA=
Date: Wed, 14 Oct 2015 18:14:08 +0000
Message-ID: 
References:  <561D0724.1030602@cisco.com>
In-Reply-To: <561D0724.1030602@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:xrVYWzz1Gy1oG03TVobgIAwc5vKhiX+8RcQpLLTNBVEfUh5Kurcneem4R+2fCe+V6CCQU+izy5Fy/DGmG0TW2+9nQpTwab/usxr5m+zZNDAQFPmx0MBaqFUz2J76zXRsIKVx5dFDtbTP4ufpTxqmRQ==; 24:VA3RRBhmTtIrgLOGD5FGKOPxk0ZDKO+588MvRYy5eQ1GyVqfA4F/gzQ5DaEpbZFu6P4f0ck0HQjgLNkhP9jjC6tDkX2oRDlDrW8Dv7/K0w8=; 20:UR5ENVLAjfH5CW10Xn9HM/BEJpcxN/TgHIvHQUASsklcqcylqISKcpqyGlH5T5aOA7JjVd3tYy+oRor+AauHWQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(199003)(377454003)(479174004)(164054003)(51444003)(122556002)(107886002)(86362001)(10400500002)(40100003)(5002640100001)(66066001)(106356001)(106116001)(19617315012)(189998001)(16236675004)(2501003)(87936001)(5008740100001)(5001960100002)(5001770100001)(81156007)(4001350100001)(101416001)(97736004)(54356999)(50986999)(2900100001)(83506001)(105586002)(19580405001)(11100500001)(5007970100001)(2950100001)(5004730100002)(92566002)(102836002)(99286002)(36756003)(64706001)(15975445007)(76176999)(19580395003)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24412E3E6EDAkwatsenjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 18:14:08.8133 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB393; 2:UjHrnZjF2p1/V8Xmz9Bz1VVmE1EsJz/xrCQJctBofIfMBF/moq1JqFE907o9pJ5qLLyAUK08ODJ/wFgvCaQXIek6L0R4m/T7vkfXkY7ZqKZWE9oEOw6dPOjA/cm+DRN1uuWyLjvHIGCEqw32WXwodXqI1LpRZ4RnBoFwAIneulA=; 23:7Bop5JA9RdhIpezAzUQeXdHW3/rcbfFYlkb0zz8yNFqSp/pGasgdeQTZuV/9QRQiKv2Wm7op+4WzZP+3C4k6VUEpX5viQeanWvQODEgmvmCgAVzat2ZNWnZTOLf70ZQcFCDni/RCjgASJ3+T8ELA13EY/noflUx1Ltp37S6A/tQMpOUbm6qnRpoOSl4ltcgk
X-OriginatorOrg: juniper.net
Archived-At: 
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 18:14:33 -0000

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


I believe that you are correct, it seems that we've doubled-down on 1C and =
so #5 should now be marked as DEAD.

This action will be taken if no objection is made before tomorrow's interim=
.

Thanks,
Kent


From: Robert Wilton >
Date: Tuesday, October 13, 2015 at 9:29 AM
To: Kent Watsen >, "netmod@=
ietf.org" >
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structur=
e of intended configuration is not the same as applied

>From the interim meeting two weeks ago, it was clarified that the schema of=
 the intended configuration nodes are expected to be the same as the schema=
 of the applied configuration nodes so that clients can easily relate betwe=
en the two.

I think that the requirement text for 1.C and the proposed updated text for=
 1.D makes this reasonable clear.

Hence, is issue 5 now at the state where is can be closed as not being a re=
quirement?  Or is there something further that needs to be discussed first?

Thanks,
Rob


On 30/09/2015 16:44, Kent Watsen wrote:

It's time to tackle another issue, just before tomorrow's meeting, and this=
 time I'm picking a hard one:

https://github.com/netm=
od-wg/opstate-reqs/issues/5

Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub=
 issue tracker.    Please first read the comments posted there and then con=
tinue the discussion here on the mailing list (not on the GitHub issue trac=
ker).

Note that this issue is closely tied to the definition of "applied configur=
ation", which is exactly what issue #4 regards (https://github.com/netmod-w=
g/opstate-reqs/issues/4), for which Mahesh and Einar have posted comments o=
n already.   As these two issues (#4 and #5) are so highly related, I'm goi=
ng to simultaneously open the other issue for discussion now as well.

Thanks,
Kent




_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinf=
o/netmod


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












I believe that you are correct, it seems that we've doubled-down on 1C=
 and so #5 should now be marked as DEAD.







This action will be taken if no objection is made before tomorrow's in=
terim.







Thanks,


Kent














From: Robert Wilton <rwilton@cisco.com>

Date: Tuesday, October 13, 2015 at =
9:29 AM

To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#5: Support for situations when structure of intended configuration is not =
the same as applied











From the interim meeting two week=
s ago, it was clarified that the schema of the intended configuration nodes=
 are expected to be the same as the schema of the applied configuration nod=
es so that clients can easily relate
 between the two.



I think that the requirement text for 1.C and the proposed updated text for=
 1.D makes this reasonable clear.



Hence, is issue 5 now at the state where is can be closed as not being a re=
quirement?  Or is there something further that needs to be discussed f=
irst?



Thanks,

Rob






On 30/09/2015 16:44, Kent Watsen wrote:













It's time to tackle another issue, just before tomorrow's meeting, and this=
 time I'm picking a hard one:














Already Carl, Mahesh, Einar, and And=
y have posted 18 comments on the GitHub issue tracker.    Please =
first read the comments posted there and then continue the discussion here =
on the mailing list (not on the GitHub issue
 tracker).







Note that this issue is closely tied to the definition of "applie=
d configuration", which is exactly what issue #4 regards (https://github.com/netmod-wg/opstate-reqs/issues/4),
 for which Mahesh and Einar have posted comments on already.   As thes=
e two issues (#4 and #5) are so highly related, I'm going to simultaneously=
 open the other issue for discussion now as well.







Thanks,


Kent









 


_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod













--_000_D24412E3E6EDAkwatsenjunipernet_--


From nobody Wed Oct 14 11:40:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1641B29A3 for ; Wed, 14 Oct 2015 11:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdiWXYVfaVF2 for ; Wed, 14 Oct 2015 11:40:46 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA4A61A6EFB for ; Wed, 14 Oct 2015 11:40:45 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F8261AE044D; Wed, 14 Oct 2015 20:40:44 +0200 (CEST)
Date: Wed, 14 Oct 2015 20:43:54 +0200 (CEST)
Message-Id: <20151014.204354.1484545235629559894.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz>
References: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] nested choices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 18:40:47 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> my action item from yesterday's interim was to check whether some updates to 6020bis are needed in order to address the corner cases presented by Balazs:
> 
> - https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk
> - https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk
> 
> I would propose this minor change to sec. 7.9.3:
> 
> OLD
> 
>    The default case is only important when considering the default
>    values of nodes under the cases.
> 
> NEW
> 
>    The default case is only important when considering the default
>    contents of nodes under the cases (default values of leafs and
>    leaf-lists, or default cases of nested choices).

Maybe a slight variation, and taking the entire paragraph into
account:

OLD:

  The default case is only important when considering the default
  values of nodes under the cases.  The default values for nodes under
  the default case are used if none of the nodes under any of the
  cases are present.

NEW:

  The default case is only important when considering the default
  statements of node under the cases (i.e., default values of leafs and
  leaf-lists, and default cases of nested choices).  The default
  values and nested default cases under the default case are used
  if none of the nodes under any of the cases are present.



/martin


From nobody Wed Oct 14 11:49:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4F1A1BA9 for ; Wed, 14 Oct 2015 11:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSlGGE4lduu0 for ; Wed, 14 Oct 2015 11:49:02 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F511A0461 for ; Wed, 14 Oct 2015 11:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2656; q=dns/txt; s=iport; t=1444848541; x=1446058141; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Vos2lIuprYzPxya1tClQIi3LxyGRWrFvTtvVO5MTKXs=; b=GfGaq68gsUIb6N6HscafQEsf69TOATx92ggEYgxP7dtvHbZZ1JO2EoU6 mlKoxUfY2M2Kd28Af5wuDR787+eO4RQWH9JoLosuglwCRHqn4jhbk91kA kLvKuNCC/kb3crT1CKCkebVHuS3LkD3r9ZVwWfNX0/WnJNIJnB9cigof5 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CjBQB6oh5W/xbLJq1ehGi4foYJgxOCCn8CghUBAQEBAQGBC4QnAQEEOC8RARALDgoJFg8JAwIBAgFFBg0GAgEBiCrDTgEBAQEBAQEBAQEBAQEBAQEBG4Z2hH6FDQeELgEElhWICYUSiROSd2OEAz0zhm8BAQE
X-IronPort-AV: E=Sophos;i="5.17,682,1437436800"; d="scan'208";a="605739860"
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; 14 Oct 2015 18:48:59 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9EImxq6014141; Wed, 14 Oct 2015 18:48:59 GMT
To: Martin Bjorklund 
References: <561CD668.6050401@cisco.com> <20151013.121749.1289164634073433213.mbj@tail-f.com> <561E1F74.5050809@cisco.com> <20151014.191452.1508719715698664237.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <561EA38D.8050003@cisco.com>
Date: Wed, 14 Oct 2015 19:48:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151014.191452.1508719715698664237.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 18:49:04 -0000

On 14/10/2015 18:14, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Martin,
>>
>> I was looking at the YANG ABNF grammar a bit more last night (to see
>> how hard it would be to write a parser for it) and I had a couple more
>> observations.  Apologies that this is after the WG last call ...
>>
>> 1. [Trivial] The indentation of the range statement in 9.3.5 looks
>> wrong.
>>
>> 9.3.5. Usage Example
>>
>>       typedef my-decimal {
>>         type decimal64 {
>>           fraction-digits 2;
>>             range "1 .. 3.14 | 10 | 20..max";
>>         }
>>       }
>>
>>
>> I presume that it should be:
>>
>> 9.3.5. Usage Example
>>
>>       typedef my-decimal {
>>         type decimal64 {
>>           fraction-digits 2;
>>           range "1 .. 3.14 | 10 | 20..max";
>>         }
>>       }
> Fixed.
>
>> 2.  The description of yang-char (around page 186) doesn't seem to be
>> quite accurate (relative to description of legal characters in 6. YANG
>> Syntax), and given that it excludes character values outside the
>> unicode range.
> Hmm, which characters are outside the unicode range?
I was thinking of anything above 0xFFFF, but it looks like my definition 
(and possibly quite a few others on the Internet) of Unicode vs UTF-16 
is out of date.

>
>>     ;; any Unicode character including tab, carriage return, and line
>>     ;; feed, but excluding the other C0 control characters, the surrogate
>>     ;; blocks, and the noncharacters.
>>     yang-char = %x9 / %xA / %xD / %x20-D7FF /
>>     ...
>>
>>
>> Should this be:
>>
>>     ;; any Unicode or IOS/IEC 10646 character including tab, carriage return,
>>     ;; and line
>>     ;; feed, but excluding the other C0 control characters, the surrogate
>>     ;; blocks, and the noncharacters.
>>     yang-char = %x9 / %xA / %xD / %x20-D7FF /
> I think this would be ok.
>
>> 3. There are lots of comments where "these stmts can appear in any
>> order", e.g.
>>
>>     linkageStmts       = ;; these stmts can appear in any order
>>                           *importStmt
>>                           *includeStmt
>>
>> Am I right in interpreting that there can be any number of import and
>> include statements and they can be interleaved in any arbitrary
>> order?
> Yes.
>
>> E.g. this specific example (but not in the general case) could equally
>> have been written *(importStmt / includeStmt).
> Well, the grammar defines the canonical order.  With the alternative
> rule above, the canonical order would be different.
Thanks for the clarification,
Rob

>
>
> /martin
> .
>


From nobody Wed Oct 14 11:57:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AB41B29D3 for ; Wed, 14 Oct 2015 11:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMDnAyvkEig8 for ; Wed, 14 Oct 2015 11:57:02 -0700 (PDT)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 AC78A1B29D2 for ; Wed, 14 Oct 2015 11:57:01 -0700 (PDT)
Received: by lbwr8 with SMTP id r8so53063998lbw.2 for ; Wed, 14 Oct 2015 11:57:00 -0700 (PDT)
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=KEhFbYjpA/WqKhlGq5upbDHwiYR3N0EifAA85KAOFR8=; b=cxMRLfjxmR9/SS2SPdjGu6/Hub2p5PNWbkuQd3/YWwmFP8puM5hQshEs3wAkDLKFo+ ztInzBtC7EA4NBTP6/TZ29J1abOrjLrZ7z72/VjBPDZp6jtPJcQeuXO08ddQCds4khNh RPAiaN4IwpZBTZkhcsej2yPfdR54M8JHXDBQck+RJCgly8kRuyaYSsng2qoSaw9oCxpD G+OwGfTjqMaseAHOBXqjqg2471deb3bwe9a/R5f1+VNyzIKdoltgFadkBMTEzZf6HfOd km2Pn3MhP4DbJebb8QODlsQym1merCsufzb2Z0RcezJqnHzmGrvlTUK0QIlaLPc1mZiH /o2g==
X-Gm-Message-State: ALoCoQmlaCWxoEqNC6YqDAVew4O6+m3OyuNNg5QlpBCO/a5btvctlk8hVPY/OZcvb1yW/3rs8FFj
MIME-Version: 1.0
X-Received: by 10.112.135.136 with SMTP id ps8mr2415711lbb.38.1444849019810; Wed, 14 Oct 2015 11:56:59 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 14 Oct 2015 11:56:59 -0700 (PDT)
In-Reply-To: 
References:  <560D269E.30002@cisco.com> 
Date: Wed, 14 Oct 2015 11:56:59 -0700
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=089e01160712949f5d052215207a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 18:57:04 -0000

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

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  wrote:

>
> Thank you Robert for bringing the discussion back to the github issues.
>
> Robert writes:
>
> > In particular:
> >    - does it include support for templating (as per
> openconfig-netmod-opstate-01 section 7.3.)?
> >    - is it allowed to represent system created objects that have no
> corresponding configuration?
> >
> > Requirement 1.D states
>
>      D.  For asynchronous systems, when fully synchronized, the data
>            in the applied configuration is the same as the data in the
>            intended configuration.
>
> >
> > So, if this requirement statement stands as being valid (which I think
> it should) then that would imply that the answer for both the two issues
> above must be "no".  The only question would be whether these need to be
> explicitly listed out?
>
> [KENT] so I think I have to (begrudgingly) agree with your logic.    I
> have heard the operators state that they want the intended/applied
> comparison to be drop-dead simple.  To that end, it would not be possible
> to flatten templates or apply defaults, or make any other change =E2=80=
=93 it needs
> to be as close as possible to a carbon-copy of the original intended
> configuration (where deviations are allowed only for cases like a missing
> line-card).  To this end, yes, I think that we could tack on a statement
> like the following:
>
> That is, the intended configuration is a subset of the applied
> configuration where omissions are only due to when the
> configuration cannot be applied (e.g., a missing line-card).
>
> What do you think?
>


I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?


Andy


>
>
> >>  - how does it relate to the state of the system after a equivalent
> synchronous config commit (if at all)?
> >>
> > Again, I think that definition of requirement 1.D, along with the
> proposed definition of synchronous configuration operation vs asynchronou=
s
> configuration operation, will provide a sufficient answer to this
> question.  I.e. that the state of the system after an asynchronous config
> operation must, when fully synchronized, be the same as the state of the
> system after an equivalent synchronous configuration operation completes
> and replies back.
>
> [KENT] I agree with this, but I think it impacts issue #6 more so than
> issue #4 - right?
>
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <kwatsen@juniper.net> wrote:












Thank you Robert for bringing the discussion back to the github issues=
.







Robert writes:











> In particular:





> =C2=A0 =C2=A0- does it include support for templating (as per ope=
nconfig-netmod-opstate-01 section 7.3.)?






> =C2=A0 =C2=A0- is it allowed to represent system created objects that =
have no corresponding configuration?

>

> Requirement 1.D states


That is, the intended conf=
iguration is a subset of the applied=C2=A0


configuration where omissi=
ons are only due to when the


configuration cannot be ap=
plied (e.g., a missing line-card).







What do you think?


I am wondering why operators would want to compare 2 massive subtre=
es
in the first place, where 1 is static and the other is changin=
g constantly.

Do they really want this complex tas=
k or do they just want to
determine if the intended config has be=
en applied yet?


Andy
=


















>> =C2=A0- how does it relate to the state of the system after a=
 equivalent synchronous config commit (if at all)?



>>

> Again, I think that definition of requirement 1.D, along with the prop=
osed definition of synchronous configuration operation vs asynchronous conf=
iguration operation, will provide a sufficient answer to this question.=C2=
=A0 I.e. that the state of the system after
 an asynchronous config operation must, when fully synchronized, be the sam=
e as the state of the system after an equivalent synchronous configuration =
operation completes and replies back.











[KENT] I agree with this, but I t=
hink it impacts issue #6 more so than issue #4 - right?














Thanks,



Kent

















_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e01160712949f5d052215207a--


From nobody Wed Oct 14 11:57:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F651B29DC for ; Wed, 14 Oct 2015 11:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QKL0HSfRolj6 for ; Wed, 14 Oct 2015 11:57:06 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03B41B29DD for ; Wed, 14 Oct 2015 11:57:05 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 18:56:47 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 18:56:47 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: upstate-reqs #8: ability to retrieve both op-state types together
Thread-Index: AQHRBrISyKR0XdW5zUueY7vWSrvKlg==
Date: Wed, 14 Oct 2015 18:56:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:TNyDWOIy0pcUOzdu/BAVR1c4z9FwxOGbSKqDPFkLv8xeT5jJ2YwN8BBOMWsc4SjLlRZRwBrYpOGmEP8nM8nFTkr3j9FdLfqBCVn9ZAXq+JAJg4IhD2ghqimPNjeAlP1DgG+38ghF9qrsJB4BaHNhdA==; 24:lYGX7zG0Sb6V0lLFLpFpvjuYW8SyMCSevqi3jMfi3Fs6p5g6DMA28vjsvxld8hajVKhHQ23s+4H8JZ7xcqQsafcMr0wQO48y4aQP9u2/+jU=; 20:i+4gsIhKHTpur69k6kAknlfZSHRkVqQ6/RCry+j130IIIQtAg/X/Vq3q/9jXtnl0qozWFJR0mobSXCG+z6aBvw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(57704003)(164054003)(189002)(5004730100002)(11100500001)(107886002)(102836002)(122556002)(15975445007)(50986999)(106356001)(36756003)(86362001)(19580395003)(110136002)(5007970100001)(189998001)(87936001)(106116001)(105586002)(99286002)(83506001)(2900100001)(10400500002)(66066001)(2501003)(4001350100001)(2351001)(5008740100001)(40100003)(450100001)(5001960100002)(5002640100001)(16236675004)(92566002)(64706001)(54356999)(101416001)(97736004)(229853001)(81156007)(46102003)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2441DABE6F30kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 18:56:45.9286 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [netmod] upstate-reqs #8: ability to retrieve both op-state types together
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 18:57:13 -0000

--_000_D2441DABE6F30kwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I created this issue a little more than a week ago, but forgot to CC the li=
st until now - sorry!

GitHub issue #8 (https://github.com/netmod-wg/opstate-reqs/issues/8) says:

=3D=3D=3D=3DSTART=3D=3D=3D=3D
On the interim call, Rob made in interesting point about config+operational=
, using BGP as an example.

Do we need to amend point 4 to allow for a method to retrieve these in a si=
ngle operation?

OLD:

   4.  Separation of configuration and operational state data; ability
       to retrieve them independently
       A.  Be able to retrieve only the derived state aspects of
           operational state
       B.  Be able to retrieve only the non-derived state aspects of
           operational state

NEW:

   4.  Separation of configuration and operational state data; ability
       to retrieve them both together and independently
       A.  Be able to retrieve only the derived state aspects of
           operational state
       B.  Be able to retrieve only the non-derived state aspects of
           operational state
       C.  Be able to retrieve both the derived and non-derived state
           aspects of operational state together

=3D=3D=3D=3DSTOP=3D=3D=3D=3D


Any objections to adding 4C?


Thanks,
Kent


--_000_D2441DABE6F30kwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <6BBCBEA3633B3F4687F4D6240C9806BC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














I created this issue a little more than a week ago, but forgot to=
 CC the list until now – sorry!
















=3D=3D=3D=3DSTART=3D=3D=3D=3D


On the interim call, Rob made in interest=
ing point about config+operational, using BGP as an example.








Do we need to amend point 4 to allow for =
a method to retrieve these in a single operation?









OLD:









   4.  Separation of confi=
guration and operational state data; ability



       to retrieve th=
em independently



       A.  Be ab=
le to retrieve only the derived state aspects of



           =
operational state



       B.  Be ab=
le to retrieve only the non-derived state aspects of



           =
operational state









NEW:









   4.  Separation of confi=
guration and operational state data; ability



       to retrieve th=
em both together and independently



       A.  Be ab=
le to retrieve only the derived state aspects of



           =
operational state



       B.  Be ab=
le to retrieve only the non-derived state aspects of



           =
operational state



       C.  Be ab=
le to retrieve both the derived and non-derived state



           =
aspects of operational state together









=3D=3D=3D=3DSTOP=3D=3D=3D=3D















Any objections to adding 4C?  















Thanks,



Kent










--_000_D2441DABE6F30kwatsenjunipernet_--


From nobody Wed Oct 14 12:12:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9622D1A1BBE for ; Wed, 14 Oct 2015 12:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0wDQeCRxdMK for ; Wed, 14 Oct 2015 12:12:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC471A0545 for ; Wed, 14 Oct 2015 12:12:10 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 19:12:03 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 19:12:03 +0000
From: Kent Watsen 
To: Robert Varga , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
Thread-Index: AQHRASbaC+/4nTaWn0y+FO1fJ8P2l55plLaAgAGOVQA=
Date: Wed, 14 Oct 2015 19:12:03 +0000
Message-ID: 
References:  <561D229B.4050900@hq.sk>
In-Reply-To: <561D229B.4050900@hq.sk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:pmNLraMeLP1ASAmQPXXDv//ETGQlMRUpWji1mzKFE7w0673XOVx1QHg+hDkZ6fW7XflnfJxT0khAETataHeLriIJPWcLYsZ/mhstVK+By6fslsHovfeLW6YRpTfpud6w7gW2XjtNTpvTkLSxH8FX3w==; 24:Toznps0Iwzth5hgXcyVXgL1R/QtCtnO0NFRgFfTAAYR0v1Si8G+B0q2E/Q+QJG3GL1ZqM/U4V8sGydELKo6HqHzJfg9w/tqPpGrwoBlVfIQ=; 20:Kyk87ydy+WBoc3SqNDNkNCSCofJlBm3OrFFvrlaYTNynDswQr9zQ09q3ABFM8334OC8DUJR41NV17CJ37onpTA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(377424004)(377454003)(164054003)(76114002)(5423002)(479174004)(199003)(40100003)(5001960100002)(76176999)(5002640100001)(19580405001)(4001350100001)(5008740100001)(46102003)(81156007)(19617315012)(92566002)(64706001)(16236675004)(5001770100001)(101416001)(97736004)(54356999)(86362001)(36756003)(50986999)(106356001)(5007970100001)(189998001)(19580395003)(107886002)(11100500001)(5004730100002)(5890100001)(5001920100001)(122556002)(4001150100001)(15975445007)(102836002)(99286002)(2501003)(230783001)(66066001)(10400500002)(83506001)(2900100001)(2950100001)(87936001)(106116001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24413C9E6EE3kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 19:12:03.0358 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:12:13 -0000

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


Interesting observation about point cut, Robert.

For the case of the "inactive" attribute that has been discussed in the pas=
t, as well as the "last-modified" attribute discussed in the draft, the int=
ent would be to allow it everywhere, so the need for point cut isn't there.

Can you think of some metadata examples that would apply to only a subset o=
f the nodes?

I recall a related conversation from before where we concluded that we want=
 attributes to only ever be used as metadata (never data), which is why the=
y are defined in a global way.  I fear that the point cut approach might br=
ing some of that concern back...

Thanks,
Kent

From: Robert Varga >
Date: Tuesday, October 13, 2015 at 11:26 AM
To: Kent Watsen >, "netmod@=
ietf.org" >
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (=
until 2015-10-22)

On 10/07/2015 07:37 PM, Kent Watsen wrote:

This is a notice to start a NETMOD WG last call for the document:

Defining and Using Metadata with YANG
http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02


I have read the document, and coming in without the previous discussions, m=
d:annotation instances feel like aspects (from aspect-oriented programming)=
 being attached to pre-defined models to address a cross-cutting concern. U=
nfortunately it seems it lacks an equivalent of pointcut specification, e.g=
. a machine-readable definition where/when a particular annotation is valid=
.

This makes annotations disconnected from the YANG metamodel, which is not d=
esirable for systems strictly based on the metamodel, as each instance of a=
n annotation will require hand-written code.

My question is whether it would make sense to define some sort of (optional=
) pointcut specification to be carried within the md:annotation statement (=
such as an explicit list of data nodes, or a 'when' statement or similar)?

That would allow us to bind some/most md:annotation instances automagically=
 to the metamodel, reducing the need to hand-code their semantics.

Thanks,
Robert

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














Interesting observation about point cut, Robert.









For the case of the "inactive" attribute that has been discussed =
in the past, as well as the "last-modified" attribute discussed i=
n the draft, the intent would be to allow it everywhere, so the need for po=
int cut isn't there.








Can you think of some metadata examp=
les that would apply to only a subset of the nodes?









I recall a related conversation from before where we concluded that we want=
 attributes to only ever be used as metadata (never data), which is why the=
y are defined in a global way.  I fear that the point cut approach mig=
ht bring some of that concern back...









Thanks,



Kent










From: Robert Varga <nite@hq.sk>

Date: Tuesday, October 13, 2015 at =
11:26 AM

To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] WG Last Call =
for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)













On 10/07/2015 07:37 PM, Kent Watsen wrote:














This =
is a notice to start a NETMOD WG last call for the document:









Defining and Using Metadata with YANG














I have read the document, and coming in without the previous discussions, m=
d:annotation instances feel like aspects (from aspect-oriented programming)=
 being attached to pre-defined models to address a cross-cutting concern. U=
nfortunately it seems it lacks an
 equivalent of pointcut specification, e.g. a machine-readable definition w=
here/when a particular annotation is valid.



This makes annotations disconnected from the YANG metamodel, which is not d=
esirable for systems strictly based on the metamodel, as each instance of a=
n annotation will require hand-written code.



My question is whether it would make sense to define some sort of (optional=
) pointcut specification to be carried within the md:annotation statement (=
such as an explicit list of data nodes, or a 'when' statement or similar)?<=
br>


That would allow us to bind some/most md:annotation instances automagically=
 to the metamodel, reducing the need to hand-code their semantics.



Thanks,

Robert









--_000_D24413C9E6EE3kwatsenjunipernet_--


From nobody Wed Oct 14 12:15:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62B31A0AC8 for ; Wed, 14 Oct 2015 12:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pmn3eTzjZYo5 for ; Wed, 14 Oct 2015 12:15:21 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6199B1A1A55 for ; Wed, 14 Oct 2015 12:15:20 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 19:15:14 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 19:15:14 +0000
From: Kent Watsen 
To: Andy Bierman 
Thread-Topic: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
Thread-Index: AQHQ+5jp1v6hLihUyE+oXDRPZo9RIJ5WkcoAgBSIcwCAAFLGgP//wgkA
Date: Wed, 14 Oct 2015 19:15:14 +0000
Message-ID: 
References:  <560D269E.30002@cisco.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:cMWfBWvQMGJvJrDjpxQhGaBGcITKa8nqfqcDaIGJb1pBKE7leZvrpwwblIKEfzYSPQp/ezeDD6Jjm+F/22z4ZdWk/gfHizfhYqSBomSHxMi22M1HgwgrCeE1sWhM1kxgUljVPuKUchxB6T9AOVJb5g==; 24:5oRhnwpkYJS+VIFVjXDejYPSETgw42srbznUlpSX7JJgvmaw1ltv2RIK3NCBbnUkizOkK4el/y5Y9CGrbXKL+Jn1bim2dObGu+tAobmzCSc=; 20:H/SFH0FglIZVglGil8tSDkZWcASx3NE2sqJAJbAXI+4b2R3/QiwIWArbaOcOG1RuTDj9xTKeUI3mUfycroPoDQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(76104003)(189002)(377454003)(51444003)(164054003)(199003)(40100003)(5001960100002)(76176999)(5002640100001)(19580405001)(4001350100001)(5008740100001)(46102003)(81156007)(19617315012)(92566002)(64706001)(16236675004)(101416001)(97736004)(54356999)(86362001)(36756003)(50986999)(106356001)(5007970100001)(189998001)(93886004)(19580395003)(110136002)(11100500001)(5004730100002)(5001920100001)(122556002)(15975445007)(102836002)(99286002)(66066001)(10400500002)(83506001)(2900100001)(2950100001)(87936001)(106116001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2442173E6F50kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 19:15:14.7741 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:15:25 -0000

--_000_D2442173E6F50kwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing constantl=
y.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions for s=
olutions to provide something like a yang-patch to describe just the diffs.=
  Makes sense to me!

K.


From: Andy Bierman >
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen >
Cc: Robert Wilton >, "netmod@ie=
tf.org" >
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "app=
lied configuration"



On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen > wrote:

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
>    - does it include support for templating (as per openconfig-netmod-ops=
tate-01 section 7.3.)?
>    - is it allowed to represent system created objects that have no corre=
sponding configuration?
>
> Requirement 1.D states

     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

>
> So, if this requirement statement stands as being valid (which I think it=
 should) then that would imply that the answer for both the two issues abov=
e must be "no".  The only question would be whether these need to be explic=
itly listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.    I have=
 heard the operators state that they want the intended/applied comparison t=
o be drop-dead simple.  To that end, it would not be possible to flatten te=
mplates or apply defaults, or make any other change - it needs to be as clo=
se as possible to a carbon-copy of the original intended configuration (whe=
re deviations are allowed only for cases like a missing line-card).  To thi=
s end, yes, I think that we could tack on a statement like the following:

That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?


I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?


Andy




>>  - how does it relate to the state of the system after a equivalent sync=
hronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the propose=
d definition of synchronous configuration operation vs asynchronous configu=
ration operation, will provide a sufficient answer to this question.  I.e. =
that the state of the system after an asynchronous config operation must, w=
hen fully synchronized, be the same as the state of the system after an equ=
ivalent synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so than issu=
e #4 - right?


Thanks,
Kent



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



--_000_D2442173E6F50kwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Andy writes:


> I am wondering why operators wo=
uld want to compare 2 massive subtrees


> in the first place, where 1 is =
static and the other is changing constantly.


>


> Do they really want this comple=
x task or do they just want to


> determine if the intended confi=
g has been applied yet?











I think that it is more the latter.   And there have been suggestions =
for solutions to provide something like a yang-patch to describe just the d=
iffs.  Makes sense to me!









K.
















From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, October 14, 2015 a=
t 2:56 PM

To: Kent Watsen <kwatsen@juniper.net>

Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#4: Provide a tighter definition of "applied configuration"



















On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen 
<kwatsen@junipe=
r.net> wrote:











Thank you Robert for bringing the discussion back to the github issues=
.







Robert writes:










> In particular:





>    - does it include support for templating (as per ope=
nconfig-netmod-opstate-01 section 7.3.)?





>    - is it allowed to represent system created objects th=
at have no corresponding configuration?

>

> Requirement 1.D states


     D=
.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

>

> So, if this requirement statement stands as being valid (which I think=
 it should) then that would imply that the answer for both the two issues a=
bove must be "no".  The only question would be whether these=
 need to be explicitly listed out?







[KENT] so I think I have to (begrudgingly) agree with your logic. &nbs=
p;  I have heard the operators state that they want the intended/appli=
ed comparison to be drop-dead simple.  To that end, it would not be po=
ssible to flatten templates or apply defaults,
 or make any other change – it needs to be as close as possible to a =
carbon-copy of the original intended configuration (where deviations are al=
lowed only for cases like a missing line-card).  To this end, yes, I t=
hink that we could tack on a statement like
 the following:







That is, the intended conf=
iguration is a subset of the applied 


configuration where omissi=
ons are only due to when the


configuration cannot be ap=
plied (e.g., a missing line-card).







What do you think?
















I am wondering why operators would want to compare 2 massive subtrees<=
/div>

in the first place, where 1 is static and the other is changing consta=
ntly.







Do they really want this complex task or do they just want to


determine if the intended config has been applied yet?














Andy


























>>  - how does it relate to the state of the system after a=
 equivalent synchronous config commit (if at all)?



>>

> Again, I think that definition of requirement 1.D, along with the prop=
osed definition of synchronous configuration operation vs asynchronous conf=
iguration operation, will provide a sufficient answer to this question.&nbs=
p; I.e. that the state of the system after
 an asynchronous config operation must, when fully synchronized, be the sam=
e as the state of the system after an equivalent synchronous configuration =
operation completes and replies back.











[KENT] I agree with this, but I t=
hink it impacts issue #6 more so than issue #4 - right?














Thanks,



Kent
















_______________________________________________

netmod mailing list

netmod@ietf.org

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





















--_000_D2442173E6F50kwatsenjunipernet_--


From nobody Wed Oct 14 12:22:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988251ACE97 for ; Wed, 14 Oct 2015 12:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhT5K5mw1sJU for ; Wed, 14 Oct 2015 12:22:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3D1ACCD9 for ; Wed, 14 Oct 2015 12:22:09 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 17D971AE044D; Wed, 14 Oct 2015 21:22:08 +0200 (CEST)
Date: Wed, 14 Oct 2015 21:25:18 +0200 (CEST)
Message-Id: <20151014.212518.877320464279591732.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <561CF838.3090308@ericsson.com>
References: <561CEA2C.4030600@ericsson.com> <20151013.133037.916630538697038960.mbj@tail-f.com> <561CF838.3090308@ericsson.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:22:10 -0000

Balazs Lengyel  wrote:
> Hello Martin,
> I agree that A1 is what follows the spirit of YANG, but then IMHO you
> should change/correct 8.2.1 in YANG because that implies A2 and error.

Ok, I agree.  I suggest we remove from 8.2.1:

   o  If data for a node tagged with "when" is present, and the "when"
      condition evaluates to "false", the server MUST reply with an
      "unknown-element" error-tag in the rpc-error.

and add to 8.2.2:

  o  Modification requests for nodes tagged with "when", and the "when"
     condition evaluates to "false".  In this case the server MUST reply
     with an "unknown-element" error-tag in the rpc-error.


/martin


> regards Balazs
> 
> On 2015-10-13 13:30, Martin Bjorklund wrote:
> > Balazs Lengyel  wrote:
> >> Hello Martin,
> >> If I had a model
> >>
> >> leaf a {type boolean;}
> >> leaf b {
> >>      when a
> >>      type int8;
> >> }
> >>
> >> if "a" is false and then you get an edit config with: set b=5 ; set
> >> a=true
> >> What should be the result?
> >> A1)  this should succeed as at commit time the "when" will be true.
> > yes.
> >
> >> A2) this should fail as at parsing (as described in 8.2.1 of the YANG
> >> RFC) the when is false - yet. This would also mean that you need 2
> >> edit-configs to set b=5.
> >> regards Balazs
> >
> > /martin
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
> 


From william.lupton@gmail.com  Wed Oct 14 02:20:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D461B2D18 for ; Wed, 14 Oct 2015 02:20:46 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgRR48vJagl9 for ; Wed, 14 Oct 2015 02:20:45 -0700 (PDT)
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 9345C1B2D1E for ; Wed, 14 Oct 2015 02:15:53 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so12294612lbb.0 for ; Wed, 14 Oct 2015 02:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=JD7mDIvRn3sU8dja6QsN0y38LE0M9HTZh92oSPidq5M=; b=Rkp0P8FyVx+ln3aO0oLTdir+gey4u8Bo/NPL1wre68NfwycQ7M98RbG8kJ7P82o+d8 AGaI2pVT/bcOFzmZKSsnn1ZptIPeuCXr1cv7sYUbs2ScXJJNpisplWjk9Ulksy4oSjqH Y+VFgP83W0aBUqrOXtJ0xp5dO/KGM7BQfyTqqrJtYr0M4Cp8J9cHWIodjRBbVK9ys3TZ zN4ICvTA2QWcuFgpKRhT/jTEzqrZKirTLM7sxdOoqUS769N1HzfSb5og2bKZvClxeq9G k0ZBQ88q0UkdSnQmsOT/h5LHd2iIigtccr61HvPn5797zGybLRD24g9bQRmSyqqpfNAc vJbg==
MIME-Version: 1.0
X-Received: by 10.112.157.99 with SMTP id wl3mr973830lbb.98.1444814151775; Wed, 14 Oct 2015 02:15:51 -0700 (PDT)
Sender: william.lupton@gmail.com
Received: by 10.113.4.133 with HTTP; Wed, 14 Oct 2015 02:15:51 -0700 (PDT)
Date: Wed, 14 Oct 2015 10:15:51 +0100
X-Google-Sender-Auth: n_ee6Nl8j4hbjdtWPqLL1uHlkxc
Message-ID: 
From: William Lupton 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=001a11c342ee487f8505220d0239
Archived-At: 
Subject: [netmod] not a non-presence container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:30:48 -0000

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

All,

Both RFC 6020 and the bis draft use the term "not a non-presence
container", sometimes with a reference to section 7.5.1.

Does this term mean the same as "presence container"? If so, I think it
would be easier (on the reader!) to say that instead. If not, I think that
the term warrants a mention in section 7.5.1.

Comments?

Thanks,
William Lupton

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


All,

Both RFC 6020 and the bis draft us=
e the term "not a non-presence container", sometimes with a refer=
ence to section 7.5.1.

Does this term mean the sam=
e as "presence container"? If so, I think it would be easier (on =
the reader!) to say that instead. If not, I think that the term warrants a =
mention in section 7.5.1.

Comments?

=

Thanks,
William Lupton


--001a11c342ee487f8505220d0239--


From nobody Wed Oct 14 12:36:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ACC1ACF1B for ; Wed, 14 Oct 2015 12:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBeYptKgjeWf for ; Wed, 14 Oct 2015 12:36:39 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 28EE31A8769 for ; Wed, 14 Oct 2015 12:36:39 -0700 (PDT)
Received: by lbwr8 with SMTP id r8so53792302lbw.2 for ; Wed, 14 Oct 2015 12:36:37 -0700 (PDT)
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=vzMGl7fz1dnIzx2rQai6k7RiOxV1s1HYQK0Ml+hH6ZQ=; b=Oi14QRfrvhP0ocOi9A+Kv8hHSFREbJxn2y9SnyHjQnymPiBU3PSZrb5rstRrwNf0bj VEFOJWF5PbTZGp9r5IZzuwsNnGtiVM2olZVAClsLPpQWxIqV3Tc3xYqnYmsPUfJFppxR xbhHJUyZ9ub4m3kDhAVer7SS/synL606Quvo7+GzxjgXVM90Gh1yfyVurmq70UbBEV/Y +UZnkBMlgVdFgjb+TScnifJT998UWlm7yd1xaD0gP0kch2cZEoIjdtxi7Kn3IfcraKW8 6BRIt08bDD5+9QpX7OKYchvDlzWED40z3JU2EzoZof5oqH/laz5UDJ+gl8U61QiZNi4U 9U4A==
X-Gm-Message-State: ALoCoQkE//hXlIpBXvk6eA6r3Dn7XyuzIz/WNEqt6hmxaPwH89pfs20Z9+lF0annByNnxUB8/QBu
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr2533390lbc.123.1444851397231;  Wed, 14 Oct 2015 12:36:37 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 14 Oct 2015 12:36:37 -0700 (PDT)
In-Reply-To: <20151014.212518.877320464279591732.mbj@tail-f.com>
References: <561CEA2C.4030600@ericsson.com> <20151013.133037.916630538697038960.mbj@tail-f.com> <561CF838.3090308@ericsson.com> <20151014.212518.877320464279591732.mbj@tail-f.com>
Date: Wed, 14 Oct 2015 12:36:37 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c26650491d1e052215aefa
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:36:41 -0000

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

On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund  wrote:

> Balazs Lengyel  wrote:
> > Hello Martin,
> > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > should change/correct 8.2.1 in YANG because that implies A2 and error.
>
> Ok, I agree.  I suggest we remove from 8.2.1:
>
>    o  If data for a node tagged with "when" is present, and the "when"
>       condition evaluates to "false", the server MUST reply with an
>       "unknown-element" error-tag in the rpc-error.
>
> and add to 8.2.2:
>
>   o  Modification requests for nodes tagged with "when", and the "when"
>      condition evaluates to "false".  In this case the server MUST reply
>      with an "unknown-element" error-tag in the rpc-error.
>
>
>

This seems like a BIG protocol change to  behavior.
IMO this not an error at all.  In our server the false-when data is just
pruned, and no error is ever sent for a pruned when=false data node.

It may be a client programming error for the client to provide
false when nodes or not.  What if the client is reusing some
code that sends 5 parameters, it it's OK if 1 of them gets
pruned sometimes because of a false when (e.g, product
feature-specific knob and that feature is not installed)

BTW, this is a really good example of what not to do, if one
wants to make the YANG specification protocol independent.




> /martin
>
>

Andy


>
> > regards Balazs
> >
> > On 2015-10-13 13:30, Martin Bjorklund wrote:
> > > Balazs Lengyel  wrote:
> > >> Hello Martin,
> > >> If I had a model
> > >>
> > >> leaf a {type boolean;}
> > >> leaf b {
> > >>      when a
> > >>      type int8;
> > >> }
> > >>
> > >> if "a" is false and then you get an edit config with: set b=5 ; set
> > >> a=true
> > >> What should be the result?
> > >> A1)  this should succeed as at commit time the "when" will be true.
> > > yes.
> > >
> > >> A2) this should fail as at parsing (as described in 8.2.1 of the YANG
> > >> RFC) the when is false - yet. This would also mean that you need 2
> > >> edit-configs to set b=5.
> > >> regards Balazs
> > >
> > > /martin
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Balazs Lengyel <balazs.lengyel@ericsson.com>=
; wrote:

> Hello Martin,

> I agree that A1 is what follows the spirit of YANG, but then IMHO you<=
br>
> should change/correct 8.2.1 in YANG because that implies A2 and error.=




Ok, I agree.=C2=A0 I suggest we remove from 8.2.1:



=C2=A0 =C2=A0o=C2=A0 If data for a node tagged with "when" is pre=
sent, and the "when"

=C2=A0 =C2=A0 =C2=A0 condition evaluates to "false", the server M=
UST reply with an

=C2=A0 =C2=A0 =C2=A0 "unknown-element" error-tag in the rpc-error=
.



and add to 8.2.2:



=C2=A0 o=C2=A0 Modification requests for nodes tagged with "when"=
, and the "when"

=C2=A0 =C2=A0 =C2=A0condition evaluates to "false".=C2=A0 In this=
 case the server MUST reply

=C2=A0 =C2=A0 =C2=A0with an "unknown-element" error-tag in the rp=
c-error.






This seems like a BIG p=
rotocol change to <edit-config> behavior.
IMO this not an e=
rror at all.=C2=A0 In our server the false-when data is just
prun=
ed, and no error is ever sent for a pruned when=3Dfalse data node.

It may be a client programming error for the client to pro=
vide
false when nodes or not.=C2=A0 What if the client is reusing=
 some
code that sends 5 parameters, it it's OK if 1 of them g=
ets
pruned sometimes because of a false when (e.g, product
<=
div>feature-specific knob and that feature is not installed)

=

BTW, this is a really good example of what not to do, if one
wants to make the YANG specification protocol independent.


=C2=A0 =C2=A0

/martin




Andy
=C2=A0



> regards Balazs

>

> On 2015-10-13 13:30, Martin Bjorklund wrote:

> > Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> >> Hello Martin,

> >> If I had a model

> >>

> >> leaf a {type boolean;}

> >> leaf b {

> >>=C2=A0 =C2=A0 =C2=A0 when a

> >>=C2=A0 =C2=A0 =C2=A0 type int8;

> >> }

> >>

> >> if "a" is false and then you get an edit config wit=
h: set b=3D5 ; set

> >> a=3Dtrue

> >> What should be the result?

> >> A1)=C2=A0 this should succeed as at commit time the "whe=
n" will be true.

> > yes.

> >

> >> A2) this should fail as at parsing (as described in 8.2.1 of =
the YANG

> >> RFC) the when is false - yet. This would also mean that you n=
eed 2

> >> edit-configs to set b=3D5.

> >> regards Balazs

> >

> > /martin

>

> --

> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> Senior Specialist

> ECN: 831 7320

> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c26650491d1e052215aefa--


From nobody Wed Oct 14 12:38:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE31A1B87 for ; Wed, 14 Oct 2015 12:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aAQuBqeCUe0 for ; Wed, 14 Oct 2015 12:38:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 31D211A1A9D for ; Wed, 14 Oct 2015 12:38:36 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 765951AE044D; Wed, 14 Oct 2015 21:38:35 +0200 (CEST)
Date: Wed, 14 Oct 2015 21:41:45 +0200 (CEST)
Message-Id: <20151014.214145.1464628339304882836.mbj@tail-f.com>
To: wfl@cantab.net
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] not a non-presence container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:38:39 -0000

William Lupton  wrote:
> All,
> 
> Both RFC 6020 and the bis draft use the term "not a non-presence
> container", sometimes with a reference to section 7.5.1.
> 
> Does this term mean the same as "presence container"?

No.  A list (for example) is not a non-presence container.

> If so, I think it
> would be easier (on the reader!) to say that instead. If not, I think that
> the term warrants a mention in section 7.5.1.

The term is "non-presence container", and it is explained in 7.5.1.


/martin


From nobody Wed Oct 14 12:45:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195F31A0117 for ; Wed, 14 Oct 2015 12:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6w4-DthTiHC for ; Wed, 14 Oct 2015 12:45:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 017691A0115 for ; Wed, 14 Oct 2015 12:45:04 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 92B8F1AE044D; Wed, 14 Oct 2015 21:45:02 +0200 (CEST)
Date: Wed, 14 Oct 2015 21:48:13 +0200 (CEST)
Message-Id: <20151014.214813.106525154933227408.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <561CF838.3090308@ericsson.com> <20151014.212518.877320464279591732.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:45:05 -0000

Andy Bierman  wrote:
> On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund  wrote:
> 
> > Balazs Lengyel  wrote:
> > > Hello Martin,
> > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > should change/correct 8.2.1 in YANG because that implies A2 and error.
> >
> > Ok, I agree.  I suggest we remove from 8.2.1:
> >
> >    o  If data for a node tagged with "when" is present, and the "when"
> >       condition evaluates to "false", the server MUST reply with an
> >       "unknown-element" error-tag in the rpc-error.
> >
> > and add to 8.2.2:
> >
> >   o  Modification requests for nodes tagged with "when", and the "when"
> >      condition evaluates to "false".  In this case the server MUST reply
> >      with an "unknown-element" error-tag in the rpc-error.
> >
> >
> >
> 
> This seems like a BIG protocol change to  behavior.
> IMO this not an error at all.  In our server the false-when data is just
> pruned, and no error is ever sent for a pruned when=false data node.

So you are not following the current RFC 6020 spec?

I don't think this is a BIG protocol change, since the spec already
says that requests for nodes w/ false when expressions MUST send
error.  The change is to say that this behavior is true regardless of
evaluation order.

> It may be a client programming error for the client to provide
> false when nodes or not.  What if the client is reusing some
> code that sends 5 parameters, it it's OK if 1 of them gets
> pruned sometimes because of a false when (e.g, product
> feature-specific knob and that feature is not installed)

Well, it might be simpler to send if-featured nodes that the specific
server doesn't support - this is also an error in 6020.

> BTW, this is a really good example of what not to do, if one
> wants to make the YANG specification protocol independent.

That statement is true for the entire section 8.2, it is not
specifically true for this change.


/martin


From nobody Wed Oct 14 12:49:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8D1A0187 for ; Wed, 14 Oct 2015 12:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSs13a5DiPHb for ; Wed, 14 Oct 2015 12:49:14 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 6784A1A0195 for ; Wed, 14 Oct 2015 12:49:14 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so25009127lbb.0 for ; Wed, 14 Oct 2015 12:49:12 -0700 (PDT)
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=zR2h/1VFOXWmjUgxFIvErlV2YHaEuXxZM8lhscWQsIw=; b=euNOb1u+FMeT+c+Y3CW7dT/Zb2zK2fDPo525yFSgd/8FYKz4dZRrDsbGTEMIx3RnBd vGIpswIEoeyaO7CGD+RGwOJEPX8uO92wgCpneyfOiV6iBJly1sdauRcH5ulkj29FPJhA djoX7RoMxXzqbE248k6tnMpjBpNGFhEIxuLKvoHdtmV08YNdxvFF9g2ykqYCDy/f42tk UuQtW1CkF2bbEa0S7aBkP0kFH90GPtz8U7vHJ6XrwdzdtTqD1FAsmVRHB5yovw6tJetc OouDjE3KBH6uBFLpI2XULMftJcA+DmmG4ZWq8avlWdEBBC33Fjid/ltWE42lgyhWb0hk Jo3Q==
X-Gm-Message-State: ALoCoQm/maOS1bRKt2VsKCsDhH+rHQ7h/t4QzvYdZUVt0nS6ZYonwf55nHrmQIwYc66WWvMMh3Ne
MIME-Version: 1.0
X-Received: by 10.112.170.165 with SMTP id an5mr2554538lbc.33.1444852152624; Wed, 14 Oct 2015 12:49:12 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 14 Oct 2015 12:49:12 -0700 (PDT)
In-Reply-To: <20151014.214813.106525154933227408.mbj@tail-f.com>
References: <561CF838.3090308@ericsson.com> <20151014.212518.877320464279591732.mbj@tail-f.com>  <20151014.214813.106525154933227408.mbj@tail-f.com>
Date: Wed, 14 Oct 2015 12:49:12 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c37a244f9bb8052215db14
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 19:49:16 -0000

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

On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
> wrote:
> >
> > > Balazs Lengyel  wrote:
> > > > Hello Martin,
> > > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > > should change/correct 8.2.1 in YANG because that implies A2 and
> error.
> > >
> > > Ok, I agree.  I suggest we remove from 8.2.1:
> > >
> > >    o  If data for a node tagged with "when" is present, and the "when"
> > >       condition evaluates to "false", the server MUST reply with an
> > >       "unknown-element" error-tag in the rpc-error.
> > >
> > > and add to 8.2.2:
> > >
> > >   o  Modification requests for nodes tagged with "when", and the "when"
> > >      condition evaluates to "false".  In this case the server MUST
> reply
> > >      with an "unknown-element" error-tag in the rpc-error.
> > >
> > >
> > >
> >
> > This seems like a BIG protocol change to  behavior.
> > IMO this not an error at all.  In our server the false-when data is just
> > pruned, and no error is ever sent for a pruned when=false data node.
>
> So you are not following the current RFC 6020 spec?
>


Yes we are following it.
The schema for the edit-config RPC operation contains
an 'anyxml' for  node.  It does not contain any
when-stmts for the data nodes that get passed in the  node.
The correct behavior is to just enforce the error on the when-stmts
that appear in the rpc-stmt.




> I don't think this is a BIG protocol change, since the spec already
> says that requests for nodes w/ false when expressions MUST send
> error.  The change is to say that this behavior is true regardless of
> evaluation order.
>
> > It may be a client programming error for the client to provide
> > false when nodes or not.  What if the client is reusing some
> > code that sends 5 parameters, it it's OK if 1 of them gets
> > pruned sometimes because of a false when (e.g, product
> > feature-specific knob and that feature is not installed)
>
> Well, it might be simpler to send if-featured nodes that the specific
> server doesn't support - this is also an error in 6020.
>
> > BTW, this is a really good example of what not to do, if one
> > wants to make the YANG specification protocol independent.
>
> That statement is true for the entire section 8.2, it is not
> specifically true for this change.
>
>
> /martin
>


Andy

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




On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> > > Hello Martin,

> > > I agree that A1 is what follows the spirit of YANG, but then=
 IMHO you

> > > should change/correct 8.2.1 in YANG because that implies A2 =
and error.

> >

> > Ok, I agree.=C2=A0 I suggest we remove from 8.2.1:

> >

> >=C2=A0 =C2=A0 o=C2=A0 If data for a node tagged with "when&qu=
ot; is present, and the "when"

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evaluates to "false"=
;, the server MUST reply with an

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-element" error-tag i=
n the rpc-error.

> >

> > and add to 8.2.2:

> >

> >=C2=A0 =C2=A0o=C2=A0 Modification requests for nodes tagged with &=
quot;when", and the "when"

> >=C2=A0 =C2=A0 =C2=A0 condition evaluates to "false".=C2=
=A0 In this case the server MUST reply

> >=C2=A0 =C2=A0 =C2=A0 with an "unknown-element" error-tag=
 in the rpc-error.

> >

> >

> >

>

> This seems like a BIG protocol change to <edit-config> behavior.=


> IMO this not an error at all.=C2=A0 In our server the false-when data =
is just

> pruned, and no error is ever sent for a pruned when=3Dfalse data node.=




So you are not following the current RFC 6020 spec?

Yes we are following it.
The schema f=
or the edit-config RPC operation contains
an 'anyxml' for=
 <config> node.=C2=A0 It does not contain any
when-stmts fo=
r the data nodes that get passed in the <config> node.
The =
correct behavior is to just enforce the error on the when-stmts
t=
hat appear in the rpc-stmt.






I don't think this is a BIG protocol change, since the spec already

says that requests for nodes w/ false when expressions MUST send

error.=C2=A0 The change is to say that this behavior is true regardless of<=
br>
evaluation order.



> It may be a client programming error for the client to provide

> false when nodes or not.=C2=A0 What if the client is reusing some

> code that sends 5 parameters, it it's OK if 1 of them gets

> pruned sometimes because of a false when (e.g, product

> feature-specific knob and that feature is not installed)



Well, it might be simpler to send if-featured nodes that the specific

server doesn't support - this is also an error in 6020.



> BTW, this is a really good example of what not to do, if one

> wants to make the YANG specification protocol independent.



That statement is true for the entire section 8.2, it is not

specifically true for this change.





/martin




<=
/div>
Andy



--001a11c37a244f9bb8052215db14--


From nobody Wed Oct 14 13:23:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BABE1A7021 for ; Wed, 14 Oct 2015 13:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSJw2CqR4MrR for ; Wed, 14 Oct 2015 13:23:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA71A7004 for ; Wed, 14 Oct 2015 13:23:35 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 227EA1AE044D; Wed, 14 Oct 2015 22:23:32 +0200 (CEST)
Date: Wed, 14 Oct 2015 22:26:42 +0200 (CEST)
Message-Id: <20151014.222642.365989360913160897.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20151014.214813.106525154933227408.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 20:23:36 -0000

Andy Bierman  wrote:
> On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
> > wrote:
> > >
> > > > Balazs Lengyel  wrote:
> > > > > Hello Martin,
> > > > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> > error.
> > > >
> > > > Ok, I agree.  I suggest we remove from 8.2.1:
> > > >
> > > >    o  If data for a node tagged with "when" is present, and the "when"
> > > >       condition evaluates to "false", the server MUST reply with an
> > > >       "unknown-element" error-tag in the rpc-error.
> > > >
> > > > and add to 8.2.2:
> > > >
> > > >   o  Modification requests for nodes tagged with "when", and the "when"
> > > >      condition evaluates to "false".  In this case the server MUST
> > reply
> > > >      with an "unknown-element" error-tag in the rpc-error.
> > > >
> > > >
> > > >
> > >
> > > This seems like a BIG protocol change to  behavior.
> > > IMO this not an error at all.  In our server the false-when data is just
> > > pruned, and no error is ever sent for a pruned when=false data node.
> >
> > So you are not following the current RFC 6020 spec?
> >
> 
> 
> Yes we are following it.

Ok.

> The schema for the edit-config RPC operation contains
> an 'anyxml' for  node.  It does not contain any
> when-stmts for the data nodes that get passed in the  node.
> The correct behavior is to just enforce the error on the when-stmts
> that appear in the rpc-stmt.

I don't understand what you are trying to say.

Here's an example:

  augment /if:interfaces/if:interface {
    when "if:type = 'ianaift:ethernetCsmacd'";

    container ethernet {
      leaf duplex {
        type enumeration {
          enum "half";
          enum "full";
        }
      }
    }
  }

Suppose the db is empty.

What if the edit-confif contains
 
  
    
      eth0
      full
      ianaift:ethernetCsmacd
    
  

will that work or not?  I.e., will the eth0 interface be created with
duplex full?
  

/martin



> 
> 
> 
> 
> > I don't think this is a BIG protocol change, since the spec already
> > says that requests for nodes w/ false when expressions MUST send
> > error.  The change is to say that this behavior is true regardless of
> > evaluation order.
> >
> > > It may be a client programming error for the client to provide
> > > false when nodes or not.  What if the client is reusing some
> > > code that sends 5 parameters, it it's OK if 1 of them gets
> > > pruned sometimes because of a false when (e.g, product
> > > feature-specific knob and that feature is not installed)
> >
> > Well, it might be simpler to send if-featured nodes that the specific
> > server doesn't support - this is also an error in 6020.
> >
> > > BTW, this is a really good example of what not to do, if one
> > > wants to make the YANG specification protocol independent.
> >
> > That statement is true for the entire section 8.2, it is not
> > specifically true for this change.
> >
> >
> > /martin
> >
> 
> 
> Andy


From nobody Wed Oct 14 14:06:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11741A8927 for ; Wed, 14 Oct 2015 14:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIMDcssTSNpu for ; Wed, 14 Oct 2015 14:06:49 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 82E7B1A8906 for ; Wed, 14 Oct 2015 14:06:48 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so26336821lbb.0 for ; Wed, 14 Oct 2015 14:06:46 -0700 (PDT)
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=ke2OhHmEx6FO9Ts62uis2kaDv6V3E/JrUs/4HSr4eFA=; b=TYXRvVYXw74ptkHERyB0KEcqsJGeI35coC+5dgBhby1RjBl/Duioq70Y9fLD2oKRuM mSq+YM9mh6Dv1tzutyUG21sFvbyEPPbLzjZsM4R3YXbClBas7QSR3ZXgZx6cKMuYqICw erwY2GpW/5xyel8zRWFHZAlCJ1jou+0IYQZ/vv9C+xrWwEgShTvgKkimzgoxqONm1460 mlPxNZ2MsGz8Lcdz6o5m6KZBXzXwNJAC/TpeTWOWrluJjsohlTLVWigjBgkhmqv/kukT Lx/o9QFk5584gxbak4QlhcTQyyNL5eExTgx5WWEhAil/v0Zzxbe+6B7L+FCGlEz8icRT fcnw==
X-Gm-Message-State: ALoCoQnjMF52Iw6SdUn1fmkowxxbUloXTR257r/4GEsVqitWloqC4GKa6VG7uFtM8vUP0aqIY1pc
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr2708920lbc.123.1444856806766;  Wed, 14 Oct 2015 14:06:46 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 14 Oct 2015 14:06:46 -0700 (PDT)
In-Reply-To: <20151014.222642.365989360913160897.mbj@tail-f.com>
References:  <20151014.214813.106525154933227408.mbj@tail-f.com>  <20151014.222642.365989360913160897.mbj@tail-f.com>
Date: Wed, 14 Oct 2015 14:06:46 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c26650b81bcf052216f0c1
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 21:06:51 -0000

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

On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
> > > wrote:
> > > >
> > > > > Balazs Lengyel  wrote:
> > > > > > Hello Martin,
> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> IMHO you
> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> > > error.
> > > > >
> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
> > > > >
> > > > >    o  If data for a node tagged with "when" is present, and the
> "when"
> > > > >       condition evaluates to "false", the server MUST reply with an
> > > > >       "unknown-element" error-tag in the rpc-error.
> > > > >
> > > > > and add to 8.2.2:
> > > > >
> > > > >   o  Modification requests for nodes tagged with "when", and the
> "when"
> > > > >      condition evaluates to "false".  In this case the server MUST
> > > reply
> > > > >      with an "unknown-element" error-tag in the rpc-error.
> > > > >
> > > > >
> > > > >
> > > >
> > > > This seems like a BIG protocol change to  behavior.
> > > > IMO this not an error at all.  In our server the false-when data is
> just
> > > > pruned, and no error is ever sent for a pruned when=false data node.
> > >
> > > So you are not following the current RFC 6020 spec?
> > >
> >
> >
> > Yes we are following it.
>
> Ok.
>
> > The schema for the edit-config RPC operation contains
> > an 'anyxml' for  node.  It does not contain any
> > when-stmts for the data nodes that get passed in the  node.
> > The correct behavior is to just enforce the error on the when-stmts
> > that appear in the rpc-stmt.
>
> I don't understand what you are trying to say.
>


I know about the text that says a false-when in an RPC is an error.
Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.




>
> Here's an example:
>
>   augment /if:interfaces/if:interface {
>     when "if:type = 'ianaift:ethernetCsmacd'";
>
>     container ethernet {
>       leaf duplex {
>         type enumeration {
>           enum "half";
>           enum "full";
>         }
>       }
>     }
>   }
>
> Suppose the db is empty.
>
> What if the edit-confif contains
>
>   
>     
>       eth0
>       full
>       ianaift:ethernetCsmacd
>     
>   
>
> will that work or not?  I.e., will the eth0 interface be created with
> duplex full?
>

Yes -- because these are data nodes and the rules for when-stmt
on data nodes are different than for rpc-stmt.  Then the when-stmt
is a test on whether the node should exist in the candidate or running
datastore.

Our server applies all the edits first, when checks all the when-stmts
that might have changed value.  Nodes that have already existed in the
datastore may get pruned, not just the new nodes.





>
> /martin
>
>
>

Andy


>
> >
> >
> >
> >
> > > I don't think this is a BIG protocol change, since the spec already
> > > says that requests for nodes w/ false when expressions MUST send
> > > error.  The change is to say that this behavior is true regardless of
> > > evaluation order.
> > >
> > > > It may be a client programming error for the client to provide
> > > > false when nodes or not.  What if the client is reusing some
> > > > code that sends 5 parameters, it it's OK if 1 of them gets
> > > > pruned sometimes because of a false when (e.g, product
> > > > feature-specific knob and that feature is not installed)
> > >
> > > Well, it might be simpler to send if-featured nodes that the specific
> > > server doesn't support - this is also an error in 6020.
> > >
> > > > BTW, this is a really good example of what not to do, if one
> > > > wants to make the YANG specification protocol independent.
> > >
> > > That statement is true for the entire section 8.2, it is not
> > > specifically true for this change.
> > >
> > >
> > > /martin
> > >
> >
> >
> > Andy
>

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




On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Andy Bierman <andy@yumaw=
orks.com> wrote:

> > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com>

> > wrote:

> > >

> > > > Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> > > > > Hello Martin,

> > > > > I agree that A1 is what follows the spirit of YANG=
, but then IMHO you

> > > > > should change/correct 8.2.1 in YANG because that i=
mplies A2 and

> > error.

> > > >

> > > > Ok, I agree.=C2=A0 I suggest we remove from 8.2.1:

> > > >

> > > >=C2=A0 =C2=A0 o=C2=A0 If data for a node tagged with &qu=
ot;when" is present, and the "when"

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evaluates to "=
false", the server MUST reply with an

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-element" e=
rror-tag in the rpc-error.

> > > >

> > > > and add to 8.2.2:

> > > >

> > > >=C2=A0 =C2=A0o=C2=A0 Modification requests for nodes tag=
ged with "when", and the "when"

> > > >=C2=A0 =C2=A0 =C2=A0 condition evaluates to "false&=
quot;.=C2=A0 In this case the server MUST

> > reply

> > > >=C2=A0 =C2=A0 =C2=A0 with an "unknown-element"=
 error-tag in the rpc-error.

> > > >

> > > >

> > > >

> > >

> > > This seems like a BIG protocol change to <edit-config>=
 behavior.

> > > IMO this not an error at all.=C2=A0 In our server the false-=
when data is just

> > > pruned, and no error is ever sent for a pruned when=3Dfalse =
data node.

> >

> > So you are not following the current RFC 6020 spec?

> >

>

>

> Yes we are following it.



Ok.



> The schema for the edit-config RPC operation contains

> an 'anyxml' for <config> node.=C2=A0 It does not contain=
 any

> when-stmts for the data nodes that get passed in the <config> no=
de.

> The correct behavior is to just enforce the error on the when-stmts
> that appear in the rpc-stmt.



I don't understand what you are trying to say.

I know about the text that says a false-when in =
an RPC is an error.
Show me the when-stmts =C2=A0"interface&=
quot; in the "edit-config" rpc-stmt.

=C2=A0



Here's an example:



=C2=A0 augment /if:interfaces/if:interface {

=C2=A0 =C2=A0 when "if:type =3D 'ianaift:ethernetCsmacd'"=
;



=C2=A0 =C2=A0 container ethernet {

=C2=A0 =C2=A0 =C2=A0 leaf duplex {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "half";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "full";

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

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

=C2=A0 =C2=A0 }

=C2=A0 }



Suppose the db is empty.



What if the edit-confif contains



=C2=A0 <interfaces>

=C2=A0 =C2=A0 <interface>

=C2=A0 =C2=A0 =C2=A0 <name>eth0</name>

=C2=A0 =C2=A0 =C2=A0 <eth:duplex>full</eth:duplex>

=C2=A0 =C2=A0 =C2=A0 <type>ianaift:ethernetCsmacd</type>

=C2=A0 =C2=A0 </interface>

=C2=A0 </interfaces>



will that work or not?=C2=A0 I.e., will the eth0 interface be created with<=
br>
duplex full?

Yes -- because these are d=
ata nodes and the rules for when-stmt
on data nodes are different=
 than for rpc-stmt.=C2=A0 Then the when-stmt
is a test on whether=
 the node should exist in the candidate or running
datastore.

Our server applies all the edits first, when checks a=
ll the when-stmts
that might have changed value.=C2=A0 Nodes that=
 have already existed in the
datastore may get pruned, not just t=
he new nodes.









/martin






Andy
=C2=A0



>

>

>

>

> > I don't think this is a BIG protocol change, since the spec a=
lready

> > says that requests for nodes w/ false when expressions MUST send<=
br>
> > error.=C2=A0 The change is to say that this behavior is true rega=
rdless of

> > evaluation order.

> >

> > > It may be a client programming error for the client to provi=
de

> > > false when nodes or not.=C2=A0 What if the client is reusing=
 some

> > > code that sends 5 parameters, it it's OK if 1 of them ge=
ts

> > > pruned sometimes because of a false when (e.g, product

> > > feature-specific knob and that feature is not installed)

> >

> > Well, it might be simpler to send if-featured nodes that the spec=
ific

> > server doesn't support - this is also an error in 6020.

> >

> > > BTW, this is a really good example of what not to do, if one=


> > > wants to make the YANG specification protocol independent.
> >

> > That statement is true for the entire section 8.2, it is not

> > specifically true for this change.

> >

> >

> > /martin

> >

>

>

> Andy





--001a11c26650b81bcf052216f0c1--


From nobody Wed Oct 14 14:28:34 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B4B1A89BB for ; Wed, 14 Oct 2015 14:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRBYu35wfYQd for ; Wed, 14 Oct 2015 14:28:28 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E71F1A89B0 for ; Wed, 14 Oct 2015 14:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19148; q=dns/txt; s=iport; t=1444858106; x=1446067706; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=EeRbWKVXVtHYW4uj0lb0bf0KoopHLRI9oxtEGiXVCXI=; b=RkaTTHheWdnEJSJYCKbOxUbL05Qjk3xMXz0cHQGVrbiThO7E0lFO2Z0v jzznDq8LHgraOMOK3VEafX1GJXraClXeAhdwuwyF2x/bGivSnSrE/K0U3 z6KTmCyeIuZaSqqbzo6Ndo4/0msPkf63kTTg4UbpMo97rBkz0O2JAfbJo M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CrBQBuyB5W/xbLJq1eglmBIW6/CxcBCYJyggo1SgKCGAEBAQEBAYELhCYBAQEDAQEBAWsKAQULCw4DAwECAQkWCAcJAwIBAgEVHwkIBgEMBgIBAReICwgNw10BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZ2hH6EfBEHhC4FlhWNG4FYhzuPCINvY4JEgT89M4ZvAQEB
X-IronPort-AV: E=Sophos;i="5.17,682,1437436800";  d="scan'208,217";a="607617449"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Oct 2015 21:28:24 +0000
Received: from [10.61.102.106] (dhcp-10-61-102-106.cisco.com [10.61.102.106]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9ELSMhf009339;  Wed, 14 Oct 2015 21:28:23 GMT
To: Kent Watsen , Andy Bierman 
References:  <560D269E.30002@cisco.com>   
From: Robert Wilton 
Message-ID: <561EC8E7.9080708@cisco.com>
Date: Wed, 14 Oct 2015 22:28:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010800090807040301060503"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 21:28:31 -0000

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



On 14/10/2015 20:15, Kent Watsen wrote:
> Andy writes:
> > I am wondering why operators would want to compare 2 massive subtrees
> > in the first place, where 1 is static and the other is changing 
> constantly.
> >
> > Do they really want this complex task or do they just want to
> > determine if the intended config has been applied yet?
>
> I think that it is more the latter.   And there have been suggestions 
> for solutions to provide something like a yang-patch to describe just 
> the diffs.  Makes sense to me!

The NMS already knows the intended config since it sent it to the device 
in the first place, so in normal circumstances I would expect the NMS to 
only query the applied config (and possibly derived state at the same 
time) and then compare it to the NMS's view of the intended cfg for that 
device.  If the NMS is smart then it might be able to restrict most of 
the queries to only the device's applied config sub-trees that could 
possibly be out of sync, perhaps with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also 
be useful (the draft that I put forward also proposes a diff-cfg-only 
option).  However, it is also worth noting that the original 
requirements don't explicitly ask for this, so perhaps more of a nice to 
have than a formal requirement?

Thanks,
Rob


>
> K.
>
>
> From: Andy Bierman >
> Date: Wednesday, October 14, 2015 at 2:56 PM
> To: Kent Watsen >
> Cc: Robert Wilton >, 
> "netmod@ietf.org "  >
> Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of 
> "applied configuration"
>
>
>
> On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  > wrote:
>
>
>     Thank you Robert for bringing the discussion back to the github
>     issues.
>
>     Robert writes:
>
>     > In particular:
>     >    - does it include support for templating (as per openconfig-netmod-opstate-01 section 7.3.)?
>     >    - is it allowed to represent system created objects that have
>     no corresponding configuration?
>     >
>     > Requirement 1.D states
>
>           D.  For asynchronous systems, when fully synchronized, the data
>                 in the applied configuration is the same as the data in the
>                 intended configuration.
>
>     >
>     > So, if this requirement statement stands as being valid (which I
>     think it should) then that would imply that the answer for both
>     the two issues above must be "no".  The only question would be
>     whether these need to be explicitly listed out?
>
>     [KENT] so I think I have to (begrudgingly) agree with your logic.
>        I have heard the operators state that they want the
>     intended/applied comparison to be drop-dead simple.  To that end,
>     it would not be possible to flatten templates or apply defaults,
>     or make any other change – it needs to be as close as possible to
>     a carbon-copy of the original intended configuration (where
>     deviations are allowed only for cases like a missing line-card). 
>     To this end, yes, I think that we could tack on a statement like
>     the following:
>
>     That is, the intended configuration is a subset of the applied
>     configuration where omissions are only due to when the
>     configuration cannot be applied (e.g., a missing line-card).
>
>     What do you think?
>
>
>
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing 
> constantly.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?
>
>
> Andy
>
>
>
>
>     >>  - how does it relate to the state of the system after a equivalent synchronous config commit (if at
>     all)?
>     >>
>     > Again, I think that definition of requirement 1.D, along with
>     the proposed definition of synchronous configuration operation vs
>     asynchronous configuration operation, will provide a sufficient
>     answer to this question.  I.e. that the state of the system after
>     an asynchronous config operation must, when fully synchronized, be
>     the same as the state of the system after an equivalent
>     synchronous configuration operation completes and replies back.
>
>     [KENT] I agree with this, but I think it impacts issue #6 more so
>     than issue #4 - right?
>
>
>     Thanks,
>     Kent
>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>


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


  
    
  
  
    

    

    
On 14/10/2015 20:15, Kent Watsen wrote:

    

    

      
      

        
Andy writes:

        
> I am wondering why
            operators would want to compare 2 massive subtrees

        
> in the first place,
            where 1 is static and the other is changing constantly.

        
>

        
> Do they really want
            this complex task or do they just want to

        
> determine if the
            intended config has been applied yet?

      

      

        

      

      

        I think that it is more the latter.   And there have been
        suggestions for solutions to provide something like a yang-patch
        to describe just the diffs.  Makes sense to me!

    

    

    The NMS already knows the intended config since it sent it to the
    device in the first place, so in normal circumstances I would expect
    the NMS to only query the applied config (and possibly derived state
    at the same time) and then compare it to the NMS's view of the
    intended cfg for that device.  If the NMS is smart then it might be
    able to restrict most of the queries to only the device's applied
    config sub-trees that could possibly be out of sync, perhaps with
    periodic full synchronization checks.

    

    Otherwise, I think that a function that returns just the diff may
    also be useful (the draft that I put forward also proposes a
    diff-cfg-only option).  However, it is also worth noting that the
    original requirements don't explicitly ask for this, so perhaps more
    of a nice to have than a formal requirement?

    

    Thanks,

    Rob

    

    

    

      

        

      

      

        K.

      

        

      

      

        

      

      
        

          From: Andy Bierman <andy@yumaworks.com>

          Date: Wednesday,
          October 14, 2015 at 2:56 PM

          To: Kent Watsen <kwatsen@juniper.net>

          Cc: Robert Wilton <rwilton@cisco.com>,
          "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          opstate-reqs #4: Provide a tighter definition of "applied
          configuration"

        

        


        

        

          

            


              


                
On Wed, Oct 14, 2015 at 11:00
                  AM, Kent Watsen 
                    <kwatsen@juniper.net>
                  wrote:

                  

                    

                      


                      

                      
Thank you Robert for bringing the discussion
                        back to the github issues.

                      


                      

                      
Robert writes:

                      


                      

                      
                        

                          
>
                            In particular:

                        

                      
                      
>    - does it include support for
                        templating (as per openconfig-netmod-opstate-01
                        section 7.3.)?

                      
                        

                          
>
                               - is it allowed to represent system
                            created objects that have no corresponding
                            configuration?

                          >

                          > Requirement 1.D states

                          
     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

                          >

                          > So, if this requirement statement stands
                          as being valid (which I think it should) then
                          that would imply that the answer for both the
                          two issues above must be "no".  The only
                          question would be whether these need to be
                          explicitly listed out?

                          

                        

                      
                      
[KENT] so I think I have to (begrudgingly)
                        agree with your logic.    I have heard the
                        operators state that they want the
                        intended/applied comparison to be drop-dead
                        simple.  To that end, it would not be possible
                        to flatten templates or apply defaults, or make
                        any other change – it needs to be as close as
                        possible to a carbon-copy of the original
                        intended configuration (where deviations are
                        allowed only for cases like a missing
                        line-card).  To this end, yes, I think that we
                        could tack on a statement like the following:

                      


                      

                      
That
                        is, the intended configuration is a subset of
                        the applied 

                      
configuration
                        where omissions are only due to when the

                      
configuration
                        cannot be applied (e.g., a missing line-card).

                      


                      

                      
What do you think?

                    

                  

                  


                  

                  


                  

                  
I am wondering why operators would want to
                    compare 2 massive subtrees

                  
in the first place, where 1 is static and the
                    other is changing constantly.

                  


                  

                  
Do they really want this complex task or do they
                    just want to

                  
determine if the intended config has been applied
                    yet?

                  

                  


                  

                  


                  

                  
Andy

                  


                  

                  

                    

                      


                      

                      


                      

                      


                      

                      
>>  - how does it relate to the state
                        of the system after a equivalent synchronous
                        config commit (if at all)?

                      
                        
>>

                          > Again, I think that definition of
                          requirement 1.D, along with the proposed
                          definition of synchronous configuration
                          operation vs asynchronous configuration
                          operation, will provide a sufficient answer to
                          this question.  I.e. that the state of the
                          system after an asynchronous config operation
                          must, when fully synchronized, be the same as
                          the state of the system after an equivalent
                          synchronous configuration operation completes
                          and replies back.

                        

                      
                      


                      

                      
                        
[KENT] I
                          agree with this, but I think it impacts issue
                          #6 more so than issue #4 - right?

                      
                      


                      

                      


                      

                      
                        
Thanks,

                      
                      
Kent

                      


                      

                      
                        


                        

                      

                    

                    _______________________________________________

                    netmod mailing list

                    netmod@ietf.org

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

                    

                  

                

                

              

            

          

        

      
    

    

  


--------------010800090807040301060503--


From nobody Wed Oct 14 14:31:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081F01A89FB for ; Wed, 14 Oct 2015 14:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rceP-CPKQuaK for ; Wed, 14 Oct 2015 14:30:50 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD9A1A89A9 for ; Wed, 14 Oct 2015 14:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10536; q=dns/txt; s=iport; t=1444858250; x=1446067850; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=CWyGInZWw8EogdB0JmA6wXHWBv8870brAAWvUum56gY=; b=XLDOrfOk7nXaTgABzNB7fyk7x7aBDDGW4JubTnO+qyZ3Yv5Fc9FqaJ1H /xXuo1vY0bKPJ+HSCpoF6q6QQJXWpi4+xEYet9ZejxfCm6hTLiMz/bT/a 3oa+QDBjiz289A1JcRR9LNL56mvnlRI4JtObAe/m7T2yykkWe8C91yVea k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CqBQAbyB5W/xbLJq1eglmBIW6/CxcBCYJyggo1SgKCGAEBAQEBAYELhCcBAQQBAQFrChELDgoJFg8JAwIBAgEVMAYBDAYCAQGIKg3DXgEBAQEBAQEBAQEBAQEBAQEBARYEhnaEfoUUhC4FklWDQIUZiAKJE5J3Y4QDPTOGbwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,682,1437436800";  d="scan'208,217";a="605741144"
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; 14 Oct 2015 21:30:47 +0000
Received: from [10.61.102.106] (dhcp-10-61-102-106.cisco.com [10.61.102.106]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9ELUl6d009780;  Wed, 14 Oct 2015 21:30:47 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <561EC979.8000004@cisco.com>
Date: Wed, 14 Oct 2015 22:30:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090301090604070108050401"
Archived-At: 
Subject: Re: [netmod] upstate-reqs #8: ability to retrieve both op-state types together
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 21:30:56 -0000

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

Hi Kent,

I support adding this.

Thanks,
Rob


On 14/10/2015 19:56, Kent Watsen wrote:
>
> I created this issue a little more than a week ago, but forgot to CC 
> the list until now – sorry!
>
> GitHub issue #8 (https://github.com/netmod-wg/opstate-reqs/issues/8) says:
>
> ====START====
> On the interim call, Rob made in interesting point about 
> config+operational, using BGP as an example.
>
> Do we need to amend point 4 to allow for a method to retrieve these in 
> a single operation?
>
> OLD:
>
>    4.  Separation of configuration and operational state data; ability
>        to retrieve them independently
>        A.  Be able to retrieve only the derived state aspects of
>            operational state
>        B.  Be able to retrieve only the non-derived state aspects of
>            operational state
>
> NEW:
>
>    4.  Separation of configuration and operational state data; ability
>        to retrieve them both together and independently
>        A.  Be able to retrieve only the derived state aspects of
>            operational state
>        B.  Be able to retrieve only the non-derived state aspects of
>            operational state
>        C.  Be able to retrieve both the derived and non-derived state
>            aspects of operational state together
>
> ====STOP====
>
>
> Any objections to adding 4C?
>
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    Hi Kent,

    

    I support adding this.

    

    Thanks,

    Rob

    

    

    
On 14/10/2015 19:56, Kent Watsen wrote:

    

    

      
      

        

      

      

        I created this issue a little more than a week ago, but forgot
        to CC the list until now – sorry!

      

        

      

      
      

        

        

      

        ====START====

      

        On the interim call, Rob made in
          interesting point about config+operational, using BGP as an
          example.

      

        

        

      

        Do we need to amend point 4 to
          allow for a method to retrieve these in a single operation?

      

        

        

      

        OLD:

      

        

        

      

           4.  Separation of
          configuration and operational state data; ability

      

               to retrieve them
          independently

      

               A.  Be able to retrieve
          only the derived state aspects of

      

                   operational state

      

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

      

                   operational state

      

        

        

      

        NEW:

      

        

        

      

           4.  Separation of
          configuration and operational state data; ability

      

               to retrieve them both
          together and independently

      

               A.  Be able to retrieve
          only the derived state aspects of

      

                   operational state

      

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

      

                   operational state

      

               C.  Be able to retrieve
          both the derived and non-derived state

      

                   aspects of
          operational state together

      

        

        

      

        ====STOP====

      

        

        

      

        

        

      

        Any objections to adding 4C?  

      

        

        

      

        

        

      

        Thanks,

      

        Kent

      

        

        

      

      

      

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


    

    

  


--------------090301090604070108050401--


From nobody Wed Oct 14 14:44:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835751A8A39 for ; Wed, 14 Oct 2015 14:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vpykwSv-HnU for ; Wed, 14 Oct 2015 14:44:14 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398FF1A8956 for ; Wed, 14 Oct 2015 14:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8663; q=dns/txt; s=iport; t=1444859055; x=1446068655; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=/UheWBu2OtFTifk0BSoyjrMz4js91iNGzioBXfzj8p4=; b=Uv4Nu4r3dYJ8/EhROsOk+44iCpQ7ErYQD6fesfT9nAEomegmf6eiXZAm 0kj8gn65nEc3JtjoygZLKaM5dKn8hVrQ70nKl9lz35SMQMl3dsvbs9JqV Rz27b2tTUFhINxTlCJUpZQC5ZaxAQhedzHbd+KVaTqnJmpgygfUamAhk0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DJAQAtzB5W/xbLJq1eglm/NAENgVqDRYJXAoIEFAEBAQEBAQGBCoQmAQEBAwF4BgsLDgoJFg8JAwIBAgFFBgEMCAEBiCIIw2kBAQEBAQEBAwEBAQEBAQEBGoZ2hH6FFIQuBZYXjRuBWIc7jwmDbx8BAUKCRIFAPYciAQEB
X-IronPort-AV: E=Sophos;i="5.17,682,1437436800";  d="scan'208,217";a="630336375"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Oct 2015 21:44:13 +0000
Received: from [10.61.102.106] (dhcp-10-61-102-106.cisco.com [10.61.102.106]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9ELiBTM012196;  Wed, 14 Oct 2015 21:44:11 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <560D269E.30002@cisco.com> 
From: Robert Wilton 
Message-ID: <561ECC9E.8070100@cisco.com>
Date: Wed, 14 Oct 2015 22:43:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030007030200060703010504"
Archived-At: 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 21:44:16 -0000

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



On 14/10/2015 19:00, Kent Watsen wrote:
>
> Thank you Robert for bringing the discussion back to the github issues.
>
> Robert writes:
>
> > In particular:
> >    - does it include support for templating (as per 
> openconfig-netmod-opstate-01 section 7.3.)?
> >    - is it allowed to represent system created objects that have no 
> corresponding configuration?
> >
> > Requirement 1.D states
>       D.  For asynchronous systems, when fully synchronized, the data
>             in the applied configuration is the same as the data in the
>             intended configuration.
> >
> > So, if this requirement statement stands as being valid (which I 
> think it should) then that would imply that the answer for both the 
> two issues above must be "no".  The only question would be whether 
> these need to be explicitly listed out?
>
> [KENT] so I think I have to (begrudgingly) agree with your logic.    I 
> have heard the operators state that they want the intended/applied 
> comparison to be drop-dead simple.  To that end, it would not be 
> possible to flatten templates or apply defaults, or make any other 
> change – it needs to be as close as possible to a carbon-copy of the 
> original intended configuration (where deviations are allowed only for 
> cases like a missing line-card).  To this end, yes, I think that we 
> could tack on a statement like the following:
>
> That is, the intended configuration is a subset of the applied
> configuration where omissions are only due to when the
> configuration cannot be applied (e.g., a missing line-card).
>
> What do you think?
>
>
>
> >>  - how does it relate to the state of the system after a equivalent 
> synchronous config commit (if at all)?
> >>
> > Again, I think that definition of requirement 1.D, along with the 
> proposed definition of synchronous configuration operation vs 
> asynchronous configuration operation, will provide a sufficient answer 
> to this question.  I.e. that the state of the system after an 
> asynchronous config operation must, when fully synchronized, be the 
> same as the state of the system after an equivalent synchronous 
> configuration operation completes and replies back.
>
> [KENT] I agree with this, but I think it impacts issue #6 more so than 
> issue #4 - right?

The original question that I was responding to was recorded in the 
description of issue #4, but I agree that this is also effectively 
covered by the proposed descriptions for #6 anyway.

Thanks,
Rob


>
>
> Thanks,
> Kent
>
>


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


  
    
  
  
    

    

    
On 14/10/2015 19:00, Kent Watsen wrote:

    

    

      
      


      

      
Thank you Robert for bringing the discussion back to the
        github issues.

      


      

      
Robert writes:

      


      

      
        

          

            > In particular:

        

      
      
>    - does it include support for templating (as per
        openconfig-netmod-opstate-01 section 7.3.)?

      
        

          

            >    - is it allowed to represent system created objects
            that have no corresponding configuration?

          >

          > Requirement 1.D states

          
     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

          >

          > So, if this requirement statement stands as being valid
          (which I think it should) then that would imply that the
          answer for both the two issues above must be "no".  The only
          question would be whether these need to be explicitly listed
          out?

          

        

      
      
[KENT] so I think I have to (begrudgingly) agree with your
        logic.    I have heard the operators state that they want the
        intended/applied comparison to be drop-dead simple.  To that
        end, it would not be possible to flatten templates or apply
        defaults, or make any other change – it needs to be as close as
        possible to a carbon-copy of the original intended configuration
        (where deviations are allowed only for cases like a missing
        line-card).  To this end, yes, I think that we could tack on a
        statement like the following:

      


      

      
That
        is, the intended configuration is a subset of the applied 

      
configuration
        where omissions are only due to when the

      
configuration
        cannot be applied (e.g., a missing line-card).

      


      

      
What do you think?

      


      

      


      

      


      

      
>>  - how does it relate to the state of the system
        after a equivalent synchronous config commit (if at all)?

      
        
>>

          > Again, I think that definition of requirement 1.D, along
          with the proposed definition of synchronous configuration
          operation vs asynchronous configuration operation, will
          provide a sufficient answer to this question.  I.e. that the
          state of the system after an asynchronous config operation
          must, when fully synchronized, be the same as the state of the
          system after an equivalent synchronous configuration operation
          completes and replies back.

        

      
      


      

      
        
[KENT] I agree with this,
          but I think it impacts issue #6 more so than issue #4 - right?

      

    

    The original question that I was responding to was recorded in the
    description of issue #4, but I agree that this is also effectively
    covered by the proposed descriptions for #6 anyway.

    

    Thanks,

    Rob

    

    

    

      
      


      

      


      

      
        
Thanks,

      
      
Kent

      


      

      
        


        

      
    

    

  


--------------030007030200060703010504--


From nobody Wed Oct 14 15:06:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1DD1A903D for ; Wed, 14 Oct 2015 15:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CcyoxwdDPHB for ; Wed, 14 Oct 2015 15:06:49 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0841A9040 for ; Wed, 14 Oct 2015 15:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1539; q=dns/txt; s=iport; t=1444860410; x=1446070010; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=XeSFNtFGiHJKJ7o8vFWTl/zYtYiUlunnfGdy1wf17fM=; b=S3sJ7zTOYeIe+fezwdVRyz6G0fna+XNgXNYH4F7N0wm+538sBE/+6/rv LBE9hwo6NSbeCbfEAZZU66sTQTgdZT52jb/6hzamMFABC/irlAGhyXJd5 xVUb0Tdj67qpig4TYY6cMihN49B9froRUlRPp2rS4OUAu4cLLMJ2SSAsr k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DJAQDf0B5W/xbLJq1ewg0BDYFag0WCVwKCBBQBAQEBAQEBgQqEJgEBAQMBOEARCw4KCRYECwkDAgECAUUGAQwIAQGIIgjDYQEBAQEBAQEBAQEBAQEBAQEBARqGdoR+hRSELgEElheICYUSgViHO4owiEgfAQFCgkSBQD2HIgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,683,1437436800"; d="scan'208";a="630336633"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Oct 2015 22:06:48 +0000
Received: from [10.61.102.106] (dhcp-10-61-102-106.cisco.com [10.61.102.106]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9EM6l5L010563;  Wed, 14 Oct 2015 22:06:47 GMT
To: Kent Watsen , Andy Bierman , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local>
From: Robert Wilton 
Message-ID: <561ED1E8.3010106@cisco.com>
Date: Wed, 14 Oct 2015 23:06:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20150928084013.GB95620@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 22:06:51 -0000

On 28/09/2015 09:40, Juergen Schoenwaelder wrote:
> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
>> Popping the stack on this issue, the issue remains as to what to do with requirement 3:
>>
>>     3.  Support for both transactional, synchronous management systems
>>          as well as distributed, asynchronous management systems
>>
> I fail to understand 'transactional' and 'distributed' here. And
> frankly, I am not sure why the management _systems_ are classified to
> be synchronous or asynchronous - I think we are talking about
> protocols between a management system and a device. In NETCONF as well
> as RESTCONF are, you can pipeline YANG operations but all operations
> are processed sequentially in order.
I basically agree, and hence I think that we can just delete requirement 
3 above.

I'm not convinced that "transactional" or "distributed" are relevant to 
the opstate requirements, I expect that these terms were originally used 
to help provide a distinction between Netconf style interactions and 
whatever management systems the operators are currently considering of 
building with proprietary protocols.

Thanks,
Rob


>
> There are apparently other proprietary protocols that do things
> differently but so far we have not seen a specification of how this
> works.
>
> Anyway, I am not sure 3. is properly worded until someone defines
> 'transactional', 'distributed', 'synchronous management systems' and
> 'asynchronous management systems'.

>
> /js
>


From nobody Wed Oct 14 15:11:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADE31A9051 for ; Wed, 14 Oct 2015 15:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we24ICcsJMWx for ; Wed, 14 Oct 2015 15:11:24 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0081A8BB7 for ; Wed, 14 Oct 2015 15:11:23 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 22:11:20 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 22:11:20 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigA==
Date: Wed, 14 Oct 2015 22:11:20 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>
In-Reply-To: <561E6DC5.1080402@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:IXScj9Uag1tjGgH1sI+OaUJ5yloDUS+e8+aKS37b25TGJw2XZUQkeSqudqDucZyoo2lIsYoIBKDoRdgRAWVljXmcxiLdn6CqAPARmOg2Q9Dabqi2RoTabWcbrd/ujJaPNJvC5OOAdqnJM1RRMtbpGw==; 24:yh0c8K2cA6EnQ6hpj5eBJZp8q/b2i4MPKfkdvv/Yhf0mUeqOcVTUMzB8zEqgaBXGaxo6BS7cHXvdNvnwKz+SQLNTpl42Zyj3QGcCW63iZGY=; 20:EzfAvMANQrqnmZ4t+pWDlWO6vXvJfnvoV/UczncjUbo1zlbJwakUkKUMUWaI2qw2xTd9jaBJlvVAqsWkTyIzbg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(52314003)(164054003)(76104003)(505384003)(51444003)(479174004)(199003)(377454003)(53754006)(24454002)(76176999)(97736004)(19580405001)(86362001)(189998001)(19580395003)(101416001)(83506001)(87936001)(54356999)(66066001)(36756003)(11100500001)(4001350100001)(122556002)(2501003)(40100003)(99286002)(81156007)(64706001)(106116001)(107886002)(10400500002)(5001960100002)(5004730100002)(50986999)(102836002)(106356001)(2900100001)(105586002)(2950100001)(92566002)(15975445007)(5008740100001)(46102003)(93886004)(5002640100001)(5007970100001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 22:11:20.0712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 22:11:27 -0000

Hi Robert,=20

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton"  wrote:

>Hi All,
>
>Are there any more comments on the following proposed descriptions, or
>are these descriptions sufficiently clear to update the requirements
>draft and resolve issue #6?
>
>Synchronous configuration operation - A configuration request to update
>the running configuration of a server that is applied synchronously with
>respect to the client request.  The server MUST fully effect the
>configuration change to all impacted components in the server, updating
>both the server's intended and applied configuration (see terms), before
>replying to the client.  The reply to the client indicates whether there
>are any errors in the request or errors from applying the configuration
>change.
>
>Asynchronous configuration operation - A configuration request to update
>the running configuration of a server that is applied asynchronously
>with respect to the client request.  The server MUST update its intended
>configuration (see term) before replying to the client indicating
>whether the request will be processed.  The server's applied
>configuration state (see term) is updated after the configuration change
>has been fully effected to all impacted components in the server.  The
>reply to the client only indicates whether there are any errors in the
>original request.
>
>Synchronous configuration server - a configuration server that processes
>all configuration operations as synchronous configuration operations.
>
>Asynchronous configuration server - a configuration server that processes
>all configuration operations as asynchronous configuration operations.
>
>Thanks,
>Rob
>
>
>On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
>> On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
>>> Hi Juergen,
>>>
>>> On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
>>>> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
>>>>> Hi Kent,
>>>>>
>>>>> Feeding in the various input, I think that this is the best
>>>>>refinement
>>>>> that I've come up with:
>>>>>
>>>>> Synchronous configuration operation - A configuration request to
>>>>>update
>>>>> the running configuration of a server that is applied synchronously
>>>>>with
>>>>> respect to the client request.  The server SHOULD ensure that the
>>>>> request is valid, and MUST fully effect the configuration change to
>>>>>all
>>>>> impacted components in the server, updating both the server's
>>>>>intended
>>>>> and applied configuration (see terms), before replying to the client.
>>>>> The reply to the client indicates whether there are any errors in the
>>>>> request or errors from applying the configuration change.
>>>> What does "SHOULD ensure that the request is valid" mean? RFC 6020
>>>> says:
>>>>
>>>>     When datastore processing is complete, the final contents MUST
>>>>obey
>>>>     all validation constraints.  This validation processing is
>>>>performed
>>>>     at differing times according to the datastore.  If the datastore
>>>>is
>>>>      or , these constraints MUST be enforced at
>>>>the
>>>>     end of the  or  operation.  If the
>>>>     datastore is , the constraint enforcement is delayed
>>>>     until a  or  operation.
>>>>
>>>> Are we talking about datastore validation or validation of a request?
>>>> If the former, are we watering down a MUST to a SHOULD?
>>> Really it is datastore validation, particularly for an async request
>>> where the intended config nodes are updated before replying. I'm not
>>> intentionally trying to water down a MUST to a SHOULD, but Kent had
>>> concerns that my previous description using "semantically validate"
>>> would exclude an ephemeral datastore, so I was trying to water down the
>>> description and also describe the behaviour in a way that isn't
>>>specific
>>> to either RESTCONF/NETCONF or datastores.
>>>
>>> Perhaps, the start of sentence could simply be changed to:
>>>
>>> The server MUST fully effect the configuration change to all
>>> impacted components in the server ...
>>>
>>> And equivalently for the asynchronous case below:
>>>
>>> The server MUST update the server's intended configuration ...
>>>
>> Works for me. Sometimes less is more.
>>
>>>> And I would not be surprised if we also need this sooner or later:
>>>>
>>>>    Mixed configuration server - a configuration server that processes
>>>>    some configuration operations as synchronous configuration
>>>>    operations and some configuration operations as asynchronous
>>>>    configuration operations.
>>> Yes, I would expect that clients may want to define the expected
>>> behaviour, potentially on a per request basis.
>> I doubt that servers will offer clients to choose; I am more with Andy
>> that in real systems, depending on the data model, certain parts of a
>> data model may be synchronous while others may be asynchronous.
>>
>>>>> Any further comments?
>>>>>
>>>>> Based on the feedback from Andy and others, it seems that the
>>>>>prevailing
>>>>> view is that existing NETCONF and RESTCONF should be regarded as
>>>>>being
>>>>> asynchronous in their behaviour in that the config nodes in the
>>>>>running
>>>>> datastore only represent the intended configuration and not the
>>>>>applied
>>>>> configuration.
>>>> Depends on the definition of applied configuration - where is the
>>>>latest
>>>> version of it?
>>> The last proposed text for intended/applied is as below:
>>>
>>>        intended configuration - this data represents the configuration
>>>        state that the network operator intends the system to be in, and
>>> that
>>>        has been accepted by the system as valid configuration.  This
>>> data is
>>>        colloquially referred to as the 'configuration' of the system.
>>>
>>>       applied configuration - this data represents the configuration
>>>        state that the network element is actually in, i.e., the
>>>        configuration state which is currently being being used by
>>>system
>>>        components (e.g., control plane daemons, operating system
>>>        kernels, line cards).
>> Well, sometimes the config goes to a control plane daemon and then to
>> the OS kernel and finally to the line cards. This definition leaves
>> some room what an applied configuration is (which is IMHO needed if
>> you want to have something implementable) and hence a NC server can
>> either be considered synchronous or asynchronous.
>>
>>>  From Thursday's interim meeting, Rob Shakir clarified that the desired
>>> intention is that applied configuration should mean that the
>>> configuration is fully applied everywhere.  I don't know if that means
>>> that the definition of applied configuration should be strengthened, or
>>> if it is sufficient?
>> As said before, an OS kernel usually does not track where resource
>> parameters were coming from. (An interface has a set of IP addresses
>> and the kernel usually does not know which addresses were coming from
>> a configuration daemon, a dhcp daemon, a tunneling daemon, a command
>> line utility, ...) The same may be true for line card. So in order to
>> implement a very tight definition, one has to either 'guess' which
>> 'subset' of operational state can be related 'somehow' to the intended
>> config and then report the result of the guess work as applied config
>> or one would have to to change daemons/kernels/linecards to have a
>> tracking number or something like that.
>>
>> Anyway, as long as a regular NC/RC server does not have to pay a price
>> for this applied config idea, I have no real problem with this since I
>> am sure the market will sort this out.
>>
>> /js
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 14 15:28:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874C61B2A1C for ; Wed, 14 Oct 2015 15:27:53 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGKvUy4rTbzK for ; Wed, 14 Oct 2015 15:27:52 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59051B2A19 for ; Wed, 14 Oct 2015 15:27:48 -0700 (PDT)
Received: by lfaz124 with SMTP id z124so19434572lfa.1 for ; Wed, 14 Oct 2015 15:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yfCOcatLM9p/HD69ggXAXXAUmT8Z3AT2wro+/YhWzl0=; b=dniahHUXHd4bSB/JVUGqT3R807NxwjxufkiwtgwVod7SeRElH1PHXILIKFxRVQNRi1 mQOz9NUy/BoWG/ft2/G8/A2AYO/NQf0f2ESnd+2Y6CmiO+L5d/tZlMS9/xsrT6K18E9R LMEPmA2qwvSkWIJhKcR/ajvvgnkBaKxcR1UeyIMsMSNsD2FuxMe6nWQQB6SWFFVL17X8 NPWnpHdc9oQ9UuWco7Z6Q0q+lkZV+zAtRHYGwPLUJUP1cAu99LlU3RtRaoURXz4P9oZJ AufUIrM5tEsgmCuFZND5vuJfswH0LAF7MS4qykSGiydN5pEqh3RSCsemWy4lPVl0rouk zeuw==
MIME-Version: 1.0
X-Received: by 10.25.83.82 with SMTP id h79mr1881521lfb.89.1444861666812; Wed, 14 Oct 2015 15:27:46 -0700 (PDT)
Sender: william.lupton@gmail.com
Received: by 10.113.4.133 with HTTP; Wed, 14 Oct 2015 15:27:46 -0700 (PDT)
In-Reply-To: <20151014.214145.1464628339304882836.mbj@tail-f.com>
References:  <20151014.214145.1464628339304882836.mbj@tail-f.com>
Date: Wed, 14 Oct 2015 23:27:46 +0100
X-Google-Sender-Auth: PW-s6NRv9wHYP_pa3bTurnOGJEs
Message-ID: 
From: William Lupton 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a114067f466692d0522181201
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] not a non-presence container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 22:27:53 -0000

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

Thanks. I see now. As you will have realised, I parsed "not a non-presence
container" as "(not a non-presence) container" (WRONG) rather than "not a
(non-presence container)" (RIGHT). Cheers, W.

On 14 October 2015 at 20:41, Martin Bjorklund  wrote:

> William Lupton  wrote:
> > All,
> >
> > Both RFC 6020 and the bis draft use the term "not a non-presence
> > container", sometimes with a reference to section 7.5.1.
> >
> > Does this term mean the same as "presence container"?
>
> No.  A list (for example) is not a non-presence container.
>
> > If so, I think it
> > would be easier (on the reader!) to say that instead. If not, I think
> that
> > the term warrants a mention in section 7.5.1.
>
> The term is "non-presence container", and it is explained in 7.5.1.
>
>
> /martin
>

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


Thanks. I see now. As you will have realised, I parsed &qu=
ot;not a non-presence container" as "(not a non-presence) contain=
er" (WRONG) rather than "not a (non-presence container)" (RI=
GHT). Cheers, W.

On 14 October 2015 at 20:41, Martin Bjorklund <mbj@tail-f.com> wrote:
William Lupt=
on <wfl@cantab.net> wrote:

> All,

>

> Both RFC 6020 and the bis draft use the term "not a non-presence<=
br>
> container", sometimes with a reference to section 7.5.1.

>

> Does this term mean the same as "presence container"?



No.=C2=A0 A list (for example) is not a non-presence container.



> If so, I think it

> would be easier (on the reader!) to say that instead. If not, I think =
that

> the term warrants a mention in section 7.5.1.



The term is "non-presence container", and it is explained =
in 7.5.1.





/martin





--001a114067f466692d0522181201--


From nobody Wed Oct 14 16:52:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2FE1A8AF4 for ; Wed, 14 Oct 2015 16:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Heit7-qXDYAk for ; Wed, 14 Oct 2015 16:52:20 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF311A90AC for ; Wed, 14 Oct 2015 16:51:56 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.300.14; Wed, 14 Oct 2015 23:51:34 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 23:51:34 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgA==
Date: Wed, 14 Oct 2015 23:51:34 +0000
Message-ID: 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local>
In-Reply-To: <20150928084013.GB95620@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:rEQ4VklrtLSqzp/b6gE9OyWVWqGc0cE1RP4YhgqNS5gaiRzKTl+uSztbtx+G2IGpZLx8TYQtmeIdwkcT9AXezRVaMTFSTuyQBEY9m1QCoSENMQcm/jwVVgua7V9rDg2aGvqaSdSQnJbwxnE4xlJVzw==; 24:LW4EcW3SOZkOQ7Wg4Bz8sK9grJx1hI9M17bB8lw+THaUKdbTysVewrSJns0N+uc/2NkghYQkgARGIxcHAie549oZt12m+1CcxG1tlJmT/8k=; 20:btypKEpri88/Zi4TgXOvjYjHubAMmcuZpyZzJ9bPPSjXXaR7k6rk+hT+4vUKRiNiyyLuDLyAYr33XmS/V3n1lQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(51444003)(24454002)(377454003)(479174004)(199003)(189002)(66066001)(36756003)(19580395003)(10400500002)(106356001)(19580405001)(99286002)(46102003)(105586002)(106116001)(83506001)(64706001)(54356999)(101416001)(86362001)(97736004)(81156007)(189998001)(87936001)(93886004)(5002640100001)(110136002)(102836002)(5008740100001)(92566002)(5001920100001)(40100003)(2950100001)(5007970100001)(5001960100002)(5004730100002)(122556002)(50986999)(4001350100001)(2900100001)(76176999)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E35401E6867334797B5E40B99820C63@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 23:51:34.2007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Oct 2015 23:52:22 -0000

On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
 wrote:

>On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
>>=20
>> Popping the stack on this issue, the issue remains as to what to do
>>with requirement 3:
>>=20
>>    3.  Support for both transactional, synchronous management systems
>>         as well as distributed, asynchronous management systems
>>
>
>I fail to understand 'transactional' and 'distributed' here.

I hope that these terms will be clarified on tomorrow's call.   There is
also a chance that these terms will be removed from the text altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.


> And
>frankly, I am not sure why the management _systems_ are classified to
>be synchronous or asynchronous - I think we are talking about
>protocols between a management system and a device.


Aye, I didn't see that before.

First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server).  The term "system" is otherwise
not defined.

But to your main point, we have been discussing the terms a/synchronous to
have to do with internal server processing of an edit request, but in '3'
the terms are being used to qualify a management system, which can't be
right.  I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.



>Anyway, I am not sure 3. is properly worded until someone defines
>'transactional', 'distributed', 'synchronous management systems' and
>'asynchronous management systems'.

The agenda for tomorrow's interim!  :)


Kent


From nobody Wed Oct 14 17:01:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C1B1A9061 for ; Wed, 14 Oct 2015 17:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leoJuUturHBI for ; Wed, 14 Oct 2015 17:01:36 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B410B1A9047 for ; Wed, 14 Oct 2015 17:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444867196; bh=WC5pIwKJCksV4E2Jjs9iZ8OvibClfFB7nV3Y8EJ3QRE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=T49T0wh1n3TJrhfmk+K72lc/KRbbIzPwjfBG/ONapCvQnRJl6m4mjHWTvPl42kC4h boYTQUS0FMisQOZqEcbVIyhuxkvGy4vR/JIzLnEi3VSwW26sc7VjBqTXXWTHdiZ/ku DgSNilIWZqMOz+g2zs+ZVD2lc1w64NqQUH3UNTkI=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Wed, 14 Oct 2015 20:00:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com>
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local> 
To: Kent Watsen 
X-Mailer: Apple Mail (2.3094)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=27 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 153, in=2077, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 00:01:38 -0000

> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen  =
wrote:
>=20
>=20
>=20
> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
>  wrote:
>=20
>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
>>>=20
>>> Popping the stack on this issue, the issue remains as to what to do
>>> with requirement 3:
>>>=20
>>>   3.  Support for both transactional, synchronous management systems
>>>        as well as distributed, asynchronous management systems
>>>=20
>>=20
>> I fail to understand 'transactional' and 'distributed' here.
>=20
> I hope that these terms will be clarified on tomorrow's call.   There =
is
> also a chance that these terms will be removed from the text =
altogether,
> as they may be viewed as unnecessarily qualify the
> synchronous/asynchronous terms.
>=20
>=20
>> And
>> frankly, I am not sure why the management _systems_ are classified to
>> be synchronous or asynchronous - I think we are talking about
>> protocols between a management system and a device.
>=20
>=20
> Aye, I didn't see that before.
>=20
> First off, elsewhere in the draft the term "system" is used 7 times to
> refer to the device (e.g., NC/RC server).  The term "system" is =
otherwise
> not defined.
>=20
> But to your main point, we have been discussing the terms =
a/synchronous to
> have to do with internal server processing of an edit request, but in =
'3'
> the terms are being used to qualify a management system, which can't =
be
> right.  I think that '3' should be rewritten to be a statement about
> devices, not a statement about management systems.

	It might be better to frame this in terms of a client and a
server.

	=E2=80=94Tom


> Anyway, I am not sure 3. is properly worded until someone defines
>> 'transactional', 'distributed', 'synchronous management systems' and
>> 'asynchronous management systems'.
>=20
> The agenda for tomorrow's interim!  :)
>=20
>=20
> Kent
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 14 23:04:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99F1B30B0 for ; Wed, 14 Oct 2015 23:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pntia8QnDWx0 for ; Wed, 14 Oct 2015 23:04:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC85F1B30AF for ; Wed, 14 Oct 2015 23:04:30 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id F0F2F1CC0183; Thu, 15 Oct 2015 08:04:33 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <20151013080254.GA65823@elstar.local>
References: <20151013080254.GA65823@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 15 Oct 2015 08:04:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9.	built-in types)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 06:04:33 -0000

Juergen Schoenwaelder  writes:

> Hi,
>
> here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I
> have finish now a complete review of the document. The most important
> bug I spotted is likely that section 9.4.6 is empty.

Yes, and the "modifier" statement should also be listed in Table 1 of
sec.=C2=A013.1.

Lada

>
> /js
>
> * p126
>
>   OLD
>
>      Some types have a lexical representation that depends on the XML
>      context in which they occur.  These types do not have a canonical
>      form.
>
>   NEW
>
>      Some types have a lexical representation that depends on the
>      encoding, e.g., the XML context in which they occur.  These types
>      do not have a canonical form.
>
>   Well, it turns out that there are XML encoding specifics in several
>   of the following sections. Perhaps instead stated upfront that the
>   section 9 describes the types and they XML encoding and noting that
>   other encodings may use different rules. Perhaps also stating that
>   the canonical representation is also used for constraint evaluation
>   purposes.
>
>   OLD
>
>     When a NETCONF server sends data, it MUST be in the canonical form.
>
>   NEW
>
>     When a server sends data encoded in XML, it MUST use the canonical
>     form defined in this section. Other encodings may introduce
>     alternate representations. Note, however, that values in the data
>     tree are conceptually stored in the canonical representation as
>     defined in this section. In particular, any XPath expression
>     evaluations are done using the canonical form.
>
> * p127
>
>   s/XML instance documents/XML encoding/
>
> * p131
>
>   s/XML instance documents/XML encoding/
>
> * p132
>
>   The section 9.4.6 (modifier statement) is empty and needs to be
>   filled in.
>
> * p137
>
>   Y25-02 says:
>
>       Keep the auto-numbering procedure for enums and bits and add an
>       explicit warning that inserting enum or bits definitions or
>       reordering enum or bits definitions violates section 10 and causes
>       interoperability problems unless explicit value assignments are
>       used.
>
>   Has this been implemented? I did not find such a statement.
>
> * p139
>
>   s/A binary can/A binary type can/
>
> * p139
>
>   s/are encoded/are encoded in XML/
>
> * p141
>
>   s/is encoded/is encoded in XML/
>
> * p146
>
>   s/is encoded/is encoded in XML/
>
> * p148
>
>   The text stating that a value is consecutively against each member
>   type does not seem to be 100% true for the JSON mapping since JSON
>   says the JSON type information is taken into account. So we either
>   change the JSON specification or we rewrite this text in RFC 6020 to
>   allow different member type selection styles by making this
>   statement specific to the XML encoding:
>
>      In the XML encoding, the value representing a union data type...
>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Oct 15 00:02:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13571A88BC for ; Thu, 15 Oct 2015 00:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_F9vNaY0wZM for ; Thu, 15 Oct 2015 00:02:48 -0700 (PDT)
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 7008E1A6FF6 for ; Thu, 15 Oct 2015 00:02:48 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:4595:7241:573a:b276] (unknown [IPv6:2001:718:1a02:1:4595:7241:573a:b276]) by mail.nic.cz (Postfix) with ESMTPSA id E02D71818DF; Thu, 15 Oct 2015 09:02:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444892566; bh=DAhOxET67h1LSyOHX6bMYATJGk6sopl8HfuylBBdVno=; h=From:Date:To; b=Ap9KVXI90F9q8aLGS8eSxN9Koj9AeHK/MJBKCPZWkrM53FMuylceOjTlPUkmZdzyD hLVBIY5IEMXieqkJ6v6V1qwA3ywucgQ2aFmVYRkrUk0mjFxXbqcHjCcaDspa0tUNtX rgLv0EWmICtnfquqyZSVx7ZepTk4amGQiYSp9TZw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151014.192857.1892050522806470333.mbj@tail-f.com>
Date: Thu, 15 Oct 2015 09:02:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B6AB764-E1A5-49AE-9212-011D46ACE071@nic.cz>
References:  <20151014.192857.1892050522806470333.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] 6020bis - sec. 5.6.4 comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 07:02:50 -0000

> On 14 Oct 2015, at 19:28, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> regarding $subj:
>>=20
>> - What about extensions? Do modules defining them have to be
>>  implemented? That is, is "default-revision" true or false for such
>>  modules?
>=20
> The "default-revision" leaf doesn't exist in ietf-yang-libary.  I will
> remove the note about aligning with ietf-yang-libary, and do:
>=20
> OLD:
>=20
>   If a server implements a module A that imports a module C without
>   specifying the revision date of module C, and the server does not
>   implement C (e.g., if C only defines some typedefs), the server
>   MUST list module C in the "/modules/module" list from
>   "ietf-yang-library", and it MUST set the leaf "default-revision" to
>   "true" for this module.
>=20
> NEW:
>=20
>   If a server implements a module A that imports a module C without
>   specifying the revision date of module C, and the server does not
>   implement C (e.g., if C only defines some typedefs), the server
>   MUST list module C in the "/modules/module" list from
>   "ietf-yang-library", and it MUST set the leaf "conformance" to
>   "import" for this module.

OK, and what about extensions? If a server supports an extension and it =
is defined in module X, what's the "conformance" value for X in =
yang-library: "import" or "implement"? Extensions aren't mentioned in =
the first paragraph of 5.6.4.

>=20
>=20
>> - Third paragraph:
>>=20
>> OLD
>>=20
>>   This is regardless of if module B is imported by revision or not.
>>=20
>> NEW
>>=20
>>   If module B is imported by revision, the corresponding =
"revision-date"
>>   statement is ignored.
>=20
> I think your proposed text can be misunderstood.  The "revision-date"
> statement is not ignored; typedefs etc. will be taken from the
> specified revision.

OK.

It seems this paragraph doesn't cover this case:

augment "/B:foo" {
    when "B:bar =3D 1";
    ...
}

What if module B implements "foo" but not "bar"? One option is to add =
"when" to "augment" and "path", and another is to consider the "when" =
expression to be false so that the augment doesn't apply in this case.

Lada=20

>=20
>=20
>=20
> /martin

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





From nobody Thu Oct 15 00:04:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1F91A88F7 for ; Thu, 15 Oct 2015 00:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level: 
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_BOTCC=2.5] 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 xC5VkOkkHNdU for ; Thu, 15 Oct 2015 00:04:09 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A05A1A88DA for ; Thu, 15 Oct 2015 00:04:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EF7C172D; Thu, 15 Oct 2015 09:04:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FBoqConsooYr; Thu, 15 Oct 2015 09:04:03 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Oct 2015 09:03:56 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E994920069; Thu, 15 Oct 2015 09:03:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1HHMaBrrJ1UF; Thu, 15 Oct 2015 09:03:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93DF520054; Thu, 15 Oct 2015 09:03:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 69F8A37B3E72; Thu, 15 Oct 2015 09:03:30 +0200 (CEST)
Date: Thu, 15 Oct 2015 09:03:30 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151015070330.GC70280@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
References:  <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> <20151013192337.GC67325@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 07:04:11 -0000

On Wed, Oct 14, 2015 at 04:01:13PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder  wrote:
> >> > 
> >> > On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote:
> >> >> 
> >> >> This is a notice to start a NETMOD WG last call for the document:
> >> >> 
> >> >> Defining and Using Metadata with YANG
> >> >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
> >> >> 
> >> >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT.
> >> >> We are not only interested in receiving defect reports, we are equally
> >> >> interested in statements of the form:
> >> >> 
> >> > 
> >> > I am concerned about this text:
> >> > 
> >> >   Annotations modify the schema of datastores and/or management
> >> >   protocol messages, and may also change their semantics.  Therefore,
> >> >   due care has to be exercised when introducing annotations in
> >> >   network management systems in order to avoid interoperability
> >> >   problems and software failures.
> >> > 
> >> > I think we should actually very clearly discourage annotations that
> >> > modify the schema of datastores and/or management protocol messages
> >> > instead of assuming all annotations are free to do so.
> >> 
> >> Annotations modify the schemas by definition because otherwise XML attributes, and objects in JSON encoding whose names start with "@", are not allowed.
> >>
> >
> > For me, the schema of a datastore is the YANG data model. I do not
> > want annotations that change the YANG data model of a datastore.
> > Perhaps you mean something different but then the text allows multiple
> > interpretations and hence it is problematic.
> 
> It depends on the definition of "schema". In any case, annotations add
> some extra information that possibly might be persistent. FWIW, a RELAX
> NG schema generated for datastore + annotation is different from the one
> that's for datastore only.

Then this usage of "schema" needs to be clarified. The text in
question does not say it is specific to RELAX NG schema. It can be
read as "annotations modify the YANG data models and/or
NETCONF/RESTCONF protocol messages". I do not want to legalize
annotations that turn data model properties upside down.

> > Annotations should add metadata but I think metadata must not change
> > the semantics of the data model itself. I am also concerned if
> > metadata changes the semantics of protocol messages. I am not
> 
> Some annotations that are of this sort, such as "inactive", have already
> been discussed. The text you cited tries to explain possible pitfalls of
> such annotations, but my understanding of the consensus so far has been
> that it is not desirable to limit annotations to "benign" ones.

I am fine with the bullets, my concern is about the paragraph above
it. For me, there are different classes of annotations

- easy annotations that only add metadata (like the 'last-modified'
  example) and which are harmless (since they can be simply ignored)

- risky annotations that impact the interpretation of data (such as an
  'inactive' annotation) and which require that systems agree that
  they understand the semantics of the annotations before they can be
  used safely

- evil annotations that are trying to overwrite essential data model
  properties (e.g. a 'key' annotation that redefines the key property
  of a list or a 'type' annotation that overwrites the type of leafs
  or a 'config' annotation that redefines the config true/false
  property on the fly)

Yes, the boundary between these classes is fuzzy. I am concerned that
a statement like

   Annotations modify the schema of datastores and/or management
   protocol messages, and may also change their semantics.

paves the way to encourage not only risky but also evil annotations.
People might point to this statement and say that evil annotations
are just fine.

> I guess the considerations are similar to extensions in general:
> certain annotations may be a mandatory part of a protocol but is has
> to be said in the protocol spec. This is essentially what was done for
> NETCONF, and a special extension was used for defining the annotations
> (XML attributes).

NETCONF is a special case since NETCONF was designed before we had
YANG and the WG retrofitted a YANG data model to describe it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Oct 15 00:06:34 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9706B1A6FEA for ; Thu, 15 Oct 2015 00:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZoxpMBkCTuY for ; Thu, 15 Oct 2015 00:06:31 -0700 (PDT)
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 330AC1A6FF7 for ; Thu, 15 Oct 2015 00:06:31 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:4595:7241:573a:b276] (unknown [IPv6:2001:718:1a02:1:4595:7241:573a:b276]) by mail.nic.cz (Postfix) with ESMTPSA id 4036B1818B5; Thu, 15 Oct 2015 09:06:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444892789; bh=yMCBCtGsYmDqYP6Dma7Nk169LKTZ8+hCmV2YKJYQ/oQ=; h=From:Date:To; b=ZSS8O7FFUF7IVaClrdZYtAWA5wr2bd34V6PNRmBkUqJOD3v25reVJfGZsVpGP2LLC Wzys4/Gmh/hxpy8uBvkDfSxuO2PBrDCk+dz5VNHvtiLFIfixTkRDPF+wFaSJflXad7 697mfepy7z/pf6hyuIelVrB/ldEFBvNwxmOGVBls=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151014.204354.1484545235629559894.mbj@tail-f.com>
Date: Thu, 15 Oct 2015 09:06:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <35FB22BA-29B8-4088-A255-3A6987E47060@nic.cz>
References: <0CE090CB-388D-4A97-976A-4132F4F462F9@nic.cz> <20151014.204354.1484545235629559894.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] nested choices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 07:06:32 -0000

> On 14 Oct 2015, at 20:43, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> my action item from yesterday's interim was to check whether some =
updates to 6020bis are needed in order to address the corner cases =
presented by Balazs:
>>=20
>> - =
https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk
>> - =
https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk
>>=20
>> I would propose this minor change to sec. 7.9.3:
>>=20
>> OLD
>>=20
>>   The default case is only important when considering the default
>>   values of nodes under the cases.
>>=20
>> NEW
>>=20
>>   The default case is only important when considering the default
>>   contents of nodes under the cases (default values of leafs and
>>   leaf-lists, or default cases of nested choices).
>=20
> Maybe a slight variation, and taking the entire paragraph into
> account:
>=20
> OLD:
>=20
>  The default case is only important when considering the default
>  values of nodes under the cases.  The default values for nodes under
>  the default case are used if none of the nodes under any of the
>  cases are present.
>=20
> NEW:
>=20
>  The default case is only important when considering the default
>  statements of node under the cases (i.e., default values of leafs and
>  leaf-lists, and default cases of nested choices).  The default
>  values and nested default cases under the default case are used
>  if none of the nodes under any of the cases are present.


OK, just s/node/nodes/ in the second line.

Lada
>=20
>=20
>=20
> /martin

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





From nobody Thu Oct 15 00:52:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033341A1B69 for ; Thu, 15 Oct 2015 00:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.139
X-Spam-Level: **
X-Spam-Status: No, score=2.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_BOTCC=2.5] 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 aqoUtPoB_Iu5 for ; Thu, 15 Oct 2015 00:52:01 -0700 (PDT)
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 08C981A039C for ; Thu, 15 Oct 2015 00:52:01 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:4595:7241:573a:b276] (unknown [IPv6:2001:718:1a02:1:4595:7241:573a:b276]) by mail.nic.cz (Postfix) with ESMTPSA id 9DD6318188B; Thu, 15 Oct 2015 09:51:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444895519; bh=1YglA1NS2ha4cNemvKC35tHS3rH9ZfztiPFDMId8Tqs=; h=From:Date:To; b=p0a8f9qvldf6jEa072Lu8cEcjcG0kH2/x0hZi8cXB5nX0Q+ochBwr55fYc3G/Qr8h 8TFl9LQy51lZ4l4MIHc41SUJaOwrMUOZkTDQeqCGx4oor+xlJYP67TQKl05g5Dajwj XOKnj2hj7cH6zl4q6bSgky+J5mEHuPHGGnqlcKNc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151015070330.GC70280@elstar.local>
Date: Thu, 15 Oct 2015 09:52:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <415D4893-F9BB-445B-A4FB-1A77CEDF642F@nic.cz>
References:  <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> <20151013192337.GC67325@elstar.local>  <20151015070330.GC70280@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 07:52:04 -0000

> On 15 Oct 2015, at 09:03, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Oct 14, 2015 at 04:01:13PM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>=20
>>> On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>>> On 13 Oct 2015, at 13:01, Juergen Schoenwaelder =
 wrote:
>>>>>=20
>>>>> On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote:
>>>>>>=20
>>>>>> This is a notice to start a NETMOD WG last call for the document:
>>>>>>=20
>>>>>> Defining and Using Metadata with YANG
>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
>>>>>>=20
>>>>>> Please indicate your support by Thursday October 22, 2015 at 9PM =
EDT.
>>>>>> We are not only interested in receiving defect reports, we are =
equally
>>>>>> interested in statements of the form:
>>>>>>=20
>>>>>=20
>>>>> I am concerned about this text:
>>>>>=20
>>>>>  Annotations modify the schema of datastores and/or management
>>>>>  protocol messages, and may also change their semantics.  =
Therefore,
>>>>>  due care has to be exercised when introducing annotations in
>>>>>  network management systems in order to avoid interoperability
>>>>>  problems and software failures.
>>>>>=20
>>>>> I think we should actually very clearly discourage annotations =
that
>>>>> modify the schema of datastores and/or management protocol =
messages
>>>>> instead of assuming all annotations are free to do so.
>>>>=20
>>>> Annotations modify the schemas by definition because otherwise XML =
attributes, and objects in JSON encoding whose names start with "@", are =
not allowed.
>>>>=20
>>>=20
>>> For me, the schema of a datastore is the YANG data model. I do not
>>> want annotations that change the YANG data model of a datastore.
>>> Perhaps you mean something different but then the text allows =
multiple
>>> interpretations and hence it is problematic.
>>=20
>> It depends on the definition of "schema". In any case, annotations =
add
>> some extra information that possibly might be persistent. FWIW, a =
RELAX
>> NG schema generated for datastore + annotation is different from the =
one
>> that's for datastore only.
>=20
> Then this usage of "schema" needs to be clarified. The text in
> question does not say it is specific to RELAX NG schema. It can be
> read as "annotations modify the YANG data models and/or
> NETCONF/RESTCONF protocol messages". I do not want to legalize
> annotations that turn data model properties upside down.

Annotations may not turn data model properties upside down but in any =
case they add stuff that the peer may not be prepared to handle. If the =
NETCONF client doesn't expect XML attributes in the data part of a =
 reply, then it might break if the server uses them. That's =
what I meant by "schema changes" and this problem is relevant for all =
uses of annotations, regardless of their semantics.

>=20
>>> Annotations should add metadata but I think metadata must not change
>>> the semantics of the data model itself. I am also concerned if
>>> metadata changes the semantics of protocol messages. I am not
>>=20
>> Some annotations that are of this sort, such as "inactive", have =
already
>> been discussed. The text you cited tries to explain possible pitfalls =
of
>> such annotations, but my understanding of the consensus so far has =
been
>> that it is not desirable to limit annotations to "benign" ones.
>=20
> I am fine with the bullets, my concern is about the paragraph above
> it. For me, there are different classes of annotations
>=20
> - easy annotations that only add metadata (like the 'last-modified'
>  example) and which are harmless (since they can be simply ignored)
>=20
> - risky annotations that impact the interpretation of data (such as an
>  'inactive' annotation) and which require that systems agree that
>  they understand the semantics of the annotations before they can be
>  used safely
>=20
> - evil annotations that are trying to overwrite essential data model
>  properties (e.g. a 'key' annotation that redefines the key property
>  of a list or a 'type' annotation that overwrites the type of leafs
>  or a 'config' annotation that redefines the config true/false
>  property on the fly)
>=20
> Yes, the boundary between these classes is fuzzy. I am concerned that

Yes, and the boundary may also depend on the presence of external =
information such as protocol specification.

> a statement like
>=20
>   Annotations modify the schema of datastores and/or management
>   protocol messages, and may also change their semantics.


The "schema" part addresses syntactic changes in protocol messages, =
which are inevitable, and the second part is about risky annotations. I =
agree evil annotations should be banned but I am not sure we can find a =
satisfactory formulation. Do you have any suggestion?

>=20
> paves the way to encourage not only risky but also evil annotations.
> People might point to this statement and say that evil annotations
> are just fine.
>=20
>> I guess the considerations are similar to extensions in general:
>> certain annotations may be a mandatory part of a protocol but is has
>> to be said in the protocol spec. This is essentially what was done =
for
>> NETCONF, and a special extension was used for defining the =
annotations
>> (XML attributes).
>=20
> NETCONF is a special case since NETCONF was designed before we had
> YANG and the WG retrofitted a YANG data model to describe it.

My point here is that XML attributes defined through =
"get-filter-element-attribute" extension are absolutely safe in the =
NETCONF context because they are also addressed in the protocol spec. On =
the other hand, attributes with similar semantics defined through a YANG =
extension (without being supported in RFC 6241) would most likely be =
evil.

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Thu Oct 15 01:00:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C761E1A88C5 for ; Thu, 15 Oct 2015 01:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Level: 
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBWArz4ljtDx for ; Thu, 15 Oct 2015 01:00:44 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9D11A88BE for ; Thu, 15 Oct 2015 01:00:43 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-1a-561f5d2a78f8
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.FC.27359.A2D5F165; Thu, 15 Oct 2015 10:00:42 +0200 (CEST)
Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 10:00:40 +0200
To: Andy Bierman , Martin Bjorklund 
References:  <20151014.214813.106525154933227408.mbj@tail-f.com>  <20151014.222642.365989360913160897.mbj@tail-f.com> 
From: Balazs Lengyel 
Message-ID: <561F5D28.5020304@ericsson.com>
Date: Thu, 15 Oct 2015 10:00:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvja5WrHyYQfMtQYsHR2axW3R3P2O3 mH+xkdWB2WPJkp9MHht/LWbxaOm/yBLAHMVlk5Kak1mWWqRvl8CV8WTXCcaCjxEV8/YcZmpg nG7WxcjJISFgIvGoYSkzhC0mceHeerYuRi4OIYGjjBITF29ignDWMkr8mf2WFaRKWMBY4tj6 VpYuRg4OEQEPiTVz3EBMIYFTTBJzBUEqmAXUJe6ceswGYrMJGElM7T/PAmLzCmhLXNpyixHE ZhFQlWhpnwNWIyoQI/F+0ypGiBpBiZMzn4DVcwoESsz/sZwFYqaGROucuewQtrxE89bZYDcL AcUfXvjLOoFRcBaS9llIWmYhaVnAyLyKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCAD275 bbCD8eVzx0OMAhyMSjy8Czjkw4RYE8uKK3MPMUpzsCiJ8zYzPQgVEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwGgqG29jey5h9e2P3skBe6tWpTeXBOnzduey7dH0Si/dd9pB72V52PWEnY1v njH48GgcdLCrrhSrSuxiLBUsEO86uNDILu663ucP6fO8VWR3zTPfs0w/Yt0koY/mVfnv2o71 GKxhC341KydAuDxoznKN99/Oe5Wt3sb5NXSK0o2AGpuQdjNdJZbijERDLeai4kQAks5PI0EC AAA=
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 08:00:47 -0000


  
    
  
  
    See below, Balazs

    

    
On 2015-10-14 23:06, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Oct 14, 2015 at 1:26 PM,
            Martin Bjorklund <mbj@tail-f.com> wrote:

            
Andy
              Bierman <andy@yumaworks.com>
              wrote:

              > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund
              <mbj@tail-f.com>
              wrote:

              >

              > > Andy Bierman <andy@yumaworks.com>
              wrote:

              > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin
              Bjorklund <mbj@tail-f.com>

              > > wrote:

              > > >

              > > > > Balazs Lengyel <balazs.lengyel@ericsson.com>
              wrote:

              > > > > > Hello Martin,

              > > > > > I agree that A1 is what follows
              the spirit of YANG, but then IMHO you

              > > > > > should change/correct 8.2.1 in
              YANG because that implies A2 and

              > > error.

              > > > >

              > > > > Ok, I agree.  I suggest we remove from
              8.2.1:

              > > > >

              > > > >    o  If data for a node tagged with
              "when" is present, and the "when"

              > > > >       condition evaluates to "false",
              the server MUST reply with an

              > > > >       "unknown-element" error-tag in
              the rpc-error.

              > > > >

              > > > > and add to 8.2.2:

              > > > >

              > > > >   o  Modification requests for nodes
              tagged with "when", and the "when"

              > > > >      condition evaluates to "false". 
              In this case the server MUST

              > > reply

              > > > >      with an "unknown-element"
              error-tag in the rpc-error.

              > > > >

              > > > >

              > > > >

              > > >

              > > > This seems like a BIG protocol change to
              <edit-config> behavior.

              > > > IMO this not an error at all.  In our
              server the false-when data is just

              > > > pruned, and no error is ever sent for a
              pruned when=false data node.

              > >

              > > So you are not following the current RFC 6020
              spec?

              > >

              >

              >

              > Yes we are following it.

              

              Ok.

              

              > The schema for the edit-config RPC operation contains

              > an 'anyxml' for <config> node.  It does not
              contain any

              > when-stmts for the data nodes that get passed in the
              <config> node.

              > The correct behavior is to just enforce the error on
              the when-stmts

              > that appear in the rpc-stmt.

              

              I don't understand what you are trying to say.

            

            


            

            


            

            
I know about the text that says a false-when in an RPC
              is an error.

            
Show me the when-stmts  "interface" in the
              "edit-config" rpc-stmt.

            


            

            


            

            
 

            

              

              Here's an example:

              

                augment /if:interfaces/if:interface {

                  when "if:type = 'ianaift:ethernetCsmacd'";

              

                  container ethernet {

                    leaf duplex {

                      type enumeration {

                        enum "half";

                        enum "full";

                      }

                    }

                  }

                }

              

              Suppose the db is empty.

              

              What if the edit-confif contains

              

                <interfaces>

                  <interface>

                    <name>eth0</name>

                    <eth:duplex>full</eth:duplex>

                    <type>ianaift:ethernetCsmacd</type>

                  </interface>

                </interfaces>

              

              will that work or not?  I.e., will the eth0 interface be
              created with

              duplex full?

            

            


            

            
Yes -- because these are data nodes and the rules for
              when-stmt

            
on data nodes are different than for rpc-stmt.  Then
              the when-stmt

            
is a test on whether the node should exist in the
              candidate or running

            
datastore.

            


            

            
Our server applies all the edits first, when checks all
              the when-stmts

            
that might have changed value.  Nodes that have already
              existed in the

            
datastore may get pruned, not just the new nodes.

            


            

            


            

            


            

            


            

            

              

              

              /martin

              

              

            

            


            

            


            

            
Andy

            
 

            

              

              >

              >

              >

              >

              > > I don't think this is a BIG protocol change,
              since the spec already

              > > says that requests for nodes w/ false when
              expressions MUST send

              > > error.  The change is to say that this behavior
              is true regardless of

              > > evaluation order.

              > >

              > > > It may be a client programming error for
              the client to provide

              > > > false when nodes or not.  What if the
              client is reusing some

              > > > code that sends 5 parameters, it it's OK if
              1 of them gets

              > > > pruned sometimes because of a false when
              (e.g, product

              > > > feature-specific knob and that feature is
              not installed)

              > >

              > > Well, it might be simpler to send if-featured
              nodes that the specific

              > > server doesn't support - this is also an error
              in 6020.

              > >

              > > > BTW, this is a really good example of what
              not to do, if one

              > > > wants to make the YANG specification
              protocol independent.

              > >

              > > That statement is true for the entire section
              8.2, it is not

              > > specifically true for this change.

              > >

              > >

              > > /martin

              > >

              >

              >

              > Andy

            

          

          

        

      

    

    And this contradicts the current rfc6020bis-07#section-8.2.1 which
    states that already during parsing you must check 

    
If data for a node tagged with "when" is present, and the "when"
      condition evaluates to "false", the server MUST reply with an
      "unknown-element" error-tag in the rpc-error.
 


    
So already during parsing <eth:duplex>full</eth:duplex> you MUST send back an error;
before processing <type>ianaift:ethernetCsmacd</type>. 
(I also assume this is independent from the document order of the edit-config request.)
So this MUST be corrected in the draft!
regards Balazs


    

    

     

    

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


  



From nobody Thu Oct 15 01:52:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C591A911E for ; Thu, 15 Oct 2015 01:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 o-ivdTBwIOWO for ; Thu, 15 Oct 2015 01:52:08 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan19.extendcp.co.uk [176.32.226.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6F21A8784 for ; Thu, 15 Oct 2015 01:52:08 -0700 (PDT)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan0.hi.local) by mailscan-g74.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZmeGZ-0002Nq-Tb; Thu, 15 Oct 2015 09:52:03 +0100
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan0.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZmeGY-0007pU-4O; Thu, 15 Oct 2015 09:52:03 +0100
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152] helo=[IPv6:::ffff:192.168.1.107]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1ZmeGU-0002Hr-AR; Thu, 15 Oct 2015 09:51:59 +0100
MIME-Version: 1.0
To: Robert Wilton , Kent Watsen ,  Andy Bierman 
From: Jonathan Hansford 
Date: Thu, 15 Oct 2015 09:55:01 +0100
Importance: normal
X-Priority: 3
In-Reply-To: <561EC8E7.9080708@cisco.com>
References:  <560D269E.30002@cisco.com>    <561EC8E7.9080708@cisco.com>
Content-Type: multipart/alternative; boundary="_1CC20088-B2FB-4C03-ADBD-AFCA9EEEC1D1_"
X-Authenticated-As: jonathan@hansfords.net
X-Extend-Src: mailout
Message-Id: 
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Oct 2015 08:52:12 -0000

--_1CC20088-B2FB-4C03-ADBD-AFCA9EEEC1D1_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

The NMS only knows the intended config if it is the only NMS capable of cha=
nging that device=E2=80=99s config. That may not always be the case.

Jonathan



From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl=
ied configuration"



On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing constantl=
y.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter. =C2=A0 And there have been suggestions =
for solutions to provide something like a yang-patch to describe just the d=
iffs. =C2=A0Makes sense to me!

The NMS already knows the intended config since it sent it to the device in=
 the first place, so in normal circumstances I would expect the NMS to only=
 query the applied config (and possibly derived state at the same time) and=
 then compare it to the NMS's view of the intended cfg for that device.=C2=
=A0 If the NMS is smart then it might be able to restrict most of the queri=
es to only the device's applied config sub-trees that could possibly be out=
 of sync, perhaps with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be u=
seful (the draft that I put forward also proposes a diff-cfg-only option).=
=C2=A0 However, it is also worth noting that the original requirements don'=
t explicitly ask for this, so perhaps more of a nice to have than a formal =
requirement?

Thanks,
Rob




K.


From: Andy Bierman 
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen 
Cc: Robert Wilton , "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "app=
lied configuration"



On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  wrote:

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
> =C2=A0 =C2=A0- does it include support for templating (as per openconfig-=
netmod-opstate-01 section 7.3.)?
> =C2=A0 =C2=A0- is it allowed to represent system created objects that hav=
e no corresponding configuration?
>
> Requirement 1.D states

     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.
>
> So, if this requirement statement stands as being valid (which I think it=
 should) then that would imply that the answer for both the two issues abov=
e must be "no".=C2=A0 The only question would be whether these need to be e=
xplicitly listed out?
[KENT] so I think I have to (begrudgingly) agree with your logic. =C2=A0 =
=C2=A0I have heard the operators state that they want the intended/applied =
comparison to be drop-dead simple.=C2=A0 To that end, it would not be possi=
ble to flatten templates or apply defaults, or make any other change =E2=80=
=93 it needs to be as close as possible to a carbon-copy of the original in=
tended configuration (where deviations are allowed only for cases like a mi=
ssing line-card).=C2=A0 To this end, yes, I think that we could tack on a s=
tatement like the following:

That is, the intended configuration is a subset of the applied=C2=A0
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?


I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?


Andy




>> =C2=A0- how does it relate to the state of the system after a equivalent=
 synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the propose=
d definition of synchronous configuration operation vs asynchronous configu=
ration operation, will provide a sufficient answer to this question.=C2=A0 =
I.e. that the state of the system after an asynchronous config operation mu=
st, when fully synchronized, be the same as the state of the system after a=
n equivalent synchronous configuration operation completes and replies back=
.

[KENT] I agree with this, but I think it impacts issue #6 more so than issu=
e #4 - right?


Thanks,
Kent



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





--_1CC20088-B2FB-4C03-ADBD-AFCA9EEEC1D1_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


The NMS only knows the intended config if it is the on=
ly NMS capable of changing that device=E2=80=99s config. That may not alway=
s be the case.
 
Jonathan
 
 

From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a=
 tighter definition of"applied configuration"
 
 
 
On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
>=
 I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changin=
g constantly.
> 
> Do they really want t=
his complex task or do they just want to
<=
p class=3DMsoNormal>> determine if the =
intended config has been applied yet?
 
I=
 think that it is more the latter.   And there have been suggestions f=
or solutions to provide something like a yang-patch to describe just the di=
ffs.  Makes sense to me!

The NMS already knows the intended config since it sent it to=
 the device in the first place, so in normal circumstances I would expect t=
he NMS to only query the applied config (and possibly derived state at the =
same time) and then compare it to the NMS's view of the intended cfg for th=
at device.  If the NMS is smart then it might be able to restrict most=
 of the queries to only the device's applied config sub-trees that could po=
ssibly be out of sync, perhaps with periodic full synchronization checks.
Otherwise, I think that a function that returns just the diff may als=
o be useful (the draft that I put forward also proposes a diff-cfg-only opt=
ion).  However, it is also worth noting that the original requirements=
 don't explicitly ask for this, so perhaps more of a nice to have than a fo=
rmal requirement?

Thanks,
Rob



 
<=
/div>
K.
 
 
From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 14, 201=
5 at 2:56 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstat=
e-reqs #4: Provide a tighter definition of "applied configuration"=
;
 
 
 
<=
div>
On Wed, Oct 14, 2=
015 at 11:00 AM, Kent Watsen <kwatsen@juniper.net> wrote:
 
Thank you Robert for=
 bringing the discussion back to the github issues.
 <=
/o:p>
Robert writes:
<=
span style=3D'font-size:12.0pt'> 
> In particular:<=
o:p>
>    - does it include support for templating=
 (as per openconfig-netmod-opstate-01 section 7.3.)?
<=
/div>
> &=
nbsp;  - is it allowed to represent system created objects that have n=
o corresponding configuration?
>
> Requirement 1.D states
=C2=A0=C2=A0=C2=A0=
=C2=A0 D.=C2=A0 For asynchronous systems, when fully synchronized, the data=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the a=
pplied configuration is the same as the data in the
= 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intended configuration.

>
> So, if this requirement stateme= nt stands as being valid (which I think it should) then that would imply th= at the answer for both the two issues above must be "no".  T= he only question would be whether these need to be explicitly listed out?

[KENT] so I think I have = to (begrudgingly) agree with your logic.    I have heard the oper= ators state that they want the intended/applied comparison to be drop-dead = simple.  To that end, it would not be possible to flatten templates or= apply defaults, or make any other change =E2=80=93 it needs to be as close= as possible to a carbon-copy of the original intended configuration (where= deviations are allowed only for cases like a missing line-card).  To = this end, yes, I think that we could tack on a statement like the following= :

 

That is, the intended configuration is a sub= set of the applied 

configuration where omissions are only = due to when the

configuration cannot be applied (e.g., a missing= line-card).

 

What do you think?

 

 

I am wondering why oper= ators would want to compare 2 massive subtrees

<= div>

in the first plac= e, where 1 is static and the other is changing constantly.

=  

Do they really want this complex task or do they just want to<= o:p>

determine if the intended config has been applied yet?

 

 

Andy

 

 

<= o:p> 

 

>>  - how does it relate to t= he state of the system after a equivalent synchronous config commit (if at = all)?

>>
> Again, I think that definition of require= ment 1.D, along with the proposed definition of synchronous configuration o= peration vs asynchronous configuration operation, will provide a sufficient= answer to this question.  I.e. that the state of the system after an = asynchronous config operation must, when fully synchronized, be the same as= the state of the system after an equivalent synchronous configuration oper= ation completes and replies back.

 

<= /div>

[KENT] I ag= ree with this, but I think it impacts issue #6 more so than issue #4 - righ= t?

 

<= span style=3D'font-size:12.0pt'> 

Thanks,=

Kent

 

 


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

 <= /span>

 

 

 

= --_1CC20088-B2FB-4C03-ADBD-AFCA9EEEC1D1_-- From nobody Thu Oct 15 01:54:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA591A912B for ; Thu, 15 Oct 2015 01:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-yy6IStDCLd for ; Thu, 15 Oct 2015 01:54:36 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F221A9126 for ; Thu, 15 Oct 2015 01:54:36 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan8.hi.local) by mailscan-g68.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZmeIz-0008IB-NH; Thu, 15 Oct 2015 09:54:33 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan8.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZmeIy-0003Hf-Ga; Thu, 15 Oct 2015 09:54:32 +0100 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152] helo=[IPv6:::ffff:192.168.1.107]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1ZmeIx-0007c7-I2; Thu, 15 Oct 2015 09:54:32 +0100 MIME-Version: 1.0 To: William Lupton , Martin Bjorklund From: Jonathan Hansford Date: Thu, 15 Oct 2015 09:57:34 +0100 Importance: normal X-Priority: 3 In-Reply-To: References: <20151014.214145.1464628339304882836.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="_9F7B333F-AA15-4E74-A164-4CDAA830DC3E_" X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Message-Id: Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] not a non-presence container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 08:54:38 -0000 --_9F7B333F-AA15-4E74-A164-4CDAA830DC3E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If that misinterpretation has already happened for (at least) one individua= l, would it be worth adding the clarification and remove the ambiguity? Jonathan From: William Lupton Sent: 14 October 2015 23:28 To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] not a non-presence container Thanks. I see now. As you will have realised, I parsed "not a non-presence = container" as "(not a non-presence) container" (WRONG) rather than "not a (= non-presence container)" (RIGHT). Cheers, W. On 14 October 2015 at 20:41, Martin Bjorklund wrote: William Lupton wrote: > All, > > Both RFC 6020 and the bis draft use the term "not a non-presence > container", sometimes with a reference to section 7.5.1. > > Does this term mean the same as "presence container"? No.=C2=A0 A list (for example) is not a non-presence container. > If so, I think it > would be easier (on the reader!) to say that instead. If not, I think tha= t > the term warrants a mention in section 7.5.1. The term is "non-presence container", and it is explained in 7.5.1. /martin --_9F7B333F-AA15-4E74-A164-4CDAA830DC3E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

If that misinterpretation has already happened for (at= least) one individual, would it be worth adding the clarification and remo= ve the ambiguity?

 

Jonathan

 <= /o:p>

 


From: William Lupton
Sent:= 14 October 2015 23:28
To: Martin Bjorklund
Cc: net= mod@ietf.org
Subject: Re: [netmod] not a non-presence container

 

 

Thanks. I see now. As you will have realised, I parsed= "not a non-presence container" as "(not a non-presence) con= tainer" (WRONG) rather than "not a (non-presence container)"= (RIGHT). Cheers, W.

= &= nbsp;

On 14 October 2015 at 20:41, Mart= in Bjorklund <mbj@ta= il-f.com> wrote:

William Lupton <wfl@cantab.net> wrote:
> All,
>
> B= oth RFC 6020 and the bis draft use the term "not a non-presence
>= ; container", sometimes with a reference to section 7.5.1.
>
= > Does this term mean the same as "presence container"?
No.  A list (for example) is not a non-presence container.

>= ; If so, I think it
> would be easier (on the reader!) to say that in= stead. If not, I think that
> the term warrants a mention in section = 7.5.1.

The term is "non-presence container", and it is exp= lained in 7.5.1.


/martin

 

 

 

= --_9F7B333F-AA15-4E74-A164-4CDAA830DC3E_-- From nobody Thu Oct 15 02:04:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EAD1A8920 for ; Thu, 15 Oct 2015 02:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dGQdSg4Sn1R for ; Thu, 15 Oct 2015 02:04:11 -0700 (PDT) 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 BF7CC1A890E for ; Thu, 15 Oct 2015 02:04:10 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-c9-561f6c089796 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.2D.05274.80C6F165; Thu, 15 Oct 2015 11:04:08 +0200 (CEST) Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 11:04:07 +0200 To: Andy Bierman , Martin Bjorklund References: <20151014.214813.106525154933227408.mbj@tail-f.com> <20151014.222642.365989360913160897.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <561F6C07.20807@ericsson.com> Date: Thu, 15 Oct 2015 11:04:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjS5HjnyYQf9HE4sHR2axW3R3P2O3 mH+xkdWB2WPJkp9MHht/LWbxaOm/yBLAHMVlk5Kak1mWWqRvl8CVcWzeQ8aCS5wVC299YW5g 3MLexcjJISFgInHmyQwWCFtM4sK99WxdjFwcQgJHGSVWdk5ghnDWMkq8ufKREaRKWMBY4tj6 VqAODg4RAQ+JNXPcQEwhgVNMEnMFQSqYBdQl7px6zAZiswkYSUztPw82n1dAU6JxwllWEJtF QFVietN/JhBbVCBG4v2mVYwQNYISJ2c+AavnFAiUmP9jOQvETAuJmfPPM0LY8hLb385hBrGF BDQkHl74yzqBUXAWkvZZSFpmIWlZwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwgA9u +a26g/HyG8dDjAIcjEo8vAs45MOEWBPLiitzDzFKc7AoifM2Mz0IFRJITyxJzU5NLUgtii8q zUktPsTIxMEp1cBYGHEsexpTQHRVg/71s5uqOj5dOVhrqi9ZP2WK9reFn8U3OVv5mc6YVmg/ 4cv8irfLJsl+2f5m8Yu5D4+6fbrs9qbwz9+ItUGsGUsZNkn2vbRb47vT8bTGsuCrc+foXjM4 UPI0bYvSnoN/izdUV3Et4+PMPtX9oc3SwWq+N4cX97mlgT4TPxesUmIpzkg01GIuKk4EAMM8 WbxBAgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:04:12 -0000 On 2015-10-14 23:06, Andy Bierman wrote: > Our server applies all the edits first, when checks all the when-stmts > that might have changed value. Nodes that have already existed in the > datastore may get pruned, not just the new nodes. > Hello Andy, We definitely need a new section/paragraph in RFC6020 about the scenario when the when statement is changed in a transaction and something under the when statement is also changed in the same transaction! --------------------------------------------------------------- So if you have the model leaf a {type boolean;} leaf b { when a type int8; } We have 3 cases: 1) if "a" is false and then you get an edit config with: set b=5 ; set a=true: result OK 2) if "a" is false and then you get an edit config with: set b=5: result unknown-element 3) if "a" is true and then you get an edit config with: set b=5 ; set a=false: result OK, b gets pruned (contradicts 8.2.1) Are these the results dictated by YANG and supported by your implementation? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Oct 15 02:51:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBC81AC3CF for ; Thu, 15 Oct 2015 02:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvqs5BJ2r10j for ; Thu, 15 Oct 2015 02:51:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A481AC39A for ; Thu, 15 Oct 2015 02:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32299; q=dns/txt; s=iport; t=1444902659; x=1446112259; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=afzX31e3PMaSSFXLkud2gZxAsFuECqwjrm7spSOUfbo=; b=GSOOm/vNTGV40vIk+OktZq4VhUVPC6+CXlFvDrVhyVfTP0bTqjpkF/Ra KMSiJDfTDI2JA8DBnDBUIunJwBND80dnuFiMccA6RGt84X1bx/caanxsr VwHKnfxXrkACQ0cRz9tpYRRG4NpAnqi6t6cNbTkn/SriswPOQu9jtycgt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMAQCgdh9W/xbLJq1eglmBIW69OgENgVYDFwEJhTFKAoFuFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwoBBQsJAhEDAQEBAQkWAQEGAwICCQMCAQIBFR8JCAYBDAYCAQEXiAsIDZIInTeTLgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnaEfoR8EQYBgmmBRQWWG40bgViHO48Ng28fAQFCgkSBQD0zhWcBAQE X-IronPort-AV: E=Sophos;i="5.17,684,1437436800"; d="scan'208,217";a="630343051" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Oct 2015 09:50:56 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9F9ouBg009566; Thu, 15 Oct 2015 09:50:56 GMT To: Jonathan Hansford , Kent Watsen , Andy Bierman References: <560D269E.30002@cisco.com> <561EC8E7.9080708@cisco.com> From: Robert Wilton Message-ID: <561F76F2.8030609@cisco.com> Date: Thu, 15 Oct 2015 10:50:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060202040009060206070302" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:51:07 -0000 This is a multi-part message in MIME format. --------------060202040009060206070302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan, Yes, of course, in the general case your statement is completely true. I think that my premise would still hold if either: - there is coordination of the intended configuration between multiple NMS - responsibility for parts of the configuration is split between multiple NMS and they are each independently responsible for ensuring that their part of the configuration has been programmed correctly. My point is really that I would more naturally expect the definitive configuration for a device to be known and held (perhaps in a distributed fashion) somewhere in the operators management network, not on the device itself. Thanks, Rob On 15/10/2015 09:55, Jonathan Hansford wrote: > > The NMS only knows the intended config if it is the only NMS capable > of changing that device’s config. That may not always be the case. > > Jonathan > > > *From: *Robert Wilton > *Sent: *14 October 2015 22:28 > *To: *Kent Watsen;Andy Bierman > *Cc: *netmod@ietf.org > *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter definition > of"applied configuration" > > On 14/10/2015 20:15, Kent Watsen wrote: > > Andy writes: > > > I am wondering why operators would want to compare 2 massive subtrees > > > in the first place, where 1 is static and the other is changing > constantly. > > > > > > Do they really want this complex task or do they just want to > > > determine if the intended config has been applied yet? > > I think that it is more the latter. And there have been > suggestions for solutions to provide something like a yang-patch > to describe just the diffs. Makes sense to me! > > > The NMS already knows the intended config since it sent it to the > device in the first place, so in normal circumstances I would expect > the NMS to only query the applied config (and possibly derived state > at the same time) and then compare it to the NMS's view of the > intended cfg for that device. If the NMS is smart then it might be > able to restrict most of the queries to only the device's applied > config sub-trees that could possibly be out of sync, perhaps with > periodic full synchronization checks. > > Otherwise, I think that a function that returns just the diff may also > be useful (the draft that I put forward also proposes a diff-cfg-only > option). However, it is also worth noting that the original > requirements don't explicitly ask for this, so perhaps more of a nice > to have than a formal requirement? > > Thanks, > Rob > > > > K. > > *From: *Andy Bierman > > *Date: *Wednesday, October 14, 2015 at 2:56 PM > *To: *Kent Watsen > > *Cc: *Robert Wilton >, "netmod@ietf.org > " > > *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter > definition of "applied configuration" > > On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen > wrote: > > Thank you Robert for bringing the discussion back to the > github issues. > > Robert writes: > > > In particular: > > > - does it include support for templating (as per > openconfig-netmod-opstate-01 section 7.3.)? > > > - is it allowed to represent system created objects that have no > corresponding configuration? > > > > > Requirement 1.D states > > D. For asynchronous systems, when fully synchronized, > the data > > in the applied configuration is the same as the > data in the > > intended configuration. > > > > > So, if this requirement statement stands as being valid > (which I think it should) then that would imply that the > answer for both the two issues above must be "no". The only > question would be whether these need to be explicitly listed out? > > [KENT] so I think I have to (begrudgingly) agree with your > logic. I have heard the operators state that they want the > intended/applied comparison to be drop-dead simple. To that > end, it would not be possible to flatten templates or apply > defaults, or make any other change – it needs to be as close > as possible to a carbon-copy of the original intended > configuration (where deviations are allowed only for cases > like a missing line-card). To this end, yes, I think that we > could tack on a statement like the following: > > That is, the intended configuration is a subset of the applied > > configuration where omissions are only due to when the > > configuration cannot be applied (e.g., a missing line-card). > > What do you think? > > I am wondering why operators would want to compare 2 massive subtrees > > in the first place, where 1 is static and the other is changing > constantly. > > Do they really want this complex task or do they just want to > > determine if the intended config has been applied yet? > > Andy > > >> - how does it relate to the state of the system after a equivalent > synchronous config commit (if at all)? > > >> > > Again, I think that definition of requirement 1.D, along > with the proposed definition of synchronous configuration > operation vs asynchronous configuration operation, will > provide a sufficient answer to this question. I.e. that the > state of the system after an asynchronous config operation > must, when fully synchronized, be the same as the state of the > system after an equivalent synchronous configuration operation > completes and replies back. > > [KENT] I agree with this, but I think it impacts issue #6 more > so than issue #4 - right? > > Thanks, > > Kent > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------060202040009060206070302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multiple NMS
 - responsibility for parts of the configuration is split between multiple NMS and they are each independently responsible for ensuring that their part of the configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive configuration for a device to be known and held (perhaps in a distributed fashion) somewhere in the operators management network, not on the device itself.

Thanks,
Rob


On 15/10/2015 09:55, Jonathan Hansford wrote:

The NMS only knows the intended config if it is the only NMS capable of changing that device’s config. That may not always be the case.

 

Jonathan

 

 


From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

 

 

 

On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:

> I am wondering why operators would want to compare 2 massive subtrees

> in the first place, where 1 is static and the other is changing constantly.

> 

> Do they really want this complex task or do they just want to

> determine if the intended config has been applied yet?

 

I think that it is more the latter.   And there have been suggestions for solutions to provide something like a yang-patch to describe just the diffs.  Makes sense to me!


The NMS already knows the intended config since it sent it to the device in the first place, so in normal circumstances I would expect the NMS to only query the applied config (and possibly derived state at the same time) and then compare it to the NMS's view of the intended cfg for that device.  If the NMS is smart then it might be able to restrict most of the queries to only the device's applied config sub-trees that could possibly be out of sync, perhaps with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be useful (the draft that I put forward also proposes a diff-cfg-only option).  However, it is also worth noting that the original requirements don't explicitly ask for this, so perhaps more of a nice to have than a formal requirement?

Thanks,
Rob



 

K.

 

 

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

 

 

 

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <kwatsen@juniper.net> wrote:

 

Thank you Robert for bringing the discussion back to the github issues.

 

Robert writes:

 

> In particular:

>    - does it include support for templating (as per openconfig-netmod-opstate-01 section 7.3.)?

>    - is it allowed to represent system created objects that have no corresponding configuration?

>
> Requirement 1.D states

     D.  For asynchronous systems, when fully synchronized, the data
           in the applied configuration is the same as the data in the
           intended configuration.

>
> So, if this requirement statement stands as being valid (which I think it should) then that would imply that the answer for both the two issues above must be "no".  The only question would be whether these need to be explicitly listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.    I have heard the operators state that they want the intended/applied comparison to be drop-dead simple.  To that end, it would not be possible to flatten templates or apply defaults, or make any other change – it needs to be as close as possible to a carbon-copy of the original intended configuration (where deviations are allowed only for cases like a missing line-card).  To this end, yes, I think that we could tack on a statement like the following:

 

That is, the intended configuration is a subset of the applied 

configuration where omissions are only due to when the

configuration cannot be applied (e.g., a missing line-card).

 

What do you think?

 

 

I am wondering why operators would want to compare 2 massive subtrees

in the first place, where 1 is static and the other is changing constantly.

 

Do they really want this complex task or do they just want to

determine if the intended config has been applied yet?

 

 

Andy

 

 

 

 

>>  - how does it relate to the state of the system after a equivalent synchronous config commit (if at all)?

>>
> Again, I think that definition of requirement 1.D, along with the proposed definition of synchronous configuration operation vs asynchronous configuration operation, will provide a sufficient answer to this question.  I.e. that the state of the system after an asynchronous config operation must, when fully synchronized, be the same as the state of the system after an equivalent synchronous configuration operation completes and replies back.

 

[KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 - right?

 

 

Thanks,

Kent

 

 


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

 

 

 

 


--------------060202040009060206070302-- From nobody Thu Oct 15 04:17:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774AC1ACE0E for ; Thu, 15 Oct 2015 04:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Tf76pk-Cw4nv for ; Thu, 15 Oct 2015 04:17:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C0A1B2B03 for ; Thu, 15 Oct 2015 04:17:45 -0700 (PDT) Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 15 Oct 2015 11:17:27 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 11:17:27 +0000 From: Gert Grammel To: Kent Watsen , Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAA Date: Thu, 15 Oct 2015 11:17:26 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:2KphmBRWL0yGbnlga6zX20ZUvbWFL/Ie7m4pNbgshWuoDuBpgeqjatrE3Egc1AhwL49BRia3SBgywBx5jLgcgvXGmXoM8FFC89qnmRUaMJFX+hBK1ysKbv996+XPCK0N4BAN/cQBO8ejE3urjkmYrA==; 24:w/htmG85mtQt8NZ6wHtk4Z+QCYdNn4UIAA9uFYMf+HyZRxtCRsJbQDXcHNV1X2dQM2a3mddWi8RwooBzLphdQK9ni1rWk5zUR5vISmRzg4A=; 20:b8t5NdW8D+w/8TmZBNP9CeyWmWh9gnIeu5ETDLjOkYE0IcUl2X3fJ1FqebmXibrHpA7N5ZTb8uVF3d91NrQyqQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(24454002)(76104003)(52314003)(189002)(505384003)(377454003)(51444003)(479174004)(199003)(53754006)(106116001)(64706001)(50986999)(93886004)(5008740100001)(5007970100001)(122556002)(54356999)(189998001)(10400500002)(81156007)(5001770100001)(36756003)(76176999)(99286002)(15975445007)(19617315012)(105586002)(5004730100002)(5001960100002)(19580395003)(16236675004)(11100500001)(106356001)(86362001)(102836002)(5001920100001)(97736004)(66066001)(2501003)(101416001)(561944003)(1941001)(4001350100001)(2900100001)(87936001)(46102003)(92566002)(40100003)(107886002)(5002640100001)(83506001)(19580405001)(2950100001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D2453EBA6FA4ggrammeljunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 11:17:26.9567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:17:54 -0000 --_000_D2453EBA6FA4ggrammeljunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn=92t look= complete. The way it stands for the synchronous operation, the client know= s that it's intended config was good AND it has been effected to the server= . In the Asynchronous case, the client only knows that the intended config = was good =96 and that=92s not enough. So the proposal is to refine the asynchronous case definition as follows: Asynchronous configuration operation - A configuration request to update th= e running configuration of a server that is applied asynchronously with res= pect to the client request. The server MUST update its intended configurat= ion (see term) before replying to the client indicating whether the request= will be processed. The reply to the client only indicates whether there a= re any errors in the original request. The server's applied configuration state (see term) is updated after the co= nfiguration change has been applied to all impacted components in the serve= r. Once applied, the client MUST be notified whether the intended config i= s now fully effective or there are any errors from applying the configurati= on change. In addition I would suggest to require a verify operation which a client ca= n request from the server to obtain above information on an on-demand basis= . Would that somehow go in the opstate-reqs #3 then? Best Gert From: netmod > on b= ehalf of Kent Watsen > Date: Thursday 15 October 2015 00:11 To: Robert Wilton >, "netmod@ie= tf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Robert, One comment, it seems that the asynchronous configuration operation should have one more sentence at its end saying that an asynchronous notification must be used to report any errors produced from when applying the configuration. What do you think? Kent // as a contributor On 10/14/15, 10:59 AM, "Robert Wilton" > wrote: Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... Works for me. Sometimes less is more. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Depends on the definition of applied configuration - where is the latest version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D2453EBA6FA4ggrammeljunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <189A7D1A7C23614CAFE9A8750C131019@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn=92t= look complete. The way it stands for the synchronous operation, the client= knows that it's intended config was good AND it has been effected to the s= erver. In the Asynchronous case, the client only knows that the intended config was good =96 and that=92s not e= nough.

So the proposal is to refine the asynchronous case definition as follo= ws:

Asynchronous configuration operation - A configuration request to upda= te the running configuration of a server that is applied asynchronously wit= h respect to the client request.  The server MUST update its inte= nded configuration (see term) before replying to the client indicating whether the request will be processed.  The = reply to the client only indicates whether there are any errors in the &nbs= p;original request.
The server's applied configuration state (see term) is updated after t= he configuration change has been applied to all impacted components in the = server.  Once applied, the client MUST be notified whether the intende= d config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a clie= nt can request from the server to obtain above information on an on-demand = basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@ietf.org> on behalf of Kent = Watsen <kwatsen@juniper.net&g= t;
Date: Thursday 15 October 2015 00:1= 1
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation sh= ould
have one more sentence at its end saying that an asynchronous notifica= tion
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or=
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to updat= e
the running configuration of a server that is applied synchronously wi= th
respect to the client request.  The server MUST fully effect= the
configuration change to all impacted components in the server, updatin= g
both the server's intended and applied configuration (see terms), befo= re
replying to the client.  The reply to the client indicates w= hether there
are any errors in the request or errors from applying the configuratio= n
change.

Asynchronous configuration operation - A configuration request to upda= te
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update = its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied=
configuration state (see term) is updated after the configuration chan= ge
has been fully effected to all impacted components in the server. = ; The
reply to the client only indicates whether there are any errors in the=
original request.

Synchronous configuration server - a configuration server that process= es
all configuration operations as synchronous configuration operations.<= /div>

Asynchronous configuration server - a configuration server that proces= ses
all configuration operations as asynchronous configuration operations.=

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure tha= t the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.<= /div>
The reply to the client indicates whether there are any errors in the<= /div>
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RF= C 6020
says:

     When datastore processing is complete, the fi= nal contents MUST
obey
     all validation constraints.  This v= alidation processing is
performed
     at differing times according to the datastore= .  If the datastore
is
     <running/> or <startup/>, these c= onstraints MUST be enforced at
the
     end of the <edit-config> or <copy-co= nfig> operation.  If the
     datastore is <candidate/>, the constrai= nt enforcement is delayed
     until a <commit> or <validate> op= eration.

Are we talking about datastore validation or validation of a request?<= /div>
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validat= e"
would exclude an ephemeral datastore, so I was trying to water down th= e
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration s= erver that processes
    some configuration operations as synchronous c= onfiguration
    operations and some configuration operations a= s asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy=
that in real systems, depending on the data model, certain parts of a<= /div>
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration= - this data represents the configuration
        state that the network= operator intends the system to be in, and
that
        has been accepted by t= he system as valid configuration.  This
data is
        colloquially referred = to as the 'configuration' of the system.

       applied configuration - this data= represents the configuration
        state that the network= element is actually in, i.e., the
        configuration state wh= ich is currently being being used by
system
        components (e.g., cont= rol plane daemons, operating system
        kernels, line cards).<= /div>
Well, sometimes the config goes to a control plane daemon and then to<= /div>
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that= the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if = that means
that the definition of applied configuration should be strengthened, o= r
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from<= /div>
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to<= /div>
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended=
config and then report the result of the guess work as applied config<= /div>
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price=
for this applied config idea, I have no real problem with this since I=
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list

--_000_D2453EBA6FA4ggrammeljunipernet_-- From nobody Thu Oct 15 04:25:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC751B2B65; Thu, 15 Oct 2015 04:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNRjwnDZoiOT; Thu, 15 Oct 2015 04:25:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A40301B2B61; Thu, 15 Oct 2015 04:25:22 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C0E691CC0183; Thu, 15 Oct 2015 13:25:25 +0200 (CEST) From: Ladislav Lhotka To: "Acee Lindem \(acee\)" In-Reply-To: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 15 Oct 2015 13:25:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Routing YANG , "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:25:26 -0000 Hi Acee, I made the necessary changes in ietf-routing, please see the GitHub repo: https://github.com/netmod-wg/routing-cfg A new leaf "rt:routing-instance" was augmented into interface configuration, and "rt:interfaces" container in configuration is gone. Below is the complete new tree. Will this work? Lada module: ietf-interfaces +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw ip:ipv4! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint16 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw (subnet) | | | +--:(prefix-length) | | | +--rw ip:prefix-length? uint8 | | +--rw ip:neighbor* [ip] | | +--rw ip:ip inet:ipv4-address-no-zone | | +--rw ip:link-layer-address yang:phys-address | +--rw ip:ipv6! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint32 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv6-address-no-zone | | | +--rw ip:prefix-length uint8 | | +--rw ip:neighbor* [ip] | | | +--rw ip:ip inet:ipv6-address-no-zone | | | +--rw ip:link-layer-address yang:phys-address | | +--rw ip:dup-addr-detect-transmits? uint32 | | +--rw ip:autoconf | | | +--rw ip:create-global-addresses? boolean | | +--rw v6ur:ipv6-router-advertisements | | +--rw v6ur:send-advertisements? boolean | | +--rw v6ur:max-rtr-adv-interval? uint16 | | +--rw v6ur:min-rtr-adv-interval? uint16 | | +--rw v6ur:managed-flag? boolean | | +--rw v6ur:other-config-flag? boolean | | +--rw v6ur:link-mtu? uint32 | | +--rw v6ur:reachable-time? uint32 | | +--rw v6ur:retrans-timer? uint32 | | +--rw v6ur:cur-hop-limit? uint8 | | +--rw v6ur:default-lifetime? uint16 | | +--rw v6ur:prefix-list | | +--rw v6ur:prefix* [prefix-spec] | | +--rw v6ur:prefix-spec inet:ipv6-prefix | | +--rw (control-adv-prefixes)? | | +--:(no-advertise) | | | +--rw v6ur:no-advertise? empty | | +--:(advertise) | | +--rw v6ur:valid-lifetime? uint32 | | +--rw v6ur:on-link-flag? boolean | | +--rw v6ur:preferred-lifetime? uint32 | | +--rw v6ur:autonomous-flag? boolean | +--rw rt:routing-instance? routing-instance-ref +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro in-octets? yang:counter64 | +--ro in-unicast-pkts? yang:counter64 | +--ro in-broadcast-pkts? yang:counter64 | +--ro in-multicast-pkts? yang:counter64 | +--ro in-discards? yang:counter32 | +--ro in-errors? yang:counter32 | +--ro in-unknown-protos? yang:counter32 | +--ro out-octets? yang:counter64 | +--ro out-unicast-pkts? yang:counter64 | +--ro out-broadcast-pkts? yang:counter64 | +--ro out-multicast-pkts? yang:counter64 | +--ro out-discards? yang:counter32 | +--ro out-errors? yang:counter32 +--ro ip:ipv4! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint16 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv4-address-no-zone | | +--ro (subnet)? | | | +--:(prefix-length) | | | +--ro ip:prefix-length? uint8 | | +--ro ip:origin? ip-address-origin | +--ro ip:neighbor* [ip] | +--ro ip:ip inet:ipv4-address-no-zone | +--ro ip:link-layer-address? yang:phys-address | +--ro ip:origin? neighbor-origin +--ro ip:ipv6! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint32 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:prefix-length uint8 | | +--ro ip:origin? ip-address-origin | | +--ro ip:status? enumeration | +--ro ip:neighbor* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:link-layer-address? yang:phys-address | | +--ro ip:origin? neighbor-origin | | +--ro ip:is-router? empty | | +--ro ip:state? enumeration | +--ro v6ur:ipv6-router-advertisements | +--ro v6ur:send-advertisements? boolean | +--ro v6ur:max-rtr-adv-interval? uint16 | +--ro v6ur:min-rtr-adv-interval? uint16 | +--ro v6ur:managed-flag? boolean | +--ro v6ur:other-config-flag? boolean | +--ro v6ur:link-mtu? uint32 | +--ro v6ur:reachable-time? uint32 | +--ro v6ur:retrans-timer? uint32 | +--ro v6ur:cur-hop-limit? uint8 | +--ro v6ur:default-lifetime? uint16 | +--ro v6ur:prefix-list | +--ro v6ur:prefix* [prefix-spec] | +--ro v6ur:prefix-spec inet:ipv6-prefix | +--ro v6ur:valid-lifetime? uint32 | +--ro v6ur:on-link-flag? boolean | +--ro v6ur:preferred-lifetime? uint32 | +--ro v6ur:autonomous-flag? boolean +--ro rt:routing-instance? routing-instance-state-ref module: ietf-routing +--ro routing-state | +--ro routing-instance* [name] | +--ro name string | +--ro type? identityref | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | +--ro type identityref | | +--ro name string | +--ro ribs | +--ro rib* [name] | +--ro name string | +--ro address-family identityref | +--ro default-rib? boolean {multiple-ribs}? | +--ro routes | +--ro route* | +--ro route-preference? route-preference | +--ro next-hop | | +--ro (next-hop-options) | | +--:(outgoing-interface) | | | +--ro outgoing-interface? if:interface-s= tate-ref | | +--:(special-next-hop) | | | +--ro special-next-hop? enumeration | | +--:(next-hop-address) | | | +--ro v6ur:next-hop-address? inet:ipv6-addr= ess | | +--:(next-hop-address) | | +--ro v4ur:next-hop-address? inet:ipv4-addr= ess | +--ro source-protocol identityref | +--ro active? empty | +--ro last-updated? yang:date-and-time | +--ro v6ur:destination-prefix? inet:ipv6-prefix | +--ro v4ur:destination-prefix? inet:ipv4-prefix +--rw routing +--rw routing-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw router-id? yang:dotted-quad +--rw description? string +--rw routing-protocols | +--rw routing-protocol* [type name] | +--rw type identityref | +--rw name string | +--rw description? string | +--rw static-routes | +--rw v6ur:ipv6 | | +--rw v6ur:route* [destination-prefix] | | +--rw v6ur:destination-prefix inet:ipv6-prefix | | +--rw v6ur:description? string | | +--rw v6ur:next-hop | | +--rw (next-hop-options) | | +--:(outgoing-interface) | | | +--rw v6ur:outgoing-interface? if:interf= ace-ref | | +--:(special-next-hop) | | | +--rw v6ur:special-next-hop? enumerati= on | | +--:(next-hop-address) | | +--rw v6ur:next-hop-address? inet:ipv6= -address | +--rw v4ur:ipv4 | +--rw v4ur:route* [destination-prefix] | +--rw v4ur:destination-prefix inet:ipv4-prefix | +--rw v4ur:description? string | +--rw v4ur:next-hop | +--rw (next-hop-options) | +--:(outgoing-interface) | | +--rw v4ur:outgoing-interface? if:interf= ace-ref | +--:(special-next-hop) | | +--rw v4ur:special-next-hop? enumerati= on | +--:(next-hop-address) | +--rw v4ur:next-hop-address? inet:ipv4= -address +--rw ribs +--rw rib* [name] +--rw name string +--rw address-family? identityref +--rw description? string "Acee Lindem (acee)" writes: > On 10/13/15, 12:30 PM, "Ladislav Lhotka" wrote: > >> >>> On 13 Oct 2015, at 17:20, Acee Lindem (acee) wrote: >>>=20 >>> Hi Lada, NETMOD, >>>=20 >>> So I think we should move forward this ietf-rtg-cfg so that it can be >>> augmented and other work can move forward. We are still in disagreement >>> with respect to routing-instance/interface configuration. >>>=20 >>> - We feel the IPv4/IPv6 interfaces should reference the >>> routing-instance in their config state. This is consistent with >>> draft-rtgyangdt-rtgwg-device-model-01.txt. >>> - You feel that the routing-instance should have a list of leaf-ref= =E2=80=99s >>> to the interface. You believe the leaf-ref provides a level of >>>validation >>> due to the fact that references can be confined to routing-instance >>> references. However, heretofore, no models are referencing the interface >>> leaf-refs in the list. >> >>True, these models (ietf-isis, for instance) use leafrefs with >>"if:interface-ref" type. However, such leafrefs are under-constrained >>because they can be configured to refer to: >> >>- interfaces of any layer, including physical interfaces, VLAN trunks etc. > > Actually, putting the routing-instance reference in the IPv4 and IPv6 > interface models (i.e., RFC 7277) constrains the reference to layer 3 more > effectively than the list of leaf-refs. > >> >>- interfaces assigned to any routing instance. > > But the list of leaf-refs doesn=E2=80=99t insure an IPv4 interface or IPv6 > interface isn=E2=80=99t included by a single routing-instance. > >> >>I believe in all these cases the choice has to be limited to (1) L3 >>interfaces, and (2) belonging to "own" routing instance. These >>constraints will have to be checked in server code somehow - I would >>prefer to have them represented in the data model. >> >>But if nobody shares this concern with me, I am not going to block the >>document on this issue. > > I=E2=80=99d also be interested if anyone shares this concern. > > Thanks, > Acee=20 > > >> >>Lada=20 >> >>>=20 >>> Other than the Routing YANG Design Team having chosen the first option - >>> are there any other opinions? >>>=20 >>> Thanks, >>> Acee >>>=20 >>> On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)" >>> wrote: >>>=20 >>>> Hi Lada,=20 >>>> I2RS is not chartered to do the base models. There are other routing >>>> models that reference routing-cfg and even in-progress implementations. >>>>=20 >>>> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I am sorry for cross-posting but I think it is high time to decide the >>>>> relationship between the data models in i2rs-rib-data-model and >>>>> netmod-routing-cfg I-Ds because they clearly target the same >>>>>management >>>>> data in a router. I can see three possible scenarios: >>>>>=20 >>>>> 1. The i2rs-rib module will be modified to augment >>>>> ietf-routing/ietf-ipv[46]-unicast-routing. >>>>=20 >>>> This would seem to be the obvious choice. >>>>=20 >>>>>=20 >>>>> 2. The scope of ietf-routing will be changed so that it would address >>>>> only host routing and simple routers. The modelling work for advanced >>>>> routers will be done elsewhere. >>>>>=20 >>>>> 3. The work on netmod-routing-cfg will be stopped. >>>>=20 >>>> A fourth option would be for me to take over ownership, move the work >>>>to >>>> the RTG WG, and we=E2=80=99d recruit some strong authors/reviewers from >>>>operators >>>> and other vendors (involving the ADs in selection). >>>>=20 >>>> Thanks, >>>> Acee=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Opinions? >>>>>=20 >>>>> Thanks, Lada >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 15 04:47:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06F91B2BB8 for ; Thu, 15 Oct 2015 04:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhgjXOLQqe5P for ; Thu, 15 Oct 2015 04:46:59 -0700 (PDT) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 D6B4C1B2BB4 for ; Thu, 15 Oct 2015 04:46:58 -0700 (PDT) Received: by lffv3 with SMTP id v3so26324360lff.0 for ; Thu, 15 Oct 2015 04:46:57 -0700 (PDT) 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=ccCClvKSyB3/I4eWd67AudjuhGXhVoa0r68OW31a6wA=; b=czrMR0DNVxn3KXcDzFajVNnwg9/YzWxE7Yfqb4x3DGcNUOumEHG7eZhTpIVxxQ76Wo 2NMs2p9Ld/wSgHBt98/C3nOj20WlIZ/Ytxe5B9DcnYhXF4LFTtCOeT+NTPQKHqmErYsq YCXYE8lxBSsfWSB0dmYUc1vOm/ZwDVMGp7zqFBEIOV2uWildy4m5eYp+G0y1CeOnEnEc d+x7sY/VGvm13YmYsGvWVAaQlgC+vEEqJ0QyjzJZcyoIBMcFO5SKN3zq01CR763LQfog WgPUalaezPWt9DwsbdD+97QEbwbdw3U0LKa3Rsg0/kHaBjj8ETQZajP/FEIjrLBndvXg P7kQ== X-Gm-Message-State: ALoCoQm4mi4PsaHUlqRyjQmiBpot67uWwdtZhlw5VY7UaobajjXFiLCHhf5v+pG/kYTNg0vbnLiR MIME-Version: 1.0 X-Received: by 10.25.218.14 with SMTP id r14mr2756451lfg.82.1444909617001; Thu, 15 Oct 2015 04:46:57 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 15 Oct 2015 04:46:56 -0700 (PDT) In-Reply-To: <561F5D28.5020304@ericsson.com> References: <20151014.214813.106525154933227408.mbj@tail-f.com> <20151014.222642.365989360913160897.mbj@tail-f.com> <561F5D28.5020304@ericsson.com> Date: Thu, 15 Oct 2015 04:46:56 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a114019b27454070522233ca2 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:47:01 -0000 --001a114019b27454070522233ca2 Content-Type: text/plain; charset=UTF-8 Hi, You are incorrect. Within the PAYLOAD (as this section describes), there is no when-stmt for data nodes within the datastore. Look at the YANG for edit-config. There are no when-stmts for "interface" in "edit-config". So explain which constraint in the payload is being violated? Andy On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel wrote: > See below, Balazs > > On 2015-10-14 23:06, Andy Bierman wrote: > > > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < > mbj@tail-f.com> wrote: > >> Andy Bierman wrote: >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund >> wrote: >> > >> > > Andy Bierman wrote: >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund >> > > wrote: >> > > > >> > > > > Balazs Lengyel < >> balazs.lengyel@ericsson.com> wrote: >> > > > > > Hello Martin, >> > > > > > I agree that A1 is what follows the spirit of YANG, but then >> IMHO you >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and >> > > error. >> > > > > >> > > > > Ok, I agree. I suggest we remove from 8.2.1: >> > > > > >> > > > > o If data for a node tagged with "when" is present, and the >> "when" >> > > > > condition evaluates to "false", the server MUST reply with >> an >> > > > > "unknown-element" error-tag in the rpc-error. >> > > > > >> > > > > and add to 8.2.2: >> > > > > >> > > > > o Modification requests for nodes tagged with "when", and the >> "when" >> > > > > condition evaluates to "false". In this case the server MUST >> > > reply >> > > > > with an "unknown-element" error-tag in the rpc-error. >> > > > > >> > > > > >> > > > > >> > > > >> > > > This seems like a BIG protocol change to behavior. >> > > > IMO this not an error at all. In our server the false-when data is >> just >> > > > pruned, and no error is ever sent for a pruned when=false data node. >> > > >> > > So you are not following the current RFC 6020 spec? >> > > >> > >> > >> > Yes we are following it. >> >> Ok. >> >> > The schema for the edit-config RPC operation contains >> > an 'anyxml' for node. It does not contain any >> > when-stmts for the data nodes that get passed in the node. >> > The correct behavior is to just enforce the error on the when-stmts >> > that appear in the rpc-stmt. >> >> I don't understand what you are trying to say. >> > > > I know about the text that says a false-when in an RPC is an error. > Show me the when-stmts "interface" in the "edit-config" rpc-stmt. > > > > >> >> Here's an example: >> >> augment /if:interfaces/if:interface { >> when "if:type = 'ianaift:ethernetCsmacd'"; >> >> container ethernet { >> leaf duplex { >> type enumeration { >> enum "half"; >> enum "full"; >> } >> } >> } >> } >> >> Suppose the db is empty. >> >> What if the edit-confif contains >> >> >> >> eth0 >> full >> ianaift:ethernetCsmacd >> >> >> >> will that work or not? I.e., will the eth0 interface be created with >> duplex full? >> > > Yes -- because these are data nodes and the rules for when-stmt > on data nodes are different than for rpc-stmt. Then the when-stmt > is a test on whether the node should exist in the candidate or running > datastore. > > Our server applies all the edits first, when checks all the when-stmts > that might have changed value. Nodes that have already existed in the > datastore may get pruned, not just the new nodes. > > > > > >> >> /martin >> >> >> > > Andy > > >> >> > >> > >> > >> > >> > > I don't think this is a BIG protocol change, since the spec already >> > > says that requests for nodes w/ false when expressions MUST send >> > > error. The change is to say that this behavior is true regardless of >> > > evaluation order. >> > > >> > > > It may be a client programming error for the client to provide >> > > > false when nodes or not. What if the client is reusing some >> > > > code that sends 5 parameters, it it's OK if 1 of them gets >> > > > pruned sometimes because of a false when (e.g, product >> > > > feature-specific knob and that feature is not installed) >> > > >> > > Well, it might be simpler to send if-featured nodes that the specific >> > > server doesn't support - this is also an error in 6020. >> > > >> > > > BTW, this is a really good example of what not to do, if one >> > > > wants to make the YANG specification protocol independent. >> > > >> > > That statement is true for the entire section 8.2, it is not >> > > specifically true for this change. >> > > >> > > >> > > /martin >> > > >> > >> > >> > Andy >> > > And this contradicts the current rfc6020bis-07#section-8.2.1 which states > that already during parsing you must check > > If data for a node tagged with "when" is present, and the "when" > condition evaluates to "false", the server MUST reply with an > "unknown-element" error-tag in the rpc-error. > > > So already during parsing full you MUST send back an error; > before processing ianaift:ethernetCsmacd. > (I also assume this is independent from the document order of the edit-config request.) > So this MUST be corrected in the draft! > regards Balazs > > > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > --001a114019b27454070522233ca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

You are incorrect.

Within the PAYLOAD (as this section describes), there is no when-s= tmt
for data nodes within the datastore.=C2=A0 Look at the YANG f= or edit-config.
There are no when-stmts for "interface"= in "edit-config".

So explain which cons= traint in the payload is being violated?


Andy


On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel &= lt;balazs.= lengyel@ericsson.com> wrote:
See below, Balazs

On 2015-10-14 23:06, Andy Bierman wrote:
=20


On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <mbj@t= ail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> > > > > Hello Martin,
> > > > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> > error.
> > > >
> > > > Ok, I agree.=C2=A0 I suggest we remove fr= om 8.2.1:
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 If data for a node t= agged with "when" is present, and the "when"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evalu= ates to "false", the server MUST reply with an
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-e= lement" error-tag in the rpc-error.
> > > >
> > > > and add to 8.2.2:
> > > >
> > > >=C2=A0 =C2=A0o=C2=A0 Modification requests= for nodes tagged with "when", and the "when"
> > > >=C2=A0 =C2=A0 =C2=A0 condition evaluates t= o "false".=C2=A0 In this case the server MUST
> > reply
> > > >=C2=A0 =C2=A0 =C2=A0 with an "unknown= -element" error-tag in the rpc-error.
> > > >
> > > >
> > > >
> > >
> > > This seems like a BIG protocol change to <edit-config> behavior.
> > > IMO this not an error at all.=C2=A0 In our server the false-when data is just
> > > pruned, and no error is ever sent for a pruned when=3Dfalse data node.
> >
> > So you are not following the current RFC 6020 spec?
> >
>
>
> Yes we are following it.

Ok.

> The schema for the edit-config RPC operation contains > an 'anyxml' for <config> node.=C2=A0 It do= es not contain any
> when-stmts for the data nodes that get passed in the <config> node.
> The correct behavior is to just enforce the error on the when-stmts
> that appear in the rpc-stmt.

I don't understand what you are trying to say.


I know about the text that says a false-when in an RPC is an error.
Show me the when-stmts =C2=A0"interface" in the "edit-config" rpc-stmt.


=C2=A0

Here's an example:

=C2=A0 augment /if:interfaces/if:interface {
=C2=A0 =C2=A0 when "if:type =3D 'ianaift:ethernetCsm= acd'";

=C2=A0 =C2=A0 container ethernet {
=C2=A0 =C2=A0 =C2=A0 leaf duplex {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "half";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "full";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }

Suppose the db is empty.

What if the edit-confif contains

=C2=A0 <interfaces>
=C2=A0 =C2=A0 <interface>
=C2=A0 =C2=A0 =C2=A0 <name>eth0</name>
=C2=A0 =C2=A0 =C2=A0 <eth:duplex>full</eth:duplex>= ;
=C2=A0 =C2=A0 =C2=A0 <type>ianaift:ethernetCsmacd</t= ype>
=C2=A0 =C2=A0 </interface>
=C2=A0 </interfaces>

will that work or not?=C2=A0 I.e., will the eth0 interface be created with
duplex full?

Yes -- because these are data nodes and the rules for when-stmt
on data nodes are different than for rpc-stmt.=C2=A0 Then the when-stmt
is a test on whether the node should exist in the candidate or running
datastore.

Our server applies all the edits first, when checks all the when-stmts
that might have changed value.=C2=A0 Nodes that have alrea= dy existed in the
datastore may get pruned, not just the new nodes.






/martin




Andy
=C2=A0

>
>
>
>
> > I don't think this is a BIG protocol change, since the spec already
> > says that requests for nodes w/ false when expressions MUST send
> > error.=C2=A0 The change is to say that this behavio= r is true regardless of
> > evaluation order.
> >
> > > It may be a client programming error for the client to provide
> > > false when nodes or not.=C2=A0 What if the client is reusing some
> > > code that sends 5 parameters, it it's OK i= f 1 of them gets
> > > pruned sometimes because of a false when (e.g, product
> > > feature-specific knob and that feature is not installed)
> >
> > Well, it might be simpler to send if-featured nodes that the specific
> > server doesn't support - this is also an error in 6020.
> >
> > > BTW, this is a really good example of what not to do, if one
> > > wants to make the YANG specification protocol independent.
> >
> > That statement is true for the entire section 8.2, it is not
> > specifically true for this change.
> >
> >
> > /martin
> >
>
>
> Andy

And this contradicts the current rfc6020bis-07#section-8.2.1 which states that already during parsing you must check 
If data for a node tagged with "when" is present, and th=
e "when"
      condition evaluates to "false", the server MUST reply with =
an
      "unknown-element" error-tag in the rpc-error.
=20

So already during parsing <eth:duplex>full</eth:duplex>=
; you MUST send back an error;
before processing <type>ianaift:ethernetCsmacd</type>.=20
(I also assume this is independent from the document order of the edit-conf=
ig request.)
So this MUST be corrected in the draft!
regards Balazs


=C2=A0

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

--001a114019b27454070522233ca2-- From nobody Thu Oct 15 04:53:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16AC1B2C16 for ; Thu, 15 Oct 2015 04:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DAc6noEoYSA for ; Thu, 15 Oct 2015 04:53:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 176251B2C15 for ; Thu, 15 Oct 2015 04:53:36 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id E3EE61AE0454; Thu, 15 Oct 2015 13:53:34 +0200 (CEST) Date: Thu, 15 Oct 2015 13:53:34 +0200 (CEST) Message-Id: <20151015.135334.2134677503217017095.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <561F5D28.5020304@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:53:38 -0000 Andy Bierman wrote: > Hi, > > You are incorrect. > > Within the PAYLOAD (as this section describes), there is no when-stmt > for data nodes within the datastore. Look at the YANG for edit-config. > There are no when-stmts for "interface" in "edit-config". Andy, there is some confusion here. The section talks about: For configuration data, there are three windows when constraints MUST be enforced: - during parsing of RPC payloads - during processing of NETCONF operations - during validation So the entire section talks about constraints *on configuration data*. If you interpret this section to talk about the nodes in the definition of edit-config, nothing in the section makes any sense at all. For example: If all keys of a list entry are not present, the server MUST reply with a "missing-element" error-tag in the rpc-error. you might say that there are no lists in the definition of edit-config, so this bullet doesn't apply. /martin > > So explain which constraint in the payload is being violated? > > > Andy > > > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel > wrote: > > > See below, Balazs > > > > On 2015-10-14 23:06, Andy Bierman wrote: > > > > > > > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < > > mbj@tail-f.com> wrote: > > > >> Andy Bierman wrote: > >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund > >> wrote: > >> > > >> > > Andy Bierman wrote: > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund > >> > > wrote: > >> > > > > >> > > > > Balazs Lengyel < > >> balazs.lengyel@ericsson.com> wrote: > >> > > > > > Hello Martin, > >> > > > > > I agree that A1 is what follows the spirit of YANG, but then > >> IMHO you > >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and > >> > > error. > >> > > > > > >> > > > > Ok, I agree. I suggest we remove from 8.2.1: > >> > > > > > >> > > > > o If data for a node tagged with "when" is present, and the > >> "when" > >> > > > > condition evaluates to "false", the server MUST reply with > >> an > >> > > > > "unknown-element" error-tag in the rpc-error. > >> > > > > > >> > > > > and add to 8.2.2: > >> > > > > > >> > > > > o Modification requests for nodes tagged with "when", and the > >> "when" > >> > > > > condition evaluates to "false". In this case the server MUST > >> > > reply > >> > > > > with an "unknown-element" error-tag in the rpc-error. > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > This seems like a BIG protocol change to behavior. > >> > > > IMO this not an error at all. In our server the false-when data is > >> just > >> > > > pruned, and no error is ever sent for a pruned when=false data node. > >> > > > >> > > So you are not following the current RFC 6020 spec? > >> > > > >> > > >> > > >> > Yes we are following it. > >> > >> Ok. > >> > >> > The schema for the edit-config RPC operation contains > >> > an 'anyxml' for node. It does not contain any > >> > when-stmts for the data nodes that get passed in the node. > >> > The correct behavior is to just enforce the error on the when-stmts > >> > that appear in the rpc-stmt. > >> > >> I don't understand what you are trying to say. > >> > > > > > > I know about the text that says a false-when in an RPC is an error. > > Show me the when-stmts "interface" in the "edit-config" rpc-stmt. > > > > > > > > > >> > >> Here's an example: > >> > >> augment /if:interfaces/if:interface { > >> when "if:type = 'ianaift:ethernetCsmacd'"; > >> > >> container ethernet { > >> leaf duplex { > >> type enumeration { > >> enum "half"; > >> enum "full"; > >> } > >> } > >> } > >> } > >> > >> Suppose the db is empty. > >> > >> What if the edit-confif contains > >> > >> > >> > >> eth0 > >> full > >> ianaift:ethernetCsmacd > >> > >> > >> > >> will that work or not? I.e., will the eth0 interface be created with > >> duplex full? > >> > > > > Yes -- because these are data nodes and the rules for when-stmt > > on data nodes are different than for rpc-stmt. Then the when-stmt > > is a test on whether the node should exist in the candidate or running > > datastore. > > > > Our server applies all the edits first, when checks all the when-stmts > > that might have changed value. Nodes that have already existed in the > > datastore may get pruned, not just the new nodes. > > > > > > > > > > > >> > >> /martin > >> > >> > >> > > > > Andy > > > > > >> > >> > > >> > > >> > > >> > > >> > > I don't think this is a BIG protocol change, since the spec already > >> > > says that requests for nodes w/ false when expressions MUST send > >> > > error. The change is to say that this behavior is true regardless of > >> > > evaluation order. > >> > > > >> > > > It may be a client programming error for the client to provide > >> > > > false when nodes or not. What if the client is reusing some > >> > > > code that sends 5 parameters, it it's OK if 1 of them gets > >> > > > pruned sometimes because of a false when (e.g, product > >> > > > feature-specific knob and that feature is not installed) > >> > > > >> > > Well, it might be simpler to send if-featured nodes that the specific > >> > > server doesn't support - this is also an error in 6020. > >> > > > >> > > > BTW, this is a really good example of what not to do, if one > >> > > > wants to make the YANG specification protocol independent. > >> > > > >> > > That statement is true for the entire section 8.2, it is not > >> > > specifically true for this change. > >> > > > >> > > > >> > > /martin > >> > > > >> > > >> > > >> > Andy > >> > > > > And this contradicts the current rfc6020bis-07#section-8.2.1 which states > > that already during parsing you must check > > > > If data for a node tagged with "when" is present, and the "when" > > condition evaluates to "false", the server MUST reply with an > > "unknown-element" error-tag in the rpc-error. > > > > > > So already during parsing full you MUST send back an error; > > before processing ianaift:ethernetCsmacd. > > (I also assume this is independent from the document order of the edit-config request.) > > So this MUST be corrected in the draft! > > regards Balazs > > > > > > > > > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > ECN: 831 7320 > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > > From nobody Thu Oct 15 04:59:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71F1B2C84 for ; Thu, 15 Oct 2015 04:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tteJcuXoNnV for ; Thu, 15 Oct 2015 04:59:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65451B2C83 for ; Thu, 15 Oct 2015 04:59:08 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-5a-561f950aea6c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.49.27359.A059F165; Thu, 15 Oct 2015 13:59:06 +0200 (CEST) Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 13:59:06 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <561F9509.4060008@ericsson.com> Date: Thu, 15 Oct 2015 13:59:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010803030007000604090103" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvjS7XVPkwg51dhhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY+/bn2wF16Urzv0/xdTA+Fqsi5GTQ0LAROL2/Z1sELaYxIV7 64FsLg4hgaOMErsv7WaBcNYySlyaPJcZpEpEQF1i5s71YB1sAkYSU/vPs4DYwgKyEpcn32YH sXkFtCXeXtzHCmKzCKhKLDj4hhHEFhWIkXi/aRUjRI2gxMmZT8B6mQUCJBZeW8IEYgsJaEg8 vPCXdQIj7ywkZbOQlEHYFhIz559nhLDlJba/ncMMU/Py0h6oGkWJKd0P2SFsD4kL/84wL2Bk X8UoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGJwHt/w22MH48rnjIUYBDkYlHt4FHPJhQqyJ ZcWVuYcYpTlYlMR5m5kehAoJpCeWpGanphakFsUXleakFh9iZOLglGpgnHDcPHfVxHUapS6a qaFGekYe7zrP3hZ+H+ketXlW76LFltseXtvTtWC519yVC5LMXshedWLWvMQ7Ne3n15s50RtC YsueZ3DVreG5qtmtfCbjm5Cdz8wJV1RUFMRuJ2j6v6gqq7nKdlugjf3Or9anbRv4O3pv8zTe fLbwjeqfeGvTcPMlWXN/KbEUZyQaajEXFScCABPQaQMvAgAA Archived-At: Subject: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:59:10 -0000 --------------010803030007000604090103 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, In RFC6020bis we write: "There MUST NOT be any circular dependencies in these "when" expressions." How about a circular when-choice loop? leaf a1 { type boolean; when not(../a2); } choice c2 { default case2; case case1 { when not(a1); leaf b1 {type int8;} } case case2 { leaf a2 { type boolean; default true; } } } Initial state: a1=false, b1=5; - Set a1=true - case1 and b1 disapears - case2 and a2=false are set as default - a1 disappears - if there is no a1 why did we delete case1/b1? Did I miss something, is this really what happens? Even if someone can come up with the correct solution, operators will be 100% sure to mess this up. Usability=0 !!! I want some of this multistep when/when, choice/choice, when/choice scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation is implementation dependent: that would make it unusable, so practically prohibiting then while maintaining backward compatibility :-) I attached an even more complicated example, so go ahead have fun understand it! regards Balazs PS: Why did we make YANG so complicated? -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------010803030007000604090103 Content-Type: text/plain; charset="UTF-8"; name="choice-when-interaction.yang" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="choice-when-interaction.yang" ICAgIGNvbnRhaW5lciBzY2VuMjIgeyAgICAgIC8vIFdoZW4tMSAod2hlblZhcmlhYmxlMSkg YmVjb21lcyBmYWxzZSwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gdGhhdCBy ZW1vdmVzIGEgY2FzZS1BIChjaG9pY2Utc2NlbjIyYTpBKSwgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgLy8gdGhhdCBjcmVhdGVzIGNhc2UgQi9zY2VuMjItbnVtMg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8vICB0aGF0IG1ha2VzIHdoZW4tMiBmYWxzZSwgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gdGhhdCBkZWxldGVzIGEgY2FzZSBicmFu Y2gsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHRodXMgY3JlYXRpbmcgYSBz aWJsaW5nIGRlZmF1bHQgY2FzZSBicmFuY2gNCiAgICAgICAgcHJlc2VuY2UgeWVzOyAgDQog ICAgICAgIGxlYWYgd2hlblZhcmlhYmxlMSB7IHR5cGUgYm9vbGVhbjt9DQogICAgICAgIGNo b2ljZSBjaG9pY2Utc2NlbjIyYSB7DQogICAgICAgICAgICBkZWZhdWx0IEI7DQogICAgICAg ICAgICBjYXNlIEEgew0KICAgICAgICAgICAgICAgIHdoZW4gd2hlblZhcmlhYmxlMTsgICAg Ly8gd2hlbi0xDQogICAgICAgICAgICAgICAgbGVhZiBzY2VuMjItbnVtMSB7dHlwZSBpbnQx Njt9DQogICAgICAgICAgICB9DQogICAgICAgICAgICBjYXNlIEIgew0KICAgICAgICAgICAg ICAgIGxlYWYgc2NlbjIyLW51bTIge3R5cGUgaW50MTY7IGRlZmF1bHQgNTt9DQogICAgICAg ICAgICB9DQogICAgICAgIH0NCiAgICAgICAgbGVhZiB3aGVuVmFyaWFibGUgeyB0eXBlIGJv b2xlYW47fQ0KICAgICAgICBjaG9pY2UgY2hvaWNlLXNjZW4yMmIgew0KICAgICAgICAgICAg ZGVmYXVsdCBCOw0KICAgICAgICAgICAgY2FzZSBBIHsNCiAgICAgICAgICAgICAgICB3aGVu ICJub3Qoc2NlbjIyLW51bTIgPSAnNScpIjsgICAvLyB3aGVuLTINCiAgICAgICAgICAgICAg ICBsZWFmIHNjZW4yMi1udW0zIHt0eXBlIGludDE2O30NCiAgICAgICAgICAgIH0NCiAgICAg ICAgICAgIGNhc2UgQiB7DQogICAgICAgICAgICAgICAgbGVhZiBzY2VuMjItbnVtNCB7dHlw ZSBpbnQxNjsgZGVmYXVsdCA4O30NCiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgICAg ICANCiAgICB9DQo= --------------010803030007000604090103-- From nobody Thu Oct 15 05:27:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06F41B2DCF for ; Thu, 15 Oct 2015 05:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8rpQUYv9mqr for ; Thu, 15 Oct 2015 05:27:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA731A038F for ; Thu, 15 Oct 2015 05:27:02 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 015891AE0454; Thu, 15 Oct 2015 14:27:00 +0200 (CEST) Date: Thu, 15 Oct 2015 14:27:00 +0200 (CEST) Message-Id: <20151015.142700.1951499231830256717.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <561F9509.4060008@ericsson.com> References: <561F9509.4060008@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:27:04 -0000 Balazs Lengyel wrote: > Hello, > In RFC6020bis we write: > "There MUST NOT be any circular dependencies in these "when" > expressions." > How about a circular when-choice loop? Good catch. choice/case can (more or less) be seen as a syntactic sugar for a special form a when expressions; or rather, choice/case can be rewritten with when: choice a { case c1 { node n11; ... node n1N; } case c2 { node n21; ... node n2N; } ... case cM { node nM1; ... node nMN; } } can (sort of) be rewritten as: node n11 { when not(n21 or .. n2N or .. nM1 or nMN); } node n1N { when not(n21 or .. n2N or .. nM1 or nMN); } node n21 { when not(n11 or .. n1N or n31 or n3N ...); } node n22 { when not(n11 or .. n1N or n31 or n3N ...); } ... So, if you expand your example, there is actually a loop in the when expressions. /martin > > leaf a1 { > type boolean; > when not(../a2); > } > choice c2 { > default case2; > case case1 { > when not(a1); > leaf b1 {type int8;} > } > case case2 { > leaf a2 { > type boolean; > default true; > } > } > } > > Initial state: a1=false, b1=5; > - Set a1=true > - case1 and b1 disapears > - case2 and a2=false are set as default > - a1 disappears > - if there is no a1 why did we delete case1/b1? > Did I miss something, is this really what happens? > > Even if someone can come up with the correct solution, operators will > be 100% sure to mess this up. Usability=0 !!! > > I want some of this multistep when/when, choice/choice, when/choice > scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the > order of evaluation is implementation dependent: that would make it > unusable, so practically prohibiting then while maintaining backward > compatibility :-) > > I attached an even more complicated example, so go ahead have fun > understand it! > regards Balazs > > PS: Why did we make YANG so complicated? > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > From nobody Thu Oct 15 05:39:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128E1B3119 for ; Thu, 15 Oct 2015 05:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaNoC4hqrhSA for ; Thu, 15 Oct 2015 05:39:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B6B411B3118 for ; Thu, 15 Oct 2015 05:39:40 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id C66ED1AE0454; Thu, 15 Oct 2015 14:39:39 +0200 (CEST) Date: Thu, 15 Oct 2015 14:39:39 +0200 (CEST) Message-Id: <20151015.143939.746024114526885799.mbj@tail-f.com> To: jonathan@hansfords.net From: Martin Bjorklund In-Reply-To: References: <20151014.214145.1464628339304882836.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] not a non-presence container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:39:47 -0000 Jonathan Hansford wrote: > If that misinterpretation has already happened for (at least) one > individual, would it be worth adding the clarification and remove the= > ambiguity? Sure. The words "not a non-presence container" occurs a couple of times throughout the document. Would it be correct to write "not a non-presence-container"? /martin > = > Jonathan > = > = > = > From: William Lupton > Sent: 14 October 2015 23:28 > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] not a non-presence container > = > = > Thanks. I see now. As you will have realised, I parsed "not a > non-presence container" as "(not a non-presence) container" (WRONG) > rather than "not a (non-presence container)" (RIGHT). Cheers, W. > = > On 14 October 2015 at 20:41, Martin Bjorklund wrote:= > William Lupton wrote: > > All, > > > > Both RFC 6020 and the bis draft use the term "not a non-presence > > container", sometimes with a reference to section 7.5.1. > > > > Does this term mean the same as "presence container"? > = > No.=A0 A list (for example) is not a non-presence container. > = > > If so, I think it > > would be easier (on the reader!) to say that instead. If not, I thi= nk > > that > > the term warrants a mention in section 7.5.1. > = > The term is "non-presence container", and it is explained in 7.5.1. > = > = > /martin > = > = > = From nobody Thu Oct 15 05:53:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C798A1B3145 for ; Thu, 15 Oct 2015 05:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSCaRNeyOw_D for ; Thu, 15 Oct 2015 05:53:25 -0700 (PDT) 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 9C5CC1B3147 for ; Thu, 15 Oct 2015 05:53:25 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:4595:7241:573a:b276] (unknown [IPv6:2001:718:1a02:1:4595:7241:573a:b276]) by mail.nic.cz (Postfix) with ESMTPSA id 12FC2181907; Thu, 15 Oct 2015 14:53:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444913604; bh=jPukZHuMCNeor6/7Q1cLbFE96Ejdxu2+aTl5fbTSg2Y=; h=From:Date:To; b=MzETHcLnQOwXRiSN1SswpG0UzfT6sPw8mK37k/tT2id1Ee+f6iCBPyRCJGrHiT0p3 aeiIN1mcoa5x19bYhxc7hlpppzOzJYTJyAFryB62X8HzR5QBHgc8OcLhzZXNr1lPaj 7YvWWwz0nQll3Oi0WF3SqTmh6zTZuztVc0GpzShI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <561F9509.4060008@ericsson.com> Date: Thu, 15 Oct 2015 14:53:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz> References: <561F9509.4060008@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:53:28 -0000 Hi Balazs, one lesson taken from early XML schema languages (DTD) was that = modifying the validated document during validation easily leads to nasty = race conditions. That's why RELAX NG avoids changing the XML infoset = like plague. I've already got tired reiterating (and providing examples) that "when" = statement is inherently broken - the schema should not depend on = evaluating arbitrary expressions in the context of an instance document = that is supposed to be validated with the schema. The standard = disclaimer is that it works for simple cases, and more complicated = corner cases are "garbage in - garbage out". Lada P.S. Note that XPath expressions like "not(../a2)" evaluate to false if = ../a2 exists, even if its content is "false". So you'd need expressions = like "not(../a2 =3D 'true')". > On 15 Oct 2015, at 13:59, Balazs Lengyel = wrote: >=20 > Hello, > In RFC6020bis we write: > "There MUST NOT be any circular dependencies in these "when" = expressions." > How about a circular when-choice loop? >=20 > leaf a1 { > type boolean; > when not(../a2); > } > choice c2 { > default case2; > case case1 { > when not(a1); > leaf b1 {type int8;} > } > case case2 { > leaf a2 { > type boolean; > default true; > } > } > } >=20 > Initial state: a1=3Dfalse, b1=3D5; > - Set a1=3Dtrue > - case1 and b1 disapears > - case2 and a2=3Dfalse are set as default > - a1 disappears > - if there is no a1 why did we delete case1/b1? > Did I miss something, is this really what happens? >=20 > Even if someone can come up with the correct solution, operators will = be 100% sure to mess this up. Usability=3D0 !!! >=20 > I want some of this multistep when/when, choice/choice, when/choice = scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the = order of evaluation is implementation dependent: that would make it = unusable, so practically prohibiting then while maintaining backward = compatibility :-) >=20 > I attached an even more complicated example, so go ahead have fun = understand it! > regards Balazs >=20 > PS: Why did we make YANG so complicated? >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > = ____________________________________________= ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 15 06:06:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3531A1BDD for ; Thu, 15 Oct 2015 06:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dgA6VKw8KOd for ; Thu, 15 Oct 2015 06:05:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FB41A1BDA for ; Thu, 15 Oct 2015 06:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4012; q=dns/txt; s=iport; t=1444914357; x=1446123957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R+7d16M8k0jbYh2OjV3RxQdfY8lN04HYrMI8tlIuH3A=; b=EaXJ+arDrUBfMMD/0xxAAdb5LtzSdkIcVzrwFrOc4eXisXHbfJn6lilM hKSdHW7809ZiwFsi4fILDpBa2VQtSRP+JDIuqh1aSmw85IKvWeWHsDdrE xtFs4yj01060DrGUc+3figfRiSIYvMOSbfpvCgFycIYhqheHrcMDIg+kX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQD6ox9W/5xdJa1egyZUbga9NwENgVkXCoUxSgIcgRo4FAEBAQEBAQGBCoQmAQEBAwEBAQEgEToLBQsCAQYCDgMDAQIBAgIfBwICAiULFQgIAgQOBQmIHQgNkhadN5MyAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihVSCEIJugkKCMBsHgmkxgRQFlhsBhRiIAoFYhDqDJJJYAR8BAUKCRIE/cYRhgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,685,1437436800"; d="scan'208";a="40987593" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2015 13:05:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9FD5uZc018337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 13:05:56 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 08:05:41 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 08:05:41 -0500 From: "Carl Moberg (camoberg)" To: Kent Watsen Thread-Topic: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied Thread-Index: AQHQ+5bVY+r8w1658UewPXEWKgfK555p0uoAgAHh9gCAATw2AA== Date: Thu, 15 Oct 2015 13:05:40 +0000 Message-ID: <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> References: <561D0724.1030602@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.135] Content-Type: text/plain; charset="utf-8" Content-ID: <6285E93908E2B74ABFB0E8B6F7DC03A7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:05:59 -0000 DQogTWF5YmUgd2XigJlyZSBjb21pbmcgZG93biB0byBhIGRlZmluaXRpb24gb2Yg4oCccmVxdWly ZW1lbnTigJ0gaGVyZS4gQnV0IHRoZSBpc3N1ZSBJIHJhaXNlZCBjYW4gYmUgc3VtbWFyaXplZCBh cyBmb2xsb3dzOg0KDQrigJzigJ3igJ0NClRoZSBhc3N1bXB0aW9uIG9mIGEgMToxIG1hcHBpbmcg aWdub3JlcyBzaXR1YXRpb25zIHdoZXJlIGEgY2hhbmdlIHRvIGFuIGludGVuZGVkIGNvbmZpZ3Vy YXRpb24gbGVhZiB2YWx1ZSBtYXkgcmVzdWx0IGluIHNldmVyYWwgaW5zdGFuY2VzIG9mIGFwcGxp ZWQgY29uZmlndXJhdGlvbiBsZWFmIHZhbHVlcyAob3BlcmF0aW9uYWwgc3RhdGUpIHRvIGJlIHVw ZGF0ZWQgaW4gdGhlIGJhY2tlbmQgZnJhbWV3b3JrIGFjcm9zcyBzZXZlcmFsIHN1YnN5c3RlbXMu DQrigJzigJ0iDQoNCiBNeSBpc3N1ZSBpcyB0aGF0IHRoZSByZXF1aXJlbWVudCBzZWVtcyB0byBp Z25vcmUgdGhlIHNpdHVhdGlvbnMgYW5kIG15IHN1Z2dlc3Rpb24gaXMgdG8gcmVsYXggdGhlIHJl cXVpcmVtZW50Lg0KDQogSSBkb27igJl0IGJlbGlldmUgMS5DIGFkZHJlc3NlcyB0aGUgYWN0dWFs IGNvbmNlcm4gd2l0aCB0aGUgcmVxdWlyZW1lbnQuDQoNCj4gT24gT2N0IDE0LCAyMDE1LCBhdCA4 OjE0IFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiAN Cj4gSSBiZWxpZXZlIHRoYXQgeW91IGFyZSBjb3JyZWN0LCBpdCBzZWVtcyB0aGF0IHdlJ3ZlIGRv dWJsZWQtZG93biBvbiAxQyBhbmQgc28gIzUgc2hvdWxkIG5vdyBiZSBtYXJrZWQgYXMgREVBRC4N Cj4gDQo+IFRoaXMgYWN0aW9uIHdpbGwgYmUgdGFrZW4gaWYgbm8gb2JqZWN0aW9uIGlzIG1hZGUg YmVmb3JlIHRvbW9ycm93J3MgaW50ZXJpbS4NCj4gDQo+IFRoYW5rcywNCj4gS2VudA0KPiANCj4g DQo+IEZyb206IFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPg0KPiBEYXRlOiBUdWVz ZGF5LCBPY3RvYmVyIDEzLCAyMDE1IGF0IDk6MjkgQU0NCj4gVG86IEtlbnQgV2F0c2VuIDxrd2F0 c2VuQGp1bmlwZXIubmV0PiwgIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NCj4g U3ViamVjdDogUmU6IFtuZXRtb2RdIG9wc3RhdGUtcmVxcyAjNTogU3VwcG9ydCBmb3Igc2l0dWF0 aW9ucyB3aGVuIHN0cnVjdHVyZSBvZiBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGlzIG5vdCB0aGUg c2FtZSBhcyBhcHBsaWVkDQo+IA0KPiBGcm9tIHRoZSBpbnRlcmltIG1lZXRpbmcgdHdvIHdlZWtz IGFnbywgaXQgd2FzIGNsYXJpZmllZCB0aGF0IHRoZSBzY2hlbWEgb2YgdGhlIGludGVuZGVkIGNv bmZpZ3VyYXRpb24gbm9kZXMgYXJlIGV4cGVjdGVkIHRvIGJlIHRoZSBzYW1lIGFzIHRoZSBzY2hl bWEgb2YgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBub2RlcyBzbyB0aGF0IGNsaWVudHMgY2Fu IGVhc2lseSByZWxhdGUgYmV0d2VlbiB0aGUgdHdvLg0KPiANCj4gSSB0aGluayB0aGF0IHRoZSBy ZXF1aXJlbWVudCB0ZXh0IGZvciAxLkMgYW5kIHRoZSBwcm9wb3NlZCB1cGRhdGVkIHRleHQgZm9y IDEuRCBtYWtlcyB0aGlzIHJlYXNvbmFibGUgY2xlYXIuDQo+IA0KPiBIZW5jZSwgaXMgaXNzdWUg NSBub3cgYXQgdGhlIHN0YXRlIHdoZXJlIGlzIGNhbiBiZSBjbG9zZWQgYXMgbm90IGJlaW5nIGEg cmVxdWlyZW1lbnQ/ICBPciBpcyB0aGVyZSBzb21ldGhpbmcgZnVydGhlciB0aGF0IG5lZWRzIHRv IGJlIGRpc2N1c3NlZCBmaXJzdD8NCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4gT24g MzAvMDkvMjAxNSAxNjo0NCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+PiANCj4+IEl0J3MgdGltZSB0 byB0YWNrbGUgYW5vdGhlciBpc3N1ZSwganVzdCBiZWZvcmUgdG9tb3Jyb3cncyBtZWV0aW5nLCBh bmQgdGhpcyB0aW1lIEknbSBwaWNraW5nIGEgaGFyZCBvbmU6DQo+PiANCj4+IGh0dHBzOi8vZ2l0 aHViLmNvbS9uZXRtb2Qtd2cvb3BzdGF0ZS1yZXFzL2lzc3Vlcy81DQo+PiANCj4+IEFscmVhZHkg Q2FybCwgTWFoZXNoLCBFaW5hciwgYW5kIEFuZHkgaGF2ZSBwb3N0ZWQgMTggY29tbWVudHMgb24g dGhlIEdpdEh1YiBpc3N1ZSB0cmFja2VyLiAgICBQbGVhc2UgZmlyc3QgcmVhZCB0aGUgY29tbWVu dHMgcG9zdGVkIHRoZXJlIGFuZCB0aGVuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGhlcmUgb24g dGhlIG1haWxpbmcgbGlzdCAobm90IG9uIHRoZSBHaXRIdWIgaXNzdWUgdHJhY2tlcikuDQo+PiAN Cj4+IE5vdGUgdGhhdCB0aGlzIGlzc3VlIGlzIGNsb3NlbHkgdGllZCB0byB0aGUgZGVmaW5pdGlv biBvZiAiYXBwbGllZCBjb25maWd1cmF0aW9uIiwgd2hpY2ggaXMgZXhhY3RseSB3aGF0IGlzc3Vl ICM0IHJlZ2FyZHMgKGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvb3BzdGF0ZS1yZXFzL2lz c3Vlcy80KSwgZm9yIHdoaWNoIE1haGVzaCBhbmQgRWluYXIgaGF2ZSBwb3N0ZWQgY29tbWVudHMg b24gYWxyZWFkeS4gICBBcyB0aGVzZSB0d28gaXNzdWVzICgjNCBhbmQgIzUpIGFyZSBzbyBoaWdo bHkgcmVsYXRlZCwgSSdtIGdvaW5nIHRvIHNpbXVsdGFuZW91c2x5IG9wZW4gdGhlIG90aGVyIGlz c3VlIGZvciBkaXNjdXNzaW9uIG5vdyBhcyB3ZWxsLg0KPj4gDQo+PiBUaGFua3MsDQo+PiBLZW50 DQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gDQo+PiBuZXRtb2RAaWV0Zi5v cmdodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Thu Oct 15 06:17:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2EA1ACD25 for ; Thu, 15 Oct 2015 06:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y86_JOkG0DT9 for ; Thu, 15 Oct 2015 06:17:35 -0700 (PDT) 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 7EE921B318D for ; Thu, 15 Oct 2015 06:17:34 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-5c-561fa76c19e3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.88.05274.C67AF165; Thu, 15 Oct 2015 15:17:32 +0200 (CEST) Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 15:17:32 +0200 To: Ladislav Lhotka References: <561F9509.4060008@ericsson.com> <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz> From: Balazs Lengyel Message-ID: <561FA76B.5040401@ericsson.com> Date: Thu, 15 Oct 2015 15:17:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+JvjW7Ocvkwgyu/DSwurJrLZjH/YiOr A5PHkiU/mTw2Xb7DGMAUxWWTkpqTWZZapG+XwJWxadds1oJ/0hVPujpYGhifiHQxcnJICJhI 9K/cyQJhi0lcuLeerYuRi0NI4CijxI7LzVDOWkaJ7Z8usYNUCQtoSSz72AnWISKgLHFxwk8w W0ggWuLuj+1gNrOAusSdU4/ZQGw2ASOJqf3nweK8AtoSP/dcAbI5OFgEVCVWb5ADCYsKxEi8 37SKEaJEUOLkzCdg5ZwCVhJ/u/eBlTML2Es82FoGMV1eYvvbOcwQWzUkHl74yzqBUXAWku5Z CB2zkHQsYGRexShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYqge3/FbdwXj5jeMhRgEORiUe 3gUc8mFCrIllxZW5hxilOViUxHmbmR6ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsVPPM bnZJt7ZPenct1c560jye84fm/WF9ZLz1QvSqFWc/Zi3N9+nRFPD/KLPjYvN2h0M1Uxw+bPZN ub/E4ITUG/+5z0RUgi1PVhimbWPQn2SmECwbpcHoZ3a+jf96jFJGkaVTKLv1Wb/7X+8+Su7l k1MuFe31PnKahTf0gOkLB60PLWYql5VYijMSDbWYi4oTAWDvKVk2AgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:17:36 -0000 Hello Lada, So can we start gathering support for limiting when/choice to the simple cases by one of the 3 methods: 1) prohibit them (backward incompatible) 2) create a guideline not to use them in 6087, (easy to do, better then nothing, but does not protect the application) 3) declaring them as implementation dependent, thus making them backward compatible, but unusable Complicated: In my view anytime a when or choice depends on another when or choice it is complicated. So use the simple cases only. regards Balazs On 2015-10-15 14:53, Ladislav Lhotka wrote: > Hi Balazs, > > one lesson taken from early XML schema languages (DTD) was that modifying the validated document during validation easily leads to nasty race conditions. That's why RELAX NG avoids changing the XML infoset like plague. > > I've already got tired reiterating (and providing examples) that "when" statement is inherently broken - the schema should not depend on evaluating arbitrary expressions in the context of an instance document that is supposed to be validated with the schema. The standard disclaimer is that it works for simple cases, and more complicated corner cases are "garbage in - garbage out". > > Lada > > P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its content is "false". So you'd need expressions like "not(../a2 = 'true')". > >> On 15 Oct 2015, at 13:59, Balazs Lengyel wrote: >> >> Hello, >> In RFC6020bis we write: >> "There MUST NOT be any circular dependencies in these "when" expressions." >> How about a circular when-choice loop? >> >> leaf a1 { >> type boolean; >> when not(../a2); >> } >> choice c2 { >> default case2; >> case case1 { >> when not(a1); >> leaf b1 {type int8;} >> } >> case case2 { >> leaf a2 { >> type boolean; >> default true; >> } >> } >> } >> >> Initial state: a1=false, b1=5; >> - Set a1=true >> - case1 and b1 disapears >> - case2 and a2=false are set as default >> - a1 disappears >> - if there is no a1 why did we delete case1/b1? >> Did I miss something, is this really what happens? >> >> Even if someone can come up with the correct solution, operators will be 100% sure to mess this up. Usability=0 !!! >> >> I want some of this multistep when/when, choice/choice, when/choice scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation is implementation dependent: that would make it unusable, so practically prohibiting then while maintaining backward compatibility :-) >> >> I attached an even more complicated example, so go ahead have fun understand it! >> regards Balazs >> >> PS: Why did we make YANG so complicated? >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Oct 15 06:42:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDADC1B321B for ; Thu, 15 Oct 2015 06:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A65nCWZj2cED for ; Thu, 15 Oct 2015 06:42:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4581B31F1 for ; Thu, 15 Oct 2015 06:42:04 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PR05MB036.namprd05.prod.outlook.com (10.255.228.155) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 13:42:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 13:42:01 +0000 From: Kent Watsen To: Gert Grammel , Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAA///FuYA= Date: Thu, 15 Oct 2015 13:42:01 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; BL2PR05MB036; 5:SpQmnr3CgOKQHks6SSJVmTqB5tK1a4VH4KeucvCrS1tOPTpFS4yiYPqWjciLXla2etjFrVZgh1iKknSQAcv6fgzZqA98eahhtpqTvVTQKoBNZ4cRarHQsCPL0IH7+VIhKS+eDIq3NTub2asVuRIgpQ==; 24:W0zOw+ufcSVXbJzN4HUHQNJz5daT0iiSz6ReA3j6IO5aEbuhHpGfBt3D4Jd3Mg7HEaB3vZkxiyfKd9a4kKeqpYbLVY7A5mA8j3wF+q22crw=; 20:JEAXnezw60OXZXxPZIopq0s3196sGhTQ+pP6raZScGhlRvEpQWFvzV0Y0ud7oWWdqEPmYN/rLGmD3bv4arZSng== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BL2PR05MB036; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB036; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(479174004)(52314003)(51444003)(164054003)(189002)(76104003)(53754006)(199003)(377454003)(505384003)(24454002)(561944003)(50986999)(5002640100001)(19617315012)(46102003)(76176999)(11100500001)(16236675004)(64706001)(102836002)(5008740100001)(36756003)(5004730100002)(2900100001)(5007970100001)(2950100001)(2501003)(92566002)(107886002)(106356001)(86362001)(93886004)(15975445007)(106116001)(101416001)(5001770100001)(5001960100002)(4001350100001)(97736004)(87936001)(122556002)(83506001)(66066001)(105586002)(54356999)(99286002)(189998001)(1941001)(40100003)(19580405001)(19580395003)(81156007)(10400500002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB036; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D2452533E72B1kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 13:42:01.0514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB036 Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:42:17 -0000 --_000_D2452533E72B1kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Gert. I've incorporated these suggestions into my notes for today's= interim meeting. From: Gert Grammel > Date: Thursday, October 15, 2015 at 7:17 AM To: Kent Watsen >, Robert W= ilton >, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn=92t look= complete. The way it stands for the synchronous operation, the client know= s that it's intended config was good AND it has been effected to the server= . In the Asynchronous case, the client only knows that the intended config = was good =96 and that=92s not enough. So the proposal is to refine the asynchronous case definition as follows: Asynchronous configuration operation - A configuration request to update th= e running configuration of a server that is applied asynchronously with res= pect to the client request. The server MUST update its intended configurat= ion (see term) before replying to the client indicating whether the request= will be processed. The reply to the client only indicates whether there a= re any errors in the original request. The server's applied configuration state (see term) is updated after the co= nfiguration change has been applied to all impacted components in the serve= r. Once applied, the client MUST be notified whether the intended config i= s now fully effective or there are any errors from applying the configurati= on change. In addition I would suggest to require a verify operation which a client ca= n request from the server to obtain above information on an on-demand basis= . Would that somehow go in the opstate-reqs #3 then? Best Gert From: netmod > on b= ehalf of Kent Watsen > Date: Thursday 15 October 2015 00:11 To: Robert Wilton >, "netmod@ie= tf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Robert, One comment, it seems that the asynchronous configuration operation should have one more sentence at its end saying that an asynchronous notification must be used to report any errors produced from when applying the configuration. What do you think? Kent // as a contributor On 10/14/15, 10:59 AM, "Robert Wilton" > wrote: Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... Works for me. Sometimes less is more. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Depends on the definition of applied configuration - where is the latest version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D2452533E72B1kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E6F2D521FE45542B1529582887C23C4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Thanks Gert.  I've incorporated these suggestions into my notes f= or today's interim meeting.


From: Gert Grammel <ggrammel@juniper.net>
Date: Thursday, October 15, 2015 at= 7:17 AM
To: Kent Watsen <kwatsen@juniper.net>, Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn=92t= look complete. The way it stands for the synchronous operation, the client= knows that it's intended config was good AND it has been effected to the s= erver. In the Asynchronous case, the client only knows that the intended config was good =96 and that=92s not e= nough.

So the proposal is to refine the asynchronous case definition as follo= ws:

Asynchronous configuration operation - A configuration request to upda= te the running configuration of a server that is applied asynchronously wit= h respect to the client request.  The server MUST update its inte= nded configuration (see term) before replying to the client indicating whether the request will be processed.  The = reply to the client only indicates whether there are any errors in the &nbs= p;original request.
The server's applied configuration state (see term) is updated after t= he configuration change has been applied to all impacted components in the = server.  Once applied, the client MUST be notified whether the intende= d config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a clie= nt can request from the server to obtain above information on an on-demand = basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@ietf.org> on behalf of Kent = Watsen <kwatsen@juniper.net&g= t;
Date: Thursday 15 October 2015 00:1= 1
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation sh= ould
have one more sentence at its end saying that an asynchronous notifica= tion
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or=
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to updat= e
the running configuration of a server that is applied synchronously wi= th
respect to the client request.  The server MUST fully effect= the
configuration change to all impacted components in the server, updatin= g
both the server's intended and applied configuration (see terms), befo= re
replying to the client.  The reply to the client indicates w= hether there
are any errors in the request or errors from applying the configuratio= n
change.

Asynchronous configuration operation - A configuration request to upda= te
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update = its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied=
configuration state (see term) is updated after the configuration chan= ge
has been fully effected to all impacted components in the server. = ; The
reply to the client only indicates whether there are any errors in the=
original request.

Synchronous configuration server - a configuration server that process= es
all configuration operations as synchronous configuration operations.<= /div>

Asynchronous configuration server - a configuration server that proces= ses
all configuration operations as asynchronous configuration operations.=

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure tha= t the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.<= /div>
The reply to the client indicates whether there are any errors in the<= /div>
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RF= C 6020
says:

     When datastore processing is complete, the fi= nal contents MUST
obey
     all validation constraints.  This v= alidation processing is
performed
     at differing times according to the datastore= .  If the datastore
is
     <running/> or <startup/>, these c= onstraints MUST be enforced at
the
     end of the <edit-config> or <copy-co= nfig> operation.  If the
     datastore is <candidate/>, the constrai= nt enforcement is delayed
     until a <commit> or <validate> op= eration.

Are we talking about datastore validation or validation of a request?<= /div>
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validat= e"
would exclude an ephemeral datastore, so I was trying to water down th= e
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration s= erver that processes
    some configuration operations as synchronous c= onfiguration
    operations and some configuration operations a= s asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy=
that in real systems, depending on the data model, certain parts of a<= /div>
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration= - this data represents the configuration
        state that the network= operator intends the system to be in, and
that
        has been accepted by t= he system as valid configuration.  This
data is
        colloquially referred = to as the 'configuration' of the system.

       applied configuration - this data= represents the configuration
        state that the network= element is actually in, i.e., the
        configuration state wh= ich is currently being being used by
system
        components (e.g., cont= rol plane daemons, operating system
        kernels, line cards).<= /div>
Well, sometimes the config goes to a control plane daemon and then to<= /div>
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that= the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if = that means
that the definition of applied configuration should be strengthened, o= r
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from<= /div>
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to<= /div>
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended=
config and then report the result of the guess work as applied config<= /div>
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price=
for this applied config idea, I have no real problem with this since I=
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list

--_000_D2452533E72B1kwatsenjunipernet_-- From nobody Thu Oct 15 06:53:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9432F1B31FA for ; Thu, 15 Oct 2015 06:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb8Hmif9KoVP for ; Thu, 15 Oct 2015 06:53:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8403C1B31E5 for ; Thu, 15 Oct 2015 06:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3857; q=dns/txt; s=iport; t=1444917231; x=1446126831; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=h1DPojSlkaJ86ovDH20el/4NtxGEvrd6WiXC5lPwSkU=; b=D38WkwR+v2PLF5BOt9PzYyXIRLIAEM26G+hxXbuSYLmK3pImwdqPxWgu JkEg5NUOEYizs2k535Wdwvp51umAvBWDy6PMgErr2N72MusXJYsKQWRnr KigTfsN15U4kZDM9D+thrhVQ5+FaJOazsFsfA7NuSdAJFlsbbF+Ukxx9W 4=; X-IronPort-AV: E=Sophos;i="5.17,685,1437436800"; d="scan'208";a="630346336" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Oct 2015 13:53:50 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9FDrmFb031413; Thu, 15 Oct 2015 13:53:48 GMT To: "Carl Moberg (camoberg)" , Kent Watsen References: <561D0724.1030602@cisco.com> <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> From: Robert Wilton Message-ID: <561FAFDE.4020007@cisco.com> Date: Thu, 15 Oct 2015 14:53:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:53:57 -0000 Hi Carl, On 15/10/2015 14:05, Carl Moberg (camoberg) wrote: > Maybe we’re coming down to a definition of “requirement” here. But the issue I raised can be summarized as follows: > > “”” > The assumption of a 1:1 mapping ignores situations where a change to an intended configuration leaf value may result in several instances of applied configuration leaf values (operational state) to be updated in the backend framework across several subsystems. > “”" > > My issue is that the requirement seems to ignore the situations and my suggestion is to relax the requirement. I think that the operator requirement is stating that the multiple actual applied configuration leaves across multiple subsystems need to be mapped back to a single logical leaf for the purposes of the applied config leaf that is exposed to the operators. If no such mapping is possible then this would imply that there is no way that the operator can determine whether a particular item of configuration is actually in effect on a system. Is this reasonable behaviour for a system? If such a mapping is possible, then I can see benefit in performing such a mapping on the device itself rather than requiring each and every operator to know and program the mapping. Is the main concern here that the cost of implementing this mapping in the system may be prohibitively expensive? Thanks, Rob > > I don’t believe 1.C addresses the actual concern with the requirement. > >> On Oct 14, 2015, at 8:14 PM, Kent Watsen wrote: >> >> >> I believe that you are correct, it seems that we've doubled-down on 1C and so #5 should now be marked as DEAD. >> >> This action will be taken if no objection is made before tomorrow's interim. >> >> Thanks, >> Kent >> >> >> From: Robert Wilton >> Date: Tuesday, October 13, 2015 at 9:29 AM >> To: Kent Watsen , "netmod@ietf.org" >> Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied >> >> From the interim meeting two weeks ago, it was clarified that the schema of the intended configuration nodes are expected to be the same as the schema of the applied configuration nodes so that clients can easily relate between the two. >> >> I think that the requirement text for 1.C and the proposed updated text for 1.D makes this reasonable clear. >> >> Hence, is issue 5 now at the state where is can be closed as not being a requirement? Or is there something further that needs to be discussed first? >> >> Thanks, >> Rob >> >> >> On 30/09/2015 16:44, Kent Watsen wrote: >>> It's time to tackle another issue, just before tomorrow's meeting, and this time I'm picking a hard one: >>> >>> https://github.com/netmod-wg/opstate-reqs/issues/5 >>> >>> Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub issue tracker. Please first read the comments posted there and then continue the discussion here on the mailing list (not on the GitHub issue tracker). >>> >>> Note that this issue is closely tied to the definition of "applied configuration", which is exactly what issue #4 regards (https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh and Einar have posted comments on already. As these two issues (#4 and #5) are so highly related, I'm going to simultaneously open the other issue for discussion now as well. >>> >>> Thanks, >>> Kent >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> >>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 15 06:54:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362301B31E5 for ; Thu, 15 Oct 2015 06:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX5Vvx88QANZ for ; Thu, 15 Oct 2015 06:54:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E481B3227 for ; Thu, 15 Oct 2015 06:54:01 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 13:53:53 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 13:53:53 +0000 From: Kent Watsen To: "Carl Moberg (camoberg)" Thread-Topic: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied Thread-Index: AQHQ+5bVY+r8w1658UewPXEWKgfK555pfxgAgAGe5gCAAX82AP//ymcA Date: Thu, 15 Oct 2015 13:53:52 +0000 Message-ID: References: <561D0724.1030602@cisco.com> <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> In-Reply-To: <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:3kfmfOX5ArfDu9QIR1Ni0M/n+tEoXoC9vWwqXbOxJ5GsU4oU7ce1QVkFLZlkesIidWaE2wnjK15FctGP2NW1CNs9kddVo3t+mUiMUw7ddaSx7sbk6myoutlZd6zXjmVe1BmXF1aiuA2Pn26eIX5sRA==; 24:G39S5iFXyEOHrmlFQNoLVPfHrrdkttXHUsPK2AHh9sDwJYGgyP+uhmbEWuIJigC8DRyjraIF0Ff6rru8m3a3xsmGSrEUXtjyGwbETR9GXo0=; 20:mRRvDBcIbmsLbNmQSrlG3NzfmmGxYvGcL4A01jBN1HWYNGoEeT6QuUb6TxaR+vKUIx/G9b3Ds7Xg1tWMEILPBA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(76104003)(51444003)(479174004)(199003)(377454003)(24454002)(97736004)(19580405001)(189998001)(86362001)(19580395003)(101416001)(76176999)(54356999)(87936001)(83506001)(66066001)(36756003)(4001350100001)(122556002)(40100003)(99286002)(81156007)(64706001)(106116001)(5008740100001)(106356001)(15975445007)(10400500002)(5004730100002)(102836002)(5001960100002)(2900100001)(105586002)(50986999)(2950100001)(46102003)(92566002)(5002640100001)(93886004)(110136002)(5007970100001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <79C8B563C50F004890E158818C9BA1AA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 13:53:52.9708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:54:06 -0000 Hi Carl, I understand your concern, but isn't it up to the server to decide the response it provides in that case? Already I think the server needs to scatter/gather responses from the operational components in the system and stitch together a result. In this case, the stitching may fail and hence it reports an error of some sort (e.g., not-completely-applied) - what do you think? Kent On 10/15/15, 9:05 AM, "Carl Moberg (camoberg)" wrote: > > Maybe we=B9re coming down to a definition of =B3requirement=B2 here. But = the >issue I raised can be summarized as follows: > >=B3=B2=B2 >The assumption of a 1:1 mapping ignores situations where a change to an >intended configuration leaf value may result in several instances of >applied configuration leaf values (operational state) to be updated in >the backend framework across several subsystems. >=B3=B2" > > My issue is that the requirement seems to ignore the situations and my >suggestion is to relax the requirement. > > I don=B9t believe 1.C addresses the actual concern with the requirement. > >> On Oct 14, 2015, at 8:14 PM, Kent Watsen wrote: >>=20 >>=20 >> I believe that you are correct, it seems that we've doubled-down on 1C >>and so #5 should now be marked as DEAD. >>=20 >> This action will be taken if no objection is made before tomorrow's >>interim. >>=20 >> Thanks, >> Kent >>=20 >>=20 >> From: Robert Wilton >> Date: Tuesday, October 13, 2015 at 9:29 AM >> To: Kent Watsen , "netmod@ietf.org" >> >> Subject: Re: [netmod] opstate-reqs #5: Support for situations when >>structure of intended configuration is not the same as applied >>=20 >> From the interim meeting two weeks ago, it was clarified that the >>schema of the intended configuration nodes are expected to be the same >>as the schema of the applied configuration nodes so that clients can >>easily relate between the two. >>=20 >> I think that the requirement text for 1.C and the proposed updated text >>for 1.D makes this reasonable clear. >>=20 >> Hence, is issue 5 now at the state where is can be closed as not being >>a requirement? Or is there something further that needs to be discussed >>first? >>=20 >> Thanks, >> Rob >>=20 >>=20 >> On 30/09/2015 16:44, Kent Watsen wrote: >>>=20 >>> It's time to tackle another issue, just before tomorrow's meeting, and >>>this time I'm picking a hard one: >>>=20 >>> https://github.com/netmod-wg/opstate-reqs/issues/5 >>>=20 >>> Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the >>>GitHub issue tracker. Please first read the comments posted there >>>and then continue the discussion here on the mailing list (not on the >>>GitHub issue tracker). >>>=20 >>> Note that this issue is closely tied to the definition of "applied >>>configuration", which is exactly what issue #4 regards >>>(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh >>>and Einar have posted comments on already. As these two issues (#4 >>>and #5) are so highly related, I'm going to simultaneously open the >>>other issue for discussion now as well. >>>=20 >>> Thanks, >>> Kent >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>>=20 >>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Oct 15 07:00:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F801B3249 for ; Thu, 15 Oct 2015 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsE0MS3acdQj for ; Thu, 15 Oct 2015 06:59:55 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107111B3247 for ; Thu, 15 Oct 2015 06:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38820; q=dns/txt; s=iport; t=1444917594; x=1446127194; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=4JFZ+TBNQeBy52VcqBGE7sFRwN6iD3Et4tmqhvfPnzY=; b=f+Hjm9Vp+5Mj8+sI/BX2mIhI2cghP+rZA4J2NNXX/kq9eEDNwGB3NjNp sXpdGJitpsJjYnPhqDf8vM91Ji7m5ksBHEjgJDSvWEvgH0WvjWVHZvrgD v+YfXj+ctsX/JadlVo0Aam9bgvl/VDu8GLQWydRhJY7vW8iXA+XFLNCvk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMAQBKsB9W/xbLJq1eglmBIW69PQENgVYDFwEJhTFKAoFpFAEBAQEBAQGBCoQmAQEBBAEBARdUGwsOAwMBAgEJFwECBAcPAhYfCQgGAQwGAgEBiCoNwyEBAQEBAQEBAQIBAQEBAQEBARYEhnaDeIEGhEI6GIQuBZJWg0WICYUSgViHO4o0iEgfAQFCghEdFoFAPTOEICWBIgEBAQ X-IronPort-AV: E=Sophos;i="5.17,685,1437436800"; d="scan'208,217";a="612233771" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 15 Oct 2015 13:59:51 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9FDxpOa000408; Thu, 15 Oct 2015 13:59:51 GMT To: Gert Grammel , Kent Watsen , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> From: Robert Wilton Message-ID: <561FB149.103@cisco.com> Date: Thu, 15 Oct 2015 14:59:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000905070503060309090404" Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:59:59 -0000 This is a multi-part message in MIME format. --------------000905070503060309090404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Gert, Kent, I think that notifying the client is one possible way that an asynchronous request could be completed, but not necessarily the only way. E.g. if the information as to whether a particular intended leave had been successfully applied was available (e.g. as per github issue #2). So, I wonder whether we shouldn't weaken the last sentence, changing MUST to COULD, or perhaps reword it.: E.g. replacing: Once applied, the client MUST be notified whether the intended config is now fully effective or there are any errors from applying the configuration change. Perhaps with: Once applied, the client COULD be notified whether the intended config is now fully effective or there are any errors from applying the configuration change. Or: Once applied, there MUST be a mechanism available for the client to be able to determine whether the intended config is now fully effective or whether there are any errors from applying the configuration change. Thanks, Rob On 15/10/2015 12:17, Gert Grammel wrote: > Kent, Rob, > > Comparing the cases, the definition of the asynchronous case doesn’t > look complete. The way it stands for the synchronous operation, the > client knows that it's intended config was good AND it has been > effected to the server. In the Asynchronous case, the client only > knows that the intended config was good – and that’s not enough. > > So the proposal is to refine the asynchronous case definition as follows: > > Asynchronous configuration operation - A configuration request to > update the running configuration of a server that is applied > asynchronously with respect to the client request. The server MUST > update its intended configuration (see term) before replying to the > client indicating whether the request will be processed. The reply to > the client only indicates whether there are any errors in the > original request. > The server's applied configuration state (see term) is updated after > the configuration change has been applied to all impacted components > in the server. Once applied, the client MUST be notified whether the > intended config is now fully effective or there are any errors from > applying the configuration change. > > In addition I would suggest to require a verify operation which a > client can request from the server to obtain above information on an > on-demand basis. Would that somehow go in the opstate-reqs #3 then? > > Best > > Gert > > > > > From: netmod > on behalf of Kent Watsen > > > Date: Thursday 15 October 2015 00:11 > To: Robert Wilton >, > "netmod@ietf.org " > > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous > vs asynchronous (esp. wrt intended and applied) > > Hi Robert, > > One comment, it seems that the asynchronous configuration operation should > have one more sentence at its end saying that an asynchronous notification > must be used to report any errors produced from when applying the > configuration. > > What do you think? > > Kent // as a contributor > > > > On 10/14/15, 10:59 AM, "Robert Wilton" > wrote: > > Hi All, > > Are there any more comments on the following proposed descriptions, or > are these descriptions sufficiently clear to update the requirements > draft and resolve issue #6? > > Synchronous configuration operation - A configuration request to > update > the running configuration of a server that is applied > synchronously with > respect to the client request. The server MUST fully effect the > configuration change to all impacted components in the server, > updating > both the server's intended and applied configuration (see terms), > before > replying to the client. The reply to the client indicates whether > there > are any errors in the request or errors from applying the > configuration > change. > > Asynchronous configuration operation - A configuration request to > update > the running configuration of a server that is applied asynchronously > with respect to the client request. The server MUST update its > intended > configuration (see term) before replying to the client indicating > whether the request will be processed. The server's applied > configuration state (see term) is updated after the configuration > change > has been fully effected to all impacted components in the server. The > reply to the client only indicates whether there are any errors in the > original request. > > Synchronous configuration server - a configuration server that > processes > all configuration operations as synchronous configuration operations. > > Asynchronous configuration server - a configuration server that > processes > all configuration operations as asynchronous configuration operations. > > Thanks, > Rob > > > On 13/10/2015 09:48, Juergen Schoenwaelder wrote: > > On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: > > Hi Juergen, > > On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > > On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert > Wilton wrote: > > Hi Kent, > > Feeding in the various input, I think that this is > the best > refinement > that I've come up with: > > Synchronous configuration operation - A > configuration request to > update > the running configuration of a server that is > applied synchronously > with > respect to the client request. The server SHOULD > ensure that the > request is valid, and MUST fully effect the > configuration change to > all > impacted components in the server, updating both > the server's > intended > and applied configuration (see terms), before > replying to the client. > The reply to the client indicates whether there > are any errors in the > request or errors from applying the configuration > change. > > What does "SHOULD ensure that the request is valid" > mean? RFC 6020 > says: > > When datastore processing is complete, the final > contents MUST > obey > all validation constraints. This validation > processing is > performed > at differing times according to the > datastore. If the datastore > is > or , these constraints MUST > be enforced at > the > end of the or > operation. If the > datastore is , the constraint > enforcement is delayed > until a or operation. > > Are we talking about datastore validation or > validation of a request? > If the former, are we watering down a MUST to a SHOULD? > > Really it is datastore validation, particularly for an > async request > where the intended config nodes are updated before > replying. I'm not > intentionally trying to water down a MUST to a SHOULD, but > Kent had > concerns that my previous description using "semantically > validate" > would exclude an ephemeral datastore, so I was trying to > water down the > description and also describe the behaviour in a way that > isn't > specific > to either RESTCONF/NETCONF or datastores. > > Perhaps, the start of sentence could simply be changed to: > > The server MUST fully effect the configuration change to all > impacted components in the server ... > > And equivalently for the asynchronous case below: > > The server MUST update the server's intended configuration ... > > Works for me. Sometimes less is more. > > And I would not be surprised if we also need this > sooner or later: > > Mixed configuration server - a configuration > server that processes > some configuration operations as synchronous > configuration > operations and some configuration operations as > asynchronous > configuration operations. > > Yes, I would expect that clients may want to define the > expected > behaviour, potentially on a per request basis. > > I doubt that servers will offer clients to choose; I am more > with Andy > that in real systems, depending on the data model, certain > parts of a > data model may be synchronous while others may be asynchronous. > > Any further comments? > > Based on the feedback from Andy and others, it > seems that the > prevailing > view is that existing NETCONF and RESTCONF should > be regarded as > being > asynchronous in their behaviour in that the config > nodes in the > running > datastore only represent the intended > configuration and not the > applied > configuration. > > Depends on the definition of applied configuration - > where is the > latest > version of it? > > The last proposed text for intended/applied is as below: > > intended configuration - this data represents the > configuration > state that the network operator intends the system > to be in, and > that > has been accepted by the system as valid > configuration. This > data is > colloquially referred to as the 'configuration' of > the system. > > applied configuration - this data represents the > configuration > state that the network element is actually in, > i.e., the > configuration state which is currently being being > used by > system > components (e.g., control plane daemons, operating > system > kernels, line cards). > > Well, sometimes the config goes to a control plane daemon and > then to > the OS kernel and finally to the line cards. This definition > leaves > some room what an applied configuration is (which is IMHO > needed if > you want to have something implementable) and hence a NC > server can > either be considered synchronous or asynchronous. > > From Thursday's interim meeting, Rob Shakir clarified > that the desired > intention is that applied configuration should mean that the > configuration is fully applied everywhere. I don't know > if that means > that the definition of applied configuration should be > strengthened, or > if it is sufficient? > > As said before, an OS kernel usually does not track where resource > parameters were coming from. (An interface has a set of IP > addresses > and the kernel usually does not know which addresses were > coming from > a configuration daemon, a dhcp daemon, a tunneling daemon, a > command > line utility, ...) The same may be true for line card. So in > order to > implement a very tight definition, one has to either 'guess' which > 'subset' of operational state can be related 'somehow' to the > intended > config and then report the result of the guess work as applied > config > or one would have to to change daemons/kernels/linecards to have a > tracking number or something like that. > > Anyway, as long as a regular NC/RC server does not have to pay > a price > for this applied config idea, I have no real problem with this > since I > am sure the market will sort this out. > > /js > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------000905070503060309090404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous request could be completed, but not necessarily the only way.  E.g. if the information as to whether a particular intended leave had been successfully applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST to COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

Or:

Once applied, there MUST be a mechanism available for the client to be able to determine whether the intended config is now fully effective or whether there are any errors from applying the configuration change.

Thanks,
Rob


On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn’t look complete. The way it stands for the synchronous operation, the client knows that it's intended config was good AND it has been effected to the server. In the Asynchronous case, the client only knows that the intended config was good – and that’s not enough.

So the proposal is to refine the asynchronous case definition as follows:

Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request.  The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed.  The reply to the client only indicates whether there are any errors in the  original request.
The server's applied configuration state (see term) is updated after the configuration change has been applied to all impacted components in the server.  Once applied, the client MUST be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a client can request from the server to obtain above information on an on-demand basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Thursday 15 October 2015 00:11
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

     When datastore processing is complete, the final contents MUST
obey
     all validation constraints.  This validation processing is
performed
     at differing times according to the datastore.  If the datastore
is
     <running/> or <startup/>, these constraints MUST be enforced at
the
     end of the <edit-config> or <copy-config> operation.  If the
     datastore is <candidate/>, the constraint enforcement is delayed
     until a <commit> or <validate> operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validate"
would exclude an ephemeral datastore, so I was trying to water down the
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration server that processes
    some configuration operations as synchronous configuration
    operations and some configuration operations as asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration - this data represents the configuration
        state that the network operator intends the system to be in, and
that
        has been accepted by the system as valid configuration.  This
data is
        colloquially referred to as the 'configuration' of the system.

       applied configuration - this data represents the configuration
        state that the network element is actually in, i.e., the
        configuration state which is currently being being used by
system
        components (e.g., control plane daemons, operating system
        kernels, line cards).
Well, sometimes the config goes to a control plane daemon and then to
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if that means
that the definition of applied configuration should be strengthened, or
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended
config and then report the result of the guess work as applied config
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price
for this applied config idea, I have no real problem with this since I
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list

--------------000905070503060309090404-- From nobody Thu Oct 15 07:08:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3A1B3273 for ; Thu, 15 Oct 2015 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 4U5jEiYJ7IIH for ; Thu, 15 Oct 2015 07:08:21 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 B7A701B3272 for ; Thu, 15 Oct 2015 07:08:21 -0700 (PDT) Received: by pabrc13 with SMTP id rc13so89114310pab.0 for ; Thu, 15 Oct 2015 07:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=I/csfs7gtgGXFckzA0AdvonqHg1nHYVc/UXcAwkVZRs=; b=nzgatQDNrg9JGpiTncRp7byRc9TzunBKIxCLWPfDNCZhIyZge5Vag7EHqGL1Ibzj64 tGNx9jNAMs3xIZG9QW7vbifwXapQZpSQeNWWi2PEqam+9Fxn3ZNyUSYjQaEStERhiVbT jpqlzCYSiRWXZ+mtLhOwxBSIgfIyO87big7LMLXYE8ghiAmGlWWqEp+mVd0lr6eTaz5g tcWXo3Nu/ky23+K8b96deubyu/exms7XntBAL0duWeZywzXOWzzKr45ZbY0+ihUvI8wC xMMPean29jrITy0R1Nm60MMjsv+gzR34L5Rv1wrK9GylHu1pEfp8Y2AW6cX+UGikh/yg 7LfA== X-Received: by 10.68.174.193 with SMTP id bu1mr10223440pbc.136.1444918101440; Thu, 15 Oct 2015 07:08:21 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:39e8:94df:fd6b:e48c]) by smtp.gmail.com with ESMTPSA id yz3sm15738526pbb.37.2015.10.15.07.08.20 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Oct 2015 07:08:20 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_D19822EA-96BE-482F-9BCE-14CBD1892C54" Message-Id: <3F16937F-7C26-4046-BB00-B336E8FB40A2@gmail.com> Date: Thu, 15 Oct 2015 07:08:19 -0700 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [netmod] WebEx invitation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:08:23 -0000 --Apple-Mail=_D19822EA-96BE-482F-9BCE-14CBD1892C54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I seem to be missing the WebEx invitation for the Interim meeting for = today. Would someone care to forward. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_D19822EA-96BE-482F-9BCE-14CBD1892C54 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I seem to be missing the WebEx invitation for the Interim meeting for today. Would someone care to forward.

Thanks.

Mahesh Jethanandani





--Apple-Mail=_D19822EA-96BE-482F-9BCE-14CBD1892C54-- From nobody Thu Oct 15 07:08:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D840B1B3279 for ; Thu, 15 Oct 2015 07:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By47Jb_UaCep for ; Thu, 15 Oct 2015 07:08:46 -0700 (PDT) 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 B90A41B3278 for ; Thu, 15 Oct 2015 07:08:40 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 5D60F18182E; Thu, 15 Oct 2015 16:08:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444918119; bh=12rNxLnTJS06T954aYkMnhHW4FT4UedkZ4Aiuxiy1Zg=; h=From:Date:To; b=SGtbEqkt6nYCcZ0Bj/JJ6fb2xTyWiplJMLaOC2DGBuXbbmyOFMYyiTosXuarCP831 E4bpBVDyetQKZzbn1hKobHVTSI44ug1W2OK6eX9qcCBv4ZKyg5JR3AHZ0ElHzS2j6w pr6C4mREqDzehDtmI6agWjDDkm0qHu/T71lu+4Z8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <561FA76B.5040401@ericsson.com> Date: Thu, 15 Oct 2015 16:08:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561F9509.4060008@ericsson.com> <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz> <561FA76B.5040401@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:08:48 -0000 > On 15 Oct 2015, at 15:17, Balazs Lengyel = wrote: >=20 > Hello Lada, > So can we start gathering support for limiting when/choice to the = simple cases by one of the 3 methods: > 1) prohibit them (backward incompatible) I would personally restrict the use of "when" only as a substatement of = "augment". This would solve most issues, including Y18 (missing context = node). I other cases, "must" can be often used instead of "when" with = the same effect - at least for validation purposes. I am not sure that = benefits of "when" outweigh the complexity - both in YANG spec and = server implementation. I also think servers should not automatically delete nodes whose "when" = expression becomes false. Lada > 2) create a guideline not to use them in 6087, (easy to do, better = then nothing, but does not protect the application) > 3) declaring them as implementation dependent, thus making them = backward compatible, but unusable >=20 > Complicated: In my view anytime a when or choice depends on another = when or choice it is complicated. So use the simple cases only. > regards Balazs >=20 > On 2015-10-15 14:53, Ladislav Lhotka wrote: >> Hi Balazs, >>=20 >> one lesson taken from early XML schema languages (DTD) was that = modifying the validated document during validation easily leads to nasty = race conditions. That's why RELAX NG avoids changing the XML infoset = like plague. >>=20 >> I've already got tired reiterating (and providing examples) that = "when" statement is inherently broken - the schema should not depend on = evaluating arbitrary expressions in the context of an instance document = that is supposed to be validated with the schema. The standard = disclaimer is that it works for simple cases, and more complicated = corner cases are "garbage in - garbage out". >>=20 >> Lada >>=20 >> P.S. Note that XPath expressions like "not(../a2)" evaluate to false = if ../a2 exists, even if its content is "false". So you'd need = expressions like "not(../a2 =3D 'true')". >>=20 >>> On 15 Oct 2015, at 13:59, Balazs Lengyel = wrote: >>>=20 >>> Hello, >>> In RFC6020bis we write: >>> "There MUST NOT be any circular dependencies in these "when" = expressions." >>> How about a circular when-choice loop? >>>=20 >>> leaf a1 { >>> type boolean; >>> when not(../a2); >>> } >>> choice c2 { >>> default case2; >>> case case1 { >>> when not(a1); >>> leaf b1 {type int8;} >>> } >>> case case2 { >>> leaf a2 { >>> type boolean; >>> default true; >>> } >>> } >>> } >>>=20 >>> Initial state: a1=3Dfalse, b1=3D5; >>> - Set a1=3Dtrue >>> - case1 and b1 disapears >>> - case2 and a2=3Dfalse are set as default >>> - a1 disappears >>> - if there is no a1 why did we delete case1/b1? >>> Did I miss something, is this really what happens? >>>=20 >>> Even if someone can come up with the correct solution, operators = will be 100% sure to mess this up. Usability=3D0 !!! >>>=20 >>> I want some of this multistep when/when, choice/choice, when/choice = scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the = order of evaluation is implementation dependent: that would make it = unusable, so practically prohibiting then while maintaining backward = compatibility :-) >>>=20 >>> I attached an even more complicated example, so go ahead have fun = understand it! >>> regards Balazs >>>=20 >>> PS: Why did we make YANG so complicated? >>>=20 >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>=20 >>> = ____________________________________________= ___ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 15 07:12:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EA81B326D for ; Thu, 15 Oct 2015 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG5qq0maUK_B for ; Thu, 15 Oct 2015 07:12:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624FF1B3259 for ; Thu, 15 Oct 2015 07:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444918274; bh=jVJGqlECOQtVvdD7X06q0OOvHFxr/F9uPiZ497RR7NU=; h=From:Subject:Date:To; b=AcN+n5/6uMpLBeMjGAHrLR64BuIeZB9F9W1k7htIMxnhKz/Zm5AlhsVzs0IEMhzUX LNS8GCkKfVwZu3Z/UC6oJ6q0i1O99b/Dt2ZjcbtWxHTo0dQJbGt/c/G54v1D+3t86J XcPtYcz4R0o7kavD7LKW35RT4r4dnkzARciN0OIM= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> Date: Thu, 15 Oct 2015 10:12:52 -0400 To: netmod WG Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 153, in=2101, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:12:56 -0000 Apologies but the WebEx unexpectedly terminated.=20 I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod Please join there if you were on the call or want to join the = interim meeting. =E2=80=94Tom From nobody Thu Oct 15 07:15:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450E01B3285 for ; Thu, 15 Oct 2015 07:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGOj0xPAQKLD for ; Thu, 15 Oct 2015 07:15:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486261B3289 for ; Thu, 15 Oct 2015 07:15:11 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 14:15:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 14:15:09 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: webex accidentally cancelled meeting - looking to restart webex now... Thread-Index: AQHRB1PlgRwPpjH2BUaeE7jar4gatQ== Date: Thu, 15 Oct 2015 14:15:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:ojRXVEwpWmtMr6gsFeR/NMucN4GAqpY6AOfu2Pc37bI4cEFWDb3IsGgMUvLjrjoKtr6uao00YZmoFFZzUXWwISqh41TxWsj4kLO8k43VG6xVDc9v6R/4wn5UidlV2vF3LirlV6O78TYvfqIiceljiw==; 24:lKDoVdmn1XscV4f7S5fKpldoOO8s7+k8hBUgGUUjKBH6d2g8HA5yCIbiTaroRAuLukU4y9Eyj/fWvPvImkbvqMBnG/q4OsBAolD6m0f8H1A=; 20:mm45mRHb1B6154slqi42uIYMtbHQYSjzpSdohqQtTrw20EBYsr0BGtT1UeHqwlA1XFgkTUBhTVDN5Snh4Yk9dw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(558084003)(81156007)(450100001)(5002640100001)(16236675004)(5001960100002)(2351001)(40100003)(5008740100001)(46102003)(229853001)(64706001)(92566002)(97736004)(54356999)(101416001)(189998001)(5007970100001)(106356001)(102836002)(110136002)(11100500001)(4001350100001)(5004730100002)(5001920100001)(99286002)(86362001)(122556002)(107886002)(66066001)(2501003)(10400500002)(2900100001)(83506001)(106116001)(105586002)(87936001)(50986999)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2452D11E72C4kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 14:15:09.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: [netmod] webex accidentally cancelled meeting - looking to restart webex now... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:15:16 -0000 --_000_D2452D11E72C4kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable webex accidentally cancelled meeting - looking to restart webex now... Kent --_000_D2452D11E72C4kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

webex accidentally cancelled meeting= - looking to restart webex now...

Kent

--_000_D2452D11E72C4kwatsenjunipernet_-- From nobody Thu Oct 15 07:16:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76281B3248 for ; Thu, 15 Oct 2015 07:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9i-ve2MDyI3B for ; Thu, 15 Oct 2015 07:16:07 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 494D31A82E2 for ; Thu, 15 Oct 2015 07:16:07 -0700 (PDT) Received: by obbrx8 with SMTP id rx8so65921119obb.3 for ; Thu, 15 Oct 2015 07:16:06 -0700 (PDT) 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=SZAxUfN5OU2GhTQ019Cp6e2333oZ7lQB6Yp0XEaCNA8=; b=G2u9xHGqNpNL2IEpxeeobmCbsLoAxYVv2bn4Pa1GQBPIS9MfCAWI+hPiGt7uLoXwd0 SVnsM1p4zCRRoV4HxteqtMbU53mm2t+R7oyC3azK1qzAlkIknQ3MYhE5pzxjHzPKQSYt x6z5WuB09FBAOfYf3F65dZTSPdHMDY+jYIQLQ0ju+y7i035iJAgvzA30EqROQiNUKZNh YI4fDvvS3J07/9BSczWdXG/5tO2kz4AZ0yhbDDKgzcuRzavix8b0Ylcd1+Bv5+hv5+e+ qAzPZi8medEqyKSQns4t8B/4lXyaC/QpWkJdIDuV5lrB+WJ7a3n75ZEYQGZXWZo7+EnC SYRw== X-Received: by 10.182.96.100 with SMTP id dr4mr6089178obb.49.1444918566657; Thu, 15 Oct 2015 07:16:06 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:39e8:94df:fd6b:e48c]) by smtp.gmail.com with ESMTPSA id q2sm6401745obf.22.2015.10.15.07.16.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 07:16:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BCB4E90-44F1-4D8A-A70B-211AF159435C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> Date: Thu, 15 Oct 2015 07:16:04 -0700 Message-Id: <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> To: Nadeau Thomas X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:16:09 -0000 --Apple-Mail=_8BCB4E90-44F1-4D8A-A70B-211AF159435C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This one says the meeting is locked and one cannot join. > On Oct 15, 2015, at 7:12 AM, Nadeau Thomas = wrote: >=20 >=20 > Apologies but the WebEx unexpectedly terminated.=20 >=20 > I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod >=20 > Please join there if you were on the call or want to join the = interim meeting. >=20 > =E2=80=94Tom >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8BCB4E90-44F1-4D8A-A70B-211AF159435C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This one says the meeting is locked and one cannot join.

On Oct 15, 2015, at 7:12 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:


Apologies = but the WebEx unexpectedly terminated.

I=E2=80=99v= e started a new one here:  https://ietf.webex.com/meet/netmod

= Please join there if you were on the call or want to join the = interim meeting.

=E2=80=94To= m

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_8BCB4E90-44F1-4D8A-A70B-211AF159435C-- From nobody Thu Oct 15 07:18:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76E1B3270 for ; Thu, 15 Oct 2015 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTA_sdVQI1Gf for ; Thu, 15 Oct 2015 07:18:23 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D663F1B3279 for ; Thu, 15 Oct 2015 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444918603; bh=SyyH8GxygGO+ct+MAEPREbyOOflwDpE4Z2fLYQUIXE0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gP2YFBGiWHThlGomQAycT+Detu87jr8+Du6dA7vVsaWasmJAOSp+Oj4U5gCID+PY+ evLUcfvkA9CSfMvlVdnJN1D170EEiuv1JsflT4yzR3vgjbxVuyjRmIuxH1g+z05TlP xXMCy6BVS+pPM2ifzvVAVVHESTHNQ7clKfaSREV4= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_0FB8EE46-1B17-456D-85B5-7CDE43E3E4E2" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Nadeau Thomas In-Reply-To: <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> Date: Thu, 15 Oct 2015 10:18:19 -0400 Message-Id: References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=18 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 153, in=2102, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:18:26 -0000 --Apple-Mail=_0FB8EE46-1B17-456D-85B5-7CDE43E3E4E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just unlocked it. Audio should work now. > On Oct 15, 2015:10:16 AM, at 10:16 AM, Mahesh Jethanandani = wrote: >=20 > This one says the meeting is locked and one cannot join. >=20 >> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas > wrote: >>=20 >>=20 >> Apologies but the WebEx unexpectedly terminated.=20 >>=20 >> I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod >>=20 >> Please join there if you were on the call or want to join the = interim meeting. >>=20 >> =E2=80=94Tom >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_0FB8EE46-1B17-456D-85B5-7CDE43E3E4E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I just = unlocked it. Audio should work now.

On = Oct 15, 2015:10:16 AM, at 10:16 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

This one says = the meeting is locked and one cannot join.

On Oct 15, 2015, at 7:12 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:


Apologies = but the WebEx unexpectedly terminated.

I=E2=80=99v= e started a new one here:  https://ietf.webex.com/meet/netmod

= Please join there if you were on the call or want to join the = interim meeting.

=E2=80=94To= m

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

Mahesh Jethanandani
mjethanandani@gmail.com






= --Apple-Mail=_0FB8EE46-1B17-456D-85B5-7CDE43E3E4E2-- From nobody Thu Oct 15 07:18:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30591B3277 for ; Thu, 15 Oct 2015 07:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF0dSm0PGmf7 for ; Thu, 15 Oct 2015 07:18:26 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE0C1B327B for ; Thu, 15 Oct 2015 07:18:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BXBQA3Q8ZV/yYyC4dTCBkBAQGCMiEsVGkGgx6CCaRNkz+BWx8BCIUwSgIcgQo6EgEBAQEBAQGBCoQjAQEBAQMBAQEPEQpBCxACAQgNAQMEAQELHQMCAgIfBgsUCQgCBAENBQgah3cDEgEMrGmKVpArDYUsAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YfhTKBPQGBEYFjJi0EBgEJgmAvgRQFlQsBhQGFdAGDNUaDX4MLiVGHMxcPgWCCHW8BAYFGgQQBAQE X-IPAS-Result: A2BXBQA3Q8ZV/yYyC4dTCBkBAQGCMiEsVGkGgx6CCaRNkz+BWx8BCIUwSgIcgQo6EgEBAQEBAQGBCoQjAQEBAQMBAQEPEQpBCxACAQgNAQMEAQELHQMCAgIfBgsUCQgCBAENBQgah3cDEgEMrGmKVpArDYUsAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YfhTKBPQGBEYFjJi0EBgEJgmAvgRQFlQsBhQGFdAGDNUaDX4MLiVGHMxcPgWCCHW8BAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="146828834" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 15 Oct 2015 10:18:23 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 Oct 2015 10:18:22 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 15 Oct 2015 16:18:21 +0200 From: "Romascanu, Dan (Dan)" To: Mahesh Jethanandani , Nadeau Thomas Thread-Topic: [netmod] interim meeting NEW webex Thread-Index: AQHRB1OYeXC53zbcME6Trak9TBVlvJ5sd94AgAAhzJA= Date: Thu, 15 Oct 2015 14:18:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17@AZ-FFEXMB04.global.avaya.com> References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> In-Reply-To: <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:18:27 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqb2luZWQgb25lIHdoZXJlIEkgYW0gdGhlIG9ubHkgcGVyc29uIGluIHRoZSBjYWxsIOKYug0K DQpDYW4gc29tZW9uZSByZS1zZW5kPw0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQpG cm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1haGVzaCBKZXRoYW5hbmRhbmkNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDE1IDU6 MTYgUE0NClRvOiBOYWRlYXUgVGhvbWFzDQpDYzogbmV0bW9kIFdHDQpTdWJqZWN0OiBSZTogW25l dG1vZF0gaW50ZXJpbSBtZWV0aW5nIE5FVyB3ZWJleA0KDQpUaGlzIG9uZSBzYXlzIHRoZSBtZWV0 aW5nIGlzIGxvY2tlZCBhbmQgb25lIGNhbm5vdCBqb2luLg0KDQpPbiBPY3QgMTUsIDIwMTUsIGF0 IDc6MTIgQU0sIE5hZGVhdSBUaG9tYXMgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0bzp0 bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4+IHdyb3RlOg0KDQoNCiAgICAgICAgICBBcG9sb2dpZXMg YnV0IHRoZSBXZWJFeCB1bmV4cGVjdGVkbHkgdGVybWluYXRlZC4NCg0KICAgICAgICAgIEnigJl2 ZSBzdGFydGVkIGEgbmV3IG9uZSBoZXJlOiAgaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9tZWV0L25l dG1vZDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X2lldGYud2ViZXguY29tX21lZXRfbmV0bW9kJmQ9QlFNRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2la SDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT12TGYw U3Nxa3JOSUt2N2NzMVMyRW9QOFE1aHFCb1Zoa3hnUElxaFM1YTI0JnM9dThpeGhmbVlLTUc5RFdI V0lwTlVlSWJTSDR6TFRrcUtjWTFYelBEMXNKbyZlPT4NCg0KICAgICAgICAgIFBsZWFzZSBqb2lu IHRoZXJlIGlmIHlvdSB3ZXJlIG9uIHRoZSBjYWxsIG9yIHdhbnQgdG8gam9pbiB0aGUgaW50ZXJp bSBtZWV0aW5nLg0KDQogICAgICAgICAg4oCUVG9tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9QlFR RmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1 Y0JYUnVjUHZkcnBocEJzRkEmbT12TGYwU3Nxa3JOSUt2N2NzMVMyRW9QOFE1aHFCb1Zoa3hnUElx aFM1YTI0JnM9SHI5NzFMOFh1cGtqZGRPQmR1QTBOVEExbkQ2eXV5UWVhZmR6WnA2dzd0ZyZlPT4N Cg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkkgam9pbmVkIG9uZSB3aGVyZSBJIGFtIHRoZSBvbmx5IHBlcnNvbiBpbiB0aGUgY2FsbA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztj b2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FuIHNvbWVvbmUgcmUtc2VuZD8NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGFuZCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBuZXRtb2Qg W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFo ZXNoIEpldGhhbmFuZGFuaTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAxNSwg MjAxNSA1OjE2IFBNPGJyPg0KPGI+VG86PC9iPiBOYWRlYXUgVGhvbWFzPGJyPg0KPGI+Q2M6PC9i PiBuZXRtb2QgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIGludGVyaW0gbWVl dGluZyBORVcgd2ViZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIG9uZSBzYXlzIHRoZSBtZWV0aW5nIGlzIGxvY2tlZCBhbmQgb25lIGNhbm5vdCBq b2luLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9j dCAxNSwgMjAxNSwgYXQgNzoxMiBBTSwgTmFkZWF1IFRob21hcyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIj50bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+QXBvbG9naWVzIGJ1dCB0aGUgV2ViRXggdW5l eHBlY3RlZGx5IHRlcm1pbmF0ZWQuDQo8YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+SeKAmXZlIHN0YXJ0ZWQgYSBuZXcgb25lIGhlcmU6ICZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0 Zi53ZWJleC5jb21fbWVldF9uZXRtb2QmYW1wO2Q9QlFNRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwx U2dpWkg2NFEmYW1wO3I9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNG QSZhbXA7bT12TGYwU3Nxa3JOSUt2N2NzMVMyRW9QOFE1aHFCb1Zoa3hnUElxaFM1YTI0JmFtcDtz PXU4aXhoZm1ZS01HOURXSFdJcE5VZUliU0g0ekxUa3FLY1kxWHpQRDFzSm8mYW1wO2U9Ij5odHRw czovL2lldGYud2ViZXguY29tL21lZXQvbmV0bW9kPC9hPjxicj4NCjxicj4NCjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5QbGVhc2Ugam9pbiB0aGVyZSBpZiB5b3Ugd2VyZSBvbiB0 aGUgY2FsbCBvciB3YW50IHRvIGpvaW4gdGhlIGludGVyaW0gbWVldGluZy48YnI+DQo8YnI+DQo8 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCUVG9tPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9k JmFtcDtkPUJRUUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDtyPUk0ZHpHeFIz MU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmYW1wO209dkxmMFNzcWtyTklLdjdj czFTMkVvUDhRNWhxQm9WaGt4Z1BJcWhTNWEyNCZhbXA7cz1Icjk3MUw4WHVwa2pkZE9CZHVBME5U QTFuRDZ5dXlRZWFmZHpacDZ3N3RnJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17AZFFEXMB04globa_-- From nobody Thu Oct 15 07:18:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23591B3285 for ; Thu, 15 Oct 2015 07:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dg7eIUt18ST for ; Thu, 15 Oct 2015 07:18:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A71D1B3270 for ; Thu, 15 Oct 2015 07:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444918630; bh=u/HABpmpxc/qjtkskS1xU8BRYIlcc/2N8ZfxbaFf4X8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gKtDSmSpdDcGwDomDcEl3gci156Eu4ackgvEQ4mHVCAw6/8YaRRwwQSZegaefRKbO tyiDWLWAGZcRmeWford07yNgwAqRwmJZrl6gubNBgBdy4K97r6yuEkJDxcNG/FeNAq toyXoeXuqAQaPjCtO7r5U2X6GgTHufpYqN/mPr2M= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_9558329F-3B9E-47ED-BE25-A782F2F781FE" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Nadeau Thomas In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17@AZ-FFEXMB04.global.avaya.com> Date: Thu, 15 Oct 2015 10:18:50 -0400 Message-Id: <5B15D058-77B1-4E13-B91E-1688ED402119@lucidvision.com> References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=19 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 153, in=2103, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:18:53 -0000 --Apple-Mail=_9558329F-3B9E-47ED-BE25-A782F2F781FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://ietf.webex.com/meet/netmod = > On Oct 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) = wrote: >=20 > I joined one where I am the only person in the call J > =20 > Can someone re-send? > =20 > Thanks and Regards, > =20 > Dan > =20 > From: netmod [mailto:netmod-bounces@ietf.org = ] On Behalf Of Mahesh Jethanandani > Sent: Thursday, October 15, 2015 5:16 PM > To: Nadeau Thomas > Cc: netmod WG > Subject: Re: [netmod] interim meeting NEW webex > =20 > This one says the meeting is locked and one cannot join. > =20 > On Oct 15, 2015, at 7:12 AM, Nadeau Thomas > wrote: > =20 >=20 > Apologies but the WebEx unexpectedly terminated.=20 >=20 > I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod = >=20 > Please join there if you were on the call or want to join = the interim meeting. >=20 > =E2=80=94Tom >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = > =20 > Mahesh Jethanandani > mjethanandani@gmail.com --Apple-Mail=_9558329F-3B9E-47ED-BE25-A782F2F781FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 https://ietf.webex.com/meet/netmod


On Oct = 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

I = joined one where I am the only person in the call J
 
Can someone = re-send?
 
Thanks and Regards,
 
Dan
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Thursday, October 15, 2015 = 5:16 PM
To: Nadeau Thomas
Cc: netmod WG
Subject: Re: [netmod] interim = meeting NEW webex
 
This one says the meeting is locked and = one cannot join.
 
On = Oct 15, 2015, at 7:12 AM, Nadeau Thomas <tnadeau@lucidvision.com> = wrote:
 

        &= nbsp; Apologies = but the WebEx unexpectedly terminated. 

        &= nbsp; I=E2=80=99v= e started a new one here:  https://ietf.webex.com/meet/netmod

        &= nbsp; Please = join there if you were on the call or want to join the interim = meeting.

        &= nbsp; =E2=80=94To= m

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 
Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_9558329F-3B9E-47ED-BE25-A782F2F781FE-- From nobody Thu Oct 15 07:20:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DFE1B328D for ; Thu, 15 Oct 2015 07:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPxv38EYMSUt for ; Thu, 15 Oct 2015 07:20:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36841B3289 for ; Thu, 15 Oct 2015 07:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444918708; bh=OTaRAID1aHtlHJpYFEYKlUNwJ3w4Huo+BVSX8gGxX4o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=LgH6OynPFH7fuz3xXhDoNLdiZ/ckeGrhQkGBkNfayq8SjvRh7ISkI31nv+Ir1mPiC GR9fOstZ5lRjk+245csE1V0/cRozIKeGMuEzxE6irHXNLeTCs3wd3mKUZquPPf5Qi7 flMY6T7Sj5aF5S/6i/nx0GvaSCPdnf+5ARQF+mo0= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_06FB3D68-1B4F-45AC-947D-5C10F5B62F9D" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Nadeau Thomas In-Reply-To: <5B15D058-77B1-4E13-B91E-1688ED402119@lucidvision.com> Date: Thu, 15 Oct 2015 10:20:06 -0400 Message-Id: References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17@AZ-FFEXMB04.global.avaya.com> <5B15D058-77B1-4E13-B91E-1688ED402119@lucidvision.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=20 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 153, in=2104, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:20:11 -0000 --Apple-Mail=_06FB3D68-1B4F-45AC-947D-5C10F5B62F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Some (including me) were having issues with =E2=80=9Ccomputer = audio=E2=80=9D. If you are, call into meeting using the dial info. > On Oct 15, 2015:10:18 AM, at 10:18 AM, Nadeau Thomas = wrote: >=20 > https://ietf.webex.com/meet/netmod = >=20 >=20 >> On Oct 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) = > wrote: >>=20 >> I joined one where I am the only person in the call J >> =20 >> Can someone re-send? >> =20 >> Thanks and Regards, >> =20 >> Dan >> =20 >> From: netmod [mailto:netmod-bounces@ietf.org = ] On Behalf Of Mahesh Jethanandani >> Sent: Thursday, October 15, 2015 5:16 PM >> To: Nadeau Thomas >> Cc: netmod WG >> Subject: Re: [netmod] interim meeting NEW webex >> =20 >> This one says the meeting is locked and one cannot join. >> =20 >> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas > wrote: >> =20 >>=20 >> Apologies but the WebEx unexpectedly terminated.=20 >>=20 >> I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod = >>=20 >> Please join there if you were on the call or want to join = the interim meeting. >>=20 >> =E2=80=94Tom >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >> =20 >> Mahesh Jethanandani >> mjethanandani@gmail.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_06FB3D68-1B4F-45AC-947D-5C10F5B62F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Some (including me) were having = issues with =E2=80=9Ccomputer audio=E2=80=9D. If you are, call into = meeting using the dial info.

On = Oct 15, 2015:10:18 AM, at 10:18 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:

https://ietf.webex.com/meet/netmod


On Oct = 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

I = joined one where I am the only person in the call J
 
Can someone = re-send?
 
Thanks and Regards,
 
Dan
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Thursday, October 15, 2015 = 5:16 PM
To: Nadeau Thomas
Cc: netmod WG
Subject: Re: [netmod] interim = meeting NEW webex
 
This one says the meeting is locked and = one cannot join.
 
On = Oct 15, 2015, at 7:12 AM, Nadeau Thomas <tnadeau@lucidvision.com> = wrote:
 

        &= nbsp; Apologies = but the WebEx unexpectedly terminated. 

        &= nbsp; I=E2=80=99v= e started a new one here:  https://ietf.webex.com/meet/netmod

        &= nbsp; Please = join there if you were on the call or want to join the interim = meeting.

        &= nbsp; =E2=80=94To= m

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 
Mahesh Jethanandani
mjethanandani@gmail.com

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

= --Apple-Mail=_06FB3D68-1B4F-45AC-947D-5C10F5B62F9D-- From nobody Thu Oct 15 07:35:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91CB1B330C for ; Thu, 15 Oct 2015 07:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HjBSSCqTAFvx for ; Thu, 15 Oct 2015 07:35:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335AF1B3307 for ; Thu, 15 Oct 2015 07:35:09 -0700 (PDT) Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB137.namprd05.prod.outlook.com (10.255.205.21) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 15 Oct 2015 14:35:04 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 15 Oct 2015 14:35:02 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 14:35:02 +0000 From: Gert Grammel To: Robert Wilton , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAA== Date: Thu, 15 Oct 2015 14:35:02 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> <561FB149.103@cisco.com> In-Reply-To: <561FB149.103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:K53YjGHwzozQR0suSVs/2WDBjTmvk1km4eoDWDjT3XzU2xtLAgh/3n6w/Eo+1BV0SO/esKUFPV/pU8Jf/vBsw1EytH13QgVjNjyMDyStwhjTA2tQD0Cz3ZKvYUplApArIVi/gxQbpq1pIuJvPWQNfA==; 24:Pm0tIfzuVZAhQGXmc8cojb+eOv5xPXnYa/rjQJts6csRakCAcQt6VlICMIkfV99kYgApgrJMmPaAIS/JPYFPSx+gB+etkT2rPmTJlX1xHUU=; 20:8P0GbhcD8LkNZ8MAvCEQWAauJ5g6190jWmeO6VHFv1JyXxtnwnKwf6YLSZBfSRXoSCnOGT4vv4RNbX+hAQUPHg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(377454003)(52314003)(199003)(53754006)(164054003)(479174004)(189002)(76104003)(24454002)(505384003)(106356001)(10400500002)(561944003)(16236675004)(99286002)(5008740100001)(102836002)(19617315012)(66066001)(107886002)(92566002)(189998001)(36756003)(106116001)(64706001)(83506001)(2900100001)(2950100001)(105586002)(15975445007)(11100500001)(76176999)(50986999)(54356999)(86362001)(101416001)(19580405001)(1941001)(2501003)(81156007)(5002640100001)(19580395003)(97736004)(5007970100001)(122556002)(5001960100002)(87936001)(93886004)(4001350100001)(5001770100001)(40100003)(46102003)(5004730100002)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D24584097148ggrammeljunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 14:35:02.6579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB137; 2:Avi9tbn+c6JGTu2tAGZlC8xJzhOrOZodIwHeBXZ0cOV8q6BJGCo4ZVlXP5j38W3SpjiwOv42yNu75ehe2qRZdJKUcV1su8UZLM0PCm2VWUyg3i5Xx/r8amNz0t9yg+3mNhIhLNsMb4gf0VkyreiqxxhJeIu70gOy1tXAXpgiykA=; 23:eckqo7gWIa/A7vRj1ZtzIAy54IF8jj01KK/hcLVO6o8HDBC20DYLlMfIoku96dfLzFBPrVcXGoSumPA2biTS9AuoJK2FmwBtMK8/ejVIkQeHgjpFn8PMoRzUaKx9iGqnoAFxvNJH+LgcjfcmQNAjHhmPvNrr+CFNWIja6ycZhiBsQkJLhXda2j/WlxhC8QLJ X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:35:15 -0000 --_000_D24584097148ggrammeljunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rob, >From a client perspective a server has three states: 1. intended !=3D applied 2. Funny-state 3. Intended =3D=3D applied Irrespective of synchronous or asynchronous processing in the server, the t= hird state MUST be reported to the client. Else (from a client perspective)= the server stays in funny-state forever. Gert From: Robert Wilton > Date: Thursday 15 October 2015 15:59 To: Gert Grammel >, Kent = Watsen >, "netmod@ietf.org<= mailto:netmod@ietf.org>" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Gert, Kent, I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way. E.g. if the = information as to whether a particular intended leave had been successfully= applied was available (e.g. as per github issue #2). So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.: E.g. replacing: Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange. Perhaps with: Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change. Or: Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change. Thanks, Rob On 15/10/2015 12:17, Gert Grammel wrote: Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn=92t look= complete. The way it stands for the synchronous operation, the client know= s that it's intended config was good AND it has been effected to the server= . In the Asynchronous case, the client only knows that the intended config = was good =96 and that=92s not enough. So the proposal is to refine the asynchronous case definition as follows: Asynchronous configuration operation - A configuration request to update th= e running configuration of a server that is applied asynchronously with res= pect to the client request. The server MUST update its intended configurat= ion (see term) before replying to the client indicating whether the request= will be processed. The reply to the client only indicates whether there a= re any errors in the original request. The server's applied configuration state (see term) is updated after the co= nfiguration change has been applied to all impacted components in the serve= r. Once applied, the client MUST be notified whether the intended config i= s now fully effective or there are any errors from applying the configurati= on change. In addition I would suggest to require a verify operation which a client ca= n request from the server to obtain above information on an on-demand basis= . Would that somehow go in the opstate-reqs #3 then? Best Gert From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen > Date: Thursday 15 October 2015 00:11 To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Robert, One comment, it seems that the asynchronous configuration operation should have one more sentence at its end saying that an asynchronous notification must be used to report any errors produced from when applying the configuration. What do you think? Kent // as a contributor On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@c= isco.com> wrote: Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... Works for me. Sometimes less is more. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Depends on the definition of applied configuration - where is the latest version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D24584097148ggrammeljunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <02D4A013E2BBA64F95D5C6D6BD578E56@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Rob,

From a client perspective a server has three states: 
  1. intended !=3D applied
  2. Funny-state
  3. Intended =3D=3D appli= ed
Irrespective of synchronous or asynchronous processing in the server, = the third state MUST be reported to the client. Else (from a client perspec= tive) the server stays in funny-state forever.


Gert


From: Robert Wilton <rwilton@cisco.com>
Date: Thursday 15 October 2015 15:5= 9
To: Gert Grammel <ggrammel@juniper.net>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way.  E.g. if= the information as to whether a particular intended leave had been success= fully applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change.

Or:

Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change.

Thanks,
Rob


On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn=92t= look complete. The way it stands for the synchronous operation, the client= knows that it's intended config was good AND it has been effected to the s= erver. In the Asynchronous case, the client only knows that the intended config was good =96 and that=92s not e= nough.

So the proposal is to refine the asynchronous case definition as follo= ws:

Asynchronous configuration operation - A configuration request to upda= te the running configuration of a server that is applied asynchronously wit= h respect to the client request.  The server MUST update its inte= nded configuration (see term) before replying to the client indicating whether the request will be processed.  The = reply to the client only indicates whether there are any errors in the &nbs= p;original request.
The server's applied configuration state (see term) is updated after t= he configuration change has been applied to all impacted components in the = server.  Once applied, the client MUST be notified whether the intende= d config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a clie= nt can request from the server to obtain above information on an on-demand = basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@iet= f.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Thursday 15 October 2015 00:1= 1
To: Robert Wilton <rwilton@cisco.com>= , "netmod@= ietf.org" <netmod@iet= f.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation sh= ould
have one more sentence at its end saying that an asynchronous notifica= tion
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wro= te:

Hi All,

Are there any more comments on the following proposed descriptions, or=
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to updat= e
the running configuration of a server that is applied synchronously wi= th
respect to the client request.  The server MUST fully effect= the
configuration change to all impacted components in the server, updatin= g
both the server's intended and applied configuration (see terms), befo= re
replying to the client.  The reply to the client indicates w= hether there
are any errors in the request or errors from applying the configuratio= n
change.

Asynchronous configuration operation - A configuration request to upda= te
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update = its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied=
configuration state (see term) is updated after the configuration chan= ge
has been fully effected to all impacted components in the server. = ; The
reply to the client only indicates whether there are any errors in the=
original request.

Synchronous configuration server - a configuration server that process= es
all configuration operations as synchronous configuration operations.<= /div>

Asynchronous configuration server - a configuration server that proces= ses
all configuration operations as asynchronous configuration operations.=

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure tha= t the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.<= /div>
The reply to the client indicates whether there are any errors in the<= /div>
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RF= C 6020
says:

     When datastore processing is complete, the fi= nal contents MUST
obey
     all validation constraints.  This v= alidation processing is
performed
     at differing times according to the datastore= .  If the datastore
is
     <running/> or <startup/>, these c= onstraints MUST be enforced at
the
     end of the <edit-config> or <copy-co= nfig> operation.  If the
     datastore is <candidate/>, the constrai= nt enforcement is delayed
     until a <commit> or <validate> op= eration.

Are we talking about datastore validation or validation of a request?<= /div>
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validat= e"
would exclude an ephemeral datastore, so I was trying to water down th= e
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration s= erver that processes
    some configuration operations as synchronous c= onfiguration
    operations and some configuration operations a= s asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy=
that in real systems, depending on the data model, certain parts of a<= /div>
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration= - this data represents the configuration
        state that the network= operator intends the system to be in, and
that
        has been accepted by t= he system as valid configuration.  This
data is
        colloquially referred = to as the 'configuration' of the system.

       applied configuration - this data= represents the configuration
        state that the network= element is actually in, i.e., the
        configuration state wh= ich is currently being being used by
system
        components (e.g., cont= rol plane daemons, operating system
        kernels, line cards).<= /div>
Well, sometimes the config goes to a control plane daemon and then to<= /div>
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that= the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if = that means
that the definition of applied configuration should be strengthened, o= r
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from<= /div>
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to<= /div>
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended=
config and then report the result of the guess work as applied config<= /div>
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price=
for this applied config idea, I have no real problem with this since I=
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list


 --_000_D24584097148ggrammeljunipernet_-- From nobody Thu Oct 15 08:02:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17451A21AC for ; Thu, 15 Oct 2015 08:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJv6NXmFER90 for ; Thu, 15 Oct 2015 08:02:12 -0700 (PDT) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 707961A00CF for ; Thu, 15 Oct 2015 08:02:07 -0700 (PDT) Received: by lffy185 with SMTP id y185so31135961lff.2 for ; Thu, 15 Oct 2015 08:02:05 -0700 (PDT) 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=4UkgOY3tTMn3BpfGvX46ryYhCDvzQIiEnas50ZhNKhA=; b=BANGXZy4vGDxVPsj/L6nXoWzk8wb6MPK3ugrnQ6ZfYWYOzdtvJB96epaoGDSAW3aOf 3FO2R6enWV1uo1ovLPELLfp4t1OufogWvVgG/EljconeLL9helrz/q/Tq3rQfsOU2WGi MMmphcLuCLzZjqI4TF1dvv416zCIS+MrmsS/Wt6NmvUNpT7y5pfNztpZAkrmuRk/iqSB sST6dKrg5rdTT9TAhOUPXg9mlRNMiwDeDInAChkPGLQRFepA7ZkFGKmaK9vKVdkP3eN2 JmUAyZjSHZWUQEZsmfp4ZvvSHyYMipnXIYc2JDDvgJ2GRnPYvp+3Q8JPS2NPUKOusevD VleQ== X-Gm-Message-State: ALoCoQm7YbItOTR5TXDqSpIuOjgqoehIClbPOfDBkhIeGkvW3XrXwyg46+wesmvJcjibL6EGfifu MIME-Version: 1.0 X-Received: by 10.25.17.208 with SMTP id 77mr2775645lfr.38.1444921324550; Thu, 15 Oct 2015 08:02:04 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 15 Oct 2015 08:02:04 -0700 (PDT) In-Reply-To: <20151015.135334.2134677503217017095.mbj@tail-f.com> References: <561F5D28.5020304@ericsson.com> <20151015.135334.2134677503217017095.mbj@tail-f.com> Date: Thu, 15 Oct 2015 08:02:04 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113fbd3c4774d8052225f6d5 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:02:20 -0000 --001a113fbd3c4774d8052225f6d5 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > You are incorrect. > > > > Within the PAYLOAD (as this section describes), there is no when-stmt > > for data nodes within the datastore. Look at the YANG for edit-config. > > There are no when-stmts for "interface" in "edit-config". > > Andy, there is some confusion here. The section talks about: > > For configuration data, there are three windows when constraints > MUST be enforced: > > - during parsing of RPC payloads > - during processing of NETCONF operations > - during validation > > So the entire section talks about constraints *on configuration data*. > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 Here is the YANG for edit-config? Please point out the when-stmts in this rpc-stmt specific to the "interface" node. I just see an "anyxml" that has no when-stmts at all. So enforcing the when constraint on the RPC PAYLOAD clearly has nothing to do with "interface" -- just the parameters specified in the rpc-stmt. > If you interpret this section to talk about the nodes in the > definition of edit-config, nothing in the section makes any sense at > all. For example: > > If all keys of a list entry are not present, the server MUST reply > with a "missing-element" error-tag in the rpc-error. > > you might say that there are no lists in the definition of > edit-config, so this bullet doesn't apply. > > > edit-config is the next section -- 8.2.2 > /martin > > Andy > > > > > > So explain which constraint in the payload is being violated? > > > > > > Andy > > > > > > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel < > balazs.lengyel@ericsson.com > > > wrote: > > > > > See below, Balazs > > > > > > On 2015-10-14 23:06, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < > > > mbj@tail-f.com> wrote: > > > > > >> Andy Bierman wrote: > > >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund > > >> wrote: > > >> > > > >> > > Andy Bierman wrote: > > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund < > mbj@tail-f.com> > > >> > > wrote: > > >> > > > > > >> > > > > Balazs Lengyel < > > >> balazs.lengyel@ericsson.com> wrote: > > >> > > > > > Hello Martin, > > >> > > > > > I agree that A1 is what follows the spirit of YANG, but then > > >> IMHO you > > >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 > and > > >> > > error. > > >> > > > > > > >> > > > > Ok, I agree. I suggest we remove from 8.2.1: > > >> > > > > > > >> > > > > o If data for a node tagged with "when" is present, and > the > > >> "when" > > >> > > > > condition evaluates to "false", the server MUST reply > with > > >> an > > >> > > > > "unknown-element" error-tag in the rpc-error. > > >> > > > > > > >> > > > > and add to 8.2.2: > > >> > > > > > > >> > > > > o Modification requests for nodes tagged with "when", and > the > > >> "when" > > >> > > > > condition evaluates to "false". In this case the server > MUST > > >> > > reply > > >> > > > > with an "unknown-element" error-tag in the rpc-error. > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > This seems like a BIG protocol change to behavior. > > >> > > > IMO this not an error at all. In our server the false-when > data is > > >> just > > >> > > > pruned, and no error is ever sent for a pruned when=false data > node. > > >> > > > > >> > > So you are not following the current RFC 6020 spec? > > >> > > > > >> > > > >> > > > >> > Yes we are following it. > > >> > > >> Ok. > > >> > > >> > The schema for the edit-config RPC operation contains > > >> > an 'anyxml' for node. It does not contain any > > >> > when-stmts for the data nodes that get passed in the node. > > >> > The correct behavior is to just enforce the error on the when-stmts > > >> > that appear in the rpc-stmt. > > >> > > >> I don't understand what you are trying to say. > > >> > > > > > > > > > I know about the text that says a false-when in an RPC is an error. > > > Show me the when-stmts "interface" in the "edit-config" rpc-stmt. > > > > > > > > > > > > > > >> > > >> Here's an example: > > >> > > >> augment /if:interfaces/if:interface { > > >> when "if:type = 'ianaift:ethernetCsmacd'"; > > >> > > >> container ethernet { > > >> leaf duplex { > > >> type enumeration { > > >> enum "half"; > > >> enum "full"; > > >> } > > >> } > > >> } > > >> } > > >> > > >> Suppose the db is empty. > > >> > > >> What if the edit-confif contains > > >> > > >> > > >> > > >> eth0 > > >> full > > >> ianaift:ethernetCsmacd > > >> > > >> > > >> > > >> will that work or not? I.e., will the eth0 interface be created with > > >> duplex full? > > >> > > > > > > Yes -- because these are data nodes and the rules for when-stmt > > > on data nodes are different than for rpc-stmt. Then the when-stmt > > > is a test on whether the node should exist in the candidate or running > > > datastore. > > > > > > Our server applies all the edits first, when checks all the when-stmts > > > that might have changed value. Nodes that have already existed in the > > > datastore may get pruned, not just the new nodes. > > > > > > > > > > > > > > > > > >> > > >> /martin > > >> > > >> > > >> > > > > > > Andy > > > > > > > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > I don't think this is a BIG protocol change, since the spec > already > > >> > > says that requests for nodes w/ false when expressions MUST send > > >> > > error. The change is to say that this behavior is true > regardless of > > >> > > evaluation order. > > >> > > > > >> > > > It may be a client programming error for the client to provide > > >> > > > false when nodes or not. What if the client is reusing some > > >> > > > code that sends 5 parameters, it it's OK if 1 of them gets > > >> > > > pruned sometimes because of a false when (e.g, product > > >> > > > feature-specific knob and that feature is not installed) > > >> > > > > >> > > Well, it might be simpler to send if-featured nodes that the > specific > > >> > > server doesn't support - this is also an error in 6020. > > >> > > > > >> > > > BTW, this is a really good example of what not to do, if one > > >> > > > wants to make the YANG specification protocol independent. > > >> > > > > >> > > That statement is true for the entire section 8.2, it is not > > >> > > specifically true for this change. > > >> > > > > >> > > > > >> > > /martin > > >> > > > > >> > > > >> > > > >> > Andy > > >> > > > > > > And this contradicts the current rfc6020bis-07#section-8.2.1 which > states > > > that already during parsing you must check > > > > > > If data for a node tagged with "when" is present, and the "when" > > > condition evaluates to "false", the server MUST reply with an > > > "unknown-element" error-tag in the rpc-error. > > > > > > > > > So already during parsing full you MUST send > back an error; > > > before processing ianaift:ethernetCsmacd. > > > (I also assume this is independent from the document order of the > edit-config request.) > > > So this MUST be corrected in the draft! > > > regards Balazs > > > > > > > > > > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > ECN: 831 7320 > > > Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com > > > > > > > --001a113fbd3c4774d8052225f6d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> You are incorrect.
>
> Within the PAYLOAD (as this section describes), there is no when-stmt<= br> > for data nodes within the datastore.=C2=A0 Look at the YANG for edit-c= onfig.
> There are no when-stmts for "interface" in "edit-config= ".

Andy, there is some confusion here.=C2=A0 The section talks about:

=C2=A0 For configuration data, there are three windows when constraints
=C2=A0 MUST be enforced:

=C2=A0 - during parsing of RPC payloads
=C2=A0 - during processing of NETCONF operations
=C2=A0 - during validation

So the entire section talks about constraints *on configuration data*.



http://w= ww.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421


Here is the YANG for edit-config?
Please point out the when-stmts in this rpc-stmt
specific= to the "interface" node.
I just see an "anyxml&qu= ot; that has no when-stmts at all.

So enforcing th= e when constraint on the RPC PAYLOAD
clearly has nothing to do wi= th "interface" -- just the parameters
specified in the = rpc-stmt.


=C2=A0
If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.=C2=A0 =C2=A0For example:

=C2=A0 If all keys of a list entry are not present, the server MUST reply =C2=A0 with a "missing-element" error-tag in the rpc-error.

you might say that there are no lists in the definition of
edit-config, so this bullet doesn't apply.




edit-config is the next= section =C2=A0-- 8.2.2



/martin



Andy
=C2=A0


>
> So explain which constraint in the payload is being violated?
>
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <balazs.lengyel@ericsson.com
> > wrote:
>
> > See below, Balazs
> >
> > On 2015-10-14 23:06, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < <mbj@tail-f.com>
> > mbj@tail-f.com> wrote: > >
> >> Andy Bierman <andy@y= umaworks.com> wrote:
> >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>
> >> wrote:
> >> >
> >> > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjork= lund <mbj@tail-f.com>
> >> > > wrote:
> >> > > >
> >> > > > > Balazs Lengyel < <balazs.lengyel@ericsson.com>
> >> balazs.lengyel= @ericsson.com> wrote:
> >> > > > > > Hello Martin,
> >> > > > > > I agree that A1 is what follows the = spirit of YANG, but then
> >> IMHO you
> >> > > > > > should change/correct 8.2.1 in YANG = because that implies A2 and
> >> > > error.
> >> > > > >
> >> > > > > Ok, I agree.=C2=A0 I suggest we remove fr= om 8.2.1:
> >> > > > >
> >> > > > >=C2=A0 =C2=A0 o=C2=A0 If data for a node t= agged with "when" is present, and the
> >> "when"
> >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evalu= ates to "false", the server MUST reply with
> >> an
> >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-e= lement" error-tag in the rpc-error.
> >> > > > >
> >> > > > > and add to 8.2.2:
> >> > > > >
> >> > > > >=C2=A0 =C2=A0o=C2=A0 Modification requests= for nodes tagged with "when", and the
> >> "when"
> >> > > > >=C2=A0 =C2=A0 =C2=A0 condition evaluates t= o "false".=C2=A0 In this case the server MUST
> >> > > reply
> >> > > > >=C2=A0 =C2=A0 =C2=A0 with an "unknown= -element" error-tag in the rpc-error.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > This seems like a BIG protocol change to <e= dit-config> behavior.
> >> > > > IMO this not an error at all.=C2=A0 In our ser= ver the false-when data is
> >> just
> >> > > > pruned, and no error is ever sent for a pruned= when=3Dfalse data node.
> >> > >
> >> > > So you are not following the current RFC 6020 spec?=
> >> > >
> >> >
> >> >
> >> > Yes we are following it.
> >>
> >> Ok.
> >>
> >> > The schema for the edit-config RPC operation contains > >> > an 'anyxml' for <config> node.=C2=A0 It do= es not contain any
> >> > when-stmts for the data nodes that get passed in the <= ;config> node.
> >> > The correct behavior is to just enforce the error on the= when-stmts
> >> > that appear in the rpc-stmt.
> >>
> >> I don't understand what you are trying to say.
> >>
> >
> >
> > I know about the text that says a false-when in an RPC is an erro= r.
> > Show me the when-stmts=C2=A0 "interface" in the "e= dit-config" rpc-stmt.
> >
> >
> >
> >
> >>
> >> Here's an example:
> >>
> >>=C2=A0 =C2=A0augment /if:interfaces/if:interface {
> >>=C2=A0 =C2=A0 =C2=A0when "if:type =3D 'ianaift:ethern= etCsmacd'";
> >>
> >>=C2=A0 =C2=A0 =C2=A0container ethernet {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf duplex {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "half"= ;
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "full"= ;
> >>=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}
> >>
> >> Suppose the db is empty.
> >>
> >> What if the edit-confif contains
> >>
> >>=C2=A0 =C2=A0<interfaces>
> >>=C2=A0 =C2=A0 =C2=A0<interface>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<eth:duplex>full</eth:dupl= ex>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<type>ianaift:ethernetCsmacd&= lt;/type>
> >>=C2=A0 =C2=A0 =C2=A0</interface>
> >>=C2=A0 =C2=A0</interfaces>
> >>
> >> will that work or not?=C2=A0 I.e., will the eth0 interface be= created with
> >> duplex full?
> >>
> >
> > Yes -- because these are data nodes and the rules for when-stmt > > on data nodes are different than for rpc-stmt.=C2=A0 Then the whe= n-stmt
> > is a test on whether the node should exist in the candidate or ru= nning
> > datastore.
> >
> > Our server applies all the edits first, when checks all the when-= stmts
> > that might have changed value.=C2=A0 Nodes that have already exis= ted in the
> > datastore may get pruned, not just the new nodes.
> >
> >
> >
> >
> >
> >>
> >> /martin
> >>
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > I don't think this is a BIG protocol change, si= nce the spec already
> >> > > says that requests for nodes w/ false when expressi= ons MUST send
> >> > > error.=C2=A0 The change is to say that this behavio= r is true regardless of
> >> > > evaluation order.
> >> > >
> >> > > > It may be a client programming error for the c= lient to provide
> >> > > > false when nodes or not.=C2=A0 What if the cli= ent is reusing some
> >> > > > code that sends 5 parameters, it it's OK i= f 1 of them gets
> >> > > > pruned sometimes because of a false when (e.g,= product
> >> > > > feature-specific knob and that feature is not = installed)
> >> > >
> >> > > Well, it might be simpler to send if-featured nodes= that the specific
> >> > > server doesn't support - this is also an error = in 6020.
> >> > >
> >> > > > BTW, this is a really good example of what not= to do, if one
> >> > > > wants to make the YANG specification protocol = independent.
> >> > >
> >> > > That statement is true for the entire section 8.2, = it is not
> >> > > specifically true for this change.
> >> > >
> >> > >
> >> > > /martin
> >> > >
> >> >
> >> >
> >> > Andy
> >>
> >
> > And this contradicts the current rfc6020bis-07#section-8.2.1 whic= h states
> > that already during parsing you must check
> >
> > If data for a node tagged with "when" is present, and t= he "when"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evaluates to "false"= ;, the server MUST reply with an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-element" error-tag i= n the rpc-error.
> >
> >
> > So already during parsing <eth:duplex>full</eth:duplex&g= t; you MUST send back an error;
> > before processing <type>ianaift:ethernetCsmacd</type>= .
> > (I also assume this is independent from the document order of the= edit-config request.)
> > So this MUST be corrected in the draft!
> > regards Balazs
> >
> >
> >
> >
> >
> > --
> > Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 email: Balazs.Lengyel= @ericsson.com
> >
> >

--001a113fbd3c4774d8052225f6d5-- From nobody Thu Oct 15 08:12:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4D71A8844 for ; Thu, 15 Oct 2015 08:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8K2M0KesyWF for ; Thu, 15 Oct 2015 08:12:03 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1D31B3124 for ; Thu, 15 Oct 2015 08:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1444921822; bh=u+W8dH9MRIPNNbMjM4U8JKq9ZDqZWVMeqrCwQ+JwESI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DzH+KodtiQDPo/vtfDSm+Wh6l6IfiZNfdDyR8niySCzM4WRYKbnEcdTnYvcJnjXxW HX32yc1iHJz0g7I7GE9Z3EJ8OYmYYmSgZs55q/HdSV8V/sFJcJbsFKLraSbQhb+u1r aD8ty9d5XXupulnjdktFxJ2jhkLFIMzkTCfT7zGo= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_BDBB0689-0917-4E4D-89A1-2BDA970354BE" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 15 Oct 2015 11:12:00 -0400 Message-Id: References: <7CC62462-DD7F-4948-8967-BB7DF0F1AB16@lucidvision.com> <67FF3818-C167-4CD7-BD03-213FE5B95D5F@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5CB4FE17@AZ-FFEXMB04.global.avaya.com> <5B15D058-77B1-4E13-B91E-1688ED402119@lucidvision.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.3094) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=22 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 153, in=2106, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod WG Subject: Re: [netmod] interim meeting NEW webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:12:10 -0000 --Apple-Mail=_BDBB0689-0917-4E4D-89A1-2BDA970354BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Webex hung up on us again. Please rejoin using the same URL. =E2=80=94Tom > On Oct 15, 2015:10:20 AM, at 10:20 AM, Nadeau Thomas = wrote: >=20 > Some (including me) were having issues with =E2=80=9Ccomputer = audio=E2=80=9D. If you are, call into meeting using the dial info. >=20 >=20 >> On Oct 15, 2015:10:18 AM, at 10:18 AM, Nadeau Thomas = > wrote: >>=20 >> https://ietf.webex.com/meet/netmod = >>=20 >>=20 >>> On Oct 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) = > wrote: >>>=20 >>> I joined one where I am the only person in the call J >>> =20 >>> Can someone re-send? >>> =20 >>> Thanks and Regards, >>> =20 >>> Dan >>> =20 >>> From: netmod [mailto:netmod-bounces@ietf.org = ] On Behalf Of Mahesh Jethanandani >>> Sent: Thursday, October 15, 2015 5:16 PM >>> To: Nadeau Thomas >>> Cc: netmod WG >>> Subject: Re: [netmod] interim meeting NEW webex >>> =20 >>> This one says the meeting is locked and one cannot join. >>> =20 >>> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas > wrote: >>> =20 >>>=20 >>> Apologies but the WebEx unexpectedly terminated.=20 >>>=20 >>> I=E2=80=99ve started a new one here: = https://ietf.webex.com/meet/netmod = >>>=20 >>> Please join there if you were on the call or want to join = the interim meeting. >>>=20 >>> =E2=80=94Tom >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod = >>> =20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_BDBB0689-0917-4E4D-89A1-2BDA970354BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Webex = hung up on us again.  Please rejoin using the same URL.

= =E2=80=94Tom

On Oct 15, 2015:10:20 AM, at = 10:20 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:

= Some (including me) were having issues with =E2=80=9Ccomputer = audio=E2=80=9D. If you are, call into meeting using the dial = info.


On Oct = 15, 2015:10:18 AM, at 10:18 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:

https://ietf.webex.com/meet/netmod


On Oct = 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

I = joined one where I am the only person in the call J
 
Can someone = re-send?
 
Thanks and Regards,
 
Dan
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Thursday, October 15, 2015 = 5:16 PM
To: Nadeau Thomas
Cc: netmod WG
Subject: Re: [netmod] interim = meeting NEW webex
 
This one says the meeting is locked and = one cannot join.
 
On = Oct 15, 2015, at 7:12 AM, Nadeau Thomas <tnadeau@lucidvision.com> = wrote:
 

        &= nbsp; Apologies = but the WebEx unexpectedly terminated. 

        &= nbsp; I=E2=80=99v= e started a new one here:  https://ietf.webex.com/meet/netmod

        &= nbsp; Please = join there if you were on the call or want to join the interim = meeting.

        &= nbsp; =E2=80=94To= m

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 
Mahesh Jethanandani
mjethanandani@gmail.com

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

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

= --Apple-Mail=_BDBB0689-0917-4E4D-89A1-2BDA970354BE-- From nobody Thu Oct 15 08:33:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5217E1B3378 for ; Thu, 15 Oct 2015 08:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CeTHA06HN84 for ; Thu, 15 Oct 2015 08:33:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8611B3383 for ; Thu, 15 Oct 2015 08:33:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-b0-561fc7374860 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.EC.17026.737CF165; Thu, 15 Oct 2015 17:33:11 +0200 (CEST) Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 17:33:10 +0200 To: Andy Bierman , Martin Bjorklund References: <561F5D28.5020304@ericsson.com> <20151015.135334.2134677503217017095.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <561FC736.6030903@ericsson.com> Date: Thu, 15 Oct 2015 17:33:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvja75cfkwg1Of9CweHJnFbtHd/Yzd Yv7FRlYHZo8lS34yeWz8tZjFo6X/IksAcxSXTUpqTmZZapG+XQJXxuRjjxkLumcyVpzuOsTU wHgivouRk0NCwETi/uOjLBC2mMSFe+vZuhi5OIQEjjJKHHp8kgXCWcsoMf3ORnaQKmEBY4lj 61uBEhwcIgIeEmvmuEHUbGeSeHfhDFgNs4C6xJ1Tj9lAbDYBI4mp/efBNvAKaEssm9/BBGKz CKhKXLneDVYvKhAj8X7TKkaIGkGJkzOfgNVzCgRK/J+8kRVipoZE65y5UPPlJZq3zmYGsYWA 4g8v/GWdwCg4C0n7LCQts5C0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGMYHt/zW 3cG4+rXjIUYBDkYlHt4FHPJhQqyJZcWVuYcYpTlYlMR5W5gehAoJpCeWpGanphakFsUXleak Fh9iZOLglGpgXBCUaZbB/tXkz5YT7PV3gyvPhKy3tWOcGDCPw0Ksb8fD0srdK5dfa8q1/qi8 rHB1Jn/1+09llnrHFfRfr1Q97cjkqVrXWV3+/otccuD90/Jt70p//z77bO6yoImila+ebeo/ 8P36SqWJhfXLU26qaVwR95/LYsY4sy/v9c0rCTMYyj12n7n1QImlOCPRUIu5qDgRAOqdGuBE AgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:33:20 -0000 Hello,
I had the same interpretation as Martin. The when could be on the config database model. Not just on the when defined in a definition of an rpc or action.
regards Balazs

On 2015-10-15 17:02, Andy Bierman wrote:


On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> You are incorrect.
>
> Within the PAYLOAD (as this section describes), there is no when-stmt
> for data nodes within the datastore.  Look at the YANG for edit-config.
> There are no when-stmts for "interface" in "edit-config".

Andy, there is some confusion here.  The section talks about:

  For configuration data, there are three windows when constraints
  MUST be enforced:

  - during parsing of RPC payloads
  - during processing of NETCONF operations
  - during validation

So the entire section talks about constraints *on configuration data*.





Here is the YANG for edit-config?
Please point out the when-stmts in this rpc-stmt
specific to the "interface" node.
I just see an "anyxml" that has no when-stmts at all.

So enforcing the when constraint on the RPC PAYLOAD
clearly has nothing to do with "interface" -- just the parameters
specified in the rpc-stmt.


 
If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.   For example:

  If all keys of a list entry are not present, the server MUST reply
  with a "missing-element" error-tag in the rpc-error.

you might say that there are no lists in the definition of
edit-config, so this bullet doesn't apply.




edit-config is the next section  -- 8.2.2



/martin



Andy
 


>
> So explain which constraint in the payload is being violated?
>
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <balazs.lengyel@ericsson.com
> > wrote:
>
> > See below, Balazs
> >
> > On 2015-10-14 23:06, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < <mbj@tail-f.com>
> > mbj@tail-f.com> wrote:
> >
> >> Andy Bierman <andy@yumaworks.com> wrote:
> >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com>
> >> wrote:
> >> >
> >> > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com>
> >> > > wrote:
> >> > > >
> >> > > > > Balazs Lengyel < <balazs.lengyel@ericsson.com>
> >> balazs.lengyel@ericsson.com> wrote:
> >> > > > > > Hello Martin,
> >> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> >> IMHO you
> >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> >> > > error.
> >> > > > >
> >> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
> >> > > > >
> >> > > > >    o  If data for a node tagged with "when" is present, and the
> >> "when"
> >> > > > >       condition evaluates to "false", the server MUST reply with
> >> an
> >> > > > >       "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > > and add to 8.2.2:
> >> > > > >
> >> > > > >   o  Modification requests for nodes tagged with "when", and the
> >> "when"
> >> > > > >      condition evaluates to "false".  In this case the server MUST
> >> > > reply
> >> > > > >      with an "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > This seems like a BIG protocol change to <edit-config> behavior.
> >> > > > IMO this not an error at all.  In our server the false-when data is
> >> just
> >> > > > pruned, and no error is ever sent for a pruned when=false data node.
> >> > >
> >> > > So you are not following the current RFC 6020 spec?
> >> > >
> >> >
> >> >
> >> > Yes we are following it.
> >>
> >> Ok.
> >>
> >> > The schema for the edit-config RPC operation contains
> >> > an 'anyxml' for <config> node.  It does not contain any
> >> > when-stmts for the data nodes that get passed in the <config> node.
> >> > The correct behavior is to just enforce the error on the when-stmts
> >> > that appear in the rpc-stmt.
> >>
> >> I don't understand what you are trying to say.
> >>
> >
> >
> > I know about the text that says a false-when in an RPC is an error.
> > Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.
> >
> >
> >
> >
> >>
> >> Here's an example:
> >>
> >>   augment /if:interfaces/if:interface {
> >>     when "if:type = 'ianaift:ethernetCsmacd'";
> >>
> >>     container ethernet {
> >>       leaf duplex {
> >>         type enumeration {
> >>           enum "half";
> >>           enum "full";
> >>         }
> >>       }
> >>     }
> >>   }
> >>
> >> Suppose the db is empty.
> >>
> >> What if the edit-confif contains
> >>
> >>   <interfaces>
> >>     <interface>
> >>       <name>eth0</name>
> >>       <eth:duplex>full</eth:duplex>
> >>       <type>ianaift:ethernetCsmacd</type>
> >>     </interface>
> >>   </interfaces>
> >>
> >> will that work or not?  I.e., will the eth0 interface be created with
> >> duplex full?
> >>
> >
> > Yes -- because these are data nodes and the rules for when-stmt
> > on data nodes are different than for rpc-stmt.  Then the when-stmt
> > is a test on whether the node should exist in the candidate or running
> > datastore.
> >
> > Our server applies all the edits first, when checks all the when-stmts
> > that might have changed value.  Nodes that have already existed in the
> > datastore may get pruned, not just the new nodes.
> >
> >
> >
> >
> >
> >>
> >> /martin
> >>
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > I don't think this is a BIG protocol change, since the spec already
> >> > > says that requests for nodes w/ false when expressions MUST send
> >> > > error.  The change is to say that this behavior is true regardless of
> >> > > evaluation order.
> >> > >
> >> > > > It may be a client programming error for the client to provide
> >> > > > false when nodes or not.  What if the client is reusing some
> >> > > > code that sends 5 parameters, it it's OK if 1 of them gets
> >> > > > pruned sometimes because of a false when (e.g, product
> >> > > > feature-specific knob and that feature is not installed)
> >> > >
> >> > > Well, it might be simpler to send if-featured nodes that the specific
> >> > > server doesn't support - this is also an error in 6020.
> >> > >
> >> > > > BTW, this is a really good example of what not to do, if one
> >> > > > wants to make the YANG specification protocol independent.
> >> > >
> >> > > That statement is true for the entire section 8.2, it is not
> >> > > specifically true for this change.
> >> > >
> >> > >
> >> > > /martin
> >> > >
> >> >
> >> >
> >> > Andy
> >>
> >
> > And this contradicts the current rfc6020bis-07#section-8.2.1 which states
> > that already during parsing you must check
> >
> > If data for a node tagged with "when" is present, and the "when"
> >       condition evaluates to "false", the server MUST reply with an
> >       "unknown-element" error-tag in the rpc-error.
> >
> >
> > So already during parsing <eth:duplex>full</eth:duplex> you MUST send back an error;
> > before processing <type>ianaift:ethernetCsmacd</type>.
> > (I also assume this is independent from the document order of the edit-config request.)
> > So this MUST be corrected in the draft!
> > regards Balazs
> >
> >
> >
> >
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> >


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu Oct 15 08:47:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6581A90F1 for ; Thu, 15 Oct 2015 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31ou5gJO7vIi for ; Thu, 15 Oct 2015 08:47:35 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EC71B3354 for ; Thu, 15 Oct 2015 08:47:32 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan7.hi.local) by mailscan-g63.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Zmkka-0007sh-OL; Thu, 15 Oct 2015 16:47:28 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan7.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZmkkZ-0005JN-3Y; Thu, 15 Oct 2015 16:47:27 +0100 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152] helo=[IPv6:::ffff:192.168.1.107]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1ZmkkW-0009wl-DF; Thu, 15 Oct 2015 16:47:24 +0100 MIME-Version: 1.0 To: Martin Bjorklund From: Jonathan Hansford Date: Thu, 15 Oct 2015 16:50:27 +0100 Importance: normal X-Priority: 3 In-Reply-To: <20151015.143939.746024114526885799.mbj@tail-f.com> References: <20151014.214145.1464628339304882836.mbj@tail-f.com> <20151015.143939.746024114526885799.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="_52A8CF4B-F1BC-4195-A32E-88E8A6790C3F_" X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Message-Id: Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] not a non-presence container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:47:38 -0000 --_52A8CF4B-F1BC-4195-A32E-88E8A6790C3F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" How about =E2=80=9Cclosest ancestor node in the schema tree (excluding non-= presence containers)=E2=80=9D? Jonathan From: Martin Bjorklund Sent: 15 October 2015 13:39 To: jonathan@hansfords.net Cc: wfl@cantab.net;netmod@ietf.org Subject: Re: [netmod] not a non-presence container Jonathan Hansford wrote: > If that misinterpretation has already happened for (at least) one > individual, would it be worth adding the clarification and remove the > ambiguity? Sure. The words "not a non-presence container" occurs a couple of times throughout the document. Would it be correct to write "not a non-presence-container"? /martin >=20 > Jonathan >=20 >=20 >=20 > From: William Lupton > Sent: 14 October 2015 23:28 > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] not a non-presence container >=20 >=20 > Thanks. I see now. As you will have realised, I parsed "not a > non-presence container" as "(not a non-presence) container" (WRONG) > rather than "not a (non-presence container)" (RIGHT). Cheers, W. >=20 > On 14 October 2015 at 20:41, Martin Bjorklund wrote: > William Lupton wrote: > > All, > > > > Both RFC 6020 and the bis draft use the term "not a non-presence > > container", sometimes with a reference to section 7.5.1. > > > > Does this term mean the same as "presence container"? >=20 > No.=C2=A0 A list (for example) is not a non-presence container. >=20 > > If so, I think it > > would be easier (on the reader!) to say that instead. If not, I think > > that > > the term warrants a mention in section 7.5.1. >=20 > The term is "non-presence container", and it is explained in 7.5.1. >=20 >=20 > /martin >=20 >=20 >=20 --_52A8CF4B-F1BC-4195-A32E-88E8A6790C3F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

How about= =E2=80=9Cclosest ancestor node in the schema tree (excluding non-presence = containers)=E2=80=9D?

 

Jonathan

&nb= sp;

 

<= p style=3D'border:none;padding:0cm'>
From: Martin Bjorklund
Sent: 15 October 2015 13:39
To: jonathan@hansfords.net
Cc: wfl@cantab.net;netmod@ietf.org
Subject: Re: [netmod] not= a non-presence container

 

=  

Jonathan Hansford <jona= than@hansfords.net> wrote:

> If that misinter= pretation has already happened for (at least) one

&= gt; individual, would it be worth adding the clarification and remove the

> ambiguity?

 <= /o:p>

Sure.=C2=A0 The words "not a non-presenc= e container" occurs a couple of

times througho= ut the document.

 

Would it be correct to write "not a non-presence-container&quo= t;?

 

=  

/martin

&= nbsp;

 

 

>

= > Jonathan

>

>

>

> From: William Lup= ton

> Sent: 14 October 2015 23:28

> To: Martin Bjorklund

> Cc: netmod= @ietf.org

> Subject: Re: [netmod] not a non-pres= ence container

>

> <= /p>

> Thanks. I see now. As you will have realised, = I parsed "not a

> non-presence container&qu= ot; as "(not a non-presence) container" (WRONG)

> rather than "not a (non-presence container)" (RIGHT).= Cheers, W.

>

> On 1= 4 October 2015 at 20:41, Martin Bjorklund <mbj@tail-f.com> wrote:

=

> William Lupton <wfl@cantab.net> wrote:

<= p class=3DMsoNormal>> > All,

> >

> > Both RFC 6020 and the bis draft use the term &q= uot;not a non-presence

> > container", s= ometimes with a reference to section 7.5.1.

> &g= t;

> > Does this term mean the same as "= presence container"?

>

> No.  A list (for example) is not a non-presence container.

>

> > If so, I thi= nk it

> > would be easier (on the reader!) to= say that instead. If not, I think

> > that

> > the term warrants a mention in section 7.5= .1.

>

> The term is = "non-presence container", and it is explained in 7.5.1.

>

>

= > /martin

>

>

>

 

 

= --_52A8CF4B-F1BC-4195-A32E-88E8A6790C3F_-- From nobody Thu Oct 15 08:59:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7BA1A8951 for ; Thu, 15 Oct 2015 08:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVAaaHRGgWPu for ; Thu, 15 Oct 2015 08:59:24 -0700 (PDT) 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 C2BD41A8820 for ; Thu, 15 Oct 2015 08:59:23 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-6d-561fcd597c96 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.C8.05274.95DCF165; Thu, 15 Oct 2015 17:59:22 +0200 (CEST) Received: from [159.107.197.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Thu, 15 Oct 2015 17:59:21 +0200 To: Ladislav Lhotka References: <561F9509.4060008@ericsson.com> <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz> <561FA76B.5040401@ericsson.com> From: Balazs Lengyel Message-ID: <561FCD59.2050003@ericsson.com> Date: Thu, 15 Oct 2015 17:59:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW7UWfkwg89dTBYXVs1ls5h/sZHV gcljyZKfTB6bLt9hDGCK4rJJSc3JLEst0rdL4Mpo+tHOXHBWo2L64imMDYzf5LoYOTkkBEwk nvy5xgRhi0lcuLeerYuRi0NI4CijRNvlScwQzlpGiXWT77KBVAkLaEks+9jJAmKLCChLXJzw kwWiaDWjxLe5rxlBEswC6hJ3Tj0Ga2ATMJKY2n8erIFXQFviUvcJoDgHB4uAqsTpXl2QsKhA jMT7TasYIUoEJU7OfAJWzilgJTGp5yELSDmzgL3Eg61lENPlJba/ncMMYgsJaEg8vPCXdQKj 4Cwk3bMQOmYh6VjAyLyKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBYD275rbqD8fIbx0OM AhyMSjy8Czjkw4RYE8uKK3MPMUpzsCiJ8zYzPQgVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wMh44KWIiZSGYe7B1/FL+7Ysf/Dnq5RfoNWDG2ulSw1WvH51Pu2GucPNlUcP/RVbdeTXX6/y tVyrPnyZanzAylFC6LXW9Efb83RNPB1XPliY++7INoE5CzbNbavU0gv4dOR/38cXQsePhuo4 XEwoWyI/2ztQeGPaRUXbgwf+/zrBoLt3nvVX9/+8SizFGYmGWsxFxYkA+GhukTcCAAA= Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] The when-choice loop X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:59:26 -0000 Limiting when to augment doesn't really solve the issues, as you can augment in all the strange constructs instead of defining them locally. My ideas would be: - when MUST NOT be dependent on a data node controlled by another when or choice statement - choice SHOULD NOT be contained under a choice as the aggregate construct is hard to understand for a human user Anything more complicated is too hard to understand. As we know 50% of all downtime in a network is caused by operator erroros. So DO NOT ake it complicated!!!! regards Balazs On 2015-10-15 16:08, Ladislav Lhotka wrote: >> On 15 Oct 2015, at 15:17, Balazs Lengyel wrote: >> >> Hello Lada, >> So can we start gathering support for limiting when/choice to the simple cases by one of the 3 methods: >> 1) prohibit them (backward incompatible) > I would personally restrict the use of "when" only as a substatement of "augment". This would solve most issues, including Y18 (missing context node). I other cases, "must" can be often used instead of "when" with the same effect - at least for validation purposes. I am not sure that benefits of "when" outweigh the complexity - both in YANG spec and server implementation. > > I also think servers should not automatically delete nodes whose "when" expression becomes false. > > Lada > >> 2) create a guideline not to use them in 6087, (easy to do, better then nothing, but does not protect the application) >> 3) declaring them as implementation dependent, thus making them backward compatible, but unusable >> >> Complicated: In my view anytime a when or choice depends on another when or choice it is complicated. So use the simple cases only. >> regards Balazs >> >> On 2015-10-15 14:53, Ladislav Lhotka wrote: >>> Hi Balazs, >>> >>> one lesson taken from early XML schema languages (DTD) was that modifying the validated document during validation easily leads to nasty race conditions. That's why RELAX NG avoids changing the XML infoset like plague. >>> >>> I've already got tired reiterating (and providing examples) that "when" statement is inherently broken - the schema should not depend on evaluating arbitrary expressions in the context of an instance document that is supposed to be validated with the schema. The standard disclaimer is that it works for simple cases, and more complicated corner cases are "garbage in - garbage out". >>> >>> Lada >>> >>> P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its content is "false". So you'd need expressions like "not(../a2 = 'true')". >>> >>>> On 15 Oct 2015, at 13:59, Balazs Lengyel wrote: >>>> >>>> Hello, >>>> In RFC6020bis we write: >>>> "There MUST NOT be any circular dependencies in these "when" expressions." >>>> How about a circular when-choice loop? >>>> >>>> leaf a1 { >>>> type boolean; >>>> when not(../a2); >>>> } >>>> choice c2 { >>>> default case2; >>>> case case1 { >>>> when not(a1); >>>> leaf b1 {type int8;} >>>> } >>>> case case2 { >>>> leaf a2 { >>>> type boolean; >>>> default true; >>>> } >>>> } >>>> } >>>> >>>> Initial state: a1=false, b1=5; >>>> - Set a1=true >>>> - case1 and b1 disapears >>>> - case2 and a2=false are set as default >>>> - a1 disappears >>>> - if there is no a1 why did we delete case1/b1? >>>> Did I miss something, is this really what happens? >>>> >>>> Even if someone can come up with the correct solution, operators will be 100% sure to mess this up. Usability=0 !!! >>>> >>>> I want some of this multistep when/when, choice/choice, when/choice scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation is implementation dependent: that would make it unusable, so practically prohibiting then while maintaining backward compatibility :-) >>>> >>>> I attached an even more complicated example, so go ahead have fun understand it! >>>> regards Balazs >>>> >>>> PS: Why did we make YANG so complicated? >>>> >>>> -- >>>> Balazs Lengyel Ericsson Hungary Ltd. >>>> Senior Specialist >>>> ECN: 831 7320 >>>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Oct 15 09:00:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EA61A912F for ; Thu, 15 Oct 2015 09:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iFBMEwH_y9m for ; Thu, 15 Oct 2015 09:00:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4DBB1A916F for ; Thu, 15 Oct 2015 09:00:39 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A1D71AE0498; Thu, 15 Oct 2015 18:00:38 +0200 (CEST) Date: Thu, 15 Oct 2015 18:03:57 +0200 (CEST) Message-Id: <20151015.180357.1644539809319777532.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20151015.135334.2134677503217017095.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:00:42 -0000 Andy Bierman wrote: > On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > You are incorrect. > > > > > > Within the PAYLOAD (as this section describes), there is no when-stmt > > > for data nodes within the datastore. Look at the YANG for edit-config. > > > There are no when-stmts for "interface" in "edit-config". > > > > Andy, there is some confusion here. The section talks about: > > > > For configuration data, there are three windows when constraints > > MUST be enforced: > > > > - during parsing of RPC payloads > > - during processing of NETCONF operations > > - during validation > > > > So the entire section talks about constraints *on configuration data*. > > > > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 > > > Here is the YANG for edit-config? > Please point out the when-stmts in this rpc-stmt > specific to the "interface" node. > I just see an "anyxml" that has no when-stmts at all. > > So enforcing the when constraint on the RPC PAYLOAD > clearly has nothing to do with "interface" -- just the parameters > specified in the rpc-stmt. Ok, you're right. 8.2.1 should be kept as it is. (we may need to rephrase the intro text in 8.2) But I think Balazs is also right. Suppose you have: leaf a { when "../b = 42"; type int32; } leaf b { type int32; } and the db contains b=10. Suppose I send an edit-config with a=2. What is the result? 1) you get an error back 2) you get ok; the request to set a to 2 is silently dropped 3) something else /martin From nobody Thu Oct 15 09:55:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3961B3384 for ; Thu, 15 Oct 2015 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-GI5jtUhXkR for ; Thu, 15 Oct 2015 09:55:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316C61B3273 for ; Thu, 15 Oct 2015 09:54:58 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 16:54:52 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 16:54:52 +0000 From: Kent Watsen To: Robert Wilton , Jonathan Hansford , Andy Bierman Thread-Topic: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" Thread-Index: AQHRBybG8wzjh71d8k+95NmY8DUKcZ5sT5sAgAAzcAA= Date: Thu, 15 Oct 2015 16:54:52 +0000 Message-ID: References: <560D269E.30002@cisco.com> <561EC8E7.9080708@cisco.com> <561F76F2.8030609@cisco.com> In-Reply-To: <561F76F2.8030609@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:/RN4S8oGsfAtDg0SVCt3xWeBp4eDsEqDdI7CLHjYGbMY36ZgXCgpX2tIv3PU2n+35brYFe+vNgbisLsUGSNoRhPCEn9j6Cb61OgtvFY65wJ9cz5HpAb3+IcvNCTHQAhSXHoA3+mMzB5pzOt/oTgc8A==; 24:Tj04Fe9U59niEImNu3RZWHA81e+fz8bzfkAeoM9LLVmZYpRJCgCCsP3K1U/UyH1n+ihuT6Pt/ATxOvzgZJRfTUF/fpNz3bZTuYO4cr3s6f4=; 20:LDw8nTOErMDkA89pq5GTJzfZQQ/LusQsYcOsKqdx4wfHZKhuePeNEknnA7S3treuc0sDJH6Zu6ferpw3sabcKw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(199003)(164054003)(51444003)(76104003)(24454002)(377454003)(189002)(99286002)(46102003)(81156007)(64706001)(4001350100001)(106116001)(122556002)(40100003)(5002640100001)(92566002)(93886004)(16236675004)(11100500001)(5004730100002)(5007970100001)(15975445007)(10400500002)(102836002)(5008740100001)(5001960100002)(50986999)(106356001)(2950100001)(105586002)(2900100001)(76176999)(86362001)(101416001)(19625215002)(189998001)(19580405001)(5001770100001)(97736004)(19580395003)(83506001)(36756003)(54356999)(66066001)(87936001)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2455080E72F6kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 16:54:52.0836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:55:09 -0000 --_000_D2455080E72F6kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable These terms were edited on today's call, resulting in the following: * intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. * applied configuration - this data represents the configuration state that the network element is actually in. That is, the configuration state which is currently being used by system components (e.g., control plane daemons, operating system kernels, line cards). NOTE: The system's ability to report applied configuration accurate= ly may be limited in some cases, such as when the the configuration goes through an intermediate layer without an ability to inspect th= e lower layer. If no objection is raise by tomorrow, this issue will be moved to the EDIT state and I'll plan to make the change in the draft before Monday's cutoff. Kent From: Robert Wilton > Date: Thursday, October 15, 2015 at 5:50 AM To: Jonathan Hansford >, Kent Watsen >, Andy Bie= rman > Cc: "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl= ied configuration" Hi Jonathan, Yes, of course, in the general case your statement is completely true. I think that my premise would still hold if either: - there is coordination of the intended configuration between multiple NMS - responsibility for parts of the configuration is split between multiple = NMS and they are each independently responsible for ensuring that their par= t of the configuration has been programmed correctly. My point is really that I would more naturally expect the definitive config= uration for a device to be known and held (perhaps in a distributed fashion= ) somewhere in the operators management network, not on the device itself. Thanks, Rob On 15/10/2015 09:55, Jonathan Hansford wrote: The NMS only knows the intended config if it is the only NMS capable of cha= nging that device=92s config. That may not always be the case. Jonathan From: Robert Wilton Sent: 14 October 2015 22:28 To: Kent Watsen;Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appl= ied configuration" On 14/10/2015 20:15, Kent Watsen wrote: Andy writes: > I am wondering why operators would want to compare 2 massive subtrees > in the first place, where 1 is static and the other is changing constantl= y. > > Do they really want this complex task or do they just want to > determine if the intended config has been applied yet? I think that it is more the latter. And there have been suggestions for s= olutions to provide something like a yang-patch to describe just the diffs.= Makes sense to me! The NMS already knows the intended config since it sent it to the device in= the first place, so in normal circumstances I would expect the NMS to only= query the applied config (and possibly derived state at the same time) and= then compare it to the NMS's view of the intended cfg for that device. If= the NMS is smart then it might be able to restrict most of the queries to = only the device's applied config sub-trees that could possibly be out of sy= nc, perhaps with periodic full synchronization checks. Otherwise, I think that a function that returns just the diff may also be u= seful (the draft that I put forward also proposes a diff-cfg-only option). = However, it is also worth noting that the original requirements don't expl= icitly ask for this, so perhaps more of a nice to have than a formal requir= ement? Thanks, Rob K. From: Andy Bierman <andy@yumaworks.com> Date: Wednesday, October 14, 2015 at 2:56 PM To: Kent Watsen > Cc: Robert Wilton >, "netmod@ie= tf.org" > Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "app= lied configuration" On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <= kwatsen@juniper.net> wrote: Thank you Robert for bringing the discussion back to the github issues. Robert writes: > In particular: > - does it include support for templating (as per openconfig-netmod-ops= tate-01 section 7.3.)? > - is it allowed to represent system created objects that have no corre= sponding configuration? > > Requirement 1.D states D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. > > So, if this requirement statement stands as being valid (which I think it= should) then that would imply that the answer for both the two issues abov= e must be "no". The only question would be whether these need to be explic= itly listed out? [KENT] so I think I have to (begrudgingly) agree with your logic. I have= heard the operators state that they want the intended/applied comparison t= o be drop-dead simple. To that end, it would not be possible to flatten te= mplates or apply defaults, or make any other change =96 it needs to be as c= lose as possible to a carbon-copy of the original intended configuration (w= here deviations are allowed only for cases like a missing line-card). To t= his end, yes, I think that we could tack on a statement like the following: That is, the intended configuration is a subset of the applied configuration where omissions are only due to when the configuration cannot be applied (e.g., a missing line-card). What do you think? I am wondering why operators would want to compare 2 massive subtrees in the first place, where 1 is static and the other is changing constantly. Do they really want this complex task or do they just want to determine if the intended config has been applied yet? Andy >> - how does it relate to the state of the system after a equivalent sync= hronous config commit (if at all)? >> > Again, I think that definition of requirement 1.D, along with the propose= d definition of synchronous configuration operation vs asynchronous configu= ration operation, will provide a sufficient answer to this question. I.e. = that the state of the system after an asynchronous config operation must, w= hen fully synchronized, be the same as the state of the system after an equ= ivalent synchronous configuration operation completes and replies back. [KENT] I agree with this, but I think it impacts issue #6 more so than issu= e #4 - right? Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D2455080E72F6kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

These terms were edited on today's call, resulting in the following:

      * intended conf= iguration - this data represents the configuration 
        state th= at the network operator intends the system to be in, and 
        that has been accepted by the system as valid conf= iguration.

      * applied confi= guration - this data represents the configuration 
        state th= at the network element is actually in.  That is, the 
        configur= ation state which is currently being used by system 
        componen= ts (e.g., control plane daemons, operating system 
        kernels,= line cards). 

        NOTE: Th= e system's ability to report applied configuration accurately
        may be limited in some cases, such as when the the= configuration
     =   goes through an intermediate layer without an ability to inspect the
     =   lower layer.

If no objection is raise by tomorrow, this issue will be moved to the =
EDIT state and I'll plan to make the change in the draft before Monday's
cutoff.

Kent


From: Robert Wilton <rwilton@cisco.com>
Date: Thursday, October 15, 2015 at= 5:50 AM
To: Jonathan Hansford <jonathan@hansfords.net>, Kent Wat= sen <kwatsen@juniper.net>,= Andy Bierman <andy@yumaworks.com<= /a>>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #4: Provide a tighter definition of"applied configuration"

Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multipl= e NMS
 - responsibility for parts of the configuration is split between mult= iple NMS and they are each independently responsible for ensuring that thei= r part of the configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive config= uration for a device to be known and held (perhaps in a distributed fashion= ) somewhere in the operators management network, not on the device itself.<= br>
Thanks,
Rob


On 15/10/2015 09:55, Jonathan Hansford wrote= :

The NMS only knows the intended config if it is the only NMS capable of = changing that device=92s config. That may not always be the case.

 

Jonathan

 

 


From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition = of"applied configuration"

 

 

 

On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:=

> I am wondering= why operators would want to compare 2 massive subtrees

> in the first p= lace, where 1 is static and the other is changing constantly.

> 

> Do they really= want this complex task or do they just want to

> determine if t= he intended config has been applied yet?

 

I think that it is = more the latter.   And there have been suggestions for solutions to pr= ovide something like a yang-patch to describe just the diffs.  Makes s= ense to me!


The NMS already knows the intended config since it sent it to the device in= the first place, so in normal circumstances I would expect the NMS to only= query the applied config (and possibly derived state at the same time) and= then compare it to the NMS's view of the intended cfg for that device.  If the NMS is smart then it mig= ht be able to restrict most of the queries to only the device's applied con= fig sub-trees that could possibly be out of sync, perhaps with periodic ful= l synchronization checks.

Otherwise, I think that a function that returns just the diff may also be u= seful (the draft that I put forward also proposes a diff-cfg-only option).&= nbsp; However, it is also worth noting that the original requirements don't= explicitly ask for this, so perhaps more of a nice to have than a formal requirement?

Thanks,
Rob



 

K.

 

 

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition = of "applied configuration"

 

 

 

On Wed, Oct 14, 201= 5 at 11:00 AM, Kent Watsen <kwatsen@juniper.net> wrote:

 

Thank you Robert fo= r bringing the discussion back to the github issues.

 

Robert writes:=

 

> In particular:=

>    -= does it include support for templating (as per openconfig-netmod-opstate-0= 1 section 7.3.)?

>    -= is it allowed to represent system created objects that have no correspondi= ng configuration?

>
> Requirement 1.D states

   =
  D.  For asynchronous systems, when fully synchronized, the data=

   =
        in the applied configuration is =
the same as the data in the
   =
        intended configuration.

>
> So, if this requirement statement stands as being valid (which I think= it should) then that would imply that the answer for both the two issues a= bove must be "no".  The only question would be whether these= need to be explicitly listed out?<= o:p>

[KENT] so I think I= have to (begrudgingly) agree with your logic.    I have heard th= e operators state that they want the intended/applied comparison to be drop= -dead simple.  To that end, it would not be possible to flatten templates or apply defaults, or make any other change =96 it ne= eds to be as close as possible to a carbon-copy of the original intended co= nfiguration (where deviations are allowed only for cases like a missing lin= e-card).  To this end, yes, I think that we could tack on a statement like the following:

 

That is, the intend= ed configuration is a subset of the applied 

configuration where= omissions are only due to when the

configuration canno= t be applied (e.g., a missing line-card).

 

What do you think?<= o:p>

 

 

I am wondering why = operators would want to compare 2 massive subtrees

in the first place,= where 1 is static and the other is changing constantly.<= /p>

 

Do they really want= this complex task or do they just want to

determine if the in= tended config has been applied yet?

 

 

Andy

 

 

 

 

>>  - ho= w does it relate to the state of the system after a equivalent synchronous = config commit (if at all)?

>>
> Again, I think that definition of requirement 1.D, along with the prop= osed definition of synchronous configuration operation vs asynchronous conf= iguration operation, will provide a sufficient answer to this question.&nbs= p; I.e. that the state of the system after an asynchronous config operation must, when fully synchronized, be the sam= e as the state of the system after an equivalent synchronous configuration = operation completes and replies back.

 

[KENT] I agree with= this, but I think it impacts issue #6 more so than issue #4 - right?<= /o:p>

 

 

Thanks,<= /span>

Kent

 

 


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

 

 

 

 =


--_000_D2455080E72F6kwatsenjunipernet_-- From nobody Thu Oct 15 10:04:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDF1ACD6F for ; Thu, 15 Oct 2015 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E-eT7LLdGlR4 for ; Thu, 15 Oct 2015 10:03:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7301A8AD0 for ; Thu, 15 Oct 2015 10:03:55 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 17:03:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 17:03:33 +0000 From: Kent Watsen To: Gert Grammel , Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgA Date: Thu, 15 Oct 2015 17:03:33 +0000 Message-ID: References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> <561FB149.103@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; BN1PR05MB041; 5:gOnYRsr3ShUhM/WvoRlHQbCypepOxQvzAp1zXn34pp9kzrf/GvpjR2yOvJYTwIv+032rHlqNCrsfPsvAy2hPMiJLzJybr3ZOH12Pa9jfZyqoB95uRJogJltcJng5Ug1W4I5+epAVFlfmCkNOYAVT8A==; 24:b341FOTdsz1cV0nvFXDn/M4Q5qaB4czBHszDjvzqXj86AcvTIq4Mli4zXKwTLEsCIJxSmJHKKzLcxSJiqAZ2hBM3znEVXFZ/oNWCZwAR5j4=; 20:IOXq+kgD/pKa9n/BxwuftqyHVOBzwnMgoNgzquBSbiwHBt5QAR1FhsW2W7utI82LGuPx27DkIysFjg/IGQUF9A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:BN1PR05MB041; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB041; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(53754006)(377454003)(199003)(24454002)(52314003)(479174004)(505384003)(76104003)(164054003)(51444003)(19580405001)(66066001)(5002640100001)(5008740100001)(19617315012)(107886002)(64706001)(561944003)(99286002)(106116001)(97736004)(189998001)(5001770100001)(16236675004)(2501003)(86362001)(46102003)(15975445007)(36756003)(102836002)(101416001)(2900100001)(4001350100001)(105586002)(106356001)(1941001)(93886004)(5004730100002)(122556002)(50986999)(10400500002)(83506001)(19580395003)(40100003)(81156007)(5007970100001)(87936001)(2950100001)(5001960100002)(54356999)(76176999)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB041; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D245533FE730Ckwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 17:03:33.2261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB041 Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:04:06 -0000 --_000_D245533FE730Ckwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable These terms were edited on today's call, resulting in the following text: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously wit= h respect to the client request. The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see term= s), before replying to the client. This may be transactional or non- transactional (need terms!). The transactionality of the operation may be a server property or specified on as a property. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to updat= e the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intende= d configuration (see term) before replying to the client indicating whether the request will be processed. This reply to the client only indicates whether there are any errors in the original request. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. Once applied, there MUST be a mechanism for the client = to determine when the request has completed processing and whether the intended config is now fully effective or there are any errors from applying the configuration change, which could be from an asynchronous notification or via a client operation. Synchronous configuration server - a configuration server that processe= s all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that process= es all configuration operations as asynchronous configuration operations. We have consensus on the above, but are hoping for some word-smithing befor= e committing it to the draft. Anybody want to take a crack at it? BTW, do we still need to define the last two terms anymore? - they're not = used elsewhere in the draft... Kent From: Gert Grammel > Date: Thursday, October 15, 2015 at 10:35 AM To: Robert Wilton >, Kent Watse= n >, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Rob, >From a client perspective a server has three states: 1. intended !=3D applied 2. Funny-state 3. Intended =3D=3D applied Irrespective of synchronous or asynchronous processing in the server, the t= hird state MUST be reported to the client. Else (from a client perspective)= the server stays in funny-state forever. Gert From: Robert Wilton > Date: Thursday 15 October 2015 15:59 To: Gert Grammel >, Kent = Watsen >, "netmod@ietf.org<= mailto:netmod@ietf.org>" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Gert, Kent, I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way. E.g. if the = information as to whether a particular intended leave had been successfully= applied was available (e.g. as per github issue #2). So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.: E.g. replacing: Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange. Perhaps with: Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change. Or: Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change. Thanks, Rob On 15/10/2015 12:17, Gert Grammel wrote: Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn=92t look= complete. The way it stands for the synchronous operation, the client know= s that it's intended config was good AND it has been effected to the server= . In the Asynchronous case, the client only knows that the intended config = was good =96 and that=92s not enough. So the proposal is to refine the asynchronous case definition as follows: Asynchronous configuration operation - A configuration request to update th= e running configuration of a server that is applied asynchronously with res= pect to the client request. The server MUST update its intended configurat= ion (see term) before replying to the client indicating whether the request= will be processed. The reply to the client only indicates whether there a= re any errors in the original request. The server's applied configuration state (see term) is updated after the co= nfiguration change has been applied to all impacted components in the serve= r. Once applied, the client MUST be notified whether the intended config i= s now fully effective or there are any errors from applying the configurati= on change. In addition I would suggest to require a verify operation which a client ca= n request from the server to obtain above information on an on-demand basis= . Would that somehow go in the opstate-reqs #3 then? Best Gert From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen > Date: Thursday 15 October 2015 00:11 To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Robert, One comment, it seems that the asynchronous configuration operation should have one more sentence at its end saying that an asynchronous notification must be used to report any errors produced from when applying the configuration. What do you think? Kent // as a contributor On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@c= isco.com> wrote: Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... Works for me. Sometimes less is more. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Depends on the definition of applied configuration - where is the latest version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D245533FE730Ckwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <231820DD4F78E14A9950516A5C44FE57@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
These terms were edited on today's call, resulting in the following te= xt:

    Synchronous configurat= ion operation - A configuration request to update
    the running configurat= ion of a server that is applied synchronously with
    respect to the client = request.  The server MUST fully attempt to apply 
    the configuration chan= ge to all impacted components in the server,
    updating both the serv= er's intended and applied configuration (see terms),
    before replying to the= client.  This may be transactional or non-
    transactional (need te= rms!).  The transactionality of the operation
    may be a server proper= ty or specified on as a property.
    The reply to the clien= t indicates whether there
    are any errors in the = request or errors from applying the configuration
    change.
    
    Asynchronous configura= tion operation - A configuration request to update
    the running configurat= ion of a server that is applied asynchronously
    with respect to the cl= ient request.  The server MUST update its intended
    configuration (see ter= m) before replying to the client indicating
    whether the request wi= ll be processed.  This reply to the client only
    indicates whether ther= e are any errors in the  original request.  The
    server's applied confi= guration state (see term) is updated after the
    configuration change h= as been fully effected to all impacted components
    in the server.  O= nce applied, there MUST be a mechanism for the client to
    determine when the req= uest has completed processing and whether the
    intended config is now= fully effective or there are any errors from
    applying the configura= tion change, which could be from an asynchronous
    notification or via a = client operation.

    Synchronous configurat= ion server - a configuration server that processes
    all configuration oper= ations as synchronous configuration operations.
    
    Asynchronous configura= tion server - a configuration server that processes
    all configuration oper= ations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing befor= e committing it to the draft.  Anybody want to take a crack at it?

BTW, do we still need to define the last two terms anymore?  - they're= not used elsewhere in the draft...

Kent



From: Gert Grammel <ggrammel@juniper.net>
Date: Thursday, October 15, 2015 at= 10:35 AM
To: Robert Wilton <rwilton@cisco.com>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Rob,

From a client perspective a server has three states: 
  1. intended !=3D applied
  2. Funny-state
  3. Intended =3D=3D appli= ed
Irrespective of synchronous or asynchronous processing in the server, = the third state MUST be reported to the client. Else (from a client perspec= tive) the server stays in funny-state forever.


Gert


From: Robert Wilton <rwilton@cisco.com>
Date: Thursday 15 October 2015 15:5= 9
To: Gert Grammel <ggrammel@juniper.net>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way.  E.g. if= the information as to whether a particular intended leave had been success= fully applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change.

Or:

Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change.

Thanks,
Rob


On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn=92t= look complete. The way it stands for the synchronous operation, the client= knows that it's intended config was good AND it has been effected to the s= erver. In the Asynchronous case, the client only knows that the intended config was good =96 and that=92s not e= nough.

So the proposal is to refine the asynchronous case definition as follo= ws:

Asynchronous configuration operation - A configuration request to upda= te the running configuration of a server that is applied asynchronously wit= h respect to the client request.  The server MUST update its inte= nded configuration (see term) before replying to the client indicating whether the request will be processed.  The = reply to the client only indicates whether there are any errors in the &nbs= p;original request.
The server's applied configuration state (see term) is updated after t= he configuration change has been applied to all impacted components in the = server.  Once applied, the client MUST be notified whether the intende= d config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a clie= nt can request from the server to obtain above information on an on-demand = basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@iet= f.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Thursday 15 October 2015 00:1= 1
To: Robert Wilton <rwilton@cisco.com>= , "netmod@= ietf.org" <netmod@iet= f.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation sh= ould
have one more sentence at its end saying that an asynchronous notifica= tion
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wro= te:

Hi All,

Are there any more comments on the following proposed descriptions, or=
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to updat= e
the running configuration of a server that is applied synchronously wi= th
respect to the client request.  The server MUST fully effect= the
configuration change to all impacted components in the server, updatin= g
both the server's intended and applied configuration (see terms), befo= re
replying to the client.  The reply to the client indicates w= hether there
are any errors in the request or errors from applying the configuratio= n
change.

Asynchronous configuration operation - A configuration request to upda= te
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update = its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied=
configuration state (see term) is updated after the configuration chan= ge
has been fully effected to all impacted components in the server. = ; The
reply to the client only indicates whether there are any errors in the=
original request.

Synchronous configuration server - a configuration server that process= es
all configuration operations as synchronous configuration operations.<= /div>

Asynchronous configuration server - a configuration server that proces= ses
all configuration operations as asynchronous configuration operations.=

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure tha= t the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.<= /div>
The reply to the client indicates whether there are any errors in the<= /div>
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RF= C 6020
says:

     When datastore processing is complete, the fi= nal contents MUST
obey
     all validation constraints.  This v= alidation processing is
performed
     at differing times according to the datastore= .  If the datastore
is
     <running/> or <startup/>, these c= onstraints MUST be enforced at
the
     end of the <edit-config> or <copy-co= nfig> operation.  If the
     datastore is <candidate/>, the constrai= nt enforcement is delayed
     until a <commit> or <validate> op= eration.

Are we talking about datastore validation or validation of a request?<= /div>
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validat= e"
would exclude an ephemeral datastore, so I was trying to water down th= e
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration s= erver that processes
    some configuration operations as synchronous c= onfiguration
    operations and some configuration operations a= s asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy=
that in real systems, depending on the data model, certain parts of a<= /div>
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration= - this data represents the configuration
        state that the network= operator intends the system to be in, and
that
        has been accepted by t= he system as valid configuration.  This
data is
        colloquially referred = to as the 'configuration' of the system.

       applied configuration - this data= represents the configuration
        state that the network= element is actually in, i.e., the
        configuration state wh= ich is currently being being used by
system
        components (e.g., cont= rol plane daemons, operating system
        kernels, line cards).<= /div>
Well, sometimes the config goes to a control plane daemon and then to<= /div>
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that= the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if = that means
that the definition of applied configuration should be strengthened, o= r
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from<= /div>
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to<= /div>
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended=
config and then report the result of the guess work as applied config<= /div>
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price=
for this applied config idea, I have no real problem with this since I=
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list


 --_000_D245533FE730Ckwatsenjunipernet_-- From nobody Thu Oct 15 10:22:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2AD1ACDD4 for ; Thu, 15 Oct 2015 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrSGgybj84CG for ; Thu, 15 Oct 2015 10:22:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51CF1ACDD0 for ; Thu, 15 Oct 2015 10:22:40 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB314.namprd05.prod.outlook.com (10.141.69.144) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 15 Oct 2015 17:22:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 17:22:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 17:22:37 +0000 From: Kent Watsen To: Nadeau Thomas Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wA= Date: Thu, 15 Oct 2015 17:22:37 +0000 Message-ID: References: <20150922142254.GB99134@elstar.local> <20150922170012.GA99454@elstar.local> <56027D26.8020801@cisco.com> <20150928084013.GB95620@elstar.local> <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com> In-Reply-To: <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:8SeUYWcS4gc32KpOapA8oNNsEKrkH1MB2RVaMeg55087aKtbhrfeE9k2OSed24NSWf4ccZp4ezTA3+Jc2eUYbiSjnjGJRtPxlW7hXDlVlqG00tZ1ohNoARaeKAooeUB3khrM1iZ6Ei+fCMis2Wzsqw==; 24:x11LL3/ZCT4P+RbPFiBXIvsmqXc0IiX9wCa8rOBdbCqv0YOodEJg7/LrBMZCYUFTK8R2/RAg/COgtlmov6b6Ej6zU3uPuSDbrprsAkFSCOw=; 20:+j3O+nYgcz/zHkyF/6wrngTG0iWLAlShBW9PnF9+e7EBirrWRU8D2+eQqCIwiZI1P5HS7rogzKqv8qMiED1I9Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(199003)(479174004)(51444003)(164054003)(52314003)(122556002)(106356001)(86362001)(66066001)(10400500002)(106116001)(40100003)(189998001)(5002640100001)(5001960100002)(87936001)(93886004)(5008740100001)(101416001)(4001350100001)(81156007)(97736004)(54356999)(50986999)(105586002)(2900100001)(102836002)(11100500001)(83506001)(110136002)(19580405001)(64706001)(5004730100002)(19580395003)(36756003)(99286002)(46102003)(92566002)(2950100001)(76176999)(15975445007)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <3EF4D7AC73FD304E8CF15F858F910B26@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 17:22:37.3263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB314; 2:1LA6PW1tLmCSWq2NZzCrtiY1jp739Q+9jf12ayNYvOz9ZRCP5+P4PEfQoguhsxJVusQ0o0uzTfBBM9uZIR5JSRFBQ7ygTgKLnlpwB08IB4jYsoB+gc6rR6vSwyMWoQcJe6n5DCmpaL0KTqkPDHFzmRVbt8BY8Bgk6rqjZy2tLGE=; 23:VPyAzZT2gH8cnLlMkyq0ukJOEdjpguuPYP2QQns0gEyKGiUhCRIMelkmxZ3oxWzxoSOYIul3/4iiaavlYN8MINQZKnMfw36jmCLwxhgR9vq0fU5A5aRk3+7IjSkDHsv8+lByRtggAt5QdtDZ+gmpB/NgKUh5G9EYPKngABs/CsP4jFiqu4D44KX1JdP+YOO7 X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:22:45 -0000 Requirement #3 was discussed on today's call. We agreed to remove the words "distributed" and "transactional" and to reword it in terms of "configuration operations". The resulting text follows: 3. Support for both synchronous and asynchronous configuration operations (see terms) A. A server may only support synchronous configuration operations, or may only support asynchronous configuration operations, or may support synchronicity to be client specified on a per-operation basis. C. Support for synchronous configuration operations requires the server to block sending a response to the client until it is able to able to determine whether there are any errors in the request or errors from applying the configuration change. =20 D. Support for asynchronous configuration operations requires the server to send a response to the client immediately indicated that the request was accepted and send a notification to the client when the intended config is fully=20 effective or there are any errors from applying the configuration change. E. Support for asynchronous configuration operations MAY also provide a verify operation which a client can request from the server to obtain information regarding the difference between the intended and applied configurations. We have consensus on the above, but wanted to rewrite it relying more on the terms from the Terminology section, and also potentially merge E into D.=20 Anybody want to take a stab at it? Thanks, Kent On 10/14/15, 8:00 PM, "Nadeau Thomas" wrote: > >> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen >>wrote: >>=20 >>=20 >>=20 >> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder" >> wrote: >>=20 >>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote: >>>>=20 >>>> Popping the stack on this issue, the issue remains as to what to do >>>> with requirement 3: >>>>=20 >>>> 3. Support for both transactional, synchronous management systems >>>> as well as distributed, asynchronous management systems >>>>=20 >>>=20 >>> I fail to understand 'transactional' and 'distributed' here. >>=20 >> I hope that these terms will be clarified on tomorrow's call. There is >> also a chance that these terms will be removed from the text altogether, >> as they may be viewed as unnecessarily qualify the >> synchronous/asynchronous terms. >>=20 >>=20 >>> And >>> frankly, I am not sure why the management _systems_ are classified to >>> be synchronous or asynchronous - I think we are talking about >>> protocols between a management system and a device. >>=20 >>=20 >> Aye, I didn't see that before. >>=20 >> First off, elsewhere in the draft the term "system" is used 7 times to >> refer to the device (e.g., NC/RC server). The term "system" is >>otherwise >> not defined. >>=20 >> But to your main point, we have been discussing the terms a/synchronous >>to >> have to do with internal server processing of an edit request, but in >>'3' >> the terms are being used to qualify a management system, which can't be >> right. I think that '3' should be rewritten to be a statement about >> devices, not a statement about management systems. > > It might be better to frame this in terms of a client and a >server. > > =8BTom > > >> Anyway, I am not sure 3. is properly worded until someone defines >>> 'transactional', 'distributed', 'synchronous management systems' and >>> 'asynchronous management systems'. >>=20 >> The agenda for tomorrow's interim! :) >>=20 >>=20 >> Kent >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Oct 15 10:33:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4AE1ACED8 for ; Thu, 15 Oct 2015 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4-B2vg27wt3 for ; Thu, 15 Oct 2015 10:32:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5A91ACECD for ; Thu, 15 Oct 2015 10:32:56 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 17:32:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 17:32:55 +0000 From: Kent Watsen To: Kent Watsen , Nadeau Thomas Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgA== Date: Thu, 15 Oct 2015 17:32:55 +0000 Message-ID: References: <20150922142254.GB99134@elstar.local> <20150922170012.GA99454@elstar.local> <56027D26.8020801@cisco.com> <20150928084013.GB95620@elstar.local> <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:cOFPvc/xlHQpxOAW1WFRtBT535URogRrQTx1GM2hEfN3rIyDj6f5L7JA7J1k8BZvFKpF2iXn3StRcb1GMzFwZlsl88tS3KKa/A1Z8BPO2BaLEBkkeonocomDUk4C3VZB6S5K/XFYKEsP2aGzeTp6YQ==; 24:sw83lgpmaw32ly7SM2/0hxeOzdQI4BVMzP0YoEn0tEGnYeQr4jN/Jb1mXYwXyymLwWlvYGPChbwgiJIoj+kB8lkWf/GPWGr1SpjzXG2LLZg=; 20:wp7ngqaMNTepxKrfnWdc5LCnEwJcpiFGw2OQtjVq23+OqHaL1pPab9uwKtR3P06O1acSm+2+WXCbFOHLS5+RXQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(199003)(164054003)(51444003)(24454002)(377454003)(189002)(52314003)(99286002)(46102003)(81156007)(64706001)(4001350100001)(106116001)(122556002)(40100003)(93886004)(92566002)(11100500001)(5004730100002)(5007970100001)(15975445007)(5002640100001)(102836002)(5008740100001)(5001960100002)(10400500002)(50986999)(106356001)(2950100001)(105586002)(2900100001)(76176999)(86362001)(101416001)(1941001)(189998001)(5001770100001)(19580405001)(97736004)(19580395003)(83506001)(36756003)(54356999)(66066001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <7C4BD3DF8529354F88C693A95CAB91EF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 17:32:55.1830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:33:04 -0000 QWdhaW4sIHdpdGggYmV0dGVyIGZvcm1hdHRpbmcgZm9yIHRoZSBsaXN0Og0KDQogICAzLiAgU3Vw cG9ydCBmb3IgYm90aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24N CiAgICAgICBvcGVyYXRpb25zIChzZWUgdGVybXMpDQoNCiAgICAgICBBLiBBIHNlcnZlciBtYXkg b25seSBzdXBwb3J0IHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgICBvcGVyYXRp b25zLCBvciBtYXkgb25seSBzdXBwb3J0IGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uDQogICAg ICAgICAgb3BlcmF0aW9ucywgb3IgbWF5IHN1cHBvcnQgc3luY2hyb25pY2l0eSB0byBiZSBjbGll bnQNCiAgICAgICAgICBzcGVjaWZpZWQgb24gYSBwZXItb3BlcmF0aW9uIGJhc2lzLg0KDQoNCiAg ICAgICBDLiBTdXBwb3J0IGZvciBzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMN CiAgICAgICAgICByZXF1aXJlcyB0aGUgc2VydmVyIHRvIGJsb2NrIHNlbmRpbmcgYSByZXNwb25z ZSB0bw0KICAgICAgICAgIHRoZSBjbGllbnQgdW50aWwgaXQgaXMgYWJsZSB0byBhYmxlIHRvIGRl dGVybWluZSB3aGV0aGVyDQogICAgICAgICAgdGhlcmUgYXJlIGFueSBlcnJvcnMgaW4gdGhlIHJl cXVlc3Qgb3IgZXJyb3JzIGZyb20NCiAgICAgICAgICBhcHBseWluZyB0aGUgY29uZmlndXJhdGlv biBjaGFuZ2UuDQogICAgDQogICAgICAgRC4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZp Z3VyYXRpb24gb3BlcmF0aW9ucw0KICAgICAgICAgIHJlcXVpcmVzIHRoZSBzZXJ2ZXIgdG8gc2Vu ZCBhIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQNCiAgICAgICAgICBpbW1lZGlhdGVseSBpbmRpY2F0 ZWQgdGhhdCB0aGUgcmVxdWVzdCB3YXMgYWNjZXB0ZWQNCiAgICAgICAgICBhbmQgc2VuZCBhIG5v dGlmaWNhdGlvbiB0byB0aGUgY2xpZW50IHdoZW4gdGhlIGludGVuZGVkDQogICAgICAgICAgY29u ZmlnIGlzIGZ1bGx5IGVmZmVjdGl2ZSBvciB0aGVyZSBhcmUgYW55IGVycm9ycyBmcm9tDQogICAg ICAgICAgYXBwbHlpbmcgdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdlLg0KDQogICAgICAgRS4gU3Vw cG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBNQVkNCiAgICAg ICAgICBhbHNvIHByb3ZpZGUgYSB2ZXJpZnkgb3BlcmF0aW9uIHdoaWNoIGEgY2xpZW50IGNhbiBy ZXF1ZXN0DQogICAgICAgICAgZnJvbSB0aGUgc2VydmVyIHRvIG9idGFpbiBpbmZvcm1hdGlvbiBy ZWdhcmRpbmcgdGhlDQogICAgICAgICAgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBpbnRlbmRlZCBh bmQgYXBwbGllZCBjb25maWd1cmF0aW9ucy4NCg0KDQpLZW50DQoNCg0KDQpPbiAxMC8xNS8xNSwg MToyMiBQTSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4N Cj5SZXF1aXJlbWVudCAjMyB3YXMgZGlzY3Vzc2VkIG9uIHRvZGF5J3MgY2FsbC4gICBXZSBhZ3Jl ZWQgdG8gcmVtb3ZlIHRoZQ0KPndvcmRzICJkaXN0cmlidXRlZCIgYW5kICJ0cmFuc2FjdGlvbmFs IiBhbmQgdG8gcmV3b3JkIGl0IGluIHRlcm1zIG9mDQo+ImNvbmZpZ3VyYXRpb24gb3BlcmF0aW9u cyIuICBUaGUgcmVzdWx0aW5nIHRleHQgZm9sbG93czoNCj4NCj4NCj4gICAzLiAgU3VwcG9ydCBm b3IgYm90aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCj5vcGVy YXRpb25zIChzZWUgdGVybXMpDQo+DQo+ICAgICAgIEEuIEEgc2VydmVyIG1heSBvbmx5IHN1cHBv cnQgc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLA0KPm9yIG1heSBvbmx5IHN1 cHBvcnQNCj4gICAgICAgICAgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywg b3IgbWF5IHN1cHBvcnQNCj5zeW5jaHJvbmljaXR5IHRvIGJlIGNsaWVudA0KPiAgICAgICAgICBz cGVjaWZpZWQgb24gYSBwZXItb3BlcmF0aW9uIGJhc2lzLg0KPg0KPg0KPiAgICAgICBDLiBTdXBw b3J0IGZvciBzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgcmVxdWlyZXMgdGhl DQo+c2VydmVyIHRvIGJsb2NrDQo+ICAgICAgICAgIHNlbmRpbmcgYSByZXNwb25zZSB0byB0aGUg Y2xpZW50IHVudGlsIGl0IGlzIGFibGUgdG8gYWJsZSB0bw0KPmRldGVybWluZSB3aGV0aGVyDQo+ ICAgICAgICAgIHRoZXJlIGFyZSBhbnkgZXJyb3JzIGluIHRoZSByZXF1ZXN0IG9yIGVycm9ycyBm cm9tIGFwcGx5aW5nIHRoZQ0KPmNvbmZpZ3VyYXRpb24NCj4gICAgICAgICAgY2hhbmdlLg0KPiAg ICANCj4gICAgICAgRC4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucyByZXF1aXJlcyB0aGUNCj5zZXJ2ZXIgdG8gc2VuZA0KPiAgICAgICAgICBhIHJlc3Bv bnNlIHRvIHRoZSBjbGllbnQgaW1tZWRpYXRlbHkgaW5kaWNhdGVkIHRoYXQgdGhlIHJlcXVlc3QN Cj53YXMgYWNjZXB0ZWQNCj4gICAgICAgICAgYW5kIHNlbmQgYSBub3RpZmljYXRpb24gdG8gdGhl IGNsaWVudCB3aGVuIHRoZSBpbnRlbmRlZCBjb25maWcNCj5pcyBmdWxseSANCj4gICAgICAgICAg ZWZmZWN0aXZlIG9yIHRoZXJlIGFyZSBhbnkgZXJyb3JzIGZyb20gYXBwbHlpbmcgdGhlDQo+Y29u ZmlndXJhdGlvbiBjaGFuZ2UuDQo+DQo+ICAgICAgIEUuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91 cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgTUFZIGFsc28NCj5wcm92aWRlIGEgdmVyaWZ5DQo+ ICAgICAgICAgIG9wZXJhdGlvbiB3aGljaCBhIGNsaWVudCBjYW4gcmVxdWVzdCBmcm9tIHRoZSBz ZXJ2ZXIgdG8gb2J0YWluDQo+aW5mb3JtYXRpb24NCj4gICAgICAgICAgcmVnYXJkaW5nIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkDQo+Y29uZmlndXJhdGlv bnMuDQo+DQo+DQo+DQo+V2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIGFib3ZlLCBidXQgd2FudGVk IHRvIHJld3JpdGUgaXQgcmVseWluZyBtb3JlIG9uDQo+dGhlIHRlcm1zIGZyb20gdGhlIFRlcm1p bm9sb2d5IHNlY3Rpb24sIGFuZCBhbHNvIHBvdGVudGlhbGx5IG1lcmdlIEUgaW50bw0KPkQuIA0K Pg0KPkFueWJvZHkgd2FudCB0byB0YWtlIGEgc3RhYiBhdCBpdD8NCj4NCj5UaGFua3MsDQo+S2Vu dA0KPg0KPg0KPg0KPk9uIDEwLzE0LzE1LCA4OjAwIFBNLCAiTmFkZWF1IFRob21hcyIgPHRuYWRl YXVAbHVjaWR2aXNpb24uY29tPiB3cm90ZToNCj4NCj4+DQo+Pj4gT24gT2N0IDE0LCAyMDE1Ojc6 NTEgUE0sIGF0IDc6NTEgUE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPj4+ d3JvdGU6DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gOS8yOC8xNSwgMTo0MCBBTSwgIkp1ZXJn ZW4gU2Nob2Vud2FlbGRlciINCj4+PiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPiB3cm90ZToNCj4+PiANCj4+Pj4gT24gV2VkLCBTZXAgMjMsIDIwMTUgYXQgMDM6MDM6NTdQ TSArMDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IFBvcHBpbmcgdGhlIHN0 YWNrIG9uIHRoaXMgaXNzdWUsIHRoZSBpc3N1ZSByZW1haW5zIGFzIHRvIHdoYXQgdG8gZG8NCj4+ Pj4+IHdpdGggcmVxdWlyZW1lbnQgMzoNCj4+Pj4+IA0KPj4+Pj4gICAzLiAgU3VwcG9ydCBmb3Ig Ym90aCB0cmFuc2FjdGlvbmFsLCBzeW5jaHJvbm91cyBtYW5hZ2VtZW50IHN5c3RlbXMNCj4+Pj4+ ICAgICAgICBhcyB3ZWxsIGFzIGRpc3RyaWJ1dGVkLCBhc3luY2hyb25vdXMgbWFuYWdlbWVudCBz eXN0ZW1zDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IEkgZmFpbCB0byB1bmRlcnN0YW5kICd0cmFuc2Fj dGlvbmFsJyBhbmQgJ2Rpc3RyaWJ1dGVkJyBoZXJlLg0KPj4+IA0KPj4+IEkgaG9wZSB0aGF0IHRo ZXNlIHRlcm1zIHdpbGwgYmUgY2xhcmlmaWVkIG9uIHRvbW9ycm93J3MgY2FsbC4gICBUaGVyZQ0K Pj4+aXMNCj4+PiBhbHNvIGEgY2hhbmNlIHRoYXQgdGhlc2UgdGVybXMgd2lsbCBiZSByZW1vdmVk IGZyb20gdGhlIHRleHQNCj4+PmFsdG9nZXRoZXIsDQo+Pj4gYXMgdGhleSBtYXkgYmUgdmlld2Vk IGFzIHVubmVjZXNzYXJpbHkgcXVhbGlmeSB0aGUNCj4+PiBzeW5jaHJvbm91cy9hc3luY2hyb25v dXMgdGVybXMuDQo+Pj4gDQo+Pj4gDQo+Pj4+IEFuZA0KPj4+PiBmcmFua2x5LCBJIGFtIG5vdCBz dXJlIHdoeSB0aGUgbWFuYWdlbWVudCBfc3lzdGVtc18gYXJlIGNsYXNzaWZpZWQgdG8NCj4+Pj4g YmUgc3luY2hyb25vdXMgb3IgYXN5bmNocm9ub3VzIC0gSSB0aGluayB3ZSBhcmUgdGFsa2luZyBh Ym91dA0KPj4+PiBwcm90b2NvbHMgYmV0d2VlbiBhIG1hbmFnZW1lbnQgc3lzdGVtIGFuZCBhIGRl dmljZS4NCj4+PiANCj4+PiANCj4+PiBBeWUsIEkgZGlkbid0IHNlZSB0aGF0IGJlZm9yZS4NCj4+ PiANCj4+PiBGaXJzdCBvZmYsIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQgdGhlIHRlcm0gInN5c3Rl bSIgaXMgdXNlZCA3IHRpbWVzIHRvDQo+Pj4gcmVmZXIgdG8gdGhlIGRldmljZSAoZS5nLiwgTkMv UkMgc2VydmVyKS4gIFRoZSB0ZXJtICJzeXN0ZW0iIGlzDQo+Pj5vdGhlcndpc2UNCj4+PiBub3Qg ZGVmaW5lZC4NCj4+PiANCj4+PiBCdXQgdG8geW91ciBtYWluIHBvaW50LCB3ZSBoYXZlIGJlZW4g ZGlzY3Vzc2luZyB0aGUgdGVybXMgYS9zeW5jaHJvbm91cw0KPj4+dG8NCj4+PiBoYXZlIHRvIGRv IHdpdGggaW50ZXJuYWwgc2VydmVyIHByb2Nlc3Npbmcgb2YgYW4gZWRpdCByZXF1ZXN0LCBidXQg aW4NCj4+PiczJw0KPj4+IHRoZSB0ZXJtcyBhcmUgYmVpbmcgdXNlZCB0byBxdWFsaWZ5IGEgbWFu YWdlbWVudCBzeXN0ZW0sIHdoaWNoIGNhbid0IGJlDQo+Pj4gcmlnaHQuICBJIHRoaW5rIHRoYXQg JzMnIHNob3VsZCBiZSByZXdyaXR0ZW4gdG8gYmUgYSBzdGF0ZW1lbnQgYWJvdXQNCj4+PiBkZXZp Y2VzLCBub3QgYSBzdGF0ZW1lbnQgYWJvdXQgbWFuYWdlbWVudCBzeXN0ZW1zLg0KPj4NCj4+CUl0 IG1pZ2h0IGJlIGJldHRlciB0byBmcmFtZSB0aGlzIGluIHRlcm1zIG9mIGEgY2xpZW50IGFuZCBh DQo+PnNlcnZlci4NCj4+DQo+PgnigLlUb20NCj4+DQo+Pg0KPj4+IEFueXdheSwgSSBhbSBub3Qg c3VyZSAzLiBpcyBwcm9wZXJseSB3b3JkZWQgdW50aWwgc29tZW9uZSBkZWZpbmVzDQo+Pj4+ICd0 cmFuc2FjdGlvbmFsJywgJ2Rpc3RyaWJ1dGVkJywgJ3N5bmNocm9ub3VzIG1hbmFnZW1lbnQgc3lz dGVtcycgYW5kDQo+Pj4+ICdhc3luY2hyb25vdXMgbWFuYWdlbWVudCBzeXN0ZW1zJy4NCj4+PiAN Cj4+PiBUaGUgYWdlbmRhIGZvciB0b21vcnJvdydzIGludGVyaW0hICA6KQ0KPj4+IA0KPj4+IA0K Pj4+IEtlbnQNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1v ZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Thu Oct 15 13:34:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E871A1A9C for ; Thu, 15 Oct 2015 13:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOOK=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJIdK8Bnq3Bu for ; Thu, 15 Oct 2015 13:34:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DADA91A0248 for ; Thu, 15 Oct 2015 13:34:29 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id C22E01AE0498; Thu, 15 Oct 2015 22:34:28 +0200 (CEST) Date: Thu, 15 Oct 2015 22:37:49 +0200 (CEST) Message-Id: <20151015.223749.1017340653632922486.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151012144431.GA64068@elstar.local> References: <20151012144431.GA64068@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 20:34:33 -0000 Hi, Thanks for this detailed review, it is much appreciated! Comments inline. Juergen Schoenwaelder wrote: > Hi, > > I have read through draft-ietf-netmod-rfc6020bis-07 (except section 9. > Built-In Types). Overall, the document is in a good shape. I spotted a > number of editorial issues or a number of issues where we could try to > seek a clearer separation of NETCONF specifics. (I plan to read > section 9 as well but I assume this is less important since there > likely are not many changes from RFC 6020 in this part.) > > I am indicating the paper number below for each comment/suggestion. > > * p8: > > s/XML has been/XML have been/ > > s/how the data model/how a data model/ > > s/represented in/encoded in/ Fixed. > * p9: > > s/names means/names mean/ Fixed. > * p11: > > s/the module faithfully/a module faithfully/ Fixed. > I am also wondering why we use device and server. It seems we use > these terms interchangeably. If so, for clarity, I would suggest to > use a single term, that is s/device/server Ok, fixed. > / and perhaps explicitly > state that unless stated otherwise server means a server providing > access to a YANG defined data tree. Yes this makes sense. But then I guess we shouldn't import client and server from 6241. (And most other documents (restconf etc) should probably import these terms from ths document). See also below. > * p12/p13 > > We import 7 terms from RFC 6241. Would it make sense to copy the > necessary text in order to avoid a too strict binding to RFC 6241? > In particular, 'client' and 'server' means NETCONF client and server > if we import from RFC 6241 but this may be a bit narrow given that > we have RESTCONF as well. In an ideal world, we would factor out > core architectural concepts but the best we can do is likely to > define core concepts inline, pointing out where they are the same. > The idea is to loosen the coupling to RFC 6241. Example: > > OLD > > o datastore: an instantiated data tree > > NEW > > o datastore: A conceptual place to store and access information. > A datastore might be implemented, for example, using files, a > database, flash memory locations, or combinations thereof. > [Matches the definition in RFC 6241.] To start with, I think we should define client and server more generically than just NETCONF: server: An entity that provides access to YANG-defined data to a client, over some network management protocol. client: An entity that can access YANG-defined data on a server, over some network management protocol. ? > * p13 > > Does the term 'mandatory node' really deserve its own subsection? I > understand that there are references to section 3.1 but would > reference to section 3 not work as well? Sure. The thing is that I have toolchain problems with nested lists... [hacking away] ... Fixed. > * p13 > > s/used for other/used with other/ Fixed. > * p14 > > s/encoded in NETCONF operations/encoded on-the-wire/ Fixed. > * p14 > > s/of NETCONF data models/of data models for network management > protocols such as NETCONF,/ Fixed. > And I suggest to remove the following sentence since it is not > really needed. > > The data models described by YANG are designed to be easily > operated upon by NETCONF operations. Fixed. > * p15 > > s/read-only access/read-only access [RFC6643]/ Fixed. > * p15 > > I am not sure why the last paragraph in section 4.1 is needed. In > the first setence, I would remove 'Like NETCONF' and in the second > sentence I am not sure what we are saying given that there is NACM. > I would definitely remove the second sentence and if the first > should be kept, I would likely move it up since it is a fairly > general statement. But I think removing the whole paragraph is the > simplest solution since it is not essential. Agree, removed. > * p13 > > Would it make sense to add a sentence right at the beginning of > section 4 stating that section 4 is intended to provide orientation > for the first time reader but that section 4 is not normative? How about: This non-normative section is intended to give a high-level overview of YANG to first-time readers. > * p15 > > With the previous in mind, I suggest to remove "This progressive > approach handles the inter-related nature of YANG concepts and > statements. A detailed description of YANG statements and syntax > begins in Section 7." from the text right below 4.2. Note that > Section 7 is actually Section 6 (but Section 5 has also important > normative content). I agree; removed. > * p16 > > s/four types of nodes/four types of data nodes/ Fixed. > * p16 > > Perhaps simplify: > > OLD > > A leaf instance contains simple data like an integer or a string. It > has exactly one value of a particular type and no child nodes. > > NEW > > A leaf data node has exactly one value of a particular type and no > child nodes. We changed this to "leaf instance" after discussion with Lada. I think it makes sense to mention that it is supposed to contain data like an integer or string, so I think I prefer to keep this text as is. > * p16-p25 > > Should this be 'XML Encoding Example' instead "NETCONF XML Example'? > This does not seem to be NETCONF specific. Fixed. > * p25 > > s/XML representation/XML encoding/ Fixed. > * p25 > > s/operations' names/operations' name/ Fixed. > * p25 > > s/node in the data hierarchy/data node/ Fixed. > * p28 > > Start section 5 by saying that this section defined language > concepts and that it is normative, e.g. > > This normative section defines core language concepts. But aren't all sections normative unless we say so? Otherwise it seems we should start every section by saying that it is either normative or not. > * p29 > > s/its contents are unchanged/its content is unchanged/ I am not sure that this is correct. The text is present in RFC 6020, and has been reviewd by the RFC editor; they usually capture things like this. > * p37 > > s/following shows valid data/following XML encoding shows valid data/ Fixed (I did "following XML encoding example...") > * p35 > > I think there should be a citation of I-D.ietf-netconf-yang-library > where this module first appears. Fixed. > * p46 > > The text concerning module names is a repetition from section 5.1. > To avoid introducing inconsistencies, perhaps replace the repeated > text with a reference to section 5.1? Ok, fixed. > * p49 > > Is the text in section 7.1.3 correct when it says all identifiers > defined by the module? I mean, schema node identifiers are > namespaced by module names and their prefixes. And data node > identifiers are using the namespace in the XML encoding. Here is > an attempt of a rewrite: > > The "namespace" statement defines the XML namespace that all data > node identifiers defined by the module are qualified by in the > XML encoding. Data node identifiers defined inside a grouping are > an exception q(see Section 7.13 for details). The argument to > the "namespace" statement is the URI of the namespace. It's actually not only data nodes, it is also rpc, actions, notifications, identities. How about: The "namespace" statement defines the XML namespace that all identifiers defined by the module are qualified by in the XML encoding, with the exception of identifiers for data nodes, action nodes, and notification nodes defined inside a grouping (see ^uses^ for details). The argument to the "namespace" statement is the URI of the namespace. > * p53 > > Another repetition of the module/submodule name requirements, does > it make sense to avoid repetition? Yes, fixed. > * p61 > > Should the text in 7.5.4.1 and 7.5.4.2 say explicitly that we talk > about NETCONF when we refer to ? Or should the text try > to be more generic, saying that the respective fields will be > carried in error message in protocols that use YANG? It is actually > somewhat opaque what an error-app-tag is or how it should be used. I think we can say "If the constraint evaluates to false, the string is passed as in the in NETCONF." Other protocols have to define how these fields are used. > * p63 > > Should the last paragraph in 7.5.7 be factored out into its own > subsection titled "NETCONF and Operations"? The > text is not really anymore about XML encoding (which may be used > with RESTCONF). Or the text is actually about the encoding but > should be written to simply state that non-presence containers can > be pruned in encodings (without restricting this to NETCONF). This makes sense. I think the last paragraph can be replaced with: If a non-presence container does not have any child nodes, the container may or may not be present in the XML encoding. > * p67 > > Similar to the comment for p63. Perhaps the right way is to phrase > this in such a way that is simply says leaf nodes containing a > default value may not be present in the XML encoding. Simply remove > NETCONF or specifics. Or maybe we should simply remove the last paragraph completely? For NETCONF, RFC 6243 details how leafs with defaults are handled. > * p72 > > s/an unspecified order/an order determined by the system/ > > Note that a description clause may actually define how the system > has to order elements and hence 'unspecified order' seems wrong. Fixed. > * p97 > > The text in 7.14 talks about NETCONF specifics, namely the > element and the "rpcOperation" substitution group. Perhaps move this > down into a specific section defining the mapping of YANG RPCs to > NETCONF s. Yes, fixed, but see below. > * p100 > > The XML encoding text starts with detailing NETCONF specifics. > Would it make sense to separate the XML encoding of the rpc and its > input/output from the specifics how the RPCs fit into NETCONF's > system? Hmm. NETCONF and RESTCONF use quite different encodings of rpcs and their output. NETCONF: 27606-0100 RESTCONF: POST to .../rock-the-house 27606-0100 result: 204 no content Maybe it would have been better to have a common encoding, like: ... and ... but this cannot be done now. So, maybe the simplest solution would be to rename the section to "NETCONF XML Encoding"? > * p102 > > The XML encoding section again mixes XML encoding of the node > hierarchy with NETCONF specifics how an action is invoked using > NETCONF's system. I suggest to factor this into two different > sections. See above, I suggest we simply rename the section to "NETCONF XML Encoding". > * p105 > > Again, the proposal is to separate the XML encoding of notifications > from the details how notifications work with RFC 5277. Also notifications are encoded differently in RESTCONF and NETCONF. > * p120 > > The text in section 7.21.1 talks about NETCONF specific operations. > Is this actually necessary? Can the purpose of the config statement > not be described by referring to general concepts such as > configuration datastores instead of using protocol specific > operations? Yes, maybe we can just say: Data nodes representing configuration are part of configuration datastores. > * p123 > > Is there a special reason why the text uses 'notification instance > data tree' instead of just 'notification data tree'? No, fixed. > * p123 > > "All leaf data values MUST match the type constraints..." may be > read as 'all data nodes that contain values' or 'all instantiations > of nodes defined by the leaf statement'. I don't really see what you mean. Can you suggest new text? > * p192 > > The Acknowledgements section may need some updates. Ok. /martin From nobody Thu Oct 15 13:58:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E771A1B63 for ; Thu, 15 Oct 2015 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrXNLNPTKm4k for ; Thu, 15 Oct 2015 13:58:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DCB191A010C for ; Thu, 15 Oct 2015 13:58:21 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D0D91AE0498; Thu, 15 Oct 2015 22:58:21 +0200 (CEST) Date: Thu, 15 Oct 2015 23:01:41 +0200 (CEST) Message-Id: <20151015.230141.2155612685960164497.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151013080254.GA65823@elstar.local> References: <20151013080254.GA65823@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 20:58:23 -0000 Juergen Schoenwaelder wrote: > Hi, > > here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I > have finish now a complete review of the document. The most important > bug I spotted is likely that section 9.4.6 is empty. Ha! It seems to have been empty since -01... > /js > > * p126 > > OLD > > Some types have a lexical representation that depends on the XML > context in which they occur. These types do not have a canonical > form. > > NEW > > Some types have a lexical representation that depends on the > encoding, e.g., the XML context in which they occur. These types > do not have a canonical form. Fixed. > Well, it turns out that there are XML encoding specifics in several > of the following sections. Perhaps instead stated upfront that the > section 9 describes the types and they XML encoding and noting that > other encodings may use different rules. Perhaps also stating that > the canonical representation is also used for constraint evaluation > purposes. > > OLD > > When a NETCONF server sends data, it MUST be in the canonical form. > > NEW > > When a server sends data encoded in XML, it MUST use the canonical > form defined in this section. Other encodings may introduce > alternate representations. Note, however, that values in the data > tree are conceptually stored in the canonical representation as > defined in this section. In particular, any XPath expression > evaluations are done using the canonical form. Fixed. > * p127 > > s/XML instance documents/XML encoding/ Fixed. > * p131 > > s/XML instance documents/XML encoding/ Fixed. > * p132 > > The section 9.4.6 (modifier statement) is empty and needs to be > filled in. Fixed. > * p137 > > Y25-02 says: > > Keep the auto-numbering procedure for enums and bits and add an > explicit warning that inserting enum or bits definitions or > reordering enum or bits definitions violates section 10 and causes > interoperability problems unless explicit value assignments are > used. > > Has this been implemented? I did not find such a statement. Neither did I :( I think it is best to add this warning to section 10: OLD: o An "enumeration" type may have new enums added, provided the old enums's values do not change. NEW: o An "enumeration" type may have new enums added, provided the old enums's values do not change. Note that inserting a new enum before an existing enum or reordering existing enums will result in new values for the existing enums, unless they have explicit values assigned to them. ? > * p139 > > s/A binary can/A binary type can/ Fixed. > * p139 > > s/are encoded/are encoded in XML/ How about s/are encoded/are lexically represented/ since it is not just XML, but also defaults and the canonical form. > * p141 > > s/is encoded/is encoded in XML/ s/is encoded/is lexically represented/ ? > * p146 > > s/is encoded/is encoded in XML/ s/is encoded/is lexically represented/ ? > * p148 > > The text stating that a value is consecutively against each member > type does not seem to be 100% true for the JSON mapping since JSON > says the JSON type information is taken into account. So we either > change the JSON specification or we rewrite this text in RFC 6020 to > allow different member type selection styles by making this > statement specific to the XML encoding: > > In the XML encoding, the value representing a union data type... I added this last sentence. /martin From nobody Thu Oct 15 14:03:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF11A1BC3 for ; Thu, 15 Oct 2015 14:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o1PYvryq48T for ; Thu, 15 Oct 2015 14:03:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFC51A1B82 for ; Thu, 15 Oct 2015 14:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11551; q=dns/txt; s=iport; t=1444943021; x=1446152621; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R0cShiIKY9IO9D3oxznrWiE2rvo3QXO5eXcoDXmFEtg=; b=ZIA5NSGfipm8XIjfmFs323YSywbxLFWub9mpmQne6+VHsiBBUheQd6rt 5v2hxjvdfvnjMmPCKTGj3FeDLCwmsSO+P8zZlTYFuxd/pNun23CZf+r8Z +xPhzR7Ow40wDPGMIWpqTGv6bXAL2Z3Lrf+m0sqzI6vqu4Duf08b/6YRy E=; X-Files: ATT00001.txt : 136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DIAgAoFCBW/4cNJK1egllNVG4GvTcOgVkXAQmFM0oCgTw4FAEBAQEBAQF/C4QmAQEBBAEBASpBCxACAQgRBAEBDhoHAiULFAcBAQUDAQEEDgUIAQWIIA3DWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLdIQ7AQFMBAYBhC4Flh0Bgk2BYWqHe4FflkmDbgEfAUOEA3EBhCY6gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="txt'?scan'208,217";a="41845445" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2015 21:03:40 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9FL3dKC008660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Oct 2015 21:03:39 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 16:03:25 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 16:03:24 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wBWjM0gAABA4YA= Date: Thu, 15 Oct 2015 21:03:24 +0000 Message-ID: <3c7b5630f1614ed388ddfa6d875d3b5f@XCH-RCD-001.cisco.com> References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <71c53c5ed57e448eb9dee71ced2afcac@XCH-RCD-001.cisco.com> In-Reply-To: <71c53c5ed57e448eb9dee71ced2afcac@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.204.93] Content-Type: multipart/mixed; boundary="_004_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] FW: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 21:03:44 -0000 --_004_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_" --_000_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding to NETMOD as people there might be interested as well (for those subscribed to both mailers, apologies for the spam...) From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Alexander Clem= m (alex) Sent: Thursday, October 15, 2015 1:57 PM To: netconf@ietf.org Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Hello all, below we noted that "draft-clemm-netconf-yang-push" would become "draft-iet= f-netconf-yang-push-00" this week. Just as an FYI, the WG draft is now po= sted: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ Kind regards --- Alex From: Eric Voit (evoit) Sent: Tuesday, October 13, 2015 8:37 PM To: netconf@ietf.org Cc: Alexander Clemm (alex) >; Alberto= Gonzalez Prieto (albertgo) >= ; Ambika Prasad Tripathy (ambtripa) >; Einar Nilsen-Nygaard (einarnn) > Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forwarding to NETMOD a= s people there might be interested as well

(for those subscribed = to both mailers, apologies for the spam…)

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of Alexander Clemm (alex)
Sent: Thursday, October 15, 2015 1:57 PM
To: netconf@ietf.org
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF,= HTTP/2

 

Hello all,

 

below we noted that “draft-clemm-netconf-yang-= push” would become “draft-ietf-netconf-yang-push-00” this= week.   Just as an FYI, the WG draft is now posted:

https://datatracker.ietf.org/doc/draft-ietf-netconf-= yang-push/

 

Kind regards

--- Alex

 

 

From: Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 8:37 PM
To: netconf@ietf.org
Cc: Alexander Clemm (alex) <ale= x@cisco.com>; Alberto Gonzalez Prieto (albertgo) <albertgo@cisco.com>; Ambika Prasad Tripathy (= ambtripa) <ambtripa@cisco.com&= gt;; Einar Nilsen-Nygaard (einarnn) <ei= narnn@cisco.com>
Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

 

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

·   =   proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

·   =   provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

·   =   provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_-- --_004_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Thu, 15 Oct 2015 20:56:53 GMT"; modification-date="Thu, 15 Oct 2015 20:56:53 GMT" Content-ID: <74E5210A4FCD7149A2C0D9FF009B8BF5@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_3c7b5630f1614ed388ddfa6d875d3b5fXCHRCD001ciscocom_-- From nobody Thu Oct 15 14:05:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DE31A1BCC for ; Thu, 15 Oct 2015 14:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fmTTZeAUdRd for ; Thu, 15 Oct 2015 14:05:51 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 276631A1BC3 for ; Thu, 15 Oct 2015 14:05:51 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so84523281lbc.3 for ; Thu, 15 Oct 2015 14:05:49 -0700 (PDT) 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=yGcIfrrHmWUw7VRQ4NmFpihwK7iXbYuzE9XWPlPFiZ8=; b=V8Exqhc2a+o4GWAmfQZjrCGx0VqQEnamEJVTqhFk8M2Rri8FIwXug4OJA0nlYuC6xL e3mNxyVjkmb1eBvJ4LDL8TG5VvPh9GnESdx4JgXVw2k4yiNoT2pj8sibZMNaY/R5qfbp Jm6YLNyA+3b+8Y9MMiJjFecSfBUZk7V/6aeBbbRE2iK+IlMYxXIZt4yWNPdJtrVyfxRo BHOYKUtIXOyMdyYP1Lo/zMoC9D7yNn9U1gUCESdFXi4/ZCMV9OgLT2s2Utvqe0Vx7Rrs efbwnJHbovTCZni0kGMv8UrWby/9S/TZPvAnj092TpiAkE9vvH7qM6bNWAxByCNg/GWO 28Sg== X-Gm-Message-State: ALoCoQlHOMC26naAOcw7uVUmytiheIigKVSDpTCJErnii+mGEPBsYtnPKdrRkwbfkKTD/zBt43E3 MIME-Version: 1.0 X-Received: by 10.112.181.71 with SMTP id du7mr5783295lbc.37.1444943149225; Thu, 15 Oct 2015 14:05:49 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 15 Oct 2015 14:05:49 -0700 (PDT) In-Reply-To: <561FC736.6030903@ericsson.com> References: <561F5D28.5020304@ericsson.com> <20151015.135334.2134677503217017095.mbj@tail-f.com> <561FC736.6030903@ericsson.com> Date: Thu, 15 Oct 2015 14:05:49 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11c3715c21710a05222b0b94 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 21:05:55 -0000 --001a11c3715c21710a05222b0b94 Content-Type: text/plain; charset=UTF-8 Hi, Show me the text that says an anyxml passes the constraints of the hidden data models through to the RPC processing. The error for false-when only applies to parameters specified in the RPC. The processing of the rpc-stmt does not have any when-stmts that need to be checked. The config data is validated as part of a datastore, not as part of the RPC payload. Andy On Thu, Oct 15, 2015 at 8:33 AM, Balazs Lengyel wrote: > Hello, > I had the same interpretation as Martin. The when could be on the config > database model. Not just on the when defined in a definition of an rpc or > action. > regards Balazs > > On 2015-10-15 17:02, Andy Bierman wrote: > > > > On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund < > mbj@tail-f.com> wrote: > >> Andy Bierman wrote: >> > Hi, >> > >> > You are incorrect. >> > >> > Within the PAYLOAD (as this section describes), there is no when-stmt >> > for data nodes within the datastore. Look at the YANG for edit-config. >> > There are no when-stmts for "interface" in "edit-config". >> >> Andy, there is some confusion here. The section talks about: >> >> For configuration data, there are three windows when constraints >> MUST be enforced: >> >> - during parsing of RPC payloads >> - during processing of NETCONF operations >> - during validation >> >> So the entire section talks about constraints *on configuration data*. >> >> > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 > > > Here is the YANG for edit-config? > Please point out the when-stmts in this rpc-stmt > specific to the "interface" node. > I just see an "anyxml" that has no when-stmts at all. > > So enforcing the when constraint on the RPC PAYLOAD > clearly has nothing to do with "interface" -- just the parameters > specified in the rpc-stmt. > > > > >> If you interpret this section to talk about the nodes in the >> definition of edit-config, nothing in the section makes any sense at >> all. For example: >> >> If all keys of a list entry are not present, the server MUST reply >> with a "missing-element" error-tag in the rpc-error. >> >> you might say that there are no lists in the definition of >> edit-config, so this bullet doesn't apply. >> >> >> > > edit-config is the next section -- 8.2.2 > > > >> /martin >> >> > > Andy > > >> >> >> > >> > So explain which constraint in the payload is being violated? >> > >> > >> > Andy >> > >> > >> > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel < >> balazs.lengyel@ericsson.com >> > > wrote: >> > >> > > See below, Balazs >> > > >> > > On 2015-10-14 23:06, Andy Bierman wrote: >> > > >> > > >> > > >> > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < >> > > mbj@tail-f.com> wrote: >> > > >> > >> Andy Bierman wrote: >> > >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund > > >> > >> wrote: >> > >> > >> > >> > > Andy Bierman < andy@yumaworks.com> wrote: >> > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund < >> mbj@tail-f.com> >> > >> > > wrote: >> > >> > > > >> > >> > > > > Balazs Lengyel < < >> balazs.lengyel@ericsson.com> >> > >> balazs.lengyel@ericsson.com> wrote: >> > >> > > > > > Hello Martin, >> > >> > > > > > I agree that A1 is what follows the spirit of YANG, but >> then >> > >> IMHO you >> > >> > > > > > should change/correct 8.2.1 in YANG because that implies >> A2 and >> > >> > > error. >> > >> > > > > >> > >> > > > > Ok, I agree. I suggest we remove from 8.2.1: >> > >> > > > > >> > >> > > > > o If data for a node tagged with "when" is present, and >> the >> > >> "when" >> > >> > > > > condition evaluates to "false", the server MUST reply >> with >> > >> an >> > >> > > > > "unknown-element" error-tag in the rpc-error. >> > >> > > > > >> > >> > > > > and add to 8.2.2: >> > >> > > > > >> > >> > > > > o Modification requests for nodes tagged with "when", and >> the >> > >> "when" >> > >> > > > > condition evaluates to "false". In this case the >> server MUST >> > >> > > reply >> > >> > > > > with an "unknown-element" error-tag in the rpc-error. >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > >> > >> > > > This seems like a BIG protocol change to >> behavior. >> > >> > > > IMO this not an error at all. In our server the false-when >> data is >> > >> just >> > >> > > > pruned, and no error is ever sent for a pruned when=false data >> node. >> > >> > > >> > >> > > So you are not following the current RFC 6020 spec? >> > >> > > >> > >> > >> > >> > >> > >> > Yes we are following it. >> > >> >> > >> Ok. >> > >> >> > >> > The schema for the edit-config RPC operation contains >> > >> > an 'anyxml' for node. It does not contain any >> > >> > when-stmts for the data nodes that get passed in the node. >> > >> > The correct behavior is to just enforce the error on the when-stmts >> > >> > that appear in the rpc-stmt. >> > >> >> > >> I don't understand what you are trying to say. >> > >> >> > > >> > > >> > > I know about the text that says a false-when in an RPC is an error. >> > > Show me the when-stmts "interface" in the "edit-config" rpc-stmt. >> > > >> > > >> > > >> > > >> > >> >> > >> Here's an example: >> > >> >> > >> augment /if:interfaces/if:interface { >> > >> when "if:type = 'ianaift:ethernetCsmacd'"; >> > >> >> > >> container ethernet { >> > >> leaf duplex { >> > >> type enumeration { >> > >> enum "half"; >> > >> enum "full"; >> > >> } >> > >> } >> > >> } >> > >> } >> > >> >> > >> Suppose the db is empty. >> > >> >> > >> What if the edit-confif contains >> > >> >> > >> >> > >> >> > >> eth0 >> > >> full >> > >> ianaift:ethernetCsmacd >> > >> >> > >> >> > >> >> > >> will that work or not? I.e., will the eth0 interface be created with >> > >> duplex full? >> > >> >> > > >> > > Yes -- because these are data nodes and the rules for when-stmt >> > > on data nodes are different than for rpc-stmt. Then the when-stmt >> > > is a test on whether the node should exist in the candidate or running >> > > datastore. >> > > >> > > Our server applies all the edits first, when checks all the when-stmts >> > > that might have changed value. Nodes that have already existed in the >> > > datastore may get pruned, not just the new nodes. >> > > >> > > >> > > >> > > >> > > >> > >> >> > >> /martin >> > >> >> > >> >> > >> >> > > >> > > Andy >> > > >> > > >> > >> >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > I don't think this is a BIG protocol change, since the spec >> already >> > >> > > says that requests for nodes w/ false when expressions MUST send >> > >> > > error. The change is to say that this behavior is true >> regardless of >> > >> > > evaluation order. >> > >> > > >> > >> > > > It may be a client programming error for the client to provide >> > >> > > > false when nodes or not. What if the client is reusing some >> > >> > > > code that sends 5 parameters, it it's OK if 1 of them gets >> > >> > > > pruned sometimes because of a false when (e.g, product >> > >> > > > feature-specific knob and that feature is not installed) >> > >> > > >> > >> > > Well, it might be simpler to send if-featured nodes that the >> specific >> > >> > > server doesn't support - this is also an error in 6020. >> > >> > > >> > >> > > > BTW, this is a really good example of what not to do, if one >> > >> > > > wants to make the YANG specification protocol independent. >> > >> > > >> > >> > > That statement is true for the entire section 8.2, it is not >> > >> > > specifically true for this change. >> > >> > > >> > >> > > >> > >> > > /martin >> > >> > > >> > >> > >> > >> > >> > >> > Andy >> > >> >> > > >> > > And this contradicts the current rfc6020bis-07#section-8.2.1 which >> states >> > > that already during parsing you must check >> > > >> > > If data for a node tagged with "when" is present, and the "when" >> > > condition evaluates to "false", the server MUST reply with an >> > > "unknown-element" error-tag in the rpc-error. >> > > >> > > >> > > So already during parsing full you MUST send >> back an error; >> > > before processing ianaift:ethernetCsmacd. >> > > (I also assume this is independent from the document order of the >> edit-config request.) >> > > So this MUST be corrected in the draft! >> > > regards Balazs >> > > >> > > >> > > >> > > >> > > >> > > -- >> > > Balazs Lengyel Ericsson Hungary Ltd. >> > > Senior Specialist >> > > ECN: 831 7320 >> > > Mobile: +36-70-330-7909 email: >> Balazs.Lengyel@ericsson.com >> > > >> > > >> > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > --001a11c3715c21710a05222b0b94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Show me the text that says an anyxm= l passes the constraints of
the hidden data models through to the= RPC processing.
The error for false-when only applies to paramet= ers specified
in the RPC.

The processing= of the rpc-stmt does not have any when-stmts that
need to be che= cked.

The config data is validated as part of a da= tastore, not as part
of the RPC payload.


Andy



On Thu, Oct 15, 2015 at 8:33 A= M, Balazs Lengyel <balazs.lengyel@ericsson.com> wr= ote:
=20 =20 =20
Hello,
I had the same interpretation as Martin. The when could be on the config database model. Not just on the when defined in a definition of an rpc or action.
regards Balazs

On 2015-10-15 17:02, Andy Bierman wrote:
=20


On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> You are incorrect.
>
> Within the PAYLOAD (as this section describes), there is no when-stmt
> for data nodes within the datastore.=C2=A0 Look at the YANG for edit-config.
> There are no when-stmts for "interface" in "edit-config".

Andy, there is some confusion here.=C2=A0 The section talks about:

=C2=A0 For configuration data, there are three windows when constraints
=C2=A0 MUST be enforced:

=C2=A0 - during parsing of RPC payloads
=C2=A0 - during processing of NETCONF operations
=C2=A0 - during validation

So the entire section talks about constraints *on configuration data*.





Here is the YANG for edit-config?
Please point out the when-stmts in this rpc-stmt
specific to the "interface" node.
I just see an "anyxml" that has no when-stmts at= all.

So enforcing the when constraint on the RPC PAYLOAD
clearly has nothing to do with "interface" -- ju= st the parameters
specified in the rpc-stmt.


=C2=A0
If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.=C2=A0 =C2=A0For example:

=C2=A0 If all keys of a list entry are not present, the serve= r MUST reply
=C2=A0 with a "missing-element" error-tag in the rp= c-error.

you might say that there are no lists in the definition of edit-config, so this bullet doesn't apply.




edit-config is the next section =C2=A0-- 8.2.2



/martin



Andy
=C2=A0


>
> So explain which constraint in the payload is being violated?
>
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <balazs.lengyel@erics= son.com
> > wrote:
>
> > See below, Balazs
> >
> > On 2015-10-14 23:06, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < <mbj@tail-f.com>
> > mbj@tail-f.com> wrote:
> >
> >> Andy Bierman <andy@yumaworks.com> wrote:
> >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com>
> >> wrote:
> >> >
> >> > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com>
> >> > > wrote:
> >> > > >
> >> > > > > Balazs Lengyel < <balazs.lengyel@er= icsson.com>
> >> balazs.lengyel@ericsson.com> wrote:
> >> > > > > > Hello Martin,
> >> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> >> IMHO you
> >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> >> > > error.
> >> > > > >
> >> > > > > Ok, I agree.=C2=A0 I sugges= t we remove from 8.2.1:
> >> > > > >
> >> > > > >=C2=A0 =C2=A0 o=C2=A0 If dat= a for a node tagged with "when" is present, and the
> >> "when"
> >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0c= ondition evaluates to "false", the server MUST reply with > >> an
> >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > > and add to 8.2.2:
> >> > > > >
> >> > > > >=C2=A0 =C2=A0o=C2=A0 Modific= ation requests for nodes tagged with "when", and the
> >> "when"
> >> > > > >=C2=A0 =C2=A0 =C2=A0 conditi= on evaluates to "false".=C2=A0 In this case the server MUST
> >> > > reply
> >> > > > >=C2=A0 =C2=A0 =C2=A0 with an "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > This seems like a BIG protocol change to <edit-config> behavior.
> >> > > > IMO this not an error at all.=C2=A0 In our server the false-when data is
> >> just
> >> > > > pruned, and no error is ever sent for a pruned when=3Dfalse data node.
> >> > >
> >> > > So you are not following the current RFC 6020 spec?
> >> > >
> >> >
> >> >
> >> > Yes we are following it.
> >>
> >> Ok.
> >>
> >> > The schema for the edit-config RPC operation contains
> >> > an 'anyxml' for <config> nod= e.=C2=A0 It does not contain any
> >> > when-stmts for the data nodes that get passed in the <config> node.
> >> > The correct behavior is to just enforce the error on the when-stmts
> >> > that appear in the rpc-stmt.
> >>
> >> I don't understand what you are trying to say.
> >>
> >
> >
> > I know about the text that says a false-when in an RPC is an error.
> > Show me the when-stmts=C2=A0 "interface" = in the "edit-config" rpc-stmt.
> >
> >
> >
> >
> >>
> >> Here's an example:
> >>
> >>=C2=A0 =C2=A0augment /if:interfaces/if:interface= {
> >>=C2=A0 =C2=A0 =C2=A0when "if:type =3D 'ianaift:ethernetCsmacd'";
> >>
> >>=C2=A0 =C2=A0 =C2=A0container ethernet {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf duplex {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumerati= on {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum &q= uot;half";
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum &q= uot;full";
> >>=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}
> >>
> >> Suppose the db is empty.
> >>
> >> What if the edit-confif contains
> >>
> >>=C2=A0 =C2=A0<interfaces>
> >>=C2=A0 =C2=A0 =C2=A0<interface>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</= name>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<eth:duplex>full</eth:duplex>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0<type>ianaift:ethernetCsmacd</type>
> >>=C2=A0 =C2=A0 =C2=A0</interface>
> >>=C2=A0 =C2=A0</interfaces>
> >>
> >> will that work or not?=C2=A0 I.e., will the eth= 0 interface be created with
> >> duplex full?
> >>
> >
> > Yes -- because these are data nodes and the rules for when-stmt
> > on data nodes are different than for rpc-stmt.=C2= =A0 Then the when-stmt
> > is a test on whether the node should exist in the candidate or running
> > datastore.
> >
> > Our server applies all the edits first, when checks all the when-stmts
> > that might have changed value.=C2=A0 Nodes that hav= e already existed in the
> > datastore may get pruned, not just the new nodes.
> >
> >
> >
> >
> >
> >>
> >> /martin
> >>
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > I don't think this is a BIG protocol change, since the spec already
> >> > > says that requests for nodes w/ false when expressions MUST send
> >> > > error.=C2=A0 The change is to say tha= t this behavior is true regardless of
> >> > > evaluation order.
> >> > >
> >> > > > It may be a client programming error for the client to provide
> >> > > > false when nodes or not.=C2=A0 What if the client is reusing some
> >> > > > code that sends 5 parameters, it it's OK if 1 of them gets
> >> > > > pruned sometimes because of a false when (e.g, product
> >> > > > feature-specific knob and that feature is not installed)
> >> > >
> >> > > Well, it might be simpler to send if-featured nodes that the specific
> >> > > server doesn't support - this is also an error in 6020.
> >> > >
> >> > > > BTW, this is a really good example of what not to do, if one
> >> > > > wants to make the YANG specification protocol independent.
> >> > >
> >> > > That statement is true for the entire section 8.2, it is not
> >> > > specifically true for this change. > >> > >
> >> > >
> >> > > /martin
> >> > >
> >> >
> >> >
> >> > Andy
> >>
> >
> > And this contradicts the current rfc6020bis-07#section-8.2.1 which states
> > that already during parsing you must check
> >
> > If data for a node tagged with "when" is present, and the "when"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0condition evaluates to &q= uot;false", the server MUST reply with an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"unknown-element&quo= t; error-tag in the rpc-error.
> >
> >
> > So already during parsing <eth:duplex>full</eth:duplex> you MUST send back an error;
> > before processing <type>ianaift:ethernetCsmacd</type>.
> > (I also assume this is independent from the document order of the edit-config request.)
> > So this MUST be corrected in the draft!
> > regards Balazs
> >
> >
> >
> >
> >
> > --
> > Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 email: Balazs.Lengyel@ericsson.com
> >
> >


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

--001a11c3715c21710a05222b0b94-- From nobody Thu Oct 15 14:12:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0521A1BC8; Thu, 15 Oct 2015 14:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.911 X-Spam-Level: X-Spam-Status: No, score=-10.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY5NAUvXS907; Thu, 15 Oct 2015 14:12:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF001A1BBE; Thu, 15 Oct 2015 14:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22542; q=dns/txt; s=iport; t=1444943552; x=1446153152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uScMXPNjLMqGClxGrDWEtbR+1TgEYksHmClbMMnwuZU=; b=hNYWXySKtnLKjSI3H18S29i9YhLx8uFXylfq602wmlPNq6ERlODt7JoS MUQlsRa94X2I+G7XczQmllUxtGTiteGEfyJwCbuLfILN/n4ySzhSavLaF AGBGeFwsRjhnjlHdIjrEz8TnZ+d82+6Bllkefu3qYLJe+6LwcdytunamL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AFAgDsFSBW/5ldJa1egyZUbga9NwENgVkXCoUzSgIcgSA4FAEBAQEBAQGBCoQnAQEEAQEBIBE6BAcQAgEIGAICJgICAiULFRACBA4FiC4NsCeTPAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKUoQ0AQ0YGBsHgmmBRQWND4kOAYUYiAKBWIQ6lX0BHwEBQoQDcYQeAQEeBxyBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="scan'208";a="197321908" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 15 Oct 2015 21:12:31 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9FLCVIq032246 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 21:12:31 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 16:12:16 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 16:12:16 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka Thread-Topic: [netmod] rib-data-model and routing-cfg Thread-Index: AQHRAmpn2WDjXB7SH0yyXI3vdDB1jJ5jMMMAgAZwt4CAAFZcgP//3TyAgALyRYCAAGEWAA== Date: Thu, 15 Oct 2015 21:12:16 +0000 Message-ID: References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: <831E8953BAB4F14782F0EA1A175A966A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Routing YANG , "i2rs@ietf.org" , NETMOD WG , Routing WG Subject: Re: [netmod] rib-data-model and routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 21:12:36 -0000 SGkgTGFkYSwgDQpJIGxvb2tlZCBhdCB0aGlzIGFuZCBJIGxpa2UgdGhpcyBzaW1wbGUgYXNzb2Np YXRpb24uIEkgdGhpbmsgd2Ugc2hvdWxkIGdvDQp3aXRoIHRoaXMgLSB0aGVyZSBpcyBvbmUgcG9p bnQgZm9yIGRpc2N1c3Npb24uDQoNCkFsbCwNCg0KSW4gcm91dGluZyBkZXNpZ24gdGVhbSBkaXNj dXNzaW9ucyB3ZSBoYWQgYXVnbWVudGVkDQrigJxpZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9p cDppcHY04oCdIGFuZA0K4oCcaWY6aW50ZXJmYWNlL2lmOmludGVyZmFjZS9pcDppcHY24oCdIHNv IGFuIGludGVyZmFjZSBjb3VsZCBiZSBtYXBwZWQgdG8NCmRpZmZlcmVudCByb3V0aW5nLWluc3Rh bmNlcyBmb3IgSVB2NCBhbmQgSVB2Ni4NCg0KRG8gd2UgcmVhbGx5IHNlZSBhc3NvY2lhdGluZyB0 aGUgc2FtZSBpbnRlcmZhY2Ugd2l0aCBkaWZmZXJlbnQNCnJvdXRpbmctaW5zdGFuY2VzIGZvciBJ UHY0IGFuZCBJUHY2PyBJIGNhbiBzZWVtIHRvIHJlbWVtYmVyIHRoZSB1c2UgY2FzZQ0KYW5kIGl0 IGRvZXMgYWRkIGNvbXBsZXhpdHkgZm9yZXZlci4NCg0KVGhhbmtzLA0KQWNlZSANCg0KDQoNCk9u IDEwLzE1LzE1LCA3OjI1IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3Jv dGU6DQoNCj5IaSBBY2VlLA0KPg0KPkkgbWFkZSB0aGUgbmVjZXNzYXJ5IGNoYW5nZXMgaW4gaWV0 Zi1yb3V0aW5nLCBwbGVhc2Ugc2VlIHRoZSBHaXRIdWINCj5yZXBvOg0KPg0KPmh0dHBzOi8vZ2l0 aHViLmNvbS9uZXRtb2Qtd2cvcm91dGluZy1jZmcNCj4NCj5BIG5ldyBsZWFmICJydDpyb3V0aW5n LWluc3RhbmNlIiB3YXMgYXVnbWVudGVkIGludG8gaW50ZXJmYWNlDQo+Y29uZmlndXJhdGlvbiwg YW5kICJydDppbnRlcmZhY2VzIiBjb250YWluZXIgaW4gY29uZmlndXJhdGlvbiBpcyBnb25lLg0K Pg0KPkJlbG93IGlzIHRoZSBjb21wbGV0ZSBuZXcgdHJlZS4NCj4NCj5XaWxsIHRoaXMgd29yaz8N Cj4NCj5MYWRhDQo+DQo+bW9kdWxlOiBpZXRmLWludGVyZmFjZXMNCj4gICArLS1ydyBpbnRlcmZh Y2VzDQo+ICAgfCAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0NCj4gICB8ICAgICArLS1ydyBuYW1l ICAgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgIHwgICAgICstLXJ3IGRlc2NyaXB0aW9uPyAg ICAgICAgICAgc3RyaW5nDQo+ICAgfCAgICAgKy0tcncgdHlwZSAgICAgICAgICAgICAgICAgICBp ZGVudGl0eXJlZg0KPiAgIHwgICAgICstLXJ3IGVuYWJsZWQ/ICAgICAgICAgICAgICAgYm9vbGVh bg0KPiAgIHwgICAgICstLXJ3IGlwOmlwdjQhDQo+ICAgfCAgICAgfCAgKy0tcncgaXA6ZW5hYmxl ZD8gICAgICBib29sZWFuDQo+ICAgfCAgICAgfCAgKy0tcncgaXA6Zm9yd2FyZGluZz8gICBib29s ZWFuDQo+ICAgfCAgICAgfCAgKy0tcncgaXA6bXR1PyAgICAgICAgICB1aW50MTYNCj4gICB8ICAg ICB8ICArLS1ydyBpcDphZGRyZXNzKiBbaXBdDQo+ICAgfCAgICAgfCAgfCAgKy0tcncgaXA6aXAg ICAgICAgICAgICAgICBpbmV0OmlwdjQtYWRkcmVzcy1uby16b25lDQo+ICAgfCAgICAgfCAgfCAg Ky0tcncgKHN1Ym5ldCkNCj4gICB8ICAgICB8ICB8ICAgICArLS06KHByZWZpeC1sZW5ndGgpDQo+ ICAgfCAgICAgfCAgfCAgICAgICAgKy0tcncgaXA6cHJlZml4LWxlbmd0aD8gICB1aW50OA0KPiAg IHwgICAgIHwgICstLXJ3IGlwOm5laWdoYm9yKiBbaXBdDQo+ICAgfCAgICAgfCAgICAgKy0tcncg aXA6aXAgICAgICAgICAgICAgICAgICAgIGluZXQ6aXB2NC1hZGRyZXNzLW5vLXpvbmUNCj4gICB8 ICAgICB8ICAgICArLS1ydyBpcDpsaW5rLWxheWVyLWFkZHJlc3MgICAgeWFuZzpwaHlzLWFkZHJl c3MNCj4gICB8ICAgICArLS1ydyBpcDppcHY2IQ0KPiAgIHwgICAgIHwgICstLXJ3IGlwOmVuYWJs ZWQ/ICAgICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KPiAgIHwgICAgIHwgICstLXJ3IGlw OmZvcndhcmRpbmc/ICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KPiAgIHwgICAgIHwgICst LXJ3IGlwOm10dT8gICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyDQo+ICAgfCAgICAg fCAgKy0tcncgaXA6YWRkcmVzcyogW2lwXQ0KPiAgIHwgICAgIHwgIHwgICstLXJ3IGlwOmlwICAg ICAgICAgICAgICAgaW5ldDppcHY2LWFkZHJlc3Mtbm8tem9uZQ0KPiAgIHwgICAgIHwgIHwgICst LXJ3IGlwOnByZWZpeC1sZW5ndGggICAgdWludDgNCj4gICB8ICAgICB8ICArLS1ydyBpcDpuZWln aGJvciogW2lwXQ0KPiAgIHwgICAgIHwgIHwgICstLXJ3IGlwOmlwICAgICAgICAgICAgICAgICAg ICBpbmV0OmlwdjYtYWRkcmVzcy1uby16b25lDQo+ICAgfCAgICAgfCAgfCAgKy0tcncgaXA6bGlu ay1sYXllci1hZGRyZXNzICAgIHlhbmc6cGh5cy1hZGRyZXNzDQo+ICAgfCAgICAgfCAgKy0tcncg aXA6ZHVwLWFkZHItZGV0ZWN0LXRyYW5zbWl0cz8gICAgICB1aW50MzINCj4gICB8ICAgICB8ICAr LS1ydyBpcDphdXRvY29uZg0KPiAgIHwgICAgIHwgIHwgICstLXJ3IGlwOmNyZWF0ZS1nbG9iYWwt YWRkcmVzc2VzPyAgIGJvb2xlYW4NCj4gICB8ICAgICB8ICArLS1ydyB2NnVyOmlwdjYtcm91dGVy LWFkdmVydGlzZW1lbnRzDQo+ICAgfCAgICAgfCAgICAgKy0tcncgdjZ1cjpzZW5kLWFkdmVydGlz ZW1lbnRzPyAgICBib29sZWFuDQo+ICAgfCAgICAgfCAgICAgKy0tcncgdjZ1cjptYXgtcnRyLWFk di1pbnRlcnZhbD8gICB1aW50MTYNCj4gICB8ICAgICB8ICAgICArLS1ydyB2NnVyOm1pbi1ydHIt YWR2LWludGVydmFsPyAgIHVpbnQxNg0KPiAgIHwgICAgIHwgICAgICstLXJ3IHY2dXI6bWFuYWdl ZC1mbGFnPyAgICAgICAgICAgYm9vbGVhbg0KPiAgIHwgICAgIHwgICAgICstLXJ3IHY2dXI6b3Ro ZXItY29uZmlnLWZsYWc/ICAgICAgYm9vbGVhbg0KPiAgIHwgICAgIHwgICAgICstLXJ3IHY2dXI6 bGluay1tdHU/ICAgICAgICAgICAgICAgdWludDMyDQo+ICAgfCAgICAgfCAgICAgKy0tcncgdjZ1 cjpyZWFjaGFibGUtdGltZT8gICAgICAgICB1aW50MzINCj4gICB8ICAgICB8ICAgICArLS1ydyB2 NnVyOnJldHJhbnMtdGltZXI/ICAgICAgICAgIHVpbnQzMg0KPiAgIHwgICAgIHwgICAgICstLXJ3 IHY2dXI6Y3VyLWhvcC1saW1pdD8gICAgICAgICAgdWludDgNCj4gICB8ICAgICB8ICAgICArLS1y dyB2NnVyOmRlZmF1bHQtbGlmZXRpbWU/ICAgICAgIHVpbnQxNg0KPiAgIHwgICAgIHwgICAgICst LXJ3IHY2dXI6cHJlZml4LWxpc3QNCj4gICB8ICAgICB8ICAgICAgICArLS1ydyB2NnVyOnByZWZp eCogW3ByZWZpeC1zcGVjXQ0KPiAgIHwgICAgIHwgICAgICAgICAgICstLXJ3IHY2dXI6cHJlZml4 LXNwZWMgICAgICAgICAgIGluZXQ6aXB2Ni1wcmVmaXgNCj4gICB8ICAgICB8ICAgICAgICAgICAr LS1ydyAoY29udHJvbC1hZHYtcHJlZml4ZXMpPw0KPiAgIHwgICAgIHwgICAgICAgICAgICAgICst LToobm8tYWR2ZXJ0aXNlKQ0KPiAgIHwgICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHY2dXI6 bm8tYWR2ZXJ0aXNlPyAgICAgICAgIGVtcHR5DQo+ICAgfCAgICAgfCAgICAgICAgICAgICAgKy0t OihhZHZlcnRpc2UpDQo+ICAgfCAgICAgfCAgICAgICAgICAgICAgICAgKy0tcncgdjZ1cjp2YWxp ZC1saWZldGltZT8gICAgICAgdWludDMyDQo+ICAgfCAgICAgfCAgICAgICAgICAgICAgICAgKy0t cncgdjZ1cjpvbi1saW5rLWZsYWc/ICAgICAgICAgYm9vbGVhbg0KPiAgIHwgICAgIHwgICAgICAg ICAgICAgICAgICstLXJ3IHY2dXI6cHJlZmVycmVkLWxpZmV0aW1lPyAgIHVpbnQzMg0KPiAgIHwg ICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IHY2dXI6YXV0b25vbW91cy1mbGFnPyAgICAgIGJv b2xlYW4NCj4gICB8ICAgICArLS1ydyBydDpyb3V0aW5nLWluc3RhbmNlPyAgIHJvdXRpbmctaW5z dGFuY2UtcmVmDQo+ICAgKy0tcm8gaW50ZXJmYWNlcy1zdGF0ZQ0KPiAgICAgICstLXJvIGludGVy ZmFjZSogW25hbWVdDQo+ICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAgICAgICAgICBzdHJp bmcNCj4gICAgICAgICArLS1ybyB0eXBlICAgICAgICAgICAgICAgICAgIGlkZW50aXR5cmVmDQo+ ICAgICAgICAgKy0tcm8gb3Blci1zdGF0dXMgICAgICAgICAgICBlbnVtZXJhdGlvbg0KPiAgICAg ICAgICstLXJvIGxhc3QtY2hhbmdlPyAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lDQo+ICAg ICAgICAgKy0tcm8gcGh5cy1hZGRyZXNzPyAgICAgICAgICB5YW5nOnBoeXMtYWRkcmVzcw0KPiAg ICAgICAgICstLXJvIGhpZ2hlci1sYXllci1pZiogICAgICAgaW50ZXJmYWNlLXN0YXRlLXJlZg0K PiAgICAgICAgICstLXJvIGxvd2VyLWxheWVyLWlmKiAgICAgICAgaW50ZXJmYWNlLXN0YXRlLXJl Zg0KPiAgICAgICAgICstLXJvIHNwZWVkPyAgICAgICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQo+ ICAgICAgICAgKy0tcm8gc3RhdGlzdGljcw0KPiAgICAgICAgIHwgICstLXJvIGRpc2NvbnRpbnVp dHktdGltZSAgICB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gICAgICAgICB8ICArLS1ybyBpbi1vY3Rl dHM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBpbi11bmlj YXN0LXBrdHM/ICAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBpbi1icm9h ZGNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBpbi1tdWx0 aWNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBpbi1kaXNj YXJkcz8gICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICB8ICArLS1ybyBpbi1lcnJv cnM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICB8ICArLS1ybyBpbi11bmtu b3duLXByb3Rvcz8gICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICB8ICArLS1ybyBvdXQtb2N0 ZXRzPyAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBvdXQtdW5p Y2FzdC1wa3RzPyAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBvdXQtYnJv YWRjYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBvdXQtbXVs dGljYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICB8ICArLS1ybyBvdXQtZGlz Y2FyZHM/ICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICB8ICArLS1ybyBvdXQtZXJy b3JzPyAgICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICArLS1ybyBpcDppcHY0IQ0K PiAgICAgICAgIHwgICstLXJvIGlwOmZvcndhcmRpbmc/ICAgYm9vbGVhbg0KPiAgICAgICAgIHwg ICstLXJvIGlwOm10dT8gICAgICAgICAgdWludDE2DQo+ICAgICAgICAgfCAgKy0tcm8gaXA6YWRk cmVzcyogW2lwXQ0KPiAgICAgICAgIHwgIHwgICstLXJvIGlwOmlwICAgICAgICAgICAgICAgaW5l dDppcHY0LWFkZHJlc3Mtbm8tem9uZQ0KPiAgICAgICAgIHwgIHwgICstLXJvIChzdWJuZXQpPw0K PiAgICAgICAgIHwgIHwgIHwgICstLToocHJlZml4LWxlbmd0aCkNCj4gICAgICAgICB8ICB8ICB8 ICAgICArLS1ybyBpcDpwcmVmaXgtbGVuZ3RoPyAgIHVpbnQ4DQo+ICAgICAgICAgfCAgfCAgKy0t cm8gaXA6b3JpZ2luPyAgICAgICAgICBpcC1hZGRyZXNzLW9yaWdpbg0KPiAgICAgICAgIHwgICst LXJvIGlwOm5laWdoYm9yKiBbaXBdDQo+ICAgICAgICAgfCAgICAgKy0tcm8gaXA6aXAgICAgICAg ICAgICAgICAgICAgIGluZXQ6aXB2NC1hZGRyZXNzLW5vLXpvbmUNCj4gICAgICAgICB8ICAgICAr LS1ybyBpcDpsaW5rLWxheWVyLWFkZHJlc3M/ICAgeWFuZzpwaHlzLWFkZHJlc3MNCj4gICAgICAg ICB8ICAgICArLS1ybyBpcDpvcmlnaW4/ICAgICAgICAgICAgICAgbmVpZ2hib3Itb3JpZ2luDQo+ ICAgICAgICAgKy0tcm8gaXA6aXB2NiENCj4gICAgICAgICB8ICArLS1ybyBpcDpmb3J3YXJkaW5n PyAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCj4gICAgICAgICB8ICArLS1ybyBpcDptdHU/ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMg0KPiAgICAgICAgIHwgICstLXJvIGlw OmFkZHJlc3MqIFtpcF0NCj4gICAgICAgICB8ICB8ICArLS1ybyBpcDppcCAgICAgICAgICAgICAg IGluZXQ6aXB2Ni1hZGRyZXNzLW5vLXpvbmUNCj4gICAgICAgICB8ICB8ICArLS1ybyBpcDpwcmVm aXgtbGVuZ3RoICAgIHVpbnQ4DQo+ICAgICAgICAgfCAgfCAgKy0tcm8gaXA6b3JpZ2luPyAgICAg ICAgICBpcC1hZGRyZXNzLW9yaWdpbg0KPiAgICAgICAgIHwgIHwgICstLXJvIGlwOnN0YXR1cz8g ICAgICAgICAgZW51bWVyYXRpb24NCj4gICAgICAgICB8ICArLS1ybyBpcDpuZWlnaGJvciogW2lw XQ0KPiAgICAgICAgIHwgIHwgICstLXJvIGlwOmlwICAgICAgICAgICAgICAgICAgICBpbmV0Omlw djYtYWRkcmVzcy1uby16b25lDQo+ICAgICAgICAgfCAgfCAgKy0tcm8gaXA6bGluay1sYXllci1h ZGRyZXNzPyAgIHlhbmc6cGh5cy1hZGRyZXNzDQo+ICAgICAgICAgfCAgfCAgKy0tcm8gaXA6b3Jp Z2luPyAgICAgICAgICAgICAgIG5laWdoYm9yLW9yaWdpbg0KPiAgICAgICAgIHwgIHwgICstLXJv IGlwOmlzLXJvdXRlcj8gICAgICAgICAgICBlbXB0eQ0KPiAgICAgICAgIHwgIHwgICstLXJvIGlw OnN0YXRlPyAgICAgICAgICAgICAgICBlbnVtZXJhdGlvbg0KPiAgICAgICAgIHwgICstLXJvIHY2 dXI6aXB2Ni1yb3V0ZXItYWR2ZXJ0aXNlbWVudHMNCj4gICAgICAgICB8ICAgICArLS1ybyB2NnVy OnNlbmQtYWR2ZXJ0aXNlbWVudHM/ICAgIGJvb2xlYW4NCj4gICAgICAgICB8ICAgICArLS1ybyB2 NnVyOm1heC1ydHItYWR2LWludGVydmFsPyAgIHVpbnQxNg0KPiAgICAgICAgIHwgICAgICstLXJv IHY2dXI6bWluLXJ0ci1hZHYtaW50ZXJ2YWw/ICAgdWludDE2DQo+ICAgICAgICAgfCAgICAgKy0t cm8gdjZ1cjptYW5hZ2VkLWZsYWc/ICAgICAgICAgICBib29sZWFuDQo+ICAgICAgICAgfCAgICAg Ky0tcm8gdjZ1cjpvdGhlci1jb25maWctZmxhZz8gICAgICBib29sZWFuDQo+ICAgICAgICAgfCAg ICAgKy0tcm8gdjZ1cjpsaW5rLW10dT8gICAgICAgICAgICAgICB1aW50MzINCj4gICAgICAgICB8 ICAgICArLS1ybyB2NnVyOnJlYWNoYWJsZS10aW1lPyAgICAgICAgIHVpbnQzMg0KPiAgICAgICAg IHwgICAgICstLXJvIHY2dXI6cmV0cmFucy10aW1lcj8gICAgICAgICAgdWludDMyDQo+ICAgICAg ICAgfCAgICAgKy0tcm8gdjZ1cjpjdXItaG9wLWxpbWl0PyAgICAgICAgICB1aW50OA0KPiAgICAg ICAgIHwgICAgICstLXJvIHY2dXI6ZGVmYXVsdC1saWZldGltZT8gICAgICAgdWludDE2DQo+ICAg ICAgICAgfCAgICAgKy0tcm8gdjZ1cjpwcmVmaXgtbGlzdA0KPiAgICAgICAgIHwgICAgICAgICst LXJvIHY2dXI6cHJlZml4KiBbcHJlZml4LXNwZWNdDQo+ICAgICAgICAgfCAgICAgICAgICAgKy0t cm8gdjZ1cjpwcmVmaXgtc3BlYyAgICAgICAgICAgaW5ldDppcHY2LXByZWZpeA0KPiAgICAgICAg IHwgICAgICAgICAgICstLXJvIHY2dXI6dmFsaWQtbGlmZXRpbWU/ICAgICAgIHVpbnQzMg0KPiAg ICAgICAgIHwgICAgICAgICAgICstLXJvIHY2dXI6b24tbGluay1mbGFnPyAgICAgICAgIGJvb2xl YW4NCj4gICAgICAgICB8ICAgICAgICAgICArLS1ybyB2NnVyOnByZWZlcnJlZC1saWZldGltZT8g ICB1aW50MzINCj4gICAgICAgICB8ICAgICAgICAgICArLS1ybyB2NnVyOmF1dG9ub21vdXMtZmxh Zz8gICAgICBib29sZWFuDQo+ICAgICAgICAgKy0tcm8gcnQ6cm91dGluZy1pbnN0YW5jZT8gICBy b3V0aW5nLWluc3RhbmNlLXN0YXRlLXJlZg0KPm1vZHVsZTogaWV0Zi1yb3V0aW5nDQo+ICAgKy0t cm8gcm91dGluZy1zdGF0ZQ0KPiAgIHwgICstLXJvIHJvdXRpbmctaW5zdGFuY2UqIFtuYW1lXQ0K PiAgIHwgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgIHwgICAgICst LXJvIHR5cGU/ICAgICAgICAgICAgICAgIGlkZW50aXR5cmVmDQo+ICAgfCAgICAgKy0tcm8gcm91 dGVyLWlkPyAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVhZA0KPiAgIHwgICAgICstLXJvIGludGVy ZmFjZXMNCj4gICB8ICAgICB8ICArLS1ybyBpbnRlcmZhY2UqICAgaWY6aW50ZXJmYWNlLXN0YXRl LXJlZg0KPiAgIHwgICAgICstLXJvIHJvdXRpbmctcHJvdG9jb2xzDQo+ICAgfCAgICAgfCAgKy0t cm8gcm91dGluZy1wcm90b2NvbCogW3R5cGUgbmFtZV0NCj4gICB8ICAgICB8ICAgICArLS1ybyB0 eXBlICAgIGlkZW50aXR5cmVmDQo+ICAgfCAgICAgfCAgICAgKy0tcm8gbmFtZSAgICBzdHJpbmcN Cj4gICB8ICAgICArLS1ybyByaWJzDQo+ICAgfCAgICAgICAgKy0tcm8gcmliKiBbbmFtZV0NCj4g ICB8ICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICBzdHJpbmcNCj4gICB8ICAgICAg ICAgICArLS1ybyBhZGRyZXNzLWZhbWlseSAgICBpZGVudGl0eXJlZg0KPiAgIHwgICAgICAgICAg ICstLXJvIGRlZmF1bHQtcmliPyAgICAgIGJvb2xlYW4ge211bHRpcGxlLXJpYnN9Pw0KPiAgIHwg ICAgICAgICAgICstLXJvIHJvdXRlcw0KPiAgIHwgICAgICAgICAgICAgICstLXJvIHJvdXRlKg0K PiAgIHwgICAgICAgICAgICAgICAgICstLXJvIHJvdXRlLXByZWZlcmVuY2U/ICAgICAgICAgIHJv dXRlLXByZWZlcmVuY2UNCj4gICB8ICAgICAgICAgICAgICAgICArLS1ybyBuZXh0LWhvcA0KPiAg IHwgICAgICAgICAgICAgICAgIHwgICstLXJvIChuZXh0LWhvcC1vcHRpb25zKQ0KPiAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICstLToob3V0Z29pbmctaW50ZXJmYWNlKQ0KPiAgIHwgICAgICAg ICAgICAgICAgIHwgICAgIHwgICstLXJvIG91dGdvaW5nLWludGVyZmFjZT8NCj5pZjppbnRlcmZh Y2Utc3RhdGUtcmVmDQo+ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgKy0tOihzcGVjaWFsLW5l eHQtaG9wKQ0KPiAgIHwgICAgICAgICAgICAgICAgIHwgICAgIHwgICstLXJvIHNwZWNpYWwtbmV4 dC1ob3A/ICAgICAgICBlbnVtZXJhdGlvbg0KPiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICst LToobmV4dC1ob3AtYWRkcmVzcykNCj4gICB8ICAgICAgICAgICAgICAgICB8ICAgICB8ICArLS1y byB2NnVyOm5leHQtaG9wLWFkZHJlc3M/DQo+aW5ldDppcHY2LWFkZHJlc3MNCj4gICB8ICAgICAg ICAgICAgICAgICB8ICAgICArLS06KG5leHQtaG9wLWFkZHJlc3MpDQo+ICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgKy0tcm8gdjR1cjpuZXh0LWhvcC1hZGRyZXNzPw0KPmluZXQ6aXB2NC1h ZGRyZXNzDQo+ICAgfCAgICAgICAgICAgICAgICAgKy0tcm8gc291cmNlLXByb3RvY29sICAgICAg ICAgICAgaWRlbnRpdHlyZWYNCj4gICB8ICAgICAgICAgICAgICAgICArLS1ybyBhY3RpdmU/ICAg ICAgICAgICAgICAgICAgICBlbXB0eQ0KPiAgIHwgICAgICAgICAgICAgICAgICstLXJvIGxhc3Qt dXBkYXRlZD8gICAgICAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KPiAgIHwgICAgICAgICAg ICAgICAgICstLXJvIHY2dXI6ZGVzdGluYXRpb24tcHJlZml4PyAgIGluZXQ6aXB2Ni1wcmVmaXgN Cj4gICB8ICAgICAgICAgICAgICAgICArLS1ybyB2NHVyOmRlc3RpbmF0aW9uLXByZWZpeD8gICBp bmV0OmlwdjQtcHJlZml4DQo+ICAgKy0tcncgcm91dGluZw0KPiAgICAgICstLXJ3IHJvdXRpbmct aW5zdGFuY2UqIFtuYW1lXQ0KPiAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgIHN0 cmluZw0KPiAgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgICAgIGlkZW50aXR5cmVmDQo+ ICAgICAgICAgKy0tcncgZW5hYmxlZD8gICAgICAgICAgICAgYm9vbGVhbg0KPiAgICAgICAgICst LXJ3IHJvdXRlci1pZD8gICAgICAgICAgIHlhbmc6ZG90dGVkLXF1YWQNCj4gICAgICAgICArLS1y dyBkZXNjcmlwdGlvbj8gICAgICAgICBzdHJpbmcNCj4gICAgICAgICArLS1ydyByb3V0aW5nLXBy b3RvY29scw0KPiAgICAgICAgIHwgICstLXJ3IHJvdXRpbmctcHJvdG9jb2wqIFt0eXBlIG5hbWVd DQo+ICAgICAgICAgfCAgICAgKy0tcncgdHlwZSAgICAgICAgICAgICBpZGVudGl0eXJlZg0KPiAg ICAgICAgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgc3RyaW5nDQo+ICAgICAgICAgfCAg ICAgKy0tcncgZGVzY3JpcHRpb24/ICAgICBzdHJpbmcNCj4gICAgICAgICB8ICAgICArLS1ydyBz dGF0aWMtcm91dGVzDQo+ICAgICAgICAgfCAgICAgICAgKy0tcncgdjZ1cjppcHY2DQo+ICAgICAg ICAgfCAgICAgICAgfCAgKy0tcncgdjZ1cjpyb3V0ZSogW2Rlc3RpbmF0aW9uLXByZWZpeF0NCj4g ICAgICAgICB8ICAgICAgICB8ICAgICArLS1ydyB2NnVyOmRlc3RpbmF0aW9uLXByZWZpeCAgICBp bmV0OmlwdjYtcHJlZml4DQo+ICAgICAgICAgfCAgICAgICAgfCAgICAgKy0tcncgdjZ1cjpkZXNj cmlwdGlvbj8gICAgICAgICAgc3RyaW5nDQo+ICAgICAgICAgfCAgICAgICAgfCAgICAgKy0tcncg djZ1cjpuZXh0LWhvcA0KPiAgICAgICAgIHwgICAgICAgIHwgICAgICAgICstLXJ3IChuZXh0LWhv cC1vcHRpb25zKQ0KPiAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICstLToob3V0Z29pbmct aW50ZXJmYWNlKQ0KPiAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IHY2dXI6 b3V0Z29pbmctaW50ZXJmYWNlPw0KPmlmOmludGVyZmFjZS1yZWYNCj4gICAgICAgICB8ICAgICAg ICB8ICAgICAgICAgICArLS06KHNwZWNpYWwtbmV4dC1ob3ApDQo+ICAgICAgICAgfCAgICAgICAg fCAgICAgICAgICAgfCAgKy0tcncgdjZ1cjpzcGVjaWFsLW5leHQtaG9wPw0KPmVudW1lcmF0aW9u DQo+ICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgKy0tOihuZXh0LWhvcC1hZGRyZXNzKQ0K PiAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICstLXJ3IHY2dXI6bmV4dC1ob3AtYWRk cmVzcz8NCj5pbmV0OmlwdjYtYWRkcmVzcw0KPiAgICAgICAgIHwgICAgICAgICstLXJ3IHY0dXI6 aXB2NA0KPiAgICAgICAgIHwgICAgICAgICAgICstLXJ3IHY0dXI6cm91dGUqIFtkZXN0aW5hdGlv bi1wcmVmaXhdDQo+ICAgICAgICAgfCAgICAgICAgICAgICAgKy0tcncgdjR1cjpkZXN0aW5hdGlv bi1wcmVmaXggICAgaW5ldDppcHY0LXByZWZpeA0KPiAgICAgICAgIHwgICAgICAgICAgICAgICst LXJ3IHY0dXI6ZGVzY3JpcHRpb24/ICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgIHwgICAgICAg ICAgICAgICstLXJ3IHY0dXI6bmV4dC1ob3ANCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAr LS1ydyAobmV4dC1ob3Atb3B0aW9ucykNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAr LS06KG91dGdvaW5nLWludGVyZmFjZSkNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8 ICArLS1ydyB2NHVyOm91dGdvaW5nLWludGVyZmFjZT8NCj5pZjppbnRlcmZhY2UtcmVmDQo+ICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgKy0tOihzcGVjaWFsLW5leHQtaG9wKQ0KPiAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgIHwgICstLXJ3IHY0dXI6c3BlY2lhbC1uZXh0LWhvcD8N Cj5lbnVtZXJhdGlvbg0KPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICstLToobmV4dC1o b3AtYWRkcmVzcykNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICArLS1ydyB2NHVy Om5leHQtaG9wLWFkZHJlc3M/DQo+aW5ldDppcHY0LWFkZHJlc3MNCj4gICAgICAgICArLS1ydyBy aWJzDQo+ICAgICAgICAgICAgKy0tcncgcmliKiBbbmFtZV0NCj4gICAgICAgICAgICAgICArLS1y dyBuYW1lICAgICAgICAgICAgICBzdHJpbmcNCj4gICAgICAgICAgICAgICArLS1ydyBhZGRyZXNz LWZhbWlseT8gICBpZGVudGl0eXJlZg0KPiAgICAgICAgICAgICAgICstLXJ3IGRlc2NyaXB0aW9u PyAgICAgIHN0cmluZw0KPg0KPiJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4g d3JpdGVzOg0KPg0KPj4gT24gMTAvMTMvMTUsIDEyOjMwIFBNLCAiTGFkaXNsYXYgTGhvdGthIiA8 bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj4+IE9uIDEzIE9jdCAyMDE1LCBhdCAx NzoyMCwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IA0K Pj4+PiBIaSBMYWRhLCBORVRNT0QsDQo+Pj4+IA0KPj4+PiBTbyBJIHRoaW5rIHdlIHNob3VsZCBt b3ZlIGZvcndhcmQgdGhpcyBpZXRmLXJ0Zy1jZmcgc28gdGhhdCBpdCBjYW4gYmUNCj4+Pj4gYXVn bWVudGVkIGFuZCBvdGhlciB3b3JrIGNhbiBtb3ZlIGZvcndhcmQuIFdlIGFyZSBzdGlsbCBpbg0K Pj4+PmRpc2FncmVlbWVudA0KPj4+PiB3aXRoIHJlc3BlY3QgdG8gcm91dGluZy1pbnN0YW5jZS9p bnRlcmZhY2UgY29uZmlndXJhdGlvbi4NCj4+Pj4gDQo+Pj4+ICAgIC0gV2UgZmVlbCB0aGUgSVB2 NC9JUHY2IGludGVyZmFjZXMgc2hvdWxkIHJlZmVyZW5jZSB0aGUNCj4+Pj4gcm91dGluZy1pbnN0 YW5jZSBpbiB0aGVpciBjb25maWcgc3RhdGUuIFRoaXMgaXMgY29uc2lzdGVudCB3aXRoDQo+Pj4+ IGRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDEudHh0Lg0KPj4+PiAgICAtIFlv dSBmZWVsIHRoYXQgdGhlIHJvdXRpbmctaW5zdGFuY2Ugc2hvdWxkIGhhdmUgYSBsaXN0IG9mDQo+ Pj4+bGVhZi1yZWbigJlzDQo+Pj4+IHRvIHRoZSBpbnRlcmZhY2UuIFlvdSBiZWxpZXZlIHRoZSBs ZWFmLXJlZiBwcm92aWRlcyBhIGxldmVsIG9mDQo+Pj4+dmFsaWRhdGlvbg0KPj4+PiBkdWUgdG8g dGhlIGZhY3QgdGhhdCByZWZlcmVuY2VzIGNhbiBiZSBjb25maW5lZCB0byByb3V0aW5nLWluc3Rh bmNlDQo+Pj4+IHJlZmVyZW5jZXMuIEhvd2V2ZXIsIGhlcmV0b2ZvcmUsIG5vIG1vZGVscyBhcmUg cmVmZXJlbmNpbmcgdGhlDQo+Pj4+aW50ZXJmYWNlDQo+Pj4+IGxlYWYtcmVmcyBpbiB0aGUgbGlz dC4NCj4+Pg0KPj4+VHJ1ZSwgdGhlc2UgbW9kZWxzIChpZXRmLWlzaXMsIGZvciBpbnN0YW5jZSkg dXNlIGxlYWZyZWZzIHdpdGgNCj4+PiJpZjppbnRlcmZhY2UtcmVmIiB0eXBlLiBIb3dldmVyLCBz dWNoIGxlYWZyZWZzIGFyZSB1bmRlci1jb25zdHJhaW5lZA0KPj4+YmVjYXVzZSB0aGV5IGNhbiBi ZSBjb25maWd1cmVkIHRvIHJlZmVyIHRvOg0KPj4+DQo+Pj4tIGludGVyZmFjZXMgb2YgYW55IGxh eWVyLCBpbmNsdWRpbmcgcGh5c2ljYWwgaW50ZXJmYWNlcywgVkxBTiB0cnVua3MNCj4+PmV0Yy4N Cj4+DQo+PiBBY3R1YWxseSwgcHV0dGluZyB0aGUgcm91dGluZy1pbnN0YW5jZSByZWZlcmVuY2Ug aW4gdGhlIElQdjQgYW5kIElQdjYNCj4+IGludGVyZmFjZSBtb2RlbHMgKGkuZS4sIFJGQyA3Mjc3 KSBjb25zdHJhaW5zIHRoZSByZWZlcmVuY2UgdG8gbGF5ZXIgMw0KPj5tb3JlDQo+PiBlZmZlY3Rp dmVseSB0aGFuIHRoZSBsaXN0IG9mIGxlYWYtcmVmcy4NCj4+DQo+Pj4NCj4+Pi0gaW50ZXJmYWNl cyBhc3NpZ25lZCB0byBhbnkgcm91dGluZyBpbnN0YW5jZS4NCj4+DQo+PiBCdXQgdGhlIGxpc3Qg b2YgbGVhZi1yZWZzIGRvZXNu4oCZdCBpbnN1cmUgYW4gSVB2NCBpbnRlcmZhY2Ugb3IgSVB2Ng0K Pj4gaW50ZXJmYWNlIGlzbuKAmXQgaW5jbHVkZWQgYnkgYSBzaW5nbGUgcm91dGluZy1pbnN0YW5j ZS4NCj4+DQo+Pj4NCj4+PkkgYmVsaWV2ZSBpbiBhbGwgdGhlc2UgY2FzZXMgdGhlIGNob2ljZSBo YXMgdG8gYmUgbGltaXRlZCB0byAoMSkgTDMNCj4+PmludGVyZmFjZXMsIGFuZCAoMikgYmVsb25n aW5nIHRvICJvd24iIHJvdXRpbmcgaW5zdGFuY2UuIFRoZXNlDQo+Pj5jb25zdHJhaW50cyB3aWxs IGhhdmUgdG8gYmUgY2hlY2tlZCBpbiBzZXJ2ZXIgY29kZSBzb21laG93IC0gSSB3b3VsZA0KPj4+ cHJlZmVyIHRvIGhhdmUgdGhlbSByZXByZXNlbnRlZCBpbiB0aGUgZGF0YSBtb2RlbC4NCj4+Pg0K Pj4+QnV0IGlmIG5vYm9keSBzaGFyZXMgdGhpcyBjb25jZXJuIHdpdGggbWUsIEkgYW0gbm90IGdv aW5nIHRvIGJsb2NrIHRoZQ0KPj4+ZG9jdW1lbnQgb24gdGhpcyBpc3N1ZS4NCj4+DQo+PiBJ4oCZ ZCBhbHNvIGJlIGludGVyZXN0ZWQgaWYgYW55b25lIHNoYXJlcyB0aGlzIGNvbmNlcm4uDQo+Pg0K Pj4gVGhhbmtzLA0KPj4gQWNlZSANCj4+DQo+Pg0KPj4+DQo+Pj5MYWRhIA0KPj4+DQo+Pj4+IA0K Pj4+PiBPdGhlciB0aGFuIHRoZSBSb3V0aW5nIFlBTkcgRGVzaWduIFRlYW0gaGF2aW5nIGNob3Nl biB0aGUgZmlyc3QNCj4+Pj5vcHRpb24gLQ0KPj4+PiBhcmUgdGhlcmUgYW55IG90aGVyIG9waW5p b25zPw0KPj4+PiANCj4+Pj4gVGhhbmtzLA0KPj4+PiBBY2VlDQo+Pj4+IA0KPj4+PiBPbiAxMC85 LzE1LCA5OjAwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSAoYWNlZSkiDQo+ Pj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5jb20+ IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIExhZGEsIA0KPj4+Pj4gSTJSUyBpcyBub3QgY2hhcnRl cmVkIHRvIGRvIHRoZSBiYXNlIG1vZGVscy4gVGhlcmUgYXJlIG90aGVyIHJvdXRpbmcNCj4+Pj4+ IG1vZGVscyB0aGF0IHJlZmVyZW5jZSByb3V0aW5nLWNmZyBhbmQgZXZlbiBpbi1wcm9ncmVzcw0K Pj4+Pj5pbXBsZW1lbnRhdGlvbnMuDQo+Pj4+PiANCj4+Pj4+IE9uIDEwLzkvMTUsIDQ6MTMgQU0s ICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj4+Pj4+IDxuZXRtb2QtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+PiAN Cj4+Pj4+PiBIaSwNCj4+Pj4+PiANCj4+Pj4+PiBJIGFtIHNvcnJ5IGZvciBjcm9zcy1wb3N0aW5n IGJ1dCBJIHRoaW5rIGl0IGlzIGhpZ2ggdGltZSB0byBkZWNpZGUNCj4+Pj4+PnRoZQ0KPj4+Pj4+ IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBkYXRhIG1vZGVscyBpbiBpMnJzLXJpYi1kYXRhLW1v ZGVsIGFuZA0KPj4+Pj4+IG5ldG1vZC1yb3V0aW5nLWNmZyBJLURzIGJlY2F1c2UgdGhleSBjbGVh cmx5IHRhcmdldCB0aGUgc2FtZQ0KPj4+Pj4+bWFuYWdlbWVudA0KPj4+Pj4+IGRhdGEgaW4gYSBy b3V0ZXIuIEkgY2FuIHNlZSB0aHJlZSBwb3NzaWJsZSBzY2VuYXJpb3M6DQo+Pj4+Pj4gDQo+Pj4+ Pj4gMS4gVGhlIGkycnMtcmliIG1vZHVsZSB3aWxsIGJlIG1vZGlmaWVkIHRvIGF1Z21lbnQNCj4+ Pj4+PiBpZXRmLXJvdXRpbmcvaWV0Zi1pcHZbNDZdLXVuaWNhc3Qtcm91dGluZy4NCj4+Pj4+IA0K Pj4+Pj4gVGhpcyB3b3VsZCBzZWVtIHRvIGJlIHRoZSBvYnZpb3VzIGNob2ljZS4NCj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IDIuIFRoZSBzY29wZSBvZiBpZXRmLXJvdXRpbmcgd2lsbCBiZSBjaGFu Z2VkIHNvIHRoYXQgaXQgd291bGQNCj4+Pj4+PmFkZHJlc3MNCj4+Pj4+PiBvbmx5IGhvc3Qgcm91 dGluZyBhbmQgc2ltcGxlIHJvdXRlcnMuIFRoZSBtb2RlbGxpbmcgd29yayBmb3INCj4+Pj4+PmFk dmFuY2VkDQo+Pj4+Pj4gcm91dGVycyB3aWxsIGJlIGRvbmUgZWxzZXdoZXJlLg0KPj4+Pj4+IA0K Pj4+Pj4+IDMuIFRoZSB3b3JrIG9uIG5ldG1vZC1yb3V0aW5nLWNmZyB3aWxsIGJlIHN0b3BwZWQu DQo+Pj4+PiANCj4+Pj4+IEEgZm91cnRoIG9wdGlvbiB3b3VsZCBiZSBmb3IgbWUgdG8gdGFrZSBv dmVyIG93bmVyc2hpcCwgbW92ZSB0aGUgd29yaw0KPj4+Pj50bw0KPj4+Pj4gdGhlIFJURyBXRywg YW5kIHdl4oCZZCByZWNydWl0IHNvbWUgc3Ryb25nIGF1dGhvcnMvcmV2aWV3ZXJzIGZyb20NCj4+ Pj4+b3BlcmF0b3JzDQo+Pj4+PiBhbmQgb3RoZXIgdmVuZG9ycyAoaW52b2x2aW5nIHRoZSBBRHMg aW4gc2VsZWN0aW9uKS4NCj4+Pj4+IA0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gQWNlZSANCj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gT3BpbmlvbnM/DQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhh bmtzLCBMYWRhDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiBMYWRpc2xhdiBMaG90a2EsIENa Lk5JQyBMYWJzDQo+Pj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBuZXRt b2RAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4gbmV0bW9kQGll dGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KPj4+PiANCj4+Pg0KPj4+LS0NCj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+ PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+DQo+LS0gDQo+ TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg== From nobody Thu Oct 15 14:59:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C851A6FFD for ; Thu, 15 Oct 2015 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crp-fuANZVal for ; Thu, 15 Oct 2015 14:59:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A1E1A6FF5 for ; Thu, 15 Oct 2015 14:59:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79E3C7DE; Thu, 15 Oct 2015 23:59:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r6pq193CdUmA; Thu, 15 Oct 2015 23:59:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Oct 2015 23:59:30 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E49E20054; Thu, 15 Oct 2015 23:59:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CsZAP6TC8fjR; Thu, 15 Oct 2015 23:59:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAB3920053; Thu, 15 Oct 2015 23:59:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CFD0137B53AC; Thu, 15 Oct 2015 23:59:27 +0200 (CEST) Date: Thu, 15 Oct 2015 23:59:27 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20151015215927.GC72419@elstar.local> Mail-Followup-To: Kent Watsen , Gert Grammel , Robert Wilton , "netmod@ietf.org" References: <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> <561FB149.103@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 21:59:35 -0000 On Thu, Oct 15, 2015 at 05:03:33PM +0000, Kent Watsen wrote: > These terms were edited on today's call, resulting in the following text: > > Synchronous configuration operation - A configuration request to update > the running configuration of a server that is applied synchronously with > respect to the client request. The server MUST fully attempt to apply > the configuration change to all impacted components in the server, > updating both the server's intended and applied configuration (see terms), > before replying to the client. This may be transactional or non- > transactional (need terms!). The transactionality of the operation > may be a server property or specified on as a property. I do not understand the transactionality blurb. What is it and why is it relevant? (The last sentence above also seems incomplete.) > The reply to the client indicates whether there > are any errors in the request or errors from applying the configuration > change. > > Asynchronous configuration operation - A configuration request to update > the running configuration of a server that is applied asynchronously > with respect to the client request. The server MUST update its intended > configuration (see term) before replying to the client indicating > whether the request will be processed. This reply to the client only > indicates whether there are any errors in the original request. The > server's applied configuration state (see term) is updated after the > configuration change has been fully effected to all impacted components > in the server. Once applied, there MUST be a mechanism for the client to > determine when the request has completed processing and whether the > intended config is now fully effective or there are any errors from > applying the configuration change, which could be from an asynchronous > notification or via a client operation. > > Synchronous configuration server - a configuration server that processes > all configuration operations as synchronous configuration operations. > > Asynchronous configuration server - a configuration server that processes > all configuration operations as asynchronous configuration operations. > > > We have consensus on the above, but are hoping for some word-smithing before committing it to the draft. Anybody want to take a crack at it? > > BTW, do we still need to define the last two terms anymore? - they're not used elsewhere in the draft... > If we do not need the terms sync/async config server, simply remove them. If we keep them, I suggest to add the mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Pure sync/async servers are likely rare. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 15 15:34:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4731A8766 for ; Thu, 15 Oct 2015 15:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yhfgq3Q5qiDB for ; Thu, 15 Oct 2015 15:34:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FF41A8771 for ; Thu, 15 Oct 2015 15:34:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6412BF85; Fri, 16 Oct 2015 00:34:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0Oc2LXhv8bGW; Fri, 16 Oct 2015 00:34:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Oct 2015 00:34:43 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AF8E20054; Fri, 16 Oct 2015 00:34:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F8lwUBLR7Ryb; Fri, 16 Oct 2015 00:34:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7757020053; Fri, 16 Oct 2015 00:34:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A8F7D37B552B; Fri, 16 Oct 2015 00:34:41 +0200 (CEST) Date: Fri, 16 Oct 2015 00:34:41 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151015223441.GD72419@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 22:34:47 -0000 On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > Conformance to YANG for the extension: NONE This includes syntax and > semantics. It makes no sense at all (Lada is right) to say the > extension semantics apply. They only apply if the tool supports the > extension. Conformance to the extension is a different matter. I would hope that a server supporting NACM implements the behaviour of nacm:default-deny-write when nodes are tagged with this extension. Sure, a YANG parser is allowed to skip over nacm:default-deny-write but if nacm:default-deny-write is used for a certain node, I think we want the server to implement the semantics implied by nacm:default-deny-write regardless which tool the developer used. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 15 15:58:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3B31A049A for ; Thu, 15 Oct 2015 15:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIhB2B4OYhxx for ; Thu, 15 Oct 2015 15:58:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B63B1A0252 for ; Thu, 15 Oct 2015 15:58:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E24F7F85; Fri, 16 Oct 2015 00:58:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ir7RXBy4XWBw; Fri, 16 Oct 2015 00:58:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Oct 2015 00:58:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D196E20054; Fri, 16 Oct 2015 00:58:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vR-2YxLImKw7; Fri, 16 Oct 2015 00:58:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EE6020053; Fri, 16 Oct 2015 00:58:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A04337B55C6; Fri, 16 Oct 2015 00:58:46 +0200 (CEST) Date: Fri, 16 Oct 2015 00:58:46 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20151015225846.GE72419@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151015.223749.1017340653632922486.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 22:58:54 -0000 On Thu, Oct 15, 2015 at 10:37:49PM +0200, Martin Bjorklund wrote: > > > * p12/p13 > > > > We import 7 terms from RFC 6241. Would it make sense to copy the > > necessary text in order to avoid a too strict binding to RFC 6241? > > In particular, 'client' and 'server' means NETCONF client and server > > if we import from RFC 6241 but this may be a bit narrow given that > > we have RESTCONF as well. In an ideal world, we would factor out > > core architectural concepts but the best we can do is likely to > > define core concepts inline, pointing out where they are the same. > > The idea is to loosen the coupling to RFC 6241. Example: > > > > OLD > > > > o datastore: an instantiated data tree > > > > NEW > > > > o datastore: A conceptual place to store and access information. > > A datastore might be implemented, for example, using files, a > > database, flash memory locations, or combinations thereof. > > [Matches the definition in RFC 6241.] > > To start with, I think we should define client and server more > generically than just NETCONF: > > server: An entity that provides access to YANG-defined data to a > client, over some network management protocol. > > client: An entity that can access YANG-defined data on a server, > over some network management protocol. > Yes, we should definately open things up so that RESTCONF clients and servers are covered. > > * p13 > > > > Would it make sense to add a sentence right at the beginning of > > section 4 stating that section 4 is intended to provide orientation > > for the first time reader but that section 4 is not normative? > > How about: > > This non-normative section is intended to give a high-level > overview of YANG to first-time readers. OK > > * p16 > > > > Perhaps simplify: > > > > OLD > > > > A leaf instance contains simple data like an integer or a string. It > > has exactly one value of a particular type and no child nodes. > > > > NEW > > > > A leaf data node has exactly one value of a particular type and no > > child nodes. > > We changed this to "leaf instance" after discussion with Lada. I > think it makes sense to mention that it is supposed to contain data > like an integer or string, so I think I prefer to keep this text as > is. I think the document uses 'leaf' in different meanings; sometimes a leaf is a 'leaf schema node instance' and sometimes a leaf is 'any leaf of the tree'. This is what got me started here but perhaps the context is clear enough (hence the 'perhaps simplify'). > > * p28 > > > > Start section 5 by saying that this section defined language > > concepts and that it is normative, e.g. > > > > This normative section defines core language concepts. > > But aren't all sections normative unless we say so? Otherwise it > seems we should start every section by saying that it is either > normative or not. OK > > * p49 > > > > Is the text in section 7.1.3 correct when it says all identifiers > > defined by the module? I mean, schema node identifiers are > > namespaced by module names and their prefixes. And data node > > identifiers are using the namespace in the XML encoding. Here is > > an attempt of a rewrite: > > > > The "namespace" statement defines the XML namespace that all data > > node identifiers defined by the module are qualified by in the > > XML encoding. Data node identifiers defined inside a grouping are > > an exception q(see Section 7.13 for details). The argument to > > the "namespace" statement is the URI of the namespace. > > It's actually not only data nodes, it is also rpc, actions, > notifications, identities. How about: > > The "namespace" statement defines the XML namespace that all > identifiers defined by the module are qualified by in the XML > encoding, with the exception of identifiers for data nodes, action > nodes, and notification nodes defined inside a grouping (see ^uses^ > for details). The argument to the "namespace" statement is the URI > of the namespace. OK > > * p61 > > > > Should the text in 7.5.4.1 and 7.5.4.2 say explicitly that we talk > > about NETCONF when we refer to ? Or should the text try > > to be more generic, saying that the respective fields will be > > carried in error message in protocols that use YANG? It is actually > > somewhat opaque what an error-app-tag is or how it should be used. > > I think we can say "If the constraint evaluates to false, the string is > passed as in the in NETCONF." Other > protocols have to define how these fields are used. OK > > * p63 > > > > Should the last paragraph in 7.5.7 be factored out into its own > > subsection titled "NETCONF and Operations"? The > > text is not really anymore about XML encoding (which may be used > > with RESTCONF). Or the text is actually about the encoding but > > should be written to simply state that non-presence containers can > > be pruned in encodings (without restricting this to NETCONF). > > This makes sense. I think the last paragraph can be replaced with: > > If a non-presence container does not have any child nodes, the > container may or may not be present in the XML encoding. OK > > * p67 > > > > Similar to the comment for p63. Perhaps the right way is to phrase > > this in such a way that is simply says leaf nodes containing a > > default value may not be present in the XML encoding. Simply remove > > NETCONF or specifics. > > Or maybe we should simply remove the last paragraph completely? For > NETCONF, RFC 6243 details how leafs with defaults are handled. Well, yes, but then readers may not know about RFC 6243. Perhaps state that leaf nodes containing a default value may not be present in the XML encoding and point to RFC 6243 for further details how NETCONF handles leafs with defaults (and I think the reference to RFC 6243 would be informative). > > * p100 > > > > The XML encoding text starts with detailing NETCONF specifics. > > Would it make sense to separate the XML encoding of the rpc and its > > input/output from the specifics how the RPCs fit into NETCONF's > > system? > > > Hmm. NETCONF and RESTCONF use quite different encodings of rpcs and > their output. > > NETCONF: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > 27606-0100 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > RESTCONF: > > POST to .../rock-the-house > > > 27606-0100 > > > result: 204 no content > > > Maybe it would have been better to have a common encoding, like: > > > ... > > > and > > > ... > > > but this cannot be done now. > > So, maybe the simplest solution would be to rename the section to > "NETCONF XML Encoding"? You mean section 7.14.4? Well, OK... Too bad these RPC encodings are actually different. Out of curiosity, was there a specific reason not to use 27606-0100 in the RESTCONF POST or did this "just happen"? > > * p105 > > > > Again, the proposal is to separate the XML encoding of notifications > > from the details how notifications work with RFC 5277. > > Also notifications are encoded differently in RESTCONF and NETCONF. Hm. > > * p120 > > > > The text in section 7.21.1 talks about NETCONF specific operations. > > Is this actually necessary? Can the purpose of the config statement > > not be described by referring to general concepts such as > > configuration datastores instead of using protocol specific > > operations? > > Yes, maybe we can just say: > > Data nodes representing configuration are part of configuration > datastores. Yes. > > * p123 > > > > "All leaf data values MUST match the type constraints..." may be > > read as 'all data nodes that contain values' or 'all instantiations > > of nodes defined by the leaf statement'. > > I don't really see what you mean. Can you suggest new text? See above, I think 'leaf' sometimes means an instance of a leaf schema node and sometimes it means all leaf instances of the data tree. Or I am confused. I think here you mean 'all leaf instances of the data tree' and not the subset of all 'instances of a leaf schema nodes'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 15 16:07:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4E1A86FD for ; Thu, 15 Oct 2015 16:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZznkuBvUwSF for ; Thu, 15 Oct 2015 16:07:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B7D1A036E for ; Thu, 15 Oct 2015 16:07:44 -0700 (PDT) Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB533.namprd05.prod.outlook.com (10.141.65.153) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 15 Oct 2015 23:07:42 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 15 Oct 2015 23:07:39 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 23:07:39 +0000 From: Gert Grammel To: Kent Watsen Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIE= Date: Thu, 15 Oct 2015 23:07:39 +0000 Message-ID: <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net> References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> <561FB149.103@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [80.187.108.121] x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:B2QAqJxOUflrP45VBiNnedeeio6xi1OQrCodo7NvWQJ7X8htr0Rmb+80sbKAkUl2mE6w1MuVHax0KBT/+qtkVXUDAQzJno8uocEE/37imG4kWR4VwT+Z5KylH20gkLP1q5A9VepyavuKNdyjMKnP1A==; 24:PEd3XJ61BEeosfz5GmuOBcJeCKe+eoIpatPyRA7WLthvOPbl7WnhfrtAgihdGds+zvBfZl/cqe9DwkjbHvBg7gfsSOQynhxkIq0JstsHkhU=; 20:TYLE0DKhctbDDxayaOs7aItWcyXAknsCXReZP10xlqC+Zjr+2a2nMcIEutPfg0Y0uos/4BWvcgjy76KHPvlJmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(52314003)(199003)(53754006)(164054003)(479174004)(189002)(76104003)(24454002)(505384003)(106356001)(5008740100001)(16236675004)(561944003)(110136002)(189998001)(15975445007)(10400500002)(102836002)(66066001)(19617315012)(36756003)(64706001)(92566002)(99286002)(106116001)(2900100001)(105586002)(2950100001)(33656002)(11100500001)(86362001)(50986999)(54356999)(4001450100002)(1941001)(81156007)(19580405001)(101416001)(5001960100002)(19580395003)(97736004)(122556002)(5007970100001)(5004730100002)(5002640100001)(87936001)(82746002)(93886004)(76176999)(83716003)(40100003)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_58A7E15C2DCD42458E6426F9C5F45F59junipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 23:07:39.3079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB533; 2:GRfRspwOS+MfKyM7oT00jaFKw7ke0uuT8Ve7fGNbSXA1QnonUc0yntSAPdVm3LsNmrlz0V950ddNME8IyKGRjbXS1QRVXCy3VgE9feeCkiJUjbfsIQ6ONO8yQcaE2qcegWPz0S8wxMP1GwAcR0uxPpPE2c55lOmP1gF1U1RFq8U=; 23:rV+RgymwPpKvlfUGISoFKYHjalxJE8XnNkpX9eYMLd9JAQ78NzpPX2AMpCLHYj51wET26NQxCl1v+Qiwk547qIDzbkTLRS+EBUZjjv3AQVjeLT1N52lpIViAdcbEBJsz5qDax6sknEM3+ih5WGr0+CKhjvjQOtRDMVAWEuEPWoNNFRZmrspHVQLtGVCDTS2W X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 23:07:52 -0000 --_000_58A7E15C2DCD42458E6426F9C5F45F59junipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kent, I don't see the need for defining synchronous/asynchronous config servers. The new definitions look good. Later in the discussion there was a common s= entiment that the requirement for synchronous operations contained some cri= sp wording we could use here too. I particularly liked the mentioning of blocking requests for some time, Nevertheless the proposed wording works for me. Gert Sent from my Apple ][ On 15 Oct 2015, at 19:03, Kent Watsen > wrote: These terms were edited on today's call, resulting in the following text: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously wit= h respect to the client request. The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see term= s), before replying to the client. This may be transactional or non- transactional (need terms!). The transactionality of the operation may be a server property or specified on as a property. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to updat= e the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intende= d configuration (see term) before replying to the client indicating whether the request will be processed. This reply to the client only indicates whether there are any errors in the original request. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. Once applied, there MUST be a mechanism for the client = to determine when the request has completed processing and whether the intended config is now fully effective or there are any errors from applying the configuration change, which could be from an asynchronous notification or via a client operation. Synchronous configuration server - a configuration server that processe= s all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that process= es all configuration operations as asynchronous configuration operations. We have consensus on the above, but are hoping for some word-smithing befor= e committing it to the draft. Anybody want to take a crack at it? BTW, do we still need to define the last two terms anymore? - they're not = used elsewhere in the draft... Kent From: Gert Grammel > Date: Thursday, October 15, 2015 at 10:35 AM To: Robert Wilton >, Kent Watse= n >, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Rob, >From a client perspective a server has three states: 1. intended !=3D applied 2. Funny-state 3. Intended =3D=3D applied Irrespective of synchronous or asynchronous processing in the server, the t= hird state MUST be reported to the client. Else (from a client perspective)= the server stays in funny-state forever. Gert From: Robert Wilton > Date: Thursday 15 October 2015 15:59 To: Gert Grammel >, Kent = Watsen >, "netmod@ietf.org<= mailto:netmod@ietf.org>" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Gert, Kent, I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way. E.g. if the = information as to whether a particular intended leave had been successfully= applied was available (e.g. as per github issue #2). So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.: E.g. replacing: Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange. Perhaps with: Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change. Or: Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change. Thanks, Rob On 15/10/2015 12:17, Gert Grammel wrote: Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn=92t look= complete. The way it stands for the synchronous operation, the client know= s that it's intended config was good AND it has been effected to the server= . In the Asynchronous case, the client only knows that the intended config = was good =96 and that=92s not enough. So the proposal is to refine the asynchronous case definition as follows: Asynchronous configuration operation - A configuration request to update th= e running configuration of a server that is applied asynchronously with res= pect to the client request. The server MUST update its intended configurat= ion (see term) before replying to the client indicating whether the request= will be processed. The reply to the client only indicates whether there a= re any errors in the original request. The server's applied configuration state (see term) is updated after the co= nfiguration change has been applied to all impacted components in the serve= r. Once applied, the client MUST be notified whether the intended config i= s now fully effective or there are any errors from applying the configurati= on change. In addition I would suggest to require a verify operation which a client ca= n request from the server to obtain above information on an on-demand basis= . Would that somehow go in the opstate-reqs #3 then? Best Gert From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen > Date: Thursday 15 October 2015 00:11 To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy= nchronous (esp. wrt intended and applied) Hi Robert, One comment, it seems that the asynchronous configuration operation should have one more sentence at its end saying that an asynchronous notification must be used to report any errors produced from when applying the configuration. What do you think? Kent // as a contributor On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@c= isco.com> wrote: Hi All, Are there any more comments on the following proposed descriptions, or are these descriptions sufficiently clear to update the requirements draft and resolve issue #6? Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request. The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed. The server's applied configuration state (see term) is updated after the configuration change has been fully effected to all impacted components in the server. The reply to the client only indicates whether there are any errors in the original request. Synchronous configuration server - a configuration server that processes all configuration operations as synchronous configuration operations. Asynchronous configuration server - a configuration server that processes all configuration operations as asynchronous configuration operations. Thanks, Rob On 13/10/2015 09:48, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: Hi Juergen, On 06/10/2015 17:16, Juergen Schoenwaelder wrote: On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: Hi Kent, Feeding in the various input, I think that this is the best refinement that I've come up with: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server SHOULD ensure that the request is valid, and MUST fully effect the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. What does "SHOULD ensure that the request is valid" mean? RFC 6020 says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. Are we talking about datastore validation or validation of a request? If the former, are we watering down a MUST to a SHOULD? Really it is datastore validation, particularly for an async request where the intended config nodes are updated before replying. I'm not intentionally trying to water down a MUST to a SHOULD, but Kent had concerns that my previous description using "semantically validate" would exclude an ephemeral datastore, so I was trying to water down the description and also describe the behaviour in a way that isn't specific to either RESTCONF/NETCONF or datastores. Perhaps, the start of sentence could simply be changed to: The server MUST fully effect the configuration change to all impacted components in the server ... And equivalently for the asynchronous case below: The server MUST update the server's intended configuration ... Works for me. Sometimes less is more. And I would not be surprised if we also need this sooner or later: Mixed configuration server - a configuration server that processes some configuration operations as synchronous configuration operations and some configuration operations as asynchronous configuration operations. Yes, I would expect that clients may want to define the expected behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. Any further comments? Based on the feedback from Andy and others, it seems that the prevailing view is that existing NETCONF and RESTCONF should be regarded as being asynchronous in their behaviour in that the config nodes in the running datastore only represent the intended configuration and not the applied configuration. Depends on the definition of applied configuration - where is the latest version of it? The last proposed text for intended/applied is as below: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the system. applied configuration - this data represents the configuration state that the network element is actually in, i.e., the configuration state which is currently being being used by system components (e.g., control plane daemons, operating system kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. From Thursday's interim meeting, Rob Shakir clarified that the desired intention is that applied configuration should mean that the configuration is fully applied everywhere. I don't know if that means that the definition of applied configuration should be strengthened, or if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_58A7E15C2DCD42458E6426F9C5F45F59junipernet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Kent,

I don't see the need for defining synchronou= s/asynchronous config servers.

The new definitions look good. Later in the = discussion there was a common sentiment that the requirement for synchronou= s operations contained some crisp wording we could use here too.
I particularly liked the mentioning of block= ing requests for some time,

Nevertheless the proposed wording works for = me.

Gert

Sent from my Apple ][

On 15 Oct 2015, at 19:03, Kent Watsen <kwatsen@juniper.net> wrote:

These terms were edited on today's call, resulting in the following te= xt:

    Synchronous configurat= ion operation - A configuration request to update
    the running configurat= ion of a server that is applied synchronously with
    respect to the client = request.  The server MUST fully attempt to apply 
    the configuration chan= ge to all impacted components in the server,
    updating both the serv= er's intended and applied configuration (see terms),
    before replying to the= client.  This may be transactional or non-
    transactional (need te= rms!).  The transactionality of the operation
    may be a server proper= ty or specified on as a property.
    The reply to the clien= t indicates whether there
    are any errors in the = request or errors from applying the configuration
    change.
    
    Asynchronous configura= tion operation - A configuration request to update
    the running configurat= ion of a server that is applied asynchronously
    with respect to the cl= ient request.  The server MUST update its intended
    configuration (see ter= m) before replying to the client indicating
    whether the request wi= ll be processed.  This reply to the client only
    indicates whether ther= e are any errors in the  original request.  The
    server's applied confi= guration state (see term) is updated after the
    configuration change h= as been fully effected to all impacted components
    in the server.  O= nce applied, there MUST be a mechanism for the client to
    determine when the req= uest has completed processing and whether the
    intended config is now= fully effective or there are any errors from
    applying the configura= tion change, which could be from an asynchronous
    notification or via a = client operation.

    Synchronous configurat= ion server - a configuration server that processes
    all configuration oper= ations as synchronous configuration operations.
    
    Asynchronous configura= tion server - a configuration server that processes
    all configuration oper= ations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing befor= e committing it to the draft.  Anybody want to take a crack at it?

BTW, do we still need to define the last two terms anymore?  - they're= not used elsewhere in the draft...

Kent



From: Gert Grammel <ggrammel@juniper.net>
Date: Thursday, October 15, 2015 at= 10:35 AM
To: Robert Wilton <rwilton@cisco.com>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Rob,

From a client perspective a server has three states: 
  1. intended !=3D applied
  2. Funny-state
  3. Intended =3D=3D appli= ed
Irrespective of synchronous or asynchronous processing in the server, = the third state MUST be reported to the client. Else (from a client perspec= tive) the server stays in funny-state forever.


Gert


From: Robert Wilton <rwilton@cisco.com>
Date: Thursday 15 October 2015 15:5= 9
To: Gert Grammel <ggrammel@juniper.net>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous = request could be completed, but not necessarily the only way.  E.g. if= the information as to whether a particular intended leave had been success= fully applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST t= o COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is no= w fully effective or there are any errors from applying the configuration c= hange.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is n= ow fully effective or there are any errors from applying the configuration = change.

Or:

Once applied, there MUST be a mechanism available for the client to be able= to determine whether the intended config is now fully effective or whether= there are any errors from applying the configuration change.

Thanks,
Rob


On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn=92t= look complete. The way it stands for the synchronous operation, the client= knows that it's intended config was good AND it has been effected to the s= erver. In the Asynchronous case, the client only knows that the intended config was good =96 and that=92s not e= nough.

So the proposal is to refine the asynchronous case definition as follo= ws:

Asynchronous configuration operation - A configuration request to upda= te the running configuration of a server that is applied asynchronously wit= h respect to the client request.  The server MUST update its inte= nded configuration (see term) before replying to the client indicating whether the request will be processed.  The = reply to the client only indicates whether there are any errors in the &nbs= p;original request.
The server's applied configuration state (see term) is updated after t= he configuration change has been applied to all impacted components in the = server.  Once applied, the client MUST be notified whether the intende= d config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a clie= nt can request from the server to obtain above information on an on-demand = basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@iet= f.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Thursday 15 October 2015 00:1= 1
To: Robert Wilton <rwilton@cisco.com>= , "netmod@= ietf.org" <netmod@iet= f.org>
Subject: Re: [netmod] opstate-reqs = #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap= plied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation sh= ould
have one more sentence at its end saying that an asynchronous notifica= tion
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wro= te:

Hi All,

Are there any more comments on the following proposed descriptions, or=
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to updat= e
the running configuration of a server that is applied synchronously wi= th
respect to the client request.  The server MUST fully effect= the
configuration change to all impacted components in the server, updatin= g
both the server's intended and applied configuration (see terms), befo= re
replying to the client.  The reply to the client indicates w= hether there
are any errors in the request or errors from applying the configuratio= n
change.

Asynchronous configuration operation - A configuration request to upda= te
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update = its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied=
configuration state (see term) is updated after the configuration chan= ge
has been fully effected to all impacted components in the server. = ; The
reply to the client only indicates whether there are any errors in the=
original request.

Synchronous configuration server - a configuration server that process= es
all configuration operations as synchronous configuration operations.<= /div>

Asynchronous configuration server - a configuration server that proces= ses
all configuration operations as asynchronous configuration operations.=

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure tha= t the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.<= /div>
The reply to the client indicates whether there are any errors in the<= /div>
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RF= C 6020
says:

     When datastore processing is complete, the fi= nal contents MUST
obey
     all validation constraints.  This v= alidation processing is
performed
     at differing times according to the datastore= .  If the datastore
is
     <running/> or <startup/>, these c= onstraints MUST be enforced at
the
     end of the <edit-config> or <copy-co= nfig> operation.  If the
     datastore is <candidate/>, the constrai= nt enforcement is delayed
     until a <commit> or <validate> op= eration.

Are we talking about datastore validation or validation of a request?<= /div>
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validat= e"
would exclude an ephemeral datastore, so I was trying to water down th= e
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration s= erver that processes
    some configuration operations as synchronous c= onfiguration
    operations and some configuration operations a= s asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy=
that in real systems, depending on the data model, certain parts of a<= /div>
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration= - this data represents the configuration
        state that the network= operator intends the system to be in, and
that
        has been accepted by t= he system as valid configuration.  This
data is
        colloquially referred = to as the 'configuration' of the system.

       applied configuration - this data= represents the configuration
        state that the network= element is actually in, i.e., the
        configuration state wh= ich is currently being being used by
system
        components (e.g., cont= rol plane daemons, operating system
        kernels, line cards).<= /div>
Well, sometimes the config goes to a control plane daemon and then to<= /div>
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that= the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if = that means
that the definition of applied configuration should be strengthened, o= r
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from<= /div>
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to<= /div>
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended=
config and then report the result of the guess work as applied config<= /div>
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price=
for this applied config idea, I have no real problem with this since I=
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list


--_000_58A7E15C2DCD42458E6426F9C5F45F59junipernet_-- From nobody Thu Oct 15 19:19:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EC81B2C69 for ; Thu, 15 Oct 2015 19:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2COhh3S_5VUX for ; Thu, 15 Oct 2015 19:19:17 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 EEC051B2C29 for ; Thu, 15 Oct 2015 19:19:16 -0700 (PDT) Received: by lbwr8 with SMTP id r8so88558998lbw.2 for ; Thu, 15 Oct 2015 19:19:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vTcBCWrXYcF2uKoCiiP6xTx7hYqsYDxxYaNqzszYgAk=; b=c7lSIZIDuJbgRdIuN892KePj0fv5+zYH5heWDTmDduRXRHxaS1VqU9jN5s3BmNsJ6t HmE5d3gbQNYrftULrHfj5l8YXtllRhxdxdI5WVjt1JuUGwNWRSxkcMIwx9zyyfH0ogPz um4RsrXCYIn6+1WmuZ/2LmYFU2Om3cxAvBS9ybilTXU1J1qj9sncaypIiqe1JWhIaxbe wxqXP5b1fXVI0AkepwkZ6IXu5hyKPp+fUfn5qTSG7C+i1QEgDXKwqNywRnnHesveuIvH 2rAxjlSbso/sB1h1Cui8X3f11vn4af5wCTOxaUOtYgQLga7iQPZeCiggjciZoTyTVtAV QOSA== X-Gm-Message-State: ALoCoQkAsjLhnPBxxXhNpdtw1u9qqenl6KeLQBYYUMIxlArvK+IAZZ9Er603thsuXxfmP3l5IHfF MIME-Version: 1.0 X-Received: by 10.112.181.71 with SMTP id du7mr6463971lbc.37.1444961954907; Thu, 15 Oct 2015 19:19:14 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 15 Oct 2015 19:19:14 -0700 (PDT) In-Reply-To: <20151015223441.GD72419@elstar.local> References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> <20151015223441.GD72419@elstar.local> Date: Thu, 15 Oct 2015 19:19:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3715c09565905222f6c78 Archived-At: Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 02:19:20 -0000 --001a11c3715c09565905222f6c78 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > Conformance to YANG for the extension: NONE This includes syntax and > > semantics. It makes no sense at all (Lada is right) to say the > > extension semantics apply. They only apply if the tool supports the > > extension. Conformance to the extension is a different matter. > > I would hope that a server supporting NACM implements the behaviour of > nacm:default-deny-write when nodes are tagged with this extension. > Sure, a YANG parser is allowed to skip over nacm:default-deny-write > but if nacm:default-deny-write is used for a certain node, I think we > want the server to implement the semantics implied by > nacm:default-deny-write regardless which tool the developer used. > > I do not agree. The semantics for this YANG extension only apply to NACM. Of course an implementation of NACM cannot ignore this extension. The extensions says what to do in NACM if the tag is found. (As it should). It does not define any behavior outside of NACM. No other tool except a NETCONF server implementation of NACM has any conformance requirement to implement this extension. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c3715c09565905222f6c78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierm= an wrote:
>
> Conformance to YANG for the extension: NONE This includes syntax and > semantics.=C2=A0 It makes no sense at all (Lada is right) to say the > extension semantics apply.=C2=A0 They only apply if the tool supports = the
> extension.=C2=A0 Conformance to the extension is a different matter.
I would hope that a server supporting NACM implements the behaviour of
nacm:default-deny-write when nodes are tagged with this extension.
Sure, a YANG parser is allowed to skip over nacm:default-deny-write
but if nacm:default-deny-write is used for a certain node, I think we
want the server to implement the semantics implied by
nacm:default-deny-write regardless which tool the developer used.


I do not agree.
The semantics for this YAN= G extension only apply to NACM.
Of course an implementation of NA= CM cannot ignore this extension.

The extensions sa= ys what to do in NACM if the tag is found.
(As it should).=C2=A0 = It does not define any behavior outside of NACM.
No other tool ex= cept a NETCONF server implementation
of NACM has any conformance = requirement to implement this extension.


/js


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

--001a11c3715c09565905222f6c78-- From nobody Thu Oct 15 23:14:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7E1B2F3A for ; Thu, 15 Oct 2015 23:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aobxs-bAJBrI for ; Thu, 15 Oct 2015 23:14:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98D5D1B2F35 for ; Thu, 15 Oct 2015 23:14:34 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 547521AE0478; Fri, 16 Oct 2015 08:14:33 +0200 (CEST) Date: Fri, 16 Oct 2015 08:14:32 +0200 (CEST) Message-Id: <20151016.081432.1725745005720477684.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20151015223441.GD72419@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 06:14:36 -0000 Andy Bierman wrote: > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > > > Conformance to YANG for the extension: NONE This includes syntax and > > > semantics. It makes no sense at all (Lada is right) to say the > > > extension semantics apply. They only apply if the tool supports the > > > extension. Conformance to the extension is a different matter. > > > > I would hope that a server supporting NACM implements the behaviour of > > nacm:default-deny-write when nodes are tagged with this extension. > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write > > but if nacm:default-deny-write is used for a certain node, I think we > > want the server to implement the semantics implied by > > nacm:default-deny-write regardless which tool the developer used. > > > > > I do not agree. > The semantics for this YANG extension only apply to NACM. > Of course an implementation of NACM cannot ignore this extension. +1 So the question is if we need to add/change any text in 6020bis? /martin > > The extensions says what to do in NACM if the tag is found. > (As it should). It does not define any behavior outside of NACM. > No other tool except a NETCONF server implementation > of NACM has any conformance requirement to implement this extension. > > > /js > > > > > Andy > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > From nobody Fri Oct 16 00:25:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12F61B2FE7 for ; Fri, 16 Oct 2015 00:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzu8GEe3CKXN for ; Fri, 16 Oct 2015 00:25:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 039EA1B2FE6 for ; Fri, 16 Oct 2015 00:25:03 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 819D21AE0478; Fri, 16 Oct 2015 09:25:01 +0200 (CEST) Date: Fri, 16 Oct 2015 09:25:00 +0200 (CEST) Message-Id: <20151016.092500.2180450444093341590.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151015225846.GE72419@elstar.local> References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> <20151015225846.GE72419@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 07:25:04 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 15, 2015 at 10:37:49PM +0200, Martin Bjorklund wrote: > > > * p67 > > > > > > Similar to the comment for p63. Perhaps the right way is to phrase > > > this in such a way that is simply says leaf nodes containing a > > > default value may not be present in the XML encoding. Simply remove > > > NETCONF or specifics. > > > > Or maybe we should simply remove the last paragraph completely? For > > NETCONF, RFC 6243 details how leafs with defaults are handled. > > Well, yes, but then readers may not know about RFC 6243. Perhaps state > that leaf nodes containing a default value may not be present in the > XML encoding and point to RFC 6243 for further details how NETCONF > handles leafs with defaults (and I think the reference to RFC 6243 > would be informative). In some sense I think it is weird to talk about default values here. This text describes how leafs and their values are encoded. The default value is defined as the value being used if the leaf doesn't exist in the data tree, so why should we mention defaults here? > > > * p100 > > > > > > The XML encoding text starts with detailing NETCONF specifics. > > > Would it make sense to separate the XML encoding of the rpc and its > > > input/output from the specifics how the RPCs fit into NETCONF's > > > system? > > > > > > Hmm. NETCONF and RESTCONF use quite different encodings of rpcs and > > their output. > > > > NETCONF: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > 27606-0100 > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > RESTCONF: > > > > POST to .../rock-the-house > > > > > > 27606-0100 > > > > > > result: 204 no content > > > > > > Maybe it would have been better to have a common encoding, like: > > > > > > ... > > > > > > and > > > > > > ... > > > > > > but this cannot be done now. > > > > So, maybe the simplest solution would be to rename the section to > > "NETCONF XML Encoding"? > > You mean section 7.14.4? Well, OK... Yes. > Too bad these RPC encodings are > actually different. Out of curiosity, was there a specific reason not > to use > > > 27606-0100 > > > in the RESTCONF POST or did this "just happen"? The reason is that we can't do output in the same way as NETCONF, and the current RESTCONF encoding of input is consistent with how we do output. But it is not too late to change this. This should be discussed in netconf though. > > > * p105 > > > > > > Again, the proposal is to separate the XML encoding of notifications > > > from the details how notifications work with RFC 5277. > > > > Also notifications are encoded differently in RESTCONF and NETCONF. > > Hm. > > > > * p120 > > > > > > The text in section 7.21.1 talks about NETCONF specific operations. > > > Is this actually necessary? Can the purpose of the config statement > > > not be described by referring to general concepts such as > > > configuration datastores instead of using protocol specific > > > operations? > > > > Yes, maybe we can just say: > > > > Data nodes representing configuration are part of configuration > > datastores. > > Yes. > > > > * p123 > > > > > > "All leaf data values MUST match the type constraints..." may be > > > read as 'all data nodes that contain values' or 'all instantiations > > > of nodes defined by the leaf statement'. > > > > I don't really see what you mean. Can you suggest new text? > > See above, I think 'leaf' sometimes means an instance of a leaf schema > node and sometimes it means all leaf instances of the data tree. Or I > am confused. I think here you mean 'all leaf instances of the data > tree' and not the subset of all 'instances of a leaf schema nodes'. Right; this is what the current text says: The following properties are true in all data trees: o All leaf data values MUST match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties. Note the sentence before the bullet where it says that this is for the data tree. /martin From nobody Fri Oct 16 00:25:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1DC1B2FEC for ; Fri, 16 Oct 2015 00:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuX6oCy7tLdk for ; Fri, 16 Oct 2015 00:25:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C7B1B2FE5 for ; Fri, 16 Oct 2015 00:25:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D70593B; Fri, 16 Oct 2015 09:25:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0QqRWgV7_Yz8; Fri, 16 Oct 2015 09:25:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Oct 2015 09:25:47 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D3182008C; Fri, 16 Oct 2015 09:25:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g689wDG22dNM; Fri, 16 Oct 2015 09:25:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90E3D2008D; Fri, 16 Oct 2015 09:25:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D38337B587F; Fri, 16 Oct 2015 09:25:44 +0200 (CEST) Date: Fri, 16 Oct 2015 09:25:43 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151016072543.GA73630@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <201510092109.t99L9URf067463@mainfs.snmp.com> <20151013101935.GA66308@elstar.local> <46764A65-6C26-47D8-A933-6BCA1974DA2A@nic.cz> <20151013104246.GC66442@elstar.local> <20151015223441.GD72419@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 07:25:55 -0000 On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote: > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > > > Conformance to YANG for the extension: NONE This includes syntax and > > > semantics. It makes no sense at all (Lada is right) to say the > > > extension semantics apply. They only apply if the tool supports the > > > extension. Conformance to the extension is a different matter. > > > > I would hope that a server supporting NACM implements the behaviour of > > nacm:default-deny-write when nodes are tagged with this extension. > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write > > but if nacm:default-deny-write is used for a certain node, I think we > > want the server to implement the semantics implied by > > nacm:default-deny-write regardless which tool the developer used. > > > > > I do not agree. > The semantics for this YANG extension only apply to NACM. > Of course an implementation of NACM cannot ignore this extension. > > The extensions says what to do in NACM if the tag is found. > (As it should). It does not define any behavior outside of NACM. > No other tool except a NETCONF server implementation > of NACM has any conformance requirement to implement this extension. I am confused, perhaps we talk past each other. If a server implements NACM and some data model X contains leaf foo { type string; nacm:default-deny-write; } does this not mean that the nacm:default-deny-write semantics must be implemented for the foo leaf regardless whether the developer's tool is able to parse nacm:default-deny-write or skips over it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 16 00:43:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3CE1B3026 for ; Fri, 16 Oct 2015 00:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt-9JIDe8yzD for ; Fri, 16 Oct 2015 00:43:04 -0700 (PDT) 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 32B191B3023 for ; Fri, 16 Oct 2015 00:43:04 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502] (unknown [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502]) by mail.nic.cz (Postfix) with ESMTPSA id A847118189D; Fri, 16 Oct 2015 09:43:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444981382; bh=x2NXiMMhvTW66QRjtJvepR4phKBU0gJKB5wuQMlYDnk=; h=From:Date:To; b=egZOofJYy0Z13skth24FAxRN/ihc4l7YofkRW9+YG+utPJAWTJvdV+5x7hOQUs6z4 xknqV63Ve/v3dBzaBcOcCnQO/KeqW2B1wBnjf1BGFuQ+fGY5Me5SboJuy69w01riWr R+PS4xhDiCRb/oYTFa+Obb3ZxwvlYup4+HINQ424= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151015.180357.1644539809319777532.mbj@tail-f.com> Date: Fri, 16 Oct 2015 09:43:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <463F6278-0D92-4E88-846A-1A11315FA52D@nic.cz> References: <20151015.135334.2134677503217017095.mbj@tail-f.com> <20151015.180357.1644539809319777532.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 07:43:06 -0000 > On 15 Oct 2015, at 18:03, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund = wrote: >>=20 >>> Andy Bierman wrote: >>>> Hi, >>>>=20 >>>> You are incorrect. >>>>=20 >>>> Within the PAYLOAD (as this section describes), there is no = when-stmt >>>> for data nodes within the datastore. Look at the YANG for = edit-config. >>>> There are no when-stmts for "interface" in "edit-config". >>>=20 >>> Andy, there is some confusion here. The section talks about: >>>=20 >>> For configuration data, there are three windows when constraints >>> MUST be enforced: >>>=20 >>> - during parsing of RPC payloads >>> - during processing of NETCONF operations >>> - during validation >>>=20 >>> So the entire section talks about constraints *on configuration = data*. >>>=20 >>>=20 >>=20 >> = http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.= 421 >>=20 >>=20 >> Here is the YANG for edit-config? >> Please point out the when-stmts in this rpc-stmt >> specific to the "interface" node. >> I just see an "anyxml" that has no when-stmts at all. >>=20 >> So enforcing the when constraint on the RPC PAYLOAD >> clearly has nothing to do with "interface" -- just the parameters >> specified in the rpc-stmt. >=20 > Ok, you're right. 8.2.1 should be kept as it is. (we may need to > rephrase the intro text in 8.2) But I think Balazs is also right. > Suppose you have: >=20 > leaf a { > when "../b =3D 42"; > type int32; > } > leaf b { > type int32; > } >=20 > and the db contains b=3D10. >=20 > Suppose I send an edit-config with a=3D2. What is the result? >=20 > 1) you get an error back > 2) you get ok; the request to set a to 2 is silently dropped > 3) something else IMO YANG spec shouldn't deal with this kind of things in the first = place. It should be sufficient to define two validation levels, e.g. = syntactic (schema) and semantic validity. Stating what a protocol does = if either of these validity types is violated would then be up to the = protocol spec, and different protocols may use different approaches. That said, I like #1 best. Lada >=20 >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 01:43:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE5D1B30C7 for ; Fri, 16 Oct 2015 01:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gh7fG1fs0Q5 for ; Fri, 16 Oct 2015 01:43:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA6CD1B30BC for ; Fri, 16 Oct 2015 01:43:26 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 43FF61CC0156; Fri, 16 Oct 2015 10:43:29 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20151016.081432.1725745005720477684.mbj@tail-f.com> References: <20151015223441.GD72419@elstar.local> <20151016.081432.1725745005720477684.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 16 Oct 2015 10:43:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 08:43:29 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >> > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: >> > > >> > > Conformance to YANG for the extension: NONE This includes syntax and >> > > semantics. It makes no sense at all (Lada is right) to say the >> > > extension semantics apply. They only apply if the tool supports the >> > > extension. Conformance to the extension is a different matter. >> > >> > I would hope that a server supporting NACM implements the behaviour of >> > nacm:default-deny-write when nodes are tagged with this extension. >> > Sure, a YANG parser is allowed to skip over nacm:default-deny-write >> > but if nacm:default-deny-write is used for a certain node, I think we >> > want the server to implement the semantics implied by >> > nacm:default-deny-write regardless which tool the developer used. >> > >> > >> I do not agree. >> The semantics for this YANG extension only apply to NACM. >> Of course an implementation of NACM cannot ignore this extension. > > +1 > > So the question is if we need to add/change any text in 6020bis? IMO, two things: 1. Clarify the text about parser/compiler behaviour - or remove it. 2. State that conformance with respect to extensions is outside the scope of YANG spec. As for #1, I think parser behaviour is totally irrelevant - a parser is supposed to do what the application or protocol implementation expects it to do. One could use a parser that ignores everything except module names, and it can be perfectly OK for a given application. What we could say is that extensions MUST NOT affect the validity of datastores, RPC messages and notifications, i.e., when validating an instance document against a YANG data model, all extensions are ignored. This is essentially the approach of RELAX NG towards foreign-namespace annotations. But then the "annotation" extension would most likely be illegal. Lada > > > /martin > >> >> The extensions says what to do in NACM if the tag is found. >> (As it should). It does not define any behavior outside of NACM. >> No other tool except a NETCONF server implementation >> of NACM has any conformance requirement to implement this extension. >> >> >> /js >> > >> >> >> Andy >> >> >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 02:19:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711F61B346D for ; Fri, 16 Oct 2015 02:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F87BgtsvCvEO for ; Fri, 16 Oct 2015 02:19:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D614A1B344F for ; Fri, 16 Oct 2015 02:19:02 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EFCA1AE0478; Fri, 16 Oct 2015 11:19:01 +0200 (CEST) Date: Fri, 16 Oct 2015 11:19:00 +0200 (CEST) Message-Id: <20151016.111900.807553366696169175.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151016072543.GA73630@elstar.local> References: <20151015223441.GD72419@elstar.local> <20151016072543.GA73630@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6020bis extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 09:19:04 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote: > > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > > > > > Conformance to YANG for the extension: NONE This includes syntax and > > > > semantics. It makes no sense at all (Lada is right) to say the > > > > extension semantics apply. They only apply if the tool supports the > > > > extension. Conformance to the extension is a different matter. > > > > > > I would hope that a server supporting NACM implements the behaviour of > > > nacm:default-deny-write when nodes are tagged with this extension. > > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write > > > but if nacm:default-deny-write is used for a certain node, I think we > > > want the server to implement the semantics implied by > > > nacm:default-deny-write regardless which tool the developer used. > > > > > > > > I do not agree. > > The semantics for this YANG extension only apply to NACM. > > Of course an implementation of NACM cannot ignore this extension. > > > > The extensions says what to do in NACM if the tag is found. > > (As it should). It does not define any behavior outside of NACM. > > No other tool except a NETCONF server implementation > > of NACM has any conformance requirement to implement this extension. > > I am confused, perhaps we talk past each other. If a server implements > NACM and some data model X contains > > leaf foo { > type string; > nacm:default-deny-write; > } > > does this not mean that the nacm:default-deny-write semantics must be > implemented for the foo leaf regardless whether the developer's tool > is able to parse nacm:default-deny-write or skips over it? Sure. Andy wrote: Of course an implementation of NACM cannot ignore this extension. /martin From nobody Fri Oct 16 02:19:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6767C1B3479 for ; Fri, 16 Oct 2015 02:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QrmKLURAlV3 for ; Fri, 16 Oct 2015 02:19:33 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 203A01B346F for ; Fri, 16 Oct 2015 02:19:33 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DCB871CC0156; Fri, 16 Oct 2015 11:19:36 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20151015.223749.1017340653632922486.mbj@tail-f.com> References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 16 Oct 2015 11:19:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 09:19:36 -0000 Martin Bjorklund writes: ... > >> I am also wondering why we use device and server. It seems we use >> these terms interchangeably. If so, for clarity, I would suggest to >> use a single term, that is s/device/server > > Ok, fixed. > >> / and perhaps explicitly >> state that unless stated otherwise server means a server providing >> access to a YANG defined data tree. > > Yes this makes sense. But then I guess we shouldn't import client and > server from 6241. (And most other documents (restconf etc) should > probably import these terms from ths document). See also below. > >> * p12/p13 >> >> We import 7 terms from RFC 6241. Would it make sense to copy the >> necessary text in order to avoid a too strict binding to RFC 6241? >> In particular, 'client' and 'server' means NETCONF client and server >> if we import from RFC 6241 but this may be a bit narrow given that >> we have RESTCONF as well. In an ideal world, we would factor out >> core architectural concepts but the best we can do is likely to >> define core concepts inline, pointing out where they are the same. >> The idea is to loosen the coupling to RFC 6241. Example: >> >> OLD >> >> o datastore: an instantiated data tree >> >> NEW >> >> o datastore: A conceptual place to store and access information. >> A datastore might be implemented, for example, using files, a >> database, flash memory locations, or combinations thereof. >> [Matches the definition in RFC 6241.] > > To start with, I think we should define client and server more > generically than just NETCONF: > > server: An entity that provides access to YANG-defined data to a > client, over some network management protocol. But then perhaps "device" is a broader term in the sense that the server is just a software component running in a device. For example, it is the device that is required to operationally use default values of parameters that are not present in the configuration. Replacing "device" with "server" here IMO means something different. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 03:38:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313D61A879A for ; Fri, 16 Oct 2015 03:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKfn2endWEsU for ; Fri, 16 Oct 2015 03:38:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2A01A7113 for ; Fri, 16 Oct 2015 03:38:44 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-5e-5620d3b23f41 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 39.A6.27359.2B3D0265; Fri, 16 Oct 2015 12:38:42 +0200 (CEST) Received: from [159.107.197.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Fri, 16 Oct 2015 12:38:42 +0200 To: Andy Bierman References: <561F5D28.5020304@ericsson.com> <20151015.135334.2134677503217017095.mbj@tail-f.com> <561FC736.6030903@ericsson.com> From: Balazs Lengyel Message-ID: <5620D3B1.6040805@ericsson.com> Date: Fri, 16 Oct 2015 12:38:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvje6mywphBq2N+hYPjsxit+jufsZu Mf9iI6sDs8eSJT+ZPDb+Wszi0dJ/kSWAOYrLJiU1J7MstUjfLoEr49Xr26wFN24wVtx72c/c wPi8sIuRk0NCwETiy83nrBC2mMSFe+vZuhi5OIQEjjJKfLxwkx3CWcsocbx7MxtIlbCAscSx 9a0sILaIgKrEhbkTmSGKFjBL7JswgREkwSzgJXFi2g6wsWwCRhJT+8+DNfAKaEssmPqAHcRm AWr+vekHE4gtKhAj8X7TKkaIGkGJkzOfANVzcHAKBALVBEGM1JBonTOXHcKWl2jeOpsZxBYC ij+88Jd1AqPgLCTds5C0zELSsoCReRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYBgf3PLb YAfjy+eOhxgFOBiVeHgVohTChFgTy4orcw8xSnOwKInzNjM9CBUSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAyPai6HR53rK5m1qXbrn83T8xOVw+4aiJ+R7naTHByj5dnoE79M9F/G5rMSyL CfjFzvWXo1cwbusMF3u+wrCCY33z2f9W/Y53LPyhLXVt9XLL2xcyjvod/1AXE/U58nv4t5PH Tkkv6VAoEVri/OSdy8e4ff9t7z76xOIlJbuyaUZcw6JVc3c1K7EUZyQaajEXFScCACPQ5NtE AgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 10:38:48 -0000 Hello Andy, Martin,
If that is what is meant by 8.2.1 then I have a few comments
- Clarify that this is for RPCs defined by the Yang RPC statement and not for all RPCs. After all edit-config is also carried in an RPC.
- Add actions as they should be validated the same way.
- I don't understand the last 2 bullets in 8.2.1:
"If the attributes "before" and "after" appears in any element"
What would before and after mean in a YANG defined RPC or ACTION. I thought they are used defined only for edit-config. Remove last bullet.
- There are other constraint not mentioned here (min/max-elements, must). Some are mentioned in the section some are not. Confusing.

Also this does not cover the questions about how to evaluate when.
regards Balazs

On 2015-10-15 23:05, Andy Bierman wrote:
Hi,

Show me the text that says an anyxml passes the constraints of
the hidden data models through to the RPC processing.
The error for false-when only applies to parameters specified
in the RPC.

The processing of the rpc-stmt does not have any when-stmts that
need to be checked.

The config data is validated as part of a datastore, not as part
of the RPC payload.


Andy



On Thu, Oct 15, 2015 at 8:33 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
I had the same interpretation as Martin. The when could be on the config database model. Not just on the when defined in a definition of an rpc or action.
regards Balazs

On 2015-10-15 17:02, Andy Bierman wrote:


On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> You are incorrect.
>
> Within the PAYLOAD (as this section describes), there is no when-stmt
> for data nodes within the datastore.  Look at the YANG for edit-config.
> There are no when-stmts for "interface" in "edit-config".

Andy, there is some confusion here.  The section talks about:

  For configuration data, there are three windows when constraints
  MUST be enforced:

  - during parsing of RPC payloads
  - during processing of NETCONF operations
  - during validation

So the entire section talks about constraints *on configuration data*.





Here is the YANG for edit-config?
Please point out the when-stmts in this rpc-stmt
specific to the "interface" node.
I just see an "anyxml" that has no when-stmts at all.

So enforcing the when constraint on the RPC PAYLOAD
clearly has nothing to do with "interface" -- just the parameters
specified in the rpc-stmt.


 
If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.   For example:

  If all keys of a list entry are not present, the server MUST reply
  with a "missing-element" error-tag in the rpc-error.

you might say that there are no lists in the definition of
edit-config, so this bullet doesn't apply.




edit-config is the next section  -- 8.2.2



/martin



Andy
 


>
> So explain which constraint in the payload is being violated?
>
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <balazs.lengyel@ericsson.com
> > wrote:
>
> > See below, Balazs
> >
> > On 2015-10-14 23:06, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < <mbj@tail-f.com>
> > mbj@tail-f.com> wrote:
> >
> >> Andy Bierman <andy@yumaworks.com> wrote:
> >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com>
> >> wrote:
> >> >
> >> > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <mbj@tail-f.com>
> >> > > wrote:
> >> > > >
> >> > > > > Balazs Lengyel < <balazs.lengyel@ericsson.com>
> >> balazs.lengyel@ericsson.com> wrote:
> >> > > > > > Hello Martin,
> >> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> >> IMHO you
> >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> >> > > error.
> >> > > > >
> >> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
> >> > > > >
> >> > > > >    o  If data for a node tagged with "when" is present, and the
> >> "when"
> >> > > > >       condition evaluates to "false", the server MUST reply with
> >> an
> >> > > > >       "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > > and add to 8.2.2:
> >> > > > >
> >> > > > >   o  Modification requests for nodes tagged with "when", and the
> >> "when"
> >> > > > >      condition evaluates to "false".  In this case the server MUST
> >> > > reply
> >> > > > >      with an "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > This seems like a BIG protocol change to <edit-config> behavior.
> >> > > > IMO this not an error at all.  In our server the false-when data is
> >> just
> >> > > > pruned, and no error is ever sent for a pruned when=false data node.
> >> > >
> >> > > So you are not following the current RFC 6020 spec?
> >> > >
> >> >
> >> >
> >> > Yes we are following it.
> >>
> >> Ok.
> >>
> >> > The schema for the edit-config RPC operation contains
> >> > an 'anyxml' for <config> node.  It does not contain any
> >> > when-stmts for the data nodes that get passed in the <config> node.
> >> > The correct behavior is to just enforce the error on the when-stmts
> >> > that appear in the rpc-stmt.
> >>
> >> I don't understand what you are trying to say.
> >>
> >
> >
> > I know about the text that says a false-when in an RPC is an error.
> > Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.
> >
> >
> >
> >
> >>
> >> Here's an example:
> >>
> >>   augment /if:interfaces/if:interface {
> >>     when "if:type = 'ianaift:ethernetCsmacd'";
> >>
> >>     container ethernet {
> >>       leaf duplex {
> >>         type enumeration {
> >>           enum "half";
> >>           enum "full";
> >>         }
> >>       }
> >>     }
> >>   }
> >>
> >> Suppose the db is empty.
> >>
> >> What if the edit-confif contains
> >>
> >>   <interfaces>
> >>     <interface>
> >>       <name>eth0</name>
> >>       <eth:duplex>full</eth:duplex>
> >>       <type>ianaift:ethernetCsmacd</type>
> >>     </interface>
> >>   </interfaces>
> >>
> >> will that work or not?  I.e., will the eth0 interface be created with
> >> duplex full?
> >>
> >
> > Yes -- because these are data nodes and the rules for when-stmt
> > on data nodes are different than for rpc-stmt.  Then the when-stmt
> > is a test on whether the node should exist in the candidate or running
> > datastore.
> >
> > Our server applies all the edits first, when checks all the when-stmts
> > that might have changed value.  Nodes that have already existed in the
> > datastore may get pruned, not just the new nodes.
> >
> >
> >
> >
> >
> >>
> >> /martin
> >>
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > I don't think this is a BIG protocol change, since the spec already
> >> > > says that requests for nodes w/ false when expressions MUST send
> >> > > error.  The change is to say that this behavior is true regardless of
> >> > > evaluation order.
> >> > >
> >> > > > It may be a client programming error for the client to provide
> >> > > > false when nodes or not.  What if the client is reusing some
> >> > > > code that sends 5 parameters, it it's OK if 1 of them gets
> >> > > > pruned sometimes because of a false when (e.g, product
> >> > > > feature-specific knob and that feature is not installed)
> >> > >
> >> > > Well, it might be simpler to send if-featured nodes that the specific
> >> > > server doesn't support - this is also an error in 6020.
> >> > >
> >> > > > BTW, this is a really good example of what not to do, if one
> >> > > > wants to make the YANG specification protocol independent.
> >> > >
> >> > > That statement is true for the entire section 8.2, it is not
> >> > > specifically true for this change.
> >> > >
> >> > >
> >> > > /martin
> >> > >
> >> >
> >> >
> >> > Andy
> >>
> >
> > And this contradicts the current rfc6020bis-07#section-8.2.1 which states
> > that already during parsing you must check
> >
> > If data for a node tagged with "when" is present, and the "when"
> >       condition evaluates to "false", the server MUST reply with an
> >       "unknown-element" error-tag in the rpc-error.
> >
> >
> > So already during parsing <eth:duplex>full</eth:duplex> you MUST send back an error;
> > before processing <type>ianaift:ethernetCsmacd</type>.
> > (I also assume this is independent from the document order of the edit-config request.)
> > So this MUST be corrected in the draft!
> > regards Balazs
> >
> >
> >
> >
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> >


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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Oct 16 04:05:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023A91A8938 for ; Fri, 16 Oct 2015 04:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TauwVYgJfMPn for ; Fri, 16 Oct 2015 04:05:26 -0700 (PDT) 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 9E1511A8925 for ; Fri, 16 Oct 2015 04:05:25 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502] (unknown [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502]) by mail.nic.cz (Postfix) with ESMTPSA id 26B11181817 for ; Fri, 16 Oct 2015 13:05:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444993524; bh=MrRjqnMMXEs7AY+pLMmnRlAMeMJ1zM7XexUN52wL8xc=; h=From:Date:To; b=dlexOrsZaiCAtlDKxS5p3egQ/udYi9HEDa11/5K3MREuB/xvmG4C78rXij9F8y9kN DsxvTwFhd05lgF122MF5T+BBddmcp2YqfP+JZAXHGhZeWa0SpwC+6EQTMuRaAGqoHm JcwLXHXWtM3d+SZOtuAYD+E7rVc2AJ1ETXiWgqH0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <5620D0FD.8010902@ericsson.com> Date: Fri, 16 Oct 2015 13:05:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151015.135334.2134677503217017095.mbj@tail-f.com> <20151015.180357.1644539809319777532.mbj@tail-f.com> <463F6278-0D92-4E88-846A-1A11315FA52D@nic.cz> <5620D0FD.8010902@ericsson.com> To: NETMOD WG X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:05:28 -0000 > On 16 Oct 2015, at 12:27, Balazs Lengyel = wrote: >=20 > IMHO YANG should define the behavoir, and I would want it to be the = same on Netconf/Restconf/CLI etc. > I agree that " 1) you get an error back" would be the best: because it = is the easiest to understand for the operator, with the fewest corner = cases. > Also we must define if in the same transaction we set b=3D42 and a=3D2. = which of the 3 options are taken? >=20 >=20 > We should not leave such complex cases undefined, or alternatively = state that they are implementation dependant. I might be difficult to say what is a complex case, unless we abandon = XPath in "when" statements and use something else - and considerably = simpler. Here is another interesting corner case - does it qualify as being = complex? leaf-list bar { type uint8; when "count(../*) > 1"; } leaf foo { type uint8; } Assuming no instances exist, is this edit allowed? (This was essentially = your question.) 1 2 But what about this? 1 2 Lada > regards Balazs >=20 > On 2015-10-16 09:43, Ladislav Lhotka wrote: >>> On 15 Oct 2015, at 18:03, Martin Bjorklund >>> wrote: >>>=20 >>> Andy Bierman=20 >>> >>> wrote: >>>=20 >>>> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund >>>> wrote: >>>>=20 >>>>=20 >>>>> Andy Bierman >>>>> wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> You are incorrect. >>>>>>=20 >>>>>> Within the PAYLOAD (as this section describes), there is no = when-stmt >>>>>> for data nodes within the datastore. Look at the YANG for = edit-config. >>>>>> There are no when-stmts for "interface" in "edit-config". >>>>>>=20 >>>>> Andy, there is some confusion here. The section talks about: >>>>>=20 >>>>> For configuration data, there are three windows when constraints >>>>> MUST be enforced: >>>>>=20 >>>>> - during parsing of RPC payloads >>>>> - during processing of NETCONF operations >>>>> - during validation >>>>>=20 >>>>> So the entire section talks about constraints *on configuration = data*. >>>>>=20 >>>>>=20 >>>>>=20 >>>> = http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.= 421 >>>>=20 >>>>=20 >>>>=20 >>>> Here is the YANG for edit-config? >>>> Please point out the when-stmts in this rpc-stmt >>>> specific to the "interface" node. >>>> I just see an "anyxml" that has no when-stmts at all. >>>>=20 >>>> So enforcing the when constraint on the RPC PAYLOAD >>>> clearly has nothing to do with "interface" -- just the parameters >>>> specified in the rpc-stmt. >>>>=20 >>> Ok, you're right. 8.2.1 should be kept as it is. (we may need to >>> rephrase the intro text in 8.2) But I think Balazs is also right. >>> Suppose you have: >>>=20 >>> leaf a { >>> when "../b =3D 42"; >>> type int32; >>> } >>> leaf b { >>> type int32; >>> } >>>=20 >>> and the db contains b=3D10. >>>=20 >>> Suppose I send an edit-config with a=3D2. What is the result? >>>=20 >>> 1) you get an error back >>> 2) you get ok; the request to set a to 2 is silently dropped >>> 3) something else >>>=20 >> IMO YANG spec shouldn't deal with this kind of things in the first = place. It should be sufficient to define two validation levels, e.g. = syntactic (schema) and semantic validity. Stating what a protocol does = if either of these validity types is violated would then be up to the = protocol spec, and different protocols may use different approaches. >>=20 >> That said, I like #1 best. >>=20 >> Lada >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>> _______________________________________________ >>> netmod mailing list >>>=20 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >>=20 >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 =20 > Mobile: +36-70-330-7909 email:=20 > Balazs.Lengyel@ericsson.com >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 04:12:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED901A8AD3 for ; Fri, 16 Oct 2015 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LETXZzIDIVC for ; Fri, 16 Oct 2015 04:12:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5DE31A8AC4 for ; Fri, 16 Oct 2015 04:12:00 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 73BF01AE0478; Fri, 16 Oct 2015 13:11:59 +0200 (CEST) Date: Fri, 16 Oct 2015 13:11:59 +0200 (CEST) Message-Id: <20151016.131159.955773379266802109.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <463F6278-0D92-4E88-846A-1A11315FA52D@nic.cz> <5620D0FD.8010902@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:12:02 -0000 Ladislav Lhotka wrote: > > > On 16 Oct 2015, at 12:27, Balazs Lengyel > > wrote: > > > > IMHO YANG should define the behavoir, and I would want it to be the > > same on Netconf/Restconf/CLI etc. > > I agree that " 1) you get an error back" would be the best: because it > > is the easiest to understand for the operator, with the fewest corner > > cases. > > Also we must define if in the same transaction we set b=42 and > > a=2. which of the 3 options are taken? > > > > > > We should not leave such complex cases undefined, or alternatively > > state that they are implementation dependant. > > I might be difficult to say what is a complex case, unless we abandon > XPath in "when" statements and use something else - and considerably > simpler. > > Here is another interesting corner case - does it qualify as being > complex? > > leaf-list bar { > type uint8; > when "count(../*) > 1"; > } > leaf foo { > type uint8; > } > > Assuming no instances exist, is this edit allowed? (This was > essentially your question.) > > 1 > 2 Yes. > But what about this? > > 1 > 2 No. (Note the new text that specifies that 'bar' is tentatively replaced with a dummy node during when processing) > > Lada > > > regards Balazs > > > > On 2015-10-16 09:43, Ladislav Lhotka wrote: > >>> On 15 Oct 2015, at 18:03, Martin Bjorklund > >>> wrote: > >>> > >>> Andy Bierman > >>> > >>> wrote: > >>> > >>>> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund > >>>> wrote: > >>>> > >>>> > >>>>> Andy Bierman > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You are incorrect. > >>>>>> > >>>>>> Within the PAYLOAD (as this section describes), there is no when-stmt > >>>>>> for data nodes within the datastore. Look at the YANG for > >>>>>> edit-config. > >>>>>> There are no when-stmts for "interface" in "edit-config". > >>>>>> > >>>>> Andy, there is some confusion here. The section talks about: > >>>>> > >>>>> For configuration data, there are three windows when constraints > >>>>> MUST be enforced: > >>>>> > >>>>> - during parsing of RPC payloads > >>>>> - during processing of NETCONF operations > >>>>> - during validation > >>>>> > >>>>> So the entire section talks about constraints *on configuration data*. > >>>>> > >>>>> > >>>>> > >>>> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 > >>>> > >>>> > >>>> > >>>> Here is the YANG for edit-config? > >>>> Please point out the when-stmts in this rpc-stmt > >>>> specific to the "interface" node. > >>>> I just see an "anyxml" that has no when-stmts at all. > >>>> > >>>> So enforcing the when constraint on the RPC PAYLOAD > >>>> clearly has nothing to do with "interface" -- just the parameters > >>>> specified in the rpc-stmt. > >>>> > >>> Ok, you're right. 8.2.1 should be kept as it is. (we may need to > >>> rephrase the intro text in 8.2) But I think Balazs is also right. > >>> Suppose you have: > >>> > >>> leaf a { > >>> when "../b = 42"; > >>> type int32; > >>> } > >>> leaf b { > >>> type int32; > >>> } > >>> > >>> and the db contains b=10. > >>> > >>> Suppose I send an edit-config with a=2. What is the result? > >>> > >>> 1) you get an error back > >>> 2) you get ok; the request to set a to 2 is silently dropped > >>> 3) something else > >>> > >> IMO YANG spec shouldn't deal with this kind of things in the first > >> place. It should be sufficient to define two validation levels, > >> e.g. syntactic (schema) and semantic validity. Stating what a protocol > >> does if either of these validity types is violated would then be up to > >> the protocol spec, and different protocols may use different > >> approaches. > >> > >> That said, I like #1 best. > >> > >> Lada > >> > >> > >>> > >>> > >>> > >>> /martin > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > >> > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > ECN: 831 7320 > > Mobile: +36-70-330-7909 email: > > Balazs.Lengyel@ericsson.com > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Oct 16 04:17:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0580F1A8F4A for ; Fri, 16 Oct 2015 04:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1xdhp59_jC6 for ; Fri, 16 Oct 2015 04:17:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3E1A8BC4 for ; Fri, 16 Oct 2015 04:17:09 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id B9F341AE0478; Fri, 16 Oct 2015 13:17:08 +0200 (CEST) Date: Fri, 16 Oct 2015 13:17:08 +0200 (CEST) Message-Id: <20151016.131708.1683862723851859367.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:17:11 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > ... > > > > >> I am also wondering why we use device and server. It seems we use > >> these terms interchangeably. If so, for clarity, I would suggest to > >> use a single term, that is s/device/server > > > > Ok, fixed. > > > >> / and perhaps explicitly > >> state that unless stated otherwise server means a server providing > >> access to a YANG defined data tree. > > > > Yes this makes sense. But then I guess we shouldn't import client and > > server from 6241. (And most other documents (restconf etc) should > > probably import these terms from ths document). See also below. > > > >> * p12/p13 > >> > >> We import 7 terms from RFC 6241. Would it make sense to copy the > >> necessary text in order to avoid a too strict binding to RFC 6241? > >> In particular, 'client' and 'server' means NETCONF client and server > >> if we import from RFC 6241 but this may be a bit narrow given that > >> we have RESTCONF as well. In an ideal world, we would factor out > >> core architectural concepts but the best we can do is likely to > >> define core concepts inline, pointing out where they are the same. > >> The idea is to loosen the coupling to RFC 6241. Example: > >> > >> OLD > >> > >> o datastore: an instantiated data tree > >> > >> NEW > >> > >> o datastore: A conceptual place to store and access information. > >> A datastore might be implemented, for example, using files, a > >> database, flash memory locations, or combinations thereof. > >> [Matches the definition in RFC 6241.] > > > > To start with, I think we should define client and server more > > generically than just NETCONF: > > > > server: An entity that provides access to YANG-defined data to a > > client, over some network management protocol. > > But then perhaps "device" is a broader term in the sense that the > server is just > a software component running in a device. So how do you define "device"? > For example, it is the device that is required to operationally use > default values of parameters that are not present in the > configuration. Replacing "device" with "server" here IMO means something The text was actually already in RFC 6020: When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value. /martin From nobody Fri Oct 16 04:24:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948401A906F for ; Fri, 16 Oct 2015 04:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGlsl7OU1zN0 for ; Fri, 16 Oct 2015 04:24:02 -0700 (PDT) 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 E7B491A906E for ; Fri, 16 Oct 2015 04:24:01 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502] (unknown [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502]) by mail.nic.cz (Postfix) with ESMTPSA id 855B4181909; Fri, 16 Oct 2015 13:24:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444994640; bh=VdsmW/D0DU64Uo7+Zvair6A+2s9Zx/vartxrShnrw38=; h=From:Date:To; b=YFuJFlElxOZp0AzG9kmx+bgT5B+oE1SpQTG5BavqJWMUhTIKaXWEiC+FnufRGYbbv B1pY+zR3EEo4Rk/yWx72O2z8eWruusi6+NPN11gLFayIGwvjjNrhpWXtaca1wNE4fU YcU4bw7Ju7oPnwofZ6n/8wCnZ+zPDYw0E7RevdQo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151016.131159.955773379266802109.mbj@tail-f.com> Date: Fri, 16 Oct 2015 13:24:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <463F6278-0D92-4E88-846A-1A11315FA52D@nic.cz> <5620D0FD.8010902@ericsson.com> <20151016.131159.955773379266802109.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:24:03 -0000 > On 16 Oct 2015, at 13:11, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 16 Oct 2015, at 12:27, Balazs Lengyel = >>> wrote: >>>=20 >>> IMHO YANG should define the behavoir, and I would want it to be the >>> same on Netconf/Restconf/CLI etc. >>> I agree that " 1) you get an error back" would be the best: because = it >>> is the easiest to understand for the operator, with the fewest = corner >>> cases. >>> Also we must define if in the same transaction we set b=3D42 and >>> a=3D2. which of the 3 options are taken? >>>=20 >>>=20 >>> We should not leave such complex cases undefined, or alternatively >>> state that they are implementation dependant. >>=20 >> I might be difficult to say what is a complex case, unless we abandon >> XPath in "when" statements and use something else - and considerably >> simpler. >>=20 >> Here is another interesting corner case - does it qualify as being >> complex? >>=20 >> leaf-list bar { >> type uint8; >> when "count(../*) > 1"; >> } >> leaf foo { >> type uint8; >> } >>=20 >> Assuming no instances exist, is this edit allowed? (This was >> essentially your question.) >>=20 >> 1 >> 2 >=20 > Yes. >=20 >> But what about this? >>=20 >> 1 >> 2 >=20 > No. >=20 > (Note the new text that specifies that 'bar' is tentatively replaced > with a dummy node during when processing) Yes, I know, but it is *extremely* weird. I can guarantee you that XPath = experts would be upset when seeing this. Lada >=20 >=20 >>=20 >> Lada >>=20 >>> regards Balazs >>>=20 >>> On 2015-10-16 09:43, Ladislav Lhotka wrote: >>>>> On 15 Oct 2015, at 18:03, Martin Bjorklund >>>>> wrote: >>>>>=20 >>>>> Andy Bierman=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund = >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>> Andy Bierman >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> You are incorrect. >>>>>>>>=20 >>>>>>>> Within the PAYLOAD (as this section describes), there is no = when-stmt >>>>>>>> for data nodes within the datastore. Look at the YANG for >>>>>>>> edit-config. >>>>>>>> There are no when-stmts for "interface" in "edit-config". >>>>>>>>=20 >>>>>>> Andy, there is some confusion here. The section talks about: >>>>>>>=20 >>>>>>> For configuration data, there are three windows when constraints >>>>>>> MUST be enforced: >>>>>>>=20 >>>>>>> - during parsing of RPC payloads >>>>>>> - during processing of NETCONF operations >>>>>>> - during validation >>>>>>>=20 >>>>>>> So the entire section talks about constraints *on configuration = data*. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> = http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.= 421 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Here is the YANG for edit-config? >>>>>> Please point out the when-stmts in this rpc-stmt >>>>>> specific to the "interface" node. >>>>>> I just see an "anyxml" that has no when-stmts at all. >>>>>>=20 >>>>>> So enforcing the when constraint on the RPC PAYLOAD >>>>>> clearly has nothing to do with "interface" -- just the parameters >>>>>> specified in the rpc-stmt. >>>>>>=20 >>>>> Ok, you're right. 8.2.1 should be kept as it is. (we may need to >>>>> rephrase the intro text in 8.2) But I think Balazs is also right. >>>>> Suppose you have: >>>>>=20 >>>>> leaf a { >>>>> when "../b =3D 42"; >>>>> type int32; >>>>> } >>>>> leaf b { >>>>> type int32; >>>>> } >>>>>=20 >>>>> and the db contains b=3D10. >>>>>=20 >>>>> Suppose I send an edit-config with a=3D2. What is the result? >>>>>=20 >>>>> 1) you get an error back >>>>> 2) you get ok; the request to set a to 2 is silently dropped >>>>> 3) something else >>>>>=20 >>>> IMO YANG spec shouldn't deal with this kind of things in the first >>>> place. It should be sufficient to define two validation levels, >>>> e.g. syntactic (schema) and semantic validity. Stating what a = protocol >>>> does if either of these validity types is violated would then be up = to >>>> the protocol spec, and different protocols may use different >>>> approaches. >>>>=20 >>>> That said, I like #1 best. >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>>=20 >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>>=20 >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 =20 >>> Mobile: +36-70-330-7909 email:=20 >>> Balazs.Lengyel@ericsson.com >>>=20 >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 04:32:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70851A909F for ; Fri, 16 Oct 2015 04:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swWAnHEVkhJt for ; Fri, 16 Oct 2015 04:32:20 -0700 (PDT) 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 DBBC81A90A0 for ; Fri, 16 Oct 2015 04:32:19 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502] (unknown [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502]) by mail.nic.cz (Postfix) with ESMTPSA id 82384181A00; Fri, 16 Oct 2015 13:32:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444995138; bh=9sVJqxxFs8k74Bcc9MnzYDQdVOfmRPMp2plvp62VJqs=; h=From:Date:To; b=WjSXyIIN1hezJHM9oBcV0B9LlhLh31Ulm0D88hZDrfG7At4VJ6mDcg5ScrRXQJIFU Nh80y+5MyARKNCwk/ulUp5Zk4yt+PmSJN4MUywFIM3WCpdp7570l4NAbFu2NPfUrRd H3NzWoJVEcCpPpiQhmFsIB5L557X+7rQ7au/8NuA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Ladislav Lhotka In-Reply-To: <20151016.131708.1683862723851859367.mbj@tail-f.com> Date: Fri, 16 Oct 2015 13:32:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87EE2A03-DEB0-4755-807C-62E4D4DE91A3@nic.cz> References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> <20151016.131708.1683862723851859367.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3094) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:32:24 -0000 > On 16 Oct 2015, at 13:17, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >> ... >>=20 >>>=20 >>>> I am also wondering why we use device and server. It seems we use >>>> these terms interchangeably. If so, for clarity, I would suggest = to >>>> use a single term, that is s/device/server >>>=20 >>> Ok, fixed. >>>=20 >>>> / and perhaps explicitly >>>> state that unless stated otherwise server means a server providing >>>> access to a YANG defined data tree. >>>=20 >>> Yes this makes sense. But then I guess we shouldn't import client = and >>> server from 6241. (And most other documents (restconf etc) should >>> probably import these terms from ths document). See also below. >>>=20 >>>> * p12/p13 >>>>=20 >>>> We import 7 terms from RFC 6241. Would it make sense to copy the >>>> necessary text in order to avoid a too strict binding to RFC 6241? >>>> In particular, 'client' and 'server' means NETCONF client and = server >>>> if we import from RFC 6241 but this may be a bit narrow given that >>>> we have RESTCONF as well. In an ideal world, we would factor out >>>> core architectural concepts but the best we can do is likely to >>>> define core concepts inline, pointing out where they are the same. >>>> The idea is to loosen the coupling to RFC 6241. Example: >>>>=20 >>>> OLD >>>>=20 >>>> o datastore: an instantiated data tree >>>>=20 >>>> NEW >>>>=20 >>>> o datastore: A conceptual place to store and access information. >>>> A datastore might be implemented, for example, using files, a >>>> database, flash memory locations, or combinations thereof. >>>> [Matches the definition in RFC 6241.] >>>=20 >>> To start with, I think we should define client and server more >>> generically than just NETCONF: >>>=20 >>> server: An entity that provides access to YANG-defined data to a >>> client, over some network management protocol. >>=20 >> But then perhaps "device" is a broader term in the sense that the >> server is just >> a software component running in a device. >=20 > So how do you define "device"? An entity that's being managed and runs the server. >=20 >> For example, it is the device that is required to operationally use >> default values of parameters that are not present in the >> configuration. Replacing "device" with "server" here IMO means = something >=20 > The text was actually already in RFC 6020: >=20 > When the default value is in use, the server MUST operationally > behave as if the leaf was present in the data tree with the default > value as its value. Right, but with your definition of "server" there is no guarantee that, = say, if "mtu" on an interface has a default value and no value is = configured, then the default value is really used - MTU has nothing to = do with server operation. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 16 05:01:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF91A914C for ; Fri, 16 Oct 2015 05:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjUE5-45ye65 for ; Fri, 16 Oct 2015 05:01:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40D291A914A for ; Fri, 16 Oct 2015 05:01:45 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 16CCE1AE0478; Fri, 16 Oct 2015 14:01:44 +0200 (CEST) Date: Fri, 16 Oct 2015 14:01:43 +0200 (CEST) Message-Id: <20151016.140143.1643639652175921028.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <5620D3B1.6040805@ericsson.com> References: <561FC736.6030903@ericsson.com> <5620D3B1.6040805@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Order of evaluation for when? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:01:46 -0000 Hi, Balazs Lengyel wrote: > Hello Andy, Martin, > If that is what is meant by 8.2.1 then I have a few comments Sorry for the confusion on this topic. I have now done some digging in the archives and I think that section 8.2 is really intended to apply only to *configuration data* (which it actually says upfront). The text in 8.2.1 is not intended to be for generic rpcs; it is intended for rpcs that modify configuration datastores (edit-config). The whole idea is that there are really three points in time where "checks" are done - (1) simple type checks and structural checks when the edit-config is parsed (2) check that the requested _operations_ are valid and (3) check that the _resulting datastore_ is valid. This said, note that section 8.1 applies to *all* valid data trees, including rpc/action input/output. So, in summary, 8.1 defines the generic rules for valid data trees, and 8.2 defines the NETCONF-specific behavior for edit-config processing. In order to resolve Balazs' original issue, we need to agree what should happen in these cases *for NETCONF*. Suppose we have: leaf a { when "../b = 42"; type int32; } leaf b { type int32; } Scenario A ---------- The DB contains b=10 The server gets an edit-config with: 2 What is the result? 1) an error is returned 2) ok; the request to set a to 2 is silently dropped Scenario B ---------- The DB contains b=10. The server gets an edit-config with: 2 42 What is the result? 1) an error is returned 2) ok, db now has b=42; the request to set a to 2 is silently dropped 3) ok, db now has a=2 and b=42 Scenario C (same as 2, but different order in edit-config) ---------- The DB contains b=10. The server gets an edit-config with: 42 2 What is the result? 1) an error is returned 2) ok, db now has b=42; the request to set a to 2 is silently dropped 3) ok, db now has a=2 and b=42 /martin From nobody Fri Oct 16 05:09:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B1D1ABC75 for ; Fri, 16 Oct 2015 05:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNhhphyeAAxR for ; Fri, 16 Oct 2015 05:08:56 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80581A9302 for ; Fri, 16 Oct 2015 05:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65844; q=dns/txt; s=iport; t=1444997335; x=1446206935; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kEmCUDUmhwujiTJ1iV+e2V+9Wm5j1RuCeR+36vCAuas=; b=kjWiUiPikgF0HRQHlxNQGQ16eRevyj3rZsPwMFH06nn2M9/LFQQLvRAZ BRwhOTEVjLwxRvEb92ROUdZvueyfPHbCmFyk2bdeh94ZK4z3Uw1cXp2i5 rm6fVZNf8CqFdGHzEz/dICCBhj13HnO4LMMd30sZ0LpgdclSYq8pZ87Tu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CkBAAD6CBW/xbLJq1eglmBIW6/TgMXAQmFM0oCggEBAQEBAQGBC4QmAQEBAwEBAQEXAVMKEQsOAwMBAgEJFgEBAgQHCQMCAQIBFR8JCAYBDAYCAQGIIggNwzABAQEBAQEBAQEBAQEBAQEBAQEBFQSGdoN4gQaEKhEBBjoYhC4FklaDR4gJhRKBWIc7ijWISGOCER0WgUA9M4QgBxcHgSIBAQE X-IronPort-AV: E=Sophos;i="5.17,688,1437436800"; d="scan'208,217";a="607640779" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Oct 2015 12:08:51 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9GC8pJW026362; Fri, 16 Oct 2015 12:08:51 GMT To: Kent Watsen , Gert Grammel , "netmod@ietf.org" References: <5603F9C2.2000500@cisco.com> <560BF9A3.4090603@cisco.com> <560D01D1.5000607@cisco.com> <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com> <561FB149.103@cisco.com> From: Robert Wilton Message-ID: <5620E8C5.4020808@cisco.com> Date: Fri, 16 Oct 2015 13:08:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040901000400090407040300" Archived-At: Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:09:01 -0000 This is a multi-part message in MIME format. --------------040901000400090407040300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Gert, Balazs pointed out, and I agree, that the text about transaction/not transactional can equally apply to both synchronous and asynchronous configuration operations. So rather than reproducing this text twice, once for each configuration definition, I propose keeping the transactional text out of the definition for synchronous/asynchronous configuration operations and instead include it as a sub-bullet for the section 3 requirements. I'll send my proposed text for the section 3 requirements on that separate email thread. Hence, I propose that we revert to this text for synchronous configuration operation: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. The reply to the client indicates whether there are any errors in the request or errors from applying the configuration change. I agree with the existing proposed text for asynchronous configuration operation and also support the proposal to drop the definition of synchronous/asynchronous configuration servers if they are not being used. Thanks, Rob On 15/10/2015 18:03, Kent Watsen wrote: > These terms were edited on today's call, resulting in the following text: > > Synchronous configuration operation - A configuration request to > update > the running configuration of a server that is applied > synchronously with > respect to the client request. The server MUST fully attempt to > apply > the configuration change to all impacted components in the server, > updating both the server's intended and applied configuration (see > terms), > before replying to the client. This may be transactional or non- > transactional (need terms!). The transactionality of the operation > may be a server property or specified on as a property. > The reply to the client indicates whether there > are any errors in the request or errors from applying the > configuration > change. > Asynchronous configuration operation - A configuration request to > update > the running configuration of a server that is applied asynchronously > with respect to the client request. The server MUST update its > intended > configuration (see term) before replying to the client indicating > whether the request will be processed. This reply to the client only > indicates whether there are any errors in the original request. The > server's applied configuration state (see term) is updated after the > configuration change has been fully effected to all impacted > components > in the server. Once applied, there MUST be a mechanism for the > client to > determine when the request has completed processing and whether the > intended config is now fully effective or there are any errors from > applying the configuration change, which could be from an asynchronous > notification or via a client operation. > > Synchronous configuration server - a configuration server that > processes > all configuration operations as synchronous configuration operations. > Asynchronous configuration server - a configuration server that > processes > all configuration operations as asynchronous configuration operations. > > > We have consensus on the above, but are hoping for some word-smithing > before committing it to the draft. Anybody want to take a crack at it? > > BTW, do we still need to define the last two terms anymore? - they're > not used elsewhere in the draft... > > Kent > > > > From: Gert Grammel > > Date: Thursday, October 15, 2015 at 10:35 AM > To: Robert Wilton >, Kent > Watsen >, > "netmod@ietf.org " > > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous > vs asynchronous (esp. wrt intended and applied) > > Rob, > > From a client perspective a server has three states: > > 1. intended != applied > 2. Funny-state > 3. Intended == applied > > Irrespective of synchronous or asynchronous processing in the server, > the third state MUST be reported to the client. Else (from a client > perspective) the server stays in funny-state forever. > > > Gert > > > From: Robert Wilton > > Date: Thursday 15 October 2015 15:59 > To: Gert Grammel >, > Kent Watsen >, > "netmod@ietf.org " > > Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous > vs asynchronous (esp. wrt intended and applied) > > Hi Gert, Kent, > > I think that notifying the client is one possible way that an > asynchronous request could be completed, but not necessarily the only > way. E.g. if the information as to whether a particular intended > leave had been successfully applied was available (e.g. as per github > issue #2). > > So, I wonder whether we shouldn't weaken the last sentence, changing > MUST to COULD, or perhaps reword it.: > > E.g. replacing: > > Once applied, the client MUST be notified whether the intended config > is now fully effective or there are any errors from applying the > configuration change. > > Perhaps with: > > Once applied, the client COULD be notified whether the intended config > is now fully effective or there are any errors from applying the > configuration change. > > Or: > > Once applied, there MUST be a mechanism available for the client to be > able to determine whether the intended config is now fully effective > or whether there are any errors from applying the configuration change. > > Thanks, > Rob > > > On 15/10/2015 12:17, Gert Grammel wrote: >> Kent, Rob, >> >> Comparing the cases, the definition of the asynchronous case doesn’t >> look complete. The way it stands for the synchronous operation, the >> client knows that it's intended config was good AND it has been >> effected to the server. In the Asynchronous case, the client only >> knows that the intended config was good – and that’s not enough. >> >> So the proposal is to refine the asynchronous case definition as follows: >> >> Asynchronous configuration operation - A configuration request to >> update the running configuration of a server that is applied >> asynchronously with respect to the client request. The server MUST >> update its intended configuration (see term) before replying to the >> client indicating whether the request will be processed. The reply >> to the client only indicates whether there are any errors in the >> original request. >> The server's applied configuration state (see term) is updated after >> the configuration change has been applied to all impacted components >> in the server. Once applied, the client MUST be notified whether the >> intended config is now fully effective or there are any errors from >> applying the configuration change. >> >> In addition I would suggest to require a verify operation which a >> client can request from the server to obtain above information on an >> on-demand basis. Would that somehow go in the opstate-reqs #3 then? >> >> Best >> >> Gert >> >> >> >> >> From: netmod on behalf of Kent Watsen >> > >> Date: Thursday 15 October 2015 00:11 >> To: Robert Wilton , "netmod@ietf.org >> " > >> Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous >> vs asynchronous (esp. wrt intended and applied) >> >> Hi Robert, >> >> One comment, it seems that the asynchronous configuration operation >> should >> have one more sentence at its end saying that an asynchronous >> notification >> must be used to report any errors produced from when applying the >> configuration. >> >> What do you think? >> >> Kent // as a contributor >> >> >> >> On 10/14/15, 10:59 AM, "Robert Wilton" wrote: >> >> Hi All, >> >> Are there any more comments on the following proposed >> descriptions, or >> are these descriptions sufficiently clear to update the requirements >> draft and resolve issue #6? >> >> Synchronous configuration operation - A configuration request to >> update >> the running configuration of a server that is applied >> synchronously with >> respect to the client request. The server MUST fully effect the >> configuration change to all impacted components in the server, >> updating >> both the server's intended and applied configuration (see terms), >> before >> replying to the client. The reply to the client indicates >> whether there >> are any errors in the request or errors from applying the >> configuration >> change. >> >> Asynchronous configuration operation - A configuration request to >> update >> the running configuration of a server that is applied asynchronously >> with respect to the client request. The server MUST update its >> intended >> configuration (see term) before replying to the client indicating >> whether the request will be processed. The server's applied >> configuration state (see term) is updated after the configuration >> change >> has been fully effected to all impacted components in the >> server. The >> reply to the client only indicates whether there are any errors >> in the >> original request. >> >> Synchronous configuration server - a configuration server that >> processes >> all configuration operations as synchronous configuration operations. >> >> Asynchronous configuration server - a configuration server that >> processes >> all configuration operations as asynchronous configuration >> operations. >> >> Thanks, >> Rob >> >> >> On 13/10/2015 09:48, Juergen Schoenwaelder wrote: >> >> On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: >> >> Hi Juergen, >> >> On 06/10/2015 17:16, Juergen Schoenwaelder wrote: >> >> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert >> Wilton wrote: >> >> Hi Kent, >> >> Feeding in the various input, I think that this >> is the best >> refinement >> that I've come up with: >> >> Synchronous configuration operation - A >> configuration request to >> update >> the running configuration of a server that is >> applied synchronously >> with >> respect to the client request. The server SHOULD >> ensure that the >> request is valid, and MUST fully effect the >> configuration change to >> all >> impacted components in the server, updating both >> the server's >> intended >> and applied configuration (see terms), before >> replying to the client. >> The reply to the client indicates whether there >> are any errors in the >> request or errors from applying the configuration >> change. >> >> What does "SHOULD ensure that the request is valid" >> mean? RFC 6020 >> says: >> >> When datastore processing is complete, the final >> contents MUST >> obey >> all validation constraints. This validation >> processing is >> performed >> at differing times according to the >> datastore. If the datastore >> is >> or , these constraints MUST >> be enforced at >> the >> end of the or >> operation. If the >> datastore is , the constraint >> enforcement is delayed >> until a or operation. >> >> Are we talking about datastore validation or >> validation of a request? >> If the former, are we watering down a MUST to a SHOULD? >> >> Really it is datastore validation, particularly for an >> async request >> where the intended config nodes are updated before >> replying. I'm not >> intentionally trying to water down a MUST to a SHOULD, >> but Kent had >> concerns that my previous description using "semantically >> validate" >> would exclude an ephemeral datastore, so I was trying to >> water down the >> description and also describe the behaviour in a way that >> isn't >> specific >> to either RESTCONF/NETCONF or datastores. >> >> Perhaps, the start of sentence could simply be changed to: >> >> The server MUST fully effect the configuration change to all >> impacted components in the server ... >> >> And equivalently for the asynchronous case below: >> >> The server MUST update the server's intended >> configuration ... >> >> Works for me. Sometimes less is more. >> >> And I would not be surprised if we also need this >> sooner or later: >> >> Mixed configuration server - a configuration >> server that processes >> some configuration operations as synchronous >> configuration >> operations and some configuration operations as >> asynchronous >> configuration operations. >> >> Yes, I would expect that clients may want to define the >> expected >> behaviour, potentially on a per request basis. >> >> I doubt that servers will offer clients to choose; I am more >> with Andy >> that in real systems, depending on the data model, certain >> parts of a >> data model may be synchronous while others may be asynchronous. >> >> Any further comments? >> >> Based on the feedback from Andy and others, it >> seems that the >> prevailing >> view is that existing NETCONF and RESTCONF should >> be regarded as >> being >> asynchronous in their behaviour in that the >> config nodes in the >> running >> datastore only represent the intended >> configuration and not the >> applied >> configuration. >> >> Depends on the definition of applied configuration - >> where is the >> latest >> version of it? >> >> The last proposed text for intended/applied is as below: >> >> intended configuration - this data represents the >> configuration >> state that the network operator intends the >> system to be in, and >> that >> has been accepted by the system as valid >> configuration. This >> data is >> colloquially referred to as the 'configuration' >> of the system. >> >> applied configuration - this data represents the >> configuration >> state that the network element is actually in, >> i.e., the >> configuration state which is currently being >> being used by >> system >> components (e.g., control plane daemons, >> operating system >> kernels, line cards). >> >> Well, sometimes the config goes to a control plane daemon and >> then to >> the OS kernel and finally to the line cards. This definition >> leaves >> some room what an applied configuration is (which is IMHO >> needed if >> you want to have something implementable) and hence a NC >> server can >> either be considered synchronous or asynchronous. >> >> From Thursday's interim meeting, Rob Shakir clarified >> that the desired >> intention is that applied configuration should mean that the >> configuration is fully applied everywhere. I don't know >> if that means >> that the definition of applied configuration should be >> strengthened, or >> if it is sufficient? >> >> As said before, an OS kernel usually does not track where >> resource >> parameters were coming from. (An interface has a set of IP >> addresses >> and the kernel usually does not know which addresses were >> coming from >> a configuration daemon, a dhcp daemon, a tunneling daemon, a >> command >> line utility, ...) The same may be true for line card. So in >> order to >> implement a very tight definition, one has to either 'guess' >> which >> 'subset' of operational state can be related 'somehow' to the >> intended >> config and then report the result of the guess work as >> applied config >> or one would have to to change daemons/kernels/linecards to >> have a >> tracking number or something like that. >> >> Anyway, as long as a regular NC/RC server does not have to >> pay a price >> for this applied config idea, I have no real problem with >> this since I >> am sure the market will sort this out. >> >> /js >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > --------------040901000400090407040300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Kent, Gert,

Balazs pointed out, and I agree, that the text about transaction/not transactional can equally apply to both synchronous and asynchronous configuration operations.

So rather than reproducing this text twice, once for each configuration definition, I propose keeping the transactional text out of the definition for synchronous/asynchronous configuration operations and instead include it as a sub-bullet for the section 3 requirements.  I'll send my proposed text for the section 3 requirements on that separate email thread.

Hence, I propose that we revert to this text for synchronous configuration operation:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously with
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see terms),
    before replying to the client.  The reply to the client indicates whether there
    are any errors in the request or errors from applying the configuration
    change.

I agree with the existing proposed text for asynchronous configuration operation and also support the proposal to drop the definition of synchronous/asynchronous configuration servers if they are not being used.

Thanks,
Rob


On 15/10/2015 18:03, Kent Watsen wrote:
These terms were edited on today's call, resulting in the following text:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously with
    respect to the client request.  The server MUST fully attempt to apply 
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see terms),
    before replying to the client.  This may be transactional or non-
    transactional (need terms!).  The transactionality of the operation
    may be a server property or specified on as a property.
    The reply to the client indicates whether there
    are any errors in the request or errors from applying the configuration
    change.
    
    Asynchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied asynchronously
    with respect to the client request.  The server MUST update its intended
    configuration (see term) before replying to the client indicating
    whether the request will be processed.  This reply to the client only
    indicates whether there are any errors in the  original request.  The
    server's applied configuration state (see term) is updated after the
    configuration change has been fully effected to all impacted components
    in the server.  Once applied, there MUST be a mechanism for the client to
    determine when the request has completed processing and whether the
    intended config is now fully effective or there are any errors from
    applying the configuration change, which could be from an asynchronous
    notification or via a client operation.

    Synchronous configuration server - a configuration server that processes
    all configuration operations as synchronous configuration operations.
    
    Asynchronous configuration server - a configuration server that processes
    all configuration operations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing before committing it to the draft.  Anybody want to take a crack at it?

BTW, do we still need to define the last two terms anymore?  - they're not used elsewhere in the draft...

Kent



From: Gert Grammel <ggrammel@juniper.net>
Date: Thursday, October 15, 2015 at 10:35 AM
To: Robert Wilton <rwilton@cisco.com>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Rob,

From a client perspective a server has three states: 
  1. intended != applied
  2. Funny-state
  3. Intended == applied
Irrespective of synchronous or asynchronous processing in the server, the third state MUST be reported to the client. Else (from a client perspective) the server stays in funny-state forever.


Gert


From: Robert Wilton <rwilton@cisco.com>
Date: Thursday 15 October 2015 15:59
To: Gert Grammel <ggrammel@juniper.net>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous request could be completed, but not necessarily the only way.  E.g. if the information as to whether a particular intended leave had been successfully applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST to COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

Or:

Once applied, there MUST be a mechanism available for the client to be able to determine whether the intended config is now fully effective or whether there are any errors from applying the configuration change.

Thanks,
Rob


On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn’t look complete. The way it stands for the synchronous operation, the client knows that it's intended config was good AND it has been effected to the server. In the Asynchronous case, the client only knows that the intended config was good – and that’s not enough.

So the proposal is to refine the asynchronous case definition as follows:

Asynchronous configuration operation - A configuration request to update the running configuration of a server that is applied asynchronously with respect to the client request.  The server MUST update its intended configuration (see term) before replying to the client indicating whether the request will be processed.  The reply to the client only indicates whether there are any errors in the  original request.
The server's applied configuration state (see term) is updated after the configuration change has been applied to all impacted components in the server.  Once applied, the client MUST be notified whether the intended config is now fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a client can request from the server to obtain above information on an on-demand basis. Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Thursday 15 October 2015 00:11
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" <rwilton@cisco.com> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server, updating both the server's
intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.
What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

     When datastore processing is complete, the final contents MUST
obey
     all validation constraints.  This validation processing is
performed
     at differing times according to the datastore.  If the datastore
is
     <running/> or <startup/>, these constraints MUST be enforced at
the
     end of the <edit-config> or <copy-config> operation.  If the
     datastore is <candidate/>, the constraint enforcement is delayed
     until a <commit> or <validate> operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validate"
would exclude an ephemeral datastore, so I was trying to water down the
description and also describe the behaviour in a way that isn't
specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...

Works for me. Sometimes less is more.

And I would not be surprised if we also need this sooner or later:

    Mixed configuration server - a configuration server that processes
    some configuration operations as synchronous configuration
    operations and some configuration operations as asynchronous
    configuration operations.
Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.
I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.

Any further comments?

Based on the feedback from Andy and others, it seems that the
prevailing
view is that existing NETCONF and RESTCONF should be regarded as
being
asynchronous in their behaviour in that the config nodes in the
running
datastore only represent the intended configuration and not the
applied
configuration.
Depends on the definition of applied configuration - where is the
latest
version of it?
The last proposed text for intended/applied is as below:

        intended configuration - this data represents the configuration
        state that the network operator intends the system to be in, and
that
        has been accepted by the system as valid configuration.  This
data is
        colloquially referred to as the 'configuration' of the system.

       applied configuration - this data represents the configuration
        state that the network element is actually in, i.e., the
        configuration state which is currently being being used by
system
        components (e.g., control plane daemons, operating system
        kernels, line cards).
Well, sometimes the config goes to a control plane daemon and then to
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

  From Thursday's interim meeting, Rob Shakir clarified that the desired
intention is that applied configuration should mean that the
configuration is fully applied everywhere.  I don't know if that means
that the definition of applied configuration should be strengthened, or
if it is sufficient?
As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from
a configuration daemon, a dhcp daemon, a tunneling daemon, a command
line utility, ...) The same may be true for line card. So in order to
implement a very tight definition, one has to either 'guess' which
'subset' of operational state can be related 'somehow' to the intended
config and then report the result of the guess work as applied config
or one would have to to change daemons/kernels/linecards to have a
tracking number or something like that.

Anyway, as long as a regular NC/RC server does not have to pay a price
for this applied config idea, I have no real problem with this since I
am sure the market will sort this out.

/js


_______________________________________________
netmod mailing list

_______________________________________________
netmod mailing list

--------------040901000400090407040300-- From nobody Fri Oct 16 05:13:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0189B1A007E for ; Fri, 16 Oct 2015 05:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNqBjOyGJYFr for ; Fri, 16 Oct 2015 05:13:13 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3A31A00E9 for ; Fri, 16 Oct 2015 05:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18302; q=dns/txt; s=iport; t=1444997573; x=1446207173; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=MPwi7R2sMk2pRKo8Ni4iLYqxGKoxnWo1Eq2QUoVRwb8=; b=S79mvHJZ+Bvzk7KAH5sDPegSyxL6qN0WZVaG4xzqnmpCl4H1TCUoLsOX cnUu5btmveqsq/bihnoODFHMR+B4btrUSKPDX1kvFXpBGK4FVoUXZaB9e 5IBvNRUD5Morw0rmiF++gZ966DTc9+Ljf27LqA44uLtMBVyTJsL4Pem/r g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKAQAi6SBW/xbLJq1eg3puvWoBDYFZFwEJhTNKAoFtFAEBAQEBAQGBCoQnAQEEAQEBIEsLEAkCDgIICRoHAgIPAhYwBgEMBgIBAYgqDZJGnTeTNAEBAQEBAQEBAQEBAQEBAQEBAQEBFASGdoN4gQaEQksHgmmBRQWHOocFhAGDXY0bgViHO4EaiRuEWYNvHwEBQoJEgUA9M4VnAQEB X-IronPort-AV: E=Sophos;i="5.17,688,1437436800"; d="scan'208,217";a="612247606" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Oct 2015 12:12:50 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GCCn65032512; Fri, 16 Oct 2015 12:12:50 GMT To: Kent Watsen , Nadeau Thomas References: <20150922142254.GB99134@elstar.local> <20150922170012.GA99454@elstar.local> <56027D26.8020801@cisco.com> <20150928084013.GB95620@elstar.local> <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com> From: Robert Wilton Message-ID: <5620E9B3.60009@cisco.com> Date: Fri, 16 Oct 2015 13:12:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000500060208010803000007" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:13:16 -0000 This is a multi-part message in MIME format. --------------000500060208010803000007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Here is my attempt at word smithing section 3: The old D and E have been merged together (now labelled as C). A new D has been added to try and define transactional error handling semantics without introducing the term transactional. 3. Support for both synchronous and asynchronous configuration operations A. A server may choose to support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations in a client specified per-operation basis. B. Support for synchronous operations as per the definition of "synchronous configuration operation". C. Support for asynchronous operations as per the definition of "asynchronous configuration operation". Servers that support asynchronous configuration operations MAY also provide a verify operation that a client can request from the server to return information regarding the difference between the intended and applied configurations. D. Support for best effort and rollback-on-error error handling semantics. The configuration protocol, or default server behavior, MUST specify whether the configuration is applied in a best effort fashion, or using "rollback on error" semantics - where all configuration changes in the request are undone if processing of any part of the configuration update failed. A configuration protocol, or server, SHOULD provide support for rollback-on-error behavior and MAY choose to provide support for best effort semantics as well. Any comments? Thanks, Rob On 15/10/2015 18:32, Kent Watsen wrote: > Again, with better formatting for the list: > > 3. Support for both synchronous and asynchronous configuration > operations (see terms) > > A. A server may only support synchronous configuration > operations, or may only support asynchronous configuration > operations, or may support synchronicity to be client > specified on a per-operation basis. > > > C. Support for synchronous configuration operations > requires the server to block sending a response to > the client until it is able to able to determine whether > there are any errors in the request or errors from > applying the configuration change. > > D. Support for asynchronous configuration operations > requires the server to send a response to the client > immediately indicated that the request was accepted > and send a notification to the client when the intended > config is fully effective or there are any errors from > applying the configuration change. > > E. Support for asynchronous configuration operations MAY > also provide a verify operation which a client can request > from the server to obtain information regarding the > difference between the intended and applied configurations. > > > Kent > > > > On 10/15/15, 1:22 PM, "Kent Watsen" wrote: > >> Requirement #3 was discussed on today's call. We agreed to remove the >> words "distributed" and "transactional" and to reword it in terms of >> "configuration operations". The resulting text follows: >> >> >> 3. Support for both synchronous and asynchronous configuration >> operations (see terms) >> >> A. A server may only support synchronous configuration operations, >> or may only support >> asynchronous configuration operations, or may support >> synchronicity to be client >> specified on a per-operation basis. >> >> >> C. Support for synchronous configuration operations requires the >> server to block >> sending a response to the client until it is able to able to >> determine whether >> there are any errors in the request or errors from applying the >> configuration >> change. >> >> D. Support for asynchronous configuration operations requires the >> server to send >> a response to the client immediately indicated that the request >> was accepted >> and send a notification to the client when the intended config >> is fully >> effective or there are any errors from applying the >> configuration change. >> >> E. Support for asynchronous configuration operations MAY also >> provide a verify >> operation which a client can request from the server to obtain >> information >> regarding the difference between the intended and applied >> configurations. >> >> >> >> We have consensus on the above, but wanted to rewrite it relying more on >> the terms from the Terminology section, and also potentially merge E into >> D. >> >> Anybody want to take a stab at it? >> >> Thanks, >> Kent >> >> >> >> On 10/14/15, 8:00 PM, "Nadeau Thomas" wrote: >> >>>> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen >>>> wrote: >>>> >>>> >>>> >>>> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder" >>>> wrote: >>>> >>>>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote: >>>>>> Popping the stack on this issue, the issue remains as to what to do >>>>>> with requirement 3: >>>>>> >>>>>> 3. Support for both transactional, synchronous management systems >>>>>> as well as distributed, asynchronous management systems >>>>>> >>>>> I fail to understand 'transactional' and 'distributed' here. >>>> I hope that these terms will be clarified on tomorrow's call. There >>>> is >>>> also a chance that these terms will be removed from the text >>>> altogether, >>>> as they may be viewed as unnecessarily qualify the >>>> synchronous/asynchronous terms. >>>> >>>> >>>>> And >>>>> frankly, I am not sure why the management _systems_ are classified to >>>>> be synchronous or asynchronous - I think we are talking about >>>>> protocols between a management system and a device. >>>> >>>> Aye, I didn't see that before. >>>> >>>> First off, elsewhere in the draft the term "system" is used 7 times to >>>> refer to the device (e.g., NC/RC server). The term "system" is >>>> otherwise >>>> not defined. >>>> >>>> But to your main point, we have been discussing the terms a/synchronous >>>> to >>>> have to do with internal server processing of an edit request, but in >>>> '3' >>>> the terms are being used to qualify a management system, which can't be >>>> right. I think that '3' should be rewritten to be a statement about >>>> devices, not a statement about management systems. >>> It might be better to frame this in terms of a client and a >>> server. >>> >>> ‹Tom >>> >>> >>>> Anyway, I am not sure 3. is properly worded until someone defines >>>>> 'transactional', 'distributed', 'synchronous management systems' and >>>>> 'asynchronous management systems'. >>>> The agenda for tomorrow's interim! :) >>>> >>>> >>>> Kent >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000500060208010803000007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kent,

Here is my attempt at word smithing section 3:

The old D and E have been merged together (now labelled as C).  A new D has been added to try and define transactional error handling semantics without introducing the term transactional.


   3.  Support for both synchronous and asynchronous configuration
       operations

       A. A server may choose to support only synchronous configuration
          operations, or only asynchronous configuration operations, or
          both synchronous and asynchronous configuration operations in
          a client specified per-operation basis.

       B. Support for synchronous operations as per the definition of
          "synchronous configuration operation".

       C. Support for asynchronous operations as per the definition of
          "asynchronous configuration operation".  Servers that support
          asynchronous configuration operations MAY also provide a
          verify operation that a client can request from the server to
          return information regarding the difference between the
          intended and applied configurations.

       D. Support for best effort and rollback-on-error error handling
          semantics.  The configuration protocol, or default server
          behavior, MUST specify whether the configuration is applied
          in a best effort fashion, or using "rollback on error"
          semantics - where all configuration changes in the request are
          undone if processing of any part of the configuration update
          failed.  A configuration protocol, or server, SHOULD provide
          support for rollback-on-error behavior and MAY choose to
          provide support for best effort semantics as well.

Any comments?

Thanks,
Rob


On 15/10/2015 18:32, Kent Watsen wrote:
Again, with better formatting for the list:

   3.  Support for both synchronous and asynchronous configuration
       operations (see terms)

       A. A server may only support synchronous configuration
          operations, or may only support asynchronous configuration
          operations, or may support synchronicity to be client
          specified on a per-operation basis.


       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request or errors from
          applying the configuration change.
    
       D. Support for asynchronous configuration operations
          requires the server to send a response to the client
          immediately indicated that the request was accepted
          and send a notification to the client when the intended
          config is fully effective or there are any errors from
          applying the configuration change.

       E. Support for asynchronous configuration operations MAY
          also provide a verify operation which a client can request
          from the server to obtain information regarding the
          difference between the intended and applied configurations.


Kent



On 10/15/15, 1:22 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:


Requirement #3 was discussed on today's call.   We agreed to remove the
words "distributed" and "transactional" and to reword it in terms of
"configuration operations".  The resulting text follows:


  3.  Support for both synchronous and asynchronous configuration
operations (see terms)

      A. A server may only support synchronous configuration operations,
or may only support
         asynchronous configuration operations, or may support
synchronicity to be client
         specified on a per-operation basis.


      C. Support for synchronous configuration operations requires the
server to block
         sending a response to the client until it is able to able to
determine whether
         there are any errors in the request or errors from applying the
configuration
         change.
   
      D. Support for asynchronous configuration operations requires the
server to send
         a response to the client immediately indicated that the request
was accepted
         and send a notification to the client when the intended config
is fully 
         effective or there are any errors from applying the
configuration change.

      E. Support for asynchronous configuration operations MAY also
provide a verify
         operation which a client can request from the server to obtain
information
         regarding the difference between the intended and applied
configurations.



We have consensus on the above, but wanted to rewrite it relying more on
the terms from the Terminology section, and also potentially merge E into
D. 

Anybody want to take a stab at it?

Thanks,
Kent



On 10/14/15, 8:00 PM, "Nadeau Thomas" <tnadeau@lucidvision.com> wrote:



          

            
On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen <kwatsen@juniper.net>
wrote:



On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
<j.schoenwaelder@jacobs-university.de> wrote:



            

              
On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:


              

                
Popping the stack on this issue, the issue remains as to what to do
with requirement 3:

  3.  Support for both transactional, synchronous management systems
       as well as distributed, asynchronous management systems



              

              
I fail to understand 'transactional' and 'distributed' here.


            

            
I hope that these terms will be clarified on tomorrow's call.   There
is
also a chance that these terms will be removed from the text
altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.




            

              
And
frankly, I am not sure why the management _systems_ are classified to
be synchronous or asynchronous - I think we are talking about
protocols between a management system and a device.


            

            

Aye, I didn't see that before.

First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server).  The term "system" is
otherwise
not defined.

But to your main point, we have been discussing the terms a/synchronous
to
have to do with internal server processing of an edit request, but in
'3'
the terms are being used to qualify a management system, which can't be
right.  I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.


          

          
	It might be better to frame this in terms of a client and a
server.

	‹Tom




          

            
Anyway, I am not sure 3. is properly worded until someone defines


            

              
'transactional', 'distributed', 'synchronous management systems' and
'asynchronous management systems'.


            

            
The agenda for tomorrow's interim!  :)


Kent

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


          

          

        

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


      

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


    

    

  


--------------000500060208010803000007--


From nobody Fri Oct 16 05:19:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478691A1ABB for ; Fri, 16 Oct 2015 05:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAmWRfgT1ztE for ; Fri, 16 Oct 2015 05:19:18 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C49D1A1AB9 for ; Fri, 16 Oct 2015 05:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1473; q=dns/txt; s=iport; t=1444997957; x=1446207557; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DN0MfU7K2YcmEnj4mlWsC064H5qMDpunqVD/Fkiafjs=; b=gicWj12iu0Kmz4XdxEJkWYJidkXm/x8iR/T5Dk4K6OANI8MRlsDbiYvR YwlftlDnjaP6NQQLXLfB2L6NhVENCR6OFcQdA0w/z4KRvPsggznXzESPV 8LOZWP4VondWuQkFMusuLWWpGYkDpl16kefBsSgR/8XjOnj08c40TMvaF Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBABb6iBW/xbLJq1exDuDRoJYAoIBAQEBAQEBgQuEJwEBBDhAEQsOCgkWBAsJAwIBAgFFBgEMCAEBiCrDQwEBAQEBAQEBAQEBAQEBAQEchnaEfoRCUoQuAQSWHY0bgViHO4o1iEhjgkSBQD2GGgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,688,1437436800"; d="scan'208";a="607640923"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Oct 2015 12:19:15 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GCJFCa001411; Fri, 16 Oct 2015 12:19:15 GMT
To: Kent Watsen , Gert Grammel , "netmod@ietf.org" 
References: <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <20151015215927.GC72419@elstar.local>
From: Robert Wilton 
Message-ID: <5620EB35.9090607@cisco.com>
Date: Fri, 16 Oct 2015 13:19:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151015215927.GC72419@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 12:19:19 -0000

Hi Juergen,

On 15/10/2015 22:59, Juergen Schoenwaelder wrote:
> On Thu, Oct 15, 2015 at 05:03:33PM +0000, Kent Watsen wrote:
>> These terms were edited on today's call, resulting in the following text:
>>
>>      Synchronous configuration operation - A configuration request to update
>>      the running configuration of a server that is applied synchronously with
>>      respect to the client request.  The server MUST fully attempt to apply
>>      the configuration change to all impacted components in the server,
>>      updating both the server's intended and applied configuration (see terms),
>>      before replying to the client.  This may be transactional or non-
>>      transactional (need terms!).  The transactionality of the operation
>>      may be a server property or specified on as a property.
> I do not understand the transactionality blurb. What is it and why is
> it relevant? (The last sentence above also seems incomplete.)

It was added in the meeting because some interpretations of the text 
assumed that the text implied that the server would always 
rollback-on-error, so the proposed text was intended to clarify that.

However, I think that this clarification applies equally to both sync 
and async operations and hence I have proposed (on a separate thread) 
that it be documented as part of the requirement 3 "Support for both 
synchronous and asynchronous configuration operations" instead.

Thanks,
Rob


From nobody Fri Oct 16 05:23:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A9D1A8ADE for ; Fri, 16 Oct 2015 05:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2qh3b1kGbGy for ; Fri, 16 Oct 2015 05:23:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F56E1A892B for ; Fri, 16 Oct 2015 05:23:17 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 20D541AE0478; Fri, 16 Oct 2015 14:23:16 +0200 (CEST)
Date: Fri, 16 Oct 2015 14:23:15 +0200 (CEST)
Message-Id: <20151016.142315.2294973158906063871.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5620E9B3.60009@cisco.com>
References:   <5620E9B3.60009@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 12:23:19 -0000

Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBLZW50LA0KPiAN
Cj4gSGVyZSBpcyBteSBhdHRlbXB0IGF0IHdvcmQgc21pdGhpbmcgc2VjdGlvbiAzOg0KPiANCj4g
VGhlIG9sZCBEIGFuZCBFIGhhdmUgYmVlbiBtZXJnZWQgdG9nZXRoZXIgKG5vdyBsYWJlbGxlZCBh
cyBDKS4gIEEgbmV3DQo+IEQgaGFzIGJlZW4gYWRkZWQgdG8gdHJ5IGFuZCBkZWZpbmUgdHJhbnNh
Y3Rpb25hbCBlcnJvciBoYW5kbGluZw0KPiBzZW1hbnRpY3Mgd2l0aG91dCBpbnRyb2R1Y2luZyB0
aGUgdGVybSB0cmFuc2FjdGlvbmFsLg0KPiANCj4gDQo+ICAgIDMuICBTdXBwb3J0IGZvciBib3Ro
IHN5bmNocm9ub3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbg0KPiAgICAgICAgb3Bl
cmF0aW9ucw0KPiANCj4gICAgICAgIEEuIEEgc2VydmVyIG1heSBjaG9vc2UgdG8gc3VwcG9ydCBv
bmx5IHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCj4gICAgICAgICAgIG9wZXJhdGlvbnMsIG9y
IG9ubHkgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgb3INCj4gICAgICAg
ICAgIGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJh
dGlvbnMgaW4NCj4gICAgICAgICAgIGEgY2xpZW50IHNwZWNpZmllZCBwZXItb3BlcmF0aW9uIGJh
c2lzLg0KDQpJIHRoaW5rIHRoZSBtb3N0IGNvbW1vbiBtb2RlICp0b2RheSogaXMgYSBtaXggb2Yg
c3luYy9hc3luYywgb24gYQ0KcGVyLW9iamVjdCBiYXNpcy4gIElzIHRoaXMgbW9kZSBubyBsb25n
ZXIgdmFsaWQ/DQoNCj4gICAgICAgIEIuIFN1cHBvcnQgZm9yIHN5bmNocm9ub3VzIG9wZXJhdGlv
bnMgYXMgcGVyIHRoZSBkZWZpbml0aW9uIG9mDQo+ICAgICAgICAgICAic3luY2hyb25vdXMgY29u
ZmlndXJhdGlvbiBvcGVyYXRpb24iLg0KDQpEb2Vzbid0IHRoaXMgZm9sbG93IGZyb20gQT8NCg0K
PiAgICAgICAgQy4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIG9wZXJhdGlvbnMgYXMgcGVyIHRo
ZSBkZWZpbml0aW9uIG9mDQo+ICAgICAgICAgICAiYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24g
b3BlcmF0aW9uIi4gIFNlcnZlcnMgdGhhdCBzdXBwb3J0DQo+ICAgICAgICAgICBhc3luY2hyb25v
dXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIE1BWSBhbHNvIHByb3ZpZGUgYQ0KPiAgICAgICAg
ICAgdmVyaWZ5IG9wZXJhdGlvbiB0aGF0IGEgY2xpZW50IGNhbiByZXF1ZXN0IGZyb20gdGhlIHNl
cnZlciB0bw0KPiAgICAgICAgICAgcmV0dXJuIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZGlm
ZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KPiAgICAgICAgICAgaW50ZW5kZWQgYW5kIGFwcGxpZWQgY29u
ZmlndXJhdGlvbnMuDQo+IA0KPiAgICAgICAgRC4gU3VwcG9ydCBmb3IgYmVzdCBlZmZvcnQgYW5k
IHJvbGxiYWNrLW9uLWVycm9yIGVycm9yIGhhbmRsaW5nDQo+ICAgICAgICAgICBzZW1hbnRpY3Mu
ICBUaGUgY29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3IgZGVmYXVsdCBzZXJ2ZXINCj4gICAgICAg
ICAgIGJlaGF2aW9yLCBNVVNUIHNwZWNpZnkgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBh
cHBsaWVkDQo+ICAgICAgICAgICBpbiBhIGJlc3QgZWZmb3J0IGZhc2hpb24sIG9yIHVzaW5nICJy
b2xsYmFjayBvbiBlcnJvciINCj4gICAgICAgICAgIHNlbWFudGljcyAtIHdoZXJlIGFsbCBjb25m
aWd1cmF0aW9uIGNoYW5nZXMgaW4gdGhlIHJlcXVlc3QgYXJlDQo+ICAgICAgICAgICB1bmRvbmUg
aWYgcHJvY2Vzc2luZyBvZiBhbnkgcGFydCBvZiB0aGUgY29uZmlndXJhdGlvbiB1cGRhdGUNCj4g
ICAgICAgICAgIGZhaWxlZC4gIEEgY29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3Igc2VydmVyLCBT
SE9VTEQgcHJvdmlkZQ0KPiAgICAgICAgICAgc3VwcG9ydCBmb3Igcm9sbGJhY2stb24tZXJyb3Ig
YmVoYXZpb3IgYW5kIE1BWSBjaG9vc2UgdG8NCj4gICAgICAgICAgIHByb3ZpZGUgc3VwcG9ydCBm
b3IgYmVzdCBlZmZvcnQgc2VtYW50aWNzIGFzIHdlbGwuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+
IEFueSBjb21tZW50cz8NCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4gT24gMTUvMTAv
MjAxNSAxODozMiwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4gQWdhaW4sIHdpdGggYmV0dGVyIGZv
cm1hdHRpbmcgZm9yIHRoZSBsaXN0Og0KPiA+DQo+ID4gICAgIDMuICBTdXBwb3J0IGZvciBib3Ro
IHN5bmNocm9ub3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbg0KPiA+ICAgICAgICAg
b3BlcmF0aW9ucyAoc2VlIHRlcm1zKQ0KPiA+DQo+ID4gICAgICAgICBBLiBBIHNlcnZlciBtYXkg
b25seSBzdXBwb3J0IHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCj4gPiAgICAgICAgICAgIG9w
ZXJhdGlvbnMsIG9yIG1heSBvbmx5IHN1cHBvcnQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24N
Cj4gPiAgICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG1heSBzdXBwb3J0IHN5bmNocm9uaWNpdHkg
dG8gYmUgY2xpZW50DQo+ID4gICAgICAgICAgICBzcGVjaWZpZWQgb24gYSBwZXItb3BlcmF0aW9u
IGJhc2lzLg0KPiA+DQo+ID4NCj4gPiAgICAgICAgIEMuIFN1cHBvcnQgZm9yIHN5bmNocm9ub3Vz
IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucw0KPiA+ICAgICAgICAgICAgcmVxdWlyZXMgdGhlIHNl
cnZlciB0byBibG9jayBzZW5kaW5nIGEgcmVzcG9uc2UgdG8NCj4gPiAgICAgICAgICAgIHRoZSBj
bGllbnQgdW50aWwgaXQgaXMgYWJsZSB0byBhYmxlIHRvIGRldGVybWluZSB3aGV0aGVyDQo+ID4g
ICAgICAgICAgICB0aGVyZSBhcmUgYW55IGVycm9ycyBpbiB0aGUgcmVxdWVzdCBvciBlcnJvcnMg
ZnJvbQ0KPiA+ICAgICAgICAgICAgYXBwbHlpbmcgdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdlLg0K
PiA+ICAgICAgICAgICAgICBELiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgY29uZmlndXJhdGlv
biBvcGVyYXRpb25zDQo+ID4gICAgICAgICAgICByZXF1aXJlcyB0aGUgc2VydmVyIHRvIHNlbmQg
YSByZXNwb25zZSB0byB0aGUgY2xpZW50DQo+ID4gICAgICAgICAgICBpbW1lZGlhdGVseSBpbmRp
Y2F0ZWQgdGhhdCB0aGUgcmVxdWVzdCB3YXMgYWNjZXB0ZWQNCj4gPiAgICAgICAgICAgIGFuZCBz
ZW5kIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBjbGllbnQgd2hlbiB0aGUgaW50ZW5kZWQNCj4gPiAg
ICAgICAgICAgIGNvbmZpZyBpcyBmdWxseSBlZmZlY3RpdmUgb3IgdGhlcmUgYXJlIGFueSBlcnJv
cnMgZnJvbQ0KPiA+ICAgICAgICAgICAgYXBwbHlpbmcgdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdl
Lg0KPiA+DQo+ID4gICAgICAgICBFLiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgY29uZmlndXJh
dGlvbiBvcGVyYXRpb25zIE1BWQ0KPiA+ICAgICAgICAgICAgYWxzbyBwcm92aWRlIGEgdmVyaWZ5
IG9wZXJhdGlvbiB3aGljaCBhIGNsaWVudCBjYW4gcmVxdWVzdA0KPiA+ICAgICAgICAgICAgZnJv
bSB0aGUgc2VydmVyIHRvIG9idGFpbiBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlDQo+ID4gICAg
ICAgICAgICBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZp
Z3VyYXRpb25zLg0KPiA+DQo+ID4NCj4gPiBLZW50DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gMTAv
MTUvMTUsIDE6MjIgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3Rl
Og0KPiA+DQo+ID4+IFJlcXVpcmVtZW50ICMzIHdhcyBkaXNjdXNzZWQgb24gdG9kYXkncyBjYWxs
LiAgV2UgYWdyZWVkIHRvIHJlbW92ZSB0aGUNCj4gPj4gd29yZHMgImRpc3RyaWJ1dGVkIiBhbmQg
InRyYW5zYWN0aW9uYWwiIGFuZCB0byByZXdvcmQgaXQgaW4gdGVybXMgb2YNCj4gPj4gImNvbmZp
Z3VyYXRpb24gb3BlcmF0aW9ucyIuICBUaGUgcmVzdWx0aW5nIHRleHQgZm9sbG93czoNCj4gPj4N
Cj4gPj4NCj4gPj4gICAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5j
aHJvbm91cyBjb25maWd1cmF0aW9uDQo+ID4+IG9wZXJhdGlvbnMgKHNlZSB0ZXJtcykNCj4gPj4N
Cj4gPj4gICAgICAgIEEuIEEgc2VydmVyIG1heSBvbmx5IHN1cHBvcnQgc3luY2hyb25vdXMgY29u
ZmlndXJhdGlvbiBvcGVyYXRpb25zLA0KPiA+PiBvciBtYXkgb25seSBzdXBwb3J0DQo+ID4+ICAg
ICAgICAgICBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLCBvciBtYXkgc3Vw
cG9ydA0KPiA+PiBzeW5jaHJvbmljaXR5IHRvIGJlIGNsaWVudA0KPiA+PiAgICAgICAgICAgc3Bl
Y2lmaWVkIG9uIGEgcGVyLW9wZXJhdGlvbiBiYXNpcy4NCj4gPj4NCj4gPj4NCj4gPj4gICAgICAg
IEMuIFN1cHBvcnQgZm9yIHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyByZXF1
aXJlcyB0aGUNCj4gPj4gc2VydmVyIHRvIGJsb2NrDQo+ID4+ICAgICAgICAgICBzZW5kaW5nIGEg
cmVzcG9uc2UgdG8gdGhlIGNsaWVudCB1bnRpbCBpdCBpcyBhYmxlIHRvIGFibGUgdG8NCj4gPj4g
ZGV0ZXJtaW5lIHdoZXRoZXINCj4gPj4gICAgICAgICAgIHRoZXJlIGFyZSBhbnkgZXJyb3JzIGlu
IHRoZSByZXF1ZXN0IG9yIGVycm9ycyBmcm9tIGFwcGx5aW5nIHRoZQ0KPiA+PiBjb25maWd1cmF0
aW9uDQo+ID4+ICAgICAgICAgICBjaGFuZ2UuDQo+ID4+ICAgICAgICAgICAgRC4gU3VwcG9ydCBm
b3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyByZXF1aXJlcw0KPiA+PiAg
ICAgICAgICAgIHRoZQ0KPiA+PiBzZXJ2ZXIgdG8gc2VuZA0KPiA+PiAgICAgICAgICAgYSByZXNw
b25zZSB0byB0aGUgY2xpZW50IGltbWVkaWF0ZWx5IGluZGljYXRlZCB0aGF0IHRoZSByZXF1ZXN0
DQo+ID4+IHdhcyBhY2NlcHRlZA0KPiA+PiAgICAgICAgICAgYW5kIHNlbmQgYSBub3RpZmljYXRp
b24gdG8gdGhlIGNsaWVudCB3aGVuIHRoZSBpbnRlbmRlZCBjb25maWcNCj4gPj4gaXMgZnVsbHkN
Cj4gPj4gICAgICAgICAgIGVmZmVjdGl2ZSBvciB0aGVyZSBhcmUgYW55IGVycm9ycyBmcm9tIGFw
cGx5aW5nIHRoZQ0KPiA+PiBjb25maWd1cmF0aW9uIGNoYW5nZS4NCj4gPj4NCj4gPj4gICAgICAg
IEUuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgTUFZ
IGFsc28NCj4gPj4gcHJvdmlkZSBhIHZlcmlmeQ0KPiA+PiAgICAgICAgICAgb3BlcmF0aW9uIHdo
aWNoIGEgY2xpZW50IGNhbiByZXF1ZXN0IGZyb20gdGhlIHNlcnZlciB0byBvYnRhaW4NCj4gPj4g
aW5mb3JtYXRpb24NCj4gPj4gICAgICAgICAgIHJlZ2FyZGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3
ZWVuIHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZA0KPiA+PiBjb25maWd1cmF0aW9ucy4NCj4gPj4N
Cj4gPj4NCj4gPj4NCj4gPj4gV2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIGFib3ZlLCBidXQgd2Fu
dGVkIHRvIHJld3JpdGUgaXQgcmVseWluZyBtb3JlDQo+ID4+IG9uDQo+ID4+IHRoZSB0ZXJtcyBm
cm9tIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLCBhbmQgYWxzbyBwb3RlbnRpYWxseSBtZXJnZSBF
DQo+ID4+IGludG8NCj4gPj4gRC4NCj4gPj4NCj4gPj4gQW55Ym9keSB3YW50IHRvIHRha2UgYSBz
dGFiIGF0IGl0Pw0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+IEtlbnQNCj4gPj4NCj4gPj4NCj4g
Pj4NCj4gPj4gT24gMTAvMTQvMTUsIDg6MDAgUE0sICJOYWRlYXUgVGhvbWFzIiA8dG5hZGVhdUBs
dWNpZHZpc2lvbi5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4+IE9uIE9jdCAxNCwgMjAxNTo3OjUx
IFBNLCBhdCA3OjUxIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCj4gPj4+
PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiA5LzI4LzE1LCAxOjQw
IEFNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPiA+Pj4+IDxqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+IE9uIFdlZCwgU2VwIDIz
LCAyMDE1IGF0IDAzOjAzOjU3UE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiA+Pj4+Pj4g
UG9wcGluZyB0aGUgc3RhY2sgb24gdGhpcyBpc3N1ZSwgdGhlIGlzc3VlIHJlbWFpbnMgYXMgdG8g
d2hhdCB0byBkbw0KPiA+Pj4+Pj4gd2l0aCByZXF1aXJlbWVudCAzOg0KPiA+Pj4+Pj4NCj4gPj4+
Pj4+ICAgIDMuICBTdXBwb3J0IGZvciBib3RoIHRyYW5zYWN0aW9uYWwsIHN5bmNocm9ub3VzIG1h
bmFnZW1lbnQgc3lzdGVtcw0KPiA+Pj4+Pj4gICAgICAgICBhcyB3ZWxsIGFzIGRpc3RyaWJ1dGVk
LCBhc3luY2hyb25vdXMgbWFuYWdlbWVudCBzeXN0ZW1zDQo+ID4+Pj4+Pg0KPiA+Pj4+PiBJIGZh
aWwgdG8gdW5kZXJzdGFuZCAndHJhbnNhY3Rpb25hbCcgYW5kICdkaXN0cmlidXRlZCcgaGVyZS4N
Cj4gPj4+PiBJIGhvcGUgdGhhdCB0aGVzZSB0ZXJtcyB3aWxsIGJlIGNsYXJpZmllZCBvbiB0b21v
cnJvdydzIGNhbGwuICAgVGhlcmUNCj4gPj4+PiBpcw0KPiA+Pj4+IGFsc28gYSBjaGFuY2UgdGhh
dCB0aGVzZSB0ZXJtcyB3aWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgdGV4dA0KPiA+Pj4+IGFsdG9n
ZXRoZXIsDQo+ID4+Pj4gYXMgdGhleSBtYXkgYmUgdmlld2VkIGFzIHVubmVjZXNzYXJpbHkgcXVh
bGlmeSB0aGUNCj4gPj4+PiBzeW5jaHJvbm91cy9hc3luY2hyb25vdXMgdGVybXMuDQo+ID4+Pj4N
Cj4gPj4+Pg0KPiA+Pj4+PiBBbmQNCj4gPj4+Pj4gZnJhbmtseSwgSSBhbSBub3Qgc3VyZSB3aHkg
dGhlIG1hbmFnZW1lbnQgX3N5c3RlbXNfIGFyZSBjbGFzc2lmaWVkIHRvDQo+ID4+Pj4+IGJlIHN5
bmNocm9ub3VzIG9yIGFzeW5jaHJvbm91cyAtIEkgdGhpbmsgd2UgYXJlIHRhbGtpbmcgYWJvdXQN
Cj4gPj4+Pj4gcHJvdG9jb2xzIGJldHdlZW4gYSBtYW5hZ2VtZW50IHN5c3RlbSBhbmQgYSBkZXZp
Y2UuDQo+ID4+Pj4NCj4gPj4+PiBBeWUsIEkgZGlkbid0IHNlZSB0aGF0IGJlZm9yZS4NCj4gPj4+
Pg0KPiA+Pj4+IEZpcnN0IG9mZiwgZWxzZXdoZXJlIGluIHRoZSBkcmFmdCB0aGUgdGVybSAic3lz
dGVtIiBpcyB1c2VkIDcgdGltZXMgdG8NCj4gPj4+PiByZWZlciB0byB0aGUgZGV2aWNlIChlLmcu
LCBOQy9SQyBzZXJ2ZXIpLiAgVGhlIHRlcm0gInN5c3RlbSIgaXMNCj4gPj4+PiBvdGhlcndpc2UN
Cj4gPj4+PiBub3QgZGVmaW5lZC4NCj4gPj4+Pg0KPiA+Pj4+IEJ1dCB0byB5b3VyIG1haW4gcG9p
bnQsIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoZSB0ZXJtcw0KPiA+Pj4+IGEvc3luY2hyb25v
dXMNCj4gPj4+PiB0bw0KPiA+Pj4+IGhhdmUgdG8gZG8gd2l0aCBpbnRlcm5hbCBzZXJ2ZXIgcHJv
Y2Vzc2luZyBvZiBhbiBlZGl0IHJlcXVlc3QsIGJ1dCBpbg0KPiA+Pj4+ICczJw0KPiA+Pj4+IHRo
ZSB0ZXJtcyBhcmUgYmVpbmcgdXNlZCB0byBxdWFsaWZ5IGEgbWFuYWdlbWVudCBzeXN0ZW0sIHdo
aWNoIGNhbid0DQo+ID4+Pj4gYmUNCj4gPj4+PiByaWdodC4gIEkgdGhpbmsgdGhhdCAnMycgc2hv
dWxkIGJlIHJld3JpdHRlbiB0byBiZSBhIHN0YXRlbWVudCBhYm91dA0KPiA+Pj4+IGRldmljZXMs
IG5vdCBhIHN0YXRlbWVudCBhYm91dCBtYW5hZ2VtZW50IHN5c3RlbXMuDQo+ID4+PiAJSXQgbWln
aHQgYmUgYmV0dGVyIHRvIGZyYW1lIHRoaXMgaW4gdGVybXMgb2YgYSBjbGllbnQgYW5kIGENCj4g
Pj4+IHNlcnZlci4NCj4gPj4+DQo+ID4+PiAJ4oC5VG9tDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBB
bnl3YXksIEkgYW0gbm90IHN1cmUgMy4gaXMgcHJvcGVybHkgd29yZGVkIHVudGlsIHNvbWVvbmUg
ZGVmaW5lcw0KPiA+Pj4+PiAndHJhbnNhY3Rpb25hbCcsICdkaXN0cmlidXRlZCcsICdzeW5jaHJv
bm91cyBtYW5hZ2VtZW50IHN5c3RlbXMnIGFuZA0KPiA+Pj4+PiAnYXN5bmNocm9ub3VzIG1hbmFn
ZW1lbnQgc3lzdGVtcycuDQo+ID4+Pj4gVGhlIGFnZW5kYSBmb3IgdG9tb3Jyb3cncyBpbnRlcmlt
ISAgOikNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gS2VudA0KPiA+Pj4+DQo+ID4+Pj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBuZXRtb2Qg
bWFpbGluZyBsaXN0DQo+ID4+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K
PiA+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcN
Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCg==


From nobody Fri Oct 16 05:52:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1B51ACEBF for ; Fri, 16 Oct 2015 05:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJmyfOj8SKcH for ; Fri, 16 Oct 2015 05:52:10 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749F81A00E3 for ; Fri, 16 Oct 2015 05:52:10 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-04-5620f2f8f3a8
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.05.29154.8F2F0265; Fri, 16 Oct 2015 14:52:08 +0200 (CEST)
Received: from [159.107.197.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.248.2; Fri, 16 Oct 2015 14:52:07 +0200
To: Martin Bjorklund 
References: <561FC736.6030903@ericsson.com>  <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <5620F2F7.30105@ericsson.com>
Date: Fri, 16 Oct 2015 14:52:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151016.140143.1643639652175921028.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje6PTwphBkcPqFg8ODKL3aK7+xm7 xfyLjawOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujF/vMgv+sFR8ffaYuYHx KXMXIyeHhICJxLd1F1kgbDGJC/fWs3UxcnEICRxllNjedJsRwlnLKPGzdTsrSJWwgLHEsfWt YB0iAqoST3auZYEoOs0ocXT/EbCxzALaEst/nABrYBMwkpjafx6oiIODV0BTovu0NEiYBaj3 94JOsHJRgRiJ95tWMYLYvAKCEidnPgEr5xRwlNjwtxbEZBawl3iwtQxiuLzE9rdzwDqFBDQk Hl74yzqBUXAWkuZZCB2zkHQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYvAe3/Lba wXjwueMhRgEORiUeXoUohTAh1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTCq/GUXTZ2m/CAjoeZOodnZc0u/bw97Wi1YvWVLx57E//rSwYYXm8vfvvzS++RN WUnnE7fg2Uonmz2ZktRb7ee8FLiz1ZzBNKdXWVPB9bykV2GsfsJj24XHVpx21giYYrRBXu/T 4qRfPjqX/AMu861mbYrwtYpTuqZToNO3//azCP/vvOv+HFJiKc5INNRiLipOBAD5eH1APwIA AA==
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 12:52:12 -0000

Hello,
AFAIK the document order in edit-config was not seen as important till 
today, with the single exception :
- user-ordered list/leaf-list
Making it significant now would be a new concept. I don't want that. It 
makes it more difficult to make a correct edit-config.
So Scenario B(2) and C should have the same result.
regards Balazs


On 2015-10-16 14:01, Martin Bjorklund wrote:
> Scenario C  (same as 2, but different order in edit-config)

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


From nobody Fri Oct 16 05:58:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1801AD072 for ; Fri, 16 Oct 2015 05:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQjEbuxrdVJs for ; Fri, 16 Oct 2015 05:58:38 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7FD1ACE5F for ; Fri, 16 Oct 2015 05:58:37 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 12:58:35 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 12:58:35 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAMwIA=
Date: Fri, 16 Oct 2015 12:58:34 +0000
Message-ID: 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local>  <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com>   <5620E9B3.60009@cisco.com>
In-Reply-To: <5620E9B3.60009@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.96.219]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:6MNp7csCHx5m73gDtPJ4pv5++nDcNzgpevNMwquAGetU+nIZLZdnu6d5rs95WazulAkOSWMSttzwrkcTn5+VGPxPDyZy4xEEeM3DEyIa2aE0T0KB2osZETdUby/fHsqd+ApAjvHjkY6MUknyPuQ8XA==; 24:NvmpVFf+XgJZGpMhzan4uWBuoxsVNBE8Ne4jHNHj0S76tCAIw0wbmRp8M/e/kcNAOQyJdfZZ7fJ/ql9k/z4EijXmZIzI+bSQ485zCgouJZo=; 20:CqxljFChWyXKhIyYgvysHLRjcYPSKYIQquNwqqcAu2CM0vU/m+3kwygN1t70PPLghiqhcxcU4Efgc+Cn6ICWdg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(52314003)(189002)(479174004)(377454003)(164054003)(51444003)(57704003)(199003)(106116001)(40100003)(81156007)(76176999)(5007970100001)(93886004)(64706001)(50986999)(105586002)(54356999)(86362001)(5008740100001)(10400500002)(189998001)(110136002)(36756003)(122556002)(19617315012)(15975445007)(5001960100002)(5004730100002)(16236675004)(99286002)(19580395003)(11100500001)(101416001)(102836002)(5001920100001)(66066001)(106356001)(97736004)(2900100001)(2950100001)(87936001)(82746002)(19580405001)(5002640100001)(46102003)(551934003)(92566002)(33656002)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BFE1544F104941A6830CED548FE1B945junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 12:58:34.2493 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 12:58:42 -0000

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

SGkgUm9iLA0KDQpUaGUgdGV4dCBsb29rcyBnb29kLiBXaXRoIHJlc3BlY3QgdG8gRCB3ZSBwcm9i
YWJseSBuZWVkIG1vcmUgd29yZHNtaXRoaW5nOg0KDQogRC4gU3VwcG9ydCBmb3IgYmVzdCBlZmZv
cnQgYW5kIHJvbGxiYWNrLW9uLWVycm9yIGVycm9yIGhhbmRsaW5nDQogICAgICAgICAgc2VtYW50
aWNzLiAgVGhlIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wsIG9yIGRlZmF1bHQgc2VydmVyDQogICAg
ICAgICAgYmVoYXZpb3IsIE1VU1Qgc3BlY2lmeSB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlz
IGFwcGxpZWQNCiAgICAgICAgICBpbiBhIGJlc3QgZWZmb3J0IGZhc2hpb24sIG9yIHVzaW5nICJy
b2xsYmFjayBvbiBlcnJvciINCiAgICAgICAgICBzZW1hbnRpY3MgLSB3aGVyZSBhbGwgY29uZmln
dXJhdGlvbiBjaGFuZ2VzIGluIHRoZSByZXF1ZXN0IGFyZQ0KICAgICAgICAgIHVuZG9uZSBpZiBw
cm9jZXNzaW5nIG9mIGFueSBwYXJ0IG9mIHRoZSBjb25maWd1cmF0aW9uIHVwZGF0ZQ0KICAgICAg
ICAgIGZhaWxlZC4NCi0tPiBob3cgd291bGQgdGhlIGNsaWVudCBrbm93IHRoYXQgYSBjZXJ0YWlu
IG9wZXJhdGlvbiBpcyBzdXBwb3J0ZWQgaW4gYW4gYXRvbWljIG9yIG5vbi1hdG9taWMgbWFubmVy
IGJ5IHRoZSBzZXJ2ZXIuIEluIG15IHZpZXcgdGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoZSBjbGll
bnQgYXNzdW1lcyBiZXN0IGVmZm9ydCBhbmQgdGhlIHNlcnZlciBpcyBhbGxvd2VkIHRvIGRvIGJl
dHRlci4NCkhlbmNlIG5vIG5lZWQgZm9yIGEgTVVTVC4NCg0KDQpBIGNvbmZpZ3VyYXRpb24gcHJv
dG9jb2wsIG9yIHNlcnZlciwgU0hPVUxEIHByb3ZpZGUNCiAgICAgICAgICBzdXBwb3J0IGZvciBy
b2xsYmFjay1vbi1lcnJvciBiZWhhdmlvciBhbmQgTUFZIGNob29zZSB0bw0KICAgICAgICAgIHBy
b3ZpZGUgc3VwcG9ydCBmb3IgYmVzdCBlZmZvcnQgc2VtYW50aWNzIGFzIHdlbGwuDQoNCldvbmRl
cmluZyBob3cgbXVjaCB3ZSBuZWVkIGhlcmUuIEFzc3VtaW5nIHRoZSBzZXJ2ZXIgc3VwcG9ydHMg
cm9sbGJhY2ssIHRoZW4gZG8gd2UgbmVlZCBwcm90b2NvbCBleHRlbnNpb25zIGZvciB0aGF0Pw0K
QXNzdW1pbmcgdGhlIHNlcnZlciBkb2Vzbid0IHN1cHBvcnQgcm9sbGJhY2suIFRoZW4gZG8gd2Ug
bmVlZCBhbnl0aGluZyBzcGVjaWFsIGluIHRoZSBwcm90b2NvbCB0byByZS1jb25maWd1cmUgdGhl
IGNvbmZpZyB0byBlbXVsYXRlIHNvbWV0aGluZyBsaWtlIGEgcm9sbGJhY2s/DQoNCk15IHBvaW50
IGlzOiBnaXZlbiB0aGF0IHRyYW5zYWN0aW9uIGlzIGEgcmVxdWlyZW1lbnQsIHdvdWxkIHdlIG5l
ZWQgdG8gcmVxdWlyZSBoZXJlIGFueXRoaW5nIG1vcmUgdGhhdCBpcyBub3QgYSBjb25zZXF1ZW5j
ZT8NCg0KUGVyaGFwcyBpdCBpcyBiZXR0ZXIgdG8gbGltaXQgb3IgZXZlbiBhdm9pZCB0ZXh0IGFi
b3V0IHRyYW5zYWN0aW9ucyBhbmQganVzdCBkZWZpbmUgdGhlIHN0YXRlIG9mIHRoZSBhcHBsaWVk
IGNvbmZpZyBhZnRlciBlcnJvci4gSSBzZWUgMyBjYXNlcyBzbyBmYXI6DQoxKSBhdG9taWM6IGFm
dGVyIGVycm9yIHRoZSBhcHBsaWVkIGNvbmZpZyBpcyBpZGVudGljYWwgdG8gdGhlIGNvbmZpZyBi
ZWZvcmUgdGhlIGVycm9yDQoyKSBzZXF1ZW5jZTogaWYgdGhlIGNvbmZpZyBpcyBhcHBsaWVkIGlu
IGEgc2VxdWVuY2UgYW5kIGEgc3BlY2lmaWMgbGVhZiBmYWlscywgdGhlIGxlYWZzIHRoYXQgaGF2
ZSBiZWVuIGNvbmZpZ3VyZWQgYmVmb3JlIHdpbGwga2VlcCB0aGUgaW50ZW5kZWQgY29uZmlnLCBs
ZWFmcyBub3QgeWV0IHByb2Nlc3NlZCBrZWVwIHRoZSBhcHBsaWVkIGNvbmZpZyBhbmQgdGhlIGZh
aWxlZCBsZWFmIGlzIHVuZGVmaW5lZA0KMykgYWxsIGxlYWZzIGluIGVycm9yIGFyZSB1bmRlZmlu
ZWQsIGFsbCBlcnJvciBmcmVlIGxlYWZzIHVzZSB0aGUgKG5ldykgaW50ZW5kZWQgY29uZmlnIGFz
IHRoZWlyIGFwcGxpZWQgY29uZmlnLg0KDQpUaG91Z2h0cz8NCg0KR2VydA0KDQpTZW50IGZyb20g
bXkgQXBwbGUgXVsNCg0KT24gMTYgT2N0IDIwMTUsIGF0IDE0OjEzLCBSb2JlcnQgV2lsdG9uIDxy
d2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkg
S2VudCwNCg0KSGVyZSBpcyBteSBhdHRlbXB0IGF0IHdvcmQgc21pdGhpbmcgc2VjdGlvbiAzOg0K
DQpUaGUgb2xkIEQgYW5kIEUgaGF2ZSBiZWVuIG1lcmdlZCB0b2dldGhlciAobm93IGxhYmVsbGVk
IGFzIEMpLiAgQSBuZXcgRCBoYXMgYmVlbiBhZGRlZCB0byB0cnkgYW5kIGRlZmluZSB0cmFuc2Fj
dGlvbmFsIGVycm9yIGhhbmRsaW5nIHNlbWFudGljcyB3aXRob3V0IGludHJvZHVjaW5nIHRoZSB0
ZXJtIHRyYW5zYWN0aW9uYWwuDQoNCg0KICAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25v
dXMgYW5kIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uDQogICAgICAgb3BlcmF0aW9ucw0KDQog
ICAgICAgQS4gQSBzZXJ2ZXIgbWF5IGNob29zZSB0byBzdXBwb3J0IG9ubHkgc3luY2hyb25vdXMg
Y29uZmlndXJhdGlvbg0KICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG9ubHkgYXN5bmNocm9ub3Vz
IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgb3INCiAgICAgICAgICBib3RoIHN5bmNocm9ub3Vz
IGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIGluDQogICAgICAgICAg
YSBjbGllbnQgc3BlY2lmaWVkIHBlci1vcGVyYXRpb24gYmFzaXMuDQoNCiAgICAgICBCLiBTdXBw
b3J0IGZvciBzeW5jaHJvbm91cyBvcGVyYXRpb25zIGFzIHBlciB0aGUgZGVmaW5pdGlvbiBvZg0K
ICAgICAgICAgICJzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbiIuDQoNCiAgICAg
ICBDLiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgb3BlcmF0aW9ucyBhcyBwZXIgdGhlIGRlZmlu
aXRpb24gb2YNCiAgICAgICAgICAiYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9u
Ii4gIFNlcnZlcnMgdGhhdCBzdXBwb3J0DQogICAgICAgICAgYXN5bmNocm9ub3VzIGNvbmZpZ3Vy
YXRpb24gb3BlcmF0aW9ucyBNQVkgYWxzbyBwcm92aWRlIGENCiAgICAgICAgICB2ZXJpZnkgb3Bl
cmF0aW9uIHRoYXQgYSBjbGllbnQgY2FuIHJlcXVlc3QgZnJvbSB0aGUgc2VydmVyIHRvDQogICAg
ICAgICAgcmV0dXJuIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu
IHRoZQ0KICAgICAgICAgIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb25zLg0KDQog
ICAgICAgRC4gU3VwcG9ydCBmb3IgYmVzdCBlZmZvcnQgYW5kIHJvbGxiYWNrLW9uLWVycm9yIGVy
cm9yIGhhbmRsaW5nDQogICAgICAgICAgc2VtYW50aWNzLiAgVGhlIGNvbmZpZ3VyYXRpb24gcHJv
dG9jb2wsIG9yIGRlZmF1bHQgc2VydmVyDQogICAgICAgICAgYmVoYXZpb3IsIE1VU1Qgc3BlY2lm
eSB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlzIGFwcGxpZWQNCiAgICAgICAgICBpbiBhIGJl
c3QgZWZmb3J0IGZhc2hpb24sIG9yIHVzaW5nICJyb2xsYmFjayBvbiBlcnJvciINCiAgICAgICAg
ICBzZW1hbnRpY3MgLSB3aGVyZSBhbGwgY29uZmlndXJhdGlvbiBjaGFuZ2VzIGluIHRoZSByZXF1
ZXN0IGFyZQ0KICAgICAgICAgIHVuZG9uZSBpZiBwcm9jZXNzaW5nIG9mIGFueSBwYXJ0IG9mIHRo
ZSBjb25maWd1cmF0aW9uIHVwZGF0ZQ0KICAgICAgICAgIGZhaWxlZC4gIEEgY29uZmlndXJhdGlv
biBwcm90b2NvbCwgb3Igc2VydmVyLCBTSE9VTEQgcHJvdmlkZQ0KICAgICAgICAgIHN1cHBvcnQg
Zm9yIHJvbGxiYWNrLW9uLWVycm9yIGJlaGF2aW9yIGFuZCBNQVkgY2hvb3NlIHRvDQogICAgICAg
ICAgcHJvdmlkZSBzdXBwb3J0IGZvciBiZXN0IGVmZm9ydCBzZW1hbnRpY3MgYXMgd2VsbC4NCg0K
QW55IGNvbW1lbnRzPw0KDQpUaGFua3MsDQpSb2INCg0KDQpPbiAxNS8xMC8yMDE1IDE4OjMyLCBL
ZW50IFdhdHNlbiB3cm90ZToNCg0KQWdhaW4sIHdpdGggYmV0dGVyIGZvcm1hdHRpbmcgZm9yIHRo
ZSBsaXN0Og0KDQogICAzLiAgU3VwcG9ydCBmb3IgYm90aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNo
cm9ub3VzIGNvbmZpZ3VyYXRpb24NCiAgICAgICBvcGVyYXRpb25zIChzZWUgdGVybXMpDQoNCiAg
ICAgICBBLiBBIHNlcnZlciBtYXkgb25seSBzdXBwb3J0IHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRp
b24NCiAgICAgICAgICBvcGVyYXRpb25zLCBvciBtYXkgb25seSBzdXBwb3J0IGFzeW5jaHJvbm91
cyBjb25maWd1cmF0aW9uDQogICAgICAgICAgb3BlcmF0aW9ucywgb3IgbWF5IHN1cHBvcnQgc3lu
Y2hyb25pY2l0eSB0byBiZSBjbGllbnQNCiAgICAgICAgICBzcGVjaWZpZWQgb24gYSBwZXItb3Bl
cmF0aW9uIGJhc2lzLg0KDQoNCiAgICAgICBDLiBTdXBwb3J0IGZvciBzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uIG9wZXJhdGlvbnMNCiAgICAgICAgICByZXF1aXJlcyB0aGUgc2VydmVyIHRvIGJs
b2NrIHNlbmRpbmcgYSByZXNwb25zZSB0bw0KICAgICAgICAgIHRoZSBjbGllbnQgdW50aWwgaXQg
aXMgYWJsZSB0byBhYmxlIHRvIGRldGVybWluZSB3aGV0aGVyDQogICAgICAgICAgdGhlcmUgYXJl
IGFueSBlcnJvcnMgaW4gdGhlIHJlcXVlc3Qgb3IgZXJyb3JzIGZyb20NCiAgICAgICAgICBhcHBs
eWluZyB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2UuDQoNCiAgICAgICBELiBTdXBwb3J0IGZvciBh
c3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zDQogICAgICAgICAgcmVxdWlyZXMg
dGhlIHNlcnZlciB0byBzZW5kIGEgcmVzcG9uc2UgdG8gdGhlIGNsaWVudA0KICAgICAgICAgIGlt
bWVkaWF0ZWx5IGluZGljYXRlZCB0aGF0IHRoZSByZXF1ZXN0IHdhcyBhY2NlcHRlZA0KICAgICAg
ICAgIGFuZCBzZW5kIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBjbGllbnQgd2hlbiB0aGUgaW50ZW5k
ZWQNCiAgICAgICAgICBjb25maWcgaXMgZnVsbHkgZWZmZWN0aXZlIG9yIHRoZXJlIGFyZSBhbnkg
ZXJyb3JzIGZyb20NCiAgICAgICAgICBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2Uu
DQoNCiAgICAgICBFLiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVy
YXRpb25zIE1BWQ0KICAgICAgICAgIGFsc28gcHJvdmlkZSBhIHZlcmlmeSBvcGVyYXRpb24gd2hp
Y2ggYSBjbGllbnQgY2FuIHJlcXVlc3QNCiAgICAgICAgICBmcm9tIHRoZSBzZXJ2ZXIgdG8gb2J0
YWluIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUNCiAgICAgICAgICBkaWZmZXJlbmNlIGJldHdl
ZW4gdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb25zLg0KDQoNCktlbnQNCg0K
DQoNCk9uIDEwLzE1LzE1LCAxOjIyIFBNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIu
bmV0PjxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCg0KDQpSZXF1aXJlbWVu
dCAjMyB3YXMgZGlzY3Vzc2VkIG9uIHRvZGF5J3MgY2FsbC4gICBXZSBhZ3JlZWQgdG8gcmVtb3Zl
IHRoZQ0Kd29yZHMgImRpc3RyaWJ1dGVkIiBhbmQgInRyYW5zYWN0aW9uYWwiIGFuZCB0byByZXdv
cmQgaXQgaW4gdGVybXMgb2YNCiJjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMiLiAgVGhlIHJlc3Vs
dGluZyB0ZXh0IGZvbGxvd3M6DQoNCg0KICAzLiAgU3VwcG9ydCBmb3IgYm90aCBzeW5jaHJvbm91
cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCm9wZXJhdGlvbnMgKHNlZSB0ZXJtcykN
Cg0KICAgICAgQS4gQSBzZXJ2ZXIgbWF5IG9ubHkgc3VwcG9ydCBzeW5jaHJvbm91cyBjb25maWd1
cmF0aW9uIG9wZXJhdGlvbnMsDQpvciBtYXkgb25seSBzdXBwb3J0DQogICAgICAgICBhc3luY2hy
b25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLCBvciBtYXkgc3VwcG9ydA0Kc3luY2hyb25p
Y2l0eSB0byBiZSBjbGllbnQNCiAgICAgICAgIHNwZWNpZmllZCBvbiBhIHBlci1vcGVyYXRpb24g
YmFzaXMuDQoNCg0KICAgICAgQy4gU3VwcG9ydCBmb3Igc3luY2hyb25vdXMgY29uZmlndXJhdGlv
biBvcGVyYXRpb25zIHJlcXVpcmVzIHRoZQ0Kc2VydmVyIHRvIGJsb2NrDQogICAgICAgICBzZW5k
aW5nIGEgcmVzcG9uc2UgdG8gdGhlIGNsaWVudCB1bnRpbCBpdCBpcyBhYmxlIHRvIGFibGUgdG8N
CmRldGVybWluZSB3aGV0aGVyDQogICAgICAgICB0aGVyZSBhcmUgYW55IGVycm9ycyBpbiB0aGUg
cmVxdWVzdCBvciBlcnJvcnMgZnJvbSBhcHBseWluZyB0aGUNCmNvbmZpZ3VyYXRpb24NCiAgICAg
ICAgIGNoYW5nZS4NCg0KICAgICAgRC4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3Vy
YXRpb24gb3BlcmF0aW9ucyByZXF1aXJlcyB0aGUNCnNlcnZlciB0byBzZW5kDQogICAgICAgICBh
IHJlc3BvbnNlIHRvIHRoZSBjbGllbnQgaW1tZWRpYXRlbHkgaW5kaWNhdGVkIHRoYXQgdGhlIHJl
cXVlc3QNCndhcyBhY2NlcHRlZA0KICAgICAgICAgYW5kIHNlbmQgYSBub3RpZmljYXRpb24gdG8g
dGhlIGNsaWVudCB3aGVuIHRoZSBpbnRlbmRlZCBjb25maWcNCmlzIGZ1bGx5DQogICAgICAgICBl
ZmZlY3RpdmUgb3IgdGhlcmUgYXJlIGFueSBlcnJvcnMgZnJvbSBhcHBseWluZyB0aGUNCmNvbmZp
Z3VyYXRpb24gY2hhbmdlLg0KDQogICAgICBFLiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgY29u
ZmlndXJhdGlvbiBvcGVyYXRpb25zIE1BWSBhbHNvDQpwcm92aWRlIGEgdmVyaWZ5DQogICAgICAg
ICBvcGVyYXRpb24gd2hpY2ggYSBjbGllbnQgY2FuIHJlcXVlc3QgZnJvbSB0aGUgc2VydmVyIHRv
IG9idGFpbg0KaW5mb3JtYXRpb24NCiAgICAgICAgIHJlZ2FyZGluZyB0aGUgZGlmZmVyZW5jZSBi
ZXR3ZWVuIHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZA0KY29uZmlndXJhdGlvbnMuDQoNCg0KDQpX
ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgYWJvdmUsIGJ1dCB3YW50ZWQgdG8gcmV3cml0ZSBpdCBy
ZWx5aW5nIG1vcmUgb24NCnRoZSB0ZXJtcyBmcm9tIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLCBh
bmQgYWxzbyBwb3RlbnRpYWxseSBtZXJnZSBFIGludG8NCkQuDQoNCkFueWJvZHkgd2FudCB0byB0
YWtlIGEgc3RhYiBhdCBpdD8NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KT24gMTAvMTQvMTUsIDg6
MDAgUE0sICJOYWRlYXUgVGhvbWFzIiA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+PG1haWx0bzp0
bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4gd3JvdGU6DQoNCg0KDQpPbiBPY3QgMTQsIDIwMTU6Nzo1
MSBQTSwgYXQgNzo1MSBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+PG1haWx0
bzprd2F0c2VuQGp1bmlwZXIubmV0Pg0Kd3JvdGU6DQoNCg0KDQpPbiA5LzI4LzE1LCAxOjQwIEFN
LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZT48bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3Jv
dGU6DQoNCg0KDQpPbiBXZWQsIFNlcCAyMywgMjAxNSBhdCAwMzowMzo1N1BNICswMDAwLCBLZW50
IFdhdHNlbiB3cm90ZToNCg0KDQpQb3BwaW5nIHRoZSBzdGFjayBvbiB0aGlzIGlzc3VlLCB0aGUg
aXNzdWUgcmVtYWlucyBhcyB0byB3aGF0IHRvIGRvDQp3aXRoIHJlcXVpcmVtZW50IDM6DQoNCiAg
My4gIFN1cHBvcnQgZm9yIGJvdGggdHJhbnNhY3Rpb25hbCwgc3luY2hyb25vdXMgbWFuYWdlbWVu
dCBzeXN0ZW1zDQogICAgICAgYXMgd2VsbCBhcyBkaXN0cmlidXRlZCwgYXN5bmNocm9ub3VzIG1h
bmFnZW1lbnQgc3lzdGVtcw0KDQoNCg0KSSBmYWlsIHRvIHVuZGVyc3RhbmQgJ3RyYW5zYWN0aW9u
YWwnIGFuZCAnZGlzdHJpYnV0ZWQnIGhlcmUuDQoNCg0KSSBob3BlIHRoYXQgdGhlc2UgdGVybXMg
d2lsbCBiZSBjbGFyaWZpZWQgb24gdG9tb3Jyb3cncyBjYWxsLiAgIFRoZXJlDQppcw0KYWxzbyBh
IGNoYW5jZSB0aGF0IHRoZXNlIHRlcm1zIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0DQph
bHRvZ2V0aGVyLA0KYXMgdGhleSBtYXkgYmUgdmlld2VkIGFzIHVubmVjZXNzYXJpbHkgcXVhbGlm
eSB0aGUNCnN5bmNocm9ub3VzL2FzeW5jaHJvbm91cyB0ZXJtcy4NCg0KDQoNCg0KQW5kDQpmcmFu
a2x5LCBJIGFtIG5vdCBzdXJlIHdoeSB0aGUgbWFuYWdlbWVudCBfc3lzdGVtc18gYXJlIGNsYXNz
aWZpZWQgdG8NCmJlIHN5bmNocm9ub3VzIG9yIGFzeW5jaHJvbm91cyAtIEkgdGhpbmsgd2UgYXJl
IHRhbGtpbmcgYWJvdXQNCnByb3RvY29scyBiZXR3ZWVuIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5k
IGEgZGV2aWNlLg0KDQoNCkF5ZSwgSSBkaWRuJ3Qgc2VlIHRoYXQgYmVmb3JlLg0KDQpGaXJzdCBv
ZmYsIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQgdGhlIHRlcm0gInN5c3RlbSIgaXMgdXNlZCA3IHRp
bWVzIHRvDQpyZWZlciB0byB0aGUgZGV2aWNlIChlLmcuLCBOQy9SQyBzZXJ2ZXIpLiAgVGhlIHRl
cm0gInN5c3RlbSIgaXMNCm90aGVyd2lzZQ0Kbm90IGRlZmluZWQuDQoNCkJ1dCB0byB5b3VyIG1h
aW4gcG9pbnQsIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoZSB0ZXJtcyBhL3N5bmNocm9ub3Vz
DQp0bw0KaGF2ZSB0byBkbyB3aXRoIGludGVybmFsIHNlcnZlciBwcm9jZXNzaW5nIG9mIGFuIGVk
aXQgcmVxdWVzdCwgYnV0IGluDQonMycNCnRoZSB0ZXJtcyBhcmUgYmVpbmcgdXNlZCB0byBxdWFs
aWZ5IGEgbWFuYWdlbWVudCBzeXN0ZW0sIHdoaWNoIGNhbid0IGJlDQpyaWdodC4gIEkgdGhpbmsg
dGhhdCAnMycgc2hvdWxkIGJlIHJld3JpdHRlbiB0byBiZSBhIHN0YXRlbWVudCBhYm91dA0KZGV2
aWNlcywgbm90IGEgc3RhdGVtZW50IGFib3V0IG1hbmFnZW1lbnQgc3lzdGVtcy4NCg0KDQogICAg
ICAgIEl0IG1pZ2h0IGJlIGJldHRlciB0byBmcmFtZSB0aGlzIGluIHRlcm1zIG9mIGEgY2xpZW50
IGFuZCBhDQpzZXJ2ZXIuDQoNCiAgICAgICAg4oC5VG9tDQoNCg0KDQoNCkFueXdheSwgSSBhbSBu
b3Qgc3VyZSAzLiBpcyBwcm9wZXJseSB3b3JkZWQgdW50aWwgc29tZW9uZSBkZWZpbmVzDQoNCg0K
J3RyYW5zYWN0aW9uYWwnLCAnZGlzdHJpYnV0ZWQnLCAnc3luY2hyb25vdXMgbWFuYWdlbWVudCBz
eXN0ZW1zJyBhbmQNCidhc3luY2hyb25vdXMgbWFuYWdlbWVudCBzeXN0ZW1zJy4NCg0KDQpUaGUg
YWdlbmRhIGZvciB0b21vcnJvdydzIGludGVyaW0hICA6KQ0KDQoNCktlbnQNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxp
c3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9k
QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkhpIFJvYiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSB0ZXh0IGxvb2tz
IGdvb2QuIFdpdGggcmVzcGVjdCB0byBEIHdlIHByb2JhYmx5IG5lZWQgbW9yZSB3b3Jkc21pdGhp
bmc6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog
cmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPiZuYnNwO0QuIFN1cHBvcnQgZm9yIGJlc3QgZWZmb3J0
IGFuZCByb2xsYmFjay1vbi1lcnJvciBlcnJvciBoYW5kbGluZzxicj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZW1hbnRpY3MuJm5ic3A7
IFRoZSBjb25maWd1cmF0aW9uIHByb3RvY29sLCBvciBkZWZhdWx0IHNlcnZlcjxicj4NCiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZWhhdmlv
ciwgTVVTVCBzcGVjaWZ5IHdoZXRoZXIgdGhlIGNvbmZpZ3VyYXRpb24gaXMgYXBwbGllZDxicj4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp
biBhIGJlc3QgZWZmb3J0IGZhc2hpb24sIG9yIHVzaW5nICZxdW90O3JvbGxiYWNrIG9uIGVycm9y
JnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHNlbWFudGljcyAtIHdoZXJlIGFsbCBjb25maWd1cmF0aW9uIGNoYW5nZXMgaW4g
dGhlIHJlcXVlc3QgYXJlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuZG9uZSBpZiBwcm9jZXNzaW5nIG9mIGFueSBwYXJ0IG9mIHRo
ZSBjb25maWd1cmF0aW9uIHVwZGF0ZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmYWlsZWQuJm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PC9i
bG9ja3F1b3RlPg0KPGRpdj4tLSZndDsgaG93IHdvdWxkIHRoZSBjbGllbnQga25vdyB0aGF0IGEg
Y2VydGFpbiBvcGVyYXRpb24gaXMgc3VwcG9ydGVkIGluIGFuIGF0b21pYyBvciBub24tYXRvbWlj
IG1hbm5lciBieSB0aGUgc2VydmVyLiBJbiBteSB2aWV3IHRoZSBkZWZhdWx0IHNob3VsZCBiZSB0
aGUgY2xpZW50IGFzc3VtZXMgYmVzdCBlZmZvcnQgYW5kIHRoZSBzZXJ2ZXIgaXMgYWxsb3dlZCB0
byBkbyBiZXR0ZXIuPC9kaXY+DQo8ZGl2PkhlbmNlIG5vIG5lZWQgZm9yIGEgTVVTVC4mbmJzcDs8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo
MjU1LCAyNTUsIDI1NSwgMCk7Ij5BIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wsIG9yIHNlcnZlciwg
U0hPVUxEIHByb3ZpZGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgc3VwcG9ydCBmb3Igcm9sbGJhY2stb24tZXJyb3IgYmVoYXZpb3Ig
YW5kIE1BWSBjaG9vc2UgdG88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZSBzdXBwb3J0IGZvciBiZXN0IGVmZm9ydCBzZW1h
bnRpY3MgYXMgd2VsbC48L3NwYW4+PC9mb250PjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+V29uZGVyaW5nIGhvdyBtdWNoIHdlIG5lZWQgaGVyZS4gQXNzdW1p
bmcgdGhlIHNlcnZlciBzdXBwb3J0cyByb2xsYmFjaywgdGhlbiBkbyB3ZSBuZWVkIHByb3RvY29s
IGV4dGVuc2lvbnMgZm9yIHRoYXQ/PC9kaXY+DQo8ZGl2PkFzc3VtaW5nIHRoZSBzZXJ2ZXIgZG9l
c24ndCBzdXBwb3J0IHJvbGxiYWNrLiBUaGVuIGRvIHdlIG5lZWQgYW55dGhpbmcgc3BlY2lhbCBp
biB0aGUgcHJvdG9jb2wgdG8gcmUtY29uZmlndXJlIHRoZSBjb25maWcgdG8gZW11bGF0ZSBzb21l
dGhpbmcgbGlrZSBhIHJvbGxiYWNrPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkg
cG9pbnQgaXM6IGdpdmVuIHRoYXQgdHJhbnNhY3Rpb24gaXMgYSByZXF1aXJlbWVudCwgd291bGQg
d2UgbmVlZCB0byByZXF1aXJlIGhlcmUgYW55dGhpbmcgbW9yZSB0aGF0IGlzIG5vdCBhIGNvbnNl
cXVlbmNlPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGVyaGFwcyBpdCBpcyBiZXR0
ZXIgdG8gbGltaXQgb3IgZXZlbiBhdm9pZCB0ZXh0IGFib3V0IHRyYW5zYWN0aW9ucyBhbmQganVz
dCBkZWZpbmUgdGhlIHN0YXRlIG9mIHRoZSBhcHBsaWVkIGNvbmZpZyBhZnRlciBlcnJvci4gSSBz
ZWUgMyBjYXNlcyBzbyBmYXI6PC9kaXY+DQo8ZGl2PjEpIGF0b21pYzogYWZ0ZXIgZXJyb3IgdGhl
IGFwcGxpZWQgY29uZmlnIGlzIGlkZW50aWNhbCB0byB0aGUgY29uZmlnIGJlZm9yZSB0aGUgZXJy
b3I8L2Rpdj4NCjxkaXY+Mikgc2VxdWVuY2U6IGlmIHRoZSBjb25maWcgaXMgYXBwbGllZCBpbiBh
IHNlcXVlbmNlIGFuZCBhIHNwZWNpZmljIGxlYWYgZmFpbHMsIHRoZSBsZWFmcyB0aGF0IGhhdmUg
YmVlbiBjb25maWd1cmVkIGJlZm9yZSB3aWxsIGtlZXAgdGhlIGludGVuZGVkIGNvbmZpZywgbGVh
ZnMgbm90IHlldCBwcm9jZXNzZWQga2VlcCB0aGUgYXBwbGllZCBjb25maWcgYW5kIHRoZSBmYWls
ZWQgbGVhZiBpcyB1bmRlZmluZWQ8L2Rpdj4NCjxkaXY+MykgYWxsIGxlYWZzIGluIGVycm9yIGFy
ZSB1bmRlZmluZWQsIGFsbCBlcnJvciBmcmVlIGxlYWZzIHVzZSB0aGUgKG5ldykgaW50ZW5kZWQg
Y29uZmlnIGFzIHRoZWlyIGFwcGxpZWQgY29uZmlnLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+VGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5HZXJ0PC9kaXY+
DQo8ZGl2Pjxicj4NCjxkaXY+U2VudCBmcm9tIG15IEFwcGxlIF1bPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KT24gMTYgT2N0IDIwMTUsIGF0IDE0OjEzLCBSb2JlcnQgV2lsdG9uICZsdDs8YSBo
cmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsg
d3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+
SGkgS2VudCw8YnI+DQo8YnI+DQpIZXJlIGlzIG15IGF0dGVtcHQgYXQgd29yZCBzbWl0aGluZyBz
ZWN0aW9uIDM6PGJyPg0KPGJyPg0KVGhlIG9sZCBEIGFuZCBFIGhhdmUgYmVlbiBtZXJnZWQgdG9n
ZXRoZXIgKG5vdyBsYWJlbGxlZCBhcyBDKS4mbmJzcDsgQSBuZXcgRCBoYXMgYmVlbiBhZGRlZCB0
byB0cnkgYW5kIGRlZmluZSB0cmFuc2FjdGlvbmFsIGVycm9yIGhhbmRsaW5nIHNlbWFudGljcyB3
aXRob3V0IGludHJvZHVjaW5nIHRoZSB0ZXJtIHRyYW5zYWN0aW9uYWwuPGJyPg0KPGJyPg0KPGJy
Pg0KPGZvbnQgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Jm5ic3A7Jm5i
c3A7IDMuJm5ic3A7IFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91
cyBjb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IG9wZXJhdGlvbnM8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgQS4gQSBzZXJ2ZXIgbWF5IGNob29zZSB0byBzdXBwb3J0IG9ubHkgc3luY2hyb25vdXMgY29u
ZmlndXJhdGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBvcGVyYXRpb25zLCBvciBvbmx5IGFzeW5jaHJvbm91cyBjb25maWd1cmF0
aW9uIG9wZXJhdGlvbnMsIG9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBj
b25maWd1cmF0aW9uIG9wZXJhdGlvbnMgaW48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBjbGllbnQgc3BlY2lmaWVkIHBlci1vcGVy
YXRpb24gYmFzaXMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEIuIFN1cHBvcnQgZm9yIHN5bmNocm9ub3VzIG9wZXJhdGlvbnMgYXMgcGVyIHRoZSBkZWZp
bml0aW9uIG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZxdW90O3N5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9uJnF1
b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDLiBT
dXBwb3J0IGZvciBhc3luY2hyb25vdXMgb3BlcmF0aW9ucyBhcyBwZXIgdGhlIGRlZmluaXRpb24g
b2Y8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgJnF1b3Q7YXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9uJnF1b3Q7LiZu
YnNwOyBTZXJ2ZXJzIHRoYXQgc3VwcG9ydDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBv
cGVyYXRpb25zIE1BWSBhbHNvIHByb3ZpZGUgYTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2ZXJpZnkgb3BlcmF0aW9uIHRoYXQgYSBj
bGllbnQgY2FuIHJlcXVlc3QgZnJvbSB0aGUgc2VydmVyIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiBpbmZvcm1hdGlv
biByZWdhcmRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGU8YnI+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZW5kZWQgYW5kIGFw
cGxpZWQgY29uZmlndXJhdGlvbnMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IEQuIFN1cHBvcnQgZm9yIGJlc3QgZWZmb3J0IGFuZCByb2xsYmFjay1vbi1l
cnJvciBlcnJvciBoYW5kbGluZzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZW1hbnRpY3MuJm5ic3A7IFRoZSBjb25maWd1cmF0aW9u
IHByb3RvY29sLCBvciBkZWZhdWx0IHNlcnZlcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZWhhdmlvciwgTVVTVCBzcGVjaWZ5IHdo
ZXRoZXIgdGhlIGNvbmZpZ3VyYXRpb24gaXMgYXBwbGllZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBhIGJlc3QgZWZmb3J0IGZh
c2hpb24sIG9yIHVzaW5nICZxdW90O3JvbGxiYWNrIG9uIGVycm9yJnF1b3Q7PGJyPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbWFudGlj
cyAtIHdoZXJlIGFsbCBjb25maWd1cmF0aW9uIGNoYW5nZXMgaW4gdGhlIHJlcXVlc3QgYXJlPGJy
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHVuZG9uZSBpZiBwcm9jZXNzaW5nIG9mIGFueSBwYXJ0IG9mIHRoZSBjb25maWd1cmF0aW9uIHVw
ZGF0ZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBmYWlsZWQuJm5ic3A7IEEgY29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3Igc2VydmVy
LCBTSE9VTEQgcHJvdmlkZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0IGZvciByb2xsYmFjay1vbi1lcnJvciBiZWhhdmlv
ciBhbmQgTUFZIGNob29zZSB0bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlIHN1cHBvcnQgZm9yIGJlc3QgZWZmb3J0IHNl
bWFudGljcyBhcyB3ZWxsLjxicj4NCjxicj4NCjwvZm9udD5BbnkgY29tbWVudHM/PGJyPg0KPGJy
Pg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxicj4NCjxicj4NCjxkaXYgY2xhc3M9Im1vei1jaXRl
LXByZWZpeCI+T24gMTUvMTAvMjAxNSAxODozMiwgS2VudCBXYXRzZW4gd3JvdGU6PGJyPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6RDI0NTVCNEMuRTczMzAlMjVrd2F0c2VuQGp1bmlw
ZXIubmV0IiB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5BZ2Fpbiwgd2l0aCBiZXR0ZXIgZm9y
bWF0dGluZyBmb3IgdGhlIGxpc3Q6DQoNCiAgIDMuICBTdXBwb3J0IGZvciBib3RoIHN5bmNocm9u
b3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbg0KICAgICAgIG9wZXJhdGlvbnMgKHNl
ZSB0ZXJtcykNCg0KICAgICAgIEEuIEEgc2VydmVyIG1heSBvbmx5IHN1cHBvcnQgc3luY2hyb25v
dXMgY29uZmlndXJhdGlvbg0KICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG1heSBvbmx5IHN1cHBv
cnQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgICBvcGVyYXRpb25zLCBvciBt
YXkgc3VwcG9ydCBzeW5jaHJvbmljaXR5IHRvIGJlIGNsaWVudA0KICAgICAgICAgIHNwZWNpZmll
ZCBvbiBhIHBlci1vcGVyYXRpb24gYmFzaXMuDQoNCg0KICAgICAgIEMuIFN1cHBvcnQgZm9yIHN5
bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucw0KICAgICAgICAgIHJlcXVpcmVzIHRo
ZSBzZXJ2ZXIgdG8gYmxvY2sgc2VuZGluZyBhIHJlc3BvbnNlIHRvDQogICAgICAgICAgdGhlIGNs
aWVudCB1bnRpbCBpdCBpcyBhYmxlIHRvIGFibGUgdG8gZGV0ZXJtaW5lIHdoZXRoZXINCiAgICAg
ICAgICB0aGVyZSBhcmUgYW55IGVycm9ycyBpbiB0aGUgcmVxdWVzdCBvciBlcnJvcnMgZnJvbQ0K
ICAgICAgICAgIGFwcGx5aW5nIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZS4NCiAgICANCiAgICAg
ICBELiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zDQog
ICAgICAgICAgcmVxdWlyZXMgdGhlIHNlcnZlciB0byBzZW5kIGEgcmVzcG9uc2UgdG8gdGhlIGNs
aWVudA0KICAgICAgICAgIGltbWVkaWF0ZWx5IGluZGljYXRlZCB0aGF0IHRoZSByZXF1ZXN0IHdh
cyBhY2NlcHRlZA0KICAgICAgICAgIGFuZCBzZW5kIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBjbGll
bnQgd2hlbiB0aGUgaW50ZW5kZWQNCiAgICAgICAgICBjb25maWcgaXMgZnVsbHkgZWZmZWN0aXZl
IG9yIHRoZXJlIGFyZSBhbnkgZXJyb3JzIGZyb20NCiAgICAgICAgICBhcHBseWluZyB0aGUgY29u
ZmlndXJhdGlvbiBjaGFuZ2UuDQoNCiAgICAgICBFLiBTdXBwb3J0IGZvciBhc3luY2hyb25vdXMg
Y29uZmlndXJhdGlvbiBvcGVyYXRpb25zIE1BWQ0KICAgICAgICAgIGFsc28gcHJvdmlkZSBhIHZl
cmlmeSBvcGVyYXRpb24gd2hpY2ggYSBjbGllbnQgY2FuIHJlcXVlc3QNCiAgICAgICAgICBmcm9t
IHRoZSBzZXJ2ZXIgdG8gb2J0YWluIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUNCiAgICAgICAg
ICBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRp
b25zLg0KDQoNCktlbnQNCg0KDQoNCk9uIDEwLzE1LzE1LCAxOjIyIFBNLCAmcXVvdDtLZW50IFdh
dHNlbiZxdW90OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86
a3dhdHNlbkBqdW5pcGVyLm5ldCI+Jmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7PC9hPiB3cm90
ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5SZXF1
aXJlbWVudCAjMyB3YXMgZGlzY3Vzc2VkIG9uIHRvZGF5J3MgY2FsbC4gICBXZSBhZ3JlZWQgdG8g
cmVtb3ZlIHRoZQ0Kd29yZHMgJnF1b3Q7ZGlzdHJpYnV0ZWQmcXVvdDsgYW5kICZxdW90O3RyYW5z
YWN0aW9uYWwmcXVvdDsgYW5kIHRvIHJld29yZCBpdCBpbiB0ZXJtcyBvZg0KJnF1b3Q7Y29uZmln
dXJhdGlvbiBvcGVyYXRpb25zJnF1b3Q7LiAgVGhlIHJlc3VsdGluZyB0ZXh0IGZvbGxvd3M6DQoN
Cg0KICAzLiAgU3VwcG9ydCBmb3IgYm90aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNv
bmZpZ3VyYXRpb24NCm9wZXJhdGlvbnMgKHNlZSB0ZXJtcykNCg0KICAgICAgQS4gQSBzZXJ2ZXIg
bWF5IG9ubHkgc3VwcG9ydCBzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMsDQpv
ciBtYXkgb25seSBzdXBwb3J0DQogICAgICAgICBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBv
cGVyYXRpb25zLCBvciBtYXkgc3VwcG9ydA0Kc3luY2hyb25pY2l0eSB0byBiZSBjbGllbnQNCiAg
ICAgICAgIHNwZWNpZmllZCBvbiBhIHBlci1vcGVyYXRpb24gYmFzaXMuDQoNCg0KICAgICAgQy4g
U3VwcG9ydCBmb3Igc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIHJlcXVpcmVz
IHRoZQ0Kc2VydmVyIHRvIGJsb2NrDQogICAgICAgICBzZW5kaW5nIGEgcmVzcG9uc2UgdG8gdGhl
IGNsaWVudCB1bnRpbCBpdCBpcyBhYmxlIHRvIGFibGUgdG8NCmRldGVybWluZSB3aGV0aGVyDQog
ICAgICAgICB0aGVyZSBhcmUgYW55IGVycm9ycyBpbiB0aGUgcmVxdWVzdCBvciBlcnJvcnMgZnJv
bSBhcHBseWluZyB0aGUNCmNvbmZpZ3VyYXRpb24NCiAgICAgICAgIGNoYW5nZS4NCiAgIA0KICAg
ICAgRC4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBy
ZXF1aXJlcyB0aGUNCnNlcnZlciB0byBzZW5kDQogICAgICAgICBhIHJlc3BvbnNlIHRvIHRoZSBj
bGllbnQgaW1tZWRpYXRlbHkgaW5kaWNhdGVkIHRoYXQgdGhlIHJlcXVlc3QNCndhcyBhY2NlcHRl
ZA0KICAgICAgICAgYW5kIHNlbmQgYSBub3RpZmljYXRpb24gdG8gdGhlIGNsaWVudCB3aGVuIHRo
ZSBpbnRlbmRlZCBjb25maWcNCmlzIGZ1bGx5IA0KICAgICAgICAgZWZmZWN0aXZlIG9yIHRoZXJl
IGFyZSBhbnkgZXJyb3JzIGZyb20gYXBwbHlpbmcgdGhlDQpjb25maWd1cmF0aW9uIGNoYW5nZS4N
Cg0KICAgICAgRS4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0
aW9ucyBNQVkgYWxzbw0KcHJvdmlkZSBhIHZlcmlmeQ0KICAgICAgICAgb3BlcmF0aW9uIHdoaWNo
IGEgY2xpZW50IGNhbiByZXF1ZXN0IGZyb20gdGhlIHNlcnZlciB0byBvYnRhaW4NCmluZm9ybWF0
aW9uDQogICAgICAgICByZWdhcmRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgaW50ZW5k
ZWQgYW5kIGFwcGxpZWQNCmNvbmZpZ3VyYXRpb25zLg0KDQoNCg0KV2UgaGF2ZSBjb25zZW5zdXMg
b24gdGhlIGFib3ZlLCBidXQgd2FudGVkIHRvIHJld3JpdGUgaXQgcmVseWluZyBtb3JlIG9uDQp0
aGUgdGVybXMgZnJvbSB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbiwgYW5kIGFsc28gcG90ZW50aWFs
bHkgbWVyZ2UgRSBpbnRvDQpELiANCg0KQW55Ym9keSB3YW50IHRvIHRha2UgYSBzdGFiIGF0IGl0
Pw0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpPbiAxMC8xNC8xNSwgODowMCBQTSwgJnF1b3Q7TmFk
ZWF1IFRob21hcyZxdW90OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt
YWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20iPiZsdDt0bmFkZWF1QGx1Y2lkdmlzaW9uLmNv
bSZndDs8L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHBy
ZSB3cmFwPSIiPjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+
T24gT2N0IDE0LCAyMDE1Ojc6NTEgUE0sIGF0IDc6NTEgUE0sIEtlbnQgV2F0c2VuIDxhIGNsYXNz
PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0
Ij4mbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZndDs8L2E+DQp3cm90ZToNCg0KDQoNCk9uIDkvMjgv
MTUsIDE6NDAgQU0sICZxdW90O0p1ZXJnZW4gU2Nob2Vud2FlbGRlciZxdW90Ow0KPGEgY2xhc3M9
Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNv
YnMtdW5pdmVyc2l0eS5kZSI+Jmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k
ZSZndDs8L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHBy
ZSB3cmFwPSIiPk9uIFdlZCwgU2VwIDIzLCAyMDE1IGF0IDAzOjAzOjU3UE0gJiM0MzswMDAwLCBL
ZW50IFdhdHNlbiB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJl
IHdyYXA9IiI+UG9wcGluZyB0aGUgc3RhY2sgb24gdGhpcyBpc3N1ZSwgdGhlIGlzc3VlIHJlbWFp
bnMgYXMgdG8gd2hhdCB0byBkbw0Kd2l0aCByZXF1aXJlbWVudCAzOg0KDQogIDMuICBTdXBwb3J0
IGZvciBib3RoIHRyYW5zYWN0aW9uYWwsIHN5bmNocm9ub3VzIG1hbmFnZW1lbnQgc3lzdGVtcw0K
ICAgICAgIGFzIHdlbGwgYXMgZGlzdHJpYnV0ZWQsIGFzeW5jaHJvbm91cyBtYW5hZ2VtZW50IHN5
c3RlbXMNCg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+SSBmYWlsIHRvIHVu
ZGVyc3RhbmQgJ3RyYW5zYWN0aW9uYWwnIGFuZCAnZGlzdHJpYnV0ZWQnIGhlcmUuDQo8L3ByZT4N
CjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5JIGhvcGUgdGhhdCB0aGVzZSB0ZXJtcyB3aWxs
IGJlIGNsYXJpZmllZCBvbiB0b21vcnJvdydzIGNhbGwuICAgVGhlcmUNCmlzDQphbHNvIGEgY2hh
bmNlIHRoYXQgdGhlc2UgdGVybXMgd2lsbCBiZSByZW1vdmVkIGZyb20gdGhlIHRleHQNCmFsdG9n
ZXRoZXIsDQphcyB0aGV5IG1heSBiZSB2aWV3ZWQgYXMgdW5uZWNlc3NhcmlseSBxdWFsaWZ5IHRo
ZQ0Kc3luY2hyb25vdXMvYXN5bmNocm9ub3VzIHRlcm1zLg0KDQoNCjwvcHJlPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+QW5kDQpmcmFua2x5LCBJIGFtIG5vdCBzdXJl
IHdoeSB0aGUgbWFuYWdlbWVudCBfc3lzdGVtc18gYXJlIGNsYXNzaWZpZWQgdG8NCmJlIHN5bmNo
cm9ub3VzIG9yIGFzeW5jaHJvbm91cyAtIEkgdGhpbmsgd2UgYXJlIHRhbGtpbmcgYWJvdXQNCnBy
b3RvY29scyBiZXR3ZWVuIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIGEgZGV2aWNlLg0KPC9wcmU+
DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+QXllLCBJIGRpZG4ndCBzZWUgdGhhdCBiZWZv
cmUuDQoNCkZpcnN0IG9mZiwgZWxzZXdoZXJlIGluIHRoZSBkcmFmdCB0aGUgdGVybSAmcXVvdDtz
eXN0ZW0mcXVvdDsgaXMgdXNlZCA3IHRpbWVzIHRvDQpyZWZlciB0byB0aGUgZGV2aWNlIChlLmcu
LCBOQy9SQyBzZXJ2ZXIpLiAgVGhlIHRlcm0gJnF1b3Q7c3lzdGVtJnF1b3Q7IGlzDQpvdGhlcndp
c2UNCm5vdCBkZWZpbmVkLg0KDQpCdXQgdG8geW91ciBtYWluIHBvaW50LCB3ZSBoYXZlIGJlZW4g
ZGlzY3Vzc2luZyB0aGUgdGVybXMgYS9zeW5jaHJvbm91cw0KdG8NCmhhdmUgdG8gZG8gd2l0aCBp
bnRlcm5hbCBzZXJ2ZXIgcHJvY2Vzc2luZyBvZiBhbiBlZGl0IHJlcXVlc3QsIGJ1dCBpbg0KJzMn
DQp0aGUgdGVybXMgYXJlIGJlaW5nIHVzZWQgdG8gcXVhbGlmeSBhIG1hbmFnZW1lbnQgc3lzdGVt
LCB3aGljaCBjYW4ndCBiZQ0KcmlnaHQuICBJIHRoaW5rIHRoYXQgJzMnIHNob3VsZCBiZSByZXdy
aXR0ZW4gdG8gYmUgYSBzdGF0ZW1lbnQgYWJvdXQNCmRldmljZXMsIG5vdCBhIHN0YXRlbWVudCBh
Ym91dCBtYW5hZ2VtZW50IHN5c3RlbXMuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3Jh
cD0iIj4JSXQgbWlnaHQgYmUgYmV0dGVyIHRvIGZyYW1lIHRoaXMgaW4gdGVybXMgb2YgYSBjbGll
bnQgYW5kIGENCnNlcnZlci4NCg0KCeKAuVRvbQ0KDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+QW55d2F5LCBJIGFtIG5vdCBzdXJlIDMuIGlzIHByb3Bl
cmx5IHdvcmRlZCB1bnRpbCBzb21lb25lIGRlZmluZXMNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+J3RyYW5zYWN0aW9uYWwnLCAnZGlzdHJpYnV0ZWQnLCAn
c3luY2hyb25vdXMgbWFuYWdlbWVudCBzeXN0ZW1zJyBhbmQNCidhc3luY2hyb25vdXMgbWFuYWdl
bWVudCBzeXN0ZW1zJy4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPlRoZSBh
Z2VuZGEgZm9yIHRvbW9ycm93J3MgaW50ZXJpbSEgIDopDQoNCg0KS2VudA0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlz
dA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPg0KPC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4NCjxh
IGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFp
bGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls
dG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4
dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8
L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPm5ldG1vZCBtYWls
aW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y
ZyI+bmV0bW9kQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BFE1544F104941A6830CED548FE1B945junipernet_--


From nobody Fri Oct 16 06:09:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152F91B2A72 for ; Fri, 16 Oct 2015 06:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqSlkFgtioJT for ; Fri, 16 Oct 2015 06:09:40 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF681B2A73 for ; Fri, 16 Oct 2015 06:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9952; q=dns/txt; s=iport; t=1445000969; x=1446210569; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5iHeVPWviZRosREu+ilCSO9ws7omtP/4P8D5KrLszq8=; b=JmCOvUo7mNS8R7bhB+4Iba8jQpxqsElvsPTQA7Y11qGg/RWeXusCEOPB yMp/ss1qEilSxOIQT/QrRO/4hmmJUecqx4dLQaOt3XA+5TkdMvMHL6ise lbGopdYyXtd13Fd/UIfyYwEe/tW9KaBVtasow1Sr9u85Kf41NHkLR/hwN g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQBE9iBW/xbLJq1eg3puvW0BDYFZFwqFM0oCgW0UAQEBAQEBAYEKhCYBAQEDAQEBASAPAQU2CwULCw4CCAICBRoHAgIPAhYwBg0GAgEBFIgOCA2vfpM6AQEBAQEBAQEBAQEBAQEBAQEBFgSBIoVUg3iBBoRCSweCaYFFBYc6hwWEAYNdjRuBWIc7gRqJG4RZg28fAQFCgkSBQD0zhWcBAQE
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800"; d="scan'208";a="630361132"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Oct 2015 13:09:26 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GD9PNZ014062; Fri, 16 Oct 2015 13:09:26 GMT
To: Martin Bjorklund 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <5620F6F7.60603@cisco.com>
Date: Fri, 16 Oct 2015 14:09:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151016.142315.2294973158906063871.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 13:09:43 -0000

Hi Martin,

On 16/10/2015 13:23, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Kent,
>>
>> Here is my attempt at word smithing section 3:
>>
>> The old D and E have been merged together (now labelled as C).  A new
>> D has been added to try and define transactional error handling
>> semantics without introducing the term transactional.
>>
>>
>>     3.  Support for both synchronous and asynchronous configuration
>>         operations
>>
>>         A. A server may choose to support only synchronous configuration
>>            operations, or only asynchronous configuration operations, or
>>            both synchronous and asynchronous configuration operations in
>>            a client specified per-operation basis.
> I think the most common mode *today* is a mix of sync/async, on a
> per-object basis.
Yes, I agree.

It might also be useful to have some text somewhere in the draft that 
makes this point clear (i.e. that existing NC/RC implementations are 
neither sync or async).

>    Is this mode no longer valid?
I don't think that we can or should invalidate existing netconf server 
implementations.

However, to sensibly support the opstate requirements, I think that the 
client has to know whether a particular request is, or all requests are, 
being handled by the server in a sync or async fashion.

There has been a suggestion that existing NC implementations could be 
regarded as being async, but that isn't going to work if there ends up 
needing to be a separate "async config apply has completed" notification 
since no existing NC/RC implementations are going to generate such a 
notification.

So, I think that ultimately operations need to be regarded as one of:
  (i) netconf current behavior
  (ii) explicit sync
  (iii) explicit async

It isn't clear to me whether only servers that support (ii) or (iii) can 
meet the opstate requirements, or whether servers supporting (i) can 
also be supported.  What do you think?

>
>>         B. Support for synchronous operations as per the definition of
>>            "synchronous configuration operation".
> Doesn't this follow from A?
Yes, possibly.  I don't mind if B is deleted.  If we do this then I 
would suggest that we also delete the analogous first sentence of C, and 
re-introduce the "(see terms)" text in the headline description.

Thanks,
Rob


>
>>         C. Support for asynchronous operations as per the definition of
>>            "asynchronous configuration operation".  Servers that support
>>            asynchronous configuration operations MAY also provide a
>>            verify operation that a client can request from the server to
>>            return information regarding the difference between the
>>            intended and applied configurations.
>>
>>         D. Support for best effort and rollback-on-error error handling
>>            semantics.  The configuration protocol, or default server
>>            behavior, MUST specify whether the configuration is applied
>>            in a best effort fashion, or using "rollback on error"
>>            semantics - where all configuration changes in the request are
>>            undone if processing of any part of the configuration update
>>            failed.  A configuration protocol, or server, SHOULD provide
>>            support for rollback-on-error behavior and MAY choose to
>>            provide support for best effort semantics as well.
>
> /martin
>
>
>> Any comments?
>>
>> Thanks,
>> Rob
>>
>>
>> On 15/10/2015 18:32, Kent Watsen wrote:
>>> Again, with better formatting for the list:
>>>
>>>      3.  Support for both synchronous and asynchronous configuration
>>>          operations (see terms)
>>>
>>>          A. A server may only support synchronous configuration
>>>             operations, or may only support asynchronous configuration
>>>             operations, or may support synchronicity to be client
>>>             specified on a per-operation basis.
>>>
>>>
>>>          C. Support for synchronous configuration operations
>>>             requires the server to block sending a response to
>>>             the client until it is able to able to determine whether
>>>             there are any errors in the request or errors from
>>>             applying the configuration change.
>>>               D. Support for asynchronous configuration operations
>>>             requires the server to send a response to the client
>>>             immediately indicated that the request was accepted
>>>             and send a notification to the client when the intended
>>>             config is fully effective or there are any errors from
>>>             applying the configuration change.
>>>
>>>          E. Support for asynchronous configuration operations MAY
>>>             also provide a verify operation which a client can request
>>>             from the server to obtain information regarding the
>>>             difference between the intended and applied configurations.
>>>
>>>
>>> Kent
>>>
>>>
>>>
>>> On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:
>>>
>>>> Requirement #3 was discussed on today's call.  We agreed to remove the
>>>> words "distributed" and "transactional" and to reword it in terms of
>>>> "configuration operations".  The resulting text follows:
>>>>
>>>>
>>>>     3.  Support for both synchronous and asynchronous configuration
>>>> operations (see terms)
>>>>
>>>>         A. A server may only support synchronous configuration operations,
>>>> or may only support
>>>>            asynchronous configuration operations, or may support
>>>> synchronicity to be client
>>>>            specified on a per-operation basis.
>>>>
>>>>
>>>>         C. Support for synchronous configuration operations requires the
>>>> server to block
>>>>            sending a response to the client until it is able to able to
>>>> determine whether
>>>>            there are any errors in the request or errors from applying the
>>>> configuration
>>>>            change.
>>>>             D. Support for asynchronous configuration operations requires
>>>>             the
>>>> server to send
>>>>            a response to the client immediately indicated that the request
>>>> was accepted
>>>>            and send a notification to the client when the intended config
>>>> is fully
>>>>            effective or there are any errors from applying the
>>>> configuration change.
>>>>
>>>>         E. Support for asynchronous configuration operations MAY also
>>>> provide a verify
>>>>            operation which a client can request from the server to obtain
>>>> information
>>>>            regarding the difference between the intended and applied
>>>> configurations.
>>>>
>>>>
>>>>
>>>> We have consensus on the above, but wanted to rewrite it relying more
>>>> on
>>>> the terms from the Terminology section, and also potentially merge E
>>>> into
>>>> D.
>>>>
>>>> Anybody want to take a stab at it?
>>>>
>>>> Thanks,
>>>> Kent
>>>>
>>>>
>>>>
>>>> On 10/14/15, 8:00 PM, "Nadeau Thomas"  wrote:
>>>>
>>>>>> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen 
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
>>>>>>  wrote:
>>>>>>
>>>>>>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
>>>>>>>> Popping the stack on this issue, the issue remains as to what to do
>>>>>>>> with requirement 3:
>>>>>>>>
>>>>>>>>     3.  Support for both transactional, synchronous management systems
>>>>>>>>          as well as distributed, asynchronous management systems
>>>>>>>>
>>>>>>> I fail to understand 'transactional' and 'distributed' here.
>>>>>> I hope that these terms will be clarified on tomorrow's call.   There
>>>>>> is
>>>>>> also a chance that these terms will be removed from the text
>>>>>> altogether,
>>>>>> as they may be viewed as unnecessarily qualify the
>>>>>> synchronous/asynchronous terms.
>>>>>>
>>>>>>
>>>>>>> And
>>>>>>> frankly, I am not sure why the management _systems_ are classified to
>>>>>>> be synchronous or asynchronous - I think we are talking about
>>>>>>> protocols between a management system and a device.
>>>>>> Aye, I didn't see that before.
>>>>>>
>>>>>> First off, elsewhere in the draft the term "system" is used 7 times to
>>>>>> refer to the device (e.g., NC/RC server).  The term "system" is
>>>>>> otherwise
>>>>>> not defined.
>>>>>>
>>>>>> But to your main point, we have been discussing the terms
>>>>>> a/synchronous
>>>>>> to
>>>>>> have to do with internal server processing of an edit request, but in
>>>>>> '3'
>>>>>> the terms are being used to qualify a management system, which can't
>>>>>> be
>>>>>> right.  I think that '3' should be rewritten to be a statement about
>>>>>> devices, not a statement about management systems.
>>>>> 	It might be better to frame this in terms of a client and a
>>>>> server.
>>>>>
>>>>> 	‹Tom
>>>>>
>>>>>
>>>>>> Anyway, I am not sure 3. is properly worded until someone defines
>>>>>>> 'transactional', 'distributed', 'synchronous management systems' and
>>>>>>> 'asynchronous management systems'.
>>>>>> The agenda for tomorrow's interim!  :)
>>>>>>
>>>>>>
>>>>>> Kent
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Oct 16 06:36:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01F1B2B05 for ; Fri, 16 Oct 2015 06:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf5A0lfRr47N for ; Fri, 16 Oct 2015 06:36:01 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9BB1B2B01 for ; Fri, 16 Oct 2015 06:36:00 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 13:35:40 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 13:35:39 +0000
From: Kent Watsen 
To: Robert Wilton , Gert Grammel , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACVvoCAAPApgP//0lgA
Date: Fri, 16 Oct 2015 13:35:39 +0000
Message-ID: 
References: <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <20151015215927.GC72419@elstar.local> <5620EB35.9090607@cisco.com>
In-Reply-To: <5620EB35.9090607@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; BY2PR05MB046; 5:fTWwhw6JVrxJ6n9N223/FnREyISxNbbtuDt7vbJXLBayQlvbkPIHBlOtXih7k/AMHrFmtk+mZIL1bxuE7WlLrKHgH3PqpRbIvDRBwQC5DQVMFtGxZ6exduoLqF8XAmh3f+Y1PSGvhca1N/US4tSDmQ==; 24:dQeLEdJeniWaQzqxIdunf5tJcqQG4yLRkSejn6oT1qJ/x3RghSgkq8Ojgs9lZqaJvZqL9LVBJLn1J5adg5/AOK34T2ntNSzEQKxU77a8KOE=; 20:c26OBqWSvRiIOspNai/Vw3BnEYb7tVbsDpBmfB5Ih0rD7HmYGe4YfgmwLGwbcTYGSIdEVx1Mqk/cfD54JExaWg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB046;
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)(520078)(3002001); SRVR:BY2PR05MB046; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB046; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(199003)(189002)(36756003)(106116001)(76176999)(66066001)(99286002)(64706001)(46102003)(105586002)(561944003)(83506001)(10400500002)(106356001)(1941001)(5001770100001)(2501003)(5008740100001)(86362001)(5007970100001)(4001350100001)(107886002)(2950100001)(54356999)(87936001)(81156007)(5002640100001)(2900100001)(189998001)(122556002)(92566002)(97736004)(40100003)(93886004)(102836002)(50986999)(101416001)(5004730100002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB046; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1A14D32BC875C042973A78E1A16C21D8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 13:35:39.1900 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB046
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 13:36:03 -0000

>>> These terms were edited on today's call, resulting in the following
>>>text:
>>>
>>>      Synchronous configuration operation - A configuration request to
>>>update
>>>      the running configuration of a server that is applied
>>>synchronously with
>>>      respect to the client request.  The server MUST fully attempt to
>>>apply
>>>      the configuration change to all impacted components in the server,
>>>      updating both the server's intended and applied configuration
>>>(see terms),
>>>      before replying to the client.  This may be transactional or non-
>>>      transactional (need terms!).  The transactionality of the
>>>operation
>>>      may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
>
>It was added in the meeting because some interpretations of the text
>assumed that the text implied that the server would always
>rollback-on-error, so the proposed text was intended to clarify that.
>
>However, I think that this clarification applies equally to both sync
>and async operations and hence I have proposed (on a separate thread)
>that it be documented as part of the requirement 3 "Support for both
>synchronous and asynchronous configuration operations" instead.


So the proposal is to remove the last two sentences? - I'm OK with that.

I think that the new word "attempt" in the previous sentence fixed it to
be (IMO) a very good definition for what is meant by a "synchronous
configuration operation" without it getting mired in details.

Kent


From nobody Fri Oct 16 06:45:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58F1B2B55 for ; Fri, 16 Oct 2015 06:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YtJgIJzTmg9Y for ; Fri, 16 Oct 2015 06:45:32 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B831B2B4D for ; Fri, 16 Oct 2015 06:45:31 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 13:45:14 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 13:45:13 +0000
From: Kent Watsen 
To: Gert Grammel 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIGAALIfAA==
Date: Fri, 16 Oct 2015 13:45:13 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>
In-Reply-To: <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB043; 5:Qhe7qLyNSUZT8tgSxLrxIj00npE3+c9rDUtXJN19kzBsZVXaeRWgQ07RGk+EUZoy6ZgLRsjfVFaTt7MGuc/xG8dBNhToPCZ+DYqSCx1Iu8TV0RVWx0neiV6fqRD86MPlM4+CXbo9GNeFZ0n2HzpGGA==; 24:e3U/iclERzMxFk7La3arGstBpVbx48sYEMYSGkfx8KP0X7Gfw7s9m4mfYDxXqhUsQ5nSc3jfHALwDQK+svdcToMVtlPOUbvkYHEpXOOiOSE=; 20:j3RSUJzy1l/WQCist5R1hWvVRl9pVIt6ct0+pC8zXcFwjDzZ27ZURpIXMFf4hHCowOJLRUWWPbj2hOPvfBYubg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB043;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BN1PR05MB043; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB043; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(76104003)(189002)(5008740100001)(50986999)(4001450100002)(16236675004)(102836002)(110136002)(93886004)(2900100001)(92566002)(40100003)(122556002)(83506001)(46102003)(64706001)(189998001)(66066001)(99286002)(87936001)(4001350100001)(54356999)(5007970100001)(97736004)(76176999)(101416001)(10400500002)(106356001)(5004730100002)(2950100001)(5001960100002)(5002640100001)(1941001)(106116001)(81156007)(86362001)(105586002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D2467579E7431kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 13:45:13.3920 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 13:45:35 -0000

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


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers=
.

Thank you (and Juergen) for the confirmation.   Again, if no objections, th=
ese two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning=
 of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as b=
eing discussed elsewhere on this thread]

OLD:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.

NEW

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request (i.e. a blocking call).  The server MUST =
fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.


What do you think?

Kent


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












Gert writes:


> I don't see the need for defining synchronous/asynchronous config=
 servers.







Thank you (and Juergen) for the confirmation.   Again, if no obje=
ctions, these two terms will not be removed.















> The new definitions look good. Later in=
 the discussion there was a common





> sentiment that the requirement for synchronous operations contain=
ed some


> crisp wording we could use here too.  I particularly liked t=
he mentioning of


> blocking requests for some time,







[Note: the following removes the last two sentences on "transacti=
ons", as being discussed elsewhere on this thread]







OLD:









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request.  The server MUST ful=
ly attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.









NEW









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request (i.e. a blocking call). &n=
bsp;The server MUST fully attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.


























What do you think?


















Kent









--_000_D2467579E7431kwatsenjunipernet_--


From nobody Fri Oct 16 06:59:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F951B2BC9 for ; Fri, 16 Oct 2015 06:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKnz76R-wagN for ; Fri, 16 Oct 2015 06:59:09 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33ADF1B2BDA for ; Fri, 16 Oct 2015 06:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34308; q=dns/txt; s=iport; t=1445003941; x=1446213541; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=G3bCti9MxXG5uccMEVoKzK75O3HY4FMY3AqpNXFjNGA=; b=KhORc7My1nGHxrmut+0owMx6Rj96luNATb8Cfrq+61GET7Pg7wHe9PGI zaIX7xjeTewqsx+mTUv4w+Oxn37layax1FbufIvJ5eIELtWxsZM1FLCm2 XgnbEh5asKe8GYAz45gO1dE934tuqvUbjwZPEr8Lq0le6kWLR5lzKLbaC U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DMAQCRASFW/xbLJq1eglmBIW69bQENgVYDFwEJhTNKAoFpFAEBAQEBAQGBCoQmAQEBAwEBAQEXCQRHCgEFCwkCDgIICRYBAwQDAgIJAwIBAgEVHxEGDQYCAQGIIggNklqdN5M3AQEBAQEBAQEBAQEBAQEBAQEBARUEhnaDeIEGhDUNRwQHgmmBRQWHMggDhwKEAYNdhRmIAoFYhzuBGokbhFmDbx8BAUKCRIFAPTOEH4FIAQEB
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800";  d="scan'208,217";a="630361595"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Oct 2015 13:58:58 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GDwweW022997; Fri, 16 Oct 2015 13:58:58 GMT
To: Gert Grammel 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local>  <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com>   <5620E9B3.60009@cisco.com> 
From: Robert Wilton 
Message-ID: <56210293.6060809@cisco.com>
Date: Fri, 16 Oct 2015 14:58:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020902030400080308090901"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 13:59:14 -0000

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

Hi Gert,

On 16/10/2015 13:58, Gert Grammel wrote:
> Hi Rob,
>
> The text looks good. With respect to D we probably need more wordsmithing:
>
>>  D. Support for best effort and rollback-on-error error handling
>>           semantics.  The configuration protocol, or default server
>>           behavior, MUST specify whether the configuration is applied
>>           in a best effort fashion, or using "rollback on error"
>>           semantics - where all configuration changes in the request are
>>           undone if processing of any part of the configuration update
>>           failed. 
> --> how would the client know that a certain operation is supported in 
> an atomic or non-atomic manner by the server. In my view the default 
> should be the client assumes best effort and the server is allowed to 
> do better.

Either the client would need to know what error semantics a particular 
server will always use to apply configuration, or the operation needs to 
indicate what semantics are in use (perhaps also being controllable by 
the client request).  But unless the client clearly knows what the error 
semantics are when it applies the config it cannot know what the value 
of the remaining leaves are if some configuration has failed.

The default error handling semantics for NC appear to be "stop on 
error", with "continue on error" and "rollback on error" being the other 
allowed options.  I wasn't aware of the "stop of first error" being the 
default option for netconf and hence hadn't considered it my text above.

So, perhaps we should lift the definitions of "stop on error", with 
"continue on error" and "rollback on error" from section 7.2. of NETCONF 
(rfc6241) into the requirements draft, and then rephrase the 1.D text in 
the context of that.

E.g. change the 1.D text to:

         D. The configuration protocol, or default server behavior, MUST
            specify how configuration errors are handled.   Errors can
            be handled by "stop on error", "continue on error" or
            "rollback on error" (see terms).  Support for "rollback on
            error" SHOULD be provided.

Lifted terms (from NETCONF):

          stop-on-error:  The configuration operation is aborted on the first
             error.

          continue-on-error:  Continue to process configuration data on
             error; error is recorded, and negative response is generated
             if any errors occur.




Enns, et al. Standards Track [Page 39]

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


RFC 6241  NETCONF Protocol June 2011


          rollback-on-error:  If an error condition occurs such that part
             of applying the configuration fails, the server will stop
             processing the configuration operation and restore the
             specified configuration to its complete state at the start
             of this configuration operation.


Thoughts?

> Hence no need for a MUST.
>
>
>> A configuration protocol, or server, SHOULD provide
>>           support for rollback-on-error behavior and MAY choose to
>>           provide support for best effort semantics as well.
>
> Wondering how much we need here. Assuming the server supports 
> rollback, then do we need protocol extensions for that?
Yes, NC already has a rollback-on-error option.


> Assuming the server doesn't support rollback. Then do we need anything 
> special in the protocol to re-configure the config to emulate 
> something like a rollback?

I would suggest no.  Either the server supports this (which is the most 
likely outcome), or the client can emulate it.


>
> My point is: given that transaction is a requirement, would we need to 
> require here anything more that is not a consequence?
>
> Perhaps it is better to limit or even avoid text about transactions 
> and just define the state of the applied config after error. I see 3 
> cases so far:
> 1) atomic: after error the applied config is identical to the config 
> before the error
> 2) sequence: if the config is applied in a sequence and a specific 
> leaf fails, the leafs that have been configured before will keep the 
> intended config, leafs not yet processed keep the applied config and 
> the failed leaf is undefined
> 3) all leafs in error are undefined, all error free leafs use the 
> (new) intended config as their applied config.
I agree with (1) and (2) but wasn't expecting (3).  By best effort, I 
was thinking of the equivalent of Netconf's  "continue on error".

Thanks,
Rob


>
> Thoughts?
>
> Gert
>
> Sent from my Apple ][
>
> On 16 Oct 2015, at 14:13, Robert Wilton  > wrote:
>
>> Hi Kent,
>>
>> Here is my attempt at word smithing section 3:
>>
>> The old D and E have been merged together (now labelled as C).  A new 
>> D has been added to try and define transactional error handling 
>> semantics without introducing the term transactional.
>>
>>
>>    3.  Support for both synchronous and asynchronous configuration
>>        operations
>>
>>        A. A server may choose to support only synchronous configuration
>>           operations, or only asynchronous configuration operations, or
>>           both synchronous and asynchronous configuration operations in
>>           a client specified per-operation basis.
>>
>>        B. Support for synchronous operations as per the definition of
>>           "synchronous configuration operation".
>>
>>        C. Support for asynchronous operations as per the definition of
>>           "asynchronous configuration operation".  Servers that support
>>           asynchronous configuration operations MAY also provide a
>>           verify operation that a client can request from the server to
>>           return information regarding the difference between the
>>           intended and applied configurations.
>>
>>        D. Support for best effort and rollback-on-error error handling
>>           semantics.  The configuration protocol, or default server
>>           behavior, MUST specify whether the configuration is applied
>>           in a best effort fashion, or using "rollback on error"
>>           semantics - where all configuration changes in the request are
>>           undone if processing of any part of the configuration update
>>           failed.  A configuration protocol, or server, SHOULD provide
>>           support for rollback-on-error behavior and MAY choose to
>>           provide support for best effort semantics as well.
>>
>> Any comments?
>>
>> Thanks,
>> Rob
>>
>>
>> On 15/10/2015 18:32, Kent Watsen wrote:
>>> Again, with better formatting for the list:
>>>
>>>     3.  Support for both synchronous and asynchronous configuration
>>>         operations (see terms)
>>>
>>>         A. A server may only support synchronous configuration
>>>            operations, or may only support asynchronous configuration
>>>            operations, or may support synchronicity to be client
>>>            specified on a per-operation basis.
>>>
>>>
>>>         C. Support for synchronous configuration operations
>>>            requires the server to block sending a response to
>>>            the client until it is able to able to determine whether
>>>            there are any errors in the request or errors from
>>>            applying the configuration change.
>>>      
>>>         D. Support for asynchronous configuration operations
>>>            requires the server to send a response to the client
>>>            immediately indicated that the request was accepted
>>>            and send a notification to the client when the intended
>>>            config is fully effective or there are any errors from
>>>            applying the configuration change.
>>>
>>>         E. Support for asynchronous configuration operations MAY
>>>            also provide a verify operation which a client can request
>>>            from the server to obtain information regarding the
>>>            difference between the intended and applied configurations.
>>>
>>>
>>> Kent
>>>
>>>
>>>
>>> On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:
>>>
>>>> Requirement #3 was discussed on today's call.   We agreed to remove the
>>>> words "distributed" and "transactional" and to reword it in terms of
>>>> "configuration operations".  The resulting text follows:
>>>>
>>>>
>>>>    3.  Support for both synchronous and asynchronous configuration
>>>> operations (see terms)
>>>>
>>>>        A. A server may only support synchronous configuration operations,
>>>> or may only support
>>>>           asynchronous configuration operations, or may support
>>>> synchronicity to be client
>>>>           specified on a per-operation basis.
>>>>
>>>>
>>>>        C. Support for synchronous configuration operations requires the
>>>> server to block
>>>>           sending a response to the client until it is able to able to
>>>> determine whether
>>>>           there are any errors in the request or errors from applying the
>>>> configuration
>>>>           change.
>>>>     
>>>>        D. Support for asynchronous configuration operations requires the
>>>> server to send
>>>>           a response to the client immediately indicated that the request
>>>> was accepted
>>>>           and send a notification to the client when the intended config
>>>> is fully
>>>>           effective or there are any errors from applying the
>>>> configuration change.
>>>>
>>>>        E. Support for asynchronous configuration operations MAY also
>>>> provide a verify
>>>>           operation which a client can request from the server to obtain
>>>> information
>>>>           regarding the difference between the intended and applied
>>>> configurations.
>>>>
>>>>
>>>>
>>>> We have consensus on the above, but wanted to rewrite it relying more on
>>>> the terms from the Terminology section, and also potentially merge E into
>>>> D.
>>>>
>>>> Anybody want to take a stab at it?
>>>>
>>>> Thanks,
>>>> Kent
>>>>
>>>>
>>>>
>>>> On 10/14/15, 8:00 PM, "Nadeau Thomas"  wrote:
>>>>
>>>>>> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
>>>>>>   wrote:
>>>>>>
>>>>>>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
>>>>>>>> Popping the stack on this issue, the issue remains as to what to do
>>>>>>>> with requirement 3:
>>>>>>>>
>>>>>>>>    3.  Support for both transactional, synchronous management systems
>>>>>>>>         as well as distributed, asynchronous management systems
>>>>>>>>
>>>>>>> I fail to understand 'transactional' and 'distributed' here.
>>>>>> I hope that these terms will be clarified on tomorrow's call.   There
>>>>>> is
>>>>>> also a chance that these terms will be removed from the text
>>>>>> altogether,
>>>>>> as they may be viewed as unnecessarily qualify the
>>>>>> synchronous/asynchronous terms.
>>>>>>
>>>>>>
>>>>>>> And
>>>>>>> frankly, I am not sure why the management _systems_ are classified to
>>>>>>> be synchronous or asynchronous - I think we are talking about
>>>>>>> protocols between a management system and a device.
>>>>>> Aye, I didn't see that before.
>>>>>>
>>>>>> First off, elsewhere in the draft the term "system" is used 7 times to
>>>>>> refer to the device (e.g., NC/RC server).  The term "system" is
>>>>>> otherwise
>>>>>> not defined.
>>>>>>
>>>>>> But to your main point, we have been discussing the terms a/synchronous
>>>>>> to
>>>>>> have to do with internal server processing of an edit request, but in
>>>>>> '3'
>>>>>> the terms are being used to qualify a management system, which can't be
>>>>>> right.  I think that '3' should be rewritten to be a statement about
>>>>>> devices, not a statement about management systems.
>>>>> 	It might be better to frame this in terms of a client and a
>>>>> server.
>>>>>
>>>>> 	‹Tom
>>>>>
>>>>>
>>>>>> Anyway, I am not sure 3. is properly worded until someone defines
>>>>>>> 'transactional', 'distributed', 'synchronous management systems' and
>>>>>>> 'asynchronous management systems'.
>>>>>> The agenda for tomorrow's interim!  :)
>>>>>>
>>>>>>
>>>>>> Kent
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    Hi Gert,

    

    
On 16/10/2015 13:58, Gert Grammel
      wrote:

    

    

      
      
Hi Rob,

      


      

      
The text looks good. With respect to D we probably need more
        wordsmithing:

      


      

      

        
 D.
              Support for best effort and rollback-on-error error
              handling

                        semantics.  The configuration protocol, or
              default server

                        behavior, MUST specify whether the configuration
              is applied

                        in a best effort fashion, or using "rollback on
              error"

                        semantics - where all configuration changes in
              the request are

                        undone if processing of any part of the
              configuration update

                        failed.  

        
--> how would the client know that a certain operation
          is supported in an atomic or non-atomic manner by the server.
          In my view the default should be the client assumes best
          effort and the server is allowed to do better.

      

    

    

    Either the client would need to know what error semantics a
    particular server will always use to apply configuration, or the
    operation needs to indicate what semantics are in use (perhaps also
    being controllable by the client request).  But unless the client
    clearly knows what the error semantics are when it applies the
    config it cannot know what the value of the remaining leaves are if
    some configuration has failed.

    

    The default error handling semantics for NC appear to be "stop on
    error", with "continue on error" and "rollback on error" being the
    other allowed options.  I wasn't aware of the "stop of first error"
    being the default option for netconf and hence hadn't considered it
    my text above.

    

    So, perhaps we should lift the definitions of "stop on error", with
    "continue on error" and "rollback on error" from section 7.2. of
    NETCONF (rfc6241) into the requirements draft, and then rephrase the
    1.D text in the context of that.

    

    E.g. change the 1.D text to:

          

            D. The configuration protocol, or default server
      behavior, MUST

                 specify how configuration errors are handled.   Errors
      can

                 be handled by "stop on error", "continue on error" or

                 "rollback on error" (see terms).  Support for "rollback
      on

                 error" SHOULD be provided.

    

    Lifted terms (from NETCONF):

    

    
         stop-on-error:  The configuration operation is aborted on the first
            error.

         continue-on-error:  Continue to process configuration data on
            error; error is recorded, and negative response is generated
            if any errors occur.




Enns, et al.                 Standards Track                   [Page 39]

    

    

RFC 6241                    NETCONF Protocol                   June 2011


         rollback-on-error:  If an error condition occurs such that part
            of applying the configuration fails, the server will stop
            processing the configuration operation and restore the
            specified configuration to its complete state at the start
            of this configuration operation.

    

    Thoughts?

    

    

      

        
Hence no need for a MUST. 

        


        

        

        
A
              configuration protocol, or server, SHOULD provide

                        support for rollback-on-error behavior and MAY
              choose to

                        provide support for best effort semantics as
              well.

      

      


      

      
Wondering how much we need here. Assuming the server supports
        rollback, then do we need protocol extensions for that?

    

    Yes, NC already has a rollback-on-error option.

    

    

    

      
Assuming the server doesn't support rollback. Then do we need
        anything special in the protocol to re-configure the config to
        emulate something like a rollback?

    

    

    I would suggest no.  Either the server supports this (which is the
    most likely outcome), or the client can emulate it. 

    

    

    

      


      

      
My point is: given that transaction is a requirement, would
        we need to require here anything more that is not a consequence?

      


      

      
Perhaps it is better to limit or even avoid text about
        transactions and just define the state of the applied config
        after error. I see 3 cases so far:

      
1) atomic: after error the applied config is identical to the
        config before the error

      
2) sequence: if the config is applied in a sequence and a
        specific leaf fails, the leafs that have been configured before
        will keep the intended config, leafs not yet processed keep the
        applied config and the failed leaf is undefined

      
3) all leafs in error are undefined, all error free leafs use
        the (new) intended config as their applied config.

    

    I agree with (1) and (2) but wasn't expecting (3).  By best effort,
    I was thinking of the equivalent of Netconf's  "continue on error".

    

    Thanks,

    Rob

    

    

    

      


      

      
Thoughts?

      


      

      
Gert

      


        
Sent from my Apple ][

      

      


        On 16 Oct 2015, at 14:13, Robert Wilton <rwilton@cisco.com>
        wrote:

        

      

      

        
Hi Kent,

          

          Here is my attempt at word smithing section 3:

          

          The old D and E have been merged together (now labelled as
          C).  A new D has been added to try and define transactional
          error handling semantics without introducing the term
          transactional.

          

          

             3.  Support
            for both synchronous and asynchronous configuration

                   operations

            

                   A. A server may choose to support only synchronous
            configuration

                      operations, or only asynchronous configuration
            operations, or

                      both synchronous and asynchronous configuration
            operations in

                      a client specified per-operation basis.

            

                   B. Support for synchronous operations as per the
            definition of

                      "synchronous configuration operation".

            

                   C. Support for asynchronous operations as per the
            definition of

                      "asynchronous configuration operation".  Servers
            that support

                      asynchronous configuration operations MAY also
            provide a

                      verify operation that a client can request from
            the server to

                      return information regarding the difference
            between the

                      intended and applied configurations.

            

                   D. Support for best effort and rollback-on-error
            error handling

                      semantics.  The configuration protocol, or default
            server

                      behavior, MUST specify whether the configuration
            is applied

                      in a best effort fashion, or using "rollback on
            error"

                      semantics - where all configuration changes in the
            request are

                      undone if processing of any part of the
            configuration update

                      failed.  A configuration protocol, or server,
            SHOULD provide

                      support for rollback-on-error behavior and MAY
            choose to

                      provide support for best effort semantics as well.

            

          Any comments?

          

          Thanks,

          Rob

          

          

          
On 15/10/2015 18:32, Kent Watsen
            wrote:

          

          

            
Again, with better formatting for the list:

   3.  Support for both synchronous and asynchronous configuration
       operations (see terms)

       A. A server may only support synchronous configuration
          operations, or may only support asynchronous configuration
          operations, or may support synchronicity to be client
          specified on a per-operation basis.


       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request or errors from
          applying the configuration change.
    
       D. Support for asynchronous configuration operations
          requires the server to send a response to the client
          immediately indicated that the request was accepted
          and send a notification to the client when the intended
          config is fully effective or there are any errors from
          applying the configuration change.

       E. Support for asynchronous configuration operations MAY
          also provide a verify operation which a client can request
          from the server to obtain information regarding the
          difference between the intended and applied configurations.


Kent



On 10/15/15, 1:22 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:



            

              
Requirement #3 was discussed on today's call.   We agreed to remove the
words "distributed" and "transactional" and to reword it in terms of
"configuration operations".  The resulting text follows:


  3.  Support for both synchronous and asynchronous configuration
operations (see terms)

      A. A server may only support synchronous configuration operations,
or may only support
         asynchronous configuration operations, or may support
synchronicity to be client
         specified on a per-operation basis.


      C. Support for synchronous configuration operations requires the
server to block
         sending a response to the client until it is able to able to
determine whether
         there are any errors in the request or errors from applying the
configuration
         change.
   
      D. Support for asynchronous configuration operations requires the
server to send
         a response to the client immediately indicated that the request
was accepted
         and send a notification to the client when the intended config
is fully 
         effective or there are any errors from applying the
configuration change.

      E. Support for asynchronous configuration operations MAY also
provide a verify
         operation which a client can request from the server to obtain
information
         regarding the difference between the intended and applied
configurations.



We have consensus on the above, but wanted to rewrite it relying more on
the terms from the Terminology section, and also potentially merge E into
D. 

Anybody want to take a stab at it?

Thanks,
Kent



On 10/14/15, 8:00 PM, "Nadeau Thomas" <tnadeau@lucidvision.com> wrote:



              

                

                  
On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen <kwatsen@juniper.net>
wrote:



On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
<j.schoenwaelder@jacobs-university.de> wrote:



                  

                    
On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:


                    

                      
Popping the stack on this issue, the issue remains as to what to do
with requirement 3:

  3.  Support for both transactional, synchronous management systems
       as well as distributed, asynchronous management systems



                    

                    
I fail to understand 'transactional' and 'distributed' here.


                  

                  
I hope that these terms will be clarified on tomorrow's call.   There
is
also a chance that these terms will be removed from the text
altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.




                  

                    
And
frankly, I am not sure why the management _systems_ are classified to
be synchronous or asynchronous - I think we are talking about
protocols between a management system and a device.


                  

                  
Aye, I didn't see that before.

First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server).  The term "system" is
otherwise
not defined.

But to your main point, we have been discussing the terms a/synchronous
to
have to do with internal server processing of an edit request, but in
'3'
the terms are being used to qualify a management system, which can't be
right.  I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.


                

                
	It might be better to frame this in terms of a client and a
server.

	‹Tom




                

                  
Anyway, I am not sure 3. is properly worded until someone defines


                  

                    
'transactional', 'distributed', 'synchronous management systems' and
'asynchronous management systems'.


                  

                  
The agenda for tomorrow's interim!  :)


Kent

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


                

              

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


            

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


          

          

        

      

      

        
_______________________________________________

          netmod mailing list

          netmod@ietf.org

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

        

      

    

    

  


--------------020902030400080308090901--


From nobody Fri Oct 16 06:59:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE3C1B2BC9 for ; Fri, 16 Oct 2015 06:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBeo0Bpq7P56 for ; Fri, 16 Oct 2015 06:59:13 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907151B2BC8 for ; Fri, 16 Oct 2015 06:59:07 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 13:59:05 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 13:59:05 +0000
From: Kent Watsen 
To: Robert Wilton , Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8A
Date: Fri, 16 Oct 2015 13:59:04 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>
In-Reply-To: <5620F6F7.60603@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:OvWuxBUTp2v9j82lPbl0V1a6I7QLi9jHV+FqFhH+B6ExiQec8wI/M/bhEYfRVr37ejidW1JIV+FrZKGoKjp02GblpFG12xwJPqGSH+O1lISCZTdTHJ8gnGkg2fInEbrxnF7A//IOSeWXwL7kuNJ7jg==; 24:S6JepavgkIR/uDzC4nTRCRcJO6EKicluUp8EF4sAP8hXkmu15tjfQ4Jf/OXKrwOzvUTsMjYwUkdc0+0c0WHn9cdvPsHQyqJtxQCPNxVJwRk=; 20:2+tnUWsQAw505GbM0MhcZ/YxzsFnEYaGhKUnArXXNZ+j1tMBcw5tnwh35y5Ejk5m6JRhOffpUo7lpREqm99etA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(66066001)(36756003)(11100500001)(10400500002)(64706001)(106356001)(105586002)(106116001)(83506001)(99286002)(101416001)(46102003)(97736004)(102836002)(87936001)(93886004)(86362001)(81156007)(5002640100001)(189998001)(5008740100001)(5001920100001)(122556002)(40100003)(2950100001)(4001350100001)(5004730100002)(92566002)(5001960100002)(5007970100001)(2900100001)(50986999)(5001770100001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 13:59:04.9442 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 13:59:15 -0000

>>>     3.  Support for both synchronous and asynchronous configuration
>>>         operations
>>>
>>>         A. A server may choose to support only synchronous
>>>configuration
>>>            operations, or only asynchronous configuration operations,
>>>or
>>>            both synchronous and asynchronous configuration operations
>>>in
>>>            a client specified per-operation basis.
>> I think the most common mode *today* is a mix of sync/async, on a
>> per-object basis.
>Yes, I agree.


Wait, I think we're talking about different things.  Martin, I'm sure that
internal to a NC/RC server, parts of the intended configuration is
actually applied synchronously (e.g., a hostname) whereas other parts are
not (e.g., config for data plane).   But that nuance is not currently
exposed in any way today -right?

What we're talking about here is an ability for a client to request a
protocol operation (PATCH) to block, or for the "done-applying"
notification to not be sent, until all that processing of the request is
complete.  This regardless if the request contains a mix of nodes that are
applied internally sync/async.  Makes sense? - or it is something else?




>>>         B. Support for synchronous operations as per the definition of
>>>            "synchronous configuration operation".
>> Doesn't this follow from A?
>Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>would suggest that we also delete the analogous first sentence of C, and
>re-introduce the "(see terms)" text in the headline description.

+1


Kent  // as a contributor



From nobody Fri Oct 16 07:00:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0291C1B2BC7 for ; Fri, 16 Oct 2015 07:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlhDNHO8XL6r for ; Fri, 16 Oct 2015 07:00:30 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD7F1B2BC1 for ; Fri, 16 Oct 2015 07:00:30 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 97A451CC00D9; Fri, 16 Oct 2015 16:00:34 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: 
References: <20151013080254.GA65823@elstar.local> 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 16 Oct 2015 16:00:34 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9.	built-in types)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:00:34 -0000

Ladislav Lhotka  writes:

> Juergen Schoenwaelder  writes:
>
>> Hi,
>>
>> here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I
>> have finish now a complete review of the document. The most important
>> bug I spotted is likely that section 9.4.6 is empty.
>
> Yes, and the "modifier" statement should also be listed in Table 1 of
> sec.=C2=A013.1.

I just noticed this table contains a copy-and-paste error:

            +------------------+---------------+-------------+
            | keyword          | argument name | yin-element |
            +------------------+---------------+-------------+
            | action           | name          | false       |
            | anydata          | 7.10          | 0..n        |
                                 ^^^^            ^^^^
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20
Lada

>
> Lada
>
>>
>> /js
>>
>> * p126
>>
>>   OLD
>>
>>      Some types have a lexical representation that depends on the XML
>>      context in which they occur.  These types do not have a canonical
>>      form.
>>
>>   NEW
>>
>>      Some types have a lexical representation that depends on the
>>      encoding, e.g., the XML context in which they occur.  These types
>>      do not have a canonical form.
>>
>>   Well, it turns out that there are XML encoding specifics in several
>>   of the following sections. Perhaps instead stated upfront that the
>>   section 9 describes the types and they XML encoding and noting that
>>   other encodings may use different rules. Perhaps also stating that
>>   the canonical representation is also used for constraint evaluation
>>   purposes.
>>
>>   OLD
>>
>>     When a NETCONF server sends data, it MUST be in the canonical form.
>>
>>   NEW
>>
>>     When a server sends data encoded in XML, it MUST use the canonical
>>     form defined in this section. Other encodings may introduce
>>     alternate representations. Note, however, that values in the data
>>     tree are conceptually stored in the canonical representation as
>>     defined in this section. In particular, any XPath expression
>>     evaluations are done using the canonical form.
>>
>> * p127
>>
>>   s/XML instance documents/XML encoding/
>>
>> * p131
>>
>>   s/XML instance documents/XML encoding/
>>
>> * p132
>>
>>   The section 9.4.6 (modifier statement) is empty and needs to be
>>   filled in.
>>
>> * p137
>>
>>   Y25-02 says:
>>
>>       Keep the auto-numbering procedure for enums and bits and add an
>>       explicit warning that inserting enum or bits definitions or
>>       reordering enum or bits definitions violates section 10 and causes
>>       interoperability problems unless explicit value assignments are
>>       used.
>>
>>   Has this been implemented? I did not find such a statement.
>>
>> * p139
>>
>>   s/A binary can/A binary type can/
>>
>> * p139
>>
>>   s/are encoded/are encoded in XML/
>>
>> * p141
>>
>>   s/is encoded/is encoded in XML/
>>
>> * p146
>>
>>   s/is encoded/is encoded in XML/
>>
>> * p148
>>
>>   The text stating that a value is consecutively against each member
>>   type does not seem to be 100% true for the JSON mapping since JSON
>>   says the JSON type information is taken into account. So we either
>>   change the JSON specification or we rewrite this text in RFC 6020 to
>>   allow different member type selection styles by making this
>>   statement specific to the XML encoding:
>>
>>      In the XML encoding, the value representing a union data type...
>>
>> /js
>>
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Oct 16 07:04:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6903F1B2BE3 for ; Fri, 16 Oct 2015 07:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.73
X-Spam-Level: 
X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG0FPaq-5sga for ; Fri, 16 Oct 2015 07:04:46 -0700 (PDT)
Received: from teledg001ba020.telecomitalia.it (teledg001ba020.telecomitalia.it [156.54.233.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798BF1B2BCB for ; Fri, 16 Oct 2015 07:04:43 -0700 (PDT)
Content-Type: multipart/mixed; boundary="_245666d3-e5e2-4a04-b8f4-2608445ba06c_"
Received: from TELCAH006BA020.telecomitalia.local (10.188.101.224) by teledg001ba020.telecomitalia.it (10.188.101.210) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 16 Oct 2015 16:04:39 +0200
Received: from TELMBA001BA020.telecomitalia.local ([169.254.1.132]) by telcah006ba020.telecomitalia.local ([10.188.101.224]) with mapi id 14.03.0181.006; Fri, 16 Oct 2015 16:04:39 +0200
From: De Noia Giuseppe 
To: "netmod@ietf.org" 
Thread-Topic: About correlation between snmp alarms and yang structures
Thread-Index: AdEIGvq/yGk/yTLQRBeWDmLVFSIzlg==
Date: Fri, 16 Oct 2015 14:04:38 +0000
Message-ID: <167E7B4797E08C4DBC40AED09620195944BFEEF0@TELMBA001BA020.telecomitalia.local>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.188.101.189]
x-ti-disclaimer: Disclaimer1
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] About correlation between snmp alarms and yang structures
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:04:54 -0000

--_245666d3-e5e2-4a04-b8f4-2608445ba06c_
Content-Type: multipart/alternative;
	boundary="_000_167E7B4797E08C4DBC40AED09620195944BFEEF0TELMBA001BA020t_"

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

Hi guys,
I have a question about Yang language support for snmp alarm correlation.
It could be nice if a device supplier, specifying the Yang model of his net=
work element, could also specify the correspondence between snmp alarms pro=
duced and affected part of the yang model of its device. This will allow fo=
r correlation between snmp traps (or other events) affecting a given object=
  and the service instance created (through Netconf/yang) on that object.

As for example, let's say a device send the following trap

xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/2015 1=
4:13:27
  Time stamp: 0 days 00h:00m:40s.15th
  Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: SN=
MPv2c Notification
  Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
  Community: public
  Enterprise: enterprises.8072.3.2.10
  Bindings (8)
    Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
    Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
    Binding #3: ifIndex.6 *** (int32) 6
    Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
    Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
    Binding #6: ifAdminStatus.6 *** (int32) down(2)
    Binding #7: ifOperStatus.6 *** (int32) down(2)
    Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10

On the same device I created a service instance, which consists on an inter=
face configuration . The interface, described through the YANG model is the=
 following
/tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.=3D'dp0s3']

Actually the SNMP trap impacts on the same interface where I configured my =
service instance, but I have no means to understand it.

How can I enrich my YANG model to support the information that a trap with =
oid=3D snmpTraps.3 and ifDescr =3D dp0s3 affect the same interface describe=
d in Yang by the xpath expression /tns:data/tnsA:interfaces/tnsB:dataplane/=
tnsB:tagnode[.=3D'dp0s3']?

Do I need to define a new YANG extension statement to carry on such a corre=
spondence, or can I rely on existing structures?

Regards,
Giuseppe De Noia




------------------------------------------------------------------
Telecom Italia
Giuseppe De Noia
T.TG.NM.OSI,
Via Reiss Romoli, 274  10148 Torino
011 2288887
331 6001197

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.

[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?=
 necessario.


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











Hi guys,


I have a q=
uestion about Yang language support for snmp alarm correlation.<=
/span>


It could b=
e nice if a device supplier, specifying the Yang model of his network eleme=
nt, could also specify the correspondence between snmp alarms
 produced and affected part of the yang model of its device. This will allo=
w for correlation between snmp traps (or other events) affecting a given ob=
ject  and the service instance created (through Netconf/yang) on that =
object.


 =
;


As for exa=
mple, let’s say a device send the following trap

 =
;


xx:
snmpTraps.3 n=
otification received from: 163.162.185.239 at 18/06/2015 14:13:27


  Tim=
e stamp: 0 days 00h:00m:40s.15th


  Age=
nt address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: SNMPv2c=
 Notification


  Man=
ager address: 163.162.107.184 Port: 162 Transport: IP/UDP=



  Com=
munity: public


  Ent=
erprise: enterprises.8072.3.2.10


  Bin=
dings (8)


 &nbs=
p;  Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th


 &nbs=
p;  Binding #2: snmpTrapOID.0 *** (oid)
snmpTraps.3


 &nbs=
p;  Binding #3: ifIndex.6 *** (int32) 6


 &nbs=
p;  Binding #4: ifDescr.6 *** (octets)
dp0s3 [64.70.=
30.73.34 (hex)]


 &nbs=
p;  Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)


 &nbs=
p;  Binding #6: ifAdminStatus.6 *** (int32) down(2)<=
/p>

 &nbs=
p;  Binding #7: ifOperStatus.6 *** (int32) down(2)

 &nbs=
p; 
Binding #8: snmpTrapEnterprise.0 *** (oid=
) enterprises.8072.3.2.10


 =
;


On the sam=
e device I created a service instance, which consists on an interface confi=
guration . The interface, described through the YANG model
 is the following


/tns:data/=
tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.=3D'dp0s3']


 =
;


Actually t=
he SNMP trap impacts on the same interface where I configured my service in=
stance, but I have no means to understand it.


 =
;


How can I =
enrich my YANG model to support the information that a trap with oid=3D snmpTraps.3
 and ifDescr =3D dp0=
s3 affect the same interface described in Yang by the xpath expressi=
on /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.=3D'dp0s3']?=



 =
;


Do I need =
to define a new YANG extension statement to carry on such a correspondence,=
 or can I rely on existing structures?


 =
;


Regards,


Giuseppe D=
e Noia


 =
;


 =
;


 =
;


 =
;


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

Telecom Italia<=
br>
Giuseppe De=
 Noia


T.=
TG.NM.OSI,



Vi=
a Reiss Romoli, 274  10148 Torino

011 2288887

331 6001197


 











=
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi
 altra azione derivante dalla conoscenza di queste informazioni sono rigoro=
samente vietate. Qualora abbiate ricevuto questo documento per errore siete=
 cortesemente pregati di darne immediata comunicazione al mittente e di pro=
vvedere alla sua distruzione, Grazie.



This e-mail and any attachments is confidential
 and may contain privileged information intended for the addressee(s) only.=
 Dissemination, copying, printing or use by anybody else is unauthorised. I=
f you are not the intended recipient, please delete this message and any at=
tachments and advise the sender
 by return e-mail, Thanks.


3D"rispettaRispetta=
 l'ambiente. Non stampare questa mail se non è necessario.











--_000_167E7B4797E08C4DBC40AED09620195944BFEEF0TELMBA001BA020t_--

--_245666d3-e5e2-4a04-b8f4-2608445ba06c_
Content-Description: logo Ambiente_foglia2.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000003@TI.Disclaimer

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

--_245666d3-e5e2-4a04-b8f4-2608445ba06c_--


From nobody Fri Oct 16 07:06:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA731B2BCB for ; Fri, 16 Oct 2015 07:06:36 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFkgU2-aGdYA for ; Fri, 16 Oct 2015 07:06:35 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 7A7061B2BE3 for ; Fri, 16 Oct 2015 07:06:15 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so100912127lbc.3 for ; Fri, 16 Oct 2015 07:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Qa0UHphWt/LfQvZO3Rx5y/RMZc1cmWHfF7sK8pcfMJk=; b=S/4NexjxC32OJfHvziLFSs0SEiVHcxgCGE+XRfYTFEdbxnRm/aeOorlHfMozK3L0id KrHBu3ghdund3z35FWxKPYRG55RV1zX/Mbl8rD8lrvSfrRNCY2CGdRug/DzdCQoGWLD/ cBbQtEsQeu7/Ki8TRrM1X37faonvOrX1YyedZ3gJO9IgdaWn1qFH/wqkBgugCrOKx/Dh GVw6wpLHRMhgHCHYvPjV8w2YMEWLtFT+xIR5U5/0eO/86EpaE3Q1iTCwajvwWZ7JakmN 6d569WJAHeL1n9BEDQlOomL+LOIQDx2QCe1wD28NSW+02RR3BWOkeVepy8CSSJx+P3hT 89vw==
MIME-Version: 1.0
X-Received: by 10.112.140.4 with SMTP id rc4mr8441414lbb.26.1445004373409; Fri, 16 Oct 2015 07:06:13 -0700 (PDT)
Sender: william.lupton@gmail.com
Received: by 10.113.4.133 with HTTP; Fri, 16 Oct 2015 07:06:13 -0700 (PDT)
In-Reply-To: 
References: <20151014.214145.1464628339304882836.mbj@tail-f.com>   <20151015.143939.746024114526885799.mbj@tail-f.com> 
Date: Fri, 16 Oct 2015 15:06:13 +0100
X-Google-Sender-Auth: kycL9BsYAOnrz1IFt4Q_HQ6-t0U
Message-ID: 
From: William Lupton 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=001a11c26324604a1e0522394c02
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] not a non-presence container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:06:37 -0000

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

I like that approach. Thanks, W.

On 15 October 2015 at 16:50, Jonathan Hansford 
wrote:

> How about =E2=80=9Cclosest ancestor node in the schema tree (excluding
> non-presence containers)=E2=80=9D?
>
>
>
> Jonathan
>
>
>
>
>
>
> *From: *Martin Bjorklund
> *Sent: *15 October 2015 13:39
> *To: *jonathan@hansfords.net
> *Cc: *wfl@cantab.net;netmod@ietf.org
>
> *Subject: *Re: [netmod] not a non-presence container
>
>
>
>
>
> Jonathan Hansford  wrote:
>
> > If that misinterpretation has already happened for (at least) one
>
> > individual, would it be worth adding the clarification and remove the
>
> > ambiguity?
>
>
>
> Sure.  The words "not a non-presence container" occurs a couple of
>
> times throughout the document.
>
>
>
> Would it be correct to write "not a non-presence-container"?
>
>
>
>
>
> /martin
>
>
>
>
>
>
>
> >
>
> > Jonathan
>
> >
>
> >
>
> >
>
> > From: William Lupton
>
> > Sent: 14 October 2015 23:28
>
> > To: Martin Bjorklund
>
> > Cc: netmod@ietf.org
>
> > Subject: Re: [netmod] not a non-presence container
>
> >
>
> >
>
> > Thanks. I see now. As you will have realised, I parsed "not a
>
> > non-presence container" as "(not a non-presence) container" (WRONG)
>
> > rather than "not a (non-presence container)" (RIGHT). Cheers, W.
>
> >
>
> > On 14 October 2015 at 20:41, Martin Bjorklund  wrote:
>
> > William Lupton  wrote:
>
> > > All,
>
> > >
>
> > > Both RFC 6020 and the bis draft use the term "not a non-presence
>
> > > container", sometimes with a reference to section 7.5.1.
>
> > >
>
> > > Does this term mean the same as "presence container"?
>
> >
>
> > No.  A list (for example) is not a non-presence container.
>
> >
>
> > > If so, I think it
>
> > > would be easier (on the reader!) to say that instead. If not, I think
>
> > > that
>
> > > the term warrants a mention in section 7.5.1.
>
> >
>
> > The term is "non-presence container", and it is explained in 7.5.1.
>
> >
>
> >
>
> > /martin
>
> >
>
> >
>
> >
>
>
>
>
>

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


I like that approach. Thanks, W.

On 15 October 2015 at 16:50, Jonathan=
 Hansford <jonathan@hansfords.net> wrote:
How about =E2=80=9Cclosest=
 ancestor node in the schema tree (excluding non-presence containers)=E2=80=
=9D?
=C2=A0
Jonathan
=C2=A0
=C2=A0
=

From: Martin Bjorklund
Sent: 15 October 2015 13:39
=
To: jona=
than@hansfords.net
Cc: wfl@cantab.net;netmod@ietf.org

Subject: <=
/b>Re: [netmod] not a non-presence container
<=
div class=3D"h5">
=C2=A0
<=
u>=C2=A0
Jonathan Hansford <=
jonathan@hansfo=
rds.net> wrote:
> If that misinterpreta=
tion has already happened for (at least) one
>=
 individual, would it be worth adding the clarification and remove the
<=
p class=3D"MsoNormal">> ambiguity?
=C2=
=A0
Sure.=C2=A0 The words "not a non-=
presence container" occurs a couple of
times=
 throughout the document.
=C2=A0
Would it be correct to write "not a non-presen=
ce-container"?
=C2=A0
=C2=A0
/martin
=C2=A0
<=
/u>=C2=A0
=C2=A0
> 
> Jonathan
> 
> 
> 
> From: William Lupton
> Sent: 14 October 2015 23:28
> T=
o: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: [netmod] not a non-presence container
> 
> 
=
> Thanks. I see now. As you will have realised, I parsed "not a
=

> non-presence container" as "(not a no=
n-presence) container" (WRONG)
> rather t=
han "not a (non-presence container)" (RIGHT). Cheers, W.
> 
> On 14 October 2015 a=
t 20:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> William=
 Lupton <wfl@cantab.=
net> wrote:
> > All,
> >
> > Both RFC 6020 and =
the bis draft use the term "not a non-presence
> > container", sometimes with a reference to section 7.5.1.<=
/p>
> >
> > Doe=
s this term mean the same as "presence container"?
> 
> No.=C2=A0 A list (for exam=
ple) is not a non-presence container.
> 
> > If so, I think it
=
> > would be easier (on the reader!) to say that instead. If not, I t=
hink
> > that
>=
; > the term warrants a mention in section 7.5.1.
> 
> The term is "non-presence con=
tainer", and it is explained in 7.5.1.
> =

> 
> /martin
=

> 
> 
> 
=C2=A0
=C2=A0



--001a11c26324604a1e0522394c02--


From nobody Fri Oct 16 07:12:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1B1B2B5E for ; Fri, 16 Oct 2015 07:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOnl5pXzAo_a for ; Fri, 16 Oct 2015 07:12:23 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9C51B2AAC for ; Fri, 16 Oct 2015 07:12:23 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 14:12:19 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 14:12:19 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACVvoCAAPApgIAADWEA
Date: Fri, 16 Oct 2015 14:12:19 +0000
Message-ID: 
References: <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <20151015215927.GC72419@elstar.local> <5620EB35.9090607@cisco.com>
In-Reply-To: <5620EB35.9090607@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.111.78]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB455; 5:vaN3gxZMLnO8SYapd8bLrFZxW5/kE5sGPwO9PjfzB7rbgM/TepBOkOXWdYwV2emZvna8ZICv0KR8FQFeSpMpzWH+/Saf9p80E+FI2n6z8HdVS+bEU4TqGBcUGeVwonXaT541DR7qwJfExNtLIvx4Kw==; 24:+ELKo5tP7r33jJABqEvEr/QX4aeK5uEBia/Yi5nZ6WFbm+eK6I+W15Dl1zugjh5U9dHpJheEfVmbeuq6RVAih2vqMNbGB5oImYAKKou1Rfk=; 20:LV/LpuIo6w0cFr016xoSEVjB3Opd+LzaSKQyfaVnffDgfq20xYzcS1I6bwqsED0rbIbdKmOVAkx05LuYaEd2eA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB455; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB455; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(51444003)(24454002)(479174004)(189002)(76176999)(11100500001)(87936001)(97736004)(106356001)(40100003)(5002640100001)(122556002)(5001960100002)(561944003)(189998001)(92566002)(99286002)(19580405001)(102836002)(36756003)(10400500002)(5004730100002)(93886004)(5007970100001)(86362001)(110136002)(81156007)(66066001)(64706001)(105586002)(54356999)(106116001)(83716003)(50986999)(101416001)(19580395003)(2900100001)(82746002)(5008740100001)(2950100001)(33656002)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 14:12:19.0485 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:12:25 -0000

Juergen,

Rob summarized the discussion well. Since I also have some strange feelings=
 about transactions here, my proposal in the other thread was to define the=
 state of the config at the time the client is notified.


Gert

Sent from my Apple ][

> On 16 Oct 2015, at 14:19, Robert Wilton  wrote:
>=20
> Hi Juergen,
>=20
>> On 15/10/2015 22:59, Juergen Schoenwaelder wrote:
>>> On Thu, Oct 15, 2015 at 05:03:33PM +0000, Kent Watsen wrote:
>>> These terms were edited on today's call, resulting in the following tex=
t:
>>>=20
>>>     Synchronous configuration operation - A configuration request to up=
date
>>>     the running configuration of a server that is applied synchronously=
 with
>>>     respect to the client request.  The server MUST fully attempt to ap=
ply
>>>     the configuration change to all impacted components in the server,
>>>     updating both the server's intended and applied configuration (see =
terms),
>>>     before replying to the client.  This may be transactional or non-
>>>     transactional (need terms!).  The transactionality of the operation
>>>     may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
>=20
> It was added in the meeting because some interpretations of the text assu=
med that the text implied that the server would always rollback-on-error, s=
o the proposed text was intended to clarify that.
>=20
> However, I think that this clarification applies equally to both sync and=
 async operations and hence I have proposed (on a separate thread) that it =
be documented as part of the requirement 3 "Support for both synchronous an=
d asynchronous configuration operations" instead.
>=20
> Thanks,
> Rob
>=20


From nobody Fri Oct 16 07:16:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090141B2C09 for ; Fri, 16 Oct 2015 07:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntfb5i4LiTm8 for ; Fri, 16 Oct 2015 07:16:55 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D271B1B2C06 for ; Fri, 16 Oct 2015 07:16:53 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 14:16:52 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 14:16:51 +0000
From: Gert Grammel 
To: Kent Watsen 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIGAALIfAIAAS+nk
Date: Fri, 16 Oct 2015 14:16:51 +0000
Message-ID: <381B554A-3421-4AC9-AB9B-FB2F6C670C3E@juniper.net>
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.111.78]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB455; 5:Gt2GEX8lqbLshTLdrcsecF/cKskFsFIP+RrYvdvqN5a1M7X4L2Spj+Dsm0Qsha5loFZO6jsb0lPnh/oxtzUgFXGIoZUtSbBl7IN62I9GxdT046xkGw8lJX3B4OhAteZi8mobJK6R7IWzczpkSLI/wg==; 24:rs1cpZhpEPoArCBvn8WpqJp9JO80/a0j+mBhR9aTmyKGy9Flbb97KfRq4VDroAwzMX/6RL0Ytg/Wdi88MuPRUcrUdbV6mguujkZXZcA8AZU=; 20:6b2CF0tfN+b3+B8AreHRXCMw4Lf/mcvlegomkOKmhnt1L/MlL9Oto7RWbjQVXvGQg+hSuslvoAzNn30QncoF/w==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB455; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB455; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(76104003)(24454002)(189002)(76176999)(87936001)(97736004)(106356001)(40100003)(5002640100001)(122556002)(5001960100002)(561944003)(189998001)(92566002)(99286002)(4001450100002)(19580405001)(102836002)(36756003)(10400500002)(5004730100002)(93886004)(5007970100001)(86362001)(110136002)(81156007)(66066001)(64706001)(105586002)(54356999)(106116001)(1941001)(83716003)(50986999)(101416001)(16236675004)(19580395003)(2900100001)(82746002)(5008740100001)(2950100001)(33656002)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_381B554A34214AC9AB9BFB2F6C670C3Ejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 14:16:51.5337 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:16:57 -0000

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

Kent,

The new one looks much better. However the last sentence is confusing with =
respect to intended config. Why is there a need to update the intended conf=
ig?

Proposal:
The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating the server's applied configuration (see terms),
    before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen > wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers=
.

Thank you (and Juergen) for the confirmation.   Again, if no objections, th=
ese two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning=
 of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as b=
eing discussed elsewhere on this thread]

OLD:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.

NEW

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request (i.e. a blocking call).  The server MUST =
fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.


What do you think?

Kent


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







Kent,







The new one looks much better. However the l=
ast sentence is confusing with respect to intended config. Why is there a n=
eed to update the intended config?







Proposal:






The server MUST fully attempt to apply 

    the configuration change to all impacted componen=
ts in the server,


    updating the server's applied configuration (see =
terms),


    before replying to the client.




Sent from my Apple ][




On 16 Oct 2015, at 15:45, Kent Watsen <kwatsen@juniper.net> wrote:















Gert writes:


> I don't see the need for defining synchronous/asynchronous config=
 servers.







Thank you (and Juergen) for the confirmation.   Again, if no obje=
ctions, these two terms will not be removed.















> The new definitions look good. Later in=
 the discussion there was a common





> sentiment that the requirement for synchronous operations contain=
ed some


> crisp wording we could use here too.  I particularly liked t=
he mentioning of


> blocking requests for some time,







[Note: the following removes the last two sentences on "transacti=
ons", as being discussed elsewhere on this thread]







OLD:









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request.  The server MUST ful=
ly attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.









NEW









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request (i.e. a blocking call). &n=
bsp;The server MUST fully attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.


























What do you think?


















Kent













--_000_381B554A34214AC9AB9BFB2F6C670C3Ejunipernet_--


From nobody Fri Oct 16 07:19:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C401B2C0C for ; Fri, 16 Oct 2015 07:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucc3JI_2m3D5 for ; Fri, 16 Oct 2015 07:18:59 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8B61A1BE6 for ; Fri, 16 Oct 2015 07:18:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBC851018; Fri, 16 Oct 2015 16:18:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id f2knbGF4BcwB; Fri, 16 Oct 2015 16:18:45 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Oct 2015 16:18:45 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BC8C2004E; Fri, 16 Oct 2015 16:18:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ksmxuBt98aag; Fri, 16 Oct 2015 16:18:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0007620053; Fri, 16 Oct 2015 16:18:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CA12A37B60C7; Fri, 16 Oct 2015 16:18:42 +0200 (CEST)
Date: Fri, 16 Oct 2015 16:18:41 +0200
From: Juergen Schoenwaelder 
To: De Noia Giuseppe 
Message-ID: <20151016141841.GA74475@elstar.local>
Mail-Followup-To: De Noia Giuseppe , "netmod@ietf.org" 
References: <167E7B4797E08C4DBC40AED09620195944BFEEF0@TELMBA001BA020.telecomitalia.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <167E7B4797E08C4DBC40AED09620195944BFEEF0@TELMBA001BA020.telecomitalia.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] About correlation between snmp alarms and yang structures
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 14:19:03 -0000

Hi,

if you implement the ietf-interfaces YANG module including the if-mib
feature, then /interfaces-state/interface/if-index provides you the
ifIndex value that MIB modules usually use to identify an interface.

/js

On Fri, Oct 16, 2015 at 02:04:38PM +0000, De Noia Giuseppe wrote:
> Hi guys,
> I have a question about Yang language support for snmp alarm correlation.
> It could be nice if a device supplier, specifying the Yang model of his network element, could also specify the correspondence between snmp alarms produced and affected part of the yang model of its device. This will allow for correlation between snmp traps (or other events) affecting a given object  and the service instance created (through Netconf/yang) on that object.
> 
> As for example, let's say a device send the following trap
> 
> xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/2015 14:13:27
>   Time stamp: 0 days 00h:00m:40s.15th
>   Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: SNMPv2c Notification
>   Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
>   Community: public
>   Enterprise: enterprises.8072.3.2.10
>   Bindings (8)
>     Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
>     Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
>     Binding #3: ifIndex.6 *** (int32) 6
>     Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
>     Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
>     Binding #6: ifAdminStatus.6 *** (int32) down(2)
>     Binding #7: ifOperStatus.6 *** (int32) down(2)
>     Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10
> 
> On the same device I created a service instance, which consists on an interface configuration . The interface, described through the YANG model is the following
> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']
> 
> Actually the SNMP trap impacts on the same interface where I configured my service instance, but I have no means to understand it.
> 
> How can I enrich my YANG model to support the information that a trap with oid= snmpTraps.3 and ifDescr = dp0s3 affect the same interface described in Yang by the xpath expression /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']?
> 
> Do I need to define a new YANG extension statement to carry on such a correspondence, or can I rely on existing structures?
> 
> Regards,
> Giuseppe De Noia
> 
> 
> 
> 
> ------------------------------------------------------------------
> Telecom Italia
> Giuseppe De Noia
> T.TG.NM.OSI,
> Via Reiss Romoli, 274  10148 Torino
> 011 2288887
> 331 6001197
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
> 
> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
> 


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


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Oct 16 08:03:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4D1B30EB for ; Fri, 16 Oct 2015 08:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8PF7jrOxcss for ; Fri, 16 Oct 2015 08:03:35 -0700 (PDT)
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (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 A03B31B2D8E for ; Fri, 16 Oct 2015 08:03:34 -0700 (PDT)
Received: by lfaz124 with SMTP id z124so80943111lfa.1 for ; Fri, 16 Oct 2015 08:03:32 -0700 (PDT)
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=Sqs5mH7Cbq4IMNcXDaVdq1P8AxgGYbXZediZ49Y0jFE=; b=XYOVyzNIDBFmlIbDv9oPdzNi59sg4irX3CORjwaFVFzZNwYRZgexxEoq5v/tWesonq 7Bk3hiPaOtnExASsRCoMUilVe22TZA4NfcJdN3C/KDgMbdHF1WjpIlcSCB6q+7k23YCw 7ZITz2MOqaSos/zUc8GtAMwf/e4Mop8xXYuiHSAg1XsUzoc/EXIXZXJe/xrAd7OrwqBo NZWN5YLlh9PQXUAVOLBBlOayAmt83WbvOv9wKgv9SNP+96mmkmTwPs27XgFmqUDO8O2e vs77IKGv8uPwoSrLbEsx0rJFTxD5qFSUp+ThT+iQXkECYFMC6s17mX/sWNB6HqfXiOpZ NPzQ==
X-Gm-Message-State: ALoCoQkBfCLI/bX9AR/6vZEEfyK9GkAJGuTVG+BMqkZj5fwYsHOMqpi+sceg4r7KgFvpmIVV2NFX
MIME-Version: 1.0
X-Received: by 10.25.155.75 with SMTP id d72mr5632579lfe.33.1445007812594; Fri, 16 Oct 2015 08:03:32 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Fri, 16 Oct 2015 08:03:32 -0700 (PDT)
In-Reply-To: <20151016.140143.1643639652175921028.mbj@tail-f.com>
References: <561FC736.6030903@ericsson.com>  <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com>
Date: Fri, 16 Oct 2015 08:03:32 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11401bd25e3ce805223a1940
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:03:37 -0000

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

Hi,

I find all this fretting over when-stmt corner-cases to be a waste of time.
I certainly have no intention of spending 100s of hours coding for
corner-cases
that have no operational value whatsoever.  When-stmt has always been full
of problems that exist on paper but not in real servers.

There is no need for the YANG spec to point out that the constraints
only apply to YANG. That is self-evident.

Why doesn't when-stmt apply to a plain rpc?


   rpc plot-point {
     input {
        leaf 3d {
          type boolean;
           default false;
        }
        leaf X { type uint32; }
        leaf Y { type uint32; }
        leaf Z {
          when "../3d";
          type uint32;
       }
     }
   }


Are you saying that the when-stmt for Z is not allowed?
Or that it gets ignored and not enforced?
IMO this section was rather clear -- it applies to when-stmt
in the RPC input.


Andy


On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund  wrote:

> Hi,
>
> Balazs Lengyel  wrote:
> > Hello Andy, Martin,
> > If that is what is meant by 8.2.1 then I have a few comments
>
> Sorry for the confusion on this topic.  I have now done some digging
> in the archives and I think that section 8.2 is really intended to
> apply only to *configuration data* (which it actually says upfront).
> The text in 8.2.1 is not intended to be for generic rpcs; it is
> intended for rpcs that modify configuration datastores (edit-config).
>
> The whole idea is that there are really three points in time where
> "checks" are done - (1) simple type checks and structural checks when
> the edit-config is parsed (2) check that the requested _operations_
> are valid and (3) check that the _resulting datastore_ is valid.
>
> This said, note that section 8.1 applies to *all* valid data trees,
> including rpc/action input/output.
>
> So, in summary, 8.1 defines the generic rules for valid data trees,
> and 8.2 defines the NETCONF-specific behavior for edit-config
> processing.
>
> In order to resolve Balazs' original issue, we need to agree what
> should happen in these cases *for NETCONF*.
>
> Suppose we have:
>
>  leaf a {
>    when "../b = 42";
>    type int32;
>  }
>  leaf b {
>    type int32;
>  }
>
>
> Scenario A
> ----------
> The DB contains b=10
>
> The server gets an edit-config with:
>
>    2
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok; the request to set a to 2 is silently dropped
>
>
> Scenario B
> ----------
> The DB contains b=10.
>
> The server gets an edit-config with:
>
>    2
>    42
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok, db now has b=42; the request to set a to 2 is silently
>      dropped
>  3)  ok, db now has a=2 and b=42
>
>
> Scenario C  (same as 2, but different order in edit-config)
> ----------
> The DB contains b=10.
>
> The server gets an edit-config with:
>
>    42
>    2
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok, db now has b=42; the request to set a to 2 is silently
>      dropped
>  3)  ok, db now has a=2 and b=42
>
>
>
> /martin
>

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


Hi,

I find all this fretting over when-=
stmt corner-cases to be a waste of time.
I certainly have no inte=
ntion of spending 100s of hours coding for corner-cases
that have=
 no operational value whatsoever.=C2=A0 When-stmt has always been full
of problems that exist on paper but not in real servers.
There is no need for the YANG spec to point out that the const=
raints
only apply to YANG. That is self-evident.

Why doesn't when-stmt apply to a plain rpc?


=C2=A0 =C2=A0rpc plot-point {
=C2=A0 =C2=A0=
 =C2=A0input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf 3d {=C2=A0
<=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default false;
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf X { type uint32; }<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf Y { type uint32; }
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 leaf Z {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 when "../3d";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ty=
pe uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =
=C2=A0}
=C2=A0 =C2=A0}


Ar=
e you saying that the when-stmt for Z is not allowed?
Or that it =
gets ignored and not enforced?
IMO this section was rather clear =
-- it applies to when-stmt
in the RPC input.

=


Andy


On Fri, Oct 16, 2015 at 5:01 AM, Martin B=
jorklund <mbj@tail-f.com> wrote:
Hi,



Balazs Lengyel <balazs.le=
ngyel@ericsson.com> wrote:

> Hello Andy, Martin,

> If that is what is meant by 8.2.1 then I have a few comments



Sorry for the confusion on this topic.=C2=A0 I have now done some digging
in the archives and I think that section 8.2 is really intended to

apply only to *configuration data* (which it actually says upfront).

The text in 8.2.1 is not intended to be for generic rpcs; it is

intended for rpcs that modify configuration datastores (edit-config).



The whole idea is that there are really three points in time where

"checks" are done - (1) simple type checks and structural checks =
when

the edit-config is parsed (2) check that the requested _operations_

are valid and (3) check that the _resulting datastore_ is valid.



This said, note that section 8.1 applies to *all* valid data trees,

including rpc/action input/output.



So, in summary, 8.1 defines the generic rules for valid data trees,

and 8.2 defines the NETCONF-specific behavior for edit-config

processing.



In order to resolve Balazs' original issue, we need to agree what

should happen in these cases *for NETCONF*.



Suppose we have:



=C2=A0leaf a {

=C2=A0 =C2=A0when "../b =3D 42";

=C2=A0 =C2=A0type int32;

=C2=A0}

=C2=A0leaf b {

=C2=A0 =C2=A0type int32;

=C2=A0}





Scenario A

----------

The DB contains b=3D10



The server gets an edit-config with:



=C2=A0 =C2=A0<a>2</a>



What is the result?



=C2=A01)=C2=A0 an error is returned

=C2=A02)=C2=A0 ok; the request to set a to 2 is silently dropped





Scenario B

----------

The DB contains b=3D10.



The server gets an edit-config with:



=C2=A0 =C2=A0<a>2</a>

=C2=A0 =C2=A0<b>42</b>



What is the result?



=C2=A01)=C2=A0 an error is returned

=C2=A02)=C2=A0 ok, db now has b=3D42; the request to set a to 2 is silently=


=C2=A0 =C2=A0 =C2=A0dropped

=C2=A03)=C2=A0 ok, db now has a=3D2 and b=3D42





Scenario C=C2=A0 (same as 2, but different order in edit-config)

----------

The DB contains b=3D10.



The server gets an edit-config with:



=C2=A0 =C2=A0<b>42</b>

=C2=A0 =C2=A0<a>2</a>



What is the result?



=C2=A01)=C2=A0 an error is returned

=C2=A02)=C2=A0 ok, db now has b=3D42; the request to set a to 2 is silently=


=C2=A0 =C2=A0 =C2=A0dropped

=C2=A03)=C2=A0 ok, db now has a=3D2 and b=3D42







/martin





--001a11401bd25e3ce805223a1940--


From nobody Fri Oct 16 08:20:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984B41B313C for ; Fri, 16 Oct 2015 08:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBxOrZiVBwNg for ; Fri, 16 Oct 2015 08:20:06 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6841B312B for ; Fri, 16 Oct 2015 08:19:49 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB048.namprd05.prod.outlook.com (10.242.34.156) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 15:19:47 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 15:19:47 +0000
From: Kent Watsen 
To: Gert Grammel 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIGAALIfAIAAS+nk///OgQA=
Date: Fri, 16 Oct 2015 15:19:47 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>  <381B554A-3421-4AC9-AB9B-FB2F6C670C3E@juniper.net>
In-Reply-To: <381B554A-3421-4AC9-AB9B-FB2F6C670C3E@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; BY2PR05MB048; 5:45MJRdmJW6Y3hzmbYaxO66tEc+23GrjG6Av8V/a/6PqX8dpwS5chCZC1484xZQBxco3GwnOUb9dUk2fdvSzuOfe6kLUcvx4QX3LegUgVPR36eeYhJPJQ3nUuVeWiMDkfcWCtsZPl1KbWyH/EGHiIJg==; 24:NscFXUsBBeSmxyoIZRFVJWwaY15bzuRmxj3qhtfqqEsWnpte5YruziJpIrDgGvek6IxViv0FK/kSmnIvPVDpuc+3+zegV1QkLZKYj+spR3w=; 20:kFCjeWZ4+qntxTp48wqfNUqnTdD7vCzLwM0WoBviHWq6qbCbtTd/gAS2N5O6It5YXMMaDj0I4LSUlwFc+uJsYQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB048;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BY2PR05MB048; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB048; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(76104003)(24454002)(377454003)(99286002)(50986999)(10400500002)(87936001)(76176999)(122556002)(106356001)(97736004)(105586002)(66066001)(5002640100001)(64706001)(106116001)(4001350100001)(110136002)(5004730100002)(19580405001)(1941001)(40100003)(5001960100002)(54356999)(81156007)(19580395003)(93886004)(101416001)(92566002)(83506001)(86362001)(189998001)(561944003)(5008740100001)(46102003)(11100500001)(102836002)(4001450100002)(2900100001)(2950100001)(5007970100001)(5001920100001)(16236675004)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB048; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D2468D48E74CDkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:19:47.6014 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB048
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:20:08 -0000

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


> Why is there a need to update the intended config?

Because that is what happens via requests like  and PATCH.  Th=
e intended (running) config gets updated first and then config is distribut=
ed to internal components, ultimately updated the applied config.

Kent  // as a contributor


From: Gert Grammel >
Date: Friday, October 16, 2015 at 10:16 AM
To: Kent Watsen >
Cc: Robert Wilton >, "netmod@ie=
tf.org" >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy=
nchronous (esp. wrt intended and applied)

Kent,

The new one looks much better. However the last sentence is confusing with =
respect to intended config. Why is there a need to update the intended conf=
ig?

Proposal:
The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating the server's applied configuration (see terms),
    before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen > wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers=
.

Thank you (and Juergen) for the confirmation.   Again, if no objections, th=
ese two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning=
 of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as b=
eing discussed elsewhere on this thread]

OLD:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.

NEW

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request (i.e. a blocking call).  The server MUST =
fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.


What do you think?

Kent


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












> Why is there a need to update the intended config? 







Because that is what happens via requests like <edit-config> and=
 PATCH.  The intended (running) config gets updated first and then con=
fig is distributed to internal components, ultimately updated the applied c=
onfig.







Kent  // as a contributor














From: Gert Grammel <ggrammel@juniper.net>

Date: Friday, October 16, 2015 at 1=
0:16 AM

To: Kent Watsen <kwatsen@juniper.net>

Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap=
plied)













Kent,







The new one looks much better. However the l=
ast sentence is confusing with respect to intended config. Why is there a n=
eed to update the intended config?







Proposal:






The server MUST fully attempt to apply 

    the configuration change to all impacted componen=
ts in the server,


    updating the server's applied configuration (see =
terms),


    before replying to the client.




Sent from my Apple ][




On 16 Oct 2015, at 15:45, Kent Watsen <kwatsen@juniper.net> wrote:















Gert writes:


> I don't see the need for defining synchronous/asynchronous config=
 servers.







Thank you (and Juergen) for the confirmation.   Again, if no obje=
ctions, these two terms will not be removed.















> The new definitions look good. Later in=
 the discussion there was a common





> sentiment that the requirement for synchronous operations contain=
ed some


> crisp wording we could use here too.  I particularly liked t=
he mentioning of


> blocking requests for some time,







[Note: the following removes the last two sentences on "transacti=
ons", as being discussed elsewhere on this thread]







OLD:









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request.  The server MUST ful=
ly attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.









NEW









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request (i.e. a blocking call). &n=
bsp;The server MUST fully attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.


























What do you think?


















Kent


















--_000_D2468D48E74CDkwatsenjunipernet_--


From nobody Fri Oct 16 08:22:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709AE1B2FF7; Fri, 16 Oct 2015 08:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZaUfXSWoVnv; Fri, 16 Oct 2015 08:22:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17C1B3152; Fri, 16 Oct 2015 08:22:11 -0700 (PDT)
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.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151016152211.4503.27891.idtracker@ietfa.amsl.com>
Date: Fri, 16 Oct 2015 08:22:11 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-20.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:22:17 -0000

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

        Title           : A YANG Data Model for Routing Management
        Authors         : Ladislav Lhotka
                          Acee Lindem
	Filename        : draft-ietf-netmod-routing-cfg-20.txt
	Pages           : 69
	Date            : 2015-10-16

Abstract:
   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring and managing a routing subsystem.  It is
   expected that these modules will be augmented by additional YANG
   modules defining data models for routing protocols, route filters and
   other functions.  The core routing data model provides common
   building blocks for such extensions - routing instances, routes,
   routing information bases (RIB), and routing protocols.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 16 08:37:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB681B31A3 for ; Fri, 16 Oct 2015 08:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cohBu6gYdTFU for ; Fri, 16 Oct 2015 08:37:44 -0700 (PDT)
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 EB73D1B319B for ; Fri, 16 Oct 2015 08:37:41 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502] (unknown [IPv6:2001:718:1a02:1:c047:f00e:ed13:2502]) by mail.nic.cz (Postfix) with ESMTPSA id 9B7FC180C46; Fri, 16 Oct 2015 17:37:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445009860; bh=8GrC/3EbbcssA49kFPe18mEjuF8R5Ia3KCwRERITEKo=; h=From:Date:To; b=e+V+oz7v8mcDWzUa+qFNWrBWFQ0oyuDs6ZSqJoK/mrqSZ9/8o2mmAscx4ry9FRxyr bzAI0Z+YcimRlZWWZSHELltigh87l/B1C7NhHsUdbMWUXLV/zkDxy6jM8qfsiToC8s H7Ik15qGDTZ8WmoD0SkKiTmYvDwgkc3nterFNPG8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 16 Oct 2015 17:37:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <431E9D9D-4236-4026-9692-69110814E147@nic.cz>
References: <561FC736.6030903@ericsson.com>  <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:37:45 -0000

> On 16 Oct 2015, at 17:03, Andy Bierman  wrote:
>=20
> Hi,
>=20
> I find all this fretting over when-stmt corner-cases to be a waste of =
time.
> I certainly have no intention of spending 100s of hours coding for =
corner-cases
> that have no operational value whatsoever.  When-stmt has always been =
full
> of problems that exist on paper but not in real servers.

This may well be because YANG module authors so far have been aware of =
the pitfalls of "when". Now that YANG is mushrooming all around, it may =
change very soon.

Lada

>=20
> There is no need for the YANG spec to point out that the constraints
> only apply to YANG. That is self-evident.
>=20
> Why doesn't when-stmt apply to a plain rpc?
>=20
>=20
>    rpc plot-point {
>      input {
>         leaf 3d {=20
>           type boolean;
>            default false;
>         }
>         leaf X { type uint32; }
>         leaf Y { type uint32; }
>         leaf Z {
>           when "../3d";
>           type uint32;
>        }
>      }
>    }
>=20
>=20
> Are you saying that the when-stmt for Z is not allowed?
> Or that it gets ignored and not enforced?
> IMO this section was rather clear -- it applies to when-stmt
> in the RPC input.
>=20
>=20
> Andy
>=20
>=20
> On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund  =
wrote:
> Hi,
>=20
> Balazs Lengyel  wrote:
> > Hello Andy, Martin,
> > If that is what is meant by 8.2.1 then I have a few comments
>=20
> Sorry for the confusion on this topic.  I have now done some digging
> in the archives and I think that section 8.2 is really intended to
> apply only to *configuration data* (which it actually says upfront).
> The text in 8.2.1 is not intended to be for generic rpcs; it is
> intended for rpcs that modify configuration datastores (edit-config).
>=20
> The whole idea is that there are really three points in time where
> "checks" are done - (1) simple type checks and structural checks when
> the edit-config is parsed (2) check that the requested _operations_
> are valid and (3) check that the _resulting datastore_ is valid.
>=20
> This said, note that section 8.1 applies to *all* valid data trees,
> including rpc/action input/output.
>=20
> So, in summary, 8.1 defines the generic rules for valid data trees,
> and 8.2 defines the NETCONF-specific behavior for edit-config
> processing.
>=20
> In order to resolve Balazs' original issue, we need to agree what
> should happen in these cases *for NETCONF*.
>=20
> Suppose we have:
>=20
>  leaf a {
>    when "../b =3D 42";
>    type int32;
>  }
>  leaf b {
>    type int32;
>  }
>=20
>=20
> Scenario A
> ----------
> The DB contains b=3D10
>=20
> The server gets an edit-config with:
>=20
>    2
>=20
> What is the result?
>=20
>  1)  an error is returned
>  2)  ok; the request to set a to 2 is silently dropped
>=20
>=20
> Scenario B
> ----------
> The DB contains b=3D10.
>=20
> The server gets an edit-config with:
>=20
>    2
>    42
>=20
> What is the result?
>=20
>  1)  an error is returned
>  2)  ok, db now has b=3D42; the request to set a to 2 is silently
>      dropped
>  3)  ok, db now has a=3D2 and b=3D42
>=20
>=20
> Scenario C  (same as 2, but different order in edit-config)
> ----------
> The DB contains b=3D10.
>=20
> The server gets an edit-config with:
>=20
>    42
>    2
>=20
> What is the result?
>=20
>  1)  an error is returned
>  2)  ok, db now has b=3D42; the request to set a to 2 is silently
>      dropped
>  3)  ok, db now has a=3D2 and b=3D42
>=20
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Fri Oct 16 08:42:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348511A916E for ; Fri, 16 Oct 2015 08:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 6NsG-4xu0YdS for ; Fri, 16 Oct 2015 08:42:27 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECBF1A9166 for ; Fri, 16 Oct 2015 08:42:26 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-f9-56211ae13581
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.97.17026.1EA11265; Fri, 16 Oct 2015 17:42:25 +0200 (CEST)
Received: from [159.107.197.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Fri, 16 Oct 2015 17:42:24 +0200
To: Andy Bierman , Martin Bjorklund 
References: <561FC736.6030903@ericsson.com>  <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com> 
From: Balazs Lengyel 
Message-ID: <56211AE0.9020105@ericsson.com>
Date: Fri, 16 Oct 2015 17:42:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvje5DKcUwg6dbxCweHJnFbtHd/Yzd Yv7FRlYHZo8lS34yeWz8tZjFo6X/IksAcxSXTUpqTmZZapG+XQJXxoGFU9gKPlhVfPvax97A uFili5GTQ0LAROLms7NMELaYxIV769m6GLk4hASOMkq8/jCNCcJZyyjxsukDK0iVsICxxLH1 rSxdjBwcIgIeEmvmuEHUTGKSOPDsOQtIDbOAusSdU4/ZQGw2ASOJqf3nwep5BbQlju9OBQmz CKhKrP3ZDVYuKhAj8X7TKkYQm1dAUOLkzCdgcU6BQIl/cy8xQ4zUkGidM5cdwpaXaN46Gywu BBR/eOEv6wRGwVlI2mchaZmFpGUBI/MqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMAQPrjl t+4OxtWvHQ8xCnAwKvHwKkQphAmxJpYVV+YeYpTmYFES521hehAqJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgbFFacVk9b9+7jni65rd3PR2NyrtUvkj9fHkL93YmyfmzJ7LK1qRvMjtvtva lZqfm1pzCur/7Z6heijo7sFPF060n+5TrVjU3Sl7v6VD8Wzh7Xtz3wmy/L3mMHHWxkZpmR/u WatMol6+fTXZPWXPU7u75rocp2MWn2l4cc3833xje16x+3Ji09qUWIozEg21mIuKEwF0UXl6 QgIAAA==
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:42:30 -0000


  
    
  
  
    Hello,

    I don't have a problem with the when in rpc/action as it is a simple
    case, it is meaningful understandable. I have problems with the
    undespecified behavior of when in  edit-config and with the MANY!
    complicated "corner" cases. I would love to just prohibit 90% of
    them.

    regards Balazs

    

    
On 2015-10-16 17:03, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I find all this fretting over when-stmt corner-cases to be
          a waste of time.

        
I certainly have no intention of spending 100s of hours
          coding for corner-cases

        
that have no operational value whatsoever.  When-stmt has
          always been full

        
of problems that exist on paper but not in real servers.

        


        

        
There is no need for the YANG spec to point out that the
          constraints

        
only apply to YANG. That is self-evident.

        


        

        
Why doesn't when-stmt apply to a plain rpc?

        


        

        


        

        
   rpc plot-point {

        
     input {

        
        leaf 3d { 

        
          type boolean;

        
           default false;

        
        }

        
        leaf X { type uint32; }

        
        leaf Y { type uint32; }

        
        leaf Z {

        
          when "../3d";

        
          type uint32;

        
       }

        
     }

        
   }

        


        

        


        

        
Are you saying that the when-stmt for Z is not allowed?

        
Or that it gets ignored and not enforced?

        
IMO this section was rather clear -- it applies to
          when-stmt

        
in the RPC input.

        


        

        


        

        
Andy

        


        

      

      


        
On Fri, Oct 16, 2015 at 5:01 AM, Martin
          Bjorklund <mbj@tail-f.com>
          wrote:

          
Hi,

            

            Balazs Lengyel <balazs.lengyel@ericsson.com>
            wrote:

            > Hello Andy, Martin,

            > If that is what is meant by 8.2.1 then I have a few
            comments

            

            Sorry for the confusion on this topic.  I have now done some
            digging

            in the archives and I think that section 8.2 is really
            intended to

            apply only to *configuration data* (which it actually says
            upfront).

            The text in 8.2.1 is not intended to be for generic rpcs; it
            is

            intended for rpcs that modify configuration datastores
            (edit-config).

            

            The whole idea is that there are really three points in time
            where

            "checks" are done - (1) simple type checks and structural
            checks when

            the edit-config is parsed (2) check that the requested
            _operations_

            are valid and (3) check that the _resulting datastore_ is
            valid.

            

            This said, note that section 8.1 applies to *all* valid data
            trees,

            including rpc/action input/output.

            

            So, in summary, 8.1 defines the generic rules for valid data
            trees,

            and 8.2 defines the NETCONF-specific behavior for
            edit-config

            processing.

            

            In order to resolve Balazs' original issue, we need to agree
            what

            should happen in these cases *for NETCONF*.

            

            Suppose we have:

            

             leaf a {

               when "../b = 42";

               type int32;

             }

             leaf b {

               type int32;

             }

            

            

            Scenario A

            ----------

            The DB contains b=10

            

            The server gets an edit-config with:

            

               <a>2</a>

            

            What is the result?

            

             1)  an error is returned

             2)  ok; the request to set a to 2 is silently dropped

            

            

            Scenario B

            ----------

            The DB contains b=10.

            

            The server gets an edit-config with:

            

               <a>2</a>

               <b>42</b>

            

            What is the result?

            

             1)  an error is returned

             2)  ok, db now has b=42; the request to set a to 2 is
            silently

                 dropped

             3)  ok, db now has a=2 and b=42

            

            

            Scenario C  (same as 2, but different order in edit-config)

            ----------

            The DB contains b=10.

            

            The server gets an edit-config with:

            

               <b>42</b>

               <a>2</a>

            

            What is the result?

            

             1)  an error is returned

             2)  ok, db now has b=42; the request to set a to 2 is
            silently

                 dropped

             3)  ok, db now has a=2 and b=42

            

                

                

                /martin

              

        

        

      

    

    

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


  



From nobody Fri Oct 16 08:44:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9491B31ED for ; Fri, 16 Oct 2015 08:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cdfXXNlU_1L for ; Fri, 16 Oct 2015 08:44:28 -0700 (PDT)
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 1325A1B31C8 for ; Fri, 16 Oct 2015 08:44:28 -0700 (PDT)
Received: by lfeh64 with SMTP id h64so78276905lfe.3 for ; Fri, 16 Oct 2015 08:44:26 -0700 (PDT)
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=4LFm6wTtM7iYE64XT0Pwtmd68mdH4wsCySGePFlIbNM=; b=cyP1Yh9MZ7FDKORRYwdHJ9wIIY4VbeElZjwrMeUjkSCV9O5+THqOJIQYsaFfomQ0Lc fCLqnWERiX6QpsCWG/fPGcBRnpVCAf5ze2HixWIcfxbiPN/VXkShniTkQQzb7GCzi/II V9QK9wzqCg9WJuvHFS1IKmacyTMkaksoCAbMFtiece/EBd9RnZACKiP52tUUPC5MOZN2 45jVVi7OIDpxzInO7Pob0bKVcFW0yVsFhxl1C9EDq806BYKhTwHRYBTiQKNAPyTI0+Qf t2WXVLY+esYrZGOaAxY4HtZzuLJH1ivu9D4142JR1rKtsPfhBpgL3W8o/cI2ZneBUM4d Pedg==
X-Gm-Message-State: ALoCoQkTueXs7AzDvG0+LskabGe67iWELXoeaQftUGVfdBOGbs6yrpV8W/7NvJSQsY+u3QRhOXzV
MIME-Version: 1.0
X-Received: by 10.25.44.80 with SMTP id s77mr5565273lfs.37.1445010266229; Fri, 16 Oct 2015 08:44:26 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Fri, 16 Oct 2015 08:44:25 -0700 (PDT)
In-Reply-To: <20151016.142315.2294973158906063871.mbj@tail-f.com>
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com>
Date: Fri, 16 Oct 2015 08:44:25 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a114109169daf1e05223aab14
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:44:32 -0000

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

On Fri, Oct 16, 2015 at 5:23 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > Hi Kent,
> >
> > Here is my attempt at word smithing section 3:
> >
> > The old D and E have been merged together (now labelled as C).  A new
> > D has been added to try and define transactional error handling
> > semantics without introducing the term transactional.
> >
> >
> >    3.  Support for both synchronous and asynchronous configuration
> >        operations
> >
> >        A. A server may choose to support only synchronous configuration
> >           operations, or only asynchronous configuration operations, or
> >           both synchronous and asynchronous configuration operations in
> >           a client specified per-operation basis.
>
> I think the most common mode *today* is a mix of sync/async, on a
> per-object basis.  Is this mode no longer valid?
>

good question.
I am curious how this synchronous return will be deployed.
Is the intent to rewrite NETCONF and RESTCONF so they have
some mechanism like "don't return until intended =3D=3D applied".


Andy


>
> >        B. Support for synchronous operations as per the definition of
> >           "synchronous configuration operation".
>
> Doesn't this follow from A?
>
> >        C. Support for asynchronous operations as per the definition of
> >           "asynchronous configuration operation".  Servers that support
> >           asynchronous configuration operations MAY also provide a
> >           verify operation that a client can request from the server to
> >           return information regarding the difference between the
> >           intended and applied configurations.
> >
> >        D. Support for best effort and rollback-on-error error handling
> >           semantics.  The configuration protocol, or default server
> >           behavior, MUST specify whether the configuration is applied
> >           in a best effort fashion, or using "rollback on error"
> >           semantics - where all configuration changes in the request ar=
e
> >           undone if processing of any part of the configuration update
> >           failed.  A configuration protocol, or server, SHOULD provide
> >           support for rollback-on-error behavior and MAY choose to
> >           provide support for best effort semantics as well.
>
>
> /martin
>
>
> >
> > Any comments?
> >
> > Thanks,
> > Rob
> >
> >
> > On 15/10/2015 18:32, Kent Watsen wrote:
> > > Again, with better formatting for the list:
> > >
> > >     3.  Support for both synchronous and asynchronous configuration
> > >         operations (see terms)
> > >
> > >         A. A server may only support synchronous configuration
> > >            operations, or may only support asynchronous configuration
> > >            operations, or may support synchronicity to be client
> > >            specified on a per-operation basis.
> > >
> > >
> > >         C. Support for synchronous configuration operations
> > >            requires the server to block sending a response to
> > >            the client until it is able to able to determine whether
> > >            there are any errors in the request or errors from
> > >            applying the configuration change.
> > >              D. Support for asynchronous configuration operations
> > >            requires the server to send a response to the client
> > >            immediately indicated that the request was accepted
> > >            and send a notification to the client when the intended
> > >            config is fully effective or there are any errors from
> > >            applying the configuration change.
> > >
> > >         E. Support for asynchronous configuration operations MAY
> > >            also provide a verify operation which a client can request
> > >            from the server to obtain information regarding the
> > >            difference between the intended and applied configurations=
.
> > >
> > >
> > > Kent
> > >
> > >
> > >
> > > On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:
> > >
> > >> Requirement #3 was discussed on today's call.  We agreed to remove t=
he
> > >> words "distributed" and "transactional" and to reword it in terms of
> > >> "configuration operations".  The resulting text follows:
> > >>
> > >>
> > >>    3.  Support for both synchronous and asynchronous configuration
> > >> operations (see terms)
> > >>
> > >>        A. A server may only support synchronous configuration
> operations,
> > >> or may only support
> > >>           asynchronous configuration operations, or may support
> > >> synchronicity to be client
> > >>           specified on a per-operation basis.
> > >>
> > >>
> > >>        C. Support for synchronous configuration operations requires
> the
> > >> server to block
> > >>           sending a response to the client until it is able to able =
to
> > >> determine whether
> > >>           there are any errors in the request or errors from applyin=
g
> the
> > >> configuration
> > >>           change.
> > >>            D. Support for asynchronous configuration operations
> requires
> > >>            the
> > >> server to send
> > >>           a response to the client immediately indicated that the
> request
> > >> was accepted
> > >>           and send a notification to the client when the intended
> config
> > >> is fully
> > >>           effective or there are any errors from applying the
> > >> configuration change.
> > >>
> > >>        E. Support for asynchronous configuration operations MAY also
> > >> provide a verify
> > >>           operation which a client can request from the server to
> obtain
> > >> information
> > >>           regarding the difference between the intended and applied
> > >> configurations.
> > >>
> > >>
> > >>
> > >> We have consensus on the above, but wanted to rewrite it relying mor=
e
> > >> on
> > >> the terms from the Terminology section, and also potentially merge E
> > >> into
> > >> D.
> > >>
> > >> Anybody want to take a stab at it?
> > >>
> > >> Thanks,
> > >> Kent
> > >>
> > >>
> > >>
> > >> On 10/14/15, 8:00 PM, "Nadeau Thomas" 
> wrote:
> > >>
> > >>>> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen <
> kwatsen@juniper.net>
> > >>>> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
> > >>>>  wrote:
> > >>>>
> > >>>>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
> > >>>>>> Popping the stack on this issue, the issue remains as to what to
> do
> > >>>>>> with requirement 3:
> > >>>>>>
> > >>>>>>    3.  Support for both transactional, synchronous management
> systems
> > >>>>>>         as well as distributed, asynchronous management systems
> > >>>>>>
> > >>>>> I fail to understand 'transactional' and 'distributed' here.
> > >>>> I hope that these terms will be clarified on tomorrow's call.
>  There
> > >>>> is
> > >>>> also a chance that these terms will be removed from the text
> > >>>> altogether,
> > >>>> as they may be viewed as unnecessarily qualify the
> > >>>> synchronous/asynchronous terms.
> > >>>>
> > >>>>
> > >>>>> And
> > >>>>> frankly, I am not sure why the management _systems_ are classifie=
d
> to
> > >>>>> be synchronous or asynchronous - I think we are talking about
> > >>>>> protocols between a management system and a device.
> > >>>>
> > >>>> Aye, I didn't see that before.
> > >>>>
> > >>>> First off, elsewhere in the draft the term "system" is used 7 time=
s
> to
> > >>>> refer to the device (e.g., NC/RC server).  The term "system" is
> > >>>> otherwise
> > >>>> not defined.
> > >>>>
> > >>>> But to your main point, we have been discussing the terms
> > >>>> a/synchronous
> > >>>> to
> > >>>> have to do with internal server processing of an edit request, but
> in
> > >>>> '3'
> > >>>> the terms are being used to qualify a management system, which can=
't
> > >>>> be
> > >>>> right.  I think that '3' should be rewritten to be a statement abo=
ut
> > >>>> devices, not a statement about management systems.
> > >>>   It might be better to frame this in terms of a client and a
> > >>> server.
> > >>>
> > >>>   =E2=80=B9Tom
> > >>>
> > >>>
> > >>>> Anyway, I am not sure 3. is properly worded until someone defines
> > >>>>> 'transactional', 'distributed', 'synchronous management systems'
> and
> > >>>>> 'asynchronous management systems'.
> > >>>> The agenda for tomorrow's interim!  :)
> > >>>>
> > >>>>
> > >>>> Kent
> > >>>>
> > >>>> _______________________________________________
> > >>>> netmod mailing list
> > >>>> netmod@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/netmod
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri, Oct 16, 2015 at 5:23 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Robert Wilton <rwilton@cisco.com> wrote:

> Hi Kent,

>

> Here is my attempt at word smithing section 3:

>

> The old D and E have been merged together (now labelled as C).=C2=A0 A=
 new

> D has been added to try and define transactional error handling

> semantics without introducing the term transactional.

>

>

>=C2=A0 =C2=A0 3.=C2=A0 Support for both synchronous and asynchronous co=
nfiguration

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 operations

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A. A server may choose to support only sync=
hronous configuration

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations, or only asynchrono=
us configuration operations, or

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0both synchronous and asynchron=
ous configuration operations in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a client specified per-operati=
on basis.



I think the most common mode *today* is a mix of sync/async, on a

per-object basis.=C2=A0 Is this mode no longer valid?
=

good question.
I am curious how this synchronous r=
eturn will be deployed.
Is the intent to rewrite NETCONF and REST=
CONF so they have
some mechanism like "don't return unti=
l intended =3D=3D applied".


An=
dy
=C2=A0



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 B. Support for synchronous operations as pe=
r the definition of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"synchronous configuratio=
n operation".



Doesn't this follow from A?



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 C. Support for asynchronous operations as p=
er the definition of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"asynchronous configurati=
on operation".=C2=A0 Servers that support

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asynchronous configuration ope=
rations MAY also provide a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0verify operation that a client=
 can request from the server to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return information regarding t=
he difference between the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended and applied configura=
tions.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 D. Support for best effort and rollback-on-=
error error handling

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0semantics.=C2=A0 The configura=
tion protocol, or default server

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behavior, MUST specify whether=
 the configuration is applied

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a best effort fashion, or u=
sing "rollback on error"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0semantics - where all configur=
ation changes in the request are

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0undone if processing of any pa=
rt of the configuration update

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0failed.=C2=A0 A configuration =
protocol, or server, SHOULD provide

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support for rollback-on-error =
behavior and MAY choose to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provide support for best effor=
t semantics as well.





/martin





>

> Any comments?

>

> Thanks,

> Rob

>

>

> On 15/10/2015 18:32, Kent Watsen wrote:

> > Again, with better formatting for the list:

> >

> >=C2=A0 =C2=A0 =C2=A03.=C2=A0 Support for both synchronous and asyn=
chronous configuration

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations (see terms)

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A. A server may only support syn=
chronous configuration

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operations, or may only =
support asynchronous configuration

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operations, or may suppo=
rt synchronicity to be client

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified on a per-opera=
tion basis.

> >

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C. Support for synchronous confi=
guration operations

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requires the server to b=
lock sending a response to

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client until it is a=
ble to able to determine whether

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are any errors in =
the request or errors from

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applying the configurati=
on change.

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D. Support for as=
ynchronous configuration operations

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requires the server to s=
end a response to the client

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 immediately indicated th=
at the request was accepted

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and send a notification =
to the client when the intended

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config is fully effectiv=
e or there are any errors from

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applying the configurati=
on change.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E. Support for asynchronous conf=
iguration operations MAY

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also provide a verify op=
eration which a client can request

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from the server to obtai=
n information regarding the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 difference between the i=
ntended and applied configurations.

> >

> >

> > Kent

> >

> >

> >

> > On 10/15/15, 1:22 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:

> >

> >> Requirement #3 was discussed on today's call.=C2=A0 We ag=
reed to remove the

> >> words "distributed" and "transactional" a=
nd to reword it in terms of

> >> "configuration operations".=C2=A0 The resulting tex=
t follows:

> >>

> >>

> >>=C2=A0 =C2=A0 3.=C2=A0 Support for both synchronous and asynch=
ronous configuration

> >> operations (see terms)

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A. A server may only support synch=
ronous configuration operations,

> >> or may only support

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asynchronous configur=
ation operations, or may support

> >> synchronicity to be client

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specified on a per-op=
eration basis.

> >>

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 C. Support for synchronous configu=
ration operations requires the

> >> server to block

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sending a response to=
 the client until it is able to able to

> >> determine whether

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there are any errors =
in the request or errors from applying the

> >> configuration

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change.

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D. Support for async=
hronous configuration operations requires

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the

> >> server to send

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a response to the cli=
ent immediately indicated that the request

> >> was accepted

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and send a notificati=
on to the client when the intended config

> >> is fully

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0effective or there ar=
e any errors from applying the

> >> configuration change.

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 E. Support for asynchronous config=
uration operations MAY also

> >> provide a verify

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operation which a cli=
ent can request from the server to obtain

> >> information

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regarding the differe=
nce between the intended and applied

> >> configurations.

> >>

> >>

> >>

> >> We have consensus on the above, but wanted to rewrite it rely=
ing more

> >> on

> >> the terms from the Terminology section, and also potentially =
merge E

> >> into

> >> D.

> >>

> >> Anybody want to take a stab at it?

> >>

> >> Thanks,

> >> Kent

> >>

> >>

> >>

> >> On 10/14/15, 8:00 PM, "Nadeau Thomas" <tnadeau@lucidvision.com> wrote:<=
br>
> >>

> >>>> On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen <=
kwatsen@juniper.net>

> >>>> wrote:

> >>>>

> >>>>

> >>>>

> >>>> On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"=
;

> >>>> <j.schoenwaelder@jacobs-university.de> wrote:

> >>>>

> >>>>> On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Wa=
tsen wrote:

> >>>>>> Popping the stack on this issue, the issue re=
mains as to what to do

> >>>>>> with requirement 3:

> >>>>>>

> >>>>>>=C2=A0 =C2=A0 3.=C2=A0 Support for both transa=
ctional, synchronous management systems

> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as well as d=
istributed, asynchronous management systems

> >>>>>>

> >>>>> I fail to understand 'transactional' and =
'distributed' here.

> >>>> I hope that these terms will be clarified on tomorrow=
's call.=C2=A0 =C2=A0There

> >>>> is

> >>>> also a chance that these terms will be removed from t=
he text

> >>>> altogether,

> >>>> as they may be viewed as unnecessarily qualify the
> >>>> synchronous/asynchronous terms.

> >>>>

> >>>>

> >>>>> And

> >>>>> frankly, I am not sure why the management _system=
s_ are classified to

> >>>>> be synchronous or asynchronous - I think we are t=
alking about

> >>>>> protocols between a management system and a devic=
e.

> >>>>

> >>>> Aye, I didn't see that before.

> >>>>

> >>>> First off, elsewhere in the draft the term "syst=
em" is used 7 times to

> >>>> refer to the device (e.g., NC/RC server).=C2=A0 The t=
erm "system" is

> >>>> otherwise

> >>>> not defined.

> >>>>

> >>>> But to your main point, we have been discussing the t=
erms

> >>>> a/synchronous

> >>>> to

> >>>> have to do with internal server processing of an edit=
 request, but in

> >>>> '3'

> >>>> the terms are being used to qualify a management syst=
em, which can't

> >>>> be

> >>>> right.=C2=A0 I think that '3' should be rewri=
tten to be a statement about

> >>>> devices, not a statement about management systems.
> >>>=C2=A0 =C2=A0It might be better to frame this in terms of =
a client and a

> >>> server.

> >>>

> >>>=C2=A0 =C2=A0=E2=80=B9Tom

> >>>

> >>>

> >>>> Anyway, I am not sure 3. is properly worded until som=
eone defines

> >>>>> 'transactional', 'distributed', &=
#39;synchronous management systems' and

> >>>>> 'asynchronous management systems'.

> >>>> The agenda for tomorrow's interim!=C2=A0 :)

> >>>>

> >>>>

> >>>> Kent

> >>>>

> >>>> _______________________________________________

> >>>> netmod mailing list

> >>>> netmod@ietf.org

> >>>> https://www.ietf.org/mailman/listi=
nfo/netmod

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@ietf.org

> >> https://www.ietf.org/mailman/listinfo/net=
mod

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

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

>

_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a114109169daf1e05223aab14--


From nobody Fri Oct 16 08:55:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC601B3266 for ; Fri, 16 Oct 2015 08:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI-ul9hVbBsk for ; Fri, 16 Oct 2015 08:55:04 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90541B3202 for ; Fri, 16 Oct 2015 08:55:03 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-bf-56211dd585b6
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.89.17026.5DD11265; Fri, 16 Oct 2015 17:55:01 +0200 (CEST)
Received: from [159.107.197.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Fri, 16 Oct 2015 17:55:01 +0200
To: Ladislav Lhotka , Andy Bierman 
References: <561FC736.6030903@ericsson.com>  <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com>  <431E9D9D-4236-4026-9692-69110814E147@nic.cz>
From: Balazs Lengyel 
Message-ID: <56211DD5.8030507@ericsson.com>
Date: Fri, 16 Oct 2015 17:55:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <431E9D9D-4236-4026-9692-69110814E147@nic.cz>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvje5VWcUwg7/frC0eHJnFbnFh1Vw2 i/kXG1kdmD2WLPnJ5LHp8h1Gj5b+iywBzFFcNimpOZllqUX6dglcGXM3d7EV7FGuePgmqIFx s1QXIyeHhICJxM1Je1ggbDGJC/fWs3UxcnEICRxllHiwdQoTSEJIYC2jxI2zESC2sICxxLH1 rWANIgJuEt07rzBBNBxikni/6wIbSIJZQF3izqnHYDabgJHE1P7zYA28AtoSSw7vBbNZBFQl Go6/YAWxRQViJN5vWsUIUSMocXLmE7AaTgEriZ8LVwPVcADNtAc6qAxivLzE9rdzmCFu05B4 eOEv6wRGwVlIumchdMxC0rGAkXkVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmD4HtzyW3cH 4+rXjocYBTgYlXh4FaIUwoRYE8uKK3MPMUpzsCiJ87YwPQgVEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwOhy5M7/r+96Dt9xmWuhsLt6063IA1/0VSLMjK6d2tGhLFjEufr01NeqPTFykzur 9IsXT3keGBHBNXNV/pMtD9Y/fZr39AB/Qh2fT1sEdzjzfH7HM1lRt85KTQlouZf4X23J/um1 RswnQitaOt6GJMp6Vh9MeZPVLfB31eaJn73zpmwu+7D2c4wSS3FGoqEWc1FxIgBgZWICQAIA AA==
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 15:55:06 -0000

Hello,
We already have embedded choice  and when in choice in the OSPF module 
https://tools.ietf.org/html/draft-ietf-ospf-yang-02.
So unless we do something fast the nasty complications will be happenning.
regards Balazs

On 2015-10-16 17:37, Ladislav Lhotka wrote:
>> On 16 Oct 2015, at 17:03, Andy Bierman  wrote:
>>
>> Hi,
>>
>> I find all this fretting over when-stmt corner-cases to be a waste of time.
>> I certainly have no intention of spending 100s of hours coding for corner-cases
>> that have no operational value whatsoever.  When-stmt has always been full
>> of problems that exist on paper but not in real servers.
> This may well be because YANG module authors so far have been aware of the pitfalls of "when". Now that YANG is mushrooming all around, it may change very soon.
>
> Lada
>
>> There is no need for the YANG spec to point out that the constraints
>> only apply to YANG. That is self-evident.
>>
>> Why doesn't when-stmt apply to a plain rpc?
>>
>>
>>     rpc plot-point {
>>       input {
>>          leaf 3d {
>>            type boolean;
>>             default false;
>>          }
>>          leaf X { type uint32; }
>>          leaf Y { type uint32; }
>>          leaf Z {
>>            when "../3d";
>>            type uint32;
>>         }
>>       }
>>     }
>>
>>
>> Are you saying that the when-stmt for Z is not allowed?
>> Or that it gets ignored and not enforced?
>> IMO this section was rather clear -- it applies to when-stmt
>> in the RPC input.
>>
>>
>> Andy
>>
>>
>> On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund  wrote:
>> Hi,
>>
>> Balazs Lengyel  wrote:
>>> Hello Andy, Martin,
>>> If that is what is meant by 8.2.1 then I have a few comments
>> Sorry for the confusion on this topic.  I have now done some digging
>> in the archives and I think that section 8.2 is really intended to
>> apply only to *configuration data* (which it actually says upfront).
>> The text in 8.2.1 is not intended to be for generic rpcs; it is
>> intended for rpcs that modify configuration datastores (edit-config).
>>
>> The whole idea is that there are really three points in time where
>> "checks" are done - (1) simple type checks and structural checks when
>> the edit-config is parsed (2) check that the requested _operations_
>> are valid and (3) check that the _resulting datastore_ is valid.
>>
>> This said, note that section 8.1 applies to *all* valid data trees,
>> including rpc/action input/output.
>>
>> So, in summary, 8.1 defines the generic rules for valid data trees,
>> and 8.2 defines the NETCONF-specific behavior for edit-config
>> processing.
>>
>> In order to resolve Balazs' original issue, we need to agree what
>> should happen in these cases *for NETCONF*.
>>
>> Suppose we have:
>>
>>   leaf a {
>>     when "../b = 42";
>>     type int32;
>>   }
>>   leaf b {
>>     type int32;
>>   }
>>
>>
>> Scenario A
>> ----------
>> The DB contains b=10
>>
>> The server gets an edit-config with:
>>
>>     2
>>
>> What is the result?
>>
>>   1)  an error is returned
>>   2)  ok; the request to set a to 2 is silently dropped
>>
>>
>> Scenario B
>> ----------
>> The DB contains b=10.
>>
>> The server gets an edit-config with:
>>
>>     2
>>     42
>>
>> What is the result?
>>
>>   1)  an error is returned
>>   2)  ok, db now has b=42; the request to set a to 2 is silently
>>       dropped
>>   3)  ok, db now has a=2 and b=42
>>
>>
>> Scenario C  (same as 2, but different order in edit-config)
>> ----------
>> The DB contains b=10.
>>
>> The server gets an edit-config with:
>>
>>     42
>>     2
>>
>> What is the result?
>>
>>   1)  an error is returned
>>   2)  ok, db now has b=42; the request to set a to 2 is silently
>>       dropped
>>   3)  ok, db now has a=2 and b=42
>>
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Fri Oct 16 09:01:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F731B32D2 for ; Fri, 16 Oct 2015 09:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q2_waJ9jX2De for ; Fri, 16 Oct 2015 09:01:31 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA28B1B32CE for ; Fri, 16 Oct 2015 09:01:29 -0700 (PDT)
Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB299.namprd05.prod.outlook.com (10.141.70.18) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 16:01:10 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 16:01:08 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 16:01:08 +0000
From: Kent Watsen 
To: Andy Bierman , Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAADg1gP//wZeA
Date: Fri, 16 Oct 2015 16:01:08 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:lh64HGiTq5Bxbsfd8ytrSZDNtZgaVncvI40IY1qBi0COtXkmvMca0cyFh004YwFrBKxsdSZl+uVGxZNB0/eL1VwdmfU8l70u+6YvMU9wkHACr70IfWKeNthsGBgxFz/5qYJfDYjVQafOheD8KZyqSQ==; 24:9MdNQgLcnI9q8Bis1elyYIV+QYtskXp5xpvyQ4S36dTDIbrLp+GkDhjJ9FbJghWJBmtXQuyilWx9ezkxZsFkYefRw+lLxESxnTuqaSV6JSA=; 20:dKrBw3zGq2hBtnsEpfAM4DM+S6zboBUkNYejOoMaCxqAabzBQY/TsYV5BDZ4tND3EurXrQempALqObowznrEsA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(102836002)(2900100001)(105586002)(81156007)(11100500001)(4001350100001)(97736004)(54356999)(50986999)(83506001)(19580395003)(5001770100001)(15975445007)(5007970100001)(92566002)(5004730100002)(64706001)(101416001)(99286002)(2950100001)(76176999)(36756003)(46102003)(66066001)(10400500002)(106356001)(122556002)(86362001)(40100003)(87936001)(16236675004)(93886004)(5008740100001)(19617315012)(189998001)(106116001)(5002640100001)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D246965EE750Ekwatsenjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:01:08.4939 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB299; 2:XPd1KV17jgtDqsMvnCuDY7MKDh8YBLnLEiHNUSWZEvjZh/1BoBuM60xRNSt6HQgcIEm8n4CmILLwr5Piz2vP3J3EalGt9BpAJyXb5gzwtEry/Y5i0P3SooTagjWxNYMMxMN20FuUF4cUNIl18iinxXfRshN9oJZbPIVkYZwdD94=; 23:vR9qNEU5cmNEdZ0Zbd0Pcf8At9jVHsHCe9Y1WA5Z0jv3pJ+zdPUV9YUFZ0yD3Mmu8YvuGUUHfhe2XuFXDC+Qbby10/iRGU0CeECrUElkKf6ePxS5KHgzDCjLSO+t7rp07w3NDFRRH36/nmkNLdTINHA+z3NKnxh/UfvZgO2Z3lX2tmIs05xE7wKD2zc5dJ6p
X-OriginatorOrg: juniper.net
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 16:01:39 -0000

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

Andy writes:
> I am curious how this synchronous return will be deployed.
> Is the intent to rewrite NETCONF and RESTCONF so they have
> some mechanism like "don't return until intended =3D=3D applied".

Yes.  And by example, imagine a new optional-to-implement query parameter c=
alled "block":

    PATCH https://example.com/restconf/data/foo?block=3Dtrue

Which means don't send the HTTP response until done *attempting* to apply t=
he configuration change to all impacted components in the server, updating =
both the server's intended and applied configuration.

Kent


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







Andy writes:


> I am curious how this synchronous return will be deployed.









> Is the intent to rewrite NETCONF and RESTCONF so they have


> some mechanism like "don't return until intended =3D=3D appl=
ied".





















Yes.  And by example, imagine a new optional-to-implement query p=
arameter called "block":




















Which means don't send the HTTP response until done *attempting* to ap=
ply the configuration change to all impacted components in the server, upda=
ting both the server's intended and applied configuration.







Kent









--_000_D246965EE750Ekwatsenjunipernet_--


From nobody Fri Oct 16 09:05:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643D21B3308 for ; Fri, 16 Oct 2015 09:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b5ILoVhMJVX for ; Fri, 16 Oct 2015 09:05:07 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7301C1B32CA for ; Fri, 16 Oct 2015 09:05:06 -0700 (PDT)
Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB203.namprd05.prod.outlook.com (10.255.206.21) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 16:05:05 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 16:05:03 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 16:05:03 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAMwICAABDngIAAHVSA
Date: Fri, 16 Oct 2015 16:05:03 +0000
Message-ID: <24CFE232-441E-453D-9597-B73820FF9A82@juniper.net>
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <20150928084013.GB95620@elstar.local>  <1F5AA600-F270-4AE7-B6CB-93FF6302449C@lucidvision.com>   <5620E9B3.60009@cisco.com>  <56210293.6060809@cisco.com>
In-Reply-To: <56210293.6060809@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.103.85]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:GzVZQpkkY2Qc4g3u7VBAC4tosweqiTH1K4vF47vAI7oJb4vu93ZEFqZLsovmkxNGvm9otxTVWfDxacFIkTdyDAZMY+b4USEjJvy5eIdgUzmRJFuXN13fzdIo8aHVODYq7/uE7y7foOeUQLEcgCT2Ow==; 24:edVA9gCjWGLALZ2MmdJf623rkx6Qzy5pQ05VXGIh1ycTCaQAIRupV0PZijHRtwSCgKRJ4u1XRCj7od0Ez2STlI6+w5Itl2kc8tNrxkP55H0=; 20:dFfI4IH4ROKAJ/jg0j0O4RSJNYfcKztIKNI5qN+VPxrjkTtHQv0+rOb2gINkf9x68Em8LcpJnXOv7TZTeOgU2Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(57704003)(377454003)(51444003)(52314003)(199003)(164054003)(479174004)(189002)(24454002)(64706001)(16236675004)(102836002)(189998001)(5008740100001)(106356001)(10400500002)(110136002)(106116001)(11100500001)(19617315012)(36756003)(66066001)(92566002)(15975445007)(2900100001)(2950100001)(33656002)(105586002)(81156007)(54356999)(50986999)(5001960100002)(551934003)(122556002)(99286002)(97736004)(5002640100001)(5004730100002)(101416001)(87936001)(5007970100001)(19580395003)(19580405001)(86362001)(93886004)(76176999)(83716003)(82746002)(46102003)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_24CFE232441E453D9597B73820FF9A82junipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:05:03.1197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB203; 2:8JFIaPt+qBqtnfHjm4TOWbYYZT1djBIT9NSUrjVQR1MB5GTBWLwRJHgNyN9Lq32KwcT19j0LrcAunnNXJg3AP3XmUJw0/G1EMGey5r8h6ZM8GaIQhG/TfdrlsuSD7BormFWBSenYCR2X7adaDzpcpVe5SMb3UAdjE+nQNk1YgKY=; 23:PVwRvmyeVPQpmtg/OlO23dpF5ZfRcGBWcXZpOgghOVxgwEu46KRpDY2S9qpqTClnwi/tobSetQwfKf8PcRvRwVB0eTCmDYKAg3A7bsofrwUZ9btd16d+UqDLyjylOCD7TQVCy3AUd+ekW9k/+cfy+siRAVLOsl+zPHkGh8mV2RwYucOxv42FJJd5V1iPSmi8
X-OriginatorOrg: juniper.net
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 16:05:13 -0000

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

Um9iLA0KDQpZZXMsIHdlIHNob3VsZCBwdWxsIHRoZSBlcnJvciBtb2RlcyBvZiBuZXRjb25mIGlu
dG8gdGhlIGRlZmluaXRpb24uIFRoZSBhdmFpbGFibGUgdGV4dCBsb29rcyByZWFkeSB0byBiZSB1
c2VkLg0KRm9yIHRoZSByZXN0IHdlIG1heSBuZWVkIHRvIGRlZmluZSBhIHJlcXVpcmVtZW50IHRo
YXQgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byByZXRyaWV2ZSB0aGUgZXJyb3IgaGFuZGxp
bmcgaW5mb3JtYXRpb24gZnJvbSB0aGUgc2VydmVyLiBJbiB0aGUgZW5kIHRoZSBjbGllbnQgbmVl
ZHMgdG8ga25vdyBpZiBpdCBoYXMgdG8gY2xlYW4gdXAgdGhlIG1lc3MgaW4gdGhlIHNlcnZlciBv
ciBub3QuDQoNCkluIHRoYXQgc2Vuc2UsIEknZCBkZWZpbmUgYSB0cmFuc2FjdGlvbiBhcyBhIGNv
bmZpZ3VyYXRpb24gY2hhbmdlIHRoYXQgY2FuIGJlIHJvbGxlZCBiYWNrIGJ5IHRoZSBzZXJ2ZXIu
DQoNCkdlcnQNCg0KU2VudCBmcm9tIG15IEFwcGxlIF1bDQoNCk9uIDE2IE9jdCAyMDE1LCBhdCAx
NTo1OSwgUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lz
Y28uY29tPj4gd3JvdGU6DQoNCkhpIEdlcnQsDQoNCk9uIDE2LzEwLzIwMTUgMTM6NTgsIEdlcnQg
R3JhbW1lbCB3cm90ZToNCkhpIFJvYiwNCg0KVGhlIHRleHQgbG9va3MgZ29vZC4gV2l0aCByZXNw
ZWN0IHRvIEQgd2UgcHJvYmFibHkgbmVlZCBtb3JlIHdvcmRzbWl0aGluZzoNCg0KIEQuIFN1cHBv
cnQgZm9yIGJlc3QgZWZmb3J0IGFuZCByb2xsYmFjay1vbi1lcnJvciBlcnJvciBoYW5kbGluZw0K
ICAgICAgICAgIHNlbWFudGljcy4gIFRoZSBjb25maWd1cmF0aW9uIHByb3RvY29sLCBvciBkZWZh
dWx0IHNlcnZlcg0KICAgICAgICAgIGJlaGF2aW9yLCBNVVNUIHNwZWNpZnkgd2hldGhlciB0aGUg
Y29uZmlndXJhdGlvbiBpcyBhcHBsaWVkDQogICAgICAgICAgaW4gYSBiZXN0IGVmZm9ydCBmYXNo
aW9uLCBvciB1c2luZyAicm9sbGJhY2sgb24gZXJyb3IiDQogICAgICAgICAgc2VtYW50aWNzIC0g
d2hlcmUgYWxsIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyBpbiB0aGUgcmVxdWVzdCBhcmUNCiAgICAg
ICAgICB1bmRvbmUgaWYgcHJvY2Vzc2luZyBvZiBhbnkgcGFydCBvZiB0aGUgY29uZmlndXJhdGlv
biB1cGRhdGUNCiAgICAgICAgICBmYWlsZWQuDQotLT4gaG93IHdvdWxkIHRoZSBjbGllbnQga25v
dyB0aGF0IGEgY2VydGFpbiBvcGVyYXRpb24gaXMgc3VwcG9ydGVkIGluIGFuIGF0b21pYyBvciBu
b24tYXRvbWljIG1hbm5lciBieSB0aGUgc2VydmVyLiBJbiBteSB2aWV3IHRoZSBkZWZhdWx0IHNo
b3VsZCBiZSB0aGUgY2xpZW50IGFzc3VtZXMgYmVzdCBlZmZvcnQgYW5kIHRoZSBzZXJ2ZXIgaXMg
YWxsb3dlZCB0byBkbyBiZXR0ZXIuDQoNCkVpdGhlciB0aGUgY2xpZW50IHdvdWxkIG5lZWQgdG8g
a25vdyB3aGF0IGVycm9yIHNlbWFudGljcyBhIHBhcnRpY3VsYXIgc2VydmVyIHdpbGwgYWx3YXlz
IHVzZSB0byBhcHBseSBjb25maWd1cmF0aW9uLCBvciB0aGUgb3BlcmF0aW9uIG5lZWRzIHRvIGlu
ZGljYXRlIHdoYXQgc2VtYW50aWNzIGFyZSBpbiB1c2UgKHBlcmhhcHMgYWxzbyBiZWluZyBjb250
cm9sbGFibGUgYnkgdGhlIGNsaWVudCByZXF1ZXN0KS4gIEJ1dCB1bmxlc3MgdGhlIGNsaWVudCBj
bGVhcmx5IGtub3dzIHdoYXQgdGhlIGVycm9yIHNlbWFudGljcyBhcmUgd2hlbiBpdCBhcHBsaWVz
IHRoZSBjb25maWcgaXQgY2Fubm90IGtub3cgd2hhdCB0aGUgdmFsdWUgb2YgdGhlIHJlbWFpbmlu
ZyBsZWF2ZXMgYXJlIGlmIHNvbWUgY29uZmlndXJhdGlvbiBoYXMgZmFpbGVkLg0KDQpUaGUgZGVm
YXVsdCBlcnJvciBoYW5kbGluZyBzZW1hbnRpY3MgZm9yIE5DIGFwcGVhciB0byBiZSAic3RvcCBv
biBlcnJvciIsIHdpdGggImNvbnRpbnVlIG9uIGVycm9yIiBhbmQgInJvbGxiYWNrIG9uIGVycm9y
IiBiZWluZyB0aGUgb3RoZXIgYWxsb3dlZCBvcHRpb25zLiAgSSB3YXNuJ3QgYXdhcmUgb2YgdGhl
ICJzdG9wIG9mIGZpcnN0IGVycm9yIiBiZWluZyB0aGUgZGVmYXVsdCBvcHRpb24gZm9yIG5ldGNv
bmYgYW5kIGhlbmNlIGhhZG4ndCBjb25zaWRlcmVkIGl0IG15IHRleHQgYWJvdmUuDQoNClNvLCBw
ZXJoYXBzIHdlIHNob3VsZCBsaWZ0IHRoZSBkZWZpbml0aW9ucyBvZiAic3RvcCBvbiBlcnJvciIs
IHdpdGggImNvbnRpbnVlIG9uIGVycm9yIiBhbmQgInJvbGxiYWNrIG9uIGVycm9yIiBmcm9tIHNl
Y3Rpb24gNy4yLiBvZiBORVRDT05GIChyZmM2MjQxKSBpbnRvIHRoZSByZXF1aXJlbWVudHMgZHJh
ZnQsIGFuZCB0aGVuIHJlcGhyYXNlIHRoZSAxLkQgdGV4dCBpbiB0aGUgY29udGV4dCBvZiB0aGF0
Lg0KDQpFLmcuIGNoYW5nZSB0aGUgMS5EIHRleHQgdG86DQoNCiAgICAgICAgRC4gVGhlIGNvbmZp
Z3VyYXRpb24gcHJvdG9jb2wsIG9yIGRlZmF1bHQgc2VydmVyIGJlaGF2aW9yLCBNVVNUDQogICAg
ICAgICAgIHNwZWNpZnkgaG93IGNvbmZpZ3VyYXRpb24gZXJyb3JzIGFyZSBoYW5kbGVkLiAgIEVy
cm9ycyBjYW4NCiAgICAgICAgICAgYmUgaGFuZGxlZCBieSAic3RvcCBvbiBlcnJvciIsICJjb250
aW51ZSBvbiBlcnJvciIgb3INCiAgICAgICAgICAgInJvbGxiYWNrIG9uIGVycm9yIiAoc2VlIHRl
cm1zKS4gIFN1cHBvcnQgZm9yICJyb2xsYmFjayBvbg0KICAgICAgICAgICBlcnJvciIgU0hPVUxE
IGJlIHByb3ZpZGVkLg0KDQpMaWZ0ZWQgdGVybXMgKGZyb20gTkVUQ09ORik6DQoNCg0KICAgICAg
ICAgc3RvcC1vbi1lcnJvcjogIFRoZSBjb25maWd1cmF0aW9uIG9wZXJhdGlvbiBpcyBhYm9ydGVk
IG9uIHRoZSBmaXJzdA0KICAgICAgICAgICAgZXJyb3IuDQoNCiAgICAgICAgIGNvbnRpbnVlLW9u
LWVycm9yOiAgQ29udGludWUgdG8gcHJvY2VzcyBjb25maWd1cmF0aW9uIGRhdGEgb24NCiAgICAg
ICAgICAgIGVycm9yOyBlcnJvciBpcyByZWNvcmRlZCwgYW5kIG5lZ2F0aXZlIHJlc3BvbnNlIGlz
IGdlbmVyYXRlZA0KICAgICAgICAgICAgaWYgYW55IGVycm9ycyBvY2N1ci4NCg0KDQoNCg0KRW5u
cywgZXQgYWwuICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAg
ICAgW1BhZ2UgMzldDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiA8aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDEjcGFnZS00MD4NClJGQyA2MjQxPGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxPiAgICAgICAgICAgICAgICAgICAgTkVUQ09O
RiBQcm90b2NvbCAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICAgICAgICByb2xs
YmFjay1vbi1lcnJvcjogIElmIGFuIGVycm9yIGNvbmRpdGlvbiBvY2N1cnMgc3VjaCB0aGF0IHBh
cnQNCiAgICAgICAgICAgIG9mIGFwcGx5aW5nIHRoZSBjb25maWd1cmF0aW9uIGZhaWxzLCB0aGUg
c2VydmVyIHdpbGwgc3RvcA0KICAgICAgICAgICAgcHJvY2Vzc2luZyB0aGUgY29uZmlndXJhdGlv
biBvcGVyYXRpb24gYW5kIHJlc3RvcmUgdGhlDQogICAgICAgICAgICBzcGVjaWZpZWQgY29uZmln
dXJhdGlvbiB0byBpdHMgY29tcGxldGUgc3RhdGUgYXQgdGhlIHN0YXJ0DQogICAgICAgICAgICBv
ZiB0aGlzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9uLg0KDQpUaG91Z2h0cz8NCg0KSGVuY2Ugbm8g
bmVlZCBmb3IgYSBNVVNULg0KDQoNCkEgY29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3Igc2VydmVy
LCBTSE9VTEQgcHJvdmlkZQ0KICAgICAgICAgIHN1cHBvcnQgZm9yIHJvbGxiYWNrLW9uLWVycm9y
IGJlaGF2aW9yIGFuZCBNQVkgY2hvb3NlIHRvDQogICAgICAgICAgcHJvdmlkZSBzdXBwb3J0IGZv
ciBiZXN0IGVmZm9ydCBzZW1hbnRpY3MgYXMgd2VsbC4NCg0KV29uZGVyaW5nIGhvdyBtdWNoIHdl
IG5lZWQgaGVyZS4gQXNzdW1pbmcgdGhlIHNlcnZlciBzdXBwb3J0cyByb2xsYmFjaywgdGhlbiBk
byB3ZSBuZWVkIHByb3RvY29sIGV4dGVuc2lvbnMgZm9yIHRoYXQ/DQpZZXMsIE5DIGFscmVhZHkg
aGFzIGEgcm9sbGJhY2stb24tZXJyb3Igb3B0aW9uLg0KDQoNCkFzc3VtaW5nIHRoZSBzZXJ2ZXIg
ZG9lc24ndCBzdXBwb3J0IHJvbGxiYWNrLiBUaGVuIGRvIHdlIG5lZWQgYW55dGhpbmcgc3BlY2lh
bCBpbiB0aGUgcHJvdG9jb2wgdG8gcmUtY29uZmlndXJlIHRoZSBjb25maWcgdG8gZW11bGF0ZSBz
b21ldGhpbmcgbGlrZSBhIHJvbGxiYWNrPw0KDQpJIHdvdWxkIHN1Z2dlc3Qgbm8uICBFaXRoZXIg
dGhlIHNlcnZlciBzdXBwb3J0cyB0aGlzICh3aGljaCBpcyB0aGUgbW9zdCBsaWtlbHkgb3V0Y29t
ZSksIG9yIHRoZSBjbGllbnQgY2FuIGVtdWxhdGUgaXQuDQoNCg0KDQpNeSBwb2ludCBpczogZ2l2
ZW4gdGhhdCB0cmFuc2FjdGlvbiBpcyBhIHJlcXVpcmVtZW50LCB3b3VsZCB3ZSBuZWVkIHRvIHJl
cXVpcmUgaGVyZSBhbnl0aGluZyBtb3JlIHRoYXQgaXMgbm90IGEgY29uc2VxdWVuY2U/DQoNClBl
cmhhcHMgaXQgaXMgYmV0dGVyIHRvIGxpbWl0IG9yIGV2ZW4gYXZvaWQgdGV4dCBhYm91dCB0cmFu
c2FjdGlvbnMgYW5kIGp1c3QgZGVmaW5lIHRoZSBzdGF0ZSBvZiB0aGUgYXBwbGllZCBjb25maWcg
YWZ0ZXIgZXJyb3IuIEkgc2VlIDMgY2FzZXMgc28gZmFyOg0KMSkgYXRvbWljOiBhZnRlciBlcnJv
ciB0aGUgYXBwbGllZCBjb25maWcgaXMgaWRlbnRpY2FsIHRvIHRoZSBjb25maWcgYmVmb3JlIHRo
ZSBlcnJvcg0KMikgc2VxdWVuY2U6IGlmIHRoZSBjb25maWcgaXMgYXBwbGllZCBpbiBhIHNlcXVl
bmNlIGFuZCBhIHNwZWNpZmljIGxlYWYgZmFpbHMsIHRoZSBsZWFmcyB0aGF0IGhhdmUgYmVlbiBj
b25maWd1cmVkIGJlZm9yZSB3aWxsIGtlZXAgdGhlIGludGVuZGVkIGNvbmZpZywgbGVhZnMgbm90
IHlldCBwcm9jZXNzZWQga2VlcCB0aGUgYXBwbGllZCBjb25maWcgYW5kIHRoZSBmYWlsZWQgbGVh
ZiBpcyB1bmRlZmluZWQNCjMpIGFsbCBsZWFmcyBpbiBlcnJvciBhcmUgdW5kZWZpbmVkLCBhbGwg
ZXJyb3IgZnJlZSBsZWFmcyB1c2UgdGhlIChuZXcpIGludGVuZGVkIGNvbmZpZyBhcyB0aGVpciBh
cHBsaWVkIGNvbmZpZy4NCkkgYWdyZWUgd2l0aCAoMSkgYW5kICgyKSBidXQgd2Fzbid0IGV4cGVj
dGluZyAoMykuICBCeSBiZXN0IGVmZm9ydCwgSSB3YXMgdGhpbmtpbmcgb2YgdGhlIGVxdWl2YWxl
bnQgb2YgTmV0Y29uZidzICAiY29udGludWUgb24gZXJyb3IiLg0KDQpUaGFua3MsDQpSb2INCg0K
DQoNClRob3VnaHRzPw0KDQpHZXJ0DQoNClNlbnQgZnJvbSBteSBBcHBsZSBdWw0KDQpPbiAxNiBP
Y3QgMjAxNSwgYXQgMTQ6MTMsIFJvYmVydCBXaWx0b24gPDxtYWlsdG86cndpbHRvbkBjaXNjby5j
b20+cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQoN
CkhpIEtlbnQsDQoNCkhlcmUgaXMgbXkgYXR0ZW1wdCBhdCB3b3JkIHNtaXRoaW5nIHNlY3Rpb24g
MzoNCg0KVGhlIG9sZCBEIGFuZCBFIGhhdmUgYmVlbiBtZXJnZWQgdG9nZXRoZXIgKG5vdyBsYWJl
bGxlZCBhcyBDKS4gIEEgbmV3IEQgaGFzIGJlZW4gYWRkZWQgdG8gdHJ5IGFuZCBkZWZpbmUgdHJh
bnNhY3Rpb25hbCBlcnJvciBoYW5kbGluZyBzZW1hbnRpY3Mgd2l0aG91dCBpbnRyb2R1Y2luZyB0
aGUgdGVybSB0cmFuc2FjdGlvbmFsLg0KDQoNCiAgIDMuICBTdXBwb3J0IGZvciBib3RoIHN5bmNo
cm9ub3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbg0KICAgICAgIG9wZXJhdGlvbnMN
Cg0KICAgICAgIEEuIEEgc2VydmVyIG1heSBjaG9vc2UgdG8gc3VwcG9ydCBvbmx5IHN5bmNocm9u
b3VzIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgICBvcGVyYXRpb25zLCBvciBvbmx5IGFzeW5jaHJv
bm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMsIG9yDQogICAgICAgICAgYm90aCBzeW5jaHJv
bm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBpbg0KICAgICAg
ICAgIGEgY2xpZW50IHNwZWNpZmllZCBwZXItb3BlcmF0aW9uIGJhc2lzLg0KDQogICAgICAgQi4g
U3VwcG9ydCBmb3Igc3luY2hyb25vdXMgb3BlcmF0aW9ucyBhcyBwZXIgdGhlIGRlZmluaXRpb24g
b2YNCiAgICAgICAgICAic3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb24iLg0KDQog
ICAgICAgQy4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIG9wZXJhdGlvbnMgYXMgcGVyIHRoZSBk
ZWZpbml0aW9uIG9mDQogICAgICAgICAgImFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJh
dGlvbiIuICBTZXJ2ZXJzIHRoYXQgc3VwcG9ydA0KICAgICAgICAgIGFzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uIG9wZXJhdGlvbnMgTUFZIGFsc28gcHJvdmlkZSBhDQogICAgICAgICAgdmVyaWZ5
IG9wZXJhdGlvbiB0aGF0IGEgY2xpZW50IGNhbiByZXF1ZXN0IGZyb20gdGhlIHNlcnZlciB0bw0K
ICAgICAgICAgIHJldHVybiBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0
d2VlbiB0aGUNCiAgICAgICAgICBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9ucy4N
Cg0KICAgICAgIEQuIFN1cHBvcnQgZm9yIGJlc3QgZWZmb3J0IGFuZCByb2xsYmFjay1vbi1lcnJv
ciBlcnJvciBoYW5kbGluZw0KICAgICAgICAgIHNlbWFudGljcy4gIFRoZSBjb25maWd1cmF0aW9u
IHByb3RvY29sLCBvciBkZWZhdWx0IHNlcnZlcg0KICAgICAgICAgIGJlaGF2aW9yLCBNVVNUIHNw
ZWNpZnkgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBhcHBsaWVkDQogICAgICAgICAgaW4g
YSBiZXN0IGVmZm9ydCBmYXNoaW9uLCBvciB1c2luZyAicm9sbGJhY2sgb24gZXJyb3IiDQogICAg
ICAgICAgc2VtYW50aWNzIC0gd2hlcmUgYWxsIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyBpbiB0aGUg
cmVxdWVzdCBhcmUNCiAgICAgICAgICB1bmRvbmUgaWYgcHJvY2Vzc2luZyBvZiBhbnkgcGFydCBv
ZiB0aGUgY29uZmlndXJhdGlvbiB1cGRhdGUNCiAgICAgICAgICBmYWlsZWQuICBBIGNvbmZpZ3Vy
YXRpb24gcHJvdG9jb2wsIG9yIHNlcnZlciwgU0hPVUxEIHByb3ZpZGUNCiAgICAgICAgICBzdXBw
b3J0IGZvciByb2xsYmFjay1vbi1lcnJvciBiZWhhdmlvciBhbmQgTUFZIGNob29zZSB0bw0KICAg
ICAgICAgIHByb3ZpZGUgc3VwcG9ydCBmb3IgYmVzdCBlZmZvcnQgc2VtYW50aWNzIGFzIHdlbGwu
DQoNCkFueSBjb21tZW50cz8NCg0KVGhhbmtzLA0KUm9iDQoNCg0KT24gMTUvMTAvMjAxNSAxODoz
MiwgS2VudCBXYXRzZW4gd3JvdGU6DQoNCkFnYWluLCB3aXRoIGJldHRlciBmb3JtYXR0aW5nIGZv
ciB0aGUgbGlzdDoNCg0KICAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25vdXMgYW5kIGFz
eW5jaHJvbm91cyBjb25maWd1cmF0aW9uDQogICAgICAgb3BlcmF0aW9ucyAoc2VlIHRlcm1zKQ0K
DQogICAgICAgQS4gQSBzZXJ2ZXIgbWF5IG9ubHkgc3VwcG9ydCBzeW5jaHJvbm91cyBjb25maWd1
cmF0aW9uDQogICAgICAgICAgb3BlcmF0aW9ucywgb3IgbWF5IG9ubHkgc3VwcG9ydCBhc3luY2hy
b25vdXMgY29uZmlndXJhdGlvbg0KICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG1heSBzdXBwb3J0
IHN5bmNocm9uaWNpdHkgdG8gYmUgY2xpZW50DQogICAgICAgICAgc3BlY2lmaWVkIG9uIGEgcGVy
LW9wZXJhdGlvbiBiYXNpcy4NCg0KDQogICAgICAgQy4gU3VwcG9ydCBmb3Igc3luY2hyb25vdXMg
Y29uZmlndXJhdGlvbiBvcGVyYXRpb25zDQogICAgICAgICAgcmVxdWlyZXMgdGhlIHNlcnZlciB0
byBibG9jayBzZW5kaW5nIGEgcmVzcG9uc2UgdG8NCiAgICAgICAgICB0aGUgY2xpZW50IHVudGls
IGl0IGlzIGFibGUgdG8gYWJsZSB0byBkZXRlcm1pbmUgd2hldGhlcg0KICAgICAgICAgIHRoZXJl
IGFyZSBhbnkgZXJyb3JzIGluIHRoZSByZXF1ZXN0IG9yIGVycm9ycyBmcm9tDQogICAgICAgICAg
YXBwbHlpbmcgdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdlLg0KDQogICAgICAgRC4gU3VwcG9ydCBm
b3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucw0KICAgICAgICAgIHJlcXVp
cmVzIHRoZSBzZXJ2ZXIgdG8gc2VuZCBhIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQNCiAgICAgICAg
ICBpbW1lZGlhdGVseSBpbmRpY2F0ZWQgdGhhdCB0aGUgcmVxdWVzdCB3YXMgYWNjZXB0ZWQNCiAg
ICAgICAgICBhbmQgc2VuZCBhIG5vdGlmaWNhdGlvbiB0byB0aGUgY2xpZW50IHdoZW4gdGhlIGlu
dGVuZGVkDQogICAgICAgICAgY29uZmlnIGlzIGZ1bGx5IGVmZmVjdGl2ZSBvciB0aGVyZSBhcmUg
YW55IGVycm9ycyBmcm9tDQogICAgICAgICAgYXBwbHlpbmcgdGhlIGNvbmZpZ3VyYXRpb24gY2hh
bmdlLg0KDQogICAgICAgRS4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24g
b3BlcmF0aW9ucyBNQVkNCiAgICAgICAgICBhbHNvIHByb3ZpZGUgYSB2ZXJpZnkgb3BlcmF0aW9u
IHdoaWNoIGEgY2xpZW50IGNhbiByZXF1ZXN0DQogICAgICAgICAgZnJvbSB0aGUgc2VydmVyIHRv
IG9idGFpbiBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlDQogICAgICAgICAgZGlmZmVyZW5jZSBi
ZXR3ZWVuIHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9ucy4NCg0KDQpLZW50
DQoNCg0KDQpPbiAxMC8xNS8xNSwgMToyMiBQTSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5p
cGVyLm5ldD48bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQoNCg0KUmVxdWly
ZW1lbnQgIzMgd2FzIGRpc2N1c3NlZCBvbiB0b2RheSdzIGNhbGwuICAgV2UgYWdyZWVkIHRvIHJl
bW92ZSB0aGUNCndvcmRzICJkaXN0cmlidXRlZCIgYW5kICJ0cmFuc2FjdGlvbmFsIiBhbmQgdG8g
cmV3b3JkIGl0IGluIHRlcm1zIG9mDQoiY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIi4gIFRoZSBy
ZXN1bHRpbmcgdGV4dCBmb2xsb3dzOg0KDQoNCiAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hy
b25vdXMgYW5kIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uDQpvcGVyYXRpb25zIChzZWUgdGVy
bXMpDQoNCiAgICAgIEEuIEEgc2VydmVyIG1heSBvbmx5IHN1cHBvcnQgc3luY2hyb25vdXMgY29u
ZmlndXJhdGlvbiBvcGVyYXRpb25zLA0Kb3IgbWF5IG9ubHkgc3VwcG9ydA0KICAgICAgICAgYXN5
bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgb3IgbWF5IHN1cHBvcnQNCnN5bmNo
cm9uaWNpdHkgdG8gYmUgY2xpZW50DQogICAgICAgICBzcGVjaWZpZWQgb24gYSBwZXItb3BlcmF0
aW9uIGJhc2lzLg0KDQoNCiAgICAgIEMuIFN1cHBvcnQgZm9yIHN5bmNocm9ub3VzIGNvbmZpZ3Vy
YXRpb24gb3BlcmF0aW9ucyByZXF1aXJlcyB0aGUNCnNlcnZlciB0byBibG9jaw0KICAgICAgICAg
c2VuZGluZyBhIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQgdW50aWwgaXQgaXMgYWJsZSB0byBhYmxl
IHRvDQpkZXRlcm1pbmUgd2hldGhlcg0KICAgICAgICAgdGhlcmUgYXJlIGFueSBlcnJvcnMgaW4g
dGhlIHJlcXVlc3Qgb3IgZXJyb3JzIGZyb20gYXBwbHlpbmcgdGhlDQpjb25maWd1cmF0aW9uDQog
ICAgICAgICBjaGFuZ2UuDQoNCiAgICAgIEQuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uIG9wZXJhdGlvbnMgcmVxdWlyZXMgdGhlDQpzZXJ2ZXIgdG8gc2VuZA0KICAgICAg
ICAgYSByZXNwb25zZSB0byB0aGUgY2xpZW50IGltbWVkaWF0ZWx5IGluZGljYXRlZCB0aGF0IHRo
ZSByZXF1ZXN0DQp3YXMgYWNjZXB0ZWQNCiAgICAgICAgIGFuZCBzZW5kIGEgbm90aWZpY2F0aW9u
IHRvIHRoZSBjbGllbnQgd2hlbiB0aGUgaW50ZW5kZWQgY29uZmlnDQppcyBmdWxseQ0KICAgICAg
ICAgZWZmZWN0aXZlIG9yIHRoZXJlIGFyZSBhbnkgZXJyb3JzIGZyb20gYXBwbHlpbmcgdGhlDQpj
b25maWd1cmF0aW9uIGNoYW5nZS4NCg0KICAgICAgRS4gU3VwcG9ydCBmb3IgYXN5bmNocm9ub3Vz
IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBNQVkgYWxzbw0KcHJvdmlkZSBhIHZlcmlmeQ0KICAg
ICAgICAgb3BlcmF0aW9uIHdoaWNoIGEgY2xpZW50IGNhbiByZXF1ZXN0IGZyb20gdGhlIHNlcnZl
ciB0byBvYnRhaW4NCmluZm9ybWF0aW9uDQogICAgICAgICByZWdhcmRpbmcgdGhlIGRpZmZlcmVu
Y2UgYmV0d2VlbiB0aGUgaW50ZW5kZWQgYW5kIGFwcGxpZWQNCmNvbmZpZ3VyYXRpb25zLg0KDQoN
Cg0KV2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIGFib3ZlLCBidXQgd2FudGVkIHRvIHJld3JpdGUg
aXQgcmVseWluZyBtb3JlIG9uDQp0aGUgdGVybXMgZnJvbSB0aGUgVGVybWlub2xvZ3kgc2VjdGlv
biwgYW5kIGFsc28gcG90ZW50aWFsbHkgbWVyZ2UgRSBpbnRvDQpELg0KDQpBbnlib2R5IHdhbnQg
dG8gdGFrZSBhIHN0YWIgYXQgaXQ/DQoNClRoYW5rcywNCktlbnQNCg0KDQoNCk9uIDEwLzE0LzE1
LCA4OjAwIFBNLCAiTmFkZWF1IFRob21hcyIgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPjxtYWls
dG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IHdyb3RlOg0KDQoNCg0KT24gT2N0IDE0LCAyMDE1
Ojc6NTEgUE0sIGF0IDc6NTEgUE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pjxt
YWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4NCndyb3RlOg0KDQoNCg0KT24gOS8yOC8xNSwgMTo0
MCBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciINCjxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu
aXZlcnNpdHkuZGU+PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+
IHdyb3RlOg0KDQoNCg0KT24gV2VkLCBTZXAgMjMsIDIwMTUgYXQgMDM6MDM6NTdQTSArMDAwMCwg
S2VudCBXYXRzZW4gd3JvdGU6DQoNCg0KUG9wcGluZyB0aGUgc3RhY2sgb24gdGhpcyBpc3N1ZSwg
dGhlIGlzc3VlIHJlbWFpbnMgYXMgdG8gd2hhdCB0byBkbw0Kd2l0aCByZXF1aXJlbWVudCAzOg0K
DQogIDMuICBTdXBwb3J0IGZvciBib3RoIHRyYW5zYWN0aW9uYWwsIHN5bmNocm9ub3VzIG1hbmFn
ZW1lbnQgc3lzdGVtcw0KICAgICAgIGFzIHdlbGwgYXMgZGlzdHJpYnV0ZWQsIGFzeW5jaHJvbm91
cyBtYW5hZ2VtZW50IHN5c3RlbXMNCg0KDQoNCkkgZmFpbCB0byB1bmRlcnN0YW5kICd0cmFuc2Fj
dGlvbmFsJyBhbmQgJ2Rpc3RyaWJ1dGVkJyBoZXJlLg0KDQoNCkkgaG9wZSB0aGF0IHRoZXNlIHRl
cm1zIHdpbGwgYmUgY2xhcmlmaWVkIG9uIHRvbW9ycm93J3MgY2FsbC4gICBUaGVyZQ0KaXMNCmFs
c28gYSBjaGFuY2UgdGhhdCB0aGVzZSB0ZXJtcyB3aWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgdGV4
dA0KYWx0b2dldGhlciwNCmFzIHRoZXkgbWF5IGJlIHZpZXdlZCBhcyB1bm5lY2Vzc2FyaWx5IHF1
YWxpZnkgdGhlDQpzeW5jaHJvbm91cy9hc3luY2hyb25vdXMgdGVybXMuDQoNCg0KDQoNCkFuZA0K
ZnJhbmtseSwgSSBhbSBub3Qgc3VyZSB3aHkgdGhlIG1hbmFnZW1lbnQgX3N5c3RlbXNfIGFyZSBj
bGFzc2lmaWVkIHRvDQpiZSBzeW5jaHJvbm91cyBvciBhc3luY2hyb25vdXMgLSBJIHRoaW5rIHdl
IGFyZSB0YWxraW5nIGFib3V0DQpwcm90b2NvbHMgYmV0d2VlbiBhIG1hbmFnZW1lbnQgc3lzdGVt
IGFuZCBhIGRldmljZS4NCg0KDQpBeWUsIEkgZGlkbid0IHNlZSB0aGF0IGJlZm9yZS4NCg0KRmly
c3Qgb2ZmLCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0IHRoZSB0ZXJtICJzeXN0ZW0iIGlzIHVzZWQg
NyB0aW1lcyB0bw0KcmVmZXIgdG8gdGhlIGRldmljZSAoZS5nLiwgTkMvUkMgc2VydmVyKS4gIFRo
ZSB0ZXJtICJzeXN0ZW0iIGlzDQpvdGhlcndpc2UNCm5vdCBkZWZpbmVkLg0KDQpCdXQgdG8geW91
ciBtYWluIHBvaW50LCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGUgdGVybXMgYS9zeW5jaHJv
bm91cw0KdG8NCmhhdmUgdG8gZG8gd2l0aCBpbnRlcm5hbCBzZXJ2ZXIgcHJvY2Vzc2luZyBvZiBh
biBlZGl0IHJlcXVlc3QsIGJ1dCBpbg0KJzMnDQp0aGUgdGVybXMgYXJlIGJlaW5nIHVzZWQgdG8g
cXVhbGlmeSBhIG1hbmFnZW1lbnQgc3lzdGVtLCB3aGljaCBjYW4ndCBiZQ0KcmlnaHQuICBJIHRo
aW5rIHRoYXQgJzMnIHNob3VsZCBiZSByZXdyaXR0ZW4gdG8gYmUgYSBzdGF0ZW1lbnQgYWJvdXQN
CmRldmljZXMsIG5vdCBhIHN0YXRlbWVudCBhYm91dCBtYW5hZ2VtZW50IHN5c3RlbXMuDQoNCg0K
ICAgICAgICBJdCBtaWdodCBiZSBiZXR0ZXIgdG8gZnJhbWUgdGhpcyBpbiB0ZXJtcyBvZiBhIGNs
aWVudCBhbmQgYQ0Kc2VydmVyLg0KDQogICAgICAgIOKAuVRvbQ0KDQoNCg0KDQpBbnl3YXksIEkg
YW0gbm90IHN1cmUgMy4gaXMgcHJvcGVybHkgd29yZGVkIHVudGlsIHNvbWVvbmUgZGVmaW5lcw0K
DQoNCid0cmFuc2FjdGlvbmFsJywgJ2Rpc3RyaWJ1dGVkJywgJ3N5bmNocm9ub3VzIG1hbmFnZW1l
bnQgc3lzdGVtcycgYW5kDQonYXN5bmNocm9ub3VzIG1hbmFnZW1lbnQgc3lzdGVtcycuDQoNCg0K
VGhlIGFnZW5kYSBmb3IgdG9tb3Jyb3cncyBpbnRlcmltISAgOikNCg0KDQpLZW50DQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu
ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5l
dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu
b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv
Om5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kDQoNCg==

--_000_24CFE232441E453D9597B73820FF9A82junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <48D9574D87C9DF40B5E203C536D655B8@junipernetworks.onmicrosoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PlJvYiw8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+
DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlllcywgd2Ugc2hvdWxkIHB1bGwgdGhlIGVy
cm9yIG1vZGVzIG9mIG5ldGNvbmYgaW50byB0aGUgZGVmaW5pdGlvbi4gVGhlIGF2YWlsYWJsZSB0
ZXh0IGxvb2tzIHJlYWR5IHRvIGJlIHVzZWQuPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPkZvciB0aGUgcmVzdCB3ZSBtYXkgbmVlZCB0byBkZWZpbmUgYSByZXF1aXJlbWVudCB0
aGF0IHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gcmV0cmlldmUgdGhlIGVycm9yIGhhbmRs
aW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIHNlcnZlci4gSW4gdGhlIGVuZCB0aGUgY2xpZW50IG5l
ZWRzIHRvIGtub3cgaWYgaXQgaGFzIHRvIGNsZWFuIHVwIHRoZSBtZXNzIGluIHRoZSBzZXJ2ZXIg
b3Igbm90LjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4N
CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+SW4gdGhhdCBzZW5zZSwgSSdkIGRlZmluZSBh
IHRyYW5zYWN0aW9uIGFzIGEgY29uZmlndXJhdGlvbiBjaGFuZ2UgdGhhdCBjYW4gYmUgcm9sbGVk
IGJhY2sgYnkgdGhlIHNlcnZlci48L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+
PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPkdlcnQ8YnI+DQo8YnI+
DQpTZW50IGZyb20gbXkgQXBwbGUgXVs8L2Rpdj4NCjxkaXY+PGJyPg0KT24gMTYgT2N0IDIwMTUs
IGF0IDE1OjU5LCBSb2JlcnQgV2lsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj
by5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+SGkgR2VydCw8YnI+DQo8YnI+DQo8ZGl2
IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDE2LzEwLzIwMTUgMTM6NTgsIEdlcnQgR3JhbW1l
bCB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDpCRkUxNTQ0Ri0xMDQ5
LTQxQTYtODMwQy1FRDU0OEZFMUI5NDVAanVuaXBlci5uZXQiIHR5cGU9ImNpdGUiPg0KPGRpdj5I
aSBSb2IsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgdGV4dCBsb29rcyBnb29k
LiBXaXRoIHJlc3BlY3QgdG8gRCB3ZSBwcm9iYWJseSBuZWVkIG1vcmUgd29yZHNtaXRoaW5nOjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo
MjU1LCAyNTUsIDI1NSwgMCk7Ij4mbmJzcDtELiBTdXBwb3J0IGZvciBiZXN0IGVmZm9ydCBhbmQg
cm9sbGJhY2stb24tZXJyb3IgZXJyb3IgaGFuZGxpbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtYW50aWNzLiZuYnNwOyBUaGUg
Y29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3IgZGVmYXVsdCBzZXJ2ZXI8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmVoYXZpb3IsIE1V
U1Qgc3BlY2lmeSB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlzIGFwcGxpZWQ8YnI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gYSBi
ZXN0IGVmZm9ydCBmYXNoaW9uLCBvciB1c2luZyAmcXVvdDtyb2xsYmFjayBvbiBlcnJvciZxdW90
Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBzZW1hbnRpY3MgLSB3aGVyZSBhbGwgY29uZmlndXJhdGlvbiBjaGFuZ2VzIGluIHRoZSBy
ZXF1ZXN0IGFyZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB1bmRvbmUgaWYgcHJvY2Vzc2luZyBvZiBhbnkgcGFydCBvZiB0aGUgY29u
ZmlndXJhdGlvbiB1cGRhdGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgZmFpbGVkLiZuYnNwOyA8L3NwYW4+PC9mb250PjwvYmxvY2tx
dW90ZT4NCjxkaXY+LS0mZ3Q7IGhvdyB3b3VsZCB0aGUgY2xpZW50IGtub3cgdGhhdCBhIGNlcnRh
aW4gb3BlcmF0aW9uIGlzIHN1cHBvcnRlZCBpbiBhbiBhdG9taWMgb3Igbm9uLWF0b21pYyBtYW5u
ZXIgYnkgdGhlIHNlcnZlci4gSW4gbXkgdmlldyB0aGUgZGVmYXVsdCBzaG91bGQgYmUgdGhlIGNs
aWVudCBhc3N1bWVzIGJlc3QgZWZmb3J0IGFuZCB0aGUgc2VydmVyIGlzIGFsbG93ZWQgdG8gZG8g
YmV0dGVyLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQpFaXRoZXIgdGhlIGNs
aWVudCB3b3VsZCBuZWVkIHRvIGtub3cgd2hhdCBlcnJvciBzZW1hbnRpY3MgYSBwYXJ0aWN1bGFy
IHNlcnZlciB3aWxsIGFsd2F5cyB1c2UgdG8gYXBwbHkgY29uZmlndXJhdGlvbiwgb3IgdGhlIG9w
ZXJhdGlvbiBuZWVkcyB0byBpbmRpY2F0ZSB3aGF0IHNlbWFudGljcyBhcmUgaW4gdXNlIChwZXJo
YXBzIGFsc28gYmVpbmcgY29udHJvbGxhYmxlIGJ5IHRoZSBjbGllbnQgcmVxdWVzdCkuJm5ic3A7
IEJ1dCB1bmxlc3MgdGhlIGNsaWVudA0KIGNsZWFybHkga25vd3Mgd2hhdCB0aGUgZXJyb3Igc2Vt
YW50aWNzIGFyZSB3aGVuIGl0IGFwcGxpZXMgdGhlIGNvbmZpZyBpdCBjYW5ub3Qga25vdyB3aGF0
IHRoZSB2YWx1ZSBvZiB0aGUgcmVtYWluaW5nIGxlYXZlcyBhcmUgaWYgc29tZSBjb25maWd1cmF0
aW9uIGhhcyBmYWlsZWQuPGJyPg0KPGJyPg0KVGhlIGRlZmF1bHQgZXJyb3IgaGFuZGxpbmcgc2Vt
YW50aWNzIGZvciBOQyBhcHBlYXIgdG8gYmUgJnF1b3Q7c3RvcCBvbiBlcnJvciZxdW90Oywgd2l0
aCAmcXVvdDtjb250aW51ZSBvbiBlcnJvciZxdW90OyBhbmQgJnF1b3Q7cm9sbGJhY2sgb24gZXJy
b3ImcXVvdDsgYmVpbmcgdGhlIG90aGVyIGFsbG93ZWQgb3B0aW9ucy4mbmJzcDsgSSB3YXNuJ3Qg
YXdhcmUgb2YgdGhlICZxdW90O3N0b3Agb2YgZmlyc3QgZXJyb3ImcXVvdDsgYmVpbmcgdGhlIGRl
ZmF1bHQgb3B0aW9uIGZvciBuZXRjb25mIGFuZCBoZW5jZSBoYWRuJ3QgY29uc2lkZXJlZA0KIGl0
IG15IHRleHQgYWJvdmUuPGJyPg0KPGJyPg0KU28sIHBlcmhhcHMgd2Ugc2hvdWxkIGxpZnQgdGhl
IGRlZmluaXRpb25zIG9mICZxdW90O3N0b3Agb24gZXJyb3ImcXVvdDssIHdpdGggJnF1b3Q7Y29u
dGludWUgb24gZXJyb3ImcXVvdDsgYW5kICZxdW90O3JvbGxiYWNrIG9uIGVycm9yJnF1b3Q7IGZy
b20gc2VjdGlvbiA3LjIuIG9mIE5FVENPTkYgKHJmYzYyNDEpIGludG8gdGhlIHJlcXVpcmVtZW50
cyBkcmFmdCwgYW5kIHRoZW4gcmVwaHJhc2UgdGhlIDEuRCB0ZXh0IGluIHRoZSBjb250ZXh0IG9m
IHRoYXQuPGJyPg0KPGJyPg0KRS5nLiBjaGFuZ2UgdGhlIDEuRCB0ZXh0IHRvOjxmb250IGNvbG9y
PSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg
MjU1LCAwKTsiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j
b2xvcjogcmdiYSgyNTUsIDI1NSwNCiAgICAgICAgICAgIDI1NSwgMCk7Ij48YnI+DQo8L3NwYW4+
PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBELiBUaGUgY29uZmlndXJhdGlvbiBwcm90b2NvbCwgb3IgZGVmYXVs
dCBzZXJ2ZXIgYmVoYXZpb3IsIE1VU1Q8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmeSBob3cgY29uZmlndXJhdGlv
biBlcnJvcnMgYXJlIGhhbmRsZWQuJm5ic3A7Jm5ic3A7IEVycm9ycyBjYW48YnI+DQombmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUg
aGFuZGxlZCBieSAmcXVvdDtzdG9wIG9uIGVycm9yJnF1b3Q7LCAmcXVvdDtjb250aW51ZSBvbiBl
cnJvciZxdW90OyBvcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtyb2xsYmFjayBvbiBlcnJvciZxdW90OyAoc2Vl
IHRlcm1zKS4mbmJzcDsgU3VwcG9ydCBmb3IgJnF1b3Q7cm9sbGJhY2sgb248YnI+DQombmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXJy
b3ImcXVvdDsgU0hPVUxEIGJlIHByb3ZpZGVkLjwvdHQ+PGJyPg0KPGJyPg0KTGlmdGVkIHRlcm1z
IChmcm9tIE5FVENPTkYpOjxicj4NCjxicj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJm
b250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7
IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2lkb3dzOiAxOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyI+ICAgICAgICAgc3RvcC1vbi1lcnJvcjogIFRoZSBjb25maWd1cmF0aW9uIG9wZXJh
dGlvbiBpcyBhYm9ydGVkIG9uIHRoZSBmaXJzdA0KICAgICAgICAgICAgZXJyb3IuDQoNCiAgICAg
ICAgIGNvbnRpbnVlLW9uLWVycm9yOiAgQ29udGludWUgdG8gcHJvY2VzcyBjb25maWd1cmF0aW9u
IGRhdGEgb24NCiAgICAgICAgICAgIGVycm9yOyBlcnJvciBpcyByZWNvcmRlZCwgYW5kIG5lZ2F0
aXZlIHJlc3BvbnNlIGlzIGdlbmVyYXRlZA0KICAgICAgICAgICAgaWYgYW55IGVycm9ycyBvY2N1
ci4NCg0KDQoNCg0KPHNwYW4gY2xhc3M9ImdyZXkiIHN0eWxlPSJjb2xvcjogcmdiKDExOSwgMTE5
LCAxMTkpOyI+RW5ucywgZXQgYWwuICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAg
ICAgICAgICAgICAgICAgW1BhZ2UgMzldPC9zcGFuPjwvcHJlPg0KPGhyIGNsYXNzPSJub3ByaW50
IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICdUaW1lcw0KICAgICAg
TmV3IFJvbWFuJzsgZm9udC1zaXplOiAxMy4zMzMzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAg
ICAgIGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOw0KICAgICAgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg
dGV4dC1hbGlnbjogc3RhcnQ7DQogICAgICB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsNCiAgICAgIHdpZG93czogMTsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsNCiAgICAgIHdpZHRoOiA5
NmV4OyIgYWxpZ249ImxlZnQiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6
ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1i
cmVhay1iZWZvcmU6IGFsd2F5czsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRv
d3M6IDE7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
Ij48YSBuYW1lPSJwYWdlLTQwIiBpZD0icGFnZS00MCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzYyNDEjcGFnZS00MCIgY2xhc3M9ImludmlzaWJsZSIgc3R5bGU9InRleHQt
ZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IHdoaXRlOyI+IDwvYT4NCjxzcGFuIGNsYXNzPSJncmV5
IiBzdHlsZT0iY29sb3I6IHJnYigxMTksIDExOSwgMTE5KTsiPjxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxIiBzdHlsZT0iY29sb3I6IHJnYigxMTksIDExOSwgMTE5
KTsiPlJGQyA2MjQxPC9hPiAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBQcm90b2NvbCAgICAg
ICAgICAgICAgICAgICBKdW5lIDIwMTE8L3NwYW4+DQoNCg0KICAgICAgICAgcm9sbGJhY2stb24t
ZXJyb3I6ICBJZiBhbiBlcnJvciBjb25kaXRpb24gb2NjdXJzIHN1Y2ggdGhhdCBwYXJ0DQogICAg
ICAgICAgICBvZiBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBmYWlscywgdGhlIHNlcnZlciB3
aWxsIHN0b3ANCiAgICAgICAgICAgIHByb2Nlc3NpbmcgdGhlIGNvbmZpZ3VyYXRpb24gb3BlcmF0
aW9uIGFuZCByZXN0b3JlIHRoZQ0KICAgICAgICAgICAgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24g
dG8gaXRzIGNvbXBsZXRlIHN0YXRlIGF0IHRoZSBzdGFydA0KICAgICAgICAgICAgb2YgdGhpcyBj
b25maWd1cmF0aW9uIG9wZXJhdGlvbi48L3ByZT4NCjxicj4NClRob3VnaHRzPzxicj4NCjxicj4N
CjxibG9ja3F1b3RlIGNpdGU9Im1pZDpCRkUxNTQ0Ri0xMDQ5LTQxQTYtODMwQy1FRDU0OEZFMUI5
NDVAanVuaXBlci5uZXQiIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+SGVuY2Ugbm8gbmVlZCBm
b3IgYSBNVVNULiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxicj4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dy
b3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkEgY29uZmlndXJhdGlvbiBwcm90
b2NvbCwgb3Igc2VydmVyLCBTSE9VTEQgcHJvdmlkZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0IGZvciByb2xsYmFjay1v
bi1lcnJvciBiZWhhdmlvciBhbmQgTUFZIGNob29zZSB0bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlIHN1cHBvcnQgZm9y
IGJlc3QgZWZmb3J0IHNlbWFudGljcyBhcyB3ZWxsLjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Xb25kZXJpbmcgaG93IG11Y2ggd2Ug
bmVlZCBoZXJlLiBBc3N1bWluZyB0aGUgc2VydmVyIHN1cHBvcnRzIHJvbGxiYWNrLCB0aGVuIGRv
IHdlIG5lZWQgcHJvdG9jb2wgZXh0ZW5zaW9ucyBmb3IgdGhhdD88L2Rpdj4NCjwvYmxvY2txdW90
ZT4NClllcywgTkMgYWxyZWFkeSBoYXMgYSByb2xsYmFjay1vbi1lcnJvciBvcHRpb24uPGJyPg0K
PGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkJGRTE1NDRGLTEwNDktNDFBNi04MzBD
LUVENTQ4RkUxQjk0NUBqdW5pcGVyLm5ldCIgdHlwZT0iY2l0ZSI+DQo8ZGl2PkFzc3VtaW5nIHRo
ZSBzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0IHJvbGxiYWNrLiBUaGVuIGRvIHdlIG5lZWQgYW55dGhp
bmcgc3BlY2lhbCBpbiB0aGUgcHJvdG9jb2wgdG8gcmUtY29uZmlndXJlIHRoZSBjb25maWcgdG8g
ZW11bGF0ZSBzb21ldGhpbmcgbGlrZSBhIHJvbGxiYWNrPzwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGJyPg0KSSB3b3VsZCBzdWdnZXN0IG5vLiZuYnNwOyBFaXRoZXIgdGhlIHNlcnZlciBzdXBwb3J0
cyB0aGlzICh3aGljaCBpcyB0aGUgbW9zdCBsaWtlbHkgb3V0Y29tZSksIG9yIHRoZSBjbGllbnQg
Y2FuIGVtdWxhdGUgaXQuDQo8YnI+DQo8YnI+DQo8YnI+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6
QkZFMTU0NEYtMTA0OS00MUE2LTgzMEMtRUQ1NDhGRTFCOTQ1QGp1bmlwZXIubmV0IiB0eXBlPSJj
aXRlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk15IHBvaW50IGlzOiBnaXZlbiB0aGF0IHRy
YW5zYWN0aW9uIGlzIGEgcmVxdWlyZW1lbnQsIHdvdWxkIHdlIG5lZWQgdG8gcmVxdWlyZSBoZXJl
IGFueXRoaW5nIG1vcmUgdGhhdCBpcyBub3QgYSBjb25zZXF1ZW5jZT88L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PlBlcmhhcHMgaXQgaXMgYmV0dGVyIHRvIGxpbWl0IG9yIGV2ZW4gYXZv
aWQgdGV4dCBhYm91dCB0cmFuc2FjdGlvbnMgYW5kIGp1c3QgZGVmaW5lIHRoZSBzdGF0ZSBvZiB0
aGUgYXBwbGllZCBjb25maWcgYWZ0ZXIgZXJyb3IuIEkgc2VlIDMgY2FzZXMgc28gZmFyOjwvZGl2
Pg0KPGRpdj4xKSBhdG9taWM6IGFmdGVyIGVycm9yIHRoZSBhcHBsaWVkIGNvbmZpZyBpcyBpZGVu
dGljYWwgdG8gdGhlIGNvbmZpZyBiZWZvcmUgdGhlIGVycm9yPC9kaXY+DQo8ZGl2PjIpIHNlcXVl
bmNlOiBpZiB0aGUgY29uZmlnIGlzIGFwcGxpZWQgaW4gYSBzZXF1ZW5jZSBhbmQgYSBzcGVjaWZp
YyBsZWFmIGZhaWxzLCB0aGUgbGVhZnMgdGhhdCBoYXZlIGJlZW4gY29uZmlndXJlZCBiZWZvcmUg
d2lsbCBrZWVwIHRoZSBpbnRlbmRlZCBjb25maWcsIGxlYWZzIG5vdCB5ZXQgcHJvY2Vzc2VkIGtl
ZXAgdGhlIGFwcGxpZWQgY29uZmlnIGFuZCB0aGUgZmFpbGVkIGxlYWYgaXMgdW5kZWZpbmVkPC9k
aXY+DQo8ZGl2PjMpIGFsbCBsZWFmcyBpbiBlcnJvciBhcmUgdW5kZWZpbmVkLCBhbGwgZXJyb3Ig
ZnJlZSBsZWFmcyB1c2UgdGhlIChuZXcpIGludGVuZGVkIGNvbmZpZyBhcyB0aGVpciBhcHBsaWVk
IGNvbmZpZy48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCkkgYWdyZWUgd2l0aCAoMSkgYW5kICgyKSBi
dXQgd2Fzbid0IGV4cGVjdGluZyAoMykuJm5ic3A7IEJ5IGJlc3QgZWZmb3J0LCBJIHdhcyB0aGlu
a2luZyBvZiB0aGUgZXF1aXZhbGVudCBvZiBOZXRjb25mJ3MmbmJzcDsgJnF1b3Q7Y29udGludWUg
b24gZXJyb3ImcXVvdDsuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxicj4NCjxi
cj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDpCRkUxNTQ0Ri0xMDQ5LTQxQTYtODMwQy1FRDU0OEZF
MUI5NDVAanVuaXBlci5uZXQiIHR5cGU9ImNpdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
VGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5HZXJ0PC9kaXY+DQo8ZGl2
Pjxicj4NCjxkaXY+U2VudCBmcm9tIG15IEFwcGxlIF1bPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJy
Pg0KT24gMTYgT2N0IDIwMTUsIGF0IDE0OjEzLCBSb2JlcnQgV2lsdG9uICZsdDs8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+PC9hPjxhIGNs
YXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2Nv
LmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5IaSBLZW50LDxicj4NCjxicj4NCkhlcmUg
aXMgbXkgYXR0ZW1wdCBhdCB3b3JkIHNtaXRoaW5nIHNlY3Rpb24gMzo8YnI+DQo8YnI+DQpUaGUg
b2xkIEQgYW5kIEUgaGF2ZSBiZWVuIG1lcmdlZCB0b2dldGhlciAobm93IGxhYmVsbGVkIGFzIEMp
LiZuYnNwOyBBIG5ldyBEIGhhcyBiZWVuIGFkZGVkIHRvIHRyeSBhbmQgZGVmaW5lIHRyYW5zYWN0
aW9uYWwgZXJyb3IgaGFuZGxpbmcgc2VtYW50aWNzIHdpdGhvdXQgaW50cm9kdWNpbmcgdGhlIHRl
cm0gdHJhbnNhY3Rpb25hbC48YnI+DQo8YnI+DQo8YnI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5l
dywgQ291cmllciwgbW9ub3NwYWNlIj4mbmJzcDsmbmJzcDsgMy4mbmJzcDsgU3VwcG9ydCBmb3Ig
Ym90aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb248YnI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW9uczxicj4NCjxicj4NCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBLiBBIHNlcnZlciBtYXkgY2hvb3Nl
IHRvIHN1cHBvcnQgb25seSBzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMs
IG9yIG9ubHkgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgb3I8YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm90
aCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBp
bjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBhIGNsaWVudCBzcGVjaWZpZWQgcGVyLW9wZXJhdGlvbiBiYXNpcy48YnI+DQo8YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQi4gU3VwcG9ydCBmb3Igc3luY2hy
b25vdXMgb3BlcmF0aW9ucyBhcyBwZXIgdGhlIGRlZmluaXRpb24gb2Y8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c3luY2hy
b25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb24mcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEMuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBv
cGVyYXRpb25zIGFzIHBlciB0aGUgZGVmaW5pdGlvbiBvZjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDthc3luY2hyb25vdXMg
Y29uZmlndXJhdGlvbiBvcGVyYXRpb24mcXVvdDsuJm5ic3A7IFNlcnZlcnMgdGhhdCBzdXBwb3J0
PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgTUFZIGFsc28gcHJvdmlk
ZSBhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHZlcmlmeSBvcGVyYXRpb24gdGhhdCBhIGNsaWVudCBjYW4gcmVxdWVzdCBmcm9tIHRo
ZSBzZXJ2ZXIgdG88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgcmV0dXJuIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZGlmZmVyZW5j
ZSBiZXR3ZWVuIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9ucy48YnI+
DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRC4gU3VwcG9ydCBm
b3IgYmVzdCBlZmZvcnQgYW5kIHJvbGxiYWNrLW9uLWVycm9yIGVycm9yIGhhbmRsaW5nPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNl
bWFudGljcy4mbmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wsIG9yIGRlZmF1bHQgc2Vy
dmVyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGJlaGF2aW9yLCBNVVNUIHNwZWNpZnkgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBp
cyBhcHBsaWVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGluIGEgYmVzdCBlZmZvcnQgZmFzaGlvbiwgb3IgdXNpbmcgJnF1b3Q7cm9s
bGJhY2sgb24gZXJyb3ImcXVvdDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtYW50aWNzIC0gd2hlcmUgYWxsIGNvbmZpZ3VyYXRp
b24gY2hhbmdlcyBpbiB0aGUgcmVxdWVzdCBhcmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdW5kb25lIGlmIHByb2Nlc3Npbmcgb2Yg
YW55IHBhcnQgb2YgdGhlIGNvbmZpZ3VyYXRpb24gdXBkYXRlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZhaWxlZC4mbmJzcDsgQSBj
b25maWd1cmF0aW9uIHByb3RvY29sLCBvciBzZXJ2ZXIsIFNIT1VMRCBwcm92aWRlPGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBv
cnQgZm9yIHJvbGxiYWNrLW9uLWVycm9yIGJlaGF2aW9yIGFuZCBNQVkgY2hvb3NlIHRvPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBy
b3ZpZGUgc3VwcG9ydCBmb3IgYmVzdCBlZmZvcnQgc2VtYW50aWNzIGFzIHdlbGwuPGJyPg0KPGJy
Pg0KPC9mb250PkFueSBjb21tZW50cz88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KUm9iPGJyPg0K
PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNS8xMC8yMDE1IDE4
OjMyLCBLZW50IFdhdHNlbiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1p
ZDpEMjQ1NUI0Qy5FNzMzMCUyNWt3YXRzZW5AanVuaXBlci5uZXQiIHR5cGU9ImNpdGUiPg0KPHBy
ZSB3cmFwPSIiPkFnYWluLCB3aXRoIGJldHRlciBmb3JtYXR0aW5nIGZvciB0aGUgbGlzdDoNCg0K
ICAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uDQogICAgICAgb3BlcmF0aW9ucyAoc2VlIHRlcm1zKQ0KDQogICAgICAgQS4gQSBz
ZXJ2ZXIgbWF5IG9ubHkgc3VwcG9ydCBzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uDQogICAgICAg
ICAgb3BlcmF0aW9ucywgb3IgbWF5IG9ubHkgc3VwcG9ydCBhc3luY2hyb25vdXMgY29uZmlndXJh
dGlvbg0KICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG1heSBzdXBwb3J0IHN5bmNocm9uaWNpdHkg
dG8gYmUgY2xpZW50DQogICAgICAgICAgc3BlY2lmaWVkIG9uIGEgcGVyLW9wZXJhdGlvbiBiYXNp
cy4NCg0KDQogICAgICAgQy4gU3VwcG9ydCBmb3Igc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBv
cGVyYXRpb25zDQogICAgICAgICAgcmVxdWlyZXMgdGhlIHNlcnZlciB0byBibG9jayBzZW5kaW5n
IGEgcmVzcG9uc2UgdG8NCiAgICAgICAgICB0aGUgY2xpZW50IHVudGlsIGl0IGlzIGFibGUgdG8g
YWJsZSB0byBkZXRlcm1pbmUgd2hldGhlcg0KICAgICAgICAgIHRoZXJlIGFyZSBhbnkgZXJyb3Jz
IGluIHRoZSByZXF1ZXN0IG9yIGVycm9ycyBmcm9tDQogICAgICAgICAgYXBwbHlpbmcgdGhlIGNv
bmZpZ3VyYXRpb24gY2hhbmdlLg0KICAgIA0KICAgICAgIEQuIFN1cHBvcnQgZm9yIGFzeW5jaHJv
bm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMNCiAgICAgICAgICByZXF1aXJlcyB0aGUgc2Vy
dmVyIHRvIHNlbmQgYSByZXNwb25zZSB0byB0aGUgY2xpZW50DQogICAgICAgICAgaW1tZWRpYXRl
bHkgaW5kaWNhdGVkIHRoYXQgdGhlIHJlcXVlc3Qgd2FzIGFjY2VwdGVkDQogICAgICAgICAgYW5k
IHNlbmQgYSBub3RpZmljYXRpb24gdG8gdGhlIGNsaWVudCB3aGVuIHRoZSBpbnRlbmRlZA0KICAg
ICAgICAgIGNvbmZpZyBpcyBmdWxseSBlZmZlY3RpdmUgb3IgdGhlcmUgYXJlIGFueSBlcnJvcnMg
ZnJvbQ0KICAgICAgICAgIGFwcGx5aW5nIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZS4NCg0KICAg
ICAgIEUuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMg
TUFZDQogICAgICAgICAgYWxzbyBwcm92aWRlIGEgdmVyaWZ5IG9wZXJhdGlvbiB3aGljaCBhIGNs
aWVudCBjYW4gcmVxdWVzdA0KICAgICAgICAgIGZyb20gdGhlIHNlcnZlciB0byBvYnRhaW4gaW5m
b3JtYXRpb24gcmVnYXJkaW5nIHRoZQ0KICAgICAgICAgIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg
aW50ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlvbnMuDQoNCg0KS2VudA0KDQoNCg0KT24g
MTAvMTUvMTUsIDE6MjIgUE0sICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7IDxhIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmt3
YXRzZW5AanVuaXBlci5uZXQiPiZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OzwvYT4gd3JvdGU6
DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+UmVxdWly
ZW1lbnQgIzMgd2FzIGRpc2N1c3NlZCBvbiB0b2RheSdzIGNhbGwuICAgV2UgYWdyZWVkIHRvIHJl
bW92ZSB0aGUNCndvcmRzICZxdW90O2Rpc3RyaWJ1dGVkJnF1b3Q7IGFuZCAmcXVvdDt0cmFuc2Fj
dGlvbmFsJnF1b3Q7IGFuZCB0byByZXdvcmQgaXQgaW4gdGVybXMgb2YNCiZxdW90O2NvbmZpZ3Vy
YXRpb24gb3BlcmF0aW9ucyZxdW90Oy4gIFRoZSByZXN1bHRpbmcgdGV4dCBmb2xsb3dzOg0KDQoN
CiAgMy4gIFN1cHBvcnQgZm9yIGJvdGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uDQpvcGVyYXRpb25zIChzZWUgdGVybXMpDQoNCiAgICAgIEEuIEEgc2VydmVyIG1h
eSBvbmx5IHN1cHBvcnQgc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLA0Kb3Ig
bWF5IG9ubHkgc3VwcG9ydA0KICAgICAgICAgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3Bl
cmF0aW9ucywgb3IgbWF5IHN1cHBvcnQNCnN5bmNocm9uaWNpdHkgdG8gYmUgY2xpZW50DQogICAg
ICAgICBzcGVjaWZpZWQgb24gYSBwZXItb3BlcmF0aW9uIGJhc2lzLg0KDQoNCiAgICAgIEMuIFN1
cHBvcnQgZm9yIHN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyByZXF1aXJlcyB0
aGUNCnNlcnZlciB0byBibG9jaw0KICAgICAgICAgc2VuZGluZyBhIHJlc3BvbnNlIHRvIHRoZSBj
bGllbnQgdW50aWwgaXQgaXMgYWJsZSB0byBhYmxlIHRvDQpkZXRlcm1pbmUgd2hldGhlcg0KICAg
ICAgICAgdGhlcmUgYXJlIGFueSBlcnJvcnMgaW4gdGhlIHJlcXVlc3Qgb3IgZXJyb3JzIGZyb20g
YXBwbHlpbmcgdGhlDQpjb25maWd1cmF0aW9uDQogICAgICAgICBjaGFuZ2UuDQogICANCiAgICAg
IEQuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgcmVx
dWlyZXMgdGhlDQpzZXJ2ZXIgdG8gc2VuZA0KICAgICAgICAgYSByZXNwb25zZSB0byB0aGUgY2xp
ZW50IGltbWVkaWF0ZWx5IGluZGljYXRlZCB0aGF0IHRoZSByZXF1ZXN0DQp3YXMgYWNjZXB0ZWQN
CiAgICAgICAgIGFuZCBzZW5kIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBjbGllbnQgd2hlbiB0aGUg
aW50ZW5kZWQgY29uZmlnDQppcyBmdWxseSANCiAgICAgICAgIGVmZmVjdGl2ZSBvciB0aGVyZSBh
cmUgYW55IGVycm9ycyBmcm9tIGFwcGx5aW5nIHRoZQ0KY29uZmlndXJhdGlvbiBjaGFuZ2UuDQoN
CiAgICAgIEUuIFN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlv
bnMgTUFZIGFsc28NCnByb3ZpZGUgYSB2ZXJpZnkNCiAgICAgICAgIG9wZXJhdGlvbiB3aGljaCBh
IGNsaWVudCBjYW4gcmVxdWVzdCBmcm9tIHRoZSBzZXJ2ZXIgdG8gb2J0YWluDQppbmZvcm1hdGlv
bg0KICAgICAgICAgcmVnYXJkaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVk
IGFuZCBhcHBsaWVkDQpjb25maWd1cmF0aW9ucy4NCg0KDQoNCldlIGhhdmUgY29uc2Vuc3VzIG9u
IHRoZSBhYm92ZSwgYnV0IHdhbnRlZCB0byByZXdyaXRlIGl0IHJlbHlpbmcgbW9yZSBvbg0KdGhl
IHRlcm1zIGZyb20gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24sIGFuZCBhbHNvIHBvdGVudGlhbGx5
IG1lcmdlIEUgaW50bw0KRC4gDQoNCkFueWJvZHkgd2FudCB0byB0YWtlIGEgc3RhYiBhdCBpdD8N
Cg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KT24gMTAvMTQvMTUsIDg6MDAgUE0sICZxdW90O05hZGVh
dSBUaG9tYXMmcXVvdDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1s
aW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20iPiZsdDt0
bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSZndDs8L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+
T24gT2N0IDE0LCAyMDE1Ojc6NTEgUE0sIGF0IDc6NTEgUE0sIEtlbnQgV2F0c2VuIDxhIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFp
bHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPiZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OzwvYT4N
Cndyb3RlOg0KDQoNCg0KT24gOS8yOC8xNSwgMTo0MCBBTSwgJnF1b3Q7SnVlcmdlbiBTY2hvZW53
YWVsZGVyJnF1b3Q7DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxp
bmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp
dHkuZGUiPiZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PC9hPiB3
cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5P
biBXZWQsIFNlcCAyMywgMjAxNSBhdCAwMzowMzo1N1BNICYjNDM7MDAwMCwgS2VudCBXYXRzZW4g
d3JvdGU6DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSB3cmFwPSIiPlBv
cHBpbmcgdGhlIHN0YWNrIG9uIHRoaXMgaXNzdWUsIHRoZSBpc3N1ZSByZW1haW5zIGFzIHRvIHdo
YXQgdG8gZG8NCndpdGggcmVxdWlyZW1lbnQgMzoNCg0KICAzLiAgU3VwcG9ydCBmb3IgYm90aCB0
cmFuc2FjdGlvbmFsLCBzeW5jaHJvbm91cyBtYW5hZ2VtZW50IHN5c3RlbXMNCiAgICAgICBhcyB3
ZWxsIGFzIGRpc3RyaWJ1dGVkLCBhc3luY2hyb25vdXMgbWFuYWdlbWVudCBzeXN0ZW1zDQoNCjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPkkgZmFpbCB0byB1bmRlcnN0YW5kICd0
cmFuc2FjdGlvbmFsJyBhbmQgJ2Rpc3RyaWJ1dGVkJyBoZXJlLg0KPC9wcmU+DQo8L2Jsb2NrcXVv
dGU+DQo8cHJlIHdyYXA9IiI+SSBob3BlIHRoYXQgdGhlc2UgdGVybXMgd2lsbCBiZSBjbGFyaWZp
ZWQgb24gdG9tb3Jyb3cncyBjYWxsLiAgIFRoZXJlDQppcw0KYWxzbyBhIGNoYW5jZSB0aGF0IHRo
ZXNlIHRlcm1zIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0DQphbHRvZ2V0aGVyLA0KYXMg
dGhleSBtYXkgYmUgdmlld2VkIGFzIHVubmVjZXNzYXJpbHkgcXVhbGlmeSB0aGUNCnN5bmNocm9u
b3VzL2FzeW5jaHJvbm91cyB0ZXJtcy4NCg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPg0KPHByZSB3cmFwPSIiPkFuZA0KZnJhbmtseSwgSSBhbSBub3Qgc3VyZSB3aHkgdGhlIG1h
bmFnZW1lbnQgX3N5c3RlbXNfIGFyZSBjbGFzc2lmaWVkIHRvDQpiZSBzeW5jaHJvbm91cyBvciBh
c3luY2hyb25vdXMgLSBJIHRoaW5rIHdlIGFyZSB0YWxraW5nIGFib3V0DQpwcm90b2NvbHMgYmV0
d2VlbiBhIG1hbmFnZW1lbnQgc3lzdGVtIGFuZCBhIGRldmljZS4NCjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHByZSB3cmFwPSIiPkF5ZSwgSSBkaWRuJ3Qgc2VlIHRoYXQgYmVmb3JlLg0KDQpGaXJz
dCBvZmYsIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQgdGhlIHRlcm0gJnF1b3Q7c3lzdGVtJnF1b3Q7
IGlzIHVzZWQgNyB0aW1lcyB0bw0KcmVmZXIgdG8gdGhlIGRldmljZSAoZS5nLiwgTkMvUkMgc2Vy
dmVyKS4gIFRoZSB0ZXJtICZxdW90O3N5c3RlbSZxdW90OyBpcw0Kb3RoZXJ3aXNlDQpub3QgZGVm
aW5lZC4NCg0KQnV0IHRvIHlvdXIgbWFpbiBwb2ludCwgd2UgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg
dGhlIHRlcm1zIGEvc3luY2hyb25vdXMNCnRvDQpoYXZlIHRvIGRvIHdpdGggaW50ZXJuYWwgc2Vy
dmVyIHByb2Nlc3Npbmcgb2YgYW4gZWRpdCByZXF1ZXN0LCBidXQgaW4NCiczJw0KdGhlIHRlcm1z
IGFyZSBiZWluZyB1c2VkIHRvIHF1YWxpZnkgYSBtYW5hZ2VtZW50IHN5c3RlbSwgd2hpY2ggY2Fu
J3QgYmUNCnJpZ2h0LiAgSSB0aGluayB0aGF0ICczJyBzaG91bGQgYmUgcmV3cml0dGVuIHRvIGJl
IGEgc3RhdGVtZW50IGFib3V0DQpkZXZpY2VzLCBub3QgYSBzdGF0ZW1lbnQgYWJvdXQgbWFuYWdl
bWVudCBzeXN0ZW1zLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+CUl0IG1p
Z2h0IGJlIGJldHRlciB0byBmcmFtZSB0aGlzIGluIHRlcm1zIG9mIGEgY2xpZW50IGFuZCBhDQpz
ZXJ2ZXIuDQoNCgnigLlUb20NCg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
PHByZSB3cmFwPSIiPkFueXdheSwgSSBhbSBub3Qgc3VyZSAzLiBpcyBwcm9wZXJseSB3b3JkZWQg
dW50aWwgc29tZW9uZSBkZWZpbmVzDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
PHByZSB3cmFwPSIiPid0cmFuc2FjdGlvbmFsJywgJ2Rpc3RyaWJ1dGVkJywgJ3N5bmNocm9ub3Vz
IG1hbmFnZW1lbnQgc3lzdGVtcycgYW5kDQonYXN5bmNocm9ub3VzIG1hbmFnZW1lbnQgc3lzdGVt
cycuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5UaGUgYWdlbmRhIGZvciB0
b21vcnJvdydzIGludGVyaW0hICA6KQ0KDQoNCktlbnQNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0i
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPg0KPGEgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KPGEgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bmV0
bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIi
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2Qg
bWFpbGluZyBsaXN0DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxp
bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT4NCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPg0KPC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5uZXRtb2QgbWFpbGluZyBsaXN0
PC9zcGFuPjxicj4NCjxzcGFuPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRv
Om5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48
YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv
dGU+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_24CFE232441E453D9597B73820FF9A82junipernet_--


From nobody Fri Oct 16 09:36:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4271A92AE for ; Fri, 16 Oct 2015 09:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4z4i0MajcU9 for ; Fri, 16 Oct 2015 09:36:26 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096421A9240 for ; Fri, 16 Oct 2015 09:36:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6867; q=dns/txt; s=iport; t=1445013386; x=1446222986; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=bENe1IW9pp8U4UTdQIol9prIQflQZkaRKtkL83dMGQA=; b=BnrbvpP8ukOPB2sVik6NK/IHfsapPVcTkiWq6xNA6Zcsy17pNFrZ+W6w P8SYNxUc8QAxvMUhv2KmKLr/sRDnBDFoorgIkyjpFm5CZUcjmki0l6C94 n+JqddnfzoFyGieKGKRoNQEqqRznWNi2pQ/p1l8WZhIus76SBqNcrpz4j 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DJAQA4JyFW/xbLJq1eglm/fAENgVmDRoJYAoFvFAEBAQEBAQGBCoQmAQEBAwF4AQULCw4KCRYECwkDAgECAUUGAQwIAQGIIgjDYgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGdoR+hEJLB4QuAQSSVoNHjRuBWIc7ijWISB8BAUKCRIFAPYYaAQEB
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800";  d="scan'208,217";a="630363252"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Oct 2015 16:36:23 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9GGaLxM006097; Fri, 16 Oct 2015 16:36:23 GMT
To: Kent Watsen , Gert Grammel 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net> 
From: Robert Wilton 
Message-ID: <56212777.4090207@cisco.com>
Date: Fri, 16 Oct 2015 17:36:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030402000504010506070301"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 16:36:28 -0000

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



On 16/10/2015 14:45, Kent Watsen wrote:
>
> Gert writes:
> > I don't see the need for defining synchronous/asynchronous config 
> servers.
>
> Thank you (and Juergen) for the confirmation.   Again, if no 
> objections, these two terms will not be removed.
>
>
> > The new definitions look good. Later in the discussion there was a common
> > sentiment that the requirement for synchronous operations contained some
> > crisp wording we could use here too.  I particularly liked the 
> mentioning of
> > blocking requests for some time,
>
> [Note: the following removes the last two sentences on "transactions", 
> as being discussed elsewhere on this thread]
>
> OLD:
>
>     Synchronous configuration operation - A configuration request to 
> update
>     the running configuration of a server that is applied 
> synchronously with
>     respect to the client request.  The server MUST fully attempt to 
> apply
>     the configuration change to all impacted components in the server,
>     updating both the server's intended and applied configuration (see 
> terms),
>     before replying to the client.
>
> NEW
>
>     Synchronous configuration operation - A configuration request to 
> update
>     the running configuration of a server that is applied 
> synchronously with
>     respect to the client request (i.e. a blocking call).  The server 
> MUST fully attempt to apply
>     the configuration change to all impacted components in the server,
>     updating both the server's intended and applied configuration (see 
> terms),
>     before replying to the client.
>
>
> What do you think?
Yes, looks good.

Thanks,
Rob


>
> Kent
>


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


  
    
  
  
    

    

    
On 16/10/2015 14:45, Kent Watsen wrote:

    

    

      
      


      

      
Gert writes:

      
> I don't see the need for defining
        synchronous/asynchronous config servers.

      


      

      
Thank you (and Juergen) for the confirmation.   Again, if no
        objections, these two terms will not be removed.

      


      

      


      

      
        

          
> The new definitions look
            good. Later in the discussion there was a common

        

      
      
> sentiment that the requirement for synchronous
        operations contained some

      
> crisp wording we could use here too.  I particularly
        liked the mentioning of

      
> blocking requests for some time,

      


      

      
[Note: the following removes the last two sentences on
        "transactions", as being discussed elsewhere on this thread]

      


      

      
OLD:

      


      

      

        
    Synchronous configuration operation - A configuration
          request to update

        
    the running configuration of a server that is applied
          synchronously with

        
    respect to the client request.  The server MUST fully
          attempt to apply 

        
    the configuration change to all impacted components in
          the server,

        
    updating both the server's intended and applied
          configuration (see terms),

        
    before replying to the client.

      

      


      

      
NEW

      


      

      

        
    Synchronous configuration operation - A configuration
          request to update

        
    the running configuration of a server that is applied
          synchronously with

        
    respect to the client request (i.e. a blocking call).
           The server MUST fully attempt to apply 

        
    the configuration change to all impacted components in
          the server,

        
    updating both the server's intended and applied
          configuration (see terms),

        
    before replying to the client.

      

      


      

      


      

      
        

          

              

                

                  
                    

                      
What do you
                        think?

                    

                  

              

            

        

      

    Yes, looks good.

    

    Thanks,

    Rob

    

    

    

        

          

              

                

                    

                    

                  

              

            

        

      
      


      

      
Kent

      


      

    

    

  


--------------030402000504010506070301--


From nobody Fri Oct 16 09:44:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492EE1A92FB for ; Fri, 16 Oct 2015 09:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWYKhD0XyXRg for ; Fri, 16 Oct 2015 09:44:12 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED301A92F3 for ; Fri, 16 Oct 2015 09:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2373; q=dns/txt; s=iport; t=1445013851; x=1446223451; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5UukDfCvlkeHtjbCXKt9fsyyQfnwCi7Puv1vylj3BoI=; b=A/RxbVpQY9Uj4l7jBFUsWoEifOo+brsn5+gXxUbGRXEfKn7TfvKZzSkx ha19Lrz5Al/hb11Z3ISs5X6+gzIGm817GKZ76rO3Xu2zTaGli9zJgkLLN dd10JUujgIxafEm5+HllNLB2vXwOHrkGcsAUUXClwZFeJliT/4XdBLWvJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBACDKCFW/xbLJq1exDyDRoJYAoIDAQEBAQEBgQuEJgEBAQMBOEABEAsOCgkWBAsJAwIBAgFFBgEMCAEBFIgOCMNiAQEBAQEBAQEBAQEBAQEBAQEBGoZ2hH6EQksHhC4BBJYdjRuBWIc7ijWISGOCRIFAPYYaAQEB
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800"; d="scan'208";a="605769056"
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; 16 Oct 2015 16:44:09 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GGi91R022012; Fri, 16 Oct 2015 16:44:09 GMT
To: Kent Watsen , Martin Bjorklund 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com> 
From: Robert Wilton 
Message-ID: <5621294A.6040107@cisco.com>
Date: Fri, 16 Oct 2015 17:43:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 16:44:13 -0000

On 16/10/2015 14:59, Kent Watsen wrote:
>
>>>>      3.  Support for both synchronous and asynchronous configuration
>>>>          operations
>>>>
>>>>          A. A server may choose to support only synchronous
>>>> configuration
>>>>             operations, or only asynchronous configuration operations,
>>>> or
>>>>             both synchronous and asynchronous configuration operations
>>>> in
>>>>             a client specified per-operation basis.
>>> I think the most common mode *today* is a mix of sync/async, on a
>>> per-object basis.
>> Yes, I agree.
>
> Wait, I think we're talking about different things.  Martin, I'm sure that
> internal to a NC/RC server, parts of the intended configuration is
> actually applied synchronously (e.g., a hostname) whereas other parts are
> not (e.g., config for data plane).   But that nuance is not currently
> exposed in any way today -right?
I think that today, from what a client sees/experiences, many replies 
from netconf servers fits neither the definition of "synchronous 
configuration operation" nor "asynchronous configuration operation", but 
instead, the reply is somewhere between the two extremes.

So the question I was trying to raise is whether servers that need to 
meet the opstate requirements have to change to strictly comply with the 
defined async or sync config operation semantics?  E.g. not just adding 
a "done-applying" option, but perhaps also adding something along the 
lines of a "done-verifying" option.

Thanks,
Rob


>
> What we're talking about here is an ability for a client to request a
> protocol operation (PATCH) to block, or for the "done-applying"
> notification to not be sent, until all that processing of the request is
> complete.  This regardless if the request contains a mix of nodes that are
> applied internally sync/async.  Makes sense? - or it is something else?



>
>
>
>>>>          B. Support for synchronous operations as per the definition of
>>>>             "synchronous configuration operation".
>>> Doesn't this follow from A?
>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>> would suggest that we also delete the analogous first sentence of C, and
>> re-introduce the "(see terms)" text in the headline description.
> +1
>
>
> Kent  // as a contributor
>
>
> .
>


From nobody Fri Oct 16 09:52:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4120D1B2ADF for ; Fri, 16 Oct 2015 09:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES48q91cPl-K for ; Fri, 16 Oct 2015 09:52:32 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5CA1B2FD7 for ; Fri, 16 Oct 2015 09:52:30 -0700 (PDT)
Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 16:52:29 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 16:52:28 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 16:52:28 +0000
From: Gert Grammel 
To: Kent Watsen 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIGAALIfAIAAS+nk///OgQCAAFz6ZA==
Date: Fri, 16 Oct 2015 16:52:28 +0000
Message-ID: <134E86B5-8C51-4C56-ADEC-6973CB68724B@juniper.net>
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>  <381B554A-3421-4AC9-AB9B-FB2F6C670C3E@juniper.net>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.99.11]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:53LYS2eW0I+6KScJBOPCIModivo55oGBM6T4Q6zSag8kZE7kLeUlM5VkAqAuwos9N74fEETAYktgeDj9/3Wzd864YvcPmLt/VQ5oZa6K0K69xxVHXoV7g5ip1xENwDRkOvb9kOgwiF+U1BcIjb52uw==; 24:r1Cgz/nO5mP2cmSWPpVANiDKOcGJ4zdGrkHHqg2VyN5E+m4kRi5jVLVSjeeYV/6XdE0Qe1Jy2oLy8HAE8onCxZh3AMkChTeE1lU3qPC5ot0=; 20:Pg9HcGJa1+cnV8R3epkcasSm+oI0HFccA8B9Uq6iz3HIjgHKND3d4uanxQxLGkTIGN4kWXBB49IpxpFCUPgO3w==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(76104003)(377454003)(199003)(97736004)(99286002)(122556002)(101416001)(5004730100002)(19580395003)(19580405001)(5007970100001)(87936001)(5001960100002)(5002640100001)(4001450100002)(50986999)(81156007)(54356999)(1941001)(46102003)(40100003)(86362001)(93886004)(82746002)(83716003)(76176999)(92566002)(36756003)(66066001)(106116001)(5008740100001)(106356001)(64706001)(16236675004)(561944003)(189998001)(102836002)(110136002)(10400500002)(2950100001)(11100500001)(105586002)(33656002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_134E86B58C514C56ADEC6973CB68724Bjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:52:28.6845 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB421; 2:mKegm68wN94Ns1jro5H6Ri6qm1kzaxjgSl6yeAxkwtKhyqLpfsy+8lxHfX6te+W9qu/wNk2NHZgIQrokl5gMQfimU0ANnIo7Up4uGrierDBEckpgh6Juz1oVwlAhVy7bDVGqzRxmsPhRvpALgF96hAIIO+Fl7NFHfEYYF/YaLm0=; 23:Yse3t4/pHIG3laL+vk58wKZW9N5QiqYGKZPpay6//P6CzNFewf6LWWpMsCWG7vC8+mACPDbGiw3SXdjEbCyamTMKbNQzfVGitbfF78daSNz4SjeSIav7DjS6Pce+RqUHuea9SZIqrLeeii/nClr6TnjkE847IkXpSEoEWb7TirPS29XIzVoVjdoSpP6eHJG8
X-OriginatorOrg: juniper.net
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 16:52:36 -0000

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

Ok,

The term 'intended config is updated' is probably correct but sounds a bit =
odd to me.    I associate with "update" a process of alignment. In the case=
 of intended config it is more like a config that is imposed by the client.=
 Later the update of the applied config is started.

Certainly a terminology issue, but I wanted to bring it up maybe others app=
ly similar semantics.


Gert


Sent from my Apple ][

On 16 Oct 2015, at 17:19, Kent Watsen > wrote:


> Why is there a need to update the intended config?

Because that is what happens via requests like  and PATCH.  Th=
e intended (running) config gets updated first and then config is distribut=
ed to internal components, ultimately updated the applied config.

Kent  // as a contributor


From: Gert Grammel >
Date: Friday, October 16, 2015 at 10:16 AM
To: Kent Watsen >
Cc: Robert Wilton >, "netmod@ie=
tf.org" >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy=
nchronous (esp. wrt intended and applied)

Kent,

The new one looks much better. However the last sentence is confusing with =
respect to intended config. Why is there a need to update the intended conf=
ig?

Proposal:
The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating the server's applied configuration (see terms),
    before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen > wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers=
.

Thank you (and Juergen) for the confirmation.   Again, if no objections, th=
ese two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning=
 of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as b=
eing discussed elsewhere on this thread]

OLD:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.

NEW

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request (i.e. a blocking call).  The server MUST =
fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.


What do you think?

Kent


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







Ok, 







The term 'intended config is updated' is pro=
bably correct but sounds a bit odd to me.    I associate with &qu=
ot;update" a process of alignment. In the case of intended config it i=
s more like a config that is imposed by the client. Later
 the update of the applied config is started.







Certainly a terminology issue, but I wanted =
to bring it up maybe others apply similar semantics.





Gert









Sent from my Apple ][




On 16 Oct 2015, at 17:19, Kent Watsen <kwatsen@juniper.net> wrote:















> Why is there a need to update the intended config? 







Because that is what happens via requests like <edit-config> and=
 PATCH.  The intended (running) config gets updated first and then con=
fig is distributed to internal components, ultimately updated the applied c=
onfig.







Kent  // as a contributor














From: Gert Grammel <ggrammel@juniper.net>

Date: Friday, October 16, 2015 at 1=
0:16 AM

To: Kent Watsen <kwatsen@juniper.net>

Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap=
plied)













Kent,







The new one looks much better. However the l=
ast sentence is confusing with respect to intended config. Why is there a n=
eed to update the intended config?







Proposal:






The server MUST fully attempt to apply 

    the configuration change to all impacted componen=
ts in the server,


    updating the server's applied configuration (see =
terms),


    before replying to the client.




Sent from my Apple ][




On 16 Oct 2015, at 15:45, Kent Watsen <kwatsen@juniper.net> wrote:















Gert writes:


> I don't see the need for defining synchronous/asynchronous config=
 servers.







Thank you (and Juergen) for the confirmation.   Again, if no obje=
ctions, these two terms will not be removed.















> The new definitions look good. Later in=
 the discussion there was a common





> sentiment that the requirement for synchronous operations contain=
ed some


> crisp wording we could use here too.  I particularly liked t=
he mentioning of


> blocking requests for some time,







[Note: the following removes the last two sentences on "transacti=
ons", as being discussed elsewhere on this thread]







OLD:









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request.  The server MUST ful=
ly attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.









NEW









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request (i.e. a blocking call). &n=
bsp;The server MUST fully attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.


























What do you think?


















Kent





















--_000_134E86B58C514C56ADEC6973CB68724Bjunipernet_--


From nobody Fri Oct 16 10:15:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4C1ACDEF for ; Fri, 16 Oct 2015 10:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNgbAkOTUYng for ; Fri, 16 Oct 2015 10:15:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E8F1ACD0D for ; Fri, 16 Oct 2015 10:15:01 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 16 Oct 2015 17:14:58 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.119]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 17:14:57 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgCAAAiu5A==
Date: Fri, 16 Oct 2015 17:14:57 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com> ,<5621294A.6040107@cisco.com>
In-Reply-To: <5621294A.6040107@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [80.187.99.11]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB455; 5:sHBJu5ZSdgXzp1469n6uLM82yvXmKs+PXuOxZmBKNBD4xSZOivBD9c0fzppBoQpnhAT1S/q39WdFtw+4TxTtNmLsNyA5IVYXqBrX/NbqgQ3sj49lpxzH1zItIT0Ls8cWLgfaiSaW921tMdW+NgcwMw==; 24:2PcKRPDeXFhjYbr71zzRFmQ1y0Ajz9KsgaYRokOoUIyhPJ7CeLBcrACm5hipfOSFPpR9xHOQbc07P4c38HmWJoCXO7rT4LTYqGJILBz1Xx8=; 20:PukLqh5y3doh+wHO+8aagsqrL4XBIJKQmoEsbHcGnV7bFJcqCuXrQ1utxjksb6KruSMm5Ib2+w3MoOGMjX8mnA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BN1PR05MB455; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB455; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(51444003)(479174004)(24454002)(189002)(76176999)(87936001)(97736004)(106356001)(40100003)(5002640100001)(122556002)(189998001)(5001960100002)(92566002)(99286002)(10400500002)(19580405001)(36756003)(102836002)(5007970100001)(5004730100002)(93886004)(86362001)(81156007)(110136002)(15975445007)(66066001)(64706001)(105586002)(54356999)(106116001)(83716003)(101416001)(50986999)(19580395003)(2900100001)(82746002)(5008740100001)(2950100001)(33656002)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 17:14:57.7073 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 17:15:04 -0000

Rob,

Current implementations are incomplete asynchronous, because they didn't ve=
rify the config as operational and applied.

What is frequently done is to perform additional checks on the intended con=
fig that go beyond a syntax check. That is fine, but I have a hard time to =
consider this to be "hybrid" which suggests something in between asynchrono=
us and synchronous.

>From a client perspective an asynchronous server and a hybrid server look t=
he same. The difference is that the asynchronous one should convey a "finis=
hed" information to the client, while the hybrid would remain in a "trust m=
e babe" mode forever.


Another way to look at hybrids is to consider them "cheating synchronous". =
Given that the new config may not have been applied at the time of the resp=
onse to the client. This is worse than the situation before where a missing=
 verify lets the client know that something may still go on. Clients can't =
tell if servers are cheating :-)

Gert



Sent from my Apple ][

> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
>=20
>=20
>=20
>> On 16/10/2015 14:59, Kent Watsen wrote:
>>=20
>>>>>     3.  Support for both synchronous and asynchronous configuration
>>>>>         operations
>>>>>=20
>>>>>         A. A server may choose to support only synchronous
>>>>> configuration
>>>>>            operations, or only asynchronous configuration operations,
>>>>> or
>>>>>            both synchronous and asynchronous configuration operations
>>>>> in
>>>>>            a client specified per-operation basis.
>>>> I think the most common mode *today* is a mix of sync/async, on a
>>>> per-object basis.
>>> Yes, I agree.
>>=20
>> Wait, I think we're talking about different things.  Martin, I'm sure th=
at
>> internal to a NC/RC server, parts of the intended configuration is
>> actually applied synchronously (e.g., a hostname) whereas other parts ar=
e
>> not (e.g., config for data plane).   But that nuance is not currently
>> exposed in any way today -right?
> I think that today, from what a client sees/experiences, many replies fro=
m netconf servers fits neither the definition of "synchronous configuration=
 operation" nor "asynchronous configuration operation", but instead, the re=
ply is somewhere between the two extremes.
>=20
> So the question I was trying to raise is whether servers that need to mee=
t the opstate requirements have to change to strictly comply with the defin=
ed async or sync config operation semantics?  E.g. not just adding a "done-=
applying" option, but perhaps also adding something along the lines of a "d=
one-verifying" option.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> What we're talking about here is an ability for a client to request a
>> protocol operation (PATCH) to block, or for the "done-applying"
>> notification to not be sent, until all that processing of the request is
>> complete.  This regardless if the request contains a mix of nodes that a=
re
>> applied internally sync/async.  Makes sense? - or it is something else?
>=20
>=20
>=20
>>=20
>>=20
>>=20
>>>>>         B. Support for synchronous operations as per the definition o=
f
>>>>>            "synchronous configuration operation".
>>>> Doesn't this follow from A?
>>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>>> would suggest that we also delete the analogous first sentence of C, an=
d
>>> re-introduce the "(see terms)" text in the headline description.
>> +1
>>=20
>>=20
>> Kent  // as a contributor
>>=20
>>=20
>> .
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Oct 16 10:17:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33641B31FC for ; Fri, 16 Oct 2015 10:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ2nBEU1U7YO for ; Fri, 16 Oct 2015 10:17:42 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA3B1B31FF for ; Fri, 16 Oct 2015 10:17:40 -0700 (PDT)
Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 17:17:38 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 17:17:38 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 17:17:37 +0000
From: Kent Watsen 
To: Robert Wilton , Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgD//8ZaAA==
Date: Fri, 16 Oct 2015 17:17:37 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com>
In-Reply-To: <5621294A.6040107@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:7vAI35ZYBYb7xTVivkDiGTSPDlzwAgHskKptHGsnpzVrJOWkCbPBapkGtjTrpuqg080Cx7Prk1QLkUBrHkzplfSd59BWgVJ67Jo1ubDJiIF91yMRY6BrBePypjvF7tyVPd0+/3UDYBV6zl38DhYrXw==; 24:RheG4xS7gJRMgtIxbgm8KDnfC3pxBpzzwXoOXUeujOEtn/vaqj7V8srmFSmBJGkcXAHlodH3wera+Jzz+SsNHbQwtOq1zB9cn4jHwH/Ef80=; 20:xO23Ti8IQvlNjgu4Dr4V4im5VKUkMo6f0jQn8/VzrcRunp8ybOgYFB1n0p0s2OV1CLFs4d2AtvMsv67vc1Z9Ag==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(51444003)(122556002)(106356001)(86362001)(10400500002)(66066001)(189998001)(5002640100001)(5001960100002)(106116001)(87936001)(40100003)(5008740100001)(93886004)(4001350100001)(81156007)(50986999)(97736004)(54356999)(102836002)(2900100001)(105586002)(83506001)(99286002)(2950100001)(101416001)(64706001)(92566002)(76176999)(5004730100002)(46102003)(36756003)(5001770100001)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <67DC6569D0385E499D4BAD8989D4976B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 17:17:37.4146 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB460; 2:aK0RxLrkQ/4jeJMhCN6ls4ITdca9JToabdXqjSr/fjU9nUmVuWAfiewaYs5XeDOsfSEkfaSf4QbZsCkKrNv49QIM985X/PDnipdaO0Dm4hyJC45NEl8ef1tu6C7rBvUDQT+dRrFqIDmbzT+f1AtUcu81iqvaJt1SdH81yu+KYNc=; 23:0meI7l87xWeKW4ZncNnYzRxyRH6J3Dx3yKjJzzHTsQZF/oS1TW/itIcPiPoQ7TQ5Fr+7iAT8fGix8fSe76ZxhMcuaER5L+j6CI/3CtNWoqGJeMLbKmwjnz9GGsvqZaihrADP+nHQo1U1gKmI9KO7XEfhRH3C2i9KpMqA44frJrdxJc5oeeFKiLtOkY+wgMFH
X-OriginatorOrg: juniper.net
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 17:17:43 -0000

>>Wait, I think we're talking about different things.  Martin, I'm sure
>>that
>> internal to a NC/RC server, parts of the intended configuration is
>> actually applied synchronously (e.g., a hostname) whereas other parts
>>are
>> not (e.g., config for data plane).   But that nuance is not currently
>> exposed in any way today -right?
>I think that today, from what a client sees/experiences, many replies
>from netconf servers fits neither the definition of "synchronous
>configuration operation" nor "asynchronous configuration operation", but
>instead, the reply is somewhere between the two extremes.

I don't think it matters if the server is anywhere between the two
extremes.  My point is that clients currently have no choice but to handle
it as we define "asynchronous" today.  This came up a couple years ago and
it was confirmed then that  does not mean "applied".


>So the question I was trying to raise is whether servers that need to
>meet the opstate requirements have to change to strictly comply with the
>defined async or sync config operation semantics?  E.g. not just adding
>a "done-applying" option, but perhaps also adding something along the
>lines of a "done-verifying" option.

NC/RC servers (other protocols may vary) have to change only to the extent
they want to support some new features.  For instance, if they want to
support blocking, they can advertise a module defining the extensions
needed.  Likewise, if they want to support transactional/atomic behavior
(wrt applying the config), they can advertise a module
defining the extensions needed to do that too.

Where do you derive there being a requirement for a server to notify when
done verifying?  - has that been discussed before?


Also not that whilst a done-verifying notification would be possible, the
synchronous equivalent isn't (AFAICT), as we define it as not returning
until done-applying (long after the done-verifying step).


Kent  // as a contributor


>
>Thanks,
>Rob


From nobody Fri Oct 16 11:50:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0F1ACDC3 for ; Fri, 16 Oct 2015 11:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXf4ueILpq1P for ; Fri, 16 Oct 2015 11:50:55 -0700 (PDT)
Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07E51ACDB2 for ; Fri, 16 Oct 2015 11:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5525; q=dns/txt; s=iport; t=1445021454; x=1446231054; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xQIidELr32p9Iwl1ZS01b1gO0O2h2eSe6JOSaX5F08w=; b=ORJTkT+Qagr10Y3cmCruUeK+HYgP1K2Ri7bU3LM124eOMErqB48CLd0R 2Qt1p2MK4sMhNPyqzLsfnYuIV9JSsowHM1IY1yojr32EjfWz6Ny3IJi4w 3iGi2uxQTwvchxGr+IRx/b3cxUOVI66HqjMyushevChcMksJQnxCoZm54 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQAkRiFW/xjFo0heg3puvW0BDYFZFwqFM0oCgXAUAQEBAQEBAYEKhCYBAQEDAQEBATU2CgEQCw4KCRYECwkDAgECARUwBg0GAgEBFIgOCA3DZwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnaEfoRCSweELgEElh2NG4FYhzuKNYhIHwEBQoJEgUA9M4VnAQEB
X-IronPort-AV: E=Sophos;i="5.17,690,1437436800"; d="scan'208";a="25428809"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 16 Oct 2015 18:50:50 +0000
Received: from [10.61.217.184] ([10.61.217.184]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9GIomDh027690; Fri, 16 Oct 2015 18:50:49 GMT
To: Gert Grammel 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com> 
From: Robert Wilton 
Message-ID: <562146F8.4020503@cisco.com>
Date: Fri, 16 Oct 2015 19:50:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 18:50:57 -0000

Hi Gert,

On 16/10/2015 18:14, Gert Grammel wrote:
> Rob,
>
> Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied.
>
> What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be "hybrid" which suggests something in between asynchronous and synchronous.
I'm talking about netconf servers that effectively apply most of their 
configuration before they reply.  E.g. they might take 10 minutes to reply.

Perhaps this isn't a valid Netconf implementation, and all Netconf 
server implementations are expected to be asynchronous w.r.t to when 
they apply their configuration - but I can't see where this is stated in 
the NETCONF RFC (but possibly I'm not looking in the right place).


>
> >From a client perspective an asynchronous server and a hybrid server look the same. The difference is that the asynchronous one should convey a "finished" information to the client, while the hybrid would remain in a "trust me babe" mode forever.
Yes, but this isn't the only difference:
  - a client could expect that an asynchronous config operation response 
should be reasonably expedient.  E.g. if a client was to update 10 
devices each with a reasonable size configuration (that takes minutes to 
apply) in an asynchronous way then it might reasonably consider 
sequencing the async config requests to each server on one thread.  If 
each server acknowledged the requests in a couple of seconds then all 
the servers would broadly end up applying the configuration concurrently.
- however, if the servers were hybrid, and their replies were sent much 
closer to when the configuration was actually applied then initiating 
the requests sequentially would effectively mean that the devices end up 
applying the configuration serially which would end up taking much 
longer.  I.e. it seems reasonable that a client may want to 
differentiate between the behaviour of these two servers even if how it 
handles the resultant config changes is the same.

>
>
> Another way to look at hybrids is to consider them "cheating synchronous". Given that the new config may not have been applied at the time of the response to the client. This is worse than the situation before where a missing verify lets the client know that something may still go on. Clients can't tell if servers are cheating :-)
Yes, but clients also need to be able to determine if the server is 
likely to be slow to response, because then the client would probably be 
designed to interact with the server in a different fashion (e.g. use a 
pool of threads to initiate the updates concurrently).

Thanks,
Rob


>
> Gert
>
>
>
> Sent from my Apple ][
>
>> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
>>
>>
>>
>>> On 16/10/2015 14:59, Kent Watsen wrote:
>>>
>>>>>>      3.  Support for both synchronous and asynchronous configuration
>>>>>>          operations
>>>>>>
>>>>>>          A. A server may choose to support only synchronous
>>>>>> configuration
>>>>>>             operations, or only asynchronous configuration operations,
>>>>>> or
>>>>>>             both synchronous and asynchronous configuration operations
>>>>>> in
>>>>>>             a client specified per-operation basis.
>>>>> I think the most common mode *today* is a mix of sync/async, on a
>>>>> per-object basis.
>>>> Yes, I agree.
>>> Wait, I think we're talking about different things.  Martin, I'm sure that
>>> internal to a NC/RC server, parts of the intended configuration is
>>> actually applied synchronously (e.g., a hostname) whereas other parts are
>>> not (e.g., config for data plane).   But that nuance is not currently
>>> exposed in any way today -right?
>> I think that today, from what a client sees/experiences, many replies from netconf servers fits neither the definition of "synchronous configuration operation" nor "asynchronous configuration operation", but instead, the reply is somewhere between the two extremes.
>>
>> So the question I was trying to raise is whether servers that need to meet the opstate requirements have to change to strictly comply with the defined async or sync config operation semantics?  E.g. not just adding a "done-applying" option, but perhaps also adding something along the lines of a "done-verifying" option.
>>
>> Thanks,
>> Rob
>>
>>
>>> What we're talking about here is an ability for a client to request a
>>> protocol operation (PATCH) to block, or for the "done-applying"
>>> notification to not be sent, until all that processing of the request is
>>> complete.  This regardless if the request contains a mix of nodes that are
>>> applied internally sync/async.  Makes sense? - or it is something else?
>>
>>
>>>
>>>
>>>>>>          B. Support for synchronous operations as per the definition of
>>>>>>             "synchronous configuration operation".
>>>>> Doesn't this follow from A?
>>>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>>>> would suggest that we also delete the analogous first sentence of C, and
>>>> re-introduce the "(see terms)" text in the headline description.
>>> +1
>>>
>>>
>>> Kent  // as a contributor
>>>
>>>
>>> .
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Fri Oct 16 12:15:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D601ACED0 for ; Fri, 16 Oct 2015 12:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmxIHD-sXolM for ; Fri, 16 Oct 2015 12:15:52 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A7B1ACECD for ; Fri, 16 Oct 2015 12:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2822; q=dns/txt; s=iport; t=1445022952; x=1446232552; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zCwlXxekuFV1r7PMe2Emw8SMKwrqksOEDy20/eQIqs8=; b=l+HaYsSYHzP8/a4pNF5o1oTa3s9D73Ft+2FognHQks4tOxzmQ7Yyf04q FCjn0asBgCgMK1OinPIIyctdKML2Txg3qEWChsqGBLpI+Osjz9CHwKzO0 iR5s9OUBM3lrHqvDy31CyQQ2/+t8G5auBwR7BIPzG0GMwP7jVtAw2qZsp A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DJAQDNSyFW/xbLJq1ewlUBDYFZg0aCWAKBcBQBAQEBAQEBgQqEJgEBAQMBOEABEAsOCgkWBAsJAwIBAgFFBgEMCAEBiCIIw3YBAQEBAQEBAQEBAQEBAQEBAQEahnaEfoRCSweELgEElh2NG4FYhzuKNYhIHwEBQoJEgUA9hhoBAQE
X-IronPort-AV: E=Sophos;i="5.17,690,1437436800"; d="scan'208";a="630364357"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Oct 2015 19:15:49 +0000
Received: from [10.61.217.184] ([10.61.217.184]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GJFnnd016067; Fri, 16 Oct 2015 19:15:49 GMT
To: Kent Watsen , Martin Bjorklund 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com> 
From: Robert Wilton 
Message-ID: <56214CD6.1070100@cisco.com>
Date: Fri, 16 Oct 2015 20:15:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 19:15:54 -0000

Hi Kent,

On 16/10/2015 18:17, Kent Watsen wrote:
>
>>> Wait, I think we're talking about different things.  Martin, I'm sure
>>> that
>>> internal to a NC/RC server, parts of the intended configuration is
>>> actually applied synchronously (e.g., a hostname) whereas other parts
>>> are
>>> not (e.g., config for data plane).   But that nuance is not currently
>>> exposed in any way today -right?
>> I think that today, from what a client sees/experiences, many replies
> >from netconf servers fits neither the definition of "synchronous
>> configuration operation" nor "asynchronous configuration operation", but
>> instead, the reply is somewhere between the two extremes.
> I don't think it matters if the server is anywhere between the two
> extremes.  My point is that clients currently have no choice but to handle
> it as we define "asynchronous" today.  This came up a couple years ago and
> it was confirmed then that  does not mean "applied".
I think that it matters only in how long a client might reasonably 
expect to wait for a reply from the server.

>
>
>> So the question I was trying to raise is whether servers that need to
>> meet the opstate requirements have to change to strictly comply with the
>> defined async or sync config operation semantics?  E.g. not just adding
>> a "done-applying" option, but perhaps also adding something along the
>> lines of a "done-verifying" option.
> NC/RC servers (other protocols may vary) have to change only to the extent
> they want to support some new features.  For instance, if they want to
> support blocking, they can advertise a module defining the extensions
> needed.  Likewise, if they want to support transactional/atomic behavior
> (wrt applying the config), they can advertise a module
> defining the extensions needed to do that too.
>
> Where do you derive there being a requirement for a server to notify when
> done verifying?  - has that been discussed before?
Sorry, a loose/bad description.

I think that you are saying that there could be an optional "block" 
protocol extension to allow a client to specify that it wants 
synchronous semantics.

I was trying to specify an explicit asynchronous equivalent, e.g. an 
optional "don't block at all" protocol extension to allow a client to 
specify that it wants the server to exhibit asynchronous configuration 
request semantics (and hence reply to the request sooner than an 
existing Netconf server might otherwise have done).

Thanks,
Rob

>
>
> Also not that whilst a done-verifying notification would be possible, the
> synchronous equivalent isn't (AFAICT), as we define it as not returning
> until done-applying (long after the done-verifying step).
>
>
> Kent  // as a contributor
>
>
>> Thanks,
>> Rob
> .
>


From nobody Fri Oct 16 12:49:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA771B337E for ; Fri, 16 Oct 2015 12:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxj3KakIJEEO for ; Fri, 16 Oct 2015 12:49:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 934CF1B337B for ; Fri, 16 Oct 2015 12:49:45 -0700 (PDT)
Received: from localhost (h-46-59-33-90.na.cust.bahnhof.se [46.59.33.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 0E9A21AE0478; Fri, 16 Oct 2015 21:49:44 +0200 (CEST)
Date: Fri, 16 Oct 2015 21:49:35 +0200 (CEST)
Message-Id: <20151016.214935.865701461081083525.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 19:49:47 -0000

Andy Bierman  wrote:
> Hi,
> 
> I find all this fretting over when-stmt corner-cases to be a waste of time.
> I certainly have no intention of spending 100s of hours coding for
> corner-cases
> that have no operational value whatsoever.  When-stmt has always been full
> of problems that exist on paper but not in real servers.
> 
> There is no need for the YANG spec to point out that the constraints
> only apply to YANG. That is self-evident.
> 
> Why doesn't when-stmt apply to a plain rpc?
> 
> 
>    rpc plot-point {
>      input {
>         leaf 3d {
>           type boolean;
>            default false;
>         }
>         leaf X { type uint32; }
>         leaf Y { type uint32; }
>         leaf Z {
>           when "../3d";
>           type uint32;
>        }
>      }
>    }
> 
> 
> Are you saying that the when-stmt for Z is not allowed?

No.

> Or that it gets ignored and not enforced?

No.

> IMO this section was rather clear -- it applies to when-stmt
> in the RPC input.

No - and that's the problem which we need to fix.  It might be that we
all agree on the expected server behavior ,and if that's the case, we
just need to fix the text to align with what we meant.  In order to
resolve this, it would be very helpful if you could provide your
opinion on the questions in the three scenarios below:

> > Suppose we have:
> >
> >  leaf a {
> >    when "../b = 42";
> >    type int32;
> >  }
> >  leaf b {
> >    type int32;
> >  }
> >
> >
> > Scenario A
> > ----------
> > The DB contains b=10
> >
> > The server gets an edit-config with:
> >
> >    2
> >
> > What is the result?
> >
> >  1)  an error is returned
> >  2)  ok; the request to set a to 2 is silently dropped
> >
> >
> > Scenario B
> > ----------
> > The DB contains b=10.
> >
> > The server gets an edit-config with:
> >
> >    2
> >    42
> >
> > What is the result?
> >
> >  1)  an error is returned
> >  2)  ok, db now has b=42; the request to set a to 2 is silently
> >      dropped
> >  3)  ok, db now has a=2 and b=42
> >
> >
> > Scenario C  (same as 2, but different order in edit-config)
> > ----------
> > The DB contains b=10.
> >
> > The server gets an edit-config with:
> >
> >    42
> >    2
> >
> > What is the result?
> >
> >  1)  an error is returned
> >  2)  ok, db now has b=42; the request to set a to 2 is silently
> >      dropped
> >  3)  ok, db now has a=2 and b=42


/martin


From nobody Fri Oct 16 12:55:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6A61B3399 for ; Fri, 16 Oct 2015 12:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEqk4_WzWetf for ; Fri, 16 Oct 2015 12:55:53 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 F24C51B3395 for ; Fri, 16 Oct 2015 12:55:52 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so79363239lbb.0 for ; Fri, 16 Oct 2015 12:55:51 -0700 (PDT)
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=VaIKErz3g2l35dv2/BRMIH0n5jodWhtDeY0BlFKNz2M=; b=k8uCeAePszslS1z7Yxbn07eE1uPp88ljaw3wt1/MflZS0ap6o9iUjGqInq3aErgd5H laOpuQSL40viFpGQEAtMaGRBG8xmoXqHOPMQee8gZ6o6i1MMYhp4FchliT/SVacOOT2Z mnfjzRAiCEluc36nEFQgAXDtoe6X0Jb3h3qNgeu3QLnzkCVXM46UHTsUtgwABK6ydpes vJXx2RbZLFeifzIGO1U1nU1hIOHB/ViTREcMI22Y8EL1xWpbYjap64fe/fe9xnXitNGN vdhZenEAS8Xi/QYxyaifCPlu13PX2BKU/m70xWqJC4obXcbfm7jSCRALiTzOSrXT38ob jReg==
X-Gm-Message-State: ALoCoQmm+qFh5xNPo5pGnB0eBvUg8J+KtcXRwV8lq9LyhJNYPDXb5Q+gOGhsfpP4TB/30M+0UEPp
MIME-Version: 1.0
X-Received: by 10.112.181.71 with SMTP id du7mr8987855lbc.37.1445025350964; Fri, 16 Oct 2015 12:55:50 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Fri, 16 Oct 2015 12:55:50 -0700 (PDT)
In-Reply-To: <20151016.214935.865701461081083525.mbj@tail-f.com>
References: <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com>  <20151016.214935.865701461081083525.mbj@tail-f.com>
Date: Fri, 16 Oct 2015 12:55:50 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c3715cbc793705223e2e15
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 19:55:55 -0000

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

On Fri, Oct 16, 2015 at 12:49 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > Hi,
> >
> > I find all this fretting over when-stmt corner-cases to be a waste of
> time.
> > I certainly have no intention of spending 100s of hours coding for
> > corner-cases
> > that have no operational value whatsoever.  When-stmt has always been
> full
> > of problems that exist on paper but not in real servers.
> >
> > There is no need for the YANG spec to point out that the constraints
> > only apply to YANG. That is self-evident.
> >
> > Why doesn't when-stmt apply to a plain rpc?
> >
> >
> >    rpc plot-point {
> >      input {
> >         leaf 3d {
> >           type boolean;
> >            default false;
> >         }
> >         leaf X { type uint32; }
> >         leaf Y { type uint32; }
> >         leaf Z {
> >           when "../3d";
> >           type uint32;
> >        }
> >      }
> >    }
> >
> >
> > Are you saying that the when-stmt for Z is not allowed?
>
> No.
>
> > Or that it gets ignored and not enforced?
>
> No.
>
> > IMO this section was rather clear -- it applies to when-stmt
> > in the RPC input.
>
> No - and that's the problem which we need to fix.  It might be that we
> all agree on the expected server behavior ,and if that's the case, we
> just need to fix the text to align with what we meant.  In order to
> resolve this, it would be very helpful if you could provide your
> opinion on the questions in the three scenarios below:
>
> > > Suppose we have:
> > >
> > >  leaf a {
> > >    when "../b = 42";
> > >    type int32;
> > >  }
> > >  leaf b {
> > >    type int32;
> > >  }
> > >
> > >
> > > Scenario A
> > > ----------
> > > The DB contains b=10
> > >
> > > The server gets an edit-config with:
> > >
> > >    2
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok; the request to set a to 2 is silently dropped
> > >
>


We implement (2)



> > >
> > > Scenario B
> > > ----------
> > > The DB contains b=10.
> > >
> > > The server gets an edit-config with:
> > >
> > >    2
> > >    42
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok, db now has b=42; the request to set a to 2 is silently
> > >      dropped
> > >  3)  ok, db now has a=2 and b=42
> > >
>


We implement (3)



> > >
> > > Scenario C  (same as 2, but different order in edit-config)
> > > ----------
> > > The DB contains b=10.
> > >
> > > The server gets an edit-config with:
> > >
> > >    42
> > >    2
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok, db now has b=42; the request to set a to 2 is silently
> > >      dropped
> > >  3)  ok, db now has a=2 and b=42
>
>
>
We implement (3)

Order of edits never matters.
We apply all the edits in a non-destructive manner and then
run all the when-stmt tests that are needed.

The order of when-stmt evaluation can change the answer but we
have not seen any YANG modules where that really happens.




> /martin
>


Andy

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




On Fri, Oct 16, 2015 at 12:49 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> Hi,

>

> I find all this fretting over when-stmt corner-cases to be a waste of =
time.

> I certainly have no intention of spending 100s of hours coding for

> corner-cases

> that have no operational value whatsoever.=C2=A0 When-stmt has always =
been full

> of problems that exist on paper but not in real servers.

>

> There is no need for the YANG spec to point out that the constraints
> only apply to YANG. That is self-evident.

>

> Why doesn't when-stmt apply to a plain rpc?

>

>

>=C2=A0 =C2=A0 rpc plot-point {

>=C2=A0 =C2=A0 =C2=A0 input {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf 3d {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default false;

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

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type uint32; }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf Y { type uint32; }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf Z {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when "../3d";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;

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

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

>=C2=A0 =C2=A0 }

>

>

> Are you saying that the when-stmt for Z is not allowed?



No.



> Or that it gets ignored and not enforced?



No.



> IMO this section was rather clear -- it applies to when-stmt

> in the RPC input.



No - and that's the problem which we need to fix.=C2=A0 It might be tha=
t we

all agree on the expected server behavior ,and if that's the case, we
just need to fix the text to align with what we meant.=C2=A0 In order to
resolve this, it would be very helpful if you could provide your

opinion on the questions in the three scenarios below:



> > Suppose we have:

> >

> >=C2=A0 leaf a {

> >=C2=A0 =C2=A0 when "../b =3D 42";

> >=C2=A0 =C2=A0 type int32;

> >=C2=A0 }

> >=C2=A0 leaf b {

> >=C2=A0 =C2=A0 type int32;

> >=C2=A0 }

> >

> >

> > Scenario A

> > ----------

> > The DB contains b=3D10

> >

> > The server gets an edit-config with:

> >

> >=C2=A0 =C2=A0 <a>2</a>

> >

> > What is the result?

> >

> >=C2=A0 1)=C2=A0 an error is returned

> >=C2=A0 2)=C2=A0 ok; the request to set a to 2 is silently dropped<=
br>
> >


We implement (=
2)

=C2=A0

> >

> > Scenario B

> > ----------

> > The DB contains b=3D10.

> >

> > The server gets an edit-config with:

> >

> >=C2=A0 =C2=A0 <a>2</a>

> >=C2=A0 =C2=A0 <b>42</b>

> >

> > What is the result?

> >

> >=C2=A0 1)=C2=A0 an error is returned

> >=C2=A0 2)=C2=A0 ok, db now has b=3D42; the request to set a to 2 i=
s silently

> >=C2=A0 =C2=A0 =C2=A0 dropped

> >=C2=A0 3)=C2=A0 ok, db now has a=3D2 and b=3D42

> >


We implement (=
3)

=C2=A0

> >

> > Scenario C=C2=A0 (same as 2, but different order in edit-config)<=
br>
> > ----------

> > The DB contains b=3D10.

> >

> > The server gets an edit-config with:

> >

> >=C2=A0 =C2=A0 <b>42</b>

> >=C2=A0 =C2=A0 <a>2</a>

> >

> > What is the result?

> >

> >=C2=A0 1)=C2=A0 an error is returned

> >=C2=A0 2)=C2=A0 ok, db now has b=3D42; the request to set a to 2 i=
s silently

> >=C2=A0 =C2=A0 =C2=A0 dropped

> >=C2=A0 3)=C2=A0 ok, db now has a=3D2 and b=3D42





We implement (3)

Order of edits never matters.
We apply all the =
edits in a non-destructive manner and then
run all the when-stmt =
tests that are needed.

The order of when-stmt eval=
uation can change the answer but we
have not seen any YANG module=
s where that really happens.


=C2=A0=


/martin




<=
/div>
Andy



--001a11c3715cbc793705223e2e15--


From nobody Fri Oct 16 12:56:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1881B339A for ; Fri, 16 Oct 2015 12:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf0qUQofRL0L for ; Fri, 16 Oct 2015 12:56:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 135751B339C for ; Fri, 16 Oct 2015 12:56:52 -0700 (PDT)
Received: from localhost (h-46-59-33-90.na.cust.bahnhof.se [46.59.33.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 52BD71AE0478; Fri, 16 Oct 2015 21:56:51 +0200 (CEST)
Date: Fri, 16 Oct 2015 21:56:51 +0200 (CEST)
Message-Id: <20151016.215651.738952339662172367.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <5621294A.6040107@cisco.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 19:56:53 -0000

Kent Watsen  wrote:
> 
> 
> >>Wait, I think we're talking about different things.  Martin, I'm sure
> >>that
> >> internal to a NC/RC server, parts of the intended configuration is
> >> actually applied synchronously (e.g., a hostname) whereas other parts
> >>are
> >> not (e.g., config for data plane).   But that nuance is not currently
> >> exposed in any way today -right?
> >I think that today, from what a client sees/experiences, many replies
> >from netconf servers fits neither the definition of "synchronous
> >configuration operation" nor "asynchronous configuration operation", but
> >instead, the reply is somewhere between the two extremes.
> 
> I don't think it matters if the server is anywhere between the two
> extremes.

Will there ever be a server that operates in synchronous mode, given
that applied will not match intended if hardware is missing?

Will a client ever use "block" mode if it means that it might hang
forever (or at least until some hw is plugged in)?


/martin


From nobody Fri Oct 16 13:16:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA91A0022; Fri, 16 Oct 2015 13:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG3oKLuysaqV; Fri, 16 Oct 2015 13:16:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97D1A0013; Fri, 16 Oct 2015 13:16:15 -0700 (PDT)
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.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151016201615.2448.36796.idtracker@ietfa.amsl.com>
Date: Fri, 16 Oct 2015 13:16:15 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 20:16:16 -0000

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

        Title           : SYSLOG YANG model
        Author          : Clyde Wildes
	Filename        : draft-ietf-netmod-syslog-model-05.txt
	Pages           : 21
	Date            : 2015-10-16

Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messages.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 16 14:17:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90A1A0A6A for ; Fri, 16 Oct 2015 14:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEcHCt4IOwOW for ; Fri, 16 Oct 2015 14:17:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC2231A0235 for ; Fri, 16 Oct 2015 14:17:50 -0700 (PDT)
Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 852621AE0478; Fri, 16 Oct 2015 23:17:49 +0200 (CEST)
Date: Fri, 16 Oct 2015 23:17:48 +0200 (CEST)
Message-Id: <20151016.231748.458285484749412679.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <8AD6FA86-4B34-46E0-B5A9-BA10E9DB41D0@nic.cz>
References: <20151007132536.23489.13312.idtracker@ietfa.amsl.com> <8AD6FA86-4B34-46E0-B5A9-BA10E9DB41D0@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:17:52 -0000

Hi,

Ladislav Lhotka  wrote:
> Hi,
> 
> since the WGLC is over, I posted a new revision of this
> document. Compared to -05, there are no technical changes, just minor
> text modifications and one or two new examples, mainly based on
> Martin's review.

This version addresses all of my concerns.  I think it is ready for
publication.


/martin


From nobody Fri Oct 16 14:19:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC81B33FE for ; Fri, 16 Oct 2015 14:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEGs2EZTKGGW for ; Fri, 16 Oct 2015 14:19:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 564B91A1A9B for ; Fri, 16 Oct 2015 14:19:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.39]) by mail.tail-f.com (Postfix) with ESMTPSA id 70E261AE0478; Fri, 16 Oct 2015 23:19:11 +0200 (CEST)
Date: Fri, 16 Oct 2015 23:19:09 +0200 (CEST)
Message-Id: <20151016.231909.450646783824192644.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20151013080254.GA65823@elstar.local>  
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:19:13 -0000

Ladislav Lhotka  wrote:
> Ladislav Lhotka  writes:
> =

> > Juergen Schoenwaelder  writes=
:
> >
> >> Hi,
> >>
> >> here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07=
; I
> >> have finish now a complete review of the document. The most import=
ant
> >> bug I spotted is likely that section 9.4.6 is empty.
> >
> > Yes, and the "modifier" statement should also be listed in Table 1 =
of
> > sec.=A013.1.
> =

> I just noticed this table contains a copy-and-paste error:
> =

>             +------------------+---------------+-------------+
>             | keyword          | argument name | yin-element |
>             +------------------+---------------+-------------+
>             | action           | name          | false       |
>             | anydata          | 7.10          | 0..n        |
>                                  ^^^^            ^^^^

fixed!


/martin


From nobody Fri Oct 16 14:32:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7941B340E for ; Fri, 16 Oct 2015 14:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALJlkZ1xqonC for ; Fri, 16 Oct 2015 14:32:44 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F341B3412 for ; Fri, 16 Oct 2015 14:32:03 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 21:32:01 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 21:32:01 +0000
From: Kent Watsen 
To: Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgD//8ZaAIAAb4+A///XgwA=
Date: Fri, 16 Oct 2015 21:32:01 +0000
Message-ID: 
References:  <5621294A.6040107@cisco.com>  <20151016.215651.738952339662172367.mbj@tail-f.com>
In-Reply-To: <20151016.215651.738952339662172367.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:Rg/Tft7nkfIEojHJHCyoQXkGk/HVsrTn+4dSGe6PyhvIAVP/3R+bBM6IQwmqef7Yin2sFosmSwzyImOnXejsKZpx8S5U0Ms562ew2TM3km6byYR6TlPuHHUldD+7AMrL0fKAQjJyOqtNrRfiQ1PLjA==; 24:8xtMXZKRagntuDC5aqjFNviUkipVy+zYUXTKxSUbL10Ne8GuDd3D2gYz7tnO04dNbbQeskcKTEwTAWik5FlQJcvmhMJyJSjNRoR7WH2RbTI=; 20:jVyEW7g/Z6u9is8lpdMZh4q+MXcpDj4dqlBc+5UizzbFjKmaJd4aebcvZFwEl8EdMqLWsuDu2QWuCTk4dnf/2w==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(81156007)(106116001)(64706001)(46102003)(106356001)(4001350100001)(40100003)(122556002)(2900100001)(5002640100001)(110136002)(92566002)(93886004)(11100500001)(99286002)(5004730100002)(5007970100001)(5008740100001)(102836002)(2950100001)(105586002)(50986999)(10400500002)(86362001)(76176999)(189998001)(101416001)(97736004)(36756003)(83506001)(5001960100002)(66066001)(54356999)(87936001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <67D6B70881F7FE4587EC9182EC1C96C8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 21:32:01.6526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:32:45 -0000

>Will there ever be a server that operates in synchronous mode, given
>that applied will not match intended if hardware is missing?
>
>Will a client ever use "block" mode if it means that it might hang
>forever (or at least until some hw is plugged in)?

I think the key is in the phrase "The server MUST fully *attempt* to
apply..."

In my view, the server does not have to "fully apply", it merely has to
have attempted to do so.  Essentially, a request comes in resulting in a
flurry of activity, that ultimately stabilizes, at which point the
response can be sent.

If a line card is missing, then (as I understand it), the server would not
wait for the line-card to show up.  That said, if the client requested
transactional/atomic update, a missing line-card would cause an immediate
failure/rollback.

Makes sense?

Kent  // as a contributor


From nobody Fri Oct 16 14:48:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19DB1A07BD for ; Fri, 16 Oct 2015 14:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjlvMWMHvlCV for ; Fri, 16 Oct 2015 14:48:10 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D5E1A044D for ; Fri, 16 Oct 2015 14:48:10 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 21:48:08 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 21:48:08 +0000
From: Kent Watsen 
To: Martin Bjorklund , "lhotka@nic.cz" 
Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-06.txt
Thread-Index: AQHRCFgiy8Wjja82dUOjWsGs+el+MZ5uZO0A
Date: Fri, 16 Oct 2015 21:48:08 +0000
Message-ID: 
References: <20151007132536.23489.13312.idtracker@ietfa.amsl.com> <8AD6FA86-4B34-46E0-B5A9-BA10E9DB41D0@nic.cz> <20151016.231748.458285484749412679.mbj@tail-f.com>
In-Reply-To: <20151016.231748.458285484749412679.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:XtaZIZhADCK25d/1VSMmP/hmdnqfXEQk6JIjphEFh34aD1AMlpZBHukgweMkE1+6d5oeI9qduyazssgHAbx0r1gZinCppzSneQRn+eiXEY95LDdVSXxCp+7hVbPX1x2EdVenbkAJQJF28FDDNpxsXg==; 24:lx7wms1baAijn4rygxuR3qyHAmFPFe6EWv1efBezqtXMQmW3+KXUMFdXkWmarTZzjGQFWfTWZ8qyUvkGxhxdS083tveyJFMArr5JGxehWf8=; 20:LHASEhM1JR25ZM7/rB7oeO5Mu0DG7UES1uJwFC+2OsGyjz6Gw0WmXiBl3pjsWGsstbzmAWzjeEbdahOiBpDPnw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(43784003)(189002)(2473001)(377454003)(479174004)(199003)(5002640100001)(76176999)(19580405001)(92566002)(5001770100001)(5007970100001)(5001960100002)(46102003)(5008740100001)(40100003)(54356999)(11100500001)(101416001)(189998001)(64706001)(97736004)(15975445007)(102836002)(106356001)(4001350100001)(122556002)(5004730100002)(86362001)(99286002)(81156007)(19580395003)(66066001)(2501003)(230783001)(50986999)(106116001)(83506001)(2900100001)(87936001)(10400500002)(105586002)(2950100001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <75F614FE3A394C4790F0A17B93BAFC86@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 21:48:08.3648 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:48:12 -0000

[Chair hat on]

This concludes resolving issues raised during the last call on -05.  All
the issues raised during the last call have now been verified to have been
addressed in -06.  This means that -06 will be forwarded to Benoit for AD
review.   Thank you Lada for bringing it to this point.

Shortly I will send out the call for IPR on this draft, the last thing
blocking this draft's advancement to the next stage.

Thanks again,
Kent




On 10/16/15, 5:17 PM, "Martin Bjorklund"  wrote:

>Hi,
>
>Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> since the WGLC is over, I posted a new revision of this
>> document. Compared to -05, there are no technical changes, just minor
>> text modifications and one or two new examples, mainly based on
>> Martin's review.
>
>This version addresses all of my concerns.  I think it is ready for
>publication.
>
>
>/martin
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Oct 16 14:49:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1D1A1A96 for ; Fri, 16 Oct 2015 14:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kuHoZSk9CUI for ; Fri, 16 Oct 2015 14:49:02 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255191A044D for ; Fri, 16 Oct 2015 14:49:01 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 21:48:59 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 21:48:59 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: IPR Poll for draft-ietf-netmod-yang-json-06
Thread-Index: AQHRBPPrcpKMe4m61UCeTU0UQ+17Yw==
Date: Fri, 16 Oct 2015 21:48:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:pcATd/xKcWa8uWpgE9CTyVAY8OmcDf/1gA5IYYFdvpElRDxdpLj58NR4TF2DqzDsMGDZ1xCjodv4f/oVmEKELOXUYOx0m09gsfg/Yp7nHoc3Lb4gB6S/mPV0a2vYvZLfzv878aRXafPCSkM7bXeKOQ==; 24:1KRpwL3v/VnNZgrIroddr2qCMf1LQlJGv/sV5/n2/SzlYy1UhHSp/i+464xL30unx32H8ECzwPp/p1KIJRvtAIHSarM/5k0FJQeGjtyqdSo=; 20:XK/frbxPT98vjS9pdlsq3ua0IY2/dExb2qIr/usCX/UFaYKO5eJTfgXRp8RGmPtxFN6fzdrBtFvMltkOVZvLqw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(5002640100001)(92566002)(110136002)(16236675004)(5007970100001)(5001960100002)(450100001)(229853001)(46102003)(5008740100001)(40100003)(54356999)(11100500001)(101416001)(189998001)(64706001)(97736004)(102836002)(106356001)(4001350100001)(122556002)(5004730100002)(86362001)(99286002)(81156007)(2351001)(107886002)(66066001)(2501003)(230783001)(50986999)(106116001)(83506001)(2900100001)(87936001)(10400500002)(105586002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24130FCE69FDkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 21:48:59.6404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [netmod] IPR Poll for draft-ietf-netmod-yang-json-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:49:03 -0000

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

This mail starts the IPR poll on draft-ietf-netmod-yang-json-06.

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

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

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

Thank you,

Kent and Tom, NETMOD WG Chairs


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










This mail starts the IPR poll on dra=
ft-ietf-netmod-yang-json-06.








Are you aware of any IPR that=
 applies to draft-ietf-netmod-yang=
-json-06?



If so, has this IPR been disclosed in com=
pliance with IETF IPR rules (see RFCs



3979, 4879, 3669 and 5378 for more detail=
s)?









If you are listed as a document author or=
 contributor please respond to this



email explicitly regardless of whether or=
 not you are aware of any relevant IPR.



The response needs to be sent to the NETM=
OD WG mailing list.  The document



will not advance to the next stage until =
a response has been received from each



author and contributor.









If you are on the NETMOD WG email list bu=
t are not listed as an author or



contributor, then please explicitly respo=
nd only if you are aware of any IPR that



has not yet been disclosed in conformance=
 with IETF rules.









Thank you,









Kent and Tom, NETMOD WG Chairs











--_000_D24130FCE69FDkwatsenjunipernet_--


From nobody Fri Oct 16 14:51:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC51A1BD9 for ; Fri, 16 Oct 2015 14:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.197
X-Spam-Level: *
X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CArCh8BO6K9E for ; Fri, 16 Oct 2015 14:51:42 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F541A1BD4 for ; Fri, 16 Oct 2015 14:51:42 -0700 (PDT)
Received: from BL2PR05CA0044.namprd05.prod.outlook.com (10.255.226.44) by BY1PR0501MB1384.namprd05.prod.outlook.com (10.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 21:51:22 +0000
Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::116) by BL2PR05CA0044.outlook.office365.com (2a01:111:e400:c04::44) with Microsoft SMTP Server (TLS) id 15.1.300.14 via Frontend Transport; Fri, 16 Oct 2015 21:51:22 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 16 Oct 2015 21:51:21 +0000
Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 16 Oct 2015 14:51:20 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9GLpID97150;	Fri, 16 Oct 2015 14:51:18 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t9GLnJPN061794; Fri, 16 Oct 2015 17:49:20 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201510162149.t9GLnJPN061794@idle.juniper.net>
To: Kent Watsen 
In-Reply-To: 
Date: Fri, 16 Oct 2015 17:49:19 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD050; 1:ZmZuWgfspbWuJl0MUe65tdUKD2DQ0SZQZcpb01BpUIQNVFEhBqc/2RZSO4uJ62dOcVVwkA9Tp5Wudxcu38DjtlBKdw5H/Ua1PPh0cdPdFNFusi8BffP9BIjCdyvZB5z7jcBAAYvClAVSjNkyXgCJeWDIldB1ILhE9uuk55qJkAdQT+eZEvnTeWPyNq4N7Bb3H9t9J2PleZZnEjCGgJL/NAhVseS293BPRcue3kxb+Yy6JGJkjFla0c3D9wnkREign6uqKTmNlbp6QV7KEUikVOQ88zbZU3ZRJ8vihUuhLaNqiKAw2fGBou4sqkdFLamnG2iGCcV43jleFUF99OLc2zvcLjHmmwnJV8EfILWAmTaptqTqn4pSOFBe5bs3x/SS
X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(164054003)(105596002)(5003600100002)(81156007)(87936001)(189998001)(48376002)(97736004)(5001960100002)(5003940100001)(110136002)(64706001)(69596002)(4001450100002)(50466002)(46102003)(92566002)(76506005)(53416004)(54356999)(6806005)(1941001)(77096005)(106466001)(2950100001)(50986999)(47776003)(86362001)(5007970100001)(5008740100001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 2:MlREFWTCXbyv2ruCiJtTc0TbyeS5VfK35yijRxz2D39I1G01BDSBRyEBfNmdM1IYcB8NN7PerhgZNCtKhl+uGIW3HKcFW1SQMMI94MOGM7MyEhjFDo0YPW0MQApFwBroz1ykk6RtfBhdQ6jg6unsxm/4kJq54ilFLrwY3455KEg=; 3:KeOCjnFhGHrChA/RiORt7icql/2CTmqafgyxIShmhw2dFR2/M5dPKJkXUOieyz7KNVcVT3Rvf8krAX//PCIR+RXZnDk5LnOI8vGqVnKCS+27qEuJUPCPl+Qvl2E7IQZ1g6sIQZxwaDAaXADU8ey8GUMLmjWP5/fm9GfjZEMzdtUizZh2H3VnbBk6bfqEc36dmpAgG2LjoQSUKQyxAOE44ASEHNLx0a7ckH/yzcsjdWI=; 25:OxK7f4rPLP/cwiy5PNXGEPGD9LT91RtSnzAHqBphOfhfSo6EP+SgV5uvHlA+BVZDaT2PZhH8hmNrgOazEZj+xrBvJ2rR1aoMp+z+/lxok4cgan3wAj4FNoxeKe3HH0zu1jQM4IBjh0y4hVX32f8Xw2eA3uU0gnmv/O9Z66KhYddsiHuu1DL4pRh0VSG4d8ROBi7iICqtjYYJYWmsA+TOtJW+0exkVWICbHPRwIZaSIM/XC1+Tq3Ce6rNRULJ1wUZ
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 20:HldGXnQZu/wlnWXEH3dmJtAiqbJASQjtL3hW9HyQ+15s94ryg9+c7hEydTZfoGpmrhnAd0CcAPNE65tMw1GUVIuz5CY4b4o+3m9HZzenQax3Qkd4QjiHe8e94w/eFUTPDtRz8HSn9KQphJ5ILcbqSZrt8OvoFlTrBdOSSooiZZTFp1zWP2ppvVyIktgA7Ze+UYBtDS2KO2ZzmQ8t64ebNokNwRIThhWSzq6w8Wi6bBOYi6gwcf4RMxXP3vT06RIuPahDJWYrnFzagAvUb0zOjYWmP/SL/WV+LCQeTO0zaPys0P55zI0/G0HyBSQlcDvu+qC4RGwS9kcbFlZ2M1hHoAI6ccvdzUFXSA740A7fk+eAbSzGbz1f1fpWZ4NDQyrLtY591cbFSpq6wKOvjOdU9wQNGIZwgVltziC1hm7Rt98px1ms+Kqg6NZBsTbD5Bp3wTA+7oGbKOHZlH4IfA/fJi9EbmJxtLpNxFwKgSEtDhVhsz3OnmKgV+6gwRHJAXH7; 4:M2fHskkNtjQ70ET3HQ3XaTLRmra0XK/07ZBDhEqQoUNT28sg4AWNAma4CoicxWgXBGk8TMbaexNg4pEGcxYR5ZZGtI44L0hY+7rWmnwaEpQ8fCNnvnSVpeaJQTvliKhT+cGGjXDT4lc/1dwP7vOBIw3DAJj4+dco2g7QakjMZjMiM1PcJr+/LjE4jBy76yvs7/d9XWnNiA39cACkCKscXRHjqnO4Rfz2/8IsCeaHOQuedQcD73+zya56nu/Eb1IG5MTZn6NiTYRKyMWt3242zs0je+OYROcwL1h4EFwsgp57zquNcpF5C1ZuCvAO97wA+EKpJXQkknGs+F9ZtXu9iWZ7f1tHl1Sn5M5jfSQrncg=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BY1PR0501MB1384; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; 
X-Forefront-PRVS: 0731AA2DE6
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1384; 23:K/BGJvN7adBNO+t8UQxcnqcIv1/4diuZrRQfpkA?= =?us-ascii?Q?iowcGWED2ANs0esxm/DpJ8fUkZ5IzTDBAqwzv1MuTFc4ZKX7kXCecam7hGOb?= =?us-ascii?Q?Hx1uWZxNE0E4gErK6SCFqqa78o7my0UqTjHxqkoqusUYG45/AKw+Qtmu0qkY?= =?us-ascii?Q?ED1EOJQrdr9LCRhpRBBaTGptzle3pg5DjfgRhGCASpxX/yLl3lYSdL5nKksw?= =?us-ascii?Q?le6s49X5hHIVsNntkkdgKfzwnrGfgEt1DCFFf8l+s1pRC1Cp/ABvjBowYwuY?= =?us-ascii?Q?7Z7kU6JwFTWgM48xBuxOXmHYuF5vawM0RrtqMBaKQwLL+5wgszfjuBw1McO4?= =?us-ascii?Q?w76jMrrwsQFciZn4TbuZ2jpOPOepDxEDVPW8btBFoAeDrESYqeRDy+NmWXP/?= =?us-ascii?Q?2XFjf7eCLUe8SdCsnOqKOK9UyE4hjF+JWJQ3RiGCnOBuE6be5eN8jFG8Y9Gn?= =?us-ascii?Q?aW3B5t7AcaDzWIw/d7LpHLMbNGRl7NA90f+AwadmjkjMW+O0YArprXnAFrmE?= =?us-ascii?Q?XP+8C/12oYKb/Aq9YF42WS8JMQa+Q+IU7EbH+Usi1wju01cgcZxZqEVAyXoC?= =?us-ascii?Q?d0hs7Icf9JXJioKr3VaOfCuRcZyvN6QS5FEZ5oNl5GdRAeZ1MXa7geAbRErR?= =?us-ascii?Q?TgmP87fs2f3Qx2TgHA2nQM258tny3Vd5DnxtlqWZKPm70vWoh0HyqmdEDhxK?= =?us-ascii?Q?iB77mbkLThvfqTkhEJV8JabcVaGYmXweLUgoKjEGl+swsXsSHLbDqhCfokUg?= =?us-ascii?Q?AQu7VW5yrL+W6u4pWervz8oi+tIUfEY4Q4y65h5+oq1yD2JTkt9EMBZCLr2n?= =?us-ascii?Q?wddj4GpU0/md8gaKqBJsD1PCjT+TjWBQXnYjFbWXMZCvkkzhEZYBGzjLxdc5?= =?us-ascii?Q?703fTNeBG6zDsBRYBX7Sm2P/yOeLE6fz8pH5d6Hd2veTMU1WBt+rG04jhZlN?= =?us-ascii?Q?FQ8FjbifQxoq4pVEFoLRDemXEZgdYjyc1FLb2nsTqUwfAUVX634atPWRIGJS?= =?us-ascii?Q?2/0E=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 5:4YWbTZT3KWHDEZmfn2zJUpATMVXy2KIEf6qkvrUNj2c1tCJtXF8lsBQpznrB4coHLm9sQUbxYfqSuymhD+NdnEeil7gUCRteWsIh65iK8O3fNpJz2iQzQZbJRZ+rprZ+zJTtAbV1sKYnTrUMA+WwUw==; 24:GEnX8L2d2wdIW7JYgSVAzevhyuVO+DrXC4y4mA2O7o+yeiz4Q0dAgoJ16Fwl4eK7hSZVPFfS6qyHza68n4L5JbPz/5zsxEpjfFa9ozcr/NI=; 20:r/c+p4H8UfKgLgn9MKCkU5rM+agoLlGRoMJBMO0dUC869/ZBbfckTZxWhqB9KBnRwn1q7KywXaYfhKFJXJuk5Q==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2015 21:51:21.3976 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01b-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 21:51:43 -0000

Kent Watsen writes:
>If a line card is missing, then (as I understand it), the server would not
>wait for the line-card to show up.  That said, if the client requested
>transactional/atomic update, a missing line-card would cause an immediate
>failure/rollback.

We have to avoid the scenario when a box boots with a missing FRU.
In past model has always been that missing hardware does not cause
a configuration to fail validity checks.  This is enforced by the
inability of config=true constraints from referring to config=false
nodes.

Thanks,
 Phil


From nobody Fri Oct 16 15:50:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F51B34C4 for ; Fri, 16 Oct 2015 15:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOG0YNqcTJ2j for ; Fri, 16 Oct 2015 15:50:08 -0700 (PDT)
Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D963F1B34B6 for ; Fri, 16 Oct 2015 15:50:08 -0700 (PDT)
Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa08-09.prod.phx3.secureserver.net with  id Vyq71r0030FehNH01yq7PC; Fri, 16 Oct 2015 15:50:08 -0700
To: netmod@ietf.org
References: <5620D3B1.6040805@ericsson.com> <20151016.140143.1643639652175921028.mbj@tail-f.com>  <20151016.214935.865701461081083525.mbj@tail-f.com>
From: Xiang Li 
Message-ID: <56217F14.8090304@seguesoft.com>
Date: Fri, 16 Oct 2015 17:49:56 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151016.214935.865701461081083525.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 22:50:10 -0000

On 10/16/2015 2:49 PM, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> Hi,
>>
>> I find all this fretting over when-stmt corner-cases to be a waste of time.
>> I certainly have no intention of spending 100s of hours coding for
>> corner-cases
>> that have no operational value whatsoever.  When-stmt has always been full
>> of problems that exist on paper but not in real servers.
>>
>> There is no need for the YANG spec to point out that the constraints
>> only apply to YANG. That is self-evident.
>>
>> Why doesn't when-stmt apply to a plain rpc?
>>
>>
>>     rpc plot-point {
>>       input {
>>          leaf 3d {
>>            type boolean;
>>             default false;
>>          }
>>          leaf X { type uint32; }
>>          leaf Y { type uint32; }
>>          leaf Z {
>>            when "../3d";
>>            type uint32;
>>         }
>>       }
>>     }
>>
>>
>> Are you saying that the when-stmt for Z is not allowed?
> No.
>
>> Or that it gets ignored and not enforced?
> No.
>
>> IMO this section was rather clear -- it applies to when-stmt
>> in the RPC input.
> No - and that's the problem which we need to fix.  It might be that we
> all agree on the expected server behavior ,and if that's the case, we
> just need to fix the text to align with what we meant.  In order to
> resolve this, it would be very helpful if you could provide your
> opinion on the questions in the three scenarios below:
>
>>> Suppose we have:
>>>
>>>   leaf a {
>>>     when "../b = 42";
>>>     type int32;
>>>   }
>>>   leaf b {
>>>     type int32;
>>>   }
>>>
>>>
>>> Scenario A
>>> ----------
>>> The DB contains b=10
>>>
>>> The server gets an edit-config with:
>>>
>>>     2
>>>
>>> What is the result?
>>>
>>>   1)  an error is returned
>>>   2)  ok; the request to set a to 2 is silently dropped

I would expect 1).


>>>
>>> Scenario B
>>> ----------
>>> The DB contains b=10.
>>>
>>> The server gets an edit-config with:
>>>
>>>     2
>>>     42
>>>
>>> What is the result?
>>>
>>>   1)  an error is returned
>>>   2)  ok, db now has b=42; the request to set a to 2 is silently
>>>       dropped
>>>   3)  ok, db now has a=2 and b=42

I would expect 3)
>>>
>>> Scenario C  (same as 2, but different order in edit-config)
>>> ----------
>>> The DB contains b=10.
>>>
>>> The server gets an edit-config with:
>>>
>>>     42
>>>     2
>>>
>>> What is the result?
>>>
>>>   1)  an error is returned
>>>   2)  ok, db now has b=42; the request to set a to 2 is silently
>>>       dropped
>>>   3)  ok, db now has a=2 and b=42
I would expect 3)


In SNMP, when a set operation contains multiple variable bindings, the 
rule is:

"Each variable assignment specified by the SetRequest-PDU should be 
effected as if
simultaneously set with respect to all other assignments specified in
the same message."

I would expect the same rule applies for edit-config. That is , the 
order is not
significant.

-Xiang Li


From nobody Fri Oct 16 16:13:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64D31A7D81 for ; Fri, 16 Oct 2015 16:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0Yi4VDXeXIo for ; Fri, 16 Oct 2015 16:13:48 -0700 (PDT)
Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997731A702A for ; Fri, 16 Oct 2015 16:13:48 -0700 (PDT)
Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa06-09.prod.phx3.secureserver.net with  id VzDn1r0090FehNH01zDox2; Fri, 16 Oct 2015 16:13:48 -0700
References: <5621845D.6040100@seguesoft.com>
To: netmod@ietf.org
From: Xiang Li 
X-Forwarded-Message-Id: <5621845D.6040100@seguesoft.com>
Message-ID: <562184A1.6000802@seguesoft.com>
Date: Fri, 16 Oct 2015 18:13:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5621845D.6040100@seguesoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Fwd: Re:  Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Oct 2015 23:13:49 -0000

On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
>> On 16 Oct 2015, at 12:27, Balazs Lengyel  wrote:
>>
>> IMHO YANG should define the behavoir, and I would want it to be the same on Netconf/Restconf/CLI etc.
>> I agree that " 1) you get an error back" would be the best: because it is the easiest to understand for the operator, with the fewest corner cases.
>> Also we must define if in the same transaction we set b=42 and a=2. which of the 3 options are taken?
>>
>>
>> We should not leave such complex cases undefined, or alternatively state that they are implementation dependant.
> I might be difficult to say what is a complex case, unless we abandon XPath in "when" statements and use something else - and considerably simpler.
>
> Here is another interesting corner case - does it qualify as being complex?
>
> leaf-list bar {
>     type uint8;
>     when "count(../*) > 1";
> }
> leaf foo {
>     type uint8;
> }

Interesting example...

> Assuming no instances exist, is this edit allowed? (This was essentially your question.)
>
> 1
> 2

I think this should succeed

>
> But what about this?
>
> 1
> 2
>
I think this should succeed too because the when is satisfied in the
data store after the edit-config.



-Xiang Li




From nobody Fri Oct 16 20:29:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBDE1B2A16 for ; Fri, 16 Oct 2015 20:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LxOmDxQhx7lw for ; Fri, 16 Oct 2015 20:29:22 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6681B29FC for ; Fri, 16 Oct 2015 20:29:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nbK6aeq9TCXRgvGJG8R0hXvijJel4Ua5jyjxUVB8h/guS5y5DhJ3KdMH+WbFH9U1; 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.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZnIBD-0001N9-Ht for netmod@ietf.org; Fri, 16 Oct 2015 23:29:11 -0400
Received: from 76.254.48.111 by webmail.earthlink.net with HTTP; Fri, 16 Oct 2015 23:29:11 -0400
Message-ID: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Date: Fri, 16 Oct 2015 20:29:11 -0700 (GMT-07:00)
From: Randy Presuhn 
To: "netmod@ietf.org" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edd7d752764edc37f02802d4814926ce22350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.52
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Oct 2015 03:29:23 -0000

Hi -

> From: Robert Wilton
> Sent: Oct 16, 2015 5:12 AM
> To: Kent Watsen , Nadeau Thomas
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
...
>    Here is my attempt at word smithing section 3:
...
>             A. A server may choose to support only synchronous configuration
>                operations, or only asynchronous configuration operations, or
>                both synchronous and asynchronous configuration operations in
>                a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
    a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
    "choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
>          failed.  A configuration protocol, or server, SHOULD provide
>          support for rollback-on-error behavior and MAY choose to
>          provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
    depending on which of the two subjects ("protocol" or "server") one
    chooses to think about.  The server's observable behaviour is presumably
    circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy


From nobody Sat Oct 17 00:53:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFB11A8AB6 for ; Sat, 17 Oct 2015 00:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpvzId3Vn0AJ for ; Sat, 17 Oct 2015 00:53:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECF41A8AB9 for ; Sat, 17 Oct 2015 00:53:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A53B58FC; Sat, 17 Oct 2015 09:53:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qkvU7CVUcdMu; Sat, 17 Oct 2015 09:53:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 17 Oct 2015 09:53:01 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8276E20053; Sat, 17 Oct 2015 09:53:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d1axq2R75NfP; Sat, 17 Oct 2015 09:53:00 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B6CE2004E; Sat, 17 Oct 2015 09:53:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4077237B67C4; Sat, 17 Oct 2015 09:52:58 +0200 (CEST)
Date: Sat, 17 Oct 2015 09:52:58 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151017075258.GA76091@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <20151015223441.GD72419@elstar.local>  <20151016072543.GA73630@elstar.local> <20151016.111900.807553366696169175.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151016.111900.807553366696169175.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Oct 2015 07:53:06 -0000

On Fri, Oct 16, 2015 at 11:19:00AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote:
> > > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > > 
> > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote:
> > > > >
> > > > > Conformance to YANG for the extension: NONE This includes syntax and
> > > > > semantics.  It makes no sense at all (Lada is right) to say the
> > > > > extension semantics apply.  They only apply if the tool supports the
> > > > > extension.  Conformance to the extension is a different matter.
> > > >
> > > > I would hope that a server supporting NACM implements the behaviour of
> > > > nacm:default-deny-write when nodes are tagged with this extension.
> > > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write
> > > > but if nacm:default-deny-write is used for a certain node, I think we
> > > > want the server to implement the semantics implied by
> > > > nacm:default-deny-write regardless which tool the developer used.
> > > >
> > > >
> > > I do not agree.
> > > The semantics for this YANG extension only apply to NACM.
> > > Of course an implementation of NACM cannot ignore this extension.
> > > 
> > > The extensions says what to do in NACM if the tag is found.
> > > (As it should).  It does not define any behavior outside of NACM.
> > > No other tool except a NETCONF server implementation
> > > of NACM has any conformance requirement to implement this extension.
> > 
> > I am confused, perhaps we talk past each other. If a server implements
> > NACM and some data model X contains
> > 
> > 	leaf foo {
> > 	     type string;
> > 	     nacm:default-deny-write;
> > 	}
> > 
> > does this not mean that the nacm:default-deny-write semantics must be
> > implemented for the foo leaf regardless whether the developer's tool
> > is able to parse nacm:default-deny-write or skips over it?
> 
> Sure.  Andy wrote:
> 
>    Of course an implementation of NACM cannot ignore this extension.
>

Good, so we actually agree. How do we get the wording to say what we
agree on?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sat Oct 17 02:05:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12391A9142 for ; Sat, 17 Oct 2015 02:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FBPuZIKphaJ for ; Sat, 17 Oct 2015 02:05:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDED1A9140 for ; Sat, 17 Oct 2015 02:05:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D466C8E3; Sat, 17 Oct 2015 11:05:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BSxTTRgtxvMJ; Sat, 17 Oct 2015 11:05:16 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 17 Oct 2015 11:05:16 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E8E020053; Sat, 17 Oct 2015 11:05:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6RoesXqEiuZF; Sat, 17 Oct 2015 11:05:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 706482004E; Sat, 17 Oct 2015 11:05:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9DA9137B6B35; Sat, 17 Oct 2015 11:05:12 +0200 (CEST)
Date: Sat, 17 Oct 2015 11:05:12 +0200
From: Juergen Schoenwaelder 
To: David Reid 
Message-ID: <20151017090512.GA76449@elstar.local>
Mail-Followup-To: David Reid , Randy Presuhn , netmod@ietf.org
References: <3515254.1444766132543.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <201510141449.t9EEn2F7078513@mainfs.snmp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201510141449.t9EEn2F7078513@mainfs.snmp.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] 6020bis more than one revision of a module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Oct 2015 09:05:21 -0000

On Wed, Oct 14, 2015 at 10:49:02AM -0400, David Reid wrote:
> > >I'm reviewing 6020bis since it is in working group last call. 
> > >I see a new requirement that a server MUST NOT implement
> > >more than one revision of a module. I understand that supporting
> > >more than one revision can cause problems, but I expect that
> > >it will happen in practice. I know it happens sometimes with
> > >MIBs in SNMP. I think MUST NOT is too strong.
> > 
> > I've encountered the same phenomenon in the SNMP universe,
> > so if I expected Netconf to used as a replacement for SNMP
> > I'd have the same concern.
> > 
> > Randy
> 
> Here is the situation I face. We put a netconf server in our SNMP Master
> agent. Using the MIB to YANG conversion rules from RFC 6643 we can provide
> read-only access (or read-write in a non-standard way) via netconf and yang
> to all of the MIB data. We have existing customers using different revisions
> of the same MIB module in different subagents. If they convert those
> MIB modules to YANG modules and access the information via netconf, it
> would violate the proposed rule.

The RFC 6643 translation generates no mandatory statements in YANG and
the RFC 6643 translation is read-only. So for read-only access, using
the latest MIB module as a basis should work since SMIv2 has strict
backwards compatibility rules, no?

I do not know how you translate MIB modules into config true YANG
nodes but this is where things are tricky. In the SMIv2 world, you can
have many differnet conformance statements for a MIB module that can
slice MIB module implementation requirements in almost arbitrary ways
(and conformance statements may even be in different modules). In
other words, an SNMP agent claims conformance to a conformance
statement not to a MIB module per se. So in order to translate this
properly, you would have to either generate a YANG module with
suitable features for the different conformance statements or you
would have to find other ways to partition that data model to allow
differnet conformance levels.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sat Oct 17 10:42:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE6A1B2B6D for ; Sat, 17 Oct 2015 10:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uN-bSKzdkrU for ; Sat, 17 Oct 2015 10:42:11 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 28E201B2B70 for ; Sat, 17 Oct 2015 10:42:10 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so90299403lbb.0 for ; Sat, 17 Oct 2015 10:42:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RGBD0G+zB3+jJyNOgpwK2Qr8Zv0LK4MD7doiSlSUU7k=; b=gswHVPeRJr3sVhAYTipRJlJfF2oVPRke+ljps1m7Kik6wp909HBT3ZZ/KpBJplfbeO p8mGECctxO4JZ1aq9SVWg2Ew2kp4uwHEG7EQDhgcuXJ4ETNLxr71ghO0gPTJpKjWvTgf QOGFCQ6/gAG/sg5wDjw+6xbfcvNr9zji+z9dl+8I/9jh84zEmzU77H7kWJYfLA37onjF 9QRnL30tNU0xTP2v3SfjJXquN7EfvEWJENcEc792P8oHCSXsO1oxK+ZbC25pDDm4pCto B6LqWDDq2/1FSRzXcwijvgr4dPcptXxuF/Yp2BBkL9ydhVLaq03uj55uU6ssuewXvSnw Be+g==
X-Gm-Message-State: ALoCoQmyCTzHau1Dsx0l/VWTnS9Zwxrbz7tbUiOqlaxC3z2nCl8OPs5JV4fRXye5nPjQV83ve4Fo
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr10887581lbc.123.1445103728404;  Sat, 17 Oct 2015 10:42:08 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Sat, 17 Oct 2015 10:42:08 -0700 (PDT)
In-Reply-To: <20151017075258.GA76091@elstar.local>
References: <20151015223441.GD72419@elstar.local>  <20151016072543.GA73630@elstar.local> <20151016.111900.807553366696169175.mbj@tail-f.com> <20151017075258.GA76091@elstar.local>
Date: Sat, 17 Oct 2015 10:42:08 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Martin Bjorklund ,  Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2665065435a0522506e0e
Archived-At: 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Oct 2015 17:42:13 -0000

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

On Sat, Oct 17, 2015 at 12:52 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Oct 16, 2015 at 11:19:00AM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote:
> > > > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote:
> > > > > >
> > > > > > Conformance to YANG for the extension: NONE This includes syntax
> and
> > > > > > semantics.  It makes no sense at all (Lada is right) to say the
> > > > > > extension semantics apply.  They only apply if the tool supports
> the
> > > > > > extension.  Conformance to the extension is a different matter.
> > > > >
> > > > > I would hope that a server supporting NACM implements the
> behaviour of
> > > > > nacm:default-deny-write when nodes are tagged with this extension.
> > > > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write
> > > > > but if nacm:default-deny-write is used for a certain node, I think
> we
> > > > > want the server to implement the semantics implied by
> > > > > nacm:default-deny-write regardless which tool the developer used.
> > > > >
> > > > >
> > > > I do not agree.
> > > > The semantics for this YANG extension only apply to NACM.
> > > > Of course an implementation of NACM cannot ignore this extension.
> > > >
> > > > The extensions says what to do in NACM if the tag is found.
> > > > (As it should).  It does not define any behavior outside of NACM.
> > > > No other tool except a NETCONF server implementation
> > > > of NACM has any conformance requirement to implement this extension.
> > >
> > > I am confused, perhaps we talk past each other. If a server implements
> > > NACM and some data model X contains
> > >
> > >     leaf foo {
> > >          type string;
> > >          nacm:default-deny-write;
> > >     }
> > >
> > > does this not mean that the nacm:default-deny-write semantics must be
> > > implemented for the foo leaf regardless whether the developer's tool
> > > is able to parse nacm:default-deny-write or skips over it?
> >
> > Sure.  Andy wrote:
> >
> >    Of course an implementation of NACM cannot ignore this extension.
> >
>
> Good, so we actually agree. How do we get the wording to say what we
> agree on?
>


Here is my attempt...


OLD:



   If a YANG parser does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 14),
   the entire unknown-statement MAY be ignored by the parser.  Note that
   even in this case the semantics associated with the extension still
   apply (as if they were part of a description statement).




NEW:

   If a YANG parser does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 14),
   the entire unknown-statement MAY be ignored by the parser. Note that
   this only applies to a generic YANG parser. A tool which is required
   to implement the particular extension MUST NOT ignore such an
   unknown-statement.






>
> /js
>
>

Andy



> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Sat, Oct 17, 2015 at 12:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 16, 2015 at 11:19:00AM +0200, Martin Bjorklund wrote:=


> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> > On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote:

> > > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder <<=
br>
> > > j.sc=
hoenwaelder@jacobs-university.de> wrote:

> > >

> > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman =
wrote:

> > > > >

> > > > > Conformance to YANG for the extension: NONE This i=
ncludes syntax and

> > > > > semantics.=C2=A0 It makes no sense at all (Lada is=
 right) to say the

> > > > > extension semantics apply.=C2=A0 They only apply i=
f the tool supports the

> > > > > extension.=C2=A0 Conformance to the extension is a=
 different matter.

> > > >

> > > > I would hope that a server supporting NACM implements t=
he behaviour of

> > > > nacm:default-deny-write when nodes are tagged with this=
 extension.

> > > > Sure, a YANG parser is allowed to skip over nacm:defaul=
t-deny-write

> > > > but if nacm:default-deny-write is used for a certain no=
de, I think we

> > > > want the server to implement the semantics implied by
> > > > nacm:default-deny-write regardless which tool the devel=
oper used.

> > > >

> > > >

> > > I do not agree.

> > > The semantics for this YANG extension only apply to NACM.
> > > Of course an implementation of NACM cannot ignore this exten=
sion.

> > >

> > > The extensions says what to do in NACM if the tag is found.<=
br>
> > > (As it should).=C2=A0 It does not define any behavior outsid=
e of NACM.

> > > No other tool except a NETCONF server implementation

> > > of NACM has any conformance requirement to implement this ex=
tension.

> >

> > I am confused, perhaps we talk past each other. If a server imple=
ments

> > NACM and some data model X contains

> >

> >=C2=A0 =C2=A0 =C2=A0leaf foo {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nacm:default-deny-write;

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

> >

> > does this not mean that the nacm:default-deny-write semantics mus=
t be

> > implemented for the foo leaf regardless whether the developer'=
;s tool

> > is able to parse nacm:default-deny-write or skips over it?

>

> Sure.=C2=A0 Andy wrote:

>

>=C2=A0 =C2=A0 Of course an implementation of NACM cannot ignore this ex=
tension.

>



Good, so we actually agree. How do we get the wording to say what we

agree on?


Here is my att=
empt...


OLD:


   If a YANG parser does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 14),
   the entire unknown-statement MAY be ignored by the parser.  Note that
   even in this case the semantics associated with the extension still
   apply (as if they were part of a description statement).




NEW:

=

   If a YANG parser does not support a particular extension, whic=
h
   appears in a YANG module as an unknown-statement (see Section 14),
   the entire unknown-statement MAY be ignored by the parser. Note that
   this only applies to a generic YANG parser. A tool which is required
   to implement the particular extension MUST NOT ignore such an
   unknown-statement.



=C2=
=A0



/js




Andy

=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--001a11c2665065435a0522506e0e--


From nobody Sat Oct 17 19:49:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615FD1A87A5 for ; Sat, 17 Oct 2015 19:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSw2TZwFK-BV for ; Sat, 17 Oct 2015 19:49:15 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB01A879E for ; Sat, 17 Oct 2015 19:49:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AuCM4VjM7UxwLYH7eHdbShUNoiSwdfFVKN5H27AnzlG0b/U5H7TCrdBJK1VlBrac; 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.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zne1z-0001V8-6V for netmod@ietf.org; Sat, 17 Oct 2015 22:49:07 -0400
Received: from 76.254.48.143 by webmail.earthlink.net with HTTP; Sat, 17 Oct 2015 22:49:06 -0400
Message-ID: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Sat, 17 Oct 2015 19:49:06 -0700 (GMT-07:00)
From: Randy Presuhn 
To: "netmod@ietf.org" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edaa58dee1a3641730b212bdafe2b982ac350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.34
Archived-At: 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 02:49:16 -0000

Hi -

> From: Andy Bierman
> Sent: Oct 17, 2015 10:42 AM
...
> Subject: Re: [netmod] 6020bis extensions
...

Andy Proposed:

>    If a YANG parser does not support a particular extension, which
>    appears in a YANG module as an unknown-statement (see Section 14),
>    the entire unknown-statement MAY be ignored by the parser. Note that
>    this only applies to a generic YANG parser. A tool which is required
>    to implement the particular extension MUST NOT ignore such an
>    unknown-statement.

I'd suggest a slightly different wording:

  The processing of extensions depends on whether support for those
  extensions is claimed for a given YANG parser or the tool set in
  which it is embedded.  An unsupported extension, appearing in a
  YANG module as an unknown-statement (see Section 14) MAY be
  ignored in its entirety.  Any supported extension MUST be processed
  in accordance with the specification governing that extension.

Randy


From nobody Sun Oct 18 00:25:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91B1B2DD3 for ; Sun, 18 Oct 2015 00:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWsWQdj4FhzI for ; Sun, 18 Oct 2015 00:25:30 -0700 (PDT)
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 DABDC1B2DCF for ; Sun, 18 Oct 2015 00:25:29 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:bc79:f78d:dce4:846b] (unknown [IPv6:2a01:5e0:29:ffff:bc79:f78d:dce4:846b]) by mail.nic.cz (Postfix) with ESMTPSA id 42F2918112B; Sun, 18 Oct 2015 09:25:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445153128; bh=9KJXJDKbzxk41umouItKjiMEkE8C37uW1imcFMU+1NA=; h=From:Date:To; b=Rs4sRId7m7w8b+Os8B2CIb5SHyugYNecBxihpt5iljNnYEoFMYI7K5BmSB0b+1hP5 Yn67PywrmvUvQ0+Ypl18QovQZ9np8WEJ78xTM11nSHJba/PktHrmK0SxSOymptkOt0 8TFJBjNsl7nvCncy3eYyda6NiQYYbMiUcSsC4TXo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sun, 18 Oct 2015 09:25:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Kent Watsen 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-yang-json-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 07:25:32 -0000

I am not aware of any IPR applicable to this draft.

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

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





From nobody Sun Oct 18 01:10:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E3A1B2E1C for ; Sun, 18 Oct 2015 01:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yhVHlLhaL-Q for ; Sun, 18 Oct 2015 01:10:07 -0700 (PDT)
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 AA57B1B2E19 for ; Sun, 18 Oct 2015 01:10:07 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:bc79:f78d:dce4:846b] (unknown [IPv6:2a01:5e0:29:ffff:bc79:f78d:dce4:846b]) by mail.nic.cz (Postfix) with ESMTPSA id D421918161F; Sun, 18 Oct 2015 10:10:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445155805; bh=CCP9l1volJLEVgc2UO9qzLJJr5nl44TdZxLMYgn5+i8=; h=From:Date:To; b=LOn4soSGhI5+//4/SMIs5nlfHZ3KF2ax4+/CsUvabkNUlnnoWm1a5h9u3XN8QlR95 CtzWk1XarZWexw6VkAWgn5nVgQO37Y9BwCHioX9REpgA+DtQ36LqzIgst8ivZkxpPT LHSqo2/wieU506VzXim0QyX3AUPdgKz1RduwM/t8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Sun, 18 Oct 2015 10:10:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <17AC4893-3289-445B-89B1-8E753DB3B28A@nic.cz>
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:10:09 -0000

> On 18 Oct 2015, at 04:49, Randy Presuhn  =
wrote:
>=20
> Hi -
>=20
>> From: Andy Bierman
>> Sent: Oct 17, 2015 10:42 AM
> ...
>> Subject: Re: [netmod] 6020bis extensions
> ...
>=20
> Andy Proposed:
>=20
>>   If a YANG parser does not support a particular extension, which
>>   appears in a YANG module as an unknown-statement (see Section 14),
>>   the entire unknown-statement MAY be ignored by the parser. Note =
that
>>   this only applies to a generic YANG parser. A tool which is =
required
>>   to implement the particular extension MUST NOT ignore such an
>>   unknown-statement.
>=20
> I'd suggest a slightly different wording:
>=20
>  The processing of extensions depends on whether support for those
>  extensions is claimed for a given YANG parser or the tool set in
>  which it is embedded.  An unsupported extension, appearing in a
>  YANG module as an unknown-statement (see Section 14) MAY be
>  ignored in its entirety.  Any supported extension MUST be processed
>  in accordance with the specification governing that extension.

I like this text.

Do we also want to restrict semantics of extensions? If an extension =
changes YANG validity or datastore semantics, then a tool or protocol =
implementation that doesn't support that extension may not be able to =
correctly interpret instance data, or may outright break down.

In order to be able to support annotations in instance data, it is IMO =
necessary to define the concept of annotations directly in the YANG =
spec. A similar approach as for YANG extensions could perhaps be used =
for annotations:

The processing of annotations depends on whether support for those =
annotations is claimed for a given protocol or tool set. An unsupported =
annotation appearing in instance data or protocol messages MAY be =
ignored. Any supported annotation MUST be processed in accordance with =
the specification governing that annotation.

Lada

>=20
> Randy
>=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 Sun Oct 18 01:32:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3D1A893B for ; Sun, 18 Oct 2015 01:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyY3WXjicy-u for ; Sun, 18 Oct 2015 01:32:05 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C1F1A0045 for ; Sun, 18 Oct 2015 01:32:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD47093B; Sun, 18 Oct 2015 10:32:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iUtVo43A1_WO; Sun, 18 Oct 2015 10:32:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 10:32:01 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2B3320053; Sun, 18 Oct 2015 10:32:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E23KJLk8qcCO; Sun, 18 Oct 2015 10:32:00 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12E312004E; Sun, 18 Oct 2015 10:32:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3BE3C37B749E; Sun, 18 Oct 2015 10:31:58 +0200 (CEST)
Date: Sun, 18 Oct 2015 10:31:58 +0200
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20151018083158.GA78184@elstar.local>
Mail-Followup-To: Randy Presuhn , "netmod@ietf.org" 
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:32:07 -0000

On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> Hi -
> 
> > From: Andy Bierman
> > Sent: Oct 17, 2015 10:42 AM
> ...
> > Subject: Re: [netmod] 6020bis extensions
> ...
> 
> Andy Proposed:
> 
> >    If a YANG parser does not support a particular extension, which
> >    appears in a YANG module as an unknown-statement (see Section 14),
> >    the entire unknown-statement MAY be ignored by the parser. Note that
> >    this only applies to a generic YANG parser. A tool which is required
> >    to implement the particular extension MUST NOT ignore such an
> >    unknown-statement.
> 
> I'd suggest a slightly different wording:
> 
>   The processing of extensions depends on whether support for those
>   extensions is claimed for a given YANG parser or the tool set in
>   which it is embedded.  An unsupported extension, appearing in a
>   YANG module as an unknown-statement (see Section 14) MAY be
>   ignored in its entirety.  Any supported extension MUST be processed
>   in accordance with the specification governing that extension.
>

I am not happy with either of these. It is important for me to state
that the semantics associated with an extension statement apply,
irrespective of the tool being used to implement a module. You can't
simply ignore nacm:default-deny-write just because your tool skipped
over this extension statement. So what about this:

   If a tool does not support a particular extension, which appears in
   a YANG module as an unknown-statement (see Section 14), the entire
   unknown-statement MAY be ignored by the tool. Irrespective of this,
   the semantics associated with an extension MUST be implemented
   whenever an extension statement appears in a YANG module.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 01:42:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318ED1B2E3E for ; Sun, 18 Oct 2015 01:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqhWgOxCc1UK for ; Sun, 18 Oct 2015 01:42:14 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A7F1A9061 for ; Sun, 18 Oct 2015 01:42:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12240AC1; Sun, 18 Oct 2015 10:42:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G_9ELXuIuw_Q; Sun, 18 Oct 2015 10:42:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 10:42:12 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4388A20053; Sun, 18 Oct 2015 10:42:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RHl86GFBdz45; Sun, 18 Oct 2015 10:42:11 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D58712004E; Sun, 18 Oct 2015 10:42:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0EBAF37B74F7; Sun, 18 Oct 2015 10:42:09 +0200 (CEST)
Date: Sun, 18 Oct 2015 10:42:09 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151018084209.GB78184@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20151012144431.GA64068@elstar.local> <20151015.223749.1017340653632922486.mbj@tail-f.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:42:16 -0000

On Fri, Oct 16, 2015 at 11:19:34AM +0200, Ladislav Lhotka wrote:
> 
> But then perhaps "device" is a broader term in the sense that the server is just
> a software component running in a device.
> 
> For example, it is the device that is required to operationally use
> default values of parameters that are not present in the
> configuration. Replacing "device" with "server" here IMO means something
> different.
>

I prefer server. At the end it is an implementation matter whether the
server fills in a default used by the device or whether the device
uses a default which happens to be the default that the data model
used by the server defines.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 01:50:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980B51B2E4A for ; Sun, 18 Oct 2015 01:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9glNg1Ihhor3 for ; Sun, 18 Oct 2015 01:50:14 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 E93181B2E49 for ; Sun, 18 Oct 2015 01:50:13 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so95494760lbb.0 for ; Sun, 18 Oct 2015 01:50:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3D1VbK73yW++8yv5xvw2ihBRCxhmQqzRCvdNheq7REs=; b=Jw/OXUo9ghmcCVR5EJGA3pNkAOdfvYsEtKHFpDmpukajrufxqhdN8lKmiGbBFoOMI7 Zeau2JfJu5BhYjeRugp95HwoF6kjHJX3LzWzcPZWVZUyV54Rc3pFmD+eKsCmM6qC53rE tnF/8r7920nPijVmliUwGqrFGiNmiUJsxhBuszvUzOjyMFJTPBHnN+lDBnC8vLriogLD imI/rgFuzu+Rl4AMzVGWIZzKoyMRwb5AAvzksMtKaz1HubthTMPlUka2Ci2Kyoiab8qf 6Thj+7HdOvMUHBS/zsxcZI4Qvh1RH680P/uerBaHqqeyabZdEvZKiwWbYhrWxz4nIAr5 PxJA==
X-Gm-Message-State: ALoCoQlIZS1c0w4sEi43K5HrY+kAmXrIiW5x6ZQn+eAhLmd0CiBs7VCsPOjxErECzQusyUAvl4lV
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr11888873lbc.123.1445158212235;  Sun, 18 Oct 2015 01:50:12 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Sun, 18 Oct 2015 01:50:12 -0700 (PDT)
In-Reply-To: <20151018083158.GA78184@elstar.local>
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <20151018083158.GA78184@elstar.local>
Date: Sun, 18 Oct 2015 01:50:12 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  Randy Presuhn , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c26650e2911d05225d1d2d
Archived-At: 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:50:16 -0000

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

On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > Hi -
> >
> > > From: Andy Bierman
> > > Sent: Oct 17, 2015 10:42 AM
> > ...
> > > Subject: Re: [netmod] 6020bis extensions
> > ...
> >
> > Andy Proposed:
> >
> > >    If a YANG parser does not support a particular extension, which
> > >    appears in a YANG module as an unknown-statement (see Section 14),
> > >    the entire unknown-statement MAY be ignored by the parser. Note that
> > >    this only applies to a generic YANG parser. A tool which is required
> > >    to implement the particular extension MUST NOT ignore such an
> > >    unknown-statement.
> >
> > I'd suggest a slightly different wording:
> >
> >   The processing of extensions depends on whether support for those
> >   extensions is claimed for a given YANG parser or the tool set in
> >   which it is embedded.  An unsupported extension, appearing in a
> >   YANG module as an unknown-statement (see Section 14) MAY be
> >   ignored in its entirety.  Any supported extension MUST be processed
> >   in accordance with the specification governing that extension.
> >
>
> I am not happy with either of these. It is important for me to state
> that the semantics associated with an extension statement apply,
> irrespective of the tool being used to implement a module. You can't
> simply ignore nacm:default-deny-write just because your tool skipped
> over this extension statement. So what about this:
>
>    If a tool does not support a particular extension, which appears in
>    a YANG module as an unknown-statement (see Section 14), the entire
>    unknown-statement MAY be ignored by the tool. Irrespective of this,
>    the semantics associated with an extension MUST be implemented
>    whenever an extension statement appears in a YANG module.
>
>

I like Randy's text.  I don't really think any text is needed,
because the differences between "conformance to YANG"
and "conformance to a module written in YANG" are quite clear to me.
There is no way that all tools have to support some vendor extension
that is intended for 1 proprietary tool.



> /js
>

Andy


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

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




On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Pres=
uhn wrote:

> Hi -

>

> > From: Andy Bierman

> > Sent: Oct 17, 2015 10:42 AM

> ...

> > Subject: Re: [netmod] 6020bis extensions

> ...

>

> Andy Proposed:

>

> >=C2=A0 =C2=A0 If a YANG parser does not support a particular exten=
sion, which

> >=C2=A0 =C2=A0 appears in a YANG module as an unknown-statement (se=
e Section 14),

> >=C2=A0 =C2=A0 the entire unknown-statement MAY be ignored by the p=
arser. Note that

> >=C2=A0 =C2=A0 this only applies to a generic YANG parser. A tool w=
hich is required

> >=C2=A0 =C2=A0 to implement the particular extension MUST NOT ignor=
e such an

> >=C2=A0 =C2=A0 unknown-statement.

>

> I'd suggest a slightly different wording:

>

>=C2=A0 =C2=A0The processing of extensions depends on whether support fo=
r those

>=C2=A0 =C2=A0extensions is claimed for a given YANG parser or the tool =
set in

>=C2=A0 =C2=A0which it is embedded.=C2=A0 An unsupported extension, appe=
aring in a

>=C2=A0 =C2=A0YANG module as an unknown-statement (see Section 14) MAY b=
e

>=C2=A0 =C2=A0ignored in its entirety.=C2=A0 Any supported extension MUS=
T be processed

>=C2=A0 =C2=A0in accordance with the specification governing that extens=
ion.

>



I am not happy with either of these. It is important for me to state

that the semantics associated with an extension statement apply,

irrespective of the tool being used to implement a module. You can't
simply ignore nacm:default-deny-write just because your tool skipped

over this extension statement. So what about this:



=C2=A0 =C2=A0If a tool does not support a particular extension, which appea=
rs in

=C2=A0 =C2=A0a YANG module as an unknown-statement (see Section 14), the en=
tire

=C2=A0 =C2=A0unknown-statement MAY be ignored by the tool. Irrespective of =
this,

=C2=A0 =C2=A0the semantics associated with an extension MUST be implemented=


=C2=A0 =C2=A0whenever an extension statement appears in a YANG module.




I like Randy's text.=C2=A0 I don&=
#39;t really think any text is needed,
because the differences be=
tween "conformance to YANG"
and "conformance to a =
module written in YANG" are quite clear to me.
There is no w=
ay that all tools have to support some vendor extension
that is i=
ntended for 1 proprietary tool.

=C2=A0

/js

Andy
=C2=A0=




--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c26650e2911d05225d1d2d--


From nobody Sun Oct 18 01:51:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFE91B2E4C for ; Sun, 18 Oct 2015 01:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtZnIaHNcHrN for ; Sun, 18 Oct 2015 01:51:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30AD1B2E48 for ; Sun, 18 Oct 2015 01:51:18 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B78B9F6E; Sun, 18 Oct 2015 10:51:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pRIs7vvVVvlm; Sun, 18 Oct 2015 10:51:16 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 10:51:16 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A369720053; Sun, 18 Oct 2015 10:51:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AK73DGAZIB2I; Sun, 18 Oct 2015 10:51:16 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D5B82004E; Sun, 18 Oct 2015 10:51:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6BF3137B756C; Sun, 18 Oct 2015 10:51:14 +0200 (CEST)
Date: Sun, 18 Oct 2015 10:51:14 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151018085113.GC78184@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20151013080254.GA65823@elstar.local> <20151015.230141.2155612685960164497.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151015.230141.2155612685960164497.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:51:20 -0000

On Thu, Oct 15, 2015 at 11:01:41PM +0200, Martin Bjorklund wrote:

> > * p137
> > 
> >   Y25-02 says:
> > 
> >       Keep the auto-numbering procedure for enums and bits and add an
> >       explicit warning that inserting enum or bits definitions or
> >       reordering enum or bits definitions violates section 10 and causes
> >       interoperability problems unless explicit value assignments are
> >       used.
> > 
> >   Has this been implemented? I did not find such a statement.
> 
> Neither did I :(
> 
> I think it is best to add this warning to section 10:
> 
> OLD:
> 
>   o  An "enumeration" type may have new enums added, provided the old
>      enums's values do not change.
> 
> NEW:
> 
>   o  An "enumeration" type may have new enums added, provided the old
>      enums's values do not change.  Note that inserting a new enum before
>      an existing enum or reordering existing enums will result in new
>      values for the existing enums, unless they have explicit values
>      assigned to them.

OK

> > * p139
> > 
> >   s/A binary can/A binary type can/
> 
> Fixed.
> 
> > * p139
> > 
> >   s/are encoded/are encoded in XML/
> 
> How about s/are encoded/are lexically represented/
> 
> since it is not just XML, but also defaults and the canonical form.

But if you think about something like CBOR, would you still base64
encode the binary value? I do not think so. Within the YANG context,
we represent binary values as base64 encoded strings but on the wire
we might do something more efficient in a binary encoding.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 01:53:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A3B1B2E4C for ; Sun, 18 Oct 2015 01:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6GmPGNJG-xA for ; Sun, 18 Oct 2015 01:53:35 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3751B2E48 for ; Sun, 18 Oct 2015 01:53:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 11D3FF6E; Sun, 18 Oct 2015 10:53:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7f-7fHy8_xTQ; Sun, 18 Oct 2015 10:53:33 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 10:53:33 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA29520053; Sun, 18 Oct 2015 10:53:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ybLjjX66K0zz; Sun, 18 Oct 2015 10:53:31 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D0EB2004E; Sun, 18 Oct 2015 10:53:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 317F337B75A4; Sun, 18 Oct 2015 10:53:31 +0200 (CEST)
Date: Sun, 18 Oct 2015 10:53:31 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20151018085331.GD78184@elstar.local>
Mail-Followup-To: Andy Bierman , Randy Presuhn , "netmod@ietf.org" 
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <20151018083158.GA78184@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 08:53:37 -0000

On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > > Hi -
> > >
> > > > From: Andy Bierman
> > > > Sent: Oct 17, 2015 10:42 AM
> > > ...
> > > > Subject: Re: [netmod] 6020bis extensions
> > > ...
> > >
> > > Andy Proposed:
> > >
> > > >    If a YANG parser does not support a particular extension, which
> > > >    appears in a YANG module as an unknown-statement (see Section 14),
> > > >    the entire unknown-statement MAY be ignored by the parser. Note that
> > > >    this only applies to a generic YANG parser. A tool which is required
> > > >    to implement the particular extension MUST NOT ignore such an
> > > >    unknown-statement.
> > >
> > > I'd suggest a slightly different wording:
> > >
> > >   The processing of extensions depends on whether support for those
> > >   extensions is claimed for a given YANG parser or the tool set in
> > >   which it is embedded.  An unsupported extension, appearing in a
> > >   YANG module as an unknown-statement (see Section 14) MAY be
> > >   ignored in its entirety.  Any supported extension MUST be processed
> > >   in accordance with the specification governing that extension.
> > >
> >
> > I am not happy with either of these. It is important for me to state
> > that the semantics associated with an extension statement apply,
> > irrespective of the tool being used to implement a module. You can't
> > simply ignore nacm:default-deny-write just because your tool skipped
> > over this extension statement. So what about this:
> >
> >    If a tool does not support a particular extension, which appears in
> >    a YANG module as an unknown-statement (see Section 14), the entire
> >    unknown-statement MAY be ignored by the tool. Irrespective of this,
> >    the semantics associated with an extension MUST be implemented
> >    whenever an extension statement appears in a YANG module.
> 
> I like Randy's text.  I don't really think any text is needed,
> because the differences between "conformance to YANG"
> and "conformance to a module written in YANG" are quite clear to me.
> There is no way that all tools have to support some vendor extension
> that is intended for 1 proprietary tool.

I dislike Randy's text since it essentially says you can ignore any
extensions such as nacm:default-deny-write - all you have to claim is
that your tool does not support it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 02:00:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70B21B2E56 for ; Sun, 18 Oct 2015 02:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlngZ-6qAxdI for ; Sun, 18 Oct 2015 02:00:52 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BEE1B2E52 for ; Sun, 18 Oct 2015 02:00:52 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0AB35E72; Sun, 18 Oct 2015 11:00:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AFYx2S2fLf4Y; Sun, 18 Oct 2015 11:00:50 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 11:00:50 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E6322004E; Sun, 18 Oct 2015 11:00:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lGRwi21JB1KY; Sun, 18 Oct 2015 11:00:49 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D76CC20053; Sun, 18 Oct 2015 11:00:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8342D37B75D9; Sun, 18 Oct 2015 11:00:47 +0200 (CEST)
Date: Sun, 18 Oct 2015 11:00:47 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151018090047.GE78184@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
References:  <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> <20151013192337.GC67325@elstar.local>  <20151015070330.GC70280@elstar.local> <415D4893-F9BB-445B-A4FB-1A77CEDF642F@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <415D4893-F9BB-445B-A4FB-1A77CEDF642F@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 09:00:54 -0000

On Thu, Oct 15, 2015 at 09:52:00AM +0200, Ladislav Lhotka wrote:

[...]
 
> The "schema" part addresses syntactic changes in protocol messages,
> which are inevitable, and the second part is about risky
> annotations. I agree evil annotations should be banned but I am not
> sure we can find a satisfactory formulation. Do you have any
> suggestion?

Perhaps the simples solution is to remove the first sentence in order
to avoid having 'schema' understood in different ways. (I personally
believe an annotation MUST NOT change data model semantics but lets
try to find a compromise.) So my proposal is to replace the entire
paragraph with:

   Due care has to be exercised when introducing annotations in network
   management systems in order to avoid interoperability problems and
   software failures.  The following aspects should be taken into
   account:

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 02:52:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A371B2E98 for ; Sun, 18 Oct 2015 02:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqhNLXova5yM for ; Sun, 18 Oct 2015 02:52:05 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE41C1B2E97 for ; Sun, 18 Oct 2015 02:52:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C23CE8EA; Sun, 18 Oct 2015 11:52:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q1ATClX665Cj; Sun, 18 Oct 2015 11:52:03 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 11:52:03 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C650F20053; Sun, 18 Oct 2015 11:52:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vEEDiBTLWAHO; Sun, 18 Oct 2015 11:52:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE5122004E; Sun, 18 Oct 2015 11:52:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0C7AD37B782B; Sun, 18 Oct 2015 11:52:00 +0200 (CEST)
Date: Sun, 18 Oct 2015 11:52:00 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151018095200.GB78503@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151015.180357.1644539809319777532.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 09:52:06 -0000

On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> 
> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> rephrase the intro text in 8.2) But I think Balazs is also right.
> Suppose you have:
> 
>   leaf a {
>     when "../b = 42";
>     type int32;
>   }
>   leaf b {
>     type int32;
>   }
> 
> and the db contains b=10.
> 
> Suppose I send an edit-config with a=2.  What is the result?
> 
>   1)  you get an error back
>   2)  you get ok; the request to set a to 2 is silently dropped
>   3)  something else
>

Isn't the simplest to always make the changes that were requested in
the rpc/action (e.g. edit-config) and then to validate the result and
if it fails to validate to return an error? No magic addition or
removal of nodes while trying to guess what the client wanted to
achieve. I am likely missing details since I never implemented this
but having a processing logic that is simple to understand would be
good and I think it is fair to expect that clients send edits that
do not require the server to guess what should happen.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 05:14:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94711A1B5F for ; Sun, 18 Oct 2015 05:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDjQIatB9bck for ; Sun, 18 Oct 2015 05:14:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADD11A1B5D for ; Sun, 18 Oct 2015 05:14:03 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B8DD1AE046C; Sun, 18 Oct 2015 14:14:01 +0200 (CEST)
Date: Sun, 18 Oct 2015 14:17:46 +0200 (CEST)
Message-Id: <20151018.141746.64718045791283540.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151018085331.GD78184@elstar.local>
References: <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 12:14:05 -0000

Juergen Schoenwaelder  wrote:
> On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> > 
> > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > > > Hi -
> > > >
> > > > > From: Andy Bierman
> > > > > Sent: Oct 17, 2015 10:42 AM
> > > > ...
> > > > > Subject: Re: [netmod] 6020bis extensions
> > > > ...
> > > >
> > > > Andy Proposed:
> > > >
> > > > >    If a YANG parser does not support a particular extension, which
> > > > >    appears in a YANG module as an unknown-statement (see Section 14),
> > > > >    the entire unknown-statement MAY be ignored by the parser. Note that
> > > > >    this only applies to a generic YANG parser. A tool which is required
> > > > >    to implement the particular extension MUST NOT ignore such an
> > > > >    unknown-statement.
> > > >
> > > > I'd suggest a slightly different wording:
> > > >
> > > >   The processing of extensions depends on whether support for those
> > > >   extensions is claimed for a given YANG parser or the tool set in
> > > >   which it is embedded.  An unsupported extension, appearing in a
> > > >   YANG module as an unknown-statement (see Section 14) MAY be
> > > >   ignored in its entirety.  Any supported extension MUST be processed
> > > >   in accordance with the specification governing that extension.
> > > >
> > >
> > > I am not happy with either of these. It is important for me to state
> > > that the semantics associated with an extension statement apply,
> > > irrespective of the tool being used to implement a module. You can't
> > > simply ignore nacm:default-deny-write just because your tool skipped
> > > over this extension statement. So what about this:
> > >
> > >    If a tool does not support a particular extension, which appears in
> > >    a YANG module as an unknown-statement (see Section 14), the entire
> > >    unknown-statement MAY be ignored by the tool. Irrespective of this,
> > >    the semantics associated with an extension MUST be implemented
> > >    whenever an extension statement appears in a YANG module.
> > 
> > I like Randy's text.  I don't really think any text is needed,
> > because the differences between "conformance to YANG"
> > and "conformance to a module written in YANG" are quite clear to me.
> > There is no way that all tools have to support some vendor extension
> > that is intended for 1 proprietary tool.
> 
> I dislike Randy's text since it essentially says you can ignore any
> extensions such as nacm:default-deny-write - all you have to claim is
> that your tool does not support it.

I think it *is* ok to ignore this statement for a server that doesn't
implement NACM.  I think Randy's text is fine.


/martin


From nobody Sun Oct 18 05:17:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163771A1B6E for ; Sun, 18 Oct 2015 05:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHOPJzLOJU62 for ; Sun, 18 Oct 2015 05:17:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3A1A1B6B for ; Sun, 18 Oct 2015 05:17:37 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 802821AE046C; Sun, 18 Oct 2015 14:17:36 +0200 (CEST)
Date: Sun, 18 Oct 2015 14:21:22 +0200 (CEST)
Message-Id: <20151018.142122.930730372769165943.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151018095200.GB78503@elstar.local>
References:  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 12:17:39 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > 
> > Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> > rephrase the intro text in 8.2) But I think Balazs is also right.
> > Suppose you have:
> > 
> >   leaf a {
> >     when "../b = 42";
> >     type int32;
> >   }
> >   leaf b {
> >     type int32;
> >   }
> > 
> > and the db contains b=10.
> > 
> > Suppose I send an edit-config with a=2.  What is the result?
> > 
> >   1)  you get an error back
> >   2)  you get ok; the request to set a to 2 is silently dropped
> >   3)  something else
> >
> 
> Isn't the simplest to always make the changes that were requested in
> the rpc/action (e.g. edit-config) and then to validate the result and
> if it fails to validate to return an error? No magic addition or
> removal of nodes while trying to guess what the client wanted to
> achieve.

Note that "when" is like a generalized "choice".  If nodes for one
case is present, and you want another case to be set, you just have to
create the new nodes.  The server deletes the nodes from the old case
for you.  In the same way, the server deletes nodes from "when"
statements that become false.

The "must" statement behaves the way you describe above.


/martin


From nobody Sun Oct 18 05:52:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4D1A6EE1 for ; Sun, 18 Oct 2015 05:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkFSoDvZKtXS for ; Sun, 18 Oct 2015 05:52:41 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5629A1A21C0 for ; Sun, 18 Oct 2015 05:52:41 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DC7B193B; Sun, 18 Oct 2015 14:52:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NkaGlOGhqzhd; Sun, 18 Oct 2015 14:52:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 14:52:36 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EE0D20053; Sun, 18 Oct 2015 14:52:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t7RXRVrKj0Qp; Sun, 18 Oct 2015 14:52:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB2BD2004E; Sun, 18 Oct 2015 14:52:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C4C2337B79C4; Sun, 18 Oct 2015 14:52:29 +0200 (CEST)
Date: Sun, 18 Oct 2015 14:52:29 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151018125229.GA78907@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, randy_presuhn@mindspring.com, netmod@ietf.org
References: <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local> <20151018.141746.64718045791283540.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151018.141746.64718045791283540.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 12:52:45 -0000

On Sun, Oct 18, 2015 at 02:17:46PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> > > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > > 
> > > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > > > > Hi -
> > > > >
> > > > > > From: Andy Bierman
> > > > > > Sent: Oct 17, 2015 10:42 AM
> > > > > ...
> > > > > > Subject: Re: [netmod] 6020bis extensions
> > > > > ...
> > > > >
> > > > > Andy Proposed:
> > > > >
> > > > > >    If a YANG parser does not support a particular extension, which
> > > > > >    appears in a YANG module as an unknown-statement (see Section 14),
> > > > > >    the entire unknown-statement MAY be ignored by the parser. Note that
> > > > > >    this only applies to a generic YANG parser. A tool which is required
> > > > > >    to implement the particular extension MUST NOT ignore such an
> > > > > >    unknown-statement.
> > > > >
> > > > > I'd suggest a slightly different wording:
> > > > >
> > > > >   The processing of extensions depends on whether support for those
> > > > >   extensions is claimed for a given YANG parser or the tool set in
> > > > >   which it is embedded.  An unsupported extension, appearing in a
> > > > >   YANG module as an unknown-statement (see Section 14) MAY be
> > > > >   ignored in its entirety.  Any supported extension MUST be processed
> > > > >   in accordance with the specification governing that extension.
> > > > >
> > > >
> > > > I am not happy with either of these. It is important for me to state
> > > > that the semantics associated with an extension statement apply,
> > > > irrespective of the tool being used to implement a module. You can't
> > > > simply ignore nacm:default-deny-write just because your tool skipped
> > > > over this extension statement. So what about this:
> > > >
> > > >    If a tool does not support a particular extension, which appears in
> > > >    a YANG module as an unknown-statement (see Section 14), the entire
> > > >    unknown-statement MAY be ignored by the tool. Irrespective of this,
> > > >    the semantics associated with an extension MUST be implemented
> > > >    whenever an extension statement appears in a YANG module.
> > > 
> > > I like Randy's text.  I don't really think any text is needed,
> > > because the differences between "conformance to YANG"
> > > and "conformance to a module written in YANG" are quite clear to me.
> > > There is no way that all tools have to support some vendor extension
> > > that is intended for 1 proprietary tool.
> > 
> > I dislike Randy's text since it essentially says you can ignore any
> > extensions such as nacm:default-deny-write - all you have to claim is
> > that your tool does not support it.
> 
> I think it *is* ok to ignore this statement for a server that doesn't
> implement NACM.  I think Randy's text is fine.

I disagree with the idea that extensions can be ignored arbitrarily
just because a tool did skip over them. I thought we agreed that
nacm:default-deny-write can't be ignored (if you implement NACM).  I
actually think it is up to the extension to define when and how it
applies. The definition of nacm:default-deny-write actually does say
when it applies.

I could copy the text of the nacm:default-deny-write description
verbatim into the description of every object marked with
nacm:default-deny-write. Using an extension is just a shorthand for
this (with the added bonus that it is machine readable for tools). I
do not think such an extension can be arbitrarily ignored just because
a certain tool skipped over it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 06:00:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944261A6F2E for ; Sun, 18 Oct 2015 06:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRyQl-TxK3vL for ; Sun, 18 Oct 2015 06:00:33 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2951A6F2B for ; Sun, 18 Oct 2015 06:00:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ECD4593B; Sun, 18 Oct 2015 15:00:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3Ji62j0rzxJY; Sun, 18 Oct 2015 15:00:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 15:00:26 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC46C20053; Sun, 18 Oct 2015 15:00:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2kKbOlNGpa93; Sun, 18 Oct 2015 15:00:26 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E8DE2004E; Sun, 18 Oct 2015 15:00:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7C7B737B7A01; Sun, 18 Oct 2015 15:00:25 +0200 (CEST)
Date: Sun, 18 Oct 2015 15:00:25 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151018130025.GB78907@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References:  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <20151018.142122.930730372769165943.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151018.142122.930730372769165943.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 13:00:35 -0000

On Sun, Oct 18, 2015 at 02:21:22PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > > 
> > > Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> > > rephrase the intro text in 8.2) But I think Balazs is also right.
> > > Suppose you have:
> > > 
> > >   leaf a {
> > >     when "../b = 42";
> > >     type int32;
> > >   }
> > >   leaf b {
> > >     type int32;
> > >   }
> > > 
> > > and the db contains b=10.
> > > 
> > > Suppose I send an edit-config with a=2.  What is the result?
> > > 
> > >   1)  you get an error back
> > >   2)  you get ok; the request to set a to 2 is silently dropped
> > >   3)  something else
> > >
> > 
> > Isn't the simplest to always make the changes that were requested in
> > the rpc/action (e.g. edit-config) and then to validate the result and
> > if it fails to validate to return an error? No magic addition or
> > removal of nodes while trying to guess what the client wanted to
> > achieve.
> 
> Note that "when" is like a generalized "choice".  If nodes for one
> case is present, and you want another case to be set, you just have to
> create the new nodes.  The server deletes the nodes from the old case
> for you.  In the same way, the server deletes nodes from "when"
> statements that become false.
> 
> The "must" statement behaves the way you describe above.

Not sure this automatic deletion of nodes was a smart idea since this
leads to the confusion of what the server does with certain edits. I
am not sure the savings this brings (you do not have to delete the old
stuff) are worth the trouble. Are clients really relying on this
automatic deletion of nodes?

/js

PS: These are really specific protocol aspects that ideally would be
    in some other document (but its difficult to refactor things in
    the IETF).

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 06:07:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84B21A6F6F for ; Sun, 18 Oct 2015 06:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkWlAexRCIow for ; Sun, 18 Oct 2015 06:07:27 -0700 (PDT)
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 9E28C1A6F63 for ; Sun, 18 Oct 2015 06:07:25 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656] (unknown [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656]) by mail.nic.cz (Postfix) with ESMTPSA id CB2C7180F42; Sun, 18 Oct 2015 15:07:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445173643; bh=BDfoicWoz3SxfMtKfHh+TxPigFkvaKMtOdpqYnMUs6g=; h=From:Date:To; b=sCATrXggfDg0SQalO2sBs2aDEkkd8/UUyTZ5V3MqOA6pQlY3SNEm3XmD/DEj9MC77 iro0FovO76DplUZJIHaFHzkzCRtkW/5162rjtIpK/00Md95hN/3IxUSMDckCXi0zV1 RtFH5LbUgksO/+Yu3dKGkfv13BTuOKDr/MS6IVng=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151018085331.GD78184@elstar.local>
Date: Sun, 18 Oct 2015 15:07:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <362A65A7-6D78-4070-9B45-07CD7CB93C24@nic.cz>
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 13:07:29 -0000

> On 18 Oct 2015, at 10:53, Juergen Schoenwaelder =
 wrote:
>=20
> On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
>> On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>=20
>>> On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
>>>> Hi -
>>>>=20
>>>>> From: Andy Bierman
>>>>> Sent: Oct 17, 2015 10:42 AM
>>>> ...
>>>>> Subject: Re: [netmod] 6020bis extensions
>>>> ...
>>>>=20
>>>> Andy Proposed:
>>>>=20
>>>>>   If a YANG parser does not support a particular extension, which
>>>>>   appears in a YANG module as an unknown-statement (see Section =
14),
>>>>>   the entire unknown-statement MAY be ignored by the parser. Note =
that
>>>>>   this only applies to a generic YANG parser. A tool which is =
required
>>>>>   to implement the particular extension MUST NOT ignore such an
>>>>>   unknown-statement.
>>>>=20
>>>> I'd suggest a slightly different wording:
>>>>=20
>>>>  The processing of extensions depends on whether support for those
>>>>  extensions is claimed for a given YANG parser or the tool set in
>>>>  which it is embedded.  An unsupported extension, appearing in a
>>>>  YANG module as an unknown-statement (see Section 14) MAY be
>>>>  ignored in its entirety.  Any supported extension MUST be =
processed
>>>>  in accordance with the specification governing that extension.
>>>>=20
>>>=20
>>> I am not happy with either of these. It is important for me to state
>>> that the semantics associated with an extension statement apply,
>>> irrespective of the tool being used to implement a module. You can't
>>> simply ignore nacm:default-deny-write just because your tool skipped
>>> over this extension statement. So what about this:
>>>=20
>>>   If a tool does not support a particular extension, which appears =
in
>>>   a YANG module as an unknown-statement (see Section 14), the entire
>>>   unknown-statement MAY be ignored by the tool. Irrespective of =
this,
>>>   the semantics associated with an extension MUST be implemented
>>>   whenever an extension statement appears in a YANG module.
>>=20
>> I like Randy's text.  I don't really think any text is needed,
>> because the differences between "conformance to YANG"
>> and "conformance to a module written in YANG" are quite clear to me.
>> There is no way that all tools have to support some vendor extension
>> that is intended for 1 proprietary tool.
>=20
> I dislike Randy's text since it essentially says you can ignore any
> extensions such as nacm:default-deny-write - all you have to claim is
> that your tool does not support it.

It is the role of RFC 6536 to make sure the extension is supported where =
necessary. On the other hand, other applications such as translation to =
DSDL schemas have nothing to do with NACM, so they can ignore the =
extension.

Lada

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

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





From nobody Sun Oct 18 06:28:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC381A7D84 for ; Sun, 18 Oct 2015 06:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH3EdkPb_oh7 for ; Sun, 18 Oct 2015 06:28:15 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65061A711A for ; Sun, 18 Oct 2015 06:28:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8C4C8EA; Sun, 18 Oct 2015 15:28:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cyh42PJ_sAOH; Sun, 18 Oct 2015 15:28:09 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Oct 2015 15:28:09 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4476020053; Sun, 18 Oct 2015 15:28:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wu8pq4s398WS; Sun, 18 Oct 2015 15:28:08 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B426F2004E; Sun, 18 Oct 2015 15:28:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DC4A237B7A8B; Sun, 18 Oct 2015 15:28:06 +0200 (CEST)
Date: Sun, 18 Oct 2015 15:28:06 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151018132806.GA79003@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , "netmod@ietf.org" 
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local> <362A65A7-6D78-4070-9B45-07CD7CB93C24@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <362A65A7-6D78-4070-9B45-07CD7CB93C24@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 13:28:17 -0000

On Sun, Oct 18, 2015 at 03:07:22PM +0200, Ladislav Lhotka wrote:
> 
> > On 18 Oct 2015, at 10:53, Juergen Schoenwaelder  wrote:
> > 
> > On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> >> On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> >> j.schoenwaelder@jacobs-university.de> wrote:
> >> 
> >>> On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> >>>> Hi -
> >>>> 
> >>>>> From: Andy Bierman
> >>>>> Sent: Oct 17, 2015 10:42 AM
> >>>> ...
> >>>>> Subject: Re: [netmod] 6020bis extensions
> >>>> ...
> >>>> 
> >>>> Andy Proposed:
> >>>> 
> >>>>>   If a YANG parser does not support a particular extension, which
> >>>>>   appears in a YANG module as an unknown-statement (see Section 14),
> >>>>>   the entire unknown-statement MAY be ignored by the parser. Note that
> >>>>>   this only applies to a generic YANG parser. A tool which is required
> >>>>>   to implement the particular extension MUST NOT ignore such an
> >>>>>   unknown-statement.
> >>>> 
> >>>> I'd suggest a slightly different wording:
> >>>> 
> >>>>  The processing of extensions depends on whether support for those
> >>>>  extensions is claimed for a given YANG parser or the tool set in
> >>>>  which it is embedded.  An unsupported extension, appearing in a
> >>>>  YANG module as an unknown-statement (see Section 14) MAY be
> >>>>  ignored in its entirety.  Any supported extension MUST be processed
> >>>>  in accordance with the specification governing that extension.
> >>>> 
> >>> 
> >>> I am not happy with either of these. It is important for me to state
> >>> that the semantics associated with an extension statement apply,
> >>> irrespective of the tool being used to implement a module. You can't
> >>> simply ignore nacm:default-deny-write just because your tool skipped
> >>> over this extension statement. So what about this:
> >>> 
> >>>   If a tool does not support a particular extension, which appears in
> >>>   a YANG module as an unknown-statement (see Section 14), the entire
> >>>   unknown-statement MAY be ignored by the tool. Irrespective of this,
> >>>   the semantics associated with an extension MUST be implemented
> >>>   whenever an extension statement appears in a YANG module.
> >> 
> >> I like Randy's text.  I don't really think any text is needed,
> >> because the differences between "conformance to YANG"
> >> and "conformance to a module written in YANG" are quite clear to me.
> >> There is no way that all tools have to support some vendor extension
> >> that is intended for 1 proprietary tool.
> > 
> > I dislike Randy's text since it essentially says you can ignore any
> > extensions such as nacm:default-deny-write - all you have to claim is
> > that your tool does not support it.
> 
> It is the role of RFC 6536 to make sure the extension is supported where necessary. On the other hand, other applications such as translation to DSDL schemas have nothing to do with NACM, so they can ignore the extension.
>

I am talking about implementation of data models. You all seem to be
thinking about tools only or some intermediate formats. DSDL likely
ignores descriptions - all fine with me. But an implementation of a
data model I think is not allowed to simply ignore extensions (as it
is not allowed to simply ignore descriptions).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 18 06:31:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A24A1A802A for ; Sun, 18 Oct 2015 06:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7UemsSUPTlE for ; Sun, 18 Oct 2015 06:31:34 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0641A8028 for ; Sun, 18 Oct 2015 06:31:33 -0700 (PDT)
Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 340FC1CC00A2; Sun, 18 Oct 2015 15:31:38 +0200 (CEST)
From: Ladislav Lhotka 
To: Xiang Li , netmod@ietf.org
In-Reply-To: <562184A1.6000802@seguesoft.com>
References: <5621845D.6040100@seguesoft.com> <562184A1.6000802@seguesoft.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Sun, 18 Oct 2015 15:31:31 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Fwd: Re:  Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 13:31:36 -0000

Xiang Li  writes:

> On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
>>> On 16 Oct 2015, at 12:27, Balazs Lengyel  wrote:
>>>
>>> IMHO YANG should define the behavoir, and I would want it to be the same on Netconf/Restconf/CLI etc.
>>> I agree that " 1) you get an error back" would be the best: because it is the easiest to understand for the operator, with the fewest corner cases.
>>> Also we must define if in the same transaction we set b=42 and a=2. which of the 3 options are taken?
>>>
>>>
>>> We should not leave such complex cases undefined, or alternatively state that they are implementation dependant.
>> I might be difficult to say what is a complex case, unless we abandon XPath in "when" statements and use something else - and considerably simpler.
>>
>> Here is another interesting corner case - does it qualify as being complex?
>>
>> leaf-list bar {
>>     type uint8;
>>     when "count(../*) > 1";
>> }
>> leaf foo {
>>     type uint8;
>> }
>
> Interesting example...
>
>> Assuming no instances exist, is this edit allowed? (This was essentially your question.)
>>
>> 1
>> 2
>
> I think this should succeed
>
>>
>> But what about this?
>>
>> 1
>> 2
>>
> I think this should succeed too because the when is satisfied in the
> data store after the edit-config.
>

According to the third bullet in sec. 7.21.5 of 6020bis, a validating
algorithm has to remove the existing "bar" instances, add a dummy
instance and then evaluate the XPath expression. If the result is true,
the existing "bar" instances will be put back, otherwise a validation
error will be reported - so in our case we will have only one "bar" node,
which is invalid. 

The result of this change is that we (hopefully) made the processing of
"when" well-defined and unambiguous, but the cost in increased comlexity
is quite high - both for module readers and implementors of a validating
algorithm.

In fact, when we discussed issue Y18, my understanding was that dummy
node manipulations will be used only if the context node is missing.

Lada

>
>
> -Xiang Li
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Sun Oct 18 07:28:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7501A899B for ; Sun, 18 Oct 2015 07:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOIlJeeW9owi for ; Sun, 18 Oct 2015 07:28:23 -0700 (PDT)
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 14BC01A8996 for ; Sun, 18 Oct 2015 07:28:22 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656] (unknown [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656]) by mail.nic.cz (Postfix) with ESMTPSA id 9427F181752; Sun, 18 Oct 2015 16:28:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445178498; bh=DHh09SsuYmfdF+0xXf3CYaaFtFlTmM6N94dqfKWNpzU=; h=From:Date:To; b=HrwpBjgklpPimGBZfU9y71mvKoZCL1LNmTNve+0GRcxD4dycxd1l4jsuLJcavQBd9 Uxz66e7NZulRxUABykpDsLjq2P4yQIyjKRsX9wq1NxwLtTFcCAvAGcM6qfqmudPGK2 qs5H/+fo/enNHnkg7P7ee4Bbe3q+daVV6pmceY7c=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151018132806.GA79003@elstar.local>
Date: Sun, 18 Oct 2015 16:28:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CA1A43E-CA0A-41C3-A680-AF16C5EF6721@nic.cz>
References: <25071765.1445136547212.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local> <362A65A7-6D78-4070-9B45-07CD7CB93C24@nic.cz> <20151018132806.GA79003@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 14:28:27 -0000

> On 18 Oct 2015, at 15:28, Juergen Schoenwaelder =
 wrote:
>=20
> On Sun, Oct 18, 2015 at 03:07:22PM +0200, Ladislav Lhotka wrote:
>>=20
>>> On 18 Oct 2015, at 10:53, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
>>>> On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>=20
>>>>> On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
>>>>>> Hi -
>>>>>>=20
>>>>>>> From: Andy Bierman
>>>>>>> Sent: Oct 17, 2015 10:42 AM
>>>>>> ...
>>>>>>> Subject: Re: [netmod] 6020bis extensions
>>>>>> ...
>>>>>>=20
>>>>>> Andy Proposed:
>>>>>>=20
>>>>>>>  If a YANG parser does not support a particular extension, which
>>>>>>>  appears in a YANG module as an unknown-statement (see Section =
14),
>>>>>>>  the entire unknown-statement MAY be ignored by the parser. Note =
that
>>>>>>>  this only applies to a generic YANG parser. A tool which is =
required
>>>>>>>  to implement the particular extension MUST NOT ignore such an
>>>>>>>  unknown-statement.
>>>>>>=20
>>>>>> I'd suggest a slightly different wording:
>>>>>>=20
>>>>>> The processing of extensions depends on whether support for those
>>>>>> extensions is claimed for a given YANG parser or the tool set in
>>>>>> which it is embedded.  An unsupported extension, appearing in a
>>>>>> YANG module as an unknown-statement (see Section 14) MAY be
>>>>>> ignored in its entirety.  Any supported extension MUST be =
processed
>>>>>> in accordance with the specification governing that extension.
>>>>>>=20
>>>>>=20
>>>>> I am not happy with either of these. It is important for me to =
state
>>>>> that the semantics associated with an extension statement apply,
>>>>> irrespective of the tool being used to implement a module. You =
can't
>>>>> simply ignore nacm:default-deny-write just because your tool =
skipped
>>>>> over this extension statement. So what about this:
>>>>>=20
>>>>>  If a tool does not support a particular extension, which appears =
in
>>>>>  a YANG module as an unknown-statement (see Section 14), the =
entire
>>>>>  unknown-statement MAY be ignored by the tool. Irrespective of =
this,
>>>>>  the semantics associated with an extension MUST be implemented
>>>>>  whenever an extension statement appears in a YANG module.
>>>>=20
>>>> I like Randy's text.  I don't really think any text is needed,
>>>> because the differences between "conformance to YANG"
>>>> and "conformance to a module written in YANG" are quite clear to =
me.
>>>> There is no way that all tools have to support some vendor =
extension
>>>> that is intended for 1 proprietary tool.
>>>=20
>>> I dislike Randy's text since it essentially says you can ignore any
>>> extensions such as nacm:default-deny-write - all you have to claim =
is
>>> that your tool does not support it.
>>=20
>> It is the role of RFC 6536 to make sure the extension is supported =
where necessary. On the other hand, other applications such as =
translation to DSDL schemas have nothing to do with NACM, so they can =
ignore the extension.
>>=20
>=20
> I am talking about implementation of data models. You all seem to be
> thinking about tools only or some intermediate formats. DSDL likely
> ignores descriptions - all fine with me. But an implementation of a
> data model I think is not allowed to simply ignore extensions (as it
> is not allowed to simply ignore descriptions).

Then you have to define what "implementation of a data model" means. If =
it is only NETCONF server or client software, then I think it is still =
the business of RFC 6536 to specify the semantics of that extension and =
address all interoperability issues.

On the other hand, some extensions may be intended for use outside the =
NETCONF protocol.

Lada=20

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Sun Oct 18 07:43:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF31A8A1D for ; Sun, 18 Oct 2015 07:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqMwEFIOP8mg for ; Sun, 18 Oct 2015 07:43:09 -0700 (PDT)
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 654E21A8A1A for ; Sun, 18 Oct 2015 07:43:09 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656] (unknown [IPv6:2a01:5e0:29:ffff:8c0e:e346:b5c1:c656]) by mail.nic.cz (Postfix) with ESMTPSA id DB498180326; Sun, 18 Oct 2015 16:43:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445179387; bh=3HIkB1DRq6q2qeuhzwqX2d/AuL523ENwUFEO5xBntSc=; h=From:Date:To; b=b+1+LHXG0UZQlg2IqqToWAG4frsx4ROSe65X5yEoePDkE74AZtX6ir6uBGoZQ0SuJ Dexco2vjD9xYRcjL4HxEXZeuIOUtVp0KYA1UCCDucGxugOJE9OhvTluOiQInyK495s Obo63/luqn8qc2CVmJ0M9f7SyPPVFSJy0e8BB9Ic=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151018095200.GB78503@elstar.local>
Date: Sun, 18 Oct 2015 16:43:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 14:43:11 -0000

> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder =
 wrote:
>=20
> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>=20
>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
>> rephrase the intro text in 8.2) But I think Balazs is also right.
>> Suppose you have:
>>=20
>>  leaf a {
>>    when "../b =3D 42";
>>    type int32;
>>  }
>>  leaf b {
>>    type int32;
>>  }
>>=20
>> and the db contains b=3D10.
>>=20
>> Suppose I send an edit-config with a=3D2.  What is the result?
>>=20
>>  1)  you get an error back
>>  2)  you get ok; the request to set a to 2 is silently dropped
>>  3)  something else
>>=20
>=20
> Isn't the simplest to always make the changes that were requested in
> the rpc/action (e.g. edit-config) and then to validate the result and
> if it fails to validate to return an error? No magic addition or
> removal of nodes while trying to guess what the client wanted to
> achieve. I am likely missing details since I never implemented this

That would be the type of behaviour I'd prefer. The auto-deletion =
feature also goes against the principle of least embarrassement - a =
trivial error can inadvertently erase substantial parts of a data tree.

Lada

> but having a processing logic that is simple to understand would be
> good and I think it is fair to expect that clients send edits that
> do not require the server to guess what should happen.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Sun Oct 18 08:22:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C614B1A8AAD for ; Sun, 18 Oct 2015 08:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nek9o7EH9Lvb for ; Sun, 18 Oct 2015 08:22:28 -0700 (PDT)
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (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 BF5341A8AAC for ; Sun, 18 Oct 2015 08:22:27 -0700 (PDT)
Received: by lfaz124 with SMTP id z124so96587512lfa.1 for ; Sun, 18 Oct 2015 08:22:25 -0700 (PDT)
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=RZFhuz/+fNIusFCnQ4T13uiLd+PZ9EO3zUnD8ktPTPE=; b=QncYO6Awq0YYJH4K36LDvCKytOaKh1Sm2E/TfahHhS3aPj00PvTqn7uM1OpohJUDU9 8wcPC3WIDKETh5gozVKJ3KFQ5myRvnAS6hWSILc/Hr0R53cYi69LI5jN6Apu1yurhIF3 lHurpUyeD5UXUSmwDuoNCiMJ8Uk2N+hdUF/Q4xICouv5fLHtxNhs4FwrBCuOHKQYAPSr rccLwtY8rYVLCxgOuGW91afunvq0BI1BwuluFuDxhn045RXiJJVD2M/+zbR3oezxRusR /lFFN5aTmnSzeOvbfsodvk75mF4I650rBt6BQ56H0hPEPYdPANjVWkgYbttvqhW+iDaW VK2g==
X-Gm-Message-State: ALoCoQnXiuprRuXdK1Mks51ajyN8iAd95K62jHymTDUeiA6RwLGayM9TUn/GLH4ntQ+ncMydYJDX
MIME-Version: 1.0
X-Received: by 10.25.44.80 with SMTP id s77mr7997470lfs.37.1445181745676; Sun, 18 Oct 2015 08:22:25 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Sun, 18 Oct 2015 08:22:25 -0700 (PDT)
In-Reply-To: <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>
Date: Sun, 18 Oct 2015 08:22:25 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1141091696607f05226298f1
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 15:22:30 -0000

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

On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  wrote:

>
> > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> >>
> >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> >> rephrase the intro text in 8.2) But I think Balazs is also right.
> >> Suppose you have:
> >>
> >>  leaf a {
> >>    when "../b = 42";
> >>    type int32;
> >>  }
> >>  leaf b {
> >>    type int32;
> >>  }
> >>
> >> and the db contains b=10.
> >>
> >> Suppose I send an edit-config with a=2.  What is the result?
> >>
> >>  1)  you get an error back
> >>  2)  you get ok; the request to set a to 2 is silently dropped
> >>  3)  something else
> >>
> >
> > Isn't the simplest to always make the changes that were requested in
> > the rpc/action (e.g. edit-config) and then to validate the result and
> > if it fails to validate to return an error? No magic addition or
> > removal of nodes while trying to guess what the client wanted to
> > achieve. I am likely missing details since I never implemented this
>
> That would be the type of behaviour I'd prefer. The auto-deletion feature
> also goes against the principle of least embarrassement - a trivial error
> can inadvertently erase substantial parts of a data tree.
>
>
This goes against the Postel Principle,
You can make your code as fragile as possible if you want.
I have always written servers that try to figure out what the client is
doing.

It seems obvious to me that when-stmt is applied after edits are applied,
just like a choice-stmt.

The server should not be guessing that valid edits from the client
are really programming errors.




> Lada
>

Andy


>
> > but having a processing logic that is simple to understand would be
> > good and I think it is fair to expect that clients send edits that
> > do not require the server to guess what should happen.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<=
/a>> wrote:

>

> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:

>>

>> Ok, you're right.=C2=A0 8.2.1 should be kept as it is.=C2=A0 (=
we may need to

>> rephrase the intro text in 8.2) But I think Balazs is also right.<=
br>
>> Suppose you have:

>>

>>=C2=A0 leaf a {

>>=C2=A0 =C2=A0 when "../b =3D 42";

>>=C2=A0 =C2=A0 type int32;

>>=C2=A0 }

>>=C2=A0 leaf b {

>>=C2=A0 =C2=A0 type int32;

>>=C2=A0 }

>>

>> and the db contains b=3D10.

>>

>> Suppose I send an edit-config with a=3D2.=C2=A0 What is the result=
?

>>

>>=C2=A0 1)=C2=A0 you get an error back

>>=C2=A0 2)=C2=A0 you get ok; the request to set a to 2 is silently d=
ropped

>>=C2=A0 3)=C2=A0 something else

>>

>

> Isn't the simplest to always make the changes that were requested =
in

> the rpc/action (e.g. edit-config) and then to validate the result and<=
br>
> if it fails to validate to return an error? No magic addition or

> removal of nodes while trying to guess what the client wanted to

> achieve. I am likely missing details since I never implemented this


That would be the type of behaviour I'd prefer. The auto-deletion featu=
re also goes against the principle of least embarrassement - a trivial erro=
r can inadvertently erase substantial parts of a data tree.






Lada




> but having a processing logic that is simple to understand would be
> good and I think it is fair to expect that clients send edits that

> do not require the server to guess what should happen.

>

> /js

>

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1=
 | 28759 Bremen | Germany

> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
;http://www.jacobs-university.de/>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1141091696607f05226298f1--


From nobody Sun Oct 18 08:35:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A371A8AEA for ; Sun, 18 Oct 2015 08:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ii7BqkYdNQH for ; Sun, 18 Oct 2015 08:35:30 -0700 (PDT)
Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (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 702791A8AE5 for ; Sun, 18 Oct 2015 08:35:29 -0700 (PDT)
Received: by lffv3 with SMTP id v3so97173634lff.0 for ; Sun, 18 Oct 2015 08:35:27 -0700 (PDT)
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=NhIUxWc/P2WUhzb99MWQsnvimUNIvaBP9hX9weUi6ww=; b=NBgeNiIOiq2FOEQFXfjnAekmdGpMNPx5134ljpbHdTWWk0de1xXfBqlPQeUWbfw92c YeDcn3BnhZcWJDFiB3/qFXlnto69uupwk0ub0iDZVJJuaHCIa4BdM8YIODtfSZrwT5zE eNeg3oSOhMZO5p0nDLTDf6SrPZutk6wU/UGnR+nK16K2ReoWRtdxF4iv1By3wmIMtkWV 6JyJJ3NUdWbe3uGIRUsEzBNQ3xoY/dtXBaGa4q1glDobuVKWiL+MQOchok1hdEXg9Ssh pD9ACmTqVRNerc/GtxcVjbM89RreVzUvH7oWnEGYtkvUQlQ6GXMaQ8az7XjZVE6ifuiA w6Dg==
X-Gm-Message-State: ALoCoQmYsgz4eBFgiWo3NIEXxFYEGxblj4YbhNKbTFp/Y5rwSombihImAaI4Ynea6LseiE5IMrQJ
MIME-Version: 1.0
X-Received: by 10.25.17.208 with SMTP id 77mr7669645lfr.38.1445182527441; Sun, 18 Oct 2015 08:35:27 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Sun, 18 Oct 2015 08:35:27 -0700 (PDT)
In-Reply-To: <20151018.141746.64718045791283540.mbj@tail-f.com>
References: <20151018083158.GA78184@elstar.local>  <20151018085331.GD78184@elstar.local> <20151018.141746.64718045791283540.mbj@tail-f.com>
Date: Sun, 18 Oct 2015 08:35:27 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a113fbd3c2f31f6052262c7a3
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 15:35:32 -0000

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

On Sun, Oct 18, 2015 at 5:17 AM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> > > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > > > > Hi -
> > > > >
> > > > > > From: Andy Bierman
> > > > > > Sent: Oct 17, 2015 10:42 AM
> > > > > ...
> > > > > > Subject: Re: [netmod] 6020bis extensions
> > > > > ...
> > > > >
> > > > > Andy Proposed:
> > > > >
> > > > > >    If a YANG parser does not support a particular extension,
> which
> > > > > >    appears in a YANG module as an unknown-statement (see Section
> 14),
> > > > > >    the entire unknown-statement MAY be ignored by the parser.
> Note that
> > > > > >    this only applies to a generic YANG parser. A tool which is
> required
> > > > > >    to implement the particular extension MUST NOT ignore such an
> > > > > >    unknown-statement.
> > > > >
> > > > > I'd suggest a slightly different wording:
> > > > >
> > > > >   The processing of extensions depends on whether support for those
> > > > >   extensions is claimed for a given YANG parser or the tool set in
> > > > >   which it is embedded.  An unsupported extension, appearing in a
> > > > >   YANG module as an unknown-statement (see Section 14) MAY be
> > > > >   ignored in its entirety.  Any supported extension MUST be
> processed
> > > > >   in accordance with the specification governing that extension.
> > > > >
> > > >
> > > > I am not happy with either of these. It is important for me to state
> > > > that the semantics associated with an extension statement apply,
> > > > irrespective of the tool being used to implement a module. You can't
> > > > simply ignore nacm:default-deny-write just because your tool skipped
> > > > over this extension statement. So what about this:
> > > >
> > > >    If a tool does not support a particular extension, which appears
> in
> > > >    a YANG module as an unknown-statement (see Section 14), the entire
> > > >    unknown-statement MAY be ignored by the tool. Irrespective of
> this,
> > > >    the semantics associated with an extension MUST be implemented
> > > >    whenever an extension statement appears in a YANG module.
> > >
> > > I like Randy's text.  I don't really think any text is needed,
> > > because the differences between "conformance to YANG"
> > > and "conformance to a module written in YANG" are quite clear to me.
> > > There is no way that all tools have to support some vendor extension
> > > that is intended for 1 proprietary tool.
> >
> > I dislike Randy's text since it essentially says you can ignore any
> > extensions such as nacm:default-deny-write - all you have to claim is
> > that your tool does not support it.
>
> I think it *is* ok to ignore this statement for a server that doesn't
> implement NACM.  I think Randy's text is fine.
>
>
+1

Here is a concrete example -- the 'secret' leaf in the ietf-system module:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#shared-secret.564

This is tagged as "nacm:default-deny-all".

Does this mean that if an implementation supports the ietf-system "secret"
leaf,
it MUST also include an implementation of NACM?

If yes, then Juergen is right.
If no, then Randy's text is fine.

But read the definition of "default-deny-all" carefully:
http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#default-deny-all.74

Note the line:


       If present, and the NACM module is enabled (i.e.,
       /nacm/enable-nacm object equals 'true'),


Is the NACM module "enabled" leaf set to true in a server that does
not implement NACM at all?  I would say no.

Note also that the extension does not define any behavior outside
of NACM processing.  It is not intended for every tool.
It is only intended for an implementation of NACM.


>
> /martin
>

Andy

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




On Sun, Oct 18, 2015 at 5:17 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university=
.de> wrote:

> On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:

> > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <

> > j.schoenw=
aelder@jacobs-university.de> wrote:

> >

> > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrot=
e:

> > > > Hi -

> > > >

> > > > > From: Andy Bierman

> > > > > Sent: Oct 17, 2015 10:42 AM

> > > > ...

> > > > > Subject: Re: [netmod] 6020bis extensions

> > > > ...

> > > >

> > > > Andy Proposed:

> > > >

> > > > >=C2=A0 =C2=A0 If a YANG parser does not support a p=
articular extension, which

> > > > >=C2=A0 =C2=A0 appears in a YANG module as an unknow=
n-statement (see Section 14),

> > > > >=C2=A0 =C2=A0 the entire unknown-statement MAY be i=
gnored by the parser. Note that

> > > > >=C2=A0 =C2=A0 this only applies to a generic YANG p=
arser. A tool which is required

> > > > >=C2=A0 =C2=A0 to implement the particular extension=
 MUST NOT ignore such an

> > > > >=C2=A0 =C2=A0 unknown-statement.

> > > >

> > > > I'd suggest a slightly different wording:

> > > >

> > > >=C2=A0 =C2=A0The processing of extensions depends on whe=
ther support for those

> > > >=C2=A0 =C2=A0extensions is claimed for a given YANG pars=
er or the tool set in

> > > >=C2=A0 =C2=A0which it is embedded.=C2=A0 An unsupported =
extension, appearing in a

> > > >=C2=A0 =C2=A0YANG module as an unknown-statement (see Se=
ction 14) MAY be

> > > >=C2=A0 =C2=A0ignored in its entirety.=C2=A0 Any supporte=
d extension MUST be processed

> > > >=C2=A0 =C2=A0in accordance with the specification govern=
ing that extension.

> > > >

> > >

> > > I am not happy with either of these. It is important for me =
to state

> > > that the semantics associated with an extension statement ap=
ply,

> > > irrespective of the tool being used to implement a module. Y=
ou can't

> > > simply ignore nacm:default-deny-write just because your tool=
 skipped

> > > over this extension statement. So what about this:

> > >

> > >=C2=A0 =C2=A0 If a tool does not support a particular extensi=
on, which appears in

> > >=C2=A0 =C2=A0 a YANG module as an unknown-statement (see Sect=
ion 14), the entire

> > >=C2=A0 =C2=A0 unknown-statement MAY be ignored by the tool. I=
rrespective of this,

> > >=C2=A0 =C2=A0 the semantics associated with an extension MUST=
 be implemented

> > >=C2=A0 =C2=A0 whenever an extension statement appears in a YA=
NG module.

> >

> > I like Randy's text.=C2=A0 I don't really think any text =
is needed,

> > because the differences between "conformance to YANG"
> > and "conformance to a module written in YANG" are quite=
 clear to me.

> > There is no way that all tools have to support some vendor extens=
ion

> > that is intended for 1 proprietary tool.

>

> I dislike Randy's text since it essentially says you can ignore an=
y

> extensions such as nacm:default-deny-write - all you have to claim is<=
br>
> that your tool does not support it.



I think it *is* ok to ignore this statement for a server that doesn't
implement NACM.=C2=A0 I think Randy's text is fine.



+1

Here is a concrete example -- =
the 'secret' leaf in the ietf-system module:

This is tagged as "nacm:default-d=
eny-all".

Does this mean that if an implement=
ation supports the ietf-system "secret" leaf,
it MUST a=
lso include an implementation of NACM?

If yes, the=
n Juergen is right.
If no, then Randy's text is fine.

But read the definition of "default-deny-all" c=
arefully:

Note the line:

       If present, and the NACM module is enabled (i.e.,
       /nacm/enable-nacm object equals 'true'), 

Is=
 the NACM module "enabled" leaf set to true in a server that does=

not implement NACM at all?=C2=A0 I would say no.

Note also that the extension does not define any behavior outside
<=
div>of NACM processing.=C2=A0 It is not intended for every tool.
=
It is only intended for an implementation of NACM.
=C2=A0



/martin



Andy<=
/div>



--001a113fbd3c2f31f6052262c7a3--


From nobody Sun Oct 18 11:21:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DF11ACCFB for ; Sun, 18 Oct 2015 11:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWM1w-yR9P4j for ; Sun, 18 Oct 2015 11:21:23 -0700 (PDT)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA781ACCF9 for ; Sun, 18 Oct 2015 11:21:23 -0700 (PDT)
Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa09-05.prod.phx3.secureserver.net with  id WiMN1r0020FehNH01iMNRW; Sun, 18 Oct 2015 11:21:23 -0700
To: Ladislav Lhotka , netmod@ietf.org
References: <5621845D.6040100@seguesoft.com> <562184A1.6000802@seguesoft.com> 
From: Xiang Li 
Message-ID: <5623E318.7010609@seguesoft.com>
Date: Sun, 18 Oct 2015 13:21:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Fwd: Re: Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 18:21:25 -0000

On 10/18/2015 8:31 AM, Ladislav Lhotka wrote:
> Xiang Li  writes:
>
>> On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
>>>> On 16 Oct 2015, at 12:27, Balazs Lengyel  wrote:
>>>>
>>>> IMHO YANG should define the behavoir, and I would want it to be the same on Netconf/Restconf/CLI etc.
>>>> I agree that " 1) you get an error back" would be the best: because it is the easiest to understand for the operator, with the fewest corner cases.
>>>> Also we must define if in the same transaction we set b=42 and a=2. which of the 3 options are taken?
>>>>
>>>>
>>>> We should not leave such complex cases undefined, or alternatively state that they are implementation dependant.
>>> I might be difficult to say what is a complex case, unless we abandon XPath in "when" statements and use something else - and considerably simpler.
>>>
>>> Here is another interesting corner case - does it qualify as being complex?
>>>
>>> leaf-list bar {
>>>      type uint8;
>>>      when "count(../*) > 1";
>>> }
>>> leaf foo {
>>>      type uint8;
>>> }
>> Interesting example...
>>
>>> Assuming no instances exist, is this edit allowed? (This was essentially your question.)
>>>
>>> 1
>>> 2
>> I think this should succeed
>>
>>> But what about this?
>>>
>>> 1
>>> 2
>>>
>> I think this should succeed too because the when is satisfied in the
>> data store after the edit-config.
>>
> According to the third bullet in sec. 7.21.5 of 6020bis, a validating
> algorithm has to remove the existing "bar" instances, add a dummy
> instance and then evaluate the XPath expression. If the result is true,
> the existing "bar" instances will be put back, otherwise a validation
> error will be reported - so in our case we will have only one "bar" node,
> which is invalid.


Thanks  you are right. I missed that...

>
> The result of this change is that we (hopefully) made the processing of
> "when" well-defined and unambiguous, but the cost in increased comlexity
> is quite high - both for module readers and implementors of a validating
> algorithm.
yes the clarification in  sec. 7.21.5 of 6020bis   does make this clearer.

> In fact, when we discussed issue Y18, my understanding was that dummy
> node manipulations will be used only if the context node is missing.
This is something that actually still confuses me!  If a context node 
exists why we
still need to replace it with a dummy node, especially if an edit-config 
is performing a "merge" operation?

-Xiang Li



> Lada
>
>>
>> -Xiang Li
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Sun Oct 18 11:50:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6001ACDC8 for ; Sun, 18 Oct 2015 11:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfBI0MZ3Yikl for ; Sun, 18 Oct 2015 11:50:16 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5F1ACDC6 for ; Sun, 18 Oct 2015 11:50:15 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 515B91AE046C; Sun, 18 Oct 2015 20:50:14 +0200 (CEST)
Date: Sun, 18 Oct 2015 20:54:02 +0200 (CEST)
Message-Id: <20151018.205402.2291372281795457792.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151018125229.GA78907@elstar.local>
References: <20151018085331.GD78184@elstar.local> <20151018.141746.64718045791283540.mbj@tail-f.com> <20151018125229.GA78907@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 18:50:18 -0000

Juergen Schoenwaelder  wrote:
> On Sun, Oct 18, 2015 at 02:17:46PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote:
> > > > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > 
> > > > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote:
> > > > > > Hi -
> > > > > >
> > > > > > > From: Andy Bierman
> > > > > > > Sent: Oct 17, 2015 10:42 AM
> > > > > > ...
> > > > > > > Subject: Re: [netmod] 6020bis extensions
> > > > > > ...
> > > > > >
> > > > > > Andy Proposed:
> > > > > >
> > > > > > >    If a YANG parser does not support a particular extension, which
> > > > > > >    appears in a YANG module as an unknown-statement (see Section 14),
> > > > > > >    the entire unknown-statement MAY be ignored by the parser. Note that
> > > > > > >    this only applies to a generic YANG parser. A tool which is required
> > > > > > >    to implement the particular extension MUST NOT ignore such an
> > > > > > >    unknown-statement.
> > > > > >
> > > > > > I'd suggest a slightly different wording:
> > > > > >
> > > > > >   The processing of extensions depends on whether support for those
> > > > > >   extensions is claimed for a given YANG parser or the tool set in
> > > > > >   which it is embedded.  An unsupported extension, appearing in a
> > > > > >   YANG module as an unknown-statement (see Section 14) MAY be
> > > > > >   ignored in its entirety.  Any supported extension MUST be processed
> > > > > >   in accordance with the specification governing that extension.
> > > > > >
> > > > >
> > > > > I am not happy with either of these. It is important for me to state
> > > > > that the semantics associated with an extension statement apply,
> > > > > irrespective of the tool being used to implement a module. You can't
> > > > > simply ignore nacm:default-deny-write just because your tool skipped
> > > > > over this extension statement. So what about this:
> > > > >
> > > > >    If a tool does not support a particular extension, which appears in
> > > > >    a YANG module as an unknown-statement (see Section 14), the entire
> > > > >    unknown-statement MAY be ignored by the tool. Irrespective of this,
> > > > >    the semantics associated with an extension MUST be implemented
> > > > >    whenever an extension statement appears in a YANG module.
> > > > 
> > > > I like Randy's text.  I don't really think any text is needed,
> > > > because the differences between "conformance to YANG"
> > > > and "conformance to a module written in YANG" are quite clear to me.
> > > > There is no way that all tools have to support some vendor extension
> > > > that is intended for 1 proprietary tool.
> > > 
> > > I dislike Randy's text since it essentially says you can ignore any
> > > extensions such as nacm:default-deny-write - all you have to claim is
> > > that your tool does not support it.
> > 
> > I think it *is* ok to ignore this statement for a server that doesn't
> > implement NACM.  I think Randy's text is fine.
> 
> I disagree with the idea that extensions can be ignored arbitrarily
> just because a tool did skip over them. I thought we agreed that
> nacm:default-deny-write can't be ignored (if you implement NACM).
                                            ^^^^^^^^^^^^^^^^^^^^^

Absolutely!  It seems we agree on the idea, but not the words to
describe this.

> I actually think it is up to the extension to define when and how it
> applies. The definition of nacm:default-deny-write actually does say
> when it applies.

Agreed.


/martin




> I could copy the text of the nacm:default-deny-write description
> verbatim into the description of every object marked with
> nacm:default-deny-write. Using an extension is just a shorthand for
> this (with the added bonus that it is machine readable for tools). I
> do not think such an extension can be arbitrarily ignored just because
> a certain tool skipped over it.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 


From nobody Sun Oct 18 14:23:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353F11AD10A for ; Sun, 18 Oct 2015 14:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZwXSm-FXV5_o for ; Sun, 18 Oct 2015 14:23:04 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id DAF141ACE80 for ; Sun, 18 Oct 2015 14:23:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aCPpU6jgXdutz2bXwnZ0GemNqAIAS7gbpDJvjM5d9+IsoqEn4blWQvf1U88UTfyw; 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.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZnvPt-0006kF-GS for netmod@ietf.org; Sun, 18 Oct 2015 17:22:57 -0400
Received: from 76.254.51.102 by webmail.earthlink.net with HTTP; Sun, 18 Oct 2015 17:22:57 -0400
Message-ID: <9351762.1445203377352.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
Date: Sun, 18 Oct 2015 14:22:57 -0700 (GMT-07:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ede239117c0628b9d2009c1b8aad9dd4b3350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.45
Archived-At: 
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Oct 2015 21:23:05 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Oct 18, 2015 5:52 AM
>To: Martin Bjorklund 
>Cc: andy@yumaworks.com, randy_presuhn@mindspring.com, netmod@ietf.org
>Subject: Re: [netmod] 6020bis extensions
...
>I could copy the text of the nacm:default-deny-write description
>verbatim into the description of every object marked with
>nacm:default-deny-write. Using an extension is just a shorthand for
>this (with the added bonus that it is machine readable for tools). I
>do not think such an extension can be arbitrarily ignored just because
>a certain tool skipped over it.

I think there is a slight flaw in this line of reasoning.
For a *parser* to ignore an extension it does not claim to support
is really no different from that tool skipping over description text
specifying equivalent semantics.  If a tool supported NACM,
I doubt that there'd be any realistic expectation that it would
be able to reach into description text to determine whether the
natural-language specification said anything NACM-relevant,
even though of course we'd expect a model implementation to
abide by whatever constraints were thereby introduced.

*Parser* conformance and *model* implementation conformance
are distinct things, and we should not confuse them.

Randy


From nobody Sun Oct 18 20:13:34 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6778B1A01C6 for ; Sun, 18 Oct 2015 20:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPRioYiNJ3Zu for ; Sun, 18 Oct 2015 20:13:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0231A01D6 for ; Sun, 18 Oct 2015 20:13:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYY76748; Mon, 19 Oct 2015 03:13:13 +0000 (GMT)
Received: from SZXEMI412-HUB.china.huawei.com (10.86.210.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 04:13:12 +0100
Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.125]) by szxemi412-hub.china.huawei.com ([10.86.210.35]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 11:13:06 +0800
From: "fengchong (C)" 
To: "netmod@ietf.org" 
Thread-Topic: I suggest add 'abstract' statement as 'identity''s sub statement
Thread-Index: AdEKHAhanXzF1hDuRWSg3K/DehzxXQ==
Date: Mon, 19 Oct 2015 03:13:06 +0000
Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.40.226]
Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D08264E0SZXEMI506MBSchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] I suggest add 'abstract' statement as 'identity''s sub statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 03:13:32 -0000

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

Hi all,

    I notice an identity named 'interface-type' was defined in RFC 7223 (
A YANG Data Model for Interface Management). This identity is an abstract i=
dentity, vendors can define their real
Identity based it. But it's lack of a means to identify this identity 'inte=
rface-type' is abstract, so 'interface-type' can be accepted as
valid value of the leaf based this identity.
   So I suggest add 'abstract' statement as 'identity's sub statement in YA=
NG1.1. This statement is optional, default value is false.
If abstract identity is defined, 'abstract true' MUST be defined, and this =
identity's name cannot be accepted as valid value of the leaf
based this identity .
For example:

     identity interface-type {

       abstract true;

       description

         "Base identity from which specific interface types are

          derived.";

     }

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











Hi all,


  &nb=
sp; I notice an identity named ‘interface-type’ was defined in =
RFC 7223 (



A YANG Data Model for Interface Management). This identity is an abstract identity, vendors ca=
n define their real



Identity based it. But it’s lack of a means to i=
dentify this identity ‘interface-type’ is abstract, so ‘i=
nterface-type’ can be accepted as



valid value of the leaf based this identity.



   So I suggest add ‘abstract’ s=
tatement as ‘identity’s sub statement in YANG1.1. This statemen=
t is optional, default value is false.




If abstract identity is defined, ‘abstract true&=
#8217; MUST be defined, and this identity’s name cannot be accepted a=
s valid value of the leaf



based this identity .



For example:


     identity interface-type {=



       abstract true=
;


       description


         &=
quot;Base identity from which specific interface types are


        &n=
bsp; derived.";


     }










--_000_5756FB984666AD4BB8E1D63E2E3AA3D08264E0SZXEMI506MBSchina_--


From nobody Sun Oct 18 20:27:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113A61A0235 for ; Sun, 18 Oct 2015 20:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cVSPpXmQaYr for ; Sun, 18 Oct 2015 20:27:33 -0700 (PDT)
Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CE21A020D for ; Sun, 18 Oct 2015 20:27:33 -0700 (PDT)
Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa11-07.prod.phx3.secureserver.net with  id WrTW1r0050FehNH01rTXsM; Sun, 18 Oct 2015 20:27:33 -0700
To: netmod@ietf.org
References: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com>
From: Xiang Li 
Message-ID: <56246319.6050505@seguesoft.com>
Date: Sun, 18 Oct 2015 22:27:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------090606030108030207030503"
Archived-At: 
Subject: Re: [netmod] I suggest add 'abstract' statement as 'identity''s sub statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 03:27:35 -0000

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

On 10/18/2015 10:13 PM, fengchong (C) wrote:
>
> Hi all,
>
>     I notice an identity named ‘interface-type’ was defined in RFC 7223 (**
>
> *A YANG Data Model for Interface Management*). This identity is an 
> abstract identity, vendors can define their real
>
> Identity based it. But it’s lack of a means to identify this identity 
> ‘interface-type’ is abstract, so ‘interface-type’ can be accepted as
>
> valid value of the leaf based this identity.
>

You can use the fact this identity does not have a "base":

rfc6030: 7.16.2

If no "base" statement is present, the identity is defined from scratch.


However note an identity can also be defined based on another "derived" 
identity,
not just the identity defined from scratch!

-Xiang Li



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


  
    
  
  
    
On 10/18/2015 10:13 PM, fengchong (C)
      wrote:

    

    

      
      
      
      

        
Hi all,

        
    I notice an identity named ‘interface-type’ was defined in RFC 7223 (

        

          A
              YANG Data Model for Interface Management). This identity is an abstract identity,
            vendors can define their real

        

          Identity based it. But it’s lack of a means
            to identify this identity ‘interface-type’ is abstract, so
            ‘interface-type’ can be accepted as

        

          valid value of the leaf based this
            identity.

      

    

    

    You can use the fact this identity does not have a "base":

    

    rfc6030: 7.16.2

    
If no "base" statement is present, the identity is defined from scratch.

    

    However note an identity can also be defined based on another
    "derived" identity,

    not just the identity defined from scratch!

    

    -Xiang Li

    

    

  


--------------090606030108030207030503--


From nobody Sun Oct 18 20:36:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630ED1A02B1 for ; Sun, 18 Oct 2015 20:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FoPmWwoElKf for ; Sun, 18 Oct 2015 20:35:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4775E1A02AB for ; Sun, 18 Oct 2015 20:35:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCS22474; Mon, 19 Oct 2015 03:35:55 +0000 (GMT)
Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 04:35:51 +0100
Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.125]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 11:32:55 +0800
From: "fengchong (C)" 
To: Xiang Li , "netmod@ietf.org" 
Thread-Topic: [netmod] I suggest add 'abstract' statement as 'identity''s sub statement
Thread-Index: AdEKHAhanXzF1hDuRWSg3K/DehzxXf//ffOA//95stA=
Date: Mon, 19 Oct 2015 03:32:54 +0000
Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D08264FF@SZXEMI506-MBS.china.huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com> <56246319.6050505@seguesoft.com>
In-Reply-To: <56246319.6050505@seguesoft.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.40.226]
Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D08264FFSZXEMI506MBSchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] =?gb2312?b?tPC4tDogIEkgc3VnZ2VzdCBhZGQgJ2Fic3RyYWN0JyBz?= =?gb2312?b?dGF0ZW1lbnQgYXMgJ2lkZW50aXR5JydzIHN1YiBzdGF0ZW1lbnQ=?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 03:35:59 -0000

--_000_5756FB984666AD4BB8E1D63E2E3AA3D08264FFSZXEMI506MBSchina_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

RG8geW91IG1lYW4gYW4gaWRlbnRpdHkgd2l0aCBubyChrmJhc2WhryBpcyBhYnN0cmFjdCBpZGVu
dGl0eT8NCg0KSXShr3Mgbm90IGRlZmluZWQgaW4gUkZDIDYwMjAuIEluIHNvbWUgY2FzZXMsIGFu
IGlkZW50aXR5IHdpdGhvdXQgoa5iYXNloa8gbWlnaHQgbWFrZSBzZW5zZS4NCg0Kt6K8/sjLOiBu
ZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBYaWFuZyBMaQ0Kt6LL
zcqxvOQ6IDIwMTXE6jEw1MIxOcjVIDExOjI3DQrK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZw0K1vfM
4jogUmU6IFtuZXRtb2RdIEkgc3VnZ2VzdCBhZGQgJ2Fic3RyYWN0JyBzdGF0ZW1lbnQgYXMgJ2lk
ZW50aXR5JydzIHN1YiBzdGF0ZW1lbnQNCg0KT24gMTAvMTgvMjAxNSAxMDoxMyBQTSwgZmVuZ2No
b25nIChDKSB3cm90ZToNCkhpIGFsbCwNCg0KICAgIEkgbm90aWNlIGFuIGlkZW50aXR5IG5hbWVk
IKGuaW50ZXJmYWNlLXR5cGWhryB3YXMgZGVmaW5lZCBpbiBSRkMgNzIyMyAoDQpBIFlBTkcgRGF0
YSBNb2RlbCBmb3IgSW50ZXJmYWNlIE1hbmFnZW1lbnQpLiBUaGlzIGlkZW50aXR5IGlzIGFuIGFi
c3RyYWN0IGlkZW50aXR5LCB2ZW5kb3JzIGNhbiBkZWZpbmUgdGhlaXIgcmVhbA0KSWRlbnRpdHkg
YmFzZWQgaXQuIEJ1dCBpdKGvcyBsYWNrIG9mIGEgbWVhbnMgdG8gaWRlbnRpZnkgdGhpcyBpZGVu
dGl0eSChrmludGVyZmFjZS10eXBloa8gaXMgYWJzdHJhY3QsIHNvIKGuaW50ZXJmYWNlLXR5cGWh
ryBjYW4gYmUgYWNjZXB0ZWQgYXMNCnZhbGlkIHZhbHVlIG9mIHRoZSBsZWFmIGJhc2VkIHRoaXMg
aWRlbnRpdHkuDQoNCllvdSBjYW4gdXNlIHRoZSBmYWN0IHRoaXMgaWRlbnRpdHkgZG9lcyBub3Qg
aGF2ZSBhICJiYXNlIjoNCg0KcmZjNjAzMDogNy4xNi4yDQoNCg0KSWYgbm8gImJhc2UiIHN0YXRl
bWVudCBpcyBwcmVzZW50LCB0aGUgaWRlbnRpdHkgaXMgZGVmaW5lZCBmcm9tIHNjcmF0Y2guDQoN
Ckhvd2V2ZXIgbm90ZSBhbiBpZGVudGl0eSBjYW4gYWxzbyBiZSBkZWZpbmVkIGJhc2VkIG9uIGFu
b3RoZXIgImRlcml2ZWQiIGlkZW50aXR5LA0Kbm90IGp1c3QgdGhlIGlkZW50aXR5IGRlZmluZWQg
ZnJvbSBzY3JhdGNoIQ0KDQotWGlhbmcgTGkNCg0K

--_000_5756FB984666AD4BB8E1D63E2E3AA3D08264FFSZXEMI506MBSchina_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Do you =
mean an identity with no =A1=AEbase=A1=AF is abstract identity?



&n=
bsp;


It=A1=
=AFs not defined in RFC 6020. In some cases, an identity without =A1=AEbase=
=A1=AF might make sense.


&n=
bsp;






=B7=A2=
=BC=FE=C8=CB: netmod =
[mailto:netmod-bounces@ietf.org]
=B4=FA=B1=ED 
Xiang Li

=B7=A2=CB=CD=CA=B1=BC=E4:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo=
r:windowtext"> 2015=C4=EA10=D4=C219=C8=D5
 11:27

=CA=D5=BC=FE=C8=CB: netmod@ietf.org

=D6=F7=CC=E2: Re: [netmod] I suggest add 'abstract' statement as 'identity''s sub state=
ment






 




On 10/18/2015 10:13 PM, fengcho=
ng (C) wrote:






Hi all,


  &nb=
sp; I notice an identity named =A1=AEinterface-=
type=A1=AF was defined in RFC 7223 (=




A YANG Data Model for In=
terface Management). This identity is an ab=
stract identity, vendors can define their real



Identity based it. But it=A1=AFs lack of a means to id=
entify this identity =A1=AEinterface-type=A1=AF is abstract, so =A1=AEinter=
face-type=A1=AF can be accepted as



valid value of the leaf based this identity.






You can use the fact this identity does not have a "base":



rfc6030: 7.16.2






If no "base" statement is present, the identity is d=
efined from scratch.




However note an identity can also be defined based on another "derived=
" identity,

not just the identity defined from scratch!



-Xiang Li










--_000_5756FB984666AD4BB8E1D63E2E3AA3D08264FFSZXEMI506MBSchina_--


From nobody Sun Oct 18 20:37:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED381A02AB for ; Sun, 18 Oct 2015 20:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 uNbCkE9_WB8u for ; Sun, 18 Oct 2015 20:37:34 -0700 (PDT)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4412D1A0266 for ; Sun, 18 Oct 2015 20:37:34 -0700 (PDT)
Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa07-03.prod.phx3.secureserver.net with  id WrdZ1r0020FehNH01rdZtv; Sun, 18 Oct 2015 20:37:33 -0700
To: "fengchong (C)" , "netmod@ietf.org" 
References: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com> <56246319.6050505@seguesoft.com> <5756FB984666AD4BB8E1D63E2E3AA3D08264FF@SZXEMI506-MBS.china.huawei.com>
From: Xiang Li 
Message-ID: <56246574.602@seguesoft.com>
Date: Sun, 18 Oct 2015 22:37:24 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D08264FF@SZXEMI506-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------020501050608050502060603"
Archived-At: 
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiAgSSBzdWdnZXN0IGFkZCAnYWJzdHJhY3Qn?= =?utf-8?q?_statement_as_=27identity=27=27s_sub_statement?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 03:37:35 -0000

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

On 10/18/2015 10:32 PM, fengchong (C) wrote:
>
> Do you mean an identity with no â€base’ is abstract identity?
>

Not exactly. Note any identity is said to be defined as "abstract", 
"unique", and "untyped". See rfc6020 7.16:


      7.16 . The
      identity Statement



    The "identity" statement is used to define a new globally unique,
    abstract, and untyped identity.  Its only purpose is to denote its
    name, semantics, and existence.  An identity can either be defined
    from scratch or derived from a base identity.


> It’s not defined in RFC 6020. In some cases, an identity without 
> â€base’ might make sense.
>

RFC6020 does define this.


        7.16.2 . The
        base Statement



    The "base" statement, which is optional, takes as an argument a
    string that is the name of an existing identity, from which the new
    identity is derived.  If no "base" statement is present, the identity
    is defined from scratch.


-Xiang Li


> *发件人:*netmod [mailto:netmod-bounces@ietf.org] *代表 *Xiang Li
> *发é€ć—¶é—´:*2015ĺą´10ćś19ć—Ą11:27
> *收件人:*netmod@ietf.org
> *主é˘:*Re: [netmod] I suggest add 'abstract' statement as 'identity''s 
> sub statement
>
> On 10/18/2015 10:13 PM, fengchong (C) wrote:
>
>     Hi all,
>
>         I notice an identity named â€interface-type’was defined in RFC 7223 (
>
>     *A YANG Data Model for Interface Management*). This identity is an
>     abstract identity, vendors can define their real
>
>     Identity based it. But it’s lack of a means to identify this
>     identity â€interface-type’ is abstract, so â€interface-type’ can be
>     accepted as
>
>     valid value of the leaf based this identity.
>
>
> You can use the fact this identity does not have a "base":
>
> rfc6030: 7.16.2
>
> If no "base" statement is present, the identity is defined from scratch.
>
>
> However note an identity can also be defined based on another 
> "derived" identity,
> not just the identity defined from scratch!
>
> -Xiang Li
>

--------------020501050608050502060603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/18/2015 10:32 PM, fengchong (C)
      wrote:

    

    

      
      
      
      

        
Do
            you mean an identity with no â€base’ is abstract identity?
          

      

    

    

    Not exactly. Note any identity is said to be defined as "abstract",
    "unique", and "untyped". See rfc6020 7.16:

    

    
7.16.  The identity Statement


   The "identity" statement is used to define a new globally unique,
   abstract, and untyped identity.  Its only purpose is to denote its
   name, semantics, and existence.  An identity can either be defined
   from scratch or derived from a base identity.

    

    

      

        

        
 

        
It’s
            not defined in RFC 6020. In some cases, an identity without
            â€base’ might make sense.

      

    

    

    RFC6020 does define this. 

    

    

7.16.2.  The base Statement


   The "base" statement, which is optional, takes as an argument a
   string that is the name of an existing identity, from which the new
   identity is derived.  If no "base" statement is present, the identity
   is defined from scratch.


-Xiang Li


    

    

      

        

        
 

        

          

            
发件人:
                netmod [mailto:netmod-bounces@ietf.org]
              代表 
              Xiang Li

              发é€ć—¶é—´:
                2015ĺą´10ćś19ć—Ą 11:27

                收件人: netmod@ietf.org

                主é˘: Re: [netmod] I suggest add 'abstract'
                  statement as 'identity''s sub statement

          

        

        
 

        

          
On 10/18/2015 10:13
              PM, fengchong (C) wrote:

        

        

          
Hi all,

          
    I notice an identity named â€interface-type’ was defined in RFC 7223 (

          

            A YANG Data
                Model for Interface Management). This identity is an abstract identity,
              vendors can define their real

          

            Identity based it. But it’s lack of a
              means to identify this identity â€interface-type’ is
              abstract, so â€interface-type’ can be accepted as

          

            valid value of the leaf based this
              identity.

        

        


            You can use the fact this identity does not have a "base":

            

            rfc6030: 7.16.2

            

            

        
If no "base" statement is present, the identity is defined from scratch.

        


            However note an identity can also be defined based on
            another "derived" identity,

            not just the identity defined from scratch!

            

            -Xiang Li

            

            

      

    

  


--------------020501050608050502060603--


From nobody Sun Oct 18 22:41:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABBF1A1B91 for ; Sun, 18 Oct 2015 22:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dceLjWD6o3TG for ; Sun, 18 Oct 2015 22:41:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487E51A1B8F for ; Sun, 18 Oct 2015 22:41:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCS31253; Mon, 19 Oct 2015 05:41:16 +0000 (GMT)
Received: from SZXEMI403-HUB.china.huawei.com (10.82.75.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 06:40:32 +0100
Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.125]) by SZXEMI403-HUB.china.huawei.com ([10.83.65.55]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 13:40:25 +0800
From: "fengchong (C)" 
To: Xiang Li , "netmod@ietf.org" 
Thread-Topic: =?utf-8?B?562U5aSNOiBbbmV0bW9kXSBJIHN1Z2dlc3QgYWRkICdhYnN0cmFjdCcgc3Rh?= =?utf-8?Q?tement_as_'identity''s_sub_statement?=
Thread-Index: AdEKHAhanXzF1hDuRWSg3K/DehzxXf//ffOA//95stCAAIkdAP//WQdQ
Date: Mon, 19 Oct 2015 05:40:25 +0000
Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D0826516@SZXEMI506-MBS.china.huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com> <56246319.6050505@seguesoft.com> <5756FB984666AD4BB8E1D63E2E3AA3D08264FF@SZXEMI506-MBS.china.huawei.com> <56246574.602@seguesoft.com>
In-Reply-To: <56246574.602@seguesoft.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.40.226]
Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D0826516SZXEMI506MBSchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJIHN1Z2dlc3QgYWRkICdh?= =?utf-8?q?bstract=27_statement_as_=27identity=27=27s_sub_statement?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 05:41:22 -0000

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

Tm8uICBUaGUg4oCYYWJzdHJhY3TigJkgZGVmaW5lZCBpbiBSRkM2MDIwIGlzIG5vdCB0aGUgc2Ft
ZSBtZWFuaW5nIHdpdGggbXkg4oCYYWJzdHJhY3TigJkuDQoNCk15IGFic3RyYWN0IGlkZW50aXR5
IG1lYW5zIGl0cyBuYW1lIGlzIG5vdCBhIHZhbGlkIHZhbHVlIG9mIHRoZSBsZWFmIGJhc2VkIHRo
aXMgaWRlbnRpdHkuDQoNCuWPkeS7tuS6ujogWGlhbmcgTGkgW21haWx0bzp4aWFuZ2xpQHNlZ3Vl
c29mdC5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMOaciDE55pelIDExOjM3DQrmlLbku7bk
uro6IGZlbmdjaG9uZyAoQyk7IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBSZTog562U5aSNOiBb
bmV0bW9kXSBJIHN1Z2dlc3QgYWRkICdhYnN0cmFjdCcgc3RhdGVtZW50IGFzICdpZGVudGl0eScn
cyBzdWIgc3RhdGVtZW50DQoNCk9uIDEwLzE4LzIwMTUgMTA6MzIgUE0sIGZlbmdjaG9uZyAoQykg
d3JvdGU6DQpEbyB5b3UgbWVhbiBhbiBpZGVudGl0eSB3aXRoIG5vIOKAmGJhc2XigJkgaXMgYWJz
dHJhY3QgaWRlbnRpdHk/DQoNCk5vdCBleGFjdGx5LiBOb3RlIGFueSBpZGVudGl0eSBpcyBzYWlk
IHRvIGJlIGRlZmluZWQgYXMgImFic3RyYWN0IiwgInVuaXF1ZSIsIGFuZCAidW50eXBlZCIuIFNl
ZSByZmM2MDIwIDcuMTY6DQoNCg0KNy4xNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj
NjAyMCNzZWN0aW9uLTcuMTY+LiAgVGhlIGlkZW50aXR5IFN0YXRlbWVudA0KDQoNCg0KDQoNCiAg
IFRoZSAiaWRlbnRpdHkiIHN0YXRlbWVudCBpcyB1c2VkIHRvIGRlZmluZSBhIG5ldyBnbG9iYWxs
eSB1bmlxdWUsDQoNCiAgIGFic3RyYWN0LCBhbmQgdW50eXBlZCBpZGVudGl0eS4gIEl0cyBvbmx5
IHB1cnBvc2UgaXMgdG8gZGVub3RlIGl0cw0KDQogICBuYW1lLCBzZW1hbnRpY3MsIGFuZCBleGlz
dGVuY2UuICBBbiBpZGVudGl0eSBjYW4gZWl0aGVyIGJlIGRlZmluZWQNCg0KICAgZnJvbSBzY3Jh
dGNoIG9yIGRlcml2ZWQgZnJvbSBhIGJhc2UgaWRlbnRpdHkuDQoNCg0KDQpJdOKAmXMgbm90IGRl
ZmluZWQgaW4gUkZDIDYwMjAuIEluIHNvbWUgY2FzZXMsIGFuIGlkZW50aXR5IHdpdGhvdXQg4oCY
YmFzZeKAmSBtaWdodCBtYWtlIHNlbnNlLg0KDQpSRkM2MDIwIGRvZXMgZGVmaW5lIHRoaXMuDQoN
Cg0KPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDIwI3NlY3Rpb24tNy4xNi4yPg0K
Ny4xNi4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDIwI3NlY3Rpb24tNy4xNi4y
Pi4gIFRoZSBiYXNlIFN0YXRlbWVudA0KDQoNCg0KDQoNCiAgIFRoZSAiYmFzZSIgc3RhdGVtZW50
LCB3aGljaCBpcyBvcHRpb25hbCwgdGFrZXMgYXMgYW4gYXJndW1lbnQgYQ0KDQogICBzdHJpbmcg
dGhhdCBpcyB0aGUgbmFtZSBvZiBhbiBleGlzdGluZyBpZGVudGl0eSwgZnJvbSB3aGljaCB0aGUg
bmV3DQoNCiAgIGlkZW50aXR5IGlzIGRlcml2ZWQuICBJZiBubyAiYmFzZSIgc3RhdGVtZW50IGlz
IHByZXNlbnQsIHRoZSBpZGVudGl0eQ0KDQogICBpcyBkZWZpbmVkIGZyb20gc2NyYXRjaC4NCg0K
DQoNCg0KDQotWGlhbmcgTGkNCg0KDQoNCuWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBYaWFuZyBMaQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0
MTDmnIgxOeaXpSAxMToyNw0K5pS25Lu25Lq6OiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtuZXRtb2RdIEkgc3VnZ2VzdCBhZGQgJ2Fic3RyYWN0
JyBzdGF0ZW1lbnQgYXMgJ2lkZW50aXR5JydzIHN1YiBzdGF0ZW1lbnQNCg0KT24gMTAvMTgvMjAx
NSAxMDoxMyBQTSwgZmVuZ2Nob25nIChDKSB3cm90ZToNCkhpIGFsbCwNCg0KICAgIEkgbm90aWNl
IGFuIGlkZW50aXR5IG5hbWVkIOKAmGludGVyZmFjZS10eXBl4oCZIHdhcyBkZWZpbmVkIGluIFJG
QyA3MjIzICgNCkEgWUFORyBEYXRhIE1vZGVsIGZvciBJbnRlcmZhY2UgTWFuYWdlbWVudCkuIFRo
aXMgaWRlbnRpdHkgaXMgYW4gYWJzdHJhY3QgaWRlbnRpdHksIHZlbmRvcnMgY2FuIGRlZmluZSB0
aGVpciByZWFsDQpJZGVudGl0eSBiYXNlZCBpdC4gQnV0IGl04oCZcyBsYWNrIG9mIGEgbWVhbnMg
dG8gaWRlbnRpZnkgdGhpcyBpZGVudGl0eSDigJhpbnRlcmZhY2UtdHlwZeKAmSBpcyBhYnN0cmFj
dCwgc28g4oCYaW50ZXJmYWNlLXR5cGXigJkgY2FuIGJlIGFjY2VwdGVkIGFzDQp2YWxpZCB2YWx1
ZSBvZiB0aGUgbGVhZiBiYXNlZCB0aGlzIGlkZW50aXR5Lg0KDQpZb3UgY2FuIHVzZSB0aGUgZmFj
dCB0aGlzIGlkZW50aXR5IGRvZXMgbm90IGhhdmUgYSAiYmFzZSI6DQoNCnJmYzYwMzA6IDcuMTYu
Mg0KDQoNCg0KSWYgbm8gImJhc2UiIHN0YXRlbWVudCBpcyBwcmVzZW50LCB0aGUgaWRlbnRpdHkg
aXMgZGVmaW5lZCBmcm9tIHNjcmF0Y2guDQoNCkhvd2V2ZXIgbm90ZSBhbiBpZGVudGl0eSBjYW4g
YWxzbyBiZSBkZWZpbmVkIGJhc2VkIG9uIGFub3RoZXIgImRlcml2ZWQiIGlkZW50aXR5LA0Kbm90
IGp1c3QgdGhlIGlkZW50aXR5IGRlZmluZWQgZnJvbSBzY3JhdGNoIQ0KDQotWGlhbmcgTGkNCg0K
DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0
aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KaDENCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAxIENoYXIiOw0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToyNC4wcHQ7DQoJZm9udC1mYW1p
bHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0K
CW1zby1zdHlsZS1saW5rOiLmoIfpopggMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt
bGluazoi5qCH6aKYIDQgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6Ymxh
Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg
c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7
DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBs
aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5
OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLjFDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiLmoIfpopggMSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5
bGUtbGluazoi5qCH6aKYIDEiOw0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCglmb250LXdlaWdodDpi
b2xkO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byP
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDp
ooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5oMQ0KCXttc28tc3R5bGUtbmFtZTpo
MTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5o
Mw0KCXttc28tc3R5bGUtbmFtZTpoMzt9DQpzcGFuLjNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiLm
oIfpopggMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi
5qCH6aKYIDMiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
YmxhY2s7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLmg0DQoJe21zby1zdHlsZS1uYW1lOmg0
O30NCnNwYW4uNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iuagh+mimCA0IENoYXIiOw0KCW1zby1z
dHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLmoIfpopggNCI7DQoJZm9udC1mYW1p
bHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9
DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh
bi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3
Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgt
Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+Tm8uJm5ic3A7IFRoZSDigJhhYnN0cmFjdOKAmSBkZWZpbmVkIGluIFJGQzYwMjAg
aXMgbm90IHRoZSBzYW1lIG1lYW5pbmcgd2l0aCBteSDigJhhYnN0cmFjdOKAmS4NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5N
eSBhYnN0cmFjdCBpZGVudGl0eSBtZWFucyBpdHMgbmFtZSBpcyBub3QgYSB2YWxpZCB2YWx1ZSBv
ZiB0aGUgbGVhZiBiYXNlZCB0aGlzIGlkZW50aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h
bGlnbjpsZWZ0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrl
rovkvZM7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw
YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPiBYaWFuZyBMaSBbbWFpbHRvOnhp
YW5nbGlAc2VndWVzb2Z0LmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe2
6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRv
d3RleHQiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3Nw
YW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE5PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4N
CiAxMTozNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh
bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBmZW5nY2hvbmcgKEMpOyBuZXRtb2RAaWV0Zi5vcmc8
YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIj4gUmU6IDwvc3Bhbj7nrZTlpI08c3BhbiBsYW5nPSJFTi1VUyI+OiBbbmV0
bW9kXSBJIHN1Z2dlc3QgYWRkICdhYnN0cmFjdCcgc3RhdGVtZW50IGFzICdpZGVudGl0eScncyBz
dWIgc3RhdGVtZW50PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gMTAvMTgvMjAxNSAx
MDozMiBQTSwgZmVuZ2Nob25nIChDKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj5EbyB5b3UgbWVhbiBhbiBpZGVudGl0eSB3aXRoIG5vIOKAmGJhc2XigJkgaXMg
YWJzdHJhY3QgaWRlbnRpdHk/DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs
ZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQpOb3QgZXhhY3RseS4gTm90
ZSBhbnkgaWRlbnRpdHkgaXMgc2FpZCB0byBiZSBkZWZpbmVkIGFzICZxdW90O2Fic3RyYWN0JnF1
b3Q7LCAmcXVvdDt1bmlxdWUmcXVvdDssIGFuZCAmcXVvdDt1bnR5cGVkJnF1b3Q7LiBTZWUgcmZj
NjAyMCA3LjE2Ojxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxoMyBz
dHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48
YSBuYW1lPSJzZWN0aW9uLTcuMTYiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNjAyMCNzZWN0aW9uLTcuMTYiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi
bGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ny4xNjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4uJm5ic3A7DQogVGhlIGlkZW50aXR5IFN0YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFu
PjwvaDM+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoZSAmcXVvdDtp
ZGVudGl0eSZxdW90OyBzdGF0ZW1lbnQgaXMgdXNlZCB0byBkZWZpbmUgYSBuZXcgZ2xvYmFsbHkg
dW5pcXVlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i
ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PiZuYnNwOyZuYnNwOyBhYnN0cmFjdCwgYW5kIHVudHlwZWQgaWRlbnRpdHkuJm5ic3A7IEl0cyBv
bmx5IHB1cnBvc2UgaXMgdG8gZGVub3RlIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBuYW1lLCBzZW1hbnRpY3MsIGFuZCBl
eGlzdGVuY2UuJm5ic3A7IEFuIGlkZW50aXR5IGNhbiBlaXRoZXIgYmUgZGVmaW5lZDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBm
cm9tIHNjcmF0Y2ggb3IgZGVyaXZlZCBmcm9tIGEgYmFzZSBpZGVudGl0eS48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4
dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj5JdOKAmXMgbm90IGRlZmluZWQgaW4gUkZDIDYwMjAuIEluIHNvbWUgY2FzZXMsIGFu
IGlkZW50aXR5IHdpdGhvdXQg4oCYYmFzZeKAmSBtaWdodCBtYWtlIHNlbnNlLjwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxicj4NClJGQzYw
MjAgZG9lcyBkZWZpbmUgdGhpcy4gPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPGg0IHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJlZm9y
ZTphbHdheXMiPjxhIG5hbWU9InNlY3Rpb24tNy4xNi4yIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL3JmYzYwMjAjc2VjdGlvbi03LjE2LjIiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+PG86cD48L286cD48L3Nw
YW4+PC9hPjwvaDQ+DQo8aDQgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0O3BhZ2UtYnJl
YWstYmVmb3JlOmFsd2F5cyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzYwMjAjc2VjdGlvbi03LjE2LjIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazt0
ZXh0LWRlY29yYXRpb246bm9uZSI+Ny4xNi4yPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPi4mbmJzcDsNCiBUaGUgYmFzZSBTdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L2g0Pg0K
PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7YmFzZSZxdW90
OyBzdGF0ZW1lbnQsIHdoaWNoIGlzIG9wdGlvbmFsLCB0YWtlcyBhcyBhbiBhcmd1bWVudCBhPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh
eXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5i
c3A7IHN0cmluZyB0aGF0IGlzIHRoZSBuYW1lIG9mIGFuIGV4aXN0aW5nIGlkZW50aXR5LCBmcm9t
IHdoaWNoIHRoZSBuZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut
YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij4mbmJzcDsmbmJzcDsgaWRlbnRpdHkgaXMgZGVyaXZlZC4mbmJzcDsgSWYgbm8gJnF1
b3Q7YmFzZSZxdW90OyBzdGF0ZW1lbnQgaXMgcHJlc2VudCwgdGhlIGlkZW50aXR5PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGlz
IGRlZmluZWQgZnJvbSBzY3JhdGNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPi1YaWFuZyBMaTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMi
Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl
PSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0
Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Y29sb3I6d2luZG93dGV4dCI+DQogbmV0bW9kIFs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9y
OndpbmRvd3RleHQiPuS7o+ihqDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5YaWFuZyBMaTxicj4NCjwv
c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7
Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+Ojwvc3Bhbj48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRv
d3RleHQiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPjEwPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0
ZXh0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2NvbG9yOndpbmRvd3RleHQiPjE5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7ml6U8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPg0KIDEx
OjI3PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij46
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s
b3I6d2luZG93dGV4dCI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RA
aWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7kuLvpopg8L3NwYW4+PC9iPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0
ZXh0Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBbbmV0bW9kXSBJIHN1Z2dlc3QgYWRkICdhYnN0cmFj
dCcNCiBzdGF0ZW1lbnQgYXMgJ2lkZW50aXR5JydzIHN1YiBzdGF0ZW1lbnQ8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gMTAvMTgvMjAxNSAxMDoxMyBQ
TSwgZmVuZ2Nob25nIChDKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBJIG5vdGljZSBhbiBpZGVudGl0eSBuYW1l
ZCA8L3NwYW4+4oCYPHNwYW4gbGFuZz0iRU4tVVMiPmludGVyZmFjZS10eXBlPC9zcGFuPuKAmTxz
cGFuIGxhbmc9IkVOLVVTIj4gd2FzIGRlZmluZWQgaW4gUkZDIDcyMjMgKDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu
OmxlZnQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BIFlBTkcgRGF0YSBNb2RlbCBmb3IgSW50ZXJmYWNlIE1h
bmFnZW1lbnQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4pLiBUaGlzIGlkZW50aXR5IGlz
IGFuIGFic3RyYWN0IGlkZW50aXR5LCB2ZW5kb3JzIGNhbiBkZWZpbmUgdGhlaXIgcmVhbDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4
dC1hbGlnbjpsZWZ0O21zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT
Ij5JZGVudGl0eSBiYXNlZCBpdC4gQnV0IGl04oCZcyBsYWNrIG9mIGEgbWVhbnMgdG8gaWRlbnRp
ZnkgdGhpcyBpZGVudGl0eSDigJhpbnRlcmZhY2UtdHlwZeKAmSBpcyBhYnN0cmFjdCwgc28g4oCY
aW50ZXJmYWNlLXR5cGXigJkgY2FuIGJlIGFjY2VwdGVkIGFzPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNv
LWxpbmUtaGVpZ2h0LWFsdDowcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPnZhbGlkIHZhbHVlIG9m
IHRoZSBsZWFmIGJhc2VkIHRoaXMgaWRlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0
LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
PGJyPg0KWW91IGNhbiB1c2UgdGhlIGZhY3QgdGhpcyBpZGVudGl0eSBkb2VzIG5vdCBoYXZlIGEg
JnF1b3Q7YmFzZSZxdW90Ozo8YnI+DQo8YnI+DQpyZmM2MDMwOiA3LjE2LjI8YnI+DQo8YnI+DQo8
YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JZiBubyAmcXVvdDtiYXNlJnF1b3Q7IHN0YXRlbWVudCBp
cyBwcmVzZW50LCB0aGUgaWRlbnRpdHkgaXMgZGVmaW5lZCBmcm9tIHNjcmF0Y2guPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGln
bjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4N
Ckhvd2V2ZXIgbm90ZSBhbiBpZGVudGl0eSBjYW4gYWxzbyBiZSBkZWZpbmVkIGJhc2VkIG9uIGFu
b3RoZXIgJnF1b3Q7ZGVyaXZlZCZxdW90OyBpZGVudGl0eSw8YnI+DQpub3QganVzdCB0aGUgaWRl
bnRpdHkgZGVmaW5lZCBmcm9tIHNjcmF0Y2ghPGJyPg0KPGJyPg0KLVhpYW5nIExpPGJyPg0KPGJy
Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_5756FB984666AD4BB8E1D63E2E3AA3D0826516SZXEMI506MBSchina_--


From nobody Mon Oct 19 01:06:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA41C1A6FE3 for ; Mon, 19 Oct 2015 01:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2wOQVtE1cJm for ; Mon, 19 Oct 2015 01:06:17 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2E41A6FEA for ; Mon, 19 Oct 2015 01:06:16 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 08:06:14 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 08:06:14 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgCAAAiu5IAAGrQAgAP24QA=
Date: Mon, 19 Oct 2015 08:06:14 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com>  <562146F8.4020503@cisco.com>
In-Reply-To: <562146F8.4020503@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [95.113.185.113]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:+EjztemDt42CJNyGv42ARd2sZtxcTwOG5jK/OJHOUjjbhS7mrUjQzkfLmUN6PKFaQ9Mc/oLvMIAO9wFF/dZx8bQfezbZKosUY2bg9aWTtmoqatZDRie9sQrHx5n4s+w3hJRC8vUTmAXj+tLk6ahr6g==; 24:P1GVD/JmQoZDqPTQiYMRYWMQno+NWdOfoyqpv9+n5S5knwWsMQUZOfqP+iJpFW276dxH1089qhrIEsU5PePA5r6l/YsD7eH3ri73RK+MGLQ=; 20:fMOWChsR7bNYVP9dYNKmsJW7D03wb6URd8KNe4uIGZhiTC8BPT0ekZbgTMiXeJrmfH+0Xku8GQ7b/wcgNgy8EA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(479174004)(164054003)(24454002)(199003)(189002)(122556002)(64706001)(97736004)(66066001)(189998001)(101416001)(2900100001)(5004730100002)(5007970100001)(5008740100001)(40100003)(11100500001)(99286002)(2950100001)(81156007)(106116001)(92566002)(87936001)(106356001)(82746002)(54356999)(19580395003)(76176999)(19580405001)(5002640100001)(93886004)(15975445007)(102836002)(50986999)(105586002)(10400500002)(83716003)(110136002)(33656002)(5001960100002)(36756003)(46102003)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 08:06:14.0338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 08:06:19 -0000

Rob,

I think we are describing the same problem from a little different perspect=
ive:

Sent from my Apple ][

> On 16 Oct 2015, at 20:50, Robert Wilton  wrote:
>=20
> Hi Gert,
>=20
>> On 16/10/2015 18:14, Gert Grammel wrote:
>> Rob,
>>=20
>> Current implementations are incomplete asynchronous, because they didn't=
 verify the config as operational and applied.
>>=20
>> What is frequently done is to perform additional checks on the intended =
config that go beyond a syntax check. That is fine, but I have a hard time =
to consider this to be "hybrid" which suggests something in between asynchr=
onous and synchronous.
> I'm talking about netconf servers that effectively apply most of their co=
nfiguration before they reply.  E.g. they might take 10 minutes to reply.
>=20
Exactly, that's why those servers are running asynchronously. The trouble i=
s that in contrast to the synchronous operation there is no "done" informat=
ion. Current implementations often try to work around that point by applyin=
g more than just a syntax check in the first phase. This way they are still=
 quick in replying are more reliably responding, but still fail from time t=
o time

> Perhaps this isn't a valid Netconf implementation, and all Netconf server=
 implementations are expected to be asynchronous w.r.t to when they apply t=
heir configuration - but I can't see where this is stated in the NETCONF RF=
C (but possibly I'm not looking in the right place).
>=20
>=20
>>=20
>> >From a client perspective an asynchronous server and a hybrid server lo=
ok the same. The difference is that the asynchronous one should convey a "f=
inished" information to the client, while the hybrid would remain in a "tru=
st me babe" mode forever.
> Yes, but this isn't the only difference:
> - a client could expect that an asynchronous config operation response sh=
ould be reasonably expedient.
Agree, but this is true for hybrid and asynchronous and the term "reasonabl=
e" is not well defined.

>  E.g. if a client was to update 10 devices each with a reasonable size co=
nfiguration (that takes minutes to apply) in an asynchronous way then it mi=
ght reasonably consider sequencing the async config requests to each server=
 on one thread.  If each server acknowledged the requests in a couple of se=
conds then all the servers would broadly end up applying the configuration =
concurrently.
Yes, that's why we need asynchronous mode in the first place.
> - however, if the servers were hybrid, and their replies were sent much c=
loser to when the configuration was actually applied then initiating the re=
quests sequentially would effectively mean that the devices end up applying=
 the configuration serially which would end up taking much longer.  I.e. it=
 seems reasonable that a client may want to differentiate between the behav=
iour of these two servers even if how it handles the resultant config chang=
es is the same.

It seems your definition of hybrid is something like "asynchronous but with=
 a longer than reasonable response time".

This is similar to a bloated synchronous operation which takes too much tim=
e to respond.  Both cases are undesired and in both cases the solution is t=
o make them truly asynchronous. So that we can have a reasonable response t=
ime.=20

>>=20
>>=20
>> Another way to look at hybrids is to consider them "cheating synchronous=
". Given that the new config may not have been applied at the time of the r=
esponse to the client. This is worse than the situation before where a miss=
ing verify lets the client know that something may still go on. Clients can=
't tell if servers are cheating :-)
> Yes, but clients also need to be able to determine if the server is likel=
y to be slow to response, because then the client would probably be designe=
d to interact with the server in a different fashion (e.g. use a pool of th=
reads to initiate the updates concurrently).

How would you do this in practice? Even servers don't know if they're likel=
y to slow a response when they get a request. That's why a quick first resp=
onse is required that assures the client the requests will be processed, fo=
llowed by a potentially slow feedback that it is successfully executed (=3D=
verified) or failed.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Gert
>>=20
>>=20
>>=20
>> Sent from my Apple ][
>>=20
>>> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
>>>=20
>>>=20
>>>=20
>>>> On 16/10/2015 14:59, Kent Watsen wrote:
>>>>=20
>>>>>>>     3.  Support for both synchronous and asynchronous configuration
>>>>>>>         operations
>>>>>>>=20
>>>>>>>         A. A server may choose to support only synchronous
>>>>>>> configuration
>>>>>>>            operations, or only asynchronous configuration operation=
s,
>>>>>>> or
>>>>>>>            both synchronous and asynchronous configuration operatio=
ns
>>>>>>> in
>>>>>>>            a client specified per-operation basis.
>>>>>> I think the most common mode *today* is a mix of sync/async, on a
>>>>>> per-object basis.
>>>>> Yes, I agree.
>>>> Wait, I think we're talking about different things.  Martin, I'm sure =
that
>>>> internal to a NC/RC server, parts of the intended configuration is
>>>> actually applied synchronously (e.g., a hostname) whereas other parts =
are
>>>> not (e.g., config for data plane).   But that nuance is not currently
>>>> exposed in any way today -right?
>>> I think that today, from what a client sees/experiences, many replies f=
rom netconf servers fits neither the definition of "synchronous configurati=
on operation" nor "asynchronous configuration operation", but instead, the =
reply is somewhere between the two extremes.
>>>=20
>>> So the question I was trying to raise is whether servers that need to m=
eet the opstate requirements have to change to strictly comply with the def=
ined async or sync config operation semantics?  E.g. not just adding a "don=
e-applying" option, but perhaps also adding something along the lines of a =
"done-verifying" option.
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>> What we're talking about here is an ability for a client to request a
>>>> protocol operation (PATCH) to block, or for the "done-applying"
>>>> notification to not be sent, until all that processing of the request =
is
>>>> complete.  This regardless if the request contains a mix of nodes that=
 are
>>>> applied internally sync/async.  Makes sense? - or it is something else=
?
>>>=20
>>>=20
>>>>=20
>>>>=20
>>>>>>>         B. Support for synchronous operations as per the definition=
 of
>>>>>>>            "synchronous configuration operation".
>>>>>> Doesn't this follow from A?
>>>>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>>>>> would suggest that we also delete the analogous first sentence of C, =
and
>>>>> re-introduce the "(see terms)" text in the headline description.
>>>> +1
>>>>=20
>>>>=20
>>>> Kent  // as a contributor
>>>>=20
>>>>=20
>>>> .
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>=20


From nobody Mon Oct 19 01:22:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DBD1A7023 for ; Mon, 19 Oct 2015 01:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgXBF65QYIkc for ; Mon, 19 Oct 2015 01:22:14 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCA411A7025 for ; Mon, 19 Oct 2015 01:22:12 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2DCDB1CC0156; Mon, 19 Oct 2015 10:22:17 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20151018090047.GE78184@elstar.local>
References:  <20151013110100.GD66442@elstar.local> <1BAB6D17-923F-46DD-B725-2892BBCFBB9F@nic.cz> <20151013192337.GC67325@elstar.local>  <20151015070330.GC70280@elstar.local> <415D4893-F9BB-445B-A4FB-1A77CEDF642F@nic.cz> <20151018090047.GE78184@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 19 Oct 2015 10:22:08 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 08:22:16 -0000

Juergen Schoenwaelder  writes:

> On Thu, Oct 15, 2015 at 09:52:00AM +0200, Ladislav Lhotka wrote:
>
> [...]
>  
>> The "schema" part addresses syntactic changes in protocol messages,
>> which are inevitable, and the second part is about risky
>> annotations. I agree evil annotations should be banned but I am not
>> sure we can find a satisfactory formulation. Do you have any
>> suggestion?
>
> Perhaps the simples solution is to remove the first sentence in order
> to avoid having 'schema' understood in different ways. (I personally
> believe an annotation MUST NOT change data model semantics but lets
> try to find a compromise.) So my proposal is to replace the entire
> paragraph with:
>
>    Due care has to be exercised when introducing annotations in network
>    management systems in order to avoid interoperability problems and
>    software failures.  The following aspects should be taken into
>    account:

I am fine with this. In a parallel thread I proposed to extend YANG spec
with a general permission for instance data and protocol messages to
include annotations (in any encoding). This would help to make sure that
compliant parsers won't choke on XML attributes or JSON objects whose
names start with "@".

Would this be acceptable?

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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


From nobody Mon Oct 19 01:39:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276121A7028 for ; Mon, 19 Oct 2015 01:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InzVzcaLlnHK for ; Mon, 19 Oct 2015 01:39:22 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3BD1A039A for ; Mon, 19 Oct 2015 01:39:22 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A40A61CC0156; Mon, 19 Oct 2015 10:39:28 +0200 (CEST)
From: Ladislav Lhotka 
To: Xiang Li , netmod@ietf.org
In-Reply-To: <5623E318.7010609@seguesoft.com>
References: <5621845D.6040100@seguesoft.com> <562184A1.6000802@seguesoft.com>  <5623E318.7010609@seguesoft.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 19 Oct 2015 10:39:20 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Fwd: Re: Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 08:39:24 -0000

Xiang Li  writes:

> On 10/18/2015 8:31 AM, Ladislav Lhotka wrote:
>> Xiang Li  writes:
>>
>>> On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
>>>>> On 16 Oct 2015, at 12:27, Balazs Lengyel  wrote:
>>>>>
>>>>> IMHO YANG should define the behavoir, and I would want it to be the same on Netconf/Restconf/CLI etc.
>>>>> I agree that " 1) you get an error back" would be the best: because it is the easiest to understand for the operator, with the fewest corner cases.
>>>>> Also we must define if in the same transaction we set b=42 and a=2. which of the 3 options are taken?
>>>>>
>>>>>
>>>>> We should not leave such complex cases undefined, or alternatively state that they are implementation dependant.
>>>> I might be difficult to say what is a complex case, unless we abandon XPath in "when" statements and use something else - and considerably simpler.
>>>>
>>>> Here is another interesting corner case - does it qualify as being complex?
>>>>
>>>> leaf-list bar {
>>>>      type uint8;
>>>>      when "count(../*) > 1";
>>>> }
>>>> leaf foo {
>>>>      type uint8;
>>>> }
>>> Interesting example...
>>>
>>>> Assuming no instances exist, is this edit allowed? (This was essentially your question.)
>>>>
>>>> 1
>>>> 2
>>> I think this should succeed
>>>
>>>> But what about this?
>>>>
>>>> 1
>>>> 2
>>>>
>>> I think this should succeed too because the when is satisfied in the
>>> data store after the edit-config.
>>>
>> According to the third bullet in sec. 7.21.5 of 6020bis, a validating
>> algorithm has to remove the existing "bar" instances, add a dummy
>> instance and then evaluate the XPath expression. If the result is true,
>> the existing "bar" instances will be put back, otherwise a validation
>> error will be reported - so in our case we will have only one "bar" node,
>> which is invalid.
>
>
> Thanks  you are right. I missed that...
>
>>
>> The result of this change is that we (hopefully) made the processing of
>> "when" well-defined and unambiguous, but the cost in increased comlexity
>> is quite high - both for module readers and implementors of a validating
>> algorithm.
> yes the clarification in  sec. 7.21.5 of 6020bis   does make this clearer.
>
>> In fact, when we discussed issue Y18, my understanding was that dummy
>> node manipulations will be used only if the context node is missing.

> This is something that actually still confuses me!  If a context node
> exists why we still need to replace it with a dummy node, especially
> if an edit-config is performing a "merge" operation?

This is indeed rather confusing. I think the idea was to use this
procedure instead of stating that a "when" expression must not refer to
any children of its context node - the procedure removes them so the
result of evaluating the XPath expression is always the same no matter
what's the subtree of the context node actually contains.

However, the result can be that what's then in the data tree apparently
violates the "when" expression. 

Lada

>
> -Xiang Li
>
>
>
>> Lada
>>
>>>
>>> -Xiang Li
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Oct 19 01:50:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9B41A8716 for ; Mon, 19 Oct 2015 01:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaNm4V0JWr5i for ; Mon, 19 Oct 2015 01:50:47 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C231A871D for ; Mon, 19 Oct 2015 01:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1445244644; x=1446454244; h=to:from:subject:cc:message-id:date:mime-version; bh=waYCNbsKWD97+yyCVIze2IIH49A39jzt0VsHHTwyf84=; b=RlKNq1OYGOJDEZ8sLuEfOwt1SpY0VDhyoC4B3GKlg60VJ9nEGfdYDIKK Koqcem2b4ssCcWDBu/3R+P/sRoztOBZamZdswstIt4CpVNSfJ4bUnJx3n 95UTKTQHvrm4gDBHVVUvWy8bdor+/Louea/9vaN3XuCMSBb74DHsa6DC+ s=;
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800";  d="scan'208,217";a="607670188"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Oct 2015 08:50:42 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9J8ofeE014837; Mon, 19 Oct 2015 08:50:41 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: <5624AED0.3080907@cisco.com>
Date: Mon, 19 Oct 2015 10:50:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------090402030706050204090807"
Archived-At: 
Cc: "Charles Eckel \(eckelcu\)" 
Subject: [netmod] IETF 94 Hackathon: NETCONF/YANG, I2RS, OpenDaylight
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 08:50:48 -0000

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

Dear all,

Based on previous successful events, this IETF 94 week will be again 
preceded by the hackathon.
And there is a track for *NETCONF/YANG, I2RS, OpenDaylight*
See https://www.ietf.org/registration/MeetingWiki/wiki/94hackathon.

Ignas and I are busy updating the WIKI with the current topics of interest.
Don't hesitate, first to participate, and second to let us know what you 
plan on working on.

Regards, Benoit

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


  

    
  
  
    Dear all,

    

    Based on previous successful events, this IETF 94 week will be again
    preceded by the hackathon.

    And there is a track for NETCONF/YANG, I2RS, OpenDaylight

    See https://www.ietf.org/registration/MeetingWiki/wiki/94hackathon.

    

    Ignas and I are busy updating the WIKI with the current topics of
    interest.

    Don't hesitate, first to participate, and second to let us know what
    you plan on working on.

    

    Regards, Benoit

  


--------------090402030706050204090807--


From nobody Mon Oct 19 03:14:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271A11A88AD for ; Mon, 19 Oct 2015 03:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bYlkhIKjvEE for ; Mon, 19 Oct 2015 03:14:53 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813471A889D for ; Mon, 19 Oct 2015 03:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1265; q=dns/txt; s=iport; t=1445249692; x=1446459292; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ceNzlb5Le7KQc9AHhd0QeM5fYujsd9mo/TejemRM3Xk=; b=kHOPj5DZYCMzTj24wfjzb79bR8sbmPWb80gD3rZaKAi9L+rB8k3OQMpA nDIK5faqjM/qMGperkEiYFkz3CJEEGWQGk3/PnoGd1k9CSCum9uJBdZ5O t7zyc494YyM26GdstOjyQ8Olt4+DzZipYqkyKAesd3jjIwY/AbYjhedMi 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAQBQwSRW/xbLJq1ewwYBDYFag0aCWAKBYhQBAQEBAQEBgQqELQEBAQMBOEABBQsLDgoJFgQLCQMCAQIBRQYBDAgBAYgkCMJ+AQEBAQEBAQEBAQEBAQEBAQEBG4Z3hH6EQksHhC4BBJYjjR2BWIc9ijqISR8BAUKCER0WgUA9hhsBAQE
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="630391250"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Oct 2015 10:14:50 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9JAEonk006332; Mon, 19 Oct 2015 10:14:50 GMT
To: Kent Watsen , Martin Bjorklund 
References:  <5621294A.6040107@cisco.com>  <20151016.215651.738952339662172367.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <5624C289.6030203@cisco.com>
Date: Mon, 19 Oct 2015 11:14:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 10:14:54 -0000

On 16/10/2015 22:32, Kent Watsen wrote:
>> Will there ever be a server that operates in synchronous mode, given
>> that applied will not match intended if hardware is missing?
>>
>> Will a client ever use "block" mode if it means that it might hang
>> forever (or at least until some hw is plugged in)?
> I think the key is in the phrase "The server MUST fully *attempt* to
> apply..."
+1.
>
> In my view, the server does not have to "fully apply", it merely has to
> have attempted to do so.  Essentially, a request comes in resulting in a
> flurry of activity, that ultimately stabilizes, at which point the
> response can be sent.
I agree.
>
> If a line card is missing, then (as I understand it), the server would not
> wait for the line-card to show up.
I agree.

>    That said, if the client requested
> transactional/atomic update, a missing line-card would cause an immediate
> failure/rollback.
Yes, I think that this is probably right, given that the applied leaves 
cannot match the intended config leaves.  But this might need some 
further thought to check that the behaviour is sane with regards devices 
that support pre-configuration.

Thanks,
Rob


>
> Makes sense?
>
> Kent  // as a contributor
>
> .
>


From nobody Mon Oct 19 03:44:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F0C1A891B for ; Mon, 19 Oct 2015 03:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 676RU7-odMPJ for ; Mon, 19 Oct 2015 03:44:33 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF6B1A891E for ; Mon, 19 Oct 2015 03:44:33 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 10:44:31 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 10:44:30 +0000
From: Gert Grammel 
To: Robert Wilton , Kent Watsen , Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgD//8ZaAIAAb4+A///XgwAAh5lYgAAFPDaA
Date: Mon, 19 Oct 2015 10:44:30 +0000
Message-ID: 
References:  <5621294A.6040107@cisco.com>  <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com>
In-Reply-To: <5624C289.6030203@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:U72uKfEjLGFNzAjOqFJ+D1uEGV+QqsYumMwDSAQ6D0F2EUWnw8ERgJToLGnbQoay9vGs+Mpo61NfQLv801V3RnyK24U4ubZOF1lSOS3VfGyzoFKDXqjU+CIWk/UmPelTREhaOFLLtUtFf/zGo3UY9Q==; 24:f59XJlYoKYgkeCN7p2Y4QUOs1ft5hoY2GshbZFEA2dhY+M3T6XtHhanaTEOcqDL0qdYSGAqzw4HnZGrWveUR4jrkFrsvjnV9Xan9Uf9yuw0=; 20:/6jc+Kyddd1wUT97uZD9WZmJZgSCTpuskaTGUp+UOp7vU2tJ7bAEP5SjZzrqPH8o8Tm/VZ4C9IjPfu15k6rEVg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(164054003)(199003)(24454002)(479174004)(189002)(2900100001)(1941001)(122556002)(93886004)(5004730100002)(19580405001)(15975445007)(102836002)(64706001)(5002640100001)(66066001)(5007970100001)(19580395003)(87936001)(19617315012)(86362001)(189998001)(40100003)(5008740100001)(36756003)(10400500002)(2950100001)(5001960100002)(99286002)(106356001)(83506001)(16236675004)(92566002)(105586002)(106116001)(101416001)(46102003)(76176999)(4001350100001)(81156007)(5001770100001)(54356999)(97736004)(50986999)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D24A960673CBggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 10:44:30.0544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 10:44:36 -0000

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

+1
From: netmod > on b=
ehalf of Robert Wilton >
Date: Monday 19 October 2015 12:14
To: Kent Watsen >, Martin B=
jorklund >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?



On 16/10/2015 22:32, Kent Watsen wrote:
Will there ever be a server that operates in synchronous mode, given
that applied will not match intended if hardware is missing?

Will a client ever use "block" mode if it means that it might hang
forever (or at least until some hw is plugged in)?
I think the key is in the phrase "The server MUST fully *attempt* to
apply..."
+1.

In my view, the server does not have to "fully apply", it merely has to
have attempted to do so.  Essentially, a request comes in resulting in a
flurry of activity, that ultimately stabilizes, at which point the
response can be sent.
I agree.

If a line card is missing, then (as I understand it), the server would not
wait for the line-card to show up.
I agree.

    That said, if the client requested
transactional/atomic update, a missing line-card would cause an immediate
failure/rollback.
Yes, I think that this is probably right, given that the applied leaves
cannot match the intended config leaves.  But this might need some
further thought to check that the behaviour is sane with regards devices
that support pre-configuration.

Thanks,
Rob



Makes sense?

Kent  // as a contributor

.


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


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







+1 




From: netmod <netmod-bounces@ietf.org> on behalf of Rober=
t Wilton <rwilton@cisco.com>=


Date: Monday 19 October 2015 12:14<=
br>
To: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <<=
a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>

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

Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?























On 16/10/2015 22:32, Kent Watsen wrote:






Will there ever be a server that operates in synchronous mode, given

that applied will not match intended if hardware is missing?







Will a client ever use "block" mode if it means that it migh=
t hang


forever (or at least until some hw is plugged in)?




I think the key is in the phrase "The server MUST fully *attempt*=
 to


apply..."




+1.









In my view, the server does not have to "fully apply", it me=
rely has to


have attempted to do so.  Essentially, a request comes in re=
sulting in a


flurry of activity, that ultimately stabilizes, at which point the

response can be sent.




I agree.









If a line card is missing, then (as I understand it), the server would=
 not


wait for the line-card to show up.




I agree.









    That said, if the client requested


transactional/atomic update, a missing line-card would cause an immedi=
ate


failure/rollback.




Yes, I think that this is probably right, given that the applied leave=
s 


cannot match the intended config leaves.  But this might nee=
d some 


further thought to check that the behaviour is sane with regards devic=
es 


that support pre-configuration.







Thanks,


Rob



















Makes sense?







Kent  // as a contributor







.














_______________________________________________


netmod mailing list
















--_000_D24A960673CBggrammeljunipernet_--


From nobody Mon Oct 19 04:06:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009201A8957 for ; Mon, 19 Oct 2015 04:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arT9pe1CmbxH for ; Mon, 19 Oct 2015 04:06:30 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9741C1A8956 for ; Mon, 19 Oct 2015 04:06:30 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E3571AE0959; Mon, 19 Oct 2015 13:06:29 +0200 (CEST)
Date: Mon, 19 Oct 2015 13:06:28 +0200 (CEST)
Message-Id: <20151019.130628.1751760450891248750.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5624C289.6030203@cisco.com>
References: <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 11:06:32 -0000

Robert Wilton  wrote:
> 
> 
> On 16/10/2015 22:32, Kent Watsen wrote:
> >> Will there ever be a server that operates in synchronous mode, given
> >> that applied will not match intended if hardware is missing?
> >>
> >> Will a client ever use "block" mode if it means that it might hang
> >> forever (or at least until some hw is plugged in)?
> > I think the key is in the phrase "The server MUST fully *attempt* to
> > apply..."
> +1.

So today we have this situation:


   intended                                         operational
    config                                             values
      X--------------------------------------------------X
      (time ->)


When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated.  Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.

The NMS/operator writes to intended config, ang verifies by checking
the operational state.


With applied config we have this situation:


   intended                       applied           operational
    config                         config              values
      X------------------------------X-------------------X     


In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.


With async/sync systems we now have:

                      attempted
   intended            applied     applied           operational
    config              config     config              values
      X-------------------X----------X-------------------X     
                          ^
                   this is when "block"
                   would return
                 


To me it seems we're exposing another internal state to the
NMS/operator.  But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.


/martin


From nobody Mon Oct 19 04:12:51 2015
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC301A8968; Mon, 19 Oct 2015 04:12:50 -0700 (PDT)
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.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019111250.24474.96145.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 04:12:50 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 11:12:50 -0000

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

        Title           : The YANG 1.1 Data Modeling Language
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc6020bis-08.txt
	Pages           : 193
	Date            : 2015-10-19

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


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 19 04:13:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66BB1A8991 for ; Mon, 19 Oct 2015 04:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ISNyVx_nCuO for ; Mon, 19 Oct 2015 04:13:36 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 393F81A896B for ; Mon, 19 Oct 2015 04:13:34 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 54DCF1CC0156; Mon, 19 Oct 2015 13:13:39 +0200 (CEST)
From: Ladislav Lhotka 
To: "fengchong \(C\)" , "netmod\@ietf.org" 
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D08264E0@SZXEMI506-MBS.china.huawei.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 19 Oct 2015 13:13:31 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] I suggest add 'abstract' statement as 'identity''s sub	statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 11:13:42 -0000

"fengchong (C)"  writes:

> Hi all,
>
>     I notice an identity named 'interface-type' was defined in RFC
> 7223 ( A YANG Data Model for Interface Management). This identity is
> an abstract identity, vendors can define their real Identity based
> it. But it's lack of a means to identify this identity
> 'interface-type' is abstract, so 'interface-type' can be accepted as
> valid value of the leaf based this identity.

In fact, the identity that's specified as "base" in an "identityref"
type is NOT a valid value, so the base identity is abstract.

This wasn't clear in the original RFC 6020 so it was clarified in this erra=
tum:

https://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3470

Section 7.18.2 in draft-ietf-netmod-rfc6020bis-07 has this text:

   The derivation of identities has the following properties:

   o  It is irreflexive, which means that an identity is not derived
      from itself.

   =E2=80=A6

In XPath expressions, it is possible to treat an identity as being
abstract or not by using either derived-from() or derived-from-or-self()
function.

Lada

>    So I suggest add 'abstract' statement as 'identity's sub statement in =
YANG1.1. This statement is optional, default value is false.
> If abstract identity is defined, 'abstract true' MUST be defined, and thi=
s identity's name cannot be accepted as valid value of the leaf
> based this identity .
> For example:
>
>      identity interface-type {
>
>        abstract true;
>
>        description
>
>          "Base identity from which specific interface types are
>
>           derived.";
>
>      }
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Oct 19 04:15:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422251A898D for ; Mon, 19 Oct 2015 04:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly6XVcLVp-oe for ; Mon, 19 Oct 2015 04:15:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 005931A898C for ; Mon, 19 Oct 2015 04:15:37 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 3780B1AE0959 for ; Mon, 19 Oct 2015 13:15:37 +0200 (CEST)
Date: Mon, 19 Oct 2015 13:15:36 +0200 (CEST)
Message-Id: <20151019.131536.951672023333459862.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20151019111250.24474.96145.idtracker@ietfa.amsl.com>
References: <20151019111250.24474.96145.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 11:15:39 -0000

Hi,

This version addresses most WGLC comments.  This are still two ongoing
discussions, "Order of evaluation for when?" and "6020bis extensions"
that may require more changes.



/martin

internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
> 
>         Title           : The YANG 1.1 Data Modeling Language
>         Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc6020bis-08.txt
> 	Pages           : 193
> 	Date            : 2015-10-19
> 
> Abstract:
>    YANG is a data modeling language used to model configuration data,
>    state data, remote procedure calls, and notifications for network
>    management protocols like the Network Configuration Protocol
>    (NETCONF).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Oct 19 04:48:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC511A8AF1; Mon, 19 Oct 2015 04:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jeyg8NhtboJp; Mon, 19 Oct 2015 04:48:20 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BBF1A8BBD; Mon, 19 Oct 2015 04:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2399; q=dns/txt; s=iport; t=1445255298; x=1446464898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2az1ZBSc0+6nr0ni/cN+gqlnQQJPcuoOPe7qF3xK4QY=; b=MJNoXGAgR0fb95zaWvsPtE9QB5SGe06ufP/EdZZstCwXXI11alRN4mSC 7mfBI03Eldbh9TZFa1lq+oydFV77QvLq3XFXqAuTfjRfhxVW1YCRa2ZEO lhrSSL8aj2gmdrybRxFd98M1JdG2ttNlYjU9zC4c3DsjKPQ39WZCqGlK+ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9AQDA1yRW/4UNJK1egzZUbwa+CAENgVojhXsCgTQ4FAEBAQEBAQF/C4QuAQEEOg8uAg4CAgEINhAbFyUCBA4FiDANwwQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBIZzhH6FDQeELgWNEokRAYUYiASBWEiDdJYDAR8BAUKEA3KEYYEGAQEB
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="199279848"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 19 Oct 2015 11:48:17 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9JBmGZM028539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 11:48:16 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 06:47:58 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 06:47:58 -0500
From: "Gabriele Maria Galimberti (ggalimbe)" 
To: "ccamp@ietf.org" 
Thread-Topic: New Version Notification for draft-dharini-netmod-dwdm-if-yang-00.txt
Thread-Index: AQHRCmN90J+fU2rODEGJKDh34ChezJ5zKMmA
Date: Mon, 19 Oct 2015 11:47:58 +0000
Message-ID: 
References: <20151019114434.15145.85261.idtracker@ietfa.amsl.com>
In-Reply-To: <20151019114434.15145.85261.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.148.212.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3FB378337ADDF04590091034136D1D8D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Dharini Hiremagalur , "netmod@ietf.org" , Gary Ratterree , Ruediger Kunze , Luyuan Fang 
Subject: Re: [netmod] New Version Notification for draft-dharini-netmod-dwdm-if-yang-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 11:48:21 -0000

Dear All,

Based on the Prague ccamp discussions and feedbacks
We have posted the new draft is substitution of

- draft-dharini-netmod-g-698-2-yang-04.

As You seen we changed the draft name and in addition we removed the use
cases
Now reported in the: draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01.txt.

Best Regards,

The Authors





Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl



via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/ 

ggalimbe@cisco.com
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049















On 10/19/15 1:44 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-dharini-netmod-dwdm-if-yang-00.txt
>has been successfully submitted by Gabriele Galimberti and posted to the
>IETF repository.
>
>Name:		draft-dharini-netmod-dwdm-if-yang
>Revision:	00
>Title:		A YANG model to manage the optical interface parameters for an
>external transponder in a WDM network
>Document date:	2015-10-19
>Group:		Individual Submission
>Pages:		20
>URL:           =20
>https://www.ietf.org/internet-drafts/draft-dharini-netmod-dwdm-if-yang-00.
>txt
>Status:        =20
>https://datatracker.ietf.org/doc/draft-dharini-netmod-dwdm-if-yang/
>Htmlized:      =20
>https://tools.ietf.org/html/draft-dharini-netmod-dwdm-if-yang-00
>
>
>Abstract:
>   This memo defines a Yang model that translates the SNMP mib module
>   defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single
>   channel optical interface parameters of DWDM applications.  This
>   model is to support the optical parameters specified in ITU-T G.698.2
>   [ITU.G698.2] and application identifiers specified in ITU-T G.874.1
>   [ITU.G874.1] .  Note that G.874.1 encompasses vendor-specific codes,
>   which if used would make the interface a single vendor IaDI and could
>   still be managed.
>
>   The Yang model defined in this memo can be used for Optical
>   Parameters monitoring and/or configuration of the endpoints of the
>   multi-vendor IaDI optical link.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>


From nobody Mon Oct 19 05:06:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D861A0162 for ; Mon, 19 Oct 2015 05:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwqAWEi8hp8I for ; Mon, 19 Oct 2015 05:06:37 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF32C1A0161 for ; Mon, 19 Oct 2015 05:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3216; q=dns/txt; s=iport; t=1445256396; x=1446465996; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ctYWFTwyQWBnWCF70FRNrG9cwMecYikFdBpokA3+bHg=; b=Dm2GRpqT+aZQyeRNmpcY1oeOaQyhsTGEynhsPsPVnvdBV5znh5K5ALBw O9f3ZX1vBsyUHEEapgUeLZD7t4/v3+dxUX0tXjC17ckiKPp2d7LHf055r 0nW8xAQ+FNMg3enQSS3udxz4ewTPB/vtGpkYgdVXtzq+iB0/LCR4PW4zC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D/BABg2yRW/xbLJq1ehDdCv3aCZIM6AoIAAQEBAQEBgQuELgEBBCcRPAQBEAsOCgkWBAsJAwIBAgFFBg0GAgEBiCzDGwEBAQEBAQEBAQEBAQEBAQEBHIZ3hH6EQksHhC4BBIc7A4cEh2GICYUUgViHPYo6hFqDb2OCRIFAPTSFZwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="605799662"
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; 19 Oct 2015 12:06:34 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9JC6X2O001815; Mon, 19 Oct 2015 12:06:33 GMT
To: Martin Bjorklund 
References: <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <5624DCB8.8080605@cisco.com>
Date: Mon, 19 Oct 2015 13:06:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151019.130628.1751760450891248750.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:06:39 -0000

Hi Martin,

On 19/10/2015 12:06, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>>
>> On 16/10/2015 22:32, Kent Watsen wrote:
>>>> Will there ever be a server that operates in synchronous mode, given
>>>> that applied will not match intended if hardware is missing?
>>>>
>>>> Will a client ever use "block" mode if it means that it might hang
>>>> forever (or at least until some hw is plugged in)?
>>> I think the key is in the phrase "The server MUST fully *attempt* to
>>> apply..."
>> +1.
> So today we have this situation:
>
>
>     intended                                         operational
>      config                                             values
>        X--------------------------------------------------X
>        (time ->)
>
>
> When the edit-config returns, running (intended) has been updated, and
> the operational state may or may not have been updated.  Internally to
> the system, there may be a chain of things that need to happen before
> the intended config has been pushed out to all software/hardware
> components.
>
> The NMS/operator writes to intended config, ang verifies by checking
> the operational state.
>
>
> With applied config we have this situation:
>
>
>     intended                       applied           operational
>      config                         config              values
>        X------------------------------X-------------------X
>
>
> In some cases, the applied config is an approximation of the
> operational values (if e.g., a single config leaf is used by two
> different components), and in other cases the applied config is just
> one of the internal stages the config value flows through before
> reaching the end component.
>
>
> With async/sync systems we now have:
>
>                        attempted
>     intended            applied     applied           operational
>      config              config     config              values
>        X-------------------X----------X-------------------X
>                            ^
>                     this is when "block"
>                     would return
>                   
>
>
> To me it seems we're exposing another internal state to the
> NMS/operator.  But in reality nothing has changed from the first
> picture - the NMS/operator still needs to check the operational values
> in order to know that the system behaves as it should.
I see it slightly differently.

I think that "attempted applied config" is effectively the same time 
point as "applied config" above.  As in the server has attempted to 
apply all the configuration and for every it has either succeed, failed, 
or can't be applied because the hardware isn't present.

So using your time line above:
1. If you have an async config operation then the server returns at time 
"intended config".
2. If you have a sync (blocking) config operation then the server 
returns at time "applied config".
3. If you have an existing netconf config operation that is neither 
explicitly sync nor async then the server may return at any time between 
"intended config" and "applied config".

Thanks,
Rob

>
>
> /martin
> .
>


From nobody Mon Oct 19 05:18:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487641A036B for ; Mon, 19 Oct 2015 05:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8_y4u5F0pCb for ; Mon, 19 Oct 2015 05:18:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE6631A0162 for ; Mon, 19 Oct 2015 05:18:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 956CD1AE0959; Mon, 19 Oct 2015 14:18:08 +0200 (CEST)
Date: Mon, 19 Oct 2015 14:18:08 +0200 (CEST)
Message-Id: <20151019.141808.1326609430857565681.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5624DCB8.8080605@cisco.com>
References: <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com> <5624DCB8.8080605@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:18:11 -0000

Robert Wilton  wrote:
> Hi Martin,
> 
> On 19/10/2015 12:06, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 16/10/2015 22:32, Kent Watsen wrote:
> >>>> Will there ever be a server that operates in synchronous mode, given
> >>>> that applied will not match intended if hardware is missing?
> >>>>
> >>>> Will a client ever use "block" mode if it means that it might hang
> >>>> forever (or at least until some hw is plugged in)?
> >>> I think the key is in the phrase "The server MUST fully *attempt* to
> >>> apply..."
> >> +1.
> > So today we have this situation:
> >
> >
> >     intended                                         operational
> >      config                                             values
> >        X--------------------------------------------------X
> >        (time ->)
> >
> >
> > When the edit-config returns, running (intended) has been updated, and
> > the operational state may or may not have been updated.  Internally to
> > the system, there may be a chain of things that need to happen before
> > the intended config has been pushed out to all software/hardware
> > components.
> >
> > The NMS/operator writes to intended config, ang verifies by checking
> > the operational state.
> >
> >
> > With applied config we have this situation:
> >
> >
> >     intended                       applied           operational
> >      config                         config              values
> >        X------------------------------X-------------------X
> >
> >
> > In some cases, the applied config is an approximation of the
> > operational values (if e.g., a single config leaf is used by two
> > different components), and in other cases the applied config is just
> > one of the internal stages the config value flows through before
> > reaching the end component.
> >
> >
> > With async/sync systems we now have:
> >
> >                        attempted
> >     intended            applied     applied           operational
> >      config              config     config              values
> >        X-------------------X----------X-------------------X
> >                            ^
> >                     this is when "block"
> >                     would return
> >                   To me it seems we're exposing another internal state to
> >                   the
> > NMS/operator.  But in reality nothing has changed from the first
> > picture - the NMS/operator still needs to check the operational values
> > in order to know that the system behaves as it should.
> I see it slightly differently.
> 
> I think that "attempted applied config" is effectively the same time
> point as "applied config" above.

But if I pre-configure an interface for which the hw is not present,
it has been said that this config will exist in intended but not in
applied.  And you said that you didn't want "block" to wait for the hw
to be present.  So the server will return before this data shows up in
applied.

> As in the server has attempted to
> apply all the configuration and for every it has either succeed,
> failed, or can't be applied because the hardware isn't present.

Yes.

> So using your time line above:
> 1. If you have an async config operation then the server returns at
> time "intended config".
> 2. If you have a sync (blocking) config operation then the server
> returns at time "applied config".
> 3. If you have an existing netconf config operation that is neither
> explicitly sync nor async then the server may return at any time
> between "intended config" and "applied config".

Sure.  My time line shows how the new value trickels down from
intended to oper.


/martin


From nobody Mon Oct 19 05:25:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497FD1A0397 for ; Mon, 19 Oct 2015 05:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSvA2dxUsCMi for ; Mon, 19 Oct 2015 05:25:44 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B3D1A0381 for ; Mon, 19 Oct 2015 05:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8698; q=dns/txt; s=iport; t=1445257543; x=1446467143; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=FRiy+mp9hcYWuAhYZEdbNh4hZqhXrXaNRSB50D9mb/o=; b=JeoMo1elzWlbi0k6PwBKBMrBE/2+H0IkylJJl+7S+VjLd830lTspO14B w7vxTRrNCyilRPSVgRDxuHkKUaDKz1HEmcSYs3uZb5p8h5iv7PE8XRv2v oSAVQLWGy4HlNz1bQbjUkYt1Qq4YqdyixKgWhkx4H/IoWyfTUN7VuInBi o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBABx4CRW/xbLJq1ehApvv3YXCoUzSgKCAgEBAQEBAYELhC0BAQEDAQEBATU2CgEFCwsOCgkWBAsJAwIBAgEVMAYNBgIBARQDiA0IDcMLAQEBAQEBAQEBAQEBAQEBAQEBARYEhneEfoRCSweELgEEhzuHB4dhjR2BWIc9ijqEWoNvY4JEgUA9NIVnAQEB
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="607673599"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Oct 2015 12:25:41 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCPfZA004298; Mon, 19 Oct 2015 12:25:41 GMT
To: Gert Grammel 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com>  <562146F8.4020503@cisco.com> 
From: Robert Wilton 
Message-ID: <5624E134.1060007@cisco.com>
Date: Mon, 19 Oct 2015 13:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:25:46 -0000

Hi Gert,

On 19/10/2015 09:06, Gert Grammel wrote:
> Rob,
>
> I think we are describing the same problem from a little different perspective:
Perhaps, but I'm not sure that we are on the same page yet.

>
> Sent from my Apple ][
>
>> On 16 Oct 2015, at 20:50, Robert Wilton  wrote:
>>
>> Hi Gert,
>>
>>> On 16/10/2015 18:14, Gert Grammel wrote:
>>> Rob,
>>>
>>> Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied.
>>>
>>> What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be "hybrid" which suggests something in between asynchronous and synchronous.
>> I'm talking about netconf servers that effectively apply most of their configuration before they reply.  E.g. they might take 10 minutes to reply.
>>
> Exactly, that's why those servers are running asynchronously. The trouble is that in contrast to the synchronous operation there is no "done" information. Current implementations often try to work around that point by applying more than just a syntax check in the first phase. This way they are still quick in replying are more reliably responding, but still fail from time to time
I don't follow why you think that these servers are running 
asynchronously.  They are much closer to handling all config operations 
as synchronous blocking calls.  This is a just a small amount of 
programming that is being performed asynchronously.


>
>> Perhaps this isn't a valid Netconf implementation, and all Netconf server implementations are expected to be asynchronous w.r.t to when they apply their configuration - but I can't see where this is stated in the NETCONF RFC (but possibly I'm not looking in the right place).
>>
>>
>>> >From a client perspective an asynchronous server and a hybrid server look the same. The difference is that the asynchronous one should convey a "finished" information to the client, while the hybrid would remain in a "trust me babe" mode forever.
>> Yes, but this isn't the only difference:
>> - a client could expect that an asynchronous config operation response should be reasonably expedient.
> Agree, but this is true for hybrid and asynchronous and the term "reasonable" is not well defined.
This is true for asynchronous but not hybrid, since a hybrid operation 
might return just before a proper synchronous operation would.

>
>>   E.g. if a client was to update 10 devices each with a reasonable size configuration (that takes minutes to apply) in an asynchronous way then it might reasonably consider sequencing the async config requests to each server on one thread.  If each server acknowledged the requests in a couple of seconds then all the servers would broadly end up applying the configuration concurrently.
> Yes, that's why we need asynchronous mode in the first place.
>> - however, if the servers were hybrid, and their replies were sent much closer to when the configuration was actually applied then initiating the requests sequentially would effectively mean that the devices end up applying the configuration serially which would end up taking much longer.  I.e. it seems reasonable that a client may want to differentiate between the behaviour of these two servers even if how it handles the resultant config changes is the same.
> It seems your definition of hybrid is something like "asynchronous but with a longer than reasonable response time".
My definition of hybrid (i.e. the default existing netconf config 
operations) is along the lines of "asynchronous in behaviour, but may 
reply any time between when the intended configuration has been updated 
and the applied configuration has been completely updated ".

>
> This is similar to a bloated synchronous operation which takes too much time to respond.  Both cases are undesired and in both cases the solution is to make them truly asynchronous. So that we can have a reasonable response time.
I agree with the goal, but it may be difficult to change some existing 
NETCONF operational handling to be either strictly sync or async.

>   
>
>>>
>>> Another way to look at hybrids is to consider them "cheating synchronous". Given that the new config may not have been applied at the time of the response to the client. This is worse than the situation before where a missing verify lets the client know that something may still go on. Clients can't tell if servers are cheating :-)
>> Yes, but clients also need to be able to determine if the server is likely to be slow to response, because then the client would probably be designed to interact with the server in a different fashion (e.g. use a pool of threads to initiate the updates concurrently).
> How would you do this in practice?
Roughly, I would suggest:

Assuming that this is going to be a new optional to implement extension:
  - There would be a capability to indicate whether a server supports an 
explicit sync config operation.
  - There would be a capability to indicate whether a server supports an 
explicit async config operation.
  - It would be implicitly assumed that the server would support the 
existing default config operation.

In Netconf/Restconf when an edit-config request is made, an extension 
would include an option to indicate whether the request should be 
processed as sync, async, or default (i.e. existing behaviour).

Thanks,
Rob


>   Even servers don't know if they're likely to slow a response when they get a request. That's why a quick first response is required that assures the client the requests will be processed, followed by a potentially slow feedback that it is successfully executed (=verified) or failed.
>> Thanks,
>> Rob
>>
>>
>>> Gert
>>>
>>>
>>>
>>> Sent from my Apple ][
>>>
>>>> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
>>>>
>>>>
>>>>
>>>>> On 16/10/2015 14:59, Kent Watsen wrote:
>>>>>
>>>>>>>>      3.  Support for both synchronous and asynchronous configuration
>>>>>>>>          operations
>>>>>>>>
>>>>>>>>          A. A server may choose to support only synchronous
>>>>>>>> configuration
>>>>>>>>             operations, or only asynchronous configuration operations,
>>>>>>>> or
>>>>>>>>             both synchronous and asynchronous configuration operations
>>>>>>>> in
>>>>>>>>             a client specified per-operation basis.
>>>>>>> I think the most common mode *today* is a mix of sync/async, on a
>>>>>>> per-object basis.
>>>>>> Yes, I agree.
>>>>> Wait, I think we're talking about different things.  Martin, I'm sure that
>>>>> internal to a NC/RC server, parts of the intended configuration is
>>>>> actually applied synchronously (e.g., a hostname) whereas other parts are
>>>>> not (e.g., config for data plane).   But that nuance is not currently
>>>>> exposed in any way today -right?
>>>> I think that today, from what a client sees/experiences, many replies from netconf servers fits neither the definition of "synchronous configuration operation" nor "asynchronous configuration operation", but instead, the reply is somewhere between the two extremes.
>>>>
>>>> So the question I was trying to raise is whether servers that need to meet the opstate requirements have to change to strictly comply with the defined async or sync config operation semantics?  E.g. not just adding a "done-applying" option, but perhaps also adding something along the lines of a "done-verifying" option.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>> What we're talking about here is an ability for a client to request a
>>>>> protocol operation (PATCH) to block, or for the "done-applying"
>>>>> notification to not be sent, until all that processing of the request is
>>>>> complete.  This regardless if the request contains a mix of nodes that are
>>>>> applied internally sync/async.  Makes sense? - or it is something else?
>>>>
>>>>>
>>>>>>>>          B. Support for synchronous operations as per the definition of
>>>>>>>>             "synchronous configuration operation".
>>>>>>> Doesn't this follow from A?
>>>>>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>>>>>> would suggest that we also delete the analogous first sentence of C, and
>>>>>> re-introduce the "(see terms)" text in the headline description.
>>>>> +1
>>>>>
>>>>>
>>>>> Kent  // as a contributor
>>>>>
>>>>>
>>>>> .
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
> .
>


From nobody Mon Oct 19 05:39:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D48C1A1A51 for ; Mon, 19 Oct 2015 05:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.134
X-Spam-Level: 
X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-raU-I61wDL for ; Mon, 19 Oct 2015 05:39:27 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B421A1A45 for ; Mon, 19 Oct 2015 05:39:26 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 12:39:06 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 12:39:05 +0000
From: Gert Grammel 
To: Martin Bjorklund , "rwilton@cisco.com" 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgD//8ZaAIAAb4+A///XgwAAh5lYgAAB0CwAAAdspYA=
Date: Mon, 19 Oct 2015 12:39:05 +0000
Message-ID: 
References: <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com>
In-Reply-To: <20151019.130628.1751760450891248750.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB041; 5:Gjo2NxAigKLSjAvDNOYZsM5jIxgFaWTt6/b8+HvKc0THCqv06G34zYNH8DlJDAmrXxie9S+QDqOvXLhjQY6Kev+7fdlqhPJnlGXeTKdFYZ8NC7RRLLAMIVHpK1tKIBsQDunB79uhxayiJVE+fWSHiw==; 24:1WXQ6+of8DkpsxjjEVY5ZHE9DAGlXB2rLMN//dGyV2WROQGPYjAK71eaPppfZDMf/jAlTH2+dxqRDielw6IlLTimEKL84Gyoqdv3Cp4zMmc=; 20:yGAbsKW2ePsCrLZo2IEx/YKn0sTxro7iaglwAofjZSLqskkJ2MlyyfTZwn4/0M8hbHhJRfvdo2sMv4YZjt0Qdg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB041; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB041; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(199003)(189002)(24454002)(15975445007)(102836002)(97736004)(46102003)(54356999)(2501003)(19617315012)(64706001)(5004730100002)(19580405001)(19580395003)(5001960100002)(50986999)(5007970100001)(93886004)(2950100001)(2900100001)(40100003)(66066001)(189998001)(122556002)(5001920100001)(10400500002)(5002640100001)(99286002)(16236675004)(36756003)(76176999)(5008740100001)(106356001)(106116001)(4001350100001)(101416001)(83506001)(81156007)(92566002)(86362001)(105586002)(5001770100001)(87936001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB041; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24A9EA173FFggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 12:39:05.6557 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB041
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:39:29 -0000

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

Martin,

Attempting to apply a config appears to me as a process, not a state. So in=
 my mind the little drawing should look like this then:


receive   updated       Attempting to
intended  intended      apply intended    applied           operational
config    config         config            config              values
X----------X-------------------------------------X-------------------X
     ^
 this is when "block"
   would return



Gert

From: netmod > on b=
ehalf of Martin Bjorklund >
Date: Monday 19 October 2015 13:06
To: "rwilton@cisco.com" >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?

Robert Wilton > wrote:
On 16/10/2015 22:32, Kent Watsen wrote:
>> Will there ever be a server that operates in synchronous mode, given
>> that applied will not match intended if hardware is missing?
>>
>> Will a client ever use "block" mode if it means that it might hang
>> forever (or at least until some hw is plugged in)?
> I think the key is in the phrase "The server MUST fully *attempt* to
> apply..."
+1.

So today we have this situation:

   intended                                         operational
    config                                             values
      X--------------------------------------------------X
      (time ->)


When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated.  Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.

The NMS/operator writes to intended config, ang verifies by checking
the operational state.


With applied config we have this situation:


   intended                       applied           operational
    config                         config              values
      X------------------------------X-------------------X


In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.


With async/sync systems we now have:

                      attempted
   intended            applied     applied           operational
    config              config     config              values
      X-------------------X----------X-------------------X
                          ^
                   this is when "block"
                   would return



To me it seems we're exposing another internal state to the
NMS/operator.  But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.


/martin

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


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








Martin,











Attempting to apply a config appears to me as a process, not a state. So in=
 my mind the little drawing should look like this then:















receive   updated      &nbs=
p;Attempting to


intended  intended      apply intended    ap=
plied           operation=
al


config    config         config    =
;        config      &nbs=
p;       values


X----------X-------------------------------------X-------------------X&nbs=
p;    


     ^               &nb=
sp; 


 this is when "block"


   would return


    
















Gert












From: netmod <netmod-bounces@ietf.org> on behalf of Marti=
n Bjorklund <mbj@tail-f.com>
Date: Monday 19 October 2015 13:06<=
br>
To: "rwilton@cisco.com" <rwilton@cisco.com>

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

Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?













Robert Wilton <rwilton@cisco.com> wrote:








On 16/10/2015 22:32, Kent Watsen wrote:


>> Will there ever be a server that operates in synchronous mode=
, given


>> that applied will not match intended if hardware is missing?<=
/div>

>>


>> Will a client ever use "block" mode if it means tha=
t it might hang


>> forever (or at least until some hw is plugged in)?


> I think the key is in the phrase "The server MUST fully *att=
empt* to


> apply..."


+1.









So today we have this situ=
ation:

















   intended    &n=
bsp;            =
;            &n=
bsp;           operationa=
l


    config   =
;            &n=
bsp;            =
;            &n=
bsp;    values


      X----------=
----------------------------------------X


      (time ->=
)












When the edit-config retur=
ns, running (intended) has been updated, and


the operational state may =
or may not have been updated.  Internally to


the system, there may be a=
 chain of things that need to happen before


the intended config has be=
en pushed out to all software/hardware


components.







The NMS/operator writes to=
 intended config, ang verifies by checking


the operational state.











With applied config we hav=
e this situation:












   intended =
;            &n=
bsp;         applied  &nb=
sp;        operational


    co=
nfig            =
;             c=
onfig           &nbs=
p;  values


    &n=
bsp; X------------------------------X-------------------X  &=
nbsp; 













In some cases, the applied=
 config is an approximation of the


operational values (if e.g=
., a single config leaf is used by two


different components), and=
 in other cases the applied config is just


one of the internal stages=
 the config value flows through before


reaching the end component=
.












With async/sync systems we=
 now have:







    &n=
bsp;            =
;     attempted


   intended =
;           applied&=
nbsp;    applied       &n=
bsp;   operational


    co=
nfig            =
;  config     config    &=
nbsp;         values


    &n=
bsp; X-------------------X----------X-------------------X  &=
nbsp; 



    &n=
bsp;            =
;         ^


    &n=
bsp;            =
;  this is when "block"


    &n=
bsp;            =
;  would return


    &n=
bsp;            











To me it seems we're expos=
ing another internal state to the


NMS/operator.  B=
ut in reality nothing has changed from the first


picture - the NMS/operator=
 still needs to check the operational values


in order to know that the =
system behaves as it should.












/martin







__________________________=
_____________________


netmod mailing list
















--_000_D24A9EA173FFggrammeljunipernet_--


From nobody Mon Oct 19 05:54:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745041A9064 for ; Mon, 19 Oct 2015 05:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3sB2WlPPxlV for ; Mon, 19 Oct 2015 05:54:47 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375FA1A9047 for ; Mon, 19 Oct 2015 05:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4594; q=dns/txt; s=iport; t=1445259288; x=1446468888; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5kOr/VpaW73tI9s4jIHrf50V1V7X1rotiMabRqyBUp8=; b=Y28ZDAy4VTkFa/4Xbjo6zXEBAKJdHSu92Z6jdnbcj9P867crBbyKlBOY ahQfc0ZfoN22lrcdhN+amS/Nm1bIDCJZeCtZwxutXdFT+9PV/gu2pvPwH tkcvRqJ+iU3QPNB4H5zdvHiCdHeVdoqWPQRUNO2TywyhvJbpAAGyEXRl8 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DvAQAC5yRW/xbLJq1ehDdCvg4BDYFagmSDOgKBbhQBAQEBAQEBgQqELQEBAQMBJxE8BRALDgoJGgsPAkYGDQYCAQGIJAjDGwEBAQEBAQEBAQEBAQEBAQEBHIZ3hH6EQksHhC4BBIc7A4cEh2GICYUUgViHPYo6hFqDbx8BAUKCER0WgUA9NIVnAQEB
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="630393674"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Oct 2015 12:54:44 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCsh4C012265; Mon, 19 Oct 2015 12:54:43 GMT
To: Martin Bjorklund 
References: <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com> <5624DCB8.8080605@cisco.com> <20151019.141808.1326609430857565681.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <5624E802.60408@cisco.com>
Date: Mon, 19 Oct 2015 13:54:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151019.141808.1326609430857565681.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:54:49 -0000

On 19/10/2015 13:18, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Martin,
>>
>> On 19/10/2015 12:06, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
>>>> On 16/10/2015 22:32, Kent Watsen wrote:
>>>>>> Will there ever be a server that operates in synchronous mode, given
>>>>>> that applied will not match intended if hardware is missing?
>>>>>>
>>>>>> Will a client ever use "block" mode if it means that it might hang
>>>>>> forever (or at least until some hw is plugged in)?
>>>>> I think the key is in the phrase "The server MUST fully *attempt* to
>>>>> apply..."
>>>> +1.
>>> So today we have this situation:
>>>
>>>
>>>      intended                                         operational
>>>       config                                             values
>>>         X--------------------------------------------------X
>>>         (time ->)
>>>
>>>
>>> When the edit-config returns, running (intended) has been updated, and
>>> the operational state may or may not have been updated.  Internally to
>>> the system, there may be a chain of things that need to happen before
>>> the intended config has been pushed out to all software/hardware
>>> components.
>>>
>>> The NMS/operator writes to intended config, ang verifies by checking
>>> the operational state.
>>>
>>>
>>> With applied config we have this situation:
>>>
>>>
>>>      intended                       applied           operational
>>>       config                         config              values
>>>         X------------------------------X-------------------X
>>>
>>>
>>> In some cases, the applied config is an approximation of the
>>> operational values (if e.g., a single config leaf is used by two
>>> different components), and in other cases the applied config is just
>>> one of the internal stages the config value flows through before
>>> reaching the end component.
>>>
>>>
>>> With async/sync systems we now have:
>>>
>>>                         attempted
>>>      intended            applied     applied           operational
>>>       config              config     config              values
>>>         X-------------------X----------X-------------------X
>>>                             ^
>>>                      this is when "block"
>>>                      would return
>>>                    To me it seems we're exposing another internal state to
>>>                    the
>>> NMS/operator.  But in reality nothing has changed from the first
>>> picture - the NMS/operator still needs to check the operational values
>>> in order to know that the system behaves as it should.
>> I see it slightly differently.
>>
>> I think that "attempted applied config" is effectively the same time
>> point as "applied config" above.
> But if I pre-configure an interface for which the hw is not present,
> it has been said that this config will exist in intended but not in
> applied.  And you said that you didn't want "block" to wait for the hw
> to be present.  So the server will return before this data shows up in
> applied.
My thinking is:

For a synchronous operation (with continue-on-error option):
  - the hw dependent config is updated to intended, probably an 
error/warning is returned for those leaves to indicate that it can't be 
applied because the hardware isn't present.
  - at some given point in the future, i.e. as a completely separate 
event, the hardware may be inserted and the intended config is applied 
at that time.

For a synchronous operation (with rollback-on-error option):
  - the configuration would fail because the hw isn't present (same 
errors/warnings returned as above) and hence the entire config operation 
is completely undone due to the rollback-on-error semantics.

Thanks,
Rob


>
>> As in the server has attempted to
>> apply all the configuration and for every it has either succeed,
>> failed, or can't be applied because the hardware isn't present.
> Yes.
>
>> So using your time line above:
>> 1. If you have an async config operation then the server returns at
>> time "intended config".
>> 2. If you have a sync (blocking) config operation then the server
>> returns at time "applied config".
>> 3. If you have an existing netconf config operation that is neither
>> explicitly sync nor async then the server may return at any time
>> between "intended config" and "applied config".
> Sure.  My time line shows how the new value trickels down from
> intended to oper.
>
>
> /martin
> .
>


From nobody Mon Oct 19 05:57:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008561A9064 for ; Mon, 19 Oct 2015 05:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcxkKa8xcqD7 for ; Mon, 19 Oct 2015 05:57:27 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4601A1F70 for ; Mon, 19 Oct 2015 05:57:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17575; q=dns/txt; s=iport; t=1445259447; x=1446469047; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=VQCjdUNgb/fhscqU0GSSQdtY0Kwenc5CUeM2OwuT1YA=; b=WML1xFvz8MsjV+Ld3yobl5VXYEjp9oAvt4OTIUUnyzV08Rjek7hMxJHG xTDowtC1iqmHu4O41cooZwCCMmJvSU+KM7UE3KKkKTPT1cuwfUejd6eYG u3Z+JgvU8UHluUj7HS4w02Kz8M7u9q5w9ufVQa41Cy7aJNIBOqzQ/ORYi Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DRAQAp6CRW/xbLJq1egmmBIW++DgENgVoXAQmCQ4JwSgKBbhQBAQEBAQEBgQqELQEBAQMBAQEBJEcGBAEFCwsOAwMBAgEJFgQEBwkDAgECARUfCQgGAQwGAgEBiCQIDcMPAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGd4R+hCkBEQEGOhEHhC4Fhz6LHINJiAmFFIFYhDyDAYo6hFqDbx8BAUKCRIFAPTSEJ4FAAQEB
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800";  d="scan'208,217";a="630393726"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Oct 2015 12:57:23 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCvMV5011068; Mon, 19 Oct 2015 12:57:22 GMT
To: Gert Grammel , Martin Bjorklund 
References: <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <5624E8A1.7050502@cisco.com>
Date: Mon, 19 Oct 2015 13:57:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040709090300040905020805"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 12:57:29 -0000

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

Hi Gert,

I'm not sure whether your diagram might have been mangled by email, but 
please can you explain in words when you think that a synchronous 
blocking config event would return.

Thanks,
Rob


On 19/10/2015 13:39, Gert Grammel wrote:
> Martin,
>
> Attempting to apply a config appears to me as a process, not a state. 
> So in my mind the little drawing should look like this then:
>
>
> receive   updated       Attempting to
> intended  intended      apply intended  applied           operational
> config    config         config  config              values
> X----------X-------------------------------------X-------------------X
>      ^
>  this is when "block"
>    would return
>
>
> Gert
>
> From: netmod  > on behalf of Martin Bjorklund 
> >
> Date: Monday 19 October 2015 13:06
> To: "rwilton@cisco.com "  >
> Cc: "netmod@ietf.org "  >
> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for 
> asynchronous systems to provide a blocking config update?
>
> Robert Wilton > wrote:
>
>     On 16/10/2015 22:32, Kent Watsen wrote:
>     >> Will there ever be a server that operates in synchronous mode, given
>     >> that applied will not match intended if hardware is missing?
>     >>
>     >> Will a client ever use "block" mode if it means that it might hang
>     >> forever (or at least until some hw is plugged in)?
>     > I think the key is in the phrase "The server MUST fully *attempt* to
>     > apply..."
>     +1.
>
>
> So today we have this situation:
>
> intended operational
>     config values
>       X--------------------------------------------------X
>       (time ->)
>
>
> When the edit-config returns, running (intended) has been updated, and
> the operational state may or may not have been updated.  Internally to
> the system, there may be a chain of things that need to happen before
> the intended config has been pushed out to all software/hardware
> components.
>
> The NMS/operator writes to intended config, ang verifies by checking
> the operational state.
>
>
> With applied config we have this situation:
>
>
> intended                       applied operational
>     config config              values
>       X------------------------------X-------------------X
>
>
> In some cases, the applied config is an approximation of the
> operational values (if e.g., a single config leaf is used by two
> different components), and in other cases the applied config is just
> one of the internal stages the config value flows through before
> reaching the end component.
>
>
> With async/sync systems we now have:
>
>                       attempted
> intended            applied     applied operational
>     config              config config              values
>       X-------------------X----------X-------------------X
>                           ^
> this is when "block"
> would return
>
>
> To me it seems we're exposing another internal state to the
> NMS/operator.  But in reality nothing has changed from the first
> picture - the NMS/operator still needs to check the operational values
> in order to know that the system behaves as it should.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod
>


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


  
    
  
  
    Hi Gert,

    

    I'm not sure whether your diagram might have been mangled by email,
    but please can you explain in words when you think that a
    synchronous blocking config event would return.

    

    Thanks,

    Rob

    

    

    
On 19/10/2015 13:39, Gert Grammel
      wrote:

    

    

      
      

        Martin,

      

        

      

      

        

          Attempting to apply a config appears to me as a process, not a
          state. So in my mind the little drawing should look like this
          then:

        

          

        

        


          

        

          
receive   updated       Attempting
              to

          
intended  intended      apply intended  
               applied           operational

          
config    config         config          
               config              values

          
X----------X-------------------------------------X-------------------X     

          
     ^                 

          
 this is when "block"

          
   would return

          
    

        

        


        

        

          

        

        

          Gert

        

          

        

      

      
        

          From: netmod <netmod-bounces@ietf.org>
          on behalf of Martin Bjorklund <mbj@tail-f.com>

          Date: Monday 19 October
          2015 13:06

          To: "rwilton@cisco.com"
          <rwilton@cisco.com>

          Cc: "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          opstate-reqs #3: Is there a requirement for asynchronous
          systems to provide a blocking config update?

        

        


        

        

          

            
Robert Wilton
              <rwilton@cisco.com>
              wrote:

            

              
On 16/10/2015 22:32, Kent Watsen wrote:

              
>> Will there ever be a server that operates in
                synchronous mode, given

              
>> that applied will not match intended if
                hardware is missing?

              
>>

              
>> Will a client ever use "block" mode if it
                means that it might hang

              
>> forever (or at least until some hw is
                plugged in)?

              
> I think the key is in the phrase "The server
                MUST fully *attempt* to

              
> apply..."

              
+1.

            

            


            

            
So today we
              have this situation:

          

        

      
      


      

      
        

          

            
  
                intended                                        
                operational

            
    config                                            
                values

            
      X--------------------------------------------------X

            
      (time ->)

            


            

            


            

            
When the
              edit-config returns, running (intended) has been updated,
              and

            
the
              operational state may or may not have been
              updated.  Internally to

            
the system,
              there may be a chain of things that need to happen before

            
the intended
              config has been pushed out to all software/hardware

            
components.

            


            

            
The
              NMS/operator writes to intended config, ang verifies by
              checking

            
the
              operational state.

            


            

            


            

            
With applied
              config we have this situation:

            


            

            


            

            
  
              intended                       applied          
              operational

            
    config                        
              config              values

            
      X------------------------------X-------------------X    
            

            


            

            


            

            
In some
              cases, the applied config is an approximation of the

            
operational
              values (if e.g., a single config leaf is used by two

            
different
              components), and in other cases the applied config is just

            
one of the
              internal stages the config value flows through before

            
reaching the
              end component.

            


            

            


            

            
With
              async/sync systems we now have:

            


            

            
                      attempted

            
  
              intended            applied     applied          
              operational

            
    config              config    
              config              values

            
      X-------------------X----------X-------------------X    
            

            
                          ^

            
                  
              this is when "block"

            
                  
              would return

            
                
            

            


            

            


            

            
To me it
              seems we're exposing another internal state to the

            
NMS/operator.  But
              in reality nothing has changed from the first

            
picture - the
              NMS/operator still needs to check the operational values

            
in order to
              know that the system behaves as it should.

            


            

            


            

            
/martin

            


            

            
_______________________________________________

            
netmod
              mailing list

            
            
            


            

          

        

      
    

    

  


--------------040709090300040905020805--


From nobody Mon Oct 19 06:14:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBA1A909D for ; Mon, 19 Oct 2015 06:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njH7p8K8qH3C for ; Mon, 19 Oct 2015 06:14:20 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC34B1A9098 for ; Mon, 19 Oct 2015 06:14:18 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 13:14:16 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 13:14:15 +0000
From: Kent Watsen 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHRCIv9Q8yGc7JN/0i9oUnVbQsvDp5yi/EA
Date: Mon, 19 Oct 2015 13:14:15 +0000
Message-ID: 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
In-Reply-To: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:LFmY92Y6Vk1kQVWTYkKZKC7Twro9kW092dBRQ7gxlWd8hr93Gw8yNvnX5u2lRvaKB6N9sna9GcIw5WwDOr0t0h7hkytOh9wt3Qjx0svLAgZ9r60jRca0RCK9dv2FTiiPPqcOWPp6UPHUvS0Z1dycaw==; 24:XLwMW35ksw7WQB7t4oYDUJ9NC4M+OHdmr8h9qEUmUWlnw3pzYps3wa7mAl03YCCOd/FJZ6k1ZhnStXIk2PdbCWVEAoziCHRfuf9nkSZZOe8=; 20:FGKZfpJCo2lh2dZjVC1XQj9Fd/7bueA8YwSCQMTJu7ya1IpJ2+N8x151nhlyssoqW0fonDfyeVUY6KHXJNkgRQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
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)(520078)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(479174004)(164054003)(377454003)(189002)(2900100001)(86362001)(15975445007)(4001350100001)(83506001)(50986999)(102836002)(81156007)(99286002)(19580395003)(122556002)(5004730100002)(2950100001)(105586002)(106116001)(87936001)(36756003)(106356001)(10400500002)(5001960100002)(66066001)(19580405001)(76176999)(5002640100001)(5007970100001)(110136002)(54356999)(64706001)(46102003)(97736004)(189998001)(101416001)(5008740100001)(92566002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0661C3A7706BD44C8FA3B93395A4C40F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:14:15.3788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:14:22 -0000

Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent


On 10/16/15, 11:29 PM, "Randy Presuhn" 
wrote:

>Hi -
>
>> From: Robert Wilton
>> Sent: Oct 16, 2015 5:12 AM
>> To: Kent Watsen , Nadeau Thomas
>> Cc: "netmod@ietf.org"
>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>asynchronous systems to provide a blocking config update?
>...
>>    Here is my attempt at word smithing section 3:
>...
>>             A. A server may choose to support only synchronous
>>configuration
>>                operations, or only asynchronous configuration
>>operations, or
>>                both synchronous and asynchronous configuration
>>operations in
>>                a client specified per-operation basis.
>
>Editorial comments:
>  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>    a semantically inappropriate use of the keyword.
>  - please avoid unnecessary anthropomorphisms; the server doesn't
>    "choose" anything here.
>  - s/ in/ on/
>  - s/client specified/client-specified/
>
>...
>>          failed.  A configuration protocol, or server, SHOULD provide
>>          support for rollback-on-error behavior and MAY choose to
>>          provide support for best effort semantics as well.
>
>Editorial comments:
>
>  - The implications of the RFC 2119 SHOULD and MAY are quite different
>    depending on which of the two subjects ("protocol" or "server") one
>    chooses to think about.  The server's observable behaviour is
>presumably
>    circumscribed by the protocol, so I suggest removing ", or server,".
>
>  - Please suppress anthropomorphisms.
>
>  - s/best effort/best-effort/
>
>Randy
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Oct 19 06:15:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC21A909D for ; Mon, 19 Oct 2015 06:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xiLLMQjyoL5G for ; Mon, 19 Oct 2015 06:15:08 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A13E1A90A3 for ; Mon, 19 Oct 2015 06:15:08 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 13:14:45 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 13:14:45 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgCAAAiu5IAAGrQAgAP24QCAAFSCAIAAL0yA
Date: Mon, 19 Oct 2015 13:14:45 +0000
Message-ID: 
References:   <5620E9B3.60009@cisco.com> <20151016.142315.2294973158906063871.mbj@tail-f.com> <5620F6F7.60603@cisco.com>  <5621294A.6040107@cisco.com>  <562146F8.4020503@cisco.com>  <5624E134.1060007@cisco.com>
In-Reply-To: <5624E134.1060007@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:cSmJXCl9EUYpW4VWTRaKtjONeSX7j4TwKMMzoxW6PYFN+XK191p06icws7lvWL4S/uSPeUF+/yZa0UiHdtx+eQYrN725gT6mAmZmlLXph2vDSsOqj3O1G7ci7dPPWoRs3TOHR2kSuCIokvoK+USKsw==; 24:Ly9cqVWCfPxLbzyUenXe18mMXry6/OewGxE95K3TGDhL7Bzvm2Oib3aA4BgElJiMt1ErmN9lKmRzV5aYyjHyAktelZtCv2vhD1k5XSsIZXw=; 20:PvVhlp6uG7WOu5yEuYAcyfoD2GpFiOVrcu6vzrbqKR6K5oE5VbFKal3oyH73BQteZ/0RnRHWWVUqP4z7j6Uziw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(164054003)(53474002)(199003)(24454002)(479174004)(189002)(2900100001)(122556002)(93886004)(5004730100002)(19580405001)(19580395003)(15975445007)(64706001)(5002640100001)(102836002)(66066001)(5007970100001)(19617315012)(87936001)(86362001)(40100003)(189998001)(36756003)(2950100001)(5008740100001)(10400500002)(110136002)(11100500001)(5001960100002)(99286002)(83506001)(106356001)(16236675004)(92566002)(105586002)(106116001)(101416001)(46102003)(76176999)(81156007)(4001350100001)(54356999)(50986999)(97736004)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D24AB1D574B6ggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:14:45.1340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:15:15 -0000

--_000_D24AB1D574B6ggrammeljunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Rob,

From: Robert Wilton >
Date: Monday 19 October 2015 14:25
To: Gert Grammel >
Cc: Kent Watsen >, Martin B=
jorklund >, "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?

Hi Gert,

On 19/10/2015 09:06, Gert Grammel wrote:
Rob,

I think we are describing the same problem from a little different perspect=
ive:
Perhaps, but I'm not sure that we are on the same page yet.
Didn=92t claim that we=92d be on the same page, but at least we appear to l=
ook at the same problem.

Sent from my Apple ][

On 16 Oct 2015, at 20:50, Robert Wilton > wrote:

Hi Gert,

On 16/10/2015 18:14, Gert Grammel wrote:
Rob,

Current implementations are incomplete asynchronous, because they didn't ve=
rify the config as operational and applied.

What is frequently done is to perform additional checks on the intended con=
fig that go beyond a syntax check. That is fine, but I have a hard time to =
consider this to be "hybrid" which suggests something in between asynchrono=
us and synchronous.
I'm talking about netconf servers that effectively apply most of their conf=
iguration before they reply.  E.g. they might take 10 minutes to reply.

Exactly, that's why those servers are running asynchronously. The trouble i=
s that in contrast to the synchronous operation there is no "done" informat=
ion. Current implementations often try to work around that point by applyin=
g more than just a syntax check in the first phase. This way they are still=
 quick in replying are more reliably responding, but still fail from time t=
o time
I don't follow why you think that these servers are running
asynchronously.  They are much closer to handling all config operations
as synchronous blocking calls.  This is a just a small amount of
programming that is being performed asynchronously.

If a configuration would only take some second or so, everyone would probab=
ly be happy to apply synchronous config. Asynchronous config come in, when =
the server would need a long time to apply the config or if the time is unp=
redictable. So when we talk about a config that needs 10 min to be applied,=
 I would consider a synchronous configuration the wrong design choice to st=
art with. A server should reply shortly after receiving the intended config=
 to indicate that they are accepting the config and after e.g. 9:59 minutes=
 come back with an information that the config has successfully been applie=
d. If you mix both information into one you either create a black hole in t=
he beginning of the process (request an intended config and getting feedbac=
k 10min after) or you end up with a grey hole in the end where you know the=
 server is working on it but have no idea when it has finished, so that you=
 can reasonably expect an operational state in line with your config.


Perhaps this isn't a valid Netconf implementation, and all Netconf server i=
mplementations are expected to be asynchronous w.r.t to when they apply the=
ir configuration - but I can't see where this is stated in the NETCONF RFC =
(but possibly I'm not looking in the right place).


>From a client perspective an asynchronous server and a hybrid server look =
the same. The difference is that the asynchronous one should convey a "fini=
shed" information to the client, while the hybrid would remain in a "trust =
me babe" mode forever.
Yes, but this isn't the only difference:
- a client could expect that an asynchronous config operation response shou=
ld be reasonably expedient.
Agree, but this is true for hybrid and asynchronous and the term "reasonabl=
e" is not well defined.
This is true for asynchronous but not hybrid, since a hybrid operation
might return just before a proper synchronous operation would.

What is the level of information the client has before and after this =91re=
turn=92? Before the return, it doesn=92t know if the config is being proces=
sed, and after the return it doesn=92t know if it has been applied. Just li=
ke asynchronous.



   E.g. if a client was to update 10 devices each with a reasonable size co=
nfiguration (that takes minutes to apply) in an asynchronous way then it mi=
ght reasonably consider sequencing the async config requests to each server=
 on one thread.  If each server acknowledged the requests in a couple of se=
conds then all the servers would broadly end up applying the configuration =
concurrently.
Yes, that's why we need asynchronous mode in the first place.
- however, if the servers were hybrid, and their replies were sent much clo=
ser to when the configuration was actually applied then initiating the requ=
ests sequentially would effectively mean that the devices end up applying t=
he configuration serially which would end up taking much longer.  I.e. it s=
eems reasonable that a client may want to differentiate between the behavio=
ur of these two servers even if how it handles the resultant config changes=
 is the same.
It seems your definition of hybrid is something like "asynchronous but with=
 a longer than reasonable response time".
My definition of hybrid (i.e. the default existing netconf config
operations) is along the lines of "asynchronous in behaviour, but may
reply any time between when the intended configuration has been updated
and the applied configuration has been completely updated ".

Understand, but the information available to the client is just the same as=
 for asynchronous: before responding, the client doesn=92t know if the conf=
ig is being processed, and after the response it doesn=92t know if it has b=
een applied. The only difference is that in a proper asynchronous implement=
ation the time between a config request and response is short, while the ti=
me between response and applied config is long. Hybrid tends to move the re=
sponse time out. I don=92t see how in principle it is different from asynch=
ronous.


This is similar to a bloated synchronous operation which takes too much tim=
e to respond.  Both cases are undesired and in both cases the solution is t=
o make them truly asynchronous. So that we can have a reasonable response t=
ime.
I agree with the goal, but it may be difficult to change some existing
NETCONF operational handling to be either strictly sync or async.

Please help me  to understand what you mean with "strictly sync or async=94=
. And in particular why a hybrid (according to your definition) is not asyn=
ch.



Another way to look at hybrids is to consider them "cheating synchronous". =
Given that the new config may not have been applied at the time of the resp=
onse to the client. This is worse than the situation before where a missing=
 verify lets the client know that something may still go on. Clients can't =
tell if servers are cheating :-)
Yes, but clients also need to be able to determine if the server is likely =
to be slow to response, because then the client would probably be designed =
to interact with the server in a different fashion (e.g. use a pool of thre=
ads to initiate the updates concurrently).
How would you do this in practice?
Roughly, I would suggest:

Assuming that this is going to be a new optional to implement extension:
  - There would be a capability to indicate whether a server supports an
explicit sync config operation.
  - There would be a capability to indicate whether a server supports an
explicit async config operation.
  - It would be implicitly assumed that the server would support the
existing default config operation.

In Netconf/Restconf when an edit-config request is made, an extension
would include an option to indicate whether the request should be
processed as sync, async, or default (i.e. existing behaviour).

How would that help the client to figure out how slow the response is likel=
y to be? The fact that a request is synch, asynch or hybrid wouldn=92t tell=
 him how fast it is.

Thanks

Gert

Thanks,
Rob


   Even servers don't know if they're likely to slow a response when they g=
et a request. That's why a quick first response is required that assures th=
e client the requests will be processed, followed by a potentially slow fee=
dback that it is successfully executed (=3Dverified) or failed.
Thanks,
Rob


Gert



Sent from my Apple ][

On 16 Oct 2015, at 18:44, Robert Wilton > wrote:



On 16/10/2015 14:59, Kent Watsen wrote:

      3.  Support for both synchronous and asynchronous configuration
          operations

          A. A server may choose to support only synchronous
configuration
             operations, or only asynchronous configuration operations,
or
             both synchronous and asynchronous configuration operations
in
             a client specified per-operation basis.
I think the most common mode *today* is a mix of sync/async, on a
per-object basis.
Yes, I agree.
Wait, I think we're talking about different things.  Martin, I'm sure that
internal to a NC/RC server, parts of the intended configuration is
actually applied synchronously (e.g., a hostname) whereas other parts are
not (e.g., config for data plane).   But that nuance is not currently
exposed in any way today -right?
I think that today, from what a client sees/experiences, many replies from =
netconf servers fits neither the definition of "synchronous configuration o=
peration" nor "asynchronous configuration operation", but instead, the repl=
y is somewhere between the two extremes.

So the question I was trying to raise is whether servers that need to meet =
the opstate requirements have to change to strictly comply with the defined=
 async or sync config operation semantics?  E.g. not just adding a "done-ap=
plying" option, but perhaps also adding something along the lines of a "don=
e-verifying" option.

Thanks,
Rob


What we're talking about here is an ability for a client to request a
protocol operation (PATCH) to block, or for the "done-applying"
notification to not be sent, until all that processing of the request is
complete.  This regardless if the request contains a mix of nodes that are
applied internally sync/async.  Makes sense? - or it is something else?


          B. Support for synchronous operations as per the definition of
             "synchronous configuration operation".
Doesn't this follow from A?
Yes, possibly.  I don't mind if B is deleted.  If we do this then I
would suggest that we also delete the analogous first sentence of C, and
re-introduce the "(see terms)" text in the headline description.
+1


Kent  // as a contributor


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




--_000_D24AB1D574B6ggrammeljunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <2BF6BB1A9D3D44489ECB776CFBF7AE40@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Rob,









From: Robert Wilton <rwilton@cisco.com>

Date: Monday 19 October 2015 14:25<=
br>
To: Gert Grammel <ggrammel@juniper.net>

Cc: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <<=
a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?













Hi Gert,







On 19/10/2015 09:06, Gert Grammel wrote:




Rob,







I think we are describing the same problem from a little different per=
spective:




Perhaps, but I'm not sure that we are on the same page yet.


Didn=92t claim that we=92d be on the same page, but at least we appear=
 to look at the same problem.









Sent from my Apple ][









On 16 Oct 2015, at 20:50, Robert Wilton <rwilton@cisco.com> wrote:







Hi Gert,









On 16/10/2015 18:14, Gert Grammel wrote:


Rob,







Current implementations are incomplete asynchronous, because they didn=
't verify the config as operational and applied.







What is frequently done is to perform additional checks on the intende=
d config that go beyond a syntax check. That is fine, but I have a hard tim=
e to consider this to be "hybrid" which suggests something in bet=
ween asynchronous and synchronous.




I'm talking about netconf servers that effectively apply most of their=
 configuration before they reply.  E.g. they might take 10 minute=
s to reply.









Exactly, that's why those servers are running asynchronously. The trou=
ble is that in contrast to the synchronous operation there is no "done=
" information. Current implementations often try to work around that p=
oint by applying more than just a syntax check
 in the first phase. This way they are still quick in replying are more rel=
iably responding, but still fail from time to time




I don't follow why you think that these servers are running 


asynchronously.  They are much closer to handling all config=
 operations 


as synchronous blocking calls.  This is a just a small amoun=
t of 


programming that is being performed asynchronously.













If a configuration would only take some second or so, everyone would p=
robably be happy to apply synchronous config. Asynchronous config come in, =
when the server would need a long time to apply the config or if the time i=
s unpredictable. So when we talk
 about a config that needs 10 min to be applied, I would consider a synchro=
nous configuration the wrong design choice to start with. A server should r=
eply shortly after receiving the intended config to indicate that they are =
accepting the config and after e.g.
 9:59 minutes come back with an information that the config has successfull=
y been applied. If you mix both information into one you either create a bl=
ack hole in the beginning of the process (request an intended config and ge=
tting feedback 10min after) or you
 end up with a grey hole in the end where you know the server is working on=
 it but have no idea when it has finished, so that you can reasonably expec=
t an operational state in line with your config.
















Perhaps this isn't a valid Netconf implementation, and all Netconf ser=
ver implementations are expected to be asynchronous w.r.t to when they appl=
y their configuration - but I can't see where this is stated in the NETCONF=
 RFC (but possibly I'm not looking
 in the right place).














>From a client perspective an asynchronous server and a hybrid serv=
er look the same. The difference is that the asynchronous one should convey=
 a "finished" information to the client, while the hybrid would r=
emain in a "trust me babe" mode forever.




Yes, but this isn't the only difference:


- a client could expect that an asynchronous config operation response=
 should be reasonably expedient.




Agree, but this is true for hybrid and asynchronous and the term "=
;reasonable" is not well defined.




This is true for asynchronous but not hybrid, since a hybrid operation=
 


might return just before a proper synchronous operation would.








What is the level of information the client has before and after this =
=91return=92? Before the return, it doesn=92t know if the config is being p=
rocessed, and after the return it doesn=92t know if it has been applied. Ju=
st like asynchronous.






















   E.g. if a client was to update 10 devices each with a rea=
sonable size configuration (that takes minutes to apply) in an asynchronous=
 way then it might reasonably consider sequencing the async config requests=
 to each server on one thread.  If each server
 acknowledged the requests in a couple of seconds then all the servers woul=
d broadly end up applying the configuration concurrently.




Yes, that's why we need asynchronous mode in the first place.




- however, if the servers were hybrid, and their replies were sent muc=
h closer to when the configuration was actually applied then initiating the=
 requests sequentially would effectively mean that the devices end up apply=
ing the configuration serially which
 would end up taking much longer.  I.e. it seems reasonable that =
a client may want to differentiate between the behaviour of these two serve=
rs even if how it handles the resultant config changes is the same.




It seems your definition of hybrid is something like "asynchronou=
s but with a longer than reasonable response time".




My definition of hybrid (i.e. the default existing netconf config 

operations) is along the lines of "asynchronous in behaviour, but=
 may 


reply any time between when the intended configuration has been update=
d 


and the applied configuration has been completely updated ".







Understand, but the information available to the client is just the sa=
me as for asynchronous: before responding, the client doesn=92t know if the=
 config is being processed, and after the response it doesn=92t know if it =
has been applied. The only difference
 is that in a proper asynchronous implementation the time between a config =
request and response is short, while the time between response and applied =
config is long. Hybrid tends to move the response time out. I don=92t see h=
ow in principle it is different from
 asynchronous.















This is similar to a bloated synchronous operation which takes too muc=
h time to respond.  Both cases are undesired and in both cases th=
e solution is to make them truly asynchronous. So that we can have a reason=
able response time.




I agree with the goal, but it may be difficult to change some existing=
 


NETCONF operational handling to be either strictly sync or async.








Please help me  to understand what you mean with "strictly s=
ync or async=94. And in particular why a hybrid (according to your definiti=
on) is not asynch.




   
















Another way to look at hybrids is to consider them "cheating sync=
hronous". Given that the new config may not have been applied at the t=
ime of the response to the client. This is worse than the situation before =
where a missing verify lets the client know
 that something may still go on. Clients can't tell if servers are cheating=
 :-)




Yes, but clients also need to be able to determine if the server is li=
kely to be slow to response, because then the client would probably be desi=
gned to interact with the server in a different fashion (e.g. use a pool of=
 threads to initiate the updates
 concurrently).




How would you do this in practice?




Roughly, I would suggest:







Assuming that this is going to be a new optional to implement extensio=
n:


  - There would be a capability to indicate whether a server=
 supports an 


explicit sync config operation.


  - There would be a capability to indicate whether a server=
 supports an 


explicit async config operation.


  - It would be implicitly assumed that the server would sup=
port the 


existing default config operation.







In Netconf/Restconf when an edit-config request is made, an extension =



would include an option to indicate whether the request should be 

processed as sync, async, or default (i.e. existing behaviour).








How would that help the client to figure out how slow the response is =
likely to be? The fact that a request is synch, asynch or hybrid wouldn=92t=
 tell him how fast it is.







Thanks







Gert








Thanks,


Rob














   Even servers don't know if they're likely to slow a respo=
nse when they get a request. That's why a quick first response is required =
that assures the client the requests will be processed, followed by a poten=
tially slow feedback that it is successfully
 executed (=3Dverified) or failed.




Thanks,


Rob














Gert

















Sent from my Apple ][









On 16 Oct 2015, at 18:44, Robert Wilton <rwilton@cisco.com> wrote:



















On 16/10/2015 14:59, Kent Watsen wrote:













      3.  Support for both syn=
chronous and asynchronous configuration


          operations=








          A. A serve=
r may choose to support only synchronous


configuration


           &nbs=
p; operations, or only asynchronous configuration operations,


or


           &nbs=
p; both synchronous and asynchronous configuration operations


in


           &nbs=
p; a client specified per-operation basis.




I think the most common mode *today* is a mix of sync/async, on a

per-object basis.




Yes, I agree.




Wait, I think we're talking about different things.  Martin,=
 I'm sure that


internal to a NC/RC server, parts of the intended configuration is

actually applied synchronously (e.g., a hostname) whereas other parts =
are


not (e.g., config for data plane).   But that nuance is not =
currently


exposed in any way today -right?




I think that today, from what a client sees/experiences, many replies =
from netconf servers fits neither the definition of "synchronous confi=
guration operation" nor "asynchronous configuration operation&quo=
t;, but instead, the reply is somewhere between the
 two extremes.







So the question I was trying to raise is whether servers that need to =
meet the opstate requirements have to change to strictly comply with the de=
fined async or sync config operation semantics?  E.g. not just ad=
ding a "done-applying" option, but perhaps
 also adding something along the lines of a "done-verifying" opti=
on.







Thanks,


Rob














What we're talking about here is an ability for a client to request a<=
/div>

protocol operation (PATCH) to block, or for the "done-applying&qu=
ot;


notification to not be sent, until all that processing of the request =
is


complete.  This regardless if the request contains a mix of =
nodes that are


applied internally sync/async.  Makes sense? - or it is some=
thing else?






















          B. Support=
 for synchronous operations as per the definition of


           &nbs=
p; "synchronous configuration operation".




Doesn't this follow from A?




Yes, possibly.  I don't mind if B is deleted.  If =
we do this then I


would suggest that we also delete the analogous first sentence of C, a=
nd


re-introduce the "(see terms)" text in the headline descript=
ion.




+1












Kent  // as a contributor












.




_______________________________________________


netmod mailing list






.






.






















--_000_D24AB1D574B6ggrammeljunipernet_--


From nobody Mon Oct 19 06:20:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C441A90BC for ; Mon, 19 Oct 2015 06:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.134
X-Spam-Level: 
X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZB0sB7j7A_O for ; Mon, 19 Oct 2015 06:20:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889851A90C8 for ; Mon, 19 Oct 2015 06:20:01 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 13:19:59 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 13:19:59 +0000
From: Gert Grammel 
To: Robert Wilton , Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgAezuICAGeDcgIAARaqAgADf/wCAAALfgIABe+iAgAAC+4CAAAzWgP//yt8AgABxHgD//8ZaAIAAb4+A///XgwAAh5lYgAAB0CwAAAdspYD//+OCgIAAJ+oA
Date: Mon, 19 Oct 2015 13:19:58 +0000
Message-ID: 
References: <20151016.215651.738952339662172367.mbj@tail-f.com>  <5624C289.6030203@cisco.com> <20151019.130628.1751760450891248750.mbj@tail-f.com>  <5624E8A1.7050502@cisco.com>
In-Reply-To: <5624E8A1.7050502@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB041; 5:o2G18uWJ+5kuYj+apc/GBMI8AAgSH5ETkJfpi7C6c7fgJOzaBUWthTQaYfWp8i45W0xvH56Of1zP+K5Kvics0yjyUdgKl8mmR73N+swvP23issVEJGmi6kXUXGpGeHK2Adq9Tn39LItbaKOL5ZZZXA==; 24:Hoy/hxlwxGXtJ8WY+S0cHHtfSkNN7YSvWt2c9jXqWQCABD1d9V4NZKOAfIbz+ROen/sy6biMX5hnsxmKPxFisz/jaTCTBNaWLVLmqyg/2oc=; 20:XXve6z6VDCjZUAUGX0vSJqZCskyHwhr7Tyw8tQV+7UMYmQ/Zp0T2j+sYcdZXDHLy0w5Z7rLqjQBCHiwaUVyddg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB041; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB041; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(479174004)(164054003)(24454002)(189002)(36756003)(76176999)(5008740100001)(5002640100001)(99286002)(10400500002)(5001920100001)(16236675004)(86362001)(92566002)(87936001)(5001770100001)(105586002)(106116001)(4001350100001)(106356001)(101416001)(81156007)(83506001)(5001960100002)(50986999)(19580405001)(19580395003)(2950100001)(2900100001)(93886004)(11100500001)(5007970100001)(19617315012)(97736004)(46102003)(54356999)(15975445007)(102836002)(5004730100002)(64706001)(122556002)(189998001)(40100003)(66066001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB041; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24AB9B574FEggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:19:59.0060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB041
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:20:05 -0000

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


Hi Rob,

Guess we have a terminology issue here, hope that one cuts it:
                      attempt to
   intended            apply       applied           operational
    config              config     config              values
      X-------------------X----------X-------------------X
                          ^
                   this is when "block"
                   would return


From: Robert Wilton >
Date: Monday 19 October 2015 14:57
To: Gert Grammel >, Marti=
n Bjorklund >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?

Hi Gert,

I'm not sure whether your diagram might have been mangled by email, but ple=
ase can you explain in words when you think that a synchronous blocking con=
fig event would return.

Thanks,
Rob


On 19/10/2015 13:39, Gert Grammel wrote:
Martin,

Attempting to apply a config appears to me as a process, not a state. So in=
 my mind the little drawing should look like this then:


receive   updated       Attempting to
intended  intended      apply intended    applied           operational
config    config         config            config              values
X----------X-------------------------------------X-------------------X
     ^
 this is when "block"
   would return



Gert

From: netmod <netmod-bounces@ietf.org> on behalf of Martin Bjorklund >
Date: Monday 19 October 2015 13:06
To: "rwilton@cisco.com"=
 >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?

Robert Wilton > wrote:
On 16/10/2015 22:32, Kent Watsen wrote:
>> Will there ever be a server that operates in synchronous mode, given
>> that applied will not match intended if hardware is missing?
>>
>> Will a client ever use "block" mode if it means that it might hang
>> forever (or at least until some hw is plugged in)?
> I think the key is in the phrase "The server MUST fully *attempt* to
> apply..."
+1.

So today we have this situation:

   intended                                         operational
    config                                             values
      X--------------------------------------------------X
      (time ->)


When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated.  Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.

The NMS/operator writes to intended config, ang verifies by checking
the operational state.


With applied config we have this situation:


   intended                       applied           operational
    config                         config              values
      X------------------------------X-------------------X


In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.


With async/sync systems we now have:

                      attempted
   intended            applied     applied           operational
    config              config     config              values
      X-------------------X----------X-------------------X
                          ^
                   this is when "block"
                   would return



To me it seems we're exposing another internal state to the
NMS/operator.  But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.


/martin

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



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












Hi Rob,







Guess we have a terminolog=
y issue here, hope that one cuts it: 







             =
;         attempt to


   intended    &n=
bsp;       apply       ap=
plied           operation=
al


    config   =
;           config&n=
bsp;    config       &nbs=
p;      values


      X----------=
---------X----------X-------------------X    

        =
;            &n=
bsp;     ^


        =
;           this is when =
"block"


        =
;           would return<=
/font>






















From: Robert Wilton <rwilton@cisco.com>

Date: Monday 19 October 2015 14:57<=
br>
To: Gert Grammel <ggrammel@juniper.net>, Martin Bjorklund &l=
t;mbj@tail-f.com>

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

Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?











Hi Gert,



I'm not sure whether your diagram might h=
ave been mangled by email, but please can you explain in words when you thi=
nk that a synchronous blocking config event would return.



Thanks,

Rob






=
On 19/10/2015 13:39, Gert Grammel wrote:







Martin,











Attempting to apply a config appears to me as a process, not a state. So in=
 my mind the little drawing should look like this then:















receive   updated      &nbs=
p;Attempting to


intended  intended      apply intended    ap=
plied           operation=
al


config    config         config    =
;        config      &nbs=
p;       values


X----------X-------------------------------------X-------------------X&nbs=
p;    


     ^               &nb=
sp; 


 this is when "block"


   would return


    
















Gert












From: netmod <netmod-bounces@iet=
f.org> on behalf of Martin Bjorklund <mbj@tail-f.com>

Date: Monday 19 October 2015 13:06<=
br>
To: "rwilton@cisco.com" <rwilton@cisco.com<=
/a>>

Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?













Robert Wilton <rwilton@cisco.com=
> wrote:




On 16/10/2015 22:32, Kent Watsen wrote:


>> Will there ever be a server that operates in synchronous mode=
, given


>> that applied will not match intended if hardware is missing?<=
/div>

>>


>> Will a client ever use "block" mode if it means tha=
t it might hang


>> forever (or at least until some hw is plugged in)?


> I think the key is in the phrase "The server MUST fully *att=
empt* to


> apply..."


+1.









So today we have this situ=
ation:

















&nb=
sp;  intended         &nb=
sp;            =
            &nb=
sp;      operational


&nb=
sp;   config        =
            &nb=
sp;            =
            values


&nb=
sp;     X-----------------------------------------=
---------X


&nb=
sp;     (time ->)












When the edit-config retur=
ns, running (intended) has been updated, and


the operational state may =
or may not have been updated.  Internally to


the system, there may be a=
 chain of things that need to happen before


the intended config has be=
en pushed out to all software/hardware


components.







The NMS/operator writes to=
 intended config, ang verifies by checking


the operational state.











With applied config we hav=
e this situation:












   intended =
;            &n=
bsp;         applied  &nb=
sp;        operational


    co=
nfig            =
;             c=
onfig           &nbs=
p;  values


    &n=
bsp; X------------------------------X-------------------X  &=
nbsp; 













In some cases, the applied=
 config is an approximation of the


operational values (if e.g=
., a single config leaf is used by two


different components), and=
 in other cases the applied config is just


one of the internal stages=
 the config value flows through before


reaching the end component=
.












With async/sync systems we=
 now have:







        =
;            &n=
bsp; attempted


   intended    &n=
bsp;       applied   &nbs=
p; applied           oper=
ational


    config   =
;           config&n=
bsp;    config       &nbs=
p;      values


      X----------=
---------X----------X-------------------X    



        =
;            &n=
bsp;     ^


        =
;           this is when =
"block"


        =
;           would return<=
/font>


        =
;         












To me it seems we're expos=
ing another internal state to the


NMS/operator.  B=
ut in reality nothing has changed from the first


picture - the NMS/operator=
 still needs to check the operational values


in order to know that the =
system behaves as it should.












/martin







__________________________=
_____________________


netmod mailing list
























--_000_D24AB9B574FEggrammeljunipernet_--


From nobody Mon Oct 19 06:22:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D761A21C4 for ; Mon, 19 Oct 2015 06:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co8IhM7G4gTR for ; Mon, 19 Oct 2015 06:22:50 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14841A21B9 for ; Mon, 19 Oct 2015 06:22:49 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 13:22:44 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 13:22:44 +0000
From: Kent Watsen 
To: Kent Watsen , Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHRCIv9Q8yGc7JN/0i9oUnVbQsvDp5yi/EAgAACX4A=
Date: Mon, 19 Oct 2015 13:22:43 +0000
Message-ID: 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:SPw4Mkh2Fnrf9qPT44Jo6ZtZ8fd9kpmsWjqunqp5wmSdVm5lVhej3rUxWim+3OC8SGV4RMLvHqJ1YmL1+9wjL5FAeT28pqIsmsMYuIc10VyzttEesbqPQ7kz8g1tLUTq3Y5Jk1//nD8A7iN1erXk+A==; 24:qjlD1mskPhI4CxhRXx233t7xuwGNb7kr4OxSltXP66LHwiTVfh60VMXrdHZ7XXaYvFp05q5KjmaBID7oXfjqnENqYZ27GuMreMaRbWk4ntE=; 20:kwAZ2w5hvgA6btxguHbt6x743zpWHxpol29wXzeitWJBmqMcMYSRTPCcbW+kxxU5qjFrJ8Uwo7IvdyM/FVNiKQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(189002)(164054003)(377454003)(199003)(5002640100001)(5007970100001)(76176999)(19580405001)(5001960100002)(66066001)(5008740100001)(92566002)(101416001)(40100003)(64706001)(5001770100001)(1941001)(54356999)(11100500001)(97736004)(189998001)(46102003)(50986999)(102836002)(99286002)(81156007)(19580395003)(122556002)(4001350100001)(15975445007)(2900100001)(86362001)(83506001)(36756003)(87936001)(10400500002)(106356001)(5004730100002)(106116001)(2950100001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:22:43.8012 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:22:54 -0000

I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:

>Hi Rob,
>
>I know there is an on-going discussion about the time-line of things, but
>the draft needs to be posted today...  Can you help finalize the text?
>
>Randy offers some good editorial suggestions below, and I believe you and
>Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>
>Thanks,
>Kent
>
>
>On 10/16/15, 11:29 PM, "Randy Presuhn" 
>wrote:
>
>>Hi -
>>
>>> From: Robert Wilton
>>> Sent: Oct 16, 2015 5:12 AM
>>> To: Kent Watsen , Nadeau Thomas
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>asynchronous systems to provide a blocking config update?
>>...
>>>    Here is my attempt at word smithing section 3:
>>...
>>>             A. A server may choose to support only synchronous
>>>configuration
>>>                operations, or only asynchronous configuration
>>>operations, or
>>>                both synchronous and asynchronous configuration
>>>operations in
>>>                a client specified per-operation basis.
>>
>>Editorial comments:
>>  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>    a semantically inappropriate use of the keyword.
>>  - please avoid unnecessary anthropomorphisms; the server doesn't
>>    "choose" anything here.
>>  - s/ in/ on/
>>  - s/client specified/client-specified/
>>
>>...
>>>          failed.  A configuration protocol, or server, SHOULD provide
>>>          support for rollback-on-error behavior and MAY choose to
>>>          provide support for best effort semantics as well.
>>
>>Editorial comments:
>>
>>  - The implications of the RFC 2119 SHOULD and MAY are quite different
>>    depending on which of the two subjects ("protocol" or "server") one
>>    chooses to think about.  The server's observable behaviour is
>>presumably
>>    circumscribed by the protocol, so I suggest removing ", or server,".
>>
>>  - Please suppress anthropomorphisms.
>>
>>  - s/best effort/best-effort/
>>
>>Randy
>>
>>_______________________________________________
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Oct 19 06:37:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4801A1BC2 for ; Mon, 19 Oct 2015 06:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V16qBtfPiyjr for ; Mon, 19 Oct 2015 06:37:48 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6710B1A1BBB for ; Mon, 19 Oct 2015 06:37:48 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 13:37:46 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 13:37:45 +0000
From: Gert Grammel 
To: Kent Watsen , Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHRCIv9Q8yGc7JN/0i9oUnVbQsvDp5yi/EAgAACX4CAAGjIgA==
Date: Mon, 19 Oct 2015 13:37:45 +0000
Message-ID: 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:A1HEchyYPu6jrcNwRBI5BTcZgLzTx0+Eu85eAgUsNl7iMZDZcClMDwAbFXkYSc9oEujBQEekDtKeQjITty7wqyMC8laK7Lswa8sWPsmAHOWT6TT2IgZMnluwZfMibV9XA4wx3gcjEMTsWMtr2tfwuw==; 24:dONaNgwbxkGZ+H9rs6zh7U+VU8dEh/RRU3goZ4QJGJW0Uo1TDlR/R7vUQo1zDbxtjCijVqkj328wcDf7dUUwpRPKpGo2eIG6gViv+K1JNwQ=; 20:bv5AX80CwgUnm9PZ00U6S0evp3ZoMrGuf9dnbAgEojKLZ6zOswBpG9jej7jPQFquBC6z/XOQwYbgS145pzwSGw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(164054003)(24454002)(199003)(377454003)(189002)(5001770100001)(66066001)(122556002)(64706001)(97736004)(189998001)(83506001)(2900100001)(5004730100002)(99286002)(5007970100001)(2950100001)(101416001)(87936001)(92566002)(5008740100001)(81156007)(40100003)(106116001)(106356001)(76176999)(1941001)(19580395003)(4001350100001)(54356999)(19580405001)(5002640100001)(15975445007)(102836002)(50986999)(10400500002)(105586002)(5001960100002)(36756003)(46102003)(16236675004)(19617315012)(86362001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D24ABBDA750Cggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:37:45.8588 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:37:53 -0000

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

Hi Kent,

Here my proposals

   3.  Support for both synchronous and asynchronous configuration
       operations (see terms)

       A. A server may only support synchronous configuration
          operations, or may only support asynchronous configuration
          operations, or may support synchronicity to be client
          specified on a per-operation basis.

NEW   A. The way a server executes an operation (synchronous or asynchronou=
s) is implementation specific and may change on a per-operation basis.

       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request or errors from
          applying the configuration change.

NEW (changed OR into AND)
       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request and errors from
          applying the configuration change.

OK
       D. Support for asynchronous configuration operations
          requires the server to send a response to the client
          immediately indicated that the request was accepted
          and send a notification to the client when the intended
          config is fully effective or there are any errors from
          applying the configuration change.
OK
       E. Support for asynchronous configuration operations MAY
          also provide a verify operation which a client can request
          from the server to obtain information regarding the
          difference between the intended and applied configurations.










From: netmod > on b=
ehalf of Kent Watsen >
Date: Monday 19 October 2015 15:22
To: Kent Watsen >, Robert W=
ilton >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?


I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen" > wrote:

Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent


On 10/16/15, 11:29 PM, "Randy Presuhn" >
wrote:

Hi -

From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
asynchronous systems to provide a blocking config update?
...
    Here is my attempt at word smithing section 3:
...
             A. A server may choose to support only synchronous
configuration
                operations, or only asynchronous configuration
operations, or
                both synchronous and asynchronous configuration
operations in
                a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
    a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
    "choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
          failed.  A configuration protocol, or server, SHOULD provide
          support for rollback-on-error behavior and MAY choose to
          provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
    depending on which of the two subjects ("protocol" or "server") one
    chooses to think about.  The server's observable behaviour is
presumably
    circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

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

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

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


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









Hi Kent,







Here my proposals











   3.  Support for both synchronous and asynchrono=
us configuration


       operations (see terms)







       A. A server may only support sync=
hronous configuration


          operations=
, or may only support asynchronous configuration


          operations=
, or may support synchronicity to be client


          specified =
on a per-operation basis.







NEW   A. The way a server executes an operation (synchronous or a=
synchronous) is implementation specific and may change on a per-operation b=
asis.







       C. Support for synchronous config=
uration operations


          requires t=
he server to block sending a response to


          the client=
 until it is able to able to determine whether


          there are =
any errors in the request or errors from


          applying t=
he configuration change.







NEW (changed OR into AND)




       C. Support for synchronous configuration op=
erations


          requires t=
he server to block sending a response to


          the client=
 until it is able to able to determine whether


          there are =
any errors in the request and errors from


          applying t=
he configuration change.




    


OK


       D. Support for asynchronous confi=
guration operations


          requires t=
he server to send a response to the client


          immediatel=
y indicated that the request was accepted


          and send a=
 notification to the client when the intended


          config is =
fully effective or there are any errors from


          applying t=
he configuration change.


OK


       E. Support for asynchronous confi=
guration operations MAY


          also provi=
de a verify operation which a client can request


          from the s=
erver to obtain information regarding the


          difference=
 between the intended and applied configurations.




























































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

Date: Monday 19 October 2015 15:22<=
br>
To: Kent Watsen <kwatsen@juniper.net>, Robert Wilton <rwilton@cisco.com>

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

Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?


















I meant 3.D, and so did you I think when you wrote on the 16th "E=
.g.


change the 1.D text to..."







Sorry for the confusion.







Kent












On 10/19/15, 9:14 AM, "Kent Watsen" <kwatsen@juniper.net> wrote:









Hi Rob,







I know there is an on-going discussion about the time-line of things, =
but


the draft needs to be posted today...  Can you help finalize=
 the text?







Randy offers some good editorial suggestions below, and I believe you =
and


Gert had some ideas in wordsmithing 1.D. and bringing in error modes.<=
/div>






Thanks,


Kent












On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_presuhn@mindspring.com>


wrote:









Hi -









From: Robert Wilton


Sent: Oct 16, 2015 5:12 AM


To: Kent Watsen , Nadeau Thomas



Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for

asynchronous systems to provide a blocking config update?




...




    Here is my attempt at word smithing section 3:=





...




           &nbs=
p; A. A server may choose to support only synchronous


configuration


           &nbs=
p;    operations, or only asynchronous configuration

operations, or


           &nbs=
p;    both synchronous and asynchronous configuration

operations in


           &nbs=
p;    a client specified per-operation basis.









Editorial comments:


  - is the "may" intended as a RFC 2119 MAY? =
 If so, this seems


    a semantically inappropriate use of the keywor=
d.


  - please avoid unnecessary anthropomorphisms; the server d=
oesn't


    "choose" anything here.


  - s/ in/ on/


  - s/client specified/client-specified/







...




          failed.&nb=
sp; A configuration protocol, or server, SHOULD provide


          support fo=
r rollback-on-error behavior and MAY choose to


          provide su=
pport for best effort semantics as well.









Editorial comments:







  - The implications of the RFC 2119 SHOULD and MAY are quit=
e different


    depending on which of the two subjects ("=
protocol" or "server") one


    chooses to think about.  The server'=
s observable behaviour is


presumably


    circumscribed by the protocol, so I suggest re=
moving ", or server,".







  - Please suppress anthropomorphisms.







  - s/best effort/best-effort/







Randy







_______________________________________________


netmod mailing list











_______________________________________________


netmod mailing list











_______________________________________________


netmod mailing list
















--_000_D24ABBDA750Cggrammeljunipernet_--


From nobody Mon Oct 19 06:41:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46C01A1F16 for ; Mon, 19 Oct 2015 06:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScBhBEVmwup7 for ; Mon, 19 Oct 2015 06:41:54 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20FA1A1B62 for ; Mon, 19 Oct 2015 06:41:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3341; q=dns/txt; s=iport; t=1445262113; x=1446471713; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ZiIEbWwGio06V+LtZmWPzHCl746sC91VlNMmuaKWwFk=; b=SahKFneOnPYBbVG3xptiGjhHZguGKtEStGbVfTnOLQJC+EP+nehHXkVv /TTxZA7IZL2k3jwT8TpM4EO/HGMRyatydsY/iP8+5Ec4ArygPQ5o3zLtG EzSiENBsuLyJmpcxrJcXMht5DS2RctqqfQOyVKIT8qGx375YgIiaBAVZZ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBACx8SRW/xbLJq1ehApvv3YXCoUzSgKCAwEBAQEBAYELhC0BAQEDAQEBATU2ChELEQQBAQEJFgQLCQMCAQIBFSgIBgEMBgIBAYgkCA3DGwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhneEfoRCUoQuAQSHMwiHB4QYg0mNHYFYhDyDAYo6hFqDb2OCRIFAPTSFZwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,702,1437436800"; d="scan'208";a="605801117"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2015 13:41:51 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9JDfpSP015915; Mon, 19 Oct 2015 13:41:51 GMT
To: Randy Presuhn , "netmod@ietf.org" 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
From: Robert Wilton 
Message-ID: <5624F30E.9020403@cisco.com>
Date: Mon, 19 Oct 2015 14:41:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:41:55 -0000

Hi Randy,

Thanks for the comments.

On 17/10/2015 04:29, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton
>> Sent: Oct 16, 2015 5:12 AM
>> To: Kent Watsen , Nadeau Thomas
>> Cc: "netmod@ietf.org"
>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
> ...
>>     Here is my attempt at word smithing section 3:
> ...
>>              A. A server may choose to support only synchronous configuration
>>                 operations, or only asynchronous configuration operations, or
>>                 both synchronous and asynchronous configuration operations in
>>                 a client specified per-operation basis.
> Editorial comments:
>    - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>      a semantically inappropriate use of the keyword.
No, I don't think that is intended as an RFC 2119 MAY.

>    - please avoid unnecessary anthropomorphisms; the server doesn't
>      "choose" anything here.
>    - s/ in/ on/
>    - s/client specified/client-specified/
All three fixed.

Proposed updated text for 3.A:

        A. A server may support only synchronous configuration
           operations, or only asynchronous configuration operations, or
           both synchronous and asynchronous configuration operations on
           a client-specified per-operation basis.

>
> ...
>>           failed.  A configuration protocol, or server, SHOULD provide
>>           support for rollback-on-error behavior and MAY choose to
>>           provide support for best effort semantics as well.
> Editorial comments:
>
>    - The implications of the RFC 2119 SHOULD and MAY are quite different
>      depending on which of the two subjects ("protocol" or "server") one
>      chooses to think about.  The server's observable behaviour is presumably
>      circumscribed by the protocol, so I suggest removing ", or server,".
>
>    - Please suppress anthropomorphisms.
>
>    - s/best effort/best-effort/
I had reworded 3.D based on Gert's comments.  Folding in your comments 
above to that text produces:

        D. The configuration protocol MUST specify how configuration
           errors are handled.  Errors could be handled by "stop-on-error",
           "continue-on-error" or "rollback-on-error" semantics (see
           terms).  Support for "rollback-on-error" SHOULD be provided.


  Extra term to add the definitions (based on the definitions for 
NETCONF RFC):

           stop-on-error:  The configuration operation is aborted on the 
first
             error.

          continue-on-error:  Continue to process configuration data on
             error; error is recorded, and negative response is generated
             if any errors occur.

          rollback-on-error:  If an error condition occurs such that part
             of applying the configuration fails, the server will stop
             processing the configuration operation and restore the
             specified configuration to its complete state at the start
             of this configuration operation.

Thanks,
Rob

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


From nobody Mon Oct 19 06:49:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4A1A1EED for ; Mon, 19 Oct 2015 06:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YzXADBwd-e2 for ; Mon, 19 Oct 2015 06:49:28 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62081A1A58 for ; Mon, 19 Oct 2015 06:49:27 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 13:49:24 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 13:49:22 +0000
From: Kent Watsen 
To: Gert Grammel 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYCAAH4CgIAAlLEAgACmPICABwJLAIABHweAgAAmTwCAAEpTgIAKOLkAgAH6AYCAADWigIABPlAAgAANt4CAACtqAP//xOgAgACozIGAALIfAIAAS+nk///OgQCAAFz6ZIAEQMOA
Date: Mon, 19 Oct 2015 13:49:22 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>  <560D01D1.5000607@cisco.com>  <5613D3C1.3020903@cisco.com> <20151006161634.GB50204@elstar.local> <5614323D.5000507@cisco.com> <20151013084814.GA66064@elstar.local> <561E6DC5.1080402@cisco.com>   <561FB149.103@cisco.com>   <58A7E15C-2DCD-4245-8E64-26F9C5F45F59@juniper.net>  <381B554A-3421-4AC9-AB9B-FB2F6C670C3E@juniper.net>  <134E86B5-8C51-4C56-ADEC-6973CB68724B@juniper.net>
In-Reply-To: <134E86B5-8C51-4C56-ADEC-6973CB68724B@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB043; 5:uZutEU664KY0WIPmleHIraJZkyFjV+X7dJnFcTLgUbDtCBnIeZy58fIK+bggqTFD+OfAu7MF3VAktP50IPqkSbLf5WZhzk7i4CSAoM15yeftAn4dskvWV06Ri3OMxY5D1TG5oTw5JY0TSOgSqBqt0A==; 24:I6HdWK86K6eGfMUykZfESEDVFbdG8TEFhuMjPoGHfTnuGkEvQRerf/LLLQDh/ykHLOGvgMoc7z9eQE3OXJ3AEvG8kVjx8u1/N3BIWqo5oMg=; 20://d2WDA0Mon6wnAD6If9CprfjiOnLlh1o0tAu1u3Yc4ow0OX+kKU/2eKsKTFZeB1Y6hT8r5q4ic/hvHCEnQb9A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB043;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BN1PR05MB043; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB043; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(43784003)(76104003)(377454003)(189002)(24454002)(106356001)(16236675004)(122556002)(66066001)(110136002)(92566002)(5008740100001)(4001450100002)(40100003)(93886004)(561944003)(102836002)(46102003)(2900100001)(189998001)(83506001)(64706001)(101416001)(5007970100001)(54356999)(76176999)(4001350100001)(50986999)(97736004)(106116001)(5001960100002)(36756003)(5002640100001)(5004730100002)(10400500002)(86362001)(19580395003)(2950100001)(19580405001)(105586002)(81156007)(99286002)(1941001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D24A6B73E7E9Bkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 13:49:22.5672 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:49:34 -0000

--_000_D24A6B73E7E9Bkwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks you all for the word smithing.  The final draft text follows:

   This document defines the following terms:

   Synchronous configuration operation:   A configuration request to
       update the running configuration of a server that is applied
       synchronously with respect to the client request (i.e. a blocking
       call).  The server MUST fully attempt to apply the configuration
       change to all impacted components in the server, updating both
       the server's intended and applied configuration (see terms),
       before replying to the client.  The reply to the client indicates
       whether there are any errors in the request or errors from
       applying the configuration change.

   Asynchronous configuration operation:   A configuration request to
       update the running configuration of a server that is applied
       asynchronously with respect to the client request.  The server
       MUST update its intended configuration (see term) before replying
       to the client indicating whether the request will be processed.
       This reply to the client only indicates whether there are any
       errors in the original request.  The server's applied
       configuration state (see term) is updated after the configuration
       change has been fully effected to all impacted components in the
       server.  Once applied, there MUST be a mechanism for the client
       to determine when the request has completed processing and
       whether the intended config is now fully effective or there are
       any errors from applying the configuration change, which could be
       from an asynchronous notification or via a client operation.


Issue #6 will be moved to the REVIEW state - as the draft will be out short=
ly.

Thanks again,
Kent  // as a contributor


From: Gert Grammel >
Date: Friday, October 16, 2015 at 12:52 PM
To: Kent Watsen >
Cc: Robert Wilton >, "netmod@ie=
tf.org" >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy=
nchronous (esp. wrt intended and applied)

Ok,

The term 'intended config is updated' is probably correct but sounds a bit =
odd to me.    I associate with "update" a process of alignment. In the case=
 of intended config it is more like a config that is imposed by the client.=
 Later the update of the applied config is started.

Certainly a terminology issue, but I wanted to bring it up maybe others app=
ly similar semantics.


Gert


Sent from my Apple ][

On 16 Oct 2015, at 17:19, Kent Watsen > wrote:


> Why is there a need to update the intended config?

Because that is what happens via requests like  and PATCH.  Th=
e intended (running) config gets updated first and then config is distribut=
ed to internal components, ultimately updated the applied config.

Kent  // as a contributor


From: Gert Grammel >
Date: Friday, October 16, 2015 at 10:16 AM
To: Kent Watsen >
Cc: Robert Wilton >, "netmod@ie=
tf.org" >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy=
nchronous (esp. wrt intended and applied)

Kent,

The new one looks much better. However the last sentence is confusing with =
respect to intended config. Why is there a need to update the intended conf=
ig?

Proposal:
The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating the server's applied configuration (see terms),
    before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen > wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers=
.

Thank you (and Juergen) for the confirmation.   Again, if no objections, th=
ese two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning=
 of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as b=
eing discussed elsewhere on this thread]

OLD:

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request.  The server MUST fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.

NEW

    Synchronous configuration operation - A configuration request to update
    the running configuration of a server that is applied synchronously wit=
h
    respect to the client request (i.e. a blocking call).  The server MUST =
fully attempt to apply
    the configuration change to all impacted components in the server,
    updating both the server's intended and applied configuration (see term=
s),
    before replying to the client.


What do you think?

Kent


--_000_D24A6B73E7E9Bkwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <891FFB52D4993142B196CAF99C217076@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable








Thanks you all for the word smithing.  The final draft text follows:









   This document defines t=
he following terms:







   Synchronous configurati=
on operation:   A configuration request to


       update th=
e running configuration of a server that is applied


       synchrono=
usly with respect to the client request (i.e. a blocking


       call). &n=
bsp;The server MUST fully attempt to apply the configuration


       change to=
 all impacted components in the server, updating both


       the serve=
r's intended and applied configuration (see terms),


       before re=
plying to the client.  The reply to the client indicates


       whether t=
here are any errors in the request or errors from


       applying =
the configuration change.







   Asynchronous configurat=
ion operation:   A configuration request to


       update th=
e running configuration of a server that is applied


       asynchron=
ously with respect to the client request.  The server


       MUST upda=
te its intended configuration (see term) before replying


       to the cl=
ient indicating whether the request will be processed.


       This repl=
y to the client only indicates whether there are any


       errors in=
 the original request.  The server's applied


       configura=
tion state (see term) is updated after the configuration


       change ha=
s been fully effected to all impacted components in the


       server. &=
nbsp;Once applied, there MUST be a mechanism for the client


       to determ=
ine when the request has completed processing and


       whether t=
he intended config is now fully effective or there are


       any error=
s from applying the configuration change, which could be


       from an a=
synchronous notification or via a client operation.

















Issue #6 will be moved to the REVIEW state – as the draft will be out=
 shortly.









Thanks again,



Kent  // as a contributor
















From: Gert Grammel <ggrammel@juniper.net>

Date: Friday, October 16, 2015 at 1=
2:52 PM

To: Kent Watsen <kwatsen@juniper.net>

Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap=
plied)













Ok, 







The term 'intended config is updated' is pro=
bably correct but sounds a bit odd to me.    I associate with &qu=
ot;update" a process of alignment. In the case of intended config it i=
s more like a config that is imposed by the client. Later
 the update of the applied config is started.







Certainly a terminology issue, but I wanted =
to bring it up maybe others apply similar semantics.





Gert









Sent from my Apple ][




On 16 Oct 2015, at 17:19, Kent Watsen <kwatsen@juniper.net> wrote:















> Why is there a need to update the intended config? 







Because that is what happens via requests like <edit-config> and=
 PATCH.  The intended (running) config gets updated first and then con=
fig is distributed to internal components, ultimately updated the applied c=
onfig.







Kent  // as a contributor














From: Gert Grammel <ggrammel@juniper.net>

Date: Friday, October 16, 2015 at 1=
0:16 AM

To: Kent Watsen <kwatsen@juniper.net>

Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap=
plied)













Kent,







The new one looks much better. However the l=
ast sentence is confusing with respect to intended config. Why is there a n=
eed to update the intended config?







Proposal:






The server MUST fully attempt to apply 

    the configuration change to all impacted componen=
ts in the server,


    updating the server's applied configuration (see =
terms),


    before replying to the client.




Sent from my Apple ][




On 16 Oct 2015, at 15:45, Kent Watsen <kwatsen@juniper.net> wrote:















Gert writes:


> I don't see the need for defining synchronous/asynchronous config=
 servers.







Thank you (and Juergen) for the confirmation.   Again, if no obje=
ctions, these two terms will not be removed.















> The new definitions look good. Later in=
 the discussion there was a common





> sentiment that the requirement for synchronous operations contain=
ed some


> crisp wording we could use here too.  I particularly liked t=
he mentioning of


> blocking requests for some time,







[Note: the following removes the last two sentences on "transacti=
ons", as being discussed elsewhere on this thread]







OLD:









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request.  The server MUST ful=
ly attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.









NEW









    Synchronous configuration operation - A configuration re=
quest to update


    the running configuration of a server that is applied sy=
nchronously with


    respect to the client request (i.e. a blocking call). &n=
bsp;The server MUST fully attempt to apply 


    the configuration change to all impacted components in t=
he server,


    updating both the server's intended and applied configur=
ation (see terms),


    before replying to the client.


























What do you think?


















Kent


























--_000_D24A6B73E7E9Bkwatsenjunipernet_--


From nobody Mon Oct 19 06:52:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79F1A6F7C for ; Mon, 19 Oct 2015 06:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CJdXNntuJtP for ; Mon, 19 Oct 2015 06:52:53 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257C81A6F62 for ; Mon, 19 Oct 2015 06:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4606; q=dns/txt; s=iport; t=1445262770; x=1446472370; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GHmPV3iFi9YALDMcU8RIXqj048a87hD55V+H0zLk6V0=; b=Bf8XRTfc1nie8FhE+9p7SIbfyutFL7n/+WwRv4ca43M0qhwXd+Z/QMMy YfdhjkilI0aYEhpM/3NzejHU2NihiTmkyIn58GtiMtFkV1Y05G49ryeIX xHbcCcIGXCVzoROqbB6ei8mLzxVr2+ulEU9N07xksldZRSTSCTEVgtis8 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBACW9CRW/xbLJq1ehApvv3YXCoUzSgKCBAEBAQEBAYELhC0BAQEEAQEBNTYKARALDgMEAQEBCRYECwkDAgECARUoCAYNBgIBAYgsDcMnAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGd4R+hEJLB4QuAQSHMwiHB4dhjR2BWIQ8gwGKOohJY4IRHRaBQD00hWcBAQE
X-IronPort-AV: E=Sophos;i="5.17,702,1437436800"; d="scan'208";a="607674788"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Oct 2015 13:52:48 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9JDqmcM017922; Mon, 19 Oct 2015 13:52:48 GMT
To: Kent Watsen 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>  
From: Robert Wilton 
Message-ID: <5624F59F.2060607@cisco.com>
Date: Mon, 19 Oct 2015 14:52:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:52:55 -0000

Hi Kent, Gert,

For clarity, the text that I had reached for 3 (folding in the comments 
so far) is this:

    3.  Support for both synchronous and asynchronous configuration
        operations (see terms)

        A. A server may support only synchronous configuration
           operations, or only asynchronous configuration operations, or
           both synchronous and asynchronous configuration operations on
           a client-specified per-operation basis.

        B. Servers that support asynchronous configuration operations MAY
           also provide a verify operation that a client can request from
           the server to return information regarding the difference
           between the intended and applied configurations.

        C. The configuration protocol MUST specify how configuration
           errors are handled.  Errors may be handled by "stop on error",
           "continue on error" or "rollback on error" semantics (see
           terms).  Support for "rollback on error" SHOULD be provided.


  Extra terms to add the definitions section (based on the definitions 
for NETCONF RFC):

           stop-on-error:  The configuration operation is aborted on the 
first
             error.

          continue-on-error:  Continue to process configuration data on
             error; error is recorded, and negative response is generated
             if any errors occur.

          rollback-on-error:  If an error condition occurs such that part
             of applying the configuration fails, the server will stop
             processing the configuration operation and restore the
             specified configuration to its complete state at the start
             of this configuration operation.


Gert has provided some definitions that are closer to Kent's original 
text, how do we resolve?

Thanks,
Rob


On 19/10/2015 14:22, Kent Watsen wrote:
> I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
> change the 1.D text to..."
>
> Sorry for the confusion.
>
> Kent
>
>
> On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:
>
>> Hi Rob,
>>
>> I know there is an on-going discussion about the time-line of things, but
>> the draft needs to be posted today...  Can you help finalize the text?
>>
>> Randy offers some good editorial suggestions below, and I believe you and
>> Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>>
>> Thanks,
>> Kent
>>
>>
>> On 10/16/15, 11:29 PM, "Randy Presuhn" 
>> wrote:
>>
>>> Hi -
>>>
>>>> From: Robert Wilton
>>>> Sent: Oct 16, 2015 5:12 AM
>>>> To: Kent Watsen , Nadeau Thomas
>>>> Cc: "netmod@ietf.org"
>>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>> asynchronous systems to provide a blocking config update?
>>> ...
>>>>     Here is my attempt at word smithing section 3:
>>> ...
>>>>              A. A server may choose to support only synchronous
>>>> configuration
>>>>                 operations, or only asynchronous configuration
>>>> operations, or
>>>>                 both synchronous and asynchronous configuration
>>>> operations in
>>>>                 a client specified per-operation basis.
>>> Editorial comments:
>>>   - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>>     a semantically inappropriate use of the keyword.
>>>   - please avoid unnecessary anthropomorphisms; the server doesn't
>>>     "choose" anything here.
>>>   - s/ in/ on/
>>>   - s/client specified/client-specified/
>>>
>>> ...
>>>>           failed.  A configuration protocol, or server, SHOULD provide
>>>>           support for rollback-on-error behavior and MAY choose to
>>>>           provide support for best effort semantics as well.
>>> Editorial comments:
>>>
>>>   - The implications of the RFC 2119 SHOULD and MAY are quite different
>>>     depending on which of the two subjects ("protocol" or "server") one
>>>     chooses to think about.  The server's observable behaviour is
>>> presumably
>>>     circumscribed by the protocol, so I suggest removing ", or server,".
>>>
>>>   - Please suppress anthropomorphisms.
>>>
>>>   - s/best effort/best-effort/
>>>
>>> Randy
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Mon Oct 19 06:59:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3841A6F9D for ; Mon, 19 Oct 2015 06:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtQgq7nXc8mH for ; Mon, 19 Oct 2015 06:59:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3B001A6FA3 for ; Mon, 19 Oct 2015 06:59:31 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id C9BE31AE0959 for ; Mon, 19 Oct 2015 15:59:30 +0200 (CEST)
Date: Mon, 19 Oct 2015 15:59:30 +0200 (CEST)
Message-Id: <20151019.155930.1433464358995975033.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Oct_19_15_59_30_2015_541)--"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Fw: New Version Notification for draft-entitydt-netmod-entity-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:59:36 -0000

----Next_Part(Mon_Oct_19_15_59_30_2015_541)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

We have published the following draft for Entity Management (the typo
in the title will be fixed in the next rev...).

This is more or less a YANG-ified version of the Entity MIBs.  At this
point we'd like to hear the WGs opionion on this; is it the correct
approach to stay close to the MIB, is something missing, can
something be removed?


/martin 



----Next_Part(Mon_Oct_19_15_59_30_2015_541)--
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on metgos.tail-f.com
X-Spam-Level: 
X-Spam-Status: No, score=-107.5 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS,URIBL_BLOCKED,
	USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0
X-Original-To: mbj@tail-f.com
Delivered-To: mbj@tail-f.com
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
	by mail.tail-f.com (Postfix) with ESMTPS id 2D5EE1AE0959
	for ; Mon, 19 Oct 2015 15:55:15 +0200 (CEST)
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id 232E51A6F63;
	Mon, 19 Oct 2015 06:55:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: "Martin Bjorklund" , "Andy Bierman" , 
 "Dan Romascanu" , "Martin Bjorklund"
 , "Andy Bierman" , "Dan Romascanu"
 , "Jie Dong" , "Jie Dong"
 
Subject: New Version Notification for draft-entitydt-netmod-entity-00.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019135514.25392.66967.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 06:55:14 -0700
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
   int  cnt   prob  spamicity histogram
  0.00   58 0.018277 0.017471 ################################################
  0.10    3 0.112136 0.022982 ###
  0.20    0 0.000000 0.022982 
  0.30    0 0.000000 0.022982 
  0.40    0 0.000000 0.022982 
  0.50    0 0.000000 0.022982 
  0.60    0 0.000000 0.022982 
  0.70    0 0.000000 0.022982 
  0.80    0 0.000000 0.022982 
  0.90    0 0.000000 0.022982 


A new version of I-D, draft-entitydt-netmod-entity-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:		draft-entitydt-netmod-entity
Revision:	00
Title:		A YANG Data Model for Entity Managemet
Document date:	2015-10-19
Group:		Individual Submission
Pages:		36
URL:            https://www.ietf.org/internet-drafts/draft-entitydt-netmod-entity-00.txt
Status:         https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/
Htmlized:       https://tools.ietf.org/html/draft-entitydt-netmod-entity-00


Abstract:
   This document defines a YANG data model for the management of
   multiple physical entities managed by a single server.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


----Next_Part(Mon_Oct_19_15_59_30_2015_541)----


From nobody Mon Oct 19 07:01:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181A1A6FE5 for ; Mon, 19 Oct 2015 07:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 731Fd1TiOhBF for ; Mon, 19 Oct 2015 07:01:55 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CAA1A6F9F for ; Mon, 19 Oct 2015 07:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21382; q=dns/txt; s=iport; t=1445263313; x=1446472913; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=dddrmbpzvAbal0GQyJcXXGdlkTLZ/xFoZY4dSSnEBMc=; b=dByNtCMPBT4FuRUB1A09A+sbBLKmn02XaVUiu/KWpF01an/Nhp/i8owV IXXXXMxNM5n8fz9Y4GM6r/4HB1OpDf3JKLxleQW1mVHVx/aCinrVtqteU hwGBdpaRQBdpXDItDVKU9g0UDkmHAVzn3B2k333yKvGhJsmOWZSQMFQ2J g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DQAQBm9yRW/xbLJq1egmmBIW++DgENgVoXAQmFM0oCgXAUAQEBAQEBAYEKhC0BAQEDAQEBAWsKARALDgMDAQEBAQkWBAQHCQMCAQIBFR8JCAYNBgIBAYgkCA3DLgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhneEfoRCOhEHhC4FhzuHB4QYg0mNHYFYhDyDAYo6iEkfAQFCghEdFoFAPTSFZwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,702,1437436800";  d="scan'208,217";a="630394669"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Oct 2015 14:01:50 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9JE1nXe019628; Mon, 19 Oct 2015 14:01:49 GMT
To: Gert Grammel 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>   
From: Robert Wilton 
Message-ID: <5624F7BC.9030707@cisco.com>
Date: Mon, 19 Oct 2015 15:01:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050709050107000809090403"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 14:01:57 -0000

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

Hi Gert,

On 19/10/2015 14:37, Gert Grammel wrote:
> Hi Kent,
>
> Here my proposals
>
>    3.  Support for both synchronous and asynchronous configuration
>        operations (see terms)
>
>        A. A server may only support synchronous configuration
>           operations, or may only support asynchronous configuration
>           operations, or may support synchronicity to be client
>           specified on a per-operation basis.
>
> NEW   A. The way a server executes an operation (synchronous or 
> asynchronous) is implementation specific and may change on a 
> per-operation basis.
I don't agree with this new text.  I think that the server (or protocol) 
should specify whether it supports sync and/or async operations.  But it 
is up to the client to choose which particular way (out of the supported 
options) that it wants the server to process a particular operation.  
Letting the server decide would seem to push additional complexity on 
the client.

Thanks,
Rob


>
>        C. Support for synchronous configuration operations
>           requires the server to block sending a response to
>           the client until it is able to able to determine whether
>           there are any errors in the request or errors from
>           applying the configuration change.
>
> NEW (changed OR into AND)
>        C. Support for synchronous configuration operations
>           requires the server to block sending a response to
>           the client until it is able to able to determine whether
>           there are any errors in the request and errors from
>           applying the configuration change.
> OK
>        D. Support for asynchronous configuration operations
>           requires the server to send a response to the client
>           immediately indicated that the request was accepted
>           and send a notification to the client when the intended
>           config is fully effective or there are any errors from
>           applying the configuration change.
> OK
>        E. Support for asynchronous configuration operations MAY
>           also provide a verify operation which a client can request
>           from the server to obtain information regarding the
>           difference between the intended and applied configurations.
>
>
>
>
>
>
>
>
>
>
> From: netmod  > on behalf of Kent Watsen 
> >
> Date: Monday 19 October 2015 15:22
> To: Kent Watsen >, 
> Robert Wilton >
> Cc: "netmod@ietf.org "  >
> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for 
> asynchronous systems to provide a blocking config update?
>
>
> I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
> change the 1.D text to..."
>
> Sorry for the confusion.
>
> Kent
>
>
> On 10/19/15, 9:14 AM, "Kent Watsen"  > wrote:
>
>     Hi Rob,
>
>     I know there is an on-going discussion about the time-line of
>     things, but
>     the draft needs to be posted today...  Can you help finalize the text?
>
>     Randy offers some good editorial suggestions below, and I believe
>     you and
>     Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>
>     Thanks,
>     Kent
>
>
>     On 10/16/15, 11:29 PM, "Randy Presuhn"
>     >
>     wrote:
>
>         Hi -
>
>             From: Robert Wilton
>             Sent: Oct 16, 2015 5:12 AM
>             To: Kent Watsen , Nadeau Thomas
>             Cc: "netmod@ietf.org "
>             Subject: Re: [netmod] opstate-reqs #3: Is there a
>             requirement for
>             asynchronous systems to provide a blocking config update?
>
>         ...
>
>                 Here is my attempt at word smithing section 3:
>
>         ...
>
>                          A. A server may choose to support only
>             synchronous
>             configuration
>                             operations, or only asynchronous configuration
>             operations, or
>                             both synchronous and asynchronous
>             configuration
>             operations in
>                             a client specified per-operation basis.
>
>
>         Editorial comments:
>           - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>             a semantically inappropriate use of the keyword.
>           - please avoid unnecessary anthropomorphisms; the server doesn't
>             "choose" anything here.
>           - s/ in/ on/
>           - s/client specified/client-specified/
>
>         ...
>
>                       failed.  A configuration protocol, or server,
>             SHOULD provide
>                       support for rollback-on-error behavior and MAY
>             choose to
>                       provide support for best effort semantics as well.
>
>
>         Editorial comments:
>
>           - The implications of the RFC 2119 SHOULD and MAY are quite
>         different
>             depending on which of the two subjects ("protocol" or
>         "server") one
>             chooses to think about.  The server's observable behaviour is
>         presumably
>             circumscribed by the protocol, so I suggest removing ", or
>         server,".
>
>           - Please suppress anthropomorphisms.
>
>           - s/best effort/best-effort/
>
>         Randy
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod
>


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


  
    
  
  
    Hi Gert,

    

    
On 19/10/2015 14:37, Gert Grammel
      wrote:

    

    

      
      

        
Hi Kent,

        


        

        
Here my proposals

        


        

      

      

        
   3.  Support for both synchronous and asynchronous
          configuration

        
       operations (see terms)

        


        

        
       A. A server may only support synchronous
          configuration

        
          operations, or may only support asynchronous
          configuration

        
          operations, or may support synchronicity to be
          client

        
          specified on a per-operation basis.

        


        

        
NEW   A. The way a server executes an operation
          (synchronous or asynchronous) is implementation specific and
          may change on a per-operation basis.

      

    

    I don't agree with this new text.  I think that the server (or
    protocol) should specify whether it supports sync and/or async
    operations.  But it is up to the client to choose which particular
    way (out of the supported options) that it wants the server to
    process a particular operation.  Letting the server decide would
    seem to push additional complexity on the client.

    

    Thanks,

    Rob

    

    

    

      

        


        

        
       C. Support for synchronous configuration operations

        
          requires the server to block sending a response
          to

        
          the client until it is able to able to determine
          whether

        
          there are any errors in the request or errors
          from

        
          applying the configuration change.

        


        

        
NEW (changed OR into AND)

        

          
       C. Support for synchronous configuration
            operations

          
          requires the server to block sending a response
            to

          
          the client until it is able to able to
            determine whether

          
          there are any errors in the request and errors
            from

          
          applying the configuration change.

        

        
    

        
OK

        
       D. Support for asynchronous configuration operations

        
          requires the server to send a response to the
          client

        
          immediately indicated that the request was
          accepted

        
          and send a notification to the client when the
          intended

        
          config is fully effective or there are any errors
          from

        
          applying the configuration change.

        
OK

        
       E. Support for asynchronous configuration operations
          MAY

        
          also provide a verify operation which a client
          can request

        
          from the server to obtain information regarding
          the

        
          difference between the intended and applied
          configurations.

        


        

        


        

      

      

        


        

      

      


      

      


      

      


      

      


      

      


      

      


      

      


      

      
        

          From: netmod <netmod-bounces@ietf.org>
          on behalf of Kent Watsen <kwatsen@juniper.net>

          Date: Monday 19 October
          2015 15:22

          To: Kent Watsen <kwatsen@juniper.net>,
          Robert Wilton <rwilton@cisco.com>

          Cc: "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          opstate-reqs #3: Is there a requirement for asynchronous
          systems to provide a blocking config update?

        

        


        

        

          

            


            

            
I meant 3.D, and so did you I think when you wrote on
              the 16th "E.g.

            
change the 1.D text to..."

            


            

            
Sorry for the confusion.

            


            

            
Kent

            


            

            


            

            
On 10/19/15, 9:14 AM, "Kent Watsen" <kwatsen@juniper.net>
              wrote:

            


            

            

              
Hi Rob,

              


              

              
I know there is an on-going discussion about the
                time-line of things, but

              
the draft needs to be posted today...  Can you help
                finalize the text?

              


              

              
Randy offers some good editorial suggestions below,
                and I believe you and

              
Gert had some ideas in wordsmithing 1.D. and bringing
                in error modes.

              


              

              
Thanks,

              
Kent

              


              

              


              

              
On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_presuhn@mindspring.com>

              
wrote:

              


              

              

                
Hi -

                


                

                

                  
From: Robert Wilton

                  
Sent: Oct 16, 2015 5:12 AM

                  
To: Kent Watsen , Nadeau Thomas

                  
                  
Subject: Re: [netmod] opstate-reqs #3: Is there a
                    requirement for

                  
asynchronous systems to provide a blocking config
                    update?

                

                
...

                

                  
    Here is my attempt at word smithing section
                    3:

                

                
...

                

                  
             A. A server may choose to support
                    only synchronous

                  
configuration

                  
                operations, or only asynchronous
                    configuration

                  
operations, or

                  
                both synchronous and asynchronous
                    configuration

                  
operations in

                  
                a client specified per-operation
                    basis.

                

                


                

                
Editorial comments:

                
  - is the "may" intended as a RFC 2119 MAY?  If
                  so, this seems

                
    a semantically inappropriate use of the
                  keyword.

                
  - please avoid unnecessary anthropomorphisms; the
                  server doesn't

                
    "choose" anything here.

                
  - s/ in/ on/

                
  - s/client specified/client-specified/

                


                

                
...

                

                  
          failed.  A configuration protocol, or
                    server, SHOULD provide

                  
          support for rollback-on-error behavior
                    and MAY choose to

                  
          provide support for best effort
                    semantics as well.

                

                


                

                
Editorial comments:

                


                

                
  - The implications of the RFC 2119 SHOULD and MAY
                  are quite different

                
    depending on which of the two subjects
                  ("protocol" or "server") one

                
    chooses to think about.  The server's
                  observable behaviour is

                
presumably

                
    circumscribed by the protocol, so I suggest
                  removing ", or server,".

                


                

                
  - Please suppress anthropomorphisms.

                


                

                
  - s/best effort/best-effort/

                


                

                
Randy

                


                

                
_______________________________________________

                
netmod mailing list

                
                
              

              


              

              
_______________________________________________

              
netmod mailing list

              
              
            

            


            

            
_______________________________________________

            
netmod mailing list

            
            
            


            

          

        

      
    

    

  


--------------050709050107000809090403--


From nobody Mon Oct 19 07:27:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF91A8741 for ; Mon, 19 Oct 2015 07:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3T7DI3Vb7R4 for ; Mon, 19 Oct 2015 07:27:28 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D941A6EFB for ; Mon, 19 Oct 2015 07:27:28 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 14:27:26 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 14:27:25 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHRCIv9Q8yGc7JN/0i9oUnVbQsvDp5yi/EAgAACX4CAAGjIgP//5SEAgAAHO+I=
Date: Mon, 19 Oct 2015 14:27:25 +0000
Message-ID: <78BB4CDA-FE0B-4438-B5F9-C471C1388594@juniper.net>
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>   ,<5624F7BC.9030707@cisco.com>
In-Reply-To: <5624F7BC.9030707@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [95.113.185.113]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:GRTN3eqfhz3dMzSJCb8y7igeNr/gCcxh/D2/gkkEyQvvSJcfbGM1N/6C7tqXTVeVpyhphExEzBZiSFTSYIEM38cLKTePst4zjdC3ekpNaLzSb8/dnd1V4euhjPUVditeN/xywlURTaF1ZV9Y7v/l8w==; 24:/u/oelB/5qNADMOrIcsUbVKclgPlDwcEtf2C4dMGWR4ZHEoi/nYowpDg4xqF2qT64+rL90RZMZBAY+JTiomh5kZhfzm8gvwbE2HKoCCqdh4=; 20:21C/CAEHHWtnkSqvkk2r3Nt3tkaDE63pwCv4n5d7Pg9xvUeI/k6Blh6XYNt+tW7fqsL939xr6liFUyaLby37JA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(164054003)(479174004)(51444003)(24454002)(199003)(102836002)(50986999)(5002640100001)(93886004)(15975445007)(46102003)(36756003)(19617315012)(86362001)(16236675004)(10400500002)(33656002)(83716003)(105586002)(5001960100002)(110136002)(189998001)(122556002)(66066001)(64706001)(97736004)(76176999)(106356001)(54356999)(82746002)(19580405001)(5007970100001)(19580395003)(99286002)(2950100001)(101416001)(87936001)(2900100001)(5004730100002)(106116001)(40100003)(5008740100001)(92566002)(81156007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_78BB4CDAFE0B4438B5F9C471C1388594junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 14:27:25.5879 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 14:27:32 -0000

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

Rob,

The current text of 3a works for me although it looks a bit complex. So we =
converged.

Gert

Sent from my Apple ][

On 19 Oct 2015, at 16:01, Robert Wilton > wrote:

Hi Gert,

On 19/10/2015 14:37, Gert Grammel wrote:
Hi Kent,

Here my proposals

   3.  Support for both synchronous and asynchronous configuration
       operations (see terms)

       A. A server may only support synchronous configuration
          operations, or may only support asynchronous configuration
          operations, or may support synchronicity to be client
          specified on a per-operation basis.

NEW   A. The way a server executes an operation (synchronous or asynchronou=
s) is implementation specific and may change on a per-operation basis.
I don't agree with this new text.  I think that the server (or protocol) sh=
ould specify whether it supports sync and/or async operations.  But it is u=
p to the client to choose which particular way (out of the supported option=
s) that it wants the server to process a particular operation.  Letting the=
 server decide would seem to push additional complexity on the client.

Thanks,
Rob



       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request or errors from
          applying the configuration change.

NEW (changed OR into AND)
       C. Support for synchronous configuration operations
          requires the server to block sending a response to
          the client until it is able to able to determine whether
          there are any errors in the request and errors from
          applying the configuration change.

OK
       D. Support for asynchronous configuration operations
          requires the server to send a response to the client
          immediately indicated that the request was accepted
          and send a notification to the client when the intended
          config is fully effective or there are any errors from
          applying the configuration change.
OK
       E. Support for asynchronous configuration operations MAY
          also provide a verify operation which a client can request
          from the server to obtain information regarding the
          difference between the intended and applied configurations.










From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen >
Date: Monday 19 October 2015 15:22
To: Kent Watsen <kwatsen@juniper.net>, Robert Wilton >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchron=
ous systems to provide a blocking config update?


I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen" <kwatsen@ju=
niper.net> wrote:

Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent


On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_presuhn@mindspring.com>
wrote:

Hi -

From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
asynchronous systems to provide a blocking config update?
...
    Here is my attempt at word smithing section 3:
...
             A. A server may choose to support only synchronous
configuration
                operations, or only asynchronous configuration
operations, or
                both synchronous and asynchronous configuration
operations in
                a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
    a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
    "choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
          failed.  A configuration protocol, or server, SHOULD provide
          support for rollback-on-error behavior and MAY choose to
          provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
    depending on which of the two subjects ("protocol" or "server") one
    chooses to think about.  The server's observable behaviour is
presumably
    circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

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

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

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



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







Rob,







The current text of 3a works for me although=
 it looks a bit complex. So we converged.







Gert 



Sent from my Apple ][




On 19 Oct 2015, at 16:01, Robert Wilton <rwilton@cisco.com> wrote:








Hi Gert,




On 19/10/2015 14:37, Gert Grammel wrote:








Hi Kent,







Here my proposals











   3.  Support for both synchronous and asynchrono=
us configuration


       operations (see terms)







       A. A server may only support sync=
hronous configuration


          operations=
, or may only support asynchronous configuration


          operations=
, or may support synchronicity to be client


          specified =
on a per-operation basis.







NEW   A. The way a server executes an operation (synchronous or a=
synchronous) is implementation specific and may change on a per-operation b=
asis.





I don't agree with this new text.  I think that the server (or protoco=
l) should specify whether it supports sync and/or async operations.  B=
ut it is up to the client to choose which particular way (out of the suppor=
ted options) that it wants the server to process
 a particular operation.  Letting the server decide would seem to push=
 additional complexity on the client.



Thanks,

Rob















       C. Support for synchronous config=
uration operations


          requires t=
he server to block sending a response to


          the client=
 until it is able to able to determine whether


          there are =
any errors in the request or errors from


          applying t=
he configuration change.







NEW (changed OR into AND)




       C. Support for synchronous configuration op=
erations


          requires t=
he server to block sending a response to


          the client=
 until it is able to able to determine whether


          there are =
any errors in the request and errors from


          applying t=
he configuration change.




    


OK


       D. Support for asynchronous confi=
guration operations


          requires t=
he server to send a response to the client


          immediatel=
y indicated that the request was accepted


          and send a=
 notification to the client when the intended


          config is =
fully effective or there are any errors from


          applying t=
he configuration change.


OK


       E. Support for asynchronous confi=
guration operations MAY


          also provi=
de a verify operation which a client can request


          from the s=
erver to obtain information regarding the


          difference=
 between the intended and applied configurations.




























































From: netmod <netmod-bounces@iet=
f.org> on behalf of Kent Watsen <kwatsen@juniper.net>

Date: Monday 19 October 2015 15:22<=
br>
To: Kent Watsen <kwatsen@juniper.net=
>, Robert Wilton <rwilton@cisco.com>

Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs =
#3: Is there a requirement for asynchronous systems to provide a blocking c=
onfig update?


















I meant 3.D, and so did you I think when you wrote on the 16th "E=
.g.


change the 1.D text to..."







Sorry for the confusion.







Kent












On 10/19/15, 9:14 AM, "Kent Watsen" <kwatsen@juniper.net>=
; wrote:









Hi Rob,







I know there is an on-going discussion about the time-line of things, =
but


the draft needs to be posted today...  Can you help finalize=
 the text?







Randy offers some good editorial suggestions below, and I believe you =
and


Gert had some ideas in wordsmithing 1.D. and bringing in error modes.<=
/div>






Thanks,


Kent












On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_p=
resuhn@mindspring.com>


wrote:









Hi -









From: Robert Wilton


Sent: Oct 16, 2015 5:12 AM


To: Kent Watsen , Nadeau Thomas



Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for

asynchronous systems to provide a blocking config update?




...




    Here is my attempt at word smithing section 3:=





...




           &nbs=
p; A. A server may choose to support only synchronous


configuration


           &nbs=
p;    operations, or only asynchronous configuration

operations, or


           &nbs=
p;    both synchronous and asynchronous configuration

operations in


           &nbs=
p;    a client specified per-operation basis.









Editorial comments:


  - is the "may" intended as a RFC 2119 MAY? =
 If so, this seems


    a semantically inappropriate use of the keywor=
d.


  - please avoid unnecessary anthropomorphisms; the server d=
oesn't


    "choose" anything here.


  - s/ in/ on/


  - s/client specified/client-specified/







...




          failed.&nb=
sp; A configuration protocol, or server, SHOULD provide


          support fo=
r rollback-on-error behavior and MAY choose to


          provide su=
pport for best effort semantics as well.









Editorial comments:







  - The implications of the RFC 2119 SHOULD and MAY are quit=
e different


    depending on which of the two subjects ("=
protocol" or "server") one


    chooses to think about.  The server'=
s observable behaviour is


presumably


    circumscribed by the protocol, so I suggest re=
moving ", or server,".







  - Please suppress anthropomorphisms.







  - s/best effort/best-effort/







Randy







_______________________________________________


netmod mailing list











_______________________________________________


netmod mailing list











_______________________________________________


netmod mailing list























--_000_78BB4CDAFE0B4438B5F9C471C1388594junipernet_--


From nobody Mon Oct 19 07:33:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D137E1A9115 for ; Mon, 19 Oct 2015 07:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0O1rZSCE2Ph for ; Mon, 19 Oct 2015 07:33:45 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9371A9108 for ; Mon, 19 Oct 2015 07:33:45 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 14:33:39 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 14:33:38 +0000
From: Kent Watsen 
To: Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHRCIv9Q8yGc7JN/0i9oUnVbQsvDp5yi/EAgAACX4CAAEtkgP//yGoA
Date: Mon, 19 Oct 2015 14:33:38 +0000
Message-ID: 
References: <23055056.1445052551541.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>   <5624F59F.2060607@cisco.com>
In-Reply-To: <5624F59F.2060607@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB043; 5:BMTI7Mvmf/6ZV9jROXWljHAdesR1HeMZa0TnlAa9A9qklm6ySwXtICrnxbFYwWjTSgKDYXI+xAANRViFbRRFcO1ejsGDjJHn8HLkaEgp+Pj6Uxs0D4JND0NZP2S1gypctaN/B5+bkoW8bHecSDGR+g==; 24:rXdFJycqHw2SJ2UE5qAE1kA5ByEJX1jBtx3DjsUXxXaN8nKLznQ3bWD4pbwcyUFEDf2k3vxhHv2QhdtGiVG7QN9ZmouEe1a0JnpvUqTa3CQ=; 20:jXxr+0ph0ft6NXBriNoFbwKtGaLq2Gv2GD/ixMiuB0W8X3NnoK8WP+QJhAKR3Ifg0DOD6BUR8zN0VCeyF4uhkg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB043;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BN1PR05MB043; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB043; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(24454002)(189002)(199003)(164054003)(50986999)(97736004)(106116001)(54356999)(15975445007)(76176999)(5007970100001)(4001350100001)(81156007)(105586002)(19580405001)(99286002)(2950100001)(87936001)(36756003)(5004730100002)(107886002)(5002640100001)(5001960100002)(19580395003)(10400500002)(86362001)(66066001)(122556002)(5008740100001)(92566002)(110136002)(40100003)(106356001)(189998001)(46102003)(102836002)(2900100001)(101416001)(64706001)(83506001)(93886004)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3146DFDA1BB735468A49E0744C8E0725@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 14:33:38.3361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 14:33:50 -0000

OK, it looks like we converged.  Thank you all.
I will use the text below for the draft.

Kent   // with editor hat on  ;)



On 10/19/15, 9:52 AM, "Robert Wilton"  wrote:

>Hi Kent, Gert,
>
>For clarity, the text that I had reached for 3 (folding in the comments
>so far) is this:
>
>    3.  Support for both synchronous and asynchronous configuration
>        operations (see terms)
>
>        A. A server may support only synchronous configuration
>           operations, or only asynchronous configuration operations, or
>           both synchronous and asynchronous configuration operations on
>           a client-specified per-operation basis.
>
>        B. Servers that support asynchronous configuration operations MAY
>           also provide a verify operation that a client can request from
>           the server to return information regarding the difference
>           between the intended and applied configurations.
>
>        C. The configuration protocol MUST specify how configuration
>           errors are handled.  Errors may be handled by "stop on error",
>           "continue on error" or "rollback on error" semantics (see
>           terms).  Support for "rollback on error" SHOULD be provided.
>
>
>  Extra terms to add the definitions section (based on the definitions
>for NETCONF RFC):
>
>           stop-on-error:  The configuration operation is aborted on the
>first
>             error.
>
>          continue-on-error:  Continue to process configuration data on
>             error; error is recorded, and negative response is generated
>             if any errors occur.
>
>          rollback-on-error:  If an error condition occurs such that part
>             of applying the configuration fails, the server will stop
>             processing the configuration operation and restore the
>             specified configuration to its complete state at the start
>             of this configuration operation.
>
>
>Gert has provided some definitions that are closer to Kent's original
>text, how do we resolve?
>
>Thanks,
>Rob
>
>
>On 19/10/2015 14:22, Kent Watsen wrote:
>> I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
>> change the 1.D text to..."
>>
>> Sorry for the confusion.
>>
>> Kent
>>
>>
>> On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:
>>
>>> Hi Rob,
>>>
>>> I know there is an on-going discussion about the time-line of things,
>>>but
>>> the draft needs to be posted today...  Can you help finalize the text?
>>>
>>> Randy offers some good editorial suggestions below, and I believe you
>>>and
>>> Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>> On 10/16/15, 11:29 PM, "Randy Presuhn" 
>>> wrote:
>>>
>>>> Hi -
>>>>
>>>>> From: Robert Wilton
>>>>> Sent: Oct 16, 2015 5:12 AM
>>>>> To: Kent Watsen , Nadeau Thomas
>>>>> Cc: "netmod@ietf.org"
>>>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>>> asynchronous systems to provide a blocking config update?
>>>> ...
>>>>>     Here is my attempt at word smithing section 3:
>>>> ...
>>>>>              A. A server may choose to support only synchronous
>>>>> configuration
>>>>>                 operations, or only asynchronous configuration
>>>>> operations, or
>>>>>                 both synchronous and asynchronous configuration
>>>>> operations in
>>>>>                 a client specified per-operation basis.
>>>> Editorial comments:
>>>>   - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>>>     a semantically inappropriate use of the keyword.
>>>>   - please avoid unnecessary anthropomorphisms; the server doesn't
>>>>     "choose" anything here.
>>>>   - s/ in/ on/
>>>>   - s/client specified/client-specified/
>>>>
>>>> ...
>>>>>           failed.  A configuration protocol, or server, SHOULD
>>>>>provide
>>>>>           support for rollback-on-error behavior and MAY choose to
>>>>>           provide support for best effort semantics as well.
>>>> Editorial comments:
>>>>
>>>>   - The implications of the RFC 2119 SHOULD and MAY are quite
>>>>different
>>>>     depending on which of the two subjects ("protocol" or "server")
>>>>one
>>>>     chooses to think about.  The server's observable behaviour is
>>>> presumably
>>>>     circumscribed by the protocol, so I suggest removing ", or
>>>>server,".
>>>>
>>>>   - Please suppress anthropomorphisms.
>>>>
>>>>   - s/best effort/best-effort/
>>>>
>>>> Randy
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>


From nobody Mon Oct 19 07:46:08 2015
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4661A923A; Mon, 19 Oct 2015 07:46:07 -0700 (PDT)
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.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019144607.31997.16374.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 07:46:07 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 14:46:07 -0000

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

        Title           : Network Access Control List (ACL) YANG Data Model
        Authors         : Dean Bogdanovic
                          Kiran Agrahara Sreenivasa
                          Lisa Huang
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-04.txt
	Pages           : 28
	Date            : 2015-10-17

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-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 Mon Oct 19 07:56:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516A21A92EC for ; Mon, 19 Oct 2015 07:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37isiz6HgbrX for ; Mon, 19 Oct 2015 07:56:40 -0700 (PDT)
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 03BEE1A9142 for ; Mon, 19 Oct 2015 07:56:40 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:71:a2ea:4352:22f3] (unknown [IPv6:2001:718:1a02:1:71:a2ea:4352:22f3]) by mail.nic.cz (Postfix) with ESMTPSA id 6F0B8180E6B for ; Mon, 19 Oct 2015 16:56:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445266598; bh=23TSxYdeg3sHx6FGLxeaXzQcdp5n+620gUBNUlyLSC4=; h=From:Date:To; b=nPsZmJ1hmGPAme2zggRuffSr2jH3ChtPzwgf0yGSjMfRRCAFI5QoouT6gpZErXq5B ltP1VERCyxJSryYG1gMvmK2StLCh8sKvXpqZ4S3UetTqFaqQZgJ4HfPJhQ3KPZcJem cTzli0/hI0iK1//j+KcNYkqP0Yy2ep3eUQY8L7A8=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz>
Date: Mon, 19 Oct 2015 16:56:37 +0200
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] mandatory versus when
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 14:56:41 -0000

Hi,

I can't find any text in 6020bis that deals with the following issue:

leaf foo {
    when "false()";
    mandatory true;
    type empty;
}

Now, sec. 7.6.5 (The leaf's mandatory Statement) says:

   o  Otherwise, the leaf MUST exist if the ancestor node exists in the
      data tree.

So, if we assume the ancestor node exists in the data tree, the leaf =
MUST exist.

But sec. 8.1 (Constraints on Data) says:

   The following properties are true in all data trees:

   =E2=80=A6

   o  There MUST be no nodes tagged with "when" present if the "when"
      condition evaluates to "false" in the data tree.

The "mandatory" and "when" statements contradict each other. How is this =
resolved?

Lada

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





From nobody Mon Oct 19 09:10:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFBB1A87BA for ; Mon, 19 Oct 2015 09:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9lipaTrGMpD for ; Mon, 19 Oct 2015 09:10:45 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791821A87AA for ; Mon, 19 Oct 2015 09:10:45 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 16:10:43 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 16:10:43 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
Thread-Index: AQHQ/Jhe+wzAtH4+rEyfclxfJZTKW55X7weAgACLuoCAAAeIAIAAIxGAgAFEqACAA3jPAIAA2WyAgABrIgCAAEK9AIAADvuAgAqACoCAAaFbgIAHuqoA
Date: Mon, 19 Oct 2015 16:10:43 +0000
Message-ID: 
References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com>   <560EE633.5060707@cisco.com>   <56139683.9010909@cisco.com> <20151006160138.GA50204@elstar.local> <5614285E.8060305@cisco.com> <20151006205407.GA50666@elstar.local> <561D03D3.90403@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:oYk8CWi4XQAzoU9CQpTjxdogh+Ihy1AL7awZBU+55K4odoARmx6E0R288wMC1XeCefOmnr6nJ0ejfOxfv3MdukVCEe4lsRyfPxzT3rS1aFZ585WpZYRK8nC7kVHGv1hMcknBsjRipO5QvAjlbnixDQ==; 24:ClDRM62IwdEs07zjqy0Du91encDZzp8dlL/LCMPJbp0F+yqiD+ZKcLjuZpJQYtE18Oso0S9q3eN6ZfkcFYtRAoX+bCLaioH3gGEcAyPIPfg=; 20:8CC2T3jDbXoqM/rzIXCliuJQdwqmsfnXUsQ+fzDa279hSNVmVyLMeWGgnI5EHSMO9qi7H4D8xxn2+iBwlMMOag==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(479174004)(24454002)(199003)(189002)(5383002)(106116001)(46102003)(4001350100001)(10400500002)(64706001)(40100003)(81156007)(122556002)(106356001)(107886002)(5008740100001)(93886004)(2900100001)(19580405001)(50986999)(5002640100001)(15975445007)(5004730100002)(11100500001)(102836002)(2501003)(2950100001)(5007970100001)(92566002)(36756003)(189998001)(76176999)(101416001)(19580395003)(5001960100002)(105586002)(5001770100001)(97736004)(99286002)(561944003)(83506001)(87936001)(86362001)(66066001)(54356999)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 16:10:43.4468 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 16:10:48 -0000

DQpBbGwsDQoNClRoaXMgaXNzdWUgc29tZXdoYXQgZHJvcHBlZCBmcm9tIG91ciByYWRhciAtIHdl
IGRpZG4ndCBkaXNjdXNzIGl0IGR1cmluZw0KdGhlIGludGVyaW0gb3Igc2luY2UuICBOb25ldGhl
bGVzcywgbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGJlbG93IHRocmVhZA0KaXMgdGhhdCBSb2Jl
cnQncyBwcm9wb3NhbCB3YXMgYWNjZXB0ZWQuICBTbyBJJ20gZ29pbmcgdG8gcmVwbGFjZSAxLkQg
d2l0aA0KdGhlIHRleHQgYmVsb3cgKGFsYmVpdCBzL3N5c3RlbS9zZXJ2ZXIvKSBhbmQgbW92ZSB0
aGlzIGlzc3VlIHRvIHRoZSBSRVZJRVcNCnN0YXRlLg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpP
biAxMC8xNC8xNSwgMjowOCBQTSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4g
d3JvdGU6DQoNCj4NCj5UaGUgbmV3IDEtRCB3b3JrcyBmb3IgbWUuICBJdCBpcyBzaW1pbGFyIGlu
IHNwaXJpdCB0byB0aGUgcHJvcG9zYWwgSSBqdXN0DQo+c2VudCBpbiB0aGUgaXNzdWUgIzQgdGhy
ZWFkLg0KPg0KPlRoYW5rcywNCj5LZW50DQo+DQo+DQo+T24gMTAvMTMvMTUsIDk6MTQgQU0sICJS
b2JlcnQgV2lsdG9uIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5JbiBhbiBhdHRl
bXB0IHRvIHRyeSBhbmQgY2xvc2Ugb24gc29tZSBvZiB0aGUgcHJvcG9zZWQgcmVxdWlyZW1lbnQg
dGV4dA0KPj5iZWZvcmUgVGh1cnNkYXkncyBpbnRlcmltIG1lZXRpbmcuDQo+Pg0KPj5Eb2VzIGFu
eW9uZSBoYXZlIGFueSBvdXRzdGFuZGluZyBvYmplY3Rpb25zIG9uIHVzaW5nIHRoaXMgcHJvcG9z
ZWQgdGV4dA0KPj5mb3IgUmVxdWlyZW1lbnQgMS5ELCBvciBpcyBpdCBzdWZmaWNpZW50bHkgY2xl
YXIgdG8gdXBkYXRlIHRoZSBkcmFmdCwNCj4+YW5kIHJlc29sdmUgaXNzdWUgMT8NCj4+DQo+Pk9M
RCB0ZXh0IGZvciBSZXF1aXJlbWVudCAxOg0KPj4NCj4+ICAgIDEuICBBYmlsaXR5IHRvIGludGVy
YWN0IHdpdGggYm90aCBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9uDQo+Pg0KPj4g
ICAgICAgIEEuICBUaGUgYWJpbGl0eSB0byBhc2sgdGhlIG9wZXJhdGlvbmFsIGNvbXBvbmVudHMg
b2YgYSBzeXN0ZW0NCj4+ICAgICAgICAgICAgKGUuZy4sIGxpbmUgY2FyZHMpIGZvciB0aGUgY29u
ZmlndXJhdGlvbiB0aGF0IHRoZXkgYXJlDQo+PiAgICAgICAgICAgIGN1cnJlbnRseSB1c2luZy4g
IFRoaXMgaXMgdGhlICJhcHBsaWVkIGNvbmZpZ3VyYXRpb24iLg0KPj4NCj4+ICAgICAgICBCLiAg
QXBwbGllZCBjb25maWd1cmF0aW9uIGlzIHJlYWQtb25seQ0KPj4NCj4+ICAgICAgICBDLiAgVGhl
IGRhdGEgbW9kZWwgZm9yIHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgdGhlIHNhbWUgYXMN
Cj4+ICAgICAgICAgICAgdGhlIGRhdGEgbW9kZWwgZm9yIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0
aW9uIChzYW1lIGxlYXZlcykNCj4+DQo+PiAgICAgICAgRC4gIEZvciBhc3luY2hyb25vdXMgc3lz
dGVtcywgd2hlbiBmdWxseSBzeW5jaHJvbml6ZWQsIHRoZSBkYXRhDQo+PiAgICAgICAgICAgIGlu
IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgdGhlIHNhbWUgYXMgdGhlIGRhdGEgaW4gdGhl
DQo+PiAgICAgICAgICAgIGludGVuZGVkIGNvbmZpZ3VyYXRpb24uDQo+Pg0KPj4NCj4+TkVXIHRl
eHQgKGFzIGFib3ZlLCBjaGFuZ2luZyAxLkQgb25seSk6DQo+Pg0KPj4gICAgMS4gIEFiaWxpdHkg
dG8gaW50ZXJhY3Qgd2l0aCBib3RoIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24N
Cj4+DQo+PiAgICAgICAgQS4gIFRoZSBhYmlsaXR5IHRvIGFzayB0aGUgb3BlcmF0aW9uYWwgY29t
cG9uZW50cyBvZiBhIHN5c3RlbQ0KPj4gICAgICAgICAgICAoZS5nLiwgbGluZSBjYXJkcykgZm9y
IHRoZSBjb25maWd1cmF0aW9uIHRoYXQgdGhleSBhcmUNCj4+ICAgICAgICAgICAgY3VycmVudGx5
IHVzaW5nLiAgVGhpcyBpcyB0aGUgImFwcGxpZWQgY29uZmlndXJhdGlvbiIuDQo+Pg0KPj4gICAg
ICAgIEIuICBBcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgcmVhZC1vbmx5DQo+Pg0KPj4gICAgICAg
IEMuICBUaGUgZGF0YSBtb2RlbCBmb3IgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBpcyB0aGUg
c2FtZSBhcw0KPj4gICAgICAgICAgICB0aGUgZGF0YSBtb2RlbCBmb3IgdGhlIGludGVuZGVkIGNv
bmZpZ3VyYXRpb24gKHNhbWUgbGVhdmVzKQ0KPj4NCj4+ICAgICAgICBELiAgV2hlbiB0aGUgY29u
ZmlndXJhdGlvbiBjaGFuZ2UgZm9yIGFueSBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+PiAgICAg
ICAgICAgIG5vZGUgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGFwcGxpZWQgdG8gdGhlIHN5c3RlbSAo
ZS5nLiBub3QNCj4+ICAgICAgICAgICAgZmFpbGVkLCBub3IgZGVmZXJyZWQgZHVlIHRvIGFic2Vu
dCBoYXJkd2FyZSkgdGhlbiB0aGUNCj4+ICAgICAgICAgICAgZXhpc3RlbmNlIGFuZCB2YWx1ZSBv
ZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkDQo+PiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24g
bm9kZSBtdXN0IG1hdGNoIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+PiAgICAgICAgICAg
IG5vZGUuDQo+Pg0KPj4NCj4+VGhhbmtzLA0KPj5Sb2INCj4+DQo+Pg0KPj5PbiAwNi8xMC8yMDE1
IDIxOjU0LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+Pj4gT24gVHVlLCBPY3QgMDYs
IDIwMTUgYXQgMDk6MDA6MzBQTSArMDEwMCwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCj4+Pj4gSGkg
SnVlcmdlbiwNCj4+Pj4NCj4+Pj4gT24gMDYvMTAvMjAxNSAxNzowMSwgSnVlcmdlbiBTY2hvZW53
YWVsZGVyIHdyb3RlOg0KPj4+Pj4gT24gVHVlLCBPY3QgMDYsIDIwMTUgYXQgMTA6Mzg6MTFBTSAr
MDEwMCwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCj4+Pj4+PiBIaSBLZW50LA0KPj4+Pj4+DQo+Pj4+
Pj4gT24gMDYvMTAvMjAxNSAwMTo0MCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+Pj4+Pj4+IFRoaXMg
aXNzdWUgYXBwZWFycyB0byBoYXZlIGJlY29tZSBtb3JlIGxpa2UgaXNzdWUgIzUgoakgc2hvdWxk
IHdlDQo+Pj4+Pj4+bWFyaw0KPj4+Pj4+PiB0aGlzIG9uZSBhIGR1cGxpY2F0ZSBvZiB0aGUgb3Ro
ZXI/DQo+Pj4+Pj4gSSBzdWdnZXN0IHRoYXQgd2UgY2FuIGp1c3QgZmluYWxpemUgb24gdGhlIHRl
eHQgYmVpbmcgZGlzY3Vzc2VkIHRvDQo+Pj4+Pj4gcmVwbGFjZSAxLkQgYW5kIHRoZW4gcmVzb2x2
ZSBpc3N1ZSAjMS4NCj4+Pj4+Pg0KPj4+Pj4+IEphc29uIGhhZCBwcm9wb3NlZCB0aGlzIHRleHQ6
DQo+Pj4+Pj4NCj4+Pj4+PiBXaGVuIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZSBmb3IgYW55IGlu
dGVuZGVkIGNvbmZpZ3VyYXRpb24gbm9kZQ0KPj4+Pj4+aGFzDQo+Pj4+Pj4gYmVlbiBzdWNjZXNz
ZnVsbHkgYXBwbGllZCB0byB0aGUgc3lzdGVtIChlLmcuIG5vdCBmYWlsZWQsIG5vcg0KPj4+Pj4+
ZGVmZXJyZWQNCj4+Pj4+PiBkdWUgdG8gYWJzZW50IGhhcmR3YXJlKSB0aGVuIHRoZSBleGlzdGVu
Y2UgYW5kIHZhbHVlIG9mIHRoZSBhcHBsaWVkDQo+Pj4+Pj4gZXF1aXZhbGVudCBvZiB0aGUgbm9k
ZSAod2hldGhlciB0aGF0IGJlIGEgY29ycmVzcG9uZGluZyBub2RlIGluIHRoZQ0KPj4+Pj4+ZGF0
YQ0KPj4+Pj4+IG1vZGVsLCBhbiBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBpbnRlbmRl
ZCBjb25maWcgbm9kZSwgdGhlDQo+Pj4+Pj4gY29uZmlndXJhdGlvbiBub2RlIHJlYWQgZnJvbSBh
IGRpZmZlcmVudCBkYXRhc3RvcmUgb3IgY29udGV4dCwgZXRjKQ0KPj4+Pj4+bXVzdA0KPj4+Pj4+
IG1hdGNoIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIG5vZGUuDQo+Pj4+PiBJIGhhdmUgbm8g
Y2x1ZSB3aGF0ICJhbiBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBpbnRlbmRlZCBjb25m
aWcNCj4+Pj4+IG5vZGUiIG9yICJ0aGUgY29uZmlndXJhdGlvbiBub2RlIHJlYWQgZnJvbSBhIGRp
ZmZlcmVudCBkYXRhc3RvcmUgb3INCj4+Pj4+IGNvbnRleHQiIG9yICJldGMiLiBtZWFucy4gV2hh
dCBleGFjdGx5IGlzIGFuICJhcHBsaWVkIGVxdWl2YWxlbnQgb2YNCj4+Pj4+IHRoZSBub2RlIj8N
Cj4+Pj4+DQo+Pj4+Pj4gT3IgcGVyaGFwcyB0aGlzIHNsaWdodGx5IGJyaWVmZXIgYWx0ZXJuYXRp
dmUgaXMgYmV0dGVyPzoNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgIEQuICBXaGVuIHRoZSBjb25m
aWd1cmF0aW9uIGNoYW5nZSBmb3IgYW55IGludGVuZGVkDQo+Pj4+Pj4gICAgICAgICAgICAgIGNv
bmZpZ3VyYXRpb24gbm9kZSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgYXBwbGllZCB0byB0aGUNCj4+
Pj4+PiAgICAgICAgICAgICAgc3lzdGVtIChlLmcuIG5vdCBmYWlsZWQsIG5vciBkZWZlcnJlZCBk
dWUgdG8gYWJzZW50DQo+Pj4+Pj5oYXJkd2FyZSkNCj4+Pj4+PiAgICAgICAgICAgICAgdGhlbiB0
aGUgZXhpc3RlbmNlIGFuZCB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZywNCj4+Pj4+PnBvc3Np
Ymx5DQo+Pj4+Pj4gICAgICAgICAgICAgIG5vdGlvbmFsLCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24g
bm9kZSBtdXN0IG1hdGNoIHRoZQ0KPj4+Pj4+aW50ZW5kZWQNCj4+Pj4+PiAgICAgICAgICAgICAg
Y29uZmlndXJhdGlvbiBub2RlLg0KPj4+Pj4gV2hhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgcGhy
YXNlICJwb3NzaWJseSBub3Rpb25hbCI/DQo+Pj4+IFRoZXJlIHdhcyBhIGNvbmNlcm4gdGhhdCBt
eSBwcmV2aW91cyB0ZXh0LCBpLmUuIGFzIGFib3ZlIGJ1dCB3aXRob3V0DQo+Pj4+ICJwb3NzaWJs
eSBub3Rpb25hbCIsIGltcGxpZWQgdGhhdCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaGFkIHRvIGJl
DQo+Pj4+IGFjdHVhbGx5IHJlcHJlc2VudGVkIGFzIHJlYWwgZGF0YSBub2RlcyBpbiBhIFlBTkcg
c2NoZW1hLCB3aGljaCB3b3VsZA0KPj4+PiBkaXNhbGxvdyB0aGUgc29sdXRpb25zIHByZXNlbnRl
ZCBpbiBkcmFmdC1rd2F0c2VuLW5ldG1vZC1vcHN0YXRlLTAwDQo+Pj4+YW5kDQo+Pj4+IGRyYWZ0
LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMC4NCj4+Pj4NCj4+Pj4gT24gYmFsYW5jZSwg
bXkgcHJlZmVyZW5jZSBpcyB0byBleGNsdWRlIHRoZSAicG9zc2libHkgbm90aW9uYWwiIHBocmFz
ZQ0KPj4+PiBpZiB0aGUgdGV4dCBpcyBzdWZmaWNpZW50bHkgY2xlYXIgd2l0aG91dCBpdC4NCj4+
PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0w
MCBwcm9wb3NlcyB0bw0KPj4+IHJlcHJlc2VudCBhcHBsaWVkIGNvbmZpZyBhcyBub2RlcyBpbiBh
IGRpZmZlcmVudCBkYXRhc3RvcmUsIHNvIHRoZXJlDQo+Pj4gaXMgbm8gbmVlZCBmb3IgJ3Bvc3Np
Ymx5IG5vdGF0aW9uYWwnLiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeQ0KPj4+IGRyYWZ0LXdpbHRv
bi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMCBpcyByZWxldmFudCBoZXJlLiBEbyB5b3UgbWVhbg0K
Pj4+IGRyYWZ0LXdpbHRvbi1uZXRtb2Qtb3BzdGF0ZS15YW5nLTAwPyBJIGRvIGhhdmUgbWFqb3Ig
Y29uY2VybnMgYWJvdXQNCj4+PiB0aGlzIHBhcnRpY3VsYXIgcHJvcG9zYWwgc2luY2UgaXQgY2hh
bmdlcyB0aGUgWUFORyBkYXRhIGVuY29kaW5nDQo+Pj4gZnVuZGFtZW50YWxseS4gVGhlcmUgd2Fz
IGFub3RoZXIgcHJvcG9zYWwgdG8gdXNlIGF0dHJpYnV0ZXMsIHdoaWNoIGlzDQo+Pj4gYWxzbyBu
b3Qgd2l0aG91dCBwcm9ibGVtcyBidXQgaXQgaXMgbGlrZWx5IGEgYml0IGxlc3MgcGFpbmZ1bC4g
QnV0DQo+Pj4gYWdhaW4sIGl0IGFsbCBkZXBlbmRzIG9uIHRoZSBmaW5hbCBkZWZpbml0aW9uIG9m
IHdoYXQgYXBwbGllZCBjb25maWcNCj4+PiByZWFsbHkgaXMuIFNvIHdoZXJlIGlzIHRoZSBsYXRl
c3QgdmVyc2lvbiBhbmQgaG93IGZhciBhcmUgd2Ugd2l0aA0KPj4+IGFncmVlaW5nIG9uIGl0Pw0K
Pj4+DQo+Pj4gWWV0IGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgdGhpcyBpcyB0byBleHBvc2Ugbm90
IHRoZSBhcHBsaWVkIGNvbmZpZyBpbg0KPj4+IGFkZGl0aW9uIHRvIHRoZSBpbnRlbmRlZCBjb25m
aWcgKEkgaGF2ZSBiZWVuIHRvbGQgY29uZmlncyBjYW4gYmUNCj4+PiByZWFsbHkgbGFyZ2UpIGJ1
dCBpbnN0ZWFkIGV4cG9zZSBsZXRzIHNheSBhIHlhbmcgcGF0Y2ggdGhhdCBzYXlzIGhvdw0KPj4+
IHRoZSBhcHBsaWVkIGNvbmZpZyBkaWZmZXJzIGZvcm0gdGhlIHJ1bm5pbmcgY29uZmlnLiBIYXZp
bmcgdG8gcmV0cmlldmUNCj4+PiB0d28gbGFyZ2UgY29uZmlncyBqdXN0IHRvIGRpZmYgdGhlbSBs
b2NhbGx5IHNlZW1zIHRvIGEgcG90ZW50aWFsbHkNCj4+PiBleHBlbnNpdmUgZXhlcmNpc2UsIGlu
IHBhcnRpY3VsYXIgaWYgdGhlIGRpZmZlcmVuY2UgaXMgb2Z0ZW4gc21hbGwuICBJDQo+Pj4gdGhp
bmsgUmFuZHkgbWVudGlvbmVkIHNvbWV0aGluZyBsaWtlIHRoaXMgYmVmb3JlIGFuZCBubyB0aGVy
ZSBpcyBubw0KPj4+IEktRC4gQnV0IGV2ZW4gd2l0aCB0aGlzIGFwcHJvYWNoLCB0aGUgZGVmaW5p
dGlvbiB3aXRob3V0ICJwb3NzaWJseQ0KPj4+IG5vdGF0aW9uYWwnIHdvdWxkIGhvbGQ7IHlvdSB3
b3VsZCBqdXN0IG5vdCBleHBvc2UgdGhlIGFwcGxpZWQgY29uZmlnDQo+Pj4gZW50aXJlbHkgYnV0
IGluc3RlYWQgYSBwYXRjaCB0aGF0IGFsbG93cyB0byBjYWxjdWxhdGUgaXQuDQo+Pj4NCj4+PiAv
anMNCj4+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+bmV0bW9kIG1haWxpbmcgbGlzdA0KPj5uZXRtb2RAaWV0Zi5vcmcNCj4+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0K


From nobody Mon Oct 19 09:18:32 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55171A8032 for ; Mon, 19 Oct 2015 09:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbK6-kmaZqi0 for ; Mon, 19 Oct 2015 09:18:16 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689D41A8837 for ; Mon, 19 Oct 2015 09:18:16 -0700 (PDT)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 16:18:10 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.167]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 16:18:10 +0000
From: Gert Grammel 
To: Kent Watsen 
Thread-Topic: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
Thread-Index: AQHQ/Jheq6QY6D7khEW4NCO6EIWXNZ5X7weAgACLuoCAAAeIAIAAIxGAgAFEqACAA7vjgIAAlliAgABrIgCAAEK9AIAADvuAgAqACoCAAeRtAIAHuqqAgAACFbU=
Date: Mon, 19 Oct 2015 16:18:10 +0000
Message-ID: 
References: <2893568.1443738455569.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <560E4D41.3070607@cisco.com>   <560EE633.5060707@cisco.com>   <56139683.9010909@cisco.com> <20151006160138.GA50204@elstar.local> <5614285E.8060305@cisco.com> <20151006205407.GA50666@elstar.local> <561D03D3.90403@cisco.com> ,
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [95.113.185.113]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB455; 5:eOSmHPy6S301ypJkxx8MzEfMLaC0yxDiUNhKZeM5YgyQGjP5F+ONFmloU7Dooetur1Jfr4maqx34tIfQ+oyhsvAPod6O0uC8bDABHGySfvF/QZl5htzMMx0rxJa65kyk6CB8mfY6bwAx/q6U30Thow==; 24:EMU1XEns52d8zLwXI+ptmVFFmB+QBwU4e7cSfsUsr2GXCa3EeKG9GWA8oj0Nsf3cHe1cqOCSc0m2KtOZMDK1dnFsFJ/8+W5qGAr7RoLUJmc=; 20:mNzWYe9GHLTHS3NnEKW+EN94YrY2SfmhcjFafCo8pOg1tpsFMVdzrzYmXKzO4tR2QG+nMMoRWSUbEeAUicsvNQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR05MB455; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB455; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(199003)(189002)(24454002)(479174004)(5383002)(87936001)(64706001)(92566002)(19580395003)(19580405001)(1941001)(10400500002)(81156007)(97736004)(83716003)(11100500001)(99286002)(86362001)(66066001)(36756003)(105586002)(54356999)(93886004)(5001960100002)(110136002)(5002640100001)(46102003)(189998001)(76176999)(4001450100002)(2900100001)(101416001)(50986999)(2950100001)(102836002)(5004730100002)(5007970100001)(106116001)(5008740100001)(33656002)(106356001)(82746002)(15975445007)(40100003)(122556002)(561944003)(17413003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 16:18:10.4338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 16:18:22 -0000

+1
Gert=20

Sent from my Apple ][

> On 19 Oct 2015, at 18:10, Kent Watsen  wrote:
>=20
>=20
> All,
>=20
> This issue somewhat dropped from our radar - we didn't discuss it during
> the interim or since.  Nonetheless, my interpretation of the below thread
> is that Robert's proposal was accepted.  So I'm going to replace 1.D with
> the text below (albeit s/system/server/) and move this issue to the REVIE=
W
> state.
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>> On 10/14/15, 2:08 PM, "Kent Watsen"  wrote:
>>=20
>>=20
>> The new 1-D works for me.  It is similar in spirit to the proposal I jus=
t
>> sent in the issue #4 thread.
>>=20
>> Thanks,
>> Kent
>>=20
>>=20
>>> On 10/13/15, 9:14 AM, "Robert Wilton"  wrote:
>>>=20
>>> In an attempt to try and close on some of the proposed requirement text
>>> before Thursday's interim meeting.
>>>=20
>>> Does anyone have any outstanding objections on using this proposed text
>>> for Requirement 1.D, or is it sufficiently clear to update the draft,
>>> and resolve issue 1?
>>>=20
>>> OLD text for Requirement 1:
>>>=20
>>>   1.  Ability to interact with both intended and applied configuration
>>>=20
>>>       A.  The ability to ask the operational components of a system
>>>           (e.g., line cards) for the configuration that they are
>>>           currently using.  This is the "applied configuration".
>>>=20
>>>       B.  Applied configuration is read-only
>>>=20
>>>       C.  The data model for the applied configuration is the same as
>>>           the data model for the intended configuration (same leaves)
>>>=20
>>>       D.  For asynchronous systems, when fully synchronized, the data
>>>           in the applied configuration is the same as the data in the
>>>           intended configuration.
>>>=20
>>>=20
>>> NEW text (as above, changing 1.D only):
>>>=20
>>>   1.  Ability to interact with both intended and applied configuration
>>>=20
>>>       A.  The ability to ask the operational components of a system
>>>           (e.g., line cards) for the configuration that they are
>>>           currently using.  This is the "applied configuration".
>>>=20
>>>       B.  Applied configuration is read-only
>>>=20
>>>       C.  The data model for the applied configuration is the same as
>>>           the data model for the intended configuration (same leaves)
>>>=20
>>>       D.  When the configuration change for any intended configuration
>>>           node has been successfully applied to the system (e.g. not
>>>           failed, nor deferred due to absent hardware) then the
>>>           existence and value of the corresponding applied
>>>           configuration node must match the intended configuration
>>>           node.
>>>=20
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>> On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
>>>>> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
>>>>> Hi Juergen,
>>>>>=20
>>>>>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
>>>>>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
>>>>>>> Hi Kent,
>>>>>>>=20
>>>>>>>> On 06/10/2015 01:40, Kent Watsen wrote:
>>>>>>>> This issue appears to have become more like issue #5 =AD should we
>>>>>>>> mark
>>>>>>>> this one a duplicate of the other?
>>>>>>> I suggest that we can just finalize on the text being discussed to
>>>>>>> replace 1.D and then resolve issue #1.
>>>>>>>=20
>>>>>>> Jason had proposed this text:
>>>>>>>=20
>>>>>>> When the configuration change for any intended configuration node
>>>>>>> has
>>>>>>> been successfully applied to the system (e.g. not failed, nor
>>>>>>> deferred
>>>>>>> due to absent hardware) then the existence and value of the applied
>>>>>>> equivalent of the node (whether that be a corresponding node in the
>>>>>>> data
>>>>>>> model, an attribute associated with the intended config node, the
>>>>>>> configuration node read from a different datastore or context, etc)
>>>>>>> must
>>>>>>> match the intended configuration node.
>>>>>> I have no clue what "an attribute associated with the intended confi=
g
>>>>>> node" or "the configuration node read from a different datastore or
>>>>>> context" or "etc". means. What exactly is an "applied equivalent of
>>>>>> the node"?
>>>>>>=20
>>>>>>> Or perhaps this slightly briefer alternative is better?:
>>>>>>>=20
>>>>>>>         D.  When the configuration change for any intended
>>>>>>>             configuration node has been successfully applied to the
>>>>>>>             system (e.g. not failed, nor deferred due to absent
>>>>>>> hardware)
>>>>>>>             then the existence and value of the corresponding,
>>>>>>> possibly
>>>>>>>             notional, applied configuration node must match the
>>>>>>> intended
>>>>>>>             configuration node.
>>>>>> What is the purpose of the phrase "possibly notional"?
>>>>> There was a concern that my previous text, i.e. as above but without
>>>>> "possibly notional", implied that applied configuration had to be
>>>>> actually represented as real data nodes in a YANG schema, which would
>>>>> disallow the solutions presented in draft-kwatsen-netmod-opstate-00
>>>>> and
>>>>> draft-wilton-netmod-intf-ext-yang-00.
>>>>>=20
>>>>> On balance, my preference is to exclude the "possibly notional" phras=
e
>>>>> if the text is sufficiently clear without it.
>>>> My understanding is that draft-kwatsen-netmod-opstate-00 proposes to
>>>> represent applied config as nodes in a different datastore, so there
>>>> is no need for 'possibly notational'. I do not understand why
>>>> draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean
>>>> draft-wilton-netmod-opstate-yang-00? I do have major concerns about
>>>> this particular proposal since it changes the YANG data encoding
>>>> fundamentally. There was another proposal to use attributes, which is
>>>> also not without problems but it is likely a bit less painful. But
>>>> again, it all depends on the final definition of what applied config
>>>> really is. So where is the latest version and how far are we with
>>>> agreeing on it?
>>>>=20
>>>> Yet another way to look at this is to expose not the applied config in
>>>> addition to the intended config (I have been told configs can be
>>>> really large) but instead expose lets say a yang patch that says how
>>>> the applied config differs form the running config. Having to retrieve
>>>> two large configs just to diff them locally seems to a potentially
>>>> expensive exercise, in particular if the difference is often small.  I
>>>> think Randy mentioned something like this before and no there is no
>>>> I-D. But even with this approach, the definition without "possibly
>>>> notational' would hold; you would just not expose the applied config
>>>> entirely but instead a patch that allows to calculate it.
>>>>=20
>>>> /js
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Oct 19 10:07:31 2015
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D750D1A8B84; Mon, 19 Oct 2015 10:07:22 -0700 (PDT)
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.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019170722.12121.13453.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 10:07:22 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 17:07:23 -0000

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

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

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


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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 19 10:24:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0C71ACEED for ; Mon, 19 Oct 2015 10:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUlOPdth5Rjc for ; Mon, 19 Oct 2015 10:24:35 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E751ACEEB for ; Mon, 19 Oct 2015 10:24:35 -0700 (PDT)
Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB281.namprd05.prod.outlook.com (10.141.70.155) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 17:24:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 19 Oct 2015 17:24:27 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 17:24:27 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-00.txt
Thread-Index: AQHRCpCpoEhFxEan00e50QlHSS6sbp5yzc8A
Date: Mon, 19 Oct 2015 17:24:27 +0000
Message-ID: 
References: <20151019170722.12121.13453.idtracker@ietfa.amsl.com>
In-Reply-To: <20151019170722.12121.13453.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:CGgnnJGNO2iijOKb5o0b7I8htxzWxQxldzpRWmCaxCan37xtx+Ay5UceLv59VItymLY+bwYn3B/Y3gaWjc3Y0CI6amLMKJ5MrY2bH3sk9qbcos++wz1T8Ukhrqx5sZD9f19FPki6eUbE0CgdCZPeaA==; 24:pFbWgln1ywokN7PZk0ZSKl3LHaBHb8iSNsSEpQ7rK0eho0587i6tLcEIhu5Wf6h2Ug9GNtFqgF6cHgBBdJ0A7O+5CDQaoVS4wMwnFEhJIVg=; 20:+en5O9fc01qZK8MN08BDX64Tlg3/fgzZXfUkwVQeHIs/yk6fIOfnIuTrbvME/+ldnHR/R2+Fi7WiiN1W2o2HuA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
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)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(199003)(377424004)(43784003)(479174004)(101416001)(2351001)(122556002)(5002640100001)(87936001)(230783001)(5008740100001)(106356001)(107886002)(106116001)(189998001)(2501003)(450100001)(86362001)(40100003)(10400500002)(5001960100002)(66066001)(97736004)(54356999)(11100500001)(2900100001)(4001350100001)(99286002)(102836002)(2950100001)(105586002)(5004730100002)(83506001)(110136002)(19580405001)(19580395003)(92566002)(36756003)(81156007)(46102003)(64706001)(76176999)(5007970100001)(15975445007)(50986999)(4001150100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <79AE7BAE2ADC2840AB43EE2F1D955144@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 17:24:27.2805 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB281; 2:qpps1ndi1qY1ikZThrURURC/eHbpSZWq5He3Vr4HYCBcYQVXz6wcgGodXJ7mSx1cVe/0Cqda+VVggWqV1+x8baVmkHDqHpv/il45Gk9ipiUA18/T3cReQxMY4Xq1NiSX4odRwQqwzIVrJ5WvqzRvEcf6Oyoze1gw90mgL2Xv1iI=; 23:m2rz4pOaCiunoAjXCmj85QZB5WNsEsZa4taxVBR6OclV0sZ1XzPqqklCeIBzTg5wC+jGyPvE6qpm2ft+akVTfrpMBAM6sMsq8AuiuWjzz9GUAuTh/2mIzEgguKp/xgGplMVgx0pCDFvYGOmUmZpAozp5WkbDmoCZ+xtJP5NnwL+YxBPlC8W8YfW652RxIAWp
X-OriginatorOrg: juniper.net
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 17:24:38 -0000

This draft has been posted as a WG draft (i.e. s/chairs/ietf/).

Thank you everyone for the time it's taken to bring it to this state.

Moving forwards, please don't wait to post comments.   That is, it's okay
to continue the discussion before the meeting in Yokohama.  We will open
new issues on the GitHub issue tracker as needed.

Thanks again,
Kent


On 10/19/15, 1:07 PM, "internet-drafts@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the NETCONF Data Modeling Language Working
>Group of the IETF.
>
>        Title           : NETMOD Operational State Requirements
>        Authors         : Kent Watsen
>                          Thomas Nadeau
>	Filename        : draft-ietf-netmod-opstate-reqs-00.txt
>	Pages           : 8
>	Date            : 2015-10-19
>
>Abstract:
>   This document defines requirements for servers enabling better
>   visibility and control over the server's operational state.  To
>   achieve this end, this document also defines terminology describing a
>   conceptual model enabling the requirements to be expressed.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Oct 19 10:57:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DA41ACD6C for ; Mon, 19 Oct 2015 10:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vllLL25RvhCQ for ; Mon, 19 Oct 2015 10:57:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B0EEB1A924B for ; Mon, 19 Oct 2015 10:57:14 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id CA4661AE0959; Mon, 19 Oct 2015 19:57:12 +0200 (CEST)
Date: Mon, 19 Oct 2015 20:01:07 +0200 (CEST)
Message-Id: <20151019.200107.2086521465388935034.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz>
References: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] mandatory versus when
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 17:57:16 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGksDQo+IA0KPiBJIGNh
bid0IGZpbmQgYW55IHRleHQgaW4gNjAyMGJpcyB0aGF0IGRlYWxzIHdpdGggdGhlIGZvbGxvd2lu
ZyBpc3N1ZToNCj4gDQo+IGxlYWYgZm9vIHsNCj4gICAgIHdoZW4gImZhbHNlKCkiOw0KPiAgICAg
bWFuZGF0b3J5IHRydWU7DQo+ICAgICB0eXBlIGVtcHR5Ow0KPiB9DQo+IA0KPiBOb3csIHNlYy4g
Ny42LjUgKFRoZSBsZWFmJ3MgbWFuZGF0b3J5IFN0YXRlbWVudCkgc2F5czoNCj4gDQo+ICAgIG8g
IE90aGVyd2lzZSwgdGhlIGxlYWYgTVVTVCBleGlzdCBpZiB0aGUgYW5jZXN0b3Igbm9kZSBleGlz
dHMgaW4gdGhlDQo+ICAgICAgIGRhdGEgdHJlZS4NCj4gDQo+IFNvLCBpZiB3ZSBhc3N1bWUgdGhl
IGFuY2VzdG9yIG5vZGUgZXhpc3RzIGluIHRoZSBkYXRhIHRyZWUsIHRoZSBsZWFmIE1VU1QgZXhp
c3QuDQo+IA0KPiBCdXQgc2VjLiA4LjEgKENvbnN0cmFpbnRzIG9uIERhdGEpIHNheXM6DQo+IA0K
PiAgICBUaGUgZm9sbG93aW5nIHByb3BlcnRpZXMgYXJlIHRydWUgaW4gYWxsIGRhdGEgdHJlZXM6
DQo+IA0KPiAgICDigKYNCj4gDQo+ICAgIG8gIFRoZXJlIE1VU1QgYmUgbm8gbm9kZXMgdGFnZ2Vk
IHdpdGggIndoZW4iIHByZXNlbnQgaWYgdGhlICJ3aGVuIg0KPiAgICAgICBjb25kaXRpb24gZXZh
bHVhdGVzIHRvICJmYWxzZSIgaW4gdGhlIGRhdGEgdHJlZS4NCj4gDQo+IFRoZSAibWFuZGF0b3J5
IiBhbmQgIndoZW4iIHN0YXRlbWVudHMgY29udHJhZGljdCBlYWNoIG90aGVyLiBIb3cgaXMNCj4g
dGhpcyByZXNvbHZlZD8NCg0KVGhlIGlkZWEgaXMgdGhhdCBhIGZhbHNlIHdoZW4gd29ya3MgbGlr
ZSBpZi1mZWF0dXJlIC0gaWYgdGhlIHdoZW4NCmV2YWx1YXRlcyB0byBmYWxzZSB0aGVuIHRoZSBt
YW5kYXRvcnkgY29uc3RyYWludCBkb2Vzbid0IGFwcGx5Lg0KDQoNCi9tYXJ0aW4NCg==


From nobody Mon Oct 19 12:05:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D066D1B2C28 for ; Mon, 19 Oct 2015 12:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv1QpSw_LK56 for ; Mon, 19 Oct 2015 12:05:01 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652331B2BF7 for ; Mon, 19 Oct 2015 12:04:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 32A3BFB7; Mon, 19 Oct 2015 21:04:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gRyY9LOIcVhc; Mon, 19 Oct 2015 21:04:45 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Oct 2015 21:04:45 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3907D20053; Mon, 19 Oct 2015 21:04:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 47c6P12jpfbX; Mon, 19 Oct 2015 21:04:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 024662004E; Mon, 19 Oct 2015 21:04:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9058837B8759; Mon, 19 Oct 2015 21:04:41 +0200 (CEST)
Date: Mon, 19 Oct 2015 21:04:34 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20151019190432.GB81250@elstar.local>
Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" 
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 19:05:04 -0000

On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
> On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  wrote:
> 
> >
> > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > >>
> > >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> > >> rephrase the intro text in 8.2) But I think Balazs is also right.
> > >> Suppose you have:
> > >>
> > >>  leaf a {
> > >>    when "../b = 42";
> > >>    type int32;
> > >>  }
> > >>  leaf b {
> > >>    type int32;
> > >>  }
> > >>
> > >> and the db contains b=10.
> > >>
> > >> Suppose I send an edit-config with a=2.  What is the result?
> > >>
> > >>  1)  you get an error back
> > >>  2)  you get ok; the request to set a to 2 is silently dropped
> > >>  3)  something else
> > >>
> > >
> > > Isn't the simplest to always make the changes that were requested in
> > > the rpc/action (e.g. edit-config) and then to validate the result and
> > > if it fails to validate to return an error? No magic addition or
> > > removal of nodes while trying to guess what the client wanted to
> > > achieve. I am likely missing details since I never implemented this
> >
> > That would be the type of behaviour I'd prefer. The auto-deletion feature
> > also goes against the principle of least embarrassement - a trivial error
> > can inadvertently erase substantial parts of a data tree.
> >
> >
> This goes against the Postel Principle,
> You can make your code as fragile as possible if you want.
> I have always written servers that try to figure out what the client is
> doing.
> 
> It seems obvious to me that when-stmt is applied after edits are applied,
> just like a choice-stmt.
> 
> The server should not be guessing that valid edits from the client
> are really programming errors.
>

To me, auto-deletion feels fragile.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Oct 19 12:11:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11131B2C0F for ; Mon, 19 Oct 2015 12:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL1memag0unb for ; Mon, 19 Oct 2015 12:11:34 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB881B2C00 for ; Mon, 19 Oct 2015 12:11:34 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 13DE2FEC; Mon, 19 Oct 2015 21:11:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oJkZ5z3NbyG8; Mon, 19 Oct 2015 21:11:32 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Oct 2015 21:11:32 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED83820053; Mon, 19 Oct 2015 21:11:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o4hW5s4MdlMV; Mon, 19 Oct 2015 21:11:31 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82D2A2004E; Mon, 19 Oct 2015 21:11:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 750C937B8819; Mon, 19 Oct 2015 21:11:29 +0200 (CEST)
Date: Mon, 19 Oct 2015 21:11:28 +0200
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20151019191128.GC81250@elstar.local>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
References: <9351762.1445203377352.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9351762.1445203377352.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] 6020bis extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 19:11:35 -0000

On Sun, Oct 18, 2015 at 02:22:57PM -0700, Randy Presuhn wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Oct 18, 2015 5:52 AM
> >To: Martin Bjorklund 
> >Cc: andy@yumaworks.com, randy_presuhn@mindspring.com, netmod@ietf.org
> >Subject: Re: [netmod] 6020bis extensions
> ...
> >I could copy the text of the nacm:default-deny-write description
> >verbatim into the description of every object marked with
> >nacm:default-deny-write. Using an extension is just a shorthand for
> >this (with the added bonus that it is machine readable for tools). I
> >do not think such an extension can be arbitrarily ignored just because
> >a certain tool skipped over it.
> 
> I think there is a slight flaw in this line of reasoning.
> For a *parser* to ignore an extension it does not claim to support
> is really no different from that tool skipping over description text
> specifying equivalent semantics.  If a tool supported NACM,
> I doubt that there'd be any realistic expectation that it would
> be able to reach into description text to determine whether the
> natural-language specification said anything NACM-relevant,
> even though of course we'd expect a model implementation to
> abide by whatever constraints were thereby introduced.
> 
> *Parser* conformance and *model* implementation conformance
> are distinct things, and we should not confuse them.
>

Yes, I fully agree. My point is that I believe the wording in RFC
6020bis does in fact confuse these two things.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Oct 19 12:22:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8839A1B2C45 for ; Mon, 19 Oct 2015 12:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBBKIZAWkpNc for ; Mon, 19 Oct 2015 12:22:06 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 D334F1B2C3E for ; Mon, 19 Oct 2015 12:22:05 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so152817037lbc.3 for ; Mon, 19 Oct 2015 12:22:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=z8i8pAl88x5pO8c/WC7U9wqFt4brWcneX1u8PawDCGQ=; b=F/hVWDIlLGsVkFxa4+vGZE4g0pDpB9A8Rh1BMVKqFDdAVOJrpfSd9IhEo/NQfgtIMo xf7CF9PMUcLHUR5I9SZxHqnu4y94vWmrWKVAvxR30AB+AWxxBmhwcvsckPKBeWov4k7J vnCxNo73ZKfgMuEI6tg4p5rmALY4rfXvdL9aTzJjFhFx9MveyJo/4t+hnRDl9XpPoej7 y1uuBcr7M01v5ArqmppE4kdDvvSHn4TJcj/uDWfVcmDRDhwjR45c6fa1QnDry4f7AxT3 ECYGGyh4gNDdGcmj3tBC9CuuPuioVAUog+zvXeIWaOihMN9XebP3NQgrtUQRQQx3RsU7 awuQ==
X-Gm-Message-State: ALoCoQkrqZxsv9+gHTwEayEWIr1ZTY92GnAxnpDTUpGgZxZQQpK+ams/j0ciAJ2008KRXo50W2/y
MIME-Version: 1.0
X-Received: by 10.112.181.71 with SMTP id du7mr15400431lbc.37.1445282524019; Mon, 19 Oct 2015 12:22:04 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 19 Oct 2015 12:22:03 -0700 (PDT)
In-Reply-To: <20151019190432.GB81250@elstar.local>
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>  <20151019190432.GB81250@elstar.local>
Date: Mon, 19 Oct 2015 12:22:03 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3715c71e63105227a0f4c
Archived-At: 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 19:22:08 -0000

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

On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
> > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  wrote:
> >
> > >
> > > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > > >>
> > > >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> > > >> rephrase the intro text in 8.2) But I think Balazs is also right.
> > > >> Suppose you have:
> > > >>
> > > >>  leaf a {
> > > >>    when "../b = 42";
> > > >>    type int32;
> > > >>  }
> > > >>  leaf b {
> > > >>    type int32;
> > > >>  }
> > > >>
> > > >> and the db contains b=10.
> > > >>
> > > >> Suppose I send an edit-config with a=2.  What is the result?
> > > >>
> > > >>  1)  you get an error back
> > > >>  2)  you get ok; the request to set a to 2 is silently dropped
> > > >>  3)  something else
> > > >>
> > > >
> > > > Isn't the simplest to always make the changes that were requested in
> > > > the rpc/action (e.g. edit-config) and then to validate the result and
> > > > if it fails to validate to return an error? No magic addition or
> > > > removal of nodes while trying to guess what the client wanted to
> > > > achieve. I am likely missing details since I never implemented this
> > >
> > > That would be the type of behaviour I'd prefer. The auto-deletion
> feature
> > > also goes against the principle of least embarrassement - a trivial
> error
> > > can inadvertently erase substantial parts of a data tree.
> > >
> > >
> > This goes against the Postel Principle,
> > You can make your code as fragile as possible if you want.
> > I have always written servers that try to figure out what the client is
> > doing.
> >
> > It seems obvious to me that when-stmt is applied after edits are applied,
> > just like a choice-stmt.
> >
> > The server should not be guessing that valid edits from the client
> > are really programming errors.
> >
>
> To me, auto-deletion feels fragile.
>
>
Why?  Returning an error seems fragile to me.
What if the client is using a template that creates some data structure.
The request says "add foo when X is true, add bar when Y is true).
Pruning the false when-stmt is what the client should expect.
Otherwise the template is very fragile and the client has to make a
different
template for every possible permutation of the data structure with
and without false-when nodes.


/js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bier=
man wrote:

> On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> >

> > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <

> > j.schoenw=
aelder@jacobs-university.de> wrote:

> > >

> > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund w=
rote:

> > >>

> > >> Ok, you're right.=C2=A0 8.2.1 should be kept as it i=
s.=C2=A0 (we may need to

> > >> rephrase the intro text in 8.2) But I think Balazs is al=
so right.

> > >> Suppose you have:

> > >>

> > >>=C2=A0 leaf a {

> > >>=C2=A0 =C2=A0 when "../b =3D 42";

> > >>=C2=A0 =C2=A0 type int32;

> > >>=C2=A0 }

> > >>=C2=A0 leaf b {

> > >>=C2=A0 =C2=A0 type int32;

> > >>=C2=A0 }

> > >>

> > >> and the db contains b=3D10.

> > >>

> > >> Suppose I send an edit-config with a=3D2.=C2=A0 What is =
the result?

> > >>

> > >>=C2=A0 1)=C2=A0 you get an error back

> > >>=C2=A0 2)=C2=A0 you get ok; the request to set a to 2 is =
silently dropped

> > >>=C2=A0 3)=C2=A0 something else

> > >>

> > >

> > > Isn't the simplest to always make the changes that were =
requested in

> > > the rpc/action (e.g. edit-config) and then to validate the r=
esult and

> > > if it fails to validate to return an error? No magic additio=
n or

> > > removal of nodes while trying to guess what the client wante=
d to

> > > achieve. I am likely missing details since I never implement=
ed this

> >

> > That would be the type of behaviour I'd prefer. The auto-dele=
tion feature

> > also goes against the principle of least embarrassement - a trivi=
al error

> > can inadvertently erase substantial parts of a data tree.

> >

> >

> This goes against the Postel Principle,

> You can make your code as fragile as possible if you want.

> I have always written servers that try to figure out what the client i=
s

> doing.

>

> It seems obvious to me that when-stmt is applied after edits are appli=
ed,

> just like a choice-stmt.

>

> The server should not be guessing that valid edits from the client

> are really programming errors.

>



To me, auto-deletion feels fragile.



Why?=C2=A0 Returning an error seems fragile to me.
What if the client is using a template that creates some data stru=
cture.
The request says "add foo when X is true, add bar whe=
n Y is true).
Pruning the false when-stmt is what the client shou=
ld expect.
Otherwise the template is very fragile and the client =
has to make a different
template for every possible permutation o=
f the data structure with
and without false-when nodes.



/js



Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--001a11c3715c71e63105227a0f4c--


From nobody Mon Oct 19 13:17:57 2015
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E41A9060; Mon, 19 Oct 2015 13:17:36 -0700 (PDT)
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.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019201736.16324.10977.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 13:17:36 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 20:17:36 -0000

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

        Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-05.txt
	Pages           : 53
	Date            : 2015-10-19

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) implementations that utilize YANG
   data model modules.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 19 13:22:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824651AC3CD for ; Mon, 19 Oct 2015 13:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2AFt-nRjnGpX for ; Mon, 19 Oct 2015 13:22:35 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620F71AC3B6 for ; Mon, 19 Oct 2015 13:22:18 -0700 (PDT)
Received: by qgbb65 with SMTP id b65so63793175qgb.2 for ; Mon, 19 Oct 2015 13:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:subject:date:references:to:message-id :mime-version; bh=94C7xeLA9TqwnuVckqn4zBUlJLkFIVpYzh5isrcGrdc=; b=ifV12NOrlJGpCK6Ch2PXoXUgKzXMPPzmxa3inrRi0oe2w9tKh6CR49iHI0P+0nQAQa zn9r1pH/TcF1FyYokBfcupu5OWJwV0/sX4rQSyTV+yZHXK5ilkmb+CDTEe2JiD0ozeas 2RuEcG5l1N4/JHOh9+eqYR2QKWcCnBeebCmORgT0cjcerZwrucbW1cgi9CIxxsDObaN9 ruJi8TLWLEasmlT9WstmvvgK3Unxw+2tedVP3eGfp+lgzbh3nPQCOQNYwbnTN6vsweo5 HgnLSr9+ECuDsJ+7cQafMnopg2KhLouNwAAvsj1EZmpXPrxgsGeM9uQB2UPFgGbQGtVk kyCA==
X-Received: by 10.140.164.140 with SMTP id k134mr40284262qhk.40.1445286137518;  Mon, 19 Oct 2015 13:22:17 -0700 (PDT)
Received: from [10.245.39.167] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id 190sm14941997qha.41.2015.10.19.13.22.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 13:22:16 -0700 (PDT)
From: Dean Bogdanovic 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7BE5FD5A-7078-47A0-80C2-9EBBC6C3C5E2"
Date: Mon, 19 Oct 2015 16:22:15 -0400
References: <20151019144607.31997.16374.idtracker@ietfa.amsl.com>
To: netmod@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Subject: [netmod] Fwd:  I-D Action: draft-ietf-netmod-acl-model-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 20:22:37 -0000

--Apple-Mail=_7BE5FD5A-7078-47A0-80C2-9EBBC6C3C5E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This version contains comments and suggestions from mailing list and =
last mtg in Prague

Dean

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-04.txt
> Date: October 19, 2015 at 10:46:07 AM EDT
> To: 
> Cc: netmod@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>=20
>        Title           : Network Access Control List (ACL) YANG Data =
Model
>        Authors         : Dean Bogdanovic
>                          Kiran Agrahara Sreenivasa
>                          Lisa Huang
>                          Dana Blair
> 	Filename        : draft-ietf-netmod-acl-model-04.txt
> 	Pages           : 28
> 	Date            : 2015-10-17
>=20
> Abstract:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-04
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-04
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_7BE5FD5A-7078-47A0-80C2-9EBBC6C3C5E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This version contains comments and suggestions from mailing =
list and last mtg in Prague

Dean

Begin forwarded =
message:

From: =
internet-drafts@ietf.org
Subject: =
[netmod] I-D =
Action: draft-ietf-netmod-acl-model-04.txt
Date: =
October 19, 2015 at 10:46:07 AM =
EDT
To: =
<i-d-announce@ietf.org>
Cc: netmod@ietf.org


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

 =
       Title =
          : Network =
Access Control List (ACL) YANG Data Model
 =
       Authors =
        : Dean Bogdanovic
 =
            &n=
bsp;           &nbs=
p;Kiran Agrahara Sreenivasa
 =
            &n=
bsp;           &nbs=
p;Lisa Huang
 =
            &n=
bsp;           &nbs=
p;Dana Blair
	Filename =
       : =
draft-ietf-netmod-acl-model-04.txt
	Pages =
          : 28
	=
Date =
           : =
2015-10-17

Abstract:
 =
  This document describes a data model of Access Control List =
(ACL)
   basic building blocks.


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

There's also a htmlized version =
available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-04

A diff from the previous version is available =
at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model=
-04


Please note that it may =
take a couple of minutes from the time of submission
until =
the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by =
anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

=

--Apple-Mail=_7BE5FD5A-7078-47A0-80C2-9EBBC6C3C5E2--


From nobody Mon Oct 19 14:54:22 2015
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B551AC3D6; Mon, 19 Oct 2015 14:54:21 -0700 (PDT)
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.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019215421.26682.60011.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 14:54:21 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 21:54:22 -0000

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

        Title           : Network Access Control List (ACL) YANG Data Model
        Authors         : Dean Bogdanovic
                          Kiran Agrahara Sreenivasa
                          Lisa Huang
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-05.txt
	Pages           : 28
	Date            : 2015-10-19

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 19 17:39:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3241B2F75 for ; Mon, 19 Oct 2015 17:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj3Njtygy47B for ; Mon, 19 Oct 2015 17:39:46 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F1B1B2F74 for ; Mon, 19 Oct 2015 17:39:45 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Tue, 20 Oct 2015 00:39:43 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Tue, 20 Oct 2015 00:39:43 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: preliminary agenda for yokohama posted
Thread-Index: AQHRCs/Pm13hF+6R50+Ka4btt70Mzw==
Date: Tue, 20 Oct 2015 00:39:43 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:LGQUq3i/Lo0kuYyGONg0X6gJD2C2Zm8W9pFX3gN2ROOe6EwDYAAbmtIcmqmnxDVcQC1Gpk7B/en8N1/uPAC7q1tRVuPzFrvQ0wXWAzseKdoIbSNq4Jo1CQcJmh/ljSh4T8BfHre9KZzZRkJOMw8gOA==; 24:uLEjqRk/vuqjSRmHREs/bUlskGK8OiPAdD/zjUNinnnae5cpHOtltiQs/VKvKMCh7BPTIMaESqqK8HCSTn4KM6JZtUak6IoobPMFLXlL9AU=; 20:7xl8CXHeWQU0WgW8EujB+DqOqu487XrE0MvRlPZs8m1LoG5wtcMrQpHB+cdqyZCffpt12qy/8CGN+Vmh6lKEzg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(2900100001)(4001350100001)(15975445007)(86362001)(83506001)(81156007)(122556002)(99286002)(19580395003)(50986999)(102836002)(5004730100002)(105586002)(107886002)(36756003)(106116001)(2501003)(87936001)(106356001)(10400500002)(66066001)(5001960100002)(450100001)(110136002)(5002640100001)(558084003)(16236675004)(5007970100001)(2351001)(19617315012)(97736004)(54356999)(101416001)(46102003)(11100500001)(189998001)(64706001)(92566002)(5008740100001)(229853001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D24B058BE8377kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 00:39:43.3141 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [netmod] preliminary agenda for yokohama posted
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 00:39:48 -0000

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


The preliminary agenda for the two sessions at Yokohama has been posted her=
e:

https://www.ietf.org/proceedings/94/agenda/agenda-94-netmod

Obviously a lot of unknowns, but that's what "preliminary" means right?  ;)

Kent   // chair hat on


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













The preliminary =
agenda for the two sessions at Yokohama has been posted here:














Obviously a lot of unknowns, but tha=
t's what "preliminary" means right?  ;)







Kent   // chair hat on








--_000_D24B058BE8377kwatsenjunipernet_--


From nobody Mon Oct 19 18:41:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FBD1ACF02 for ; Mon, 19 Oct 2015 18:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzPwHLnWZc2o for ; Mon, 19 Oct 2015 18:41:28 -0700 (PDT)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 11E041ACF1A for ; Mon, 19 Oct 2015 18:41:28 -0700 (PDT)
Received: by lbbwb3 with SMTP id wb3so3012934lbb.1 for ; Mon, 19 Oct 2015 18:41:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2qAvzmPEZOrtXCb22WV2Dma8pdMy53Wom5nvzvwSnm8=; b=AU7DNSnQeGCnZgXI2WQz7HxHDXoCy/i5NnGAN2LrsTOH4mcBgz6s8MIv+xXgV7370y PKCVBdiUiNfZmoU5zF05VUWfcLmmagx3RVYtuzxFV9WfNIa/20x7XWQxZVCn4WddrQNy lyl0otIk5tPykd1Qarp0n90NcfBPBRdvzhHd/BdCncs8sTYK6yvQKDbn2w++Y1YNzx41 EdpDV7agNsqDsLBCfMP089UUcDrtciroghTPZu76ob4n+ZY/05d8OJlGbM6aVNoT4wNw WaE8f3t+pXMp7XRYmZaaZ79mH4WngP+FE6GLpjbg3Jwh5nsymUB95T46K1GKSjqYi+cx 0n4Q==
X-Gm-Message-State: ALoCoQkiKWgUlR3AOtY+G6gwNXpRUmVE4LlzqFFNgWOn7zcAceCSkTgmZxC+6QQWqGYtLRAPZMRR
MIME-Version: 1.0
X-Received: by 10.25.154.201 with SMTP id c192mr135488lfe.119.1445305285960; Mon, 19 Oct 2015 18:41:25 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 19 Oct 2015 18:41:25 -0700 (PDT)
Date: Mon, 19 Oct 2015 18:41:25 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114032d2297df705227f5c8d
Archived-At: 
Subject: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 01:41:29 -0000

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

Hi,

I updated the YANG guidelines draft.
All open issues have been addressed in this version.

https://github.com/netmod-wg/rfc6087bis/issues


Andy

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


Hi,

I updated the YANG guidelines draft=
.
All open issues have been addressed in this version.
=


<=
div>
Andy



--001a114032d2297df705227f5c8d--


From nobody Tue Oct 20 00:31:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7A1ACEBA for ; Tue, 20 Oct 2015 00:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI3NrL9Zt8Y7 for ; Tue, 20 Oct 2015 00:31:49 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9A11ACEA8 for ; Tue, 20 Oct 2015 00:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=82; q=dns/txt; s=iport; t=1445326309; x=1446535909; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Sd3iXbgHcLP4bdDTbeQS5pCtKiEePg+oH7SgdezqABo=; b=g7AHhHqSWnVX2Z+Ulm80zoCHcx9BrNmIOoZcTecRyvOXZ/Jrw1C/Iwxg fEr9NNarYTFzsnZ3ab/Gw3+95A5WlvqOxiNG+MFe1MwfykS9l2YrmSYaL Gu4Tpdw2UqlGP1bv31pi2qnoAJMiMsKfFYAJXX7ytZb6s+8WJyWjrIEeF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DODACg7CVW/xbLJq1ehApvuXiGCSGICgEBAQEBAYELQQEBAQEDAgKECxVANgIFFgsCCwMCAQIBSw0IAQGILA2hSo9xkxYtgSKFVYY7AYY/gUUBBIFQlFR6hB+IBoIghniTCWOCHoFnPDSCABdmKYJBAQEB
X-IronPort-AV: E=Sophos;i="5.17,706,1437436800"; d="scan'208";a="607684448"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 20 Oct 2015 07:31:47 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9K7Vld7013441 for ; Tue, 20 Oct 2015 07:31:47 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: <5625EDD1.6040808@cisco.com>
Date: Tue, 20 Oct 2015 09:31:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] And another peak of new YANG models just before the submission deadline
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 07:31:51 -0000

Dear all,

See http://claise.be/IETFYANGPageCompilation.png

Regards ,Benoit


From nobody Tue Oct 20 00:40:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191B1AD0CB for ; Tue, 20 Oct 2015 00:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65dKq1rJDqka for ; Tue, 20 Oct 2015 00:40:12 -0700 (PDT)
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 D39D51B2AA5 for ; Tue, 20 Oct 2015 00:40:11 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6] (unknown [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6]) by mail.nic.cz (Postfix) with ESMTPSA id 169CF180B22; Tue, 20 Oct 2015 09:40:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445326810; bh=1T0a7TJXgB3jsqyTLuD66ZH3RlHfYlG7hd9dXtgFjwg=; h=From:Date:To; b=g07e1JsAnsyAcfzfLP+XZ/JLeGNiCrYeDd0O3rCnRukVMpOTm0ap7qB5VZ7izz/7w 7Mk8cKMF0WO0YzC2B7jVE2rYR1KtVMq+mAl064H6t2cHqL6IChi/VXqRkfIaWc3MKY X08ykRqc+OHU0WMcqxYTH1wfcru91EjSVLOXs+IE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151019190432.GB81250@elstar.local>
Date: Tue, 20 Oct 2015 09:40:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>  <20151019190432.GB81250@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 07:40:14 -0000

> On 19 Oct 2015, at 21:04, Juergen Schoenwaelder =
 wrote:
>=20
> On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
>> On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  =
wrote:
>>=20
>>>=20
>>>> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>=20
>>>> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>>>>=20
>>>>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
>>>>> rephrase the intro text in 8.2) But I think Balazs is also right.
>>>>> Suppose you have:
>>>>>=20
>>>>> leaf a {
>>>>>   when "../b =3D 42";
>>>>>   type int32;
>>>>> }
>>>>> leaf b {
>>>>>   type int32;
>>>>> }
>>>>>=20
>>>>> and the db contains b=3D10.
>>>>>=20
>>>>> Suppose I send an edit-config with a=3D2.  What is the result?
>>>>>=20
>>>>> 1)  you get an error back
>>>>> 2)  you get ok; the request to set a to 2 is silently dropped
>>>>> 3)  something else
>>>>>=20
>>>>=20
>>>> Isn't the simplest to always make the changes that were requested =
in
>>>> the rpc/action (e.g. edit-config) and then to validate the result =
and
>>>> if it fails to validate to return an error? No magic addition or
>>>> removal of nodes while trying to guess what the client wanted to
>>>> achieve. I am likely missing details since I never implemented this
>>>=20
>>> That would be the type of behaviour I'd prefer. The auto-deletion =
feature
>>> also goes against the principle of least embarrassement - a trivial =
error
>>> can inadvertently erase substantial parts of a data tree.
>>>=20
>>>=20
>> This goes against the Postel Principle,
>> You can make your code as fragile as possible if you want.
>> I have always written servers that try to figure out what the client =
is
>> doing.
>>=20
>> It seems obvious to me that when-stmt is applied after edits are =
applied,
>> just like a choice-stmt.
>>=20
>> The server should not be guessing that valid edits from the client
>> are really programming errors.
>>=20
>=20
> To me, auto-deletion feels fragile.

+1

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Tue Oct 20 00:54:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3521B2BA6 for ; Tue, 20 Oct 2015 00:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ErMO9vwBc_f for ; Tue, 20 Oct 2015 00:54:01 -0700 (PDT)
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 4C8FA1B2BB5 for ; Tue, 20 Oct 2015 00:53:54 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6] (unknown [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6]) by mail.nic.cz (Postfix) with ESMTPSA id D122618190C; Tue, 20 Oct 2015 09:53:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445327632; bh=l4/hn+heHMzRupwk2ObdqQMtGMGB9Sq8Bw1eWpINouc=; h=From:Date:To; b=Hd1es9zLd462BmCxnn6mj3AC0axMPMNjt6UNCQ0D1vslGwKgThSMPEgbFS4GzAOX8 h5XzkI6QqGerQviL2F7QOnLN1p/kE2gbTk7lGcMcZTzSVNapM//eS0VSnoZAiWzqAF W/OvRTEVwfjEFV76WyGQl/tuJ3ZEu2hGlNKcjQfA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 20 Oct 2015 09:53:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>  <20151019190432.GB81250@elstar.local> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 07:54:03 -0000

> On 19 Oct 2015, at 21:22, Andy Bierman  wrote:
>=20
>=20
>=20
> On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder =
 wrote:
> On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
> > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  =
wrote:
> >
> > >
> > > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund =
wrote:
> > > >>
> > > >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need =
to
> > > >> rephrase the intro text in 8.2) But I think Balazs is also =
right.
> > > >> Suppose you have:
> > > >>
> > > >>  leaf a {
> > > >>    when "../b =3D 42";
> > > >>    type int32;
> > > >>  }
> > > >>  leaf b {
> > > >>    type int32;
> > > >>  }
> > > >>
> > > >> and the db contains b=3D10.
> > > >>
> > > >> Suppose I send an edit-config with a=3D2.  What is the result?
> > > >>
> > > >>  1)  you get an error back
> > > >>  2)  you get ok; the request to set a to 2 is silently dropped
> > > >>  3)  something else
> > > >>
> > > >
> > > > Isn't the simplest to always make the changes that were =
requested in
> > > > the rpc/action (e.g. edit-config) and then to validate the =
result and
> > > > if it fails to validate to return an error? No magic addition or
> > > > removal of nodes while trying to guess what the client wanted to
> > > > achieve. I am likely missing details since I never implemented =
this
> > >
> > > That would be the type of behaviour I'd prefer. The auto-deletion =
feature
> > > also goes against the principle of least embarrassement - a =
trivial error
> > > can inadvertently erase substantial parts of a data tree.
> > >
> > >
> > This goes against the Postel Principle,
> > You can make your code as fragile as possible if you want.
> > I have always written servers that try to figure out what the client =
is
> > doing.
> >
> > It seems obvious to me that when-stmt is applied after edits are =
applied,
> > just like a choice-stmt.
> >
> > The server should not be guessing that valid edits from the client
> > are really programming errors.
> >
>=20
> To me, auto-deletion feels fragile.
>=20
>=20
> Why?  Returning an error seems fragile to me.
> What if the client is using a template that creates some data =
structure.
> The request says "add foo when X is true, add bar when Y is true).
> Pruning the false when-stmt is what the client should expect.
> Otherwise the template is very fragile and the client has to make a =
different
> template for every possible permutation of the data structure with
> and without false-when nodes.

I see it otherwise. If a client wants to delete existing configuration, =
he should do it explicitly, perhaps in the same transaction. With the =
complexity of "when" evalution, it is way too easy to mess up things. =
Especially when concurrent clients modify the configuration at the same =
time, the only correct server behaviour IMO is to return a validity =
error: "I don't accept your edit because another client did some edits =
in the mean time that are incompatible with your stuff."

Lada

>=20
>=20
> /js
>=20
>=20
> Andy
> =20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Tue Oct 20 01:06:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A561B2C9B for ; Tue, 20 Oct 2015 01:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT-xGnKIdblK for ; Tue, 20 Oct 2015 01:06:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73ACD1B2CFE for ; Tue, 20 Oct 2015 01:05:40 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id F21931AE044D; Tue, 20 Oct 2015 10:05:38 +0200 (CEST)
Date: Tue, 20 Oct 2015 10:09:42 +0200 (CEST)
Message-Id: <20151020.100942.1499503452934383865.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20151019190432.GB81250@elstar.local>  
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:06:16 -0000

Ladislav Lhotka  wrote:
> 
> > On 19 Oct 2015, at 21:22, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder
> >  wrote:
> > On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
> > > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka 
> > > wrote:
> > >
> > > >
> > > > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > >
> > > > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > > > >>
> > > > >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> > > > >> rephrase the intro text in 8.2) But I think Balazs is also right.
> > > > >> Suppose you have:
> > > > >>
> > > > >>  leaf a {
> > > > >>    when "../b = 42";
> > > > >>    type int32;
> > > > >>  }
> > > > >>  leaf b {
> > > > >>    type int32;
> > > > >>  }
> > > > >>
> > > > >> and the db contains b=10.
> > > > >>
> > > > >> Suppose I send an edit-config with a=2.  What is the result?
> > > > >>
> > > > >>  1)  you get an error back
> > > > >>  2)  you get ok; the request to set a to 2 is silently dropped
> > > > >>  3)  something else
> > > > >>
> > > > >
> > > > > Isn't the simplest to always make the changes that were requested in
> > > > > the rpc/action (e.g. edit-config) and then to validate the result and
> > > > > if it fails to validate to return an error? No magic addition or
> > > > > removal of nodes while trying to guess what the client wanted to
> > > > > achieve. I am likely missing details since I never implemented this
> > > >
> > > > That would be the type of behaviour I'd prefer. The auto-deletion
> > > > feature
> > > > also goes against the principle of least embarrassement - a trivial
> > > > error
> > > > can inadvertently erase substantial parts of a data tree.
> > > >
> > > >
> > > This goes against the Postel Principle,
> > > You can make your code as fragile as possible if you want.
> > > I have always written servers that try to figure out what the client
> > > is
> > > doing.
> > >
> > > It seems obvious to me that when-stmt is applied after edits are
> > > applied,
> > > just like a choice-stmt.
> > >
> > > The server should not be guessing that valid edits from the client
> > > are really programming errors.
> > >
> > 
> > To me, auto-deletion feels fragile.
> > 
> > 
> > Why?  Returning an error seems fragile to me.
> > What if the client is using a template that creates some data
> > structure.
> > The request says "add foo when X is true, add bar when Y is true).
> > Pruning the false when-stmt is what the client should expect.
> > Otherwise the template is very fragile and the client has to make a
> > different
> > template for every possible permutation of the data structure with
> > and without false-when nodes.
> 
> I see it otherwise. If a client wants to delete existing
> configuration, he should do it explicitly, perhaps in the same
> transaction. With the complexity of "when" evalution, it is way too
> easy to mess up things. Especially when concurrent clients modify the
> configuration at the same time, the only correct server behaviour IMO
> is to return a validity error: "I don't accept your edit because
> another client did some edits in the mean time that are incompatible
> with your stuff."

I agree with Andy.  This is one of these cases where the feature might
be complicated in theoretical corner-cases, but extremely useful in
practice.  People that use YANG try to capture real-world semantics.
I have never seen anyone trying to refer to the conditional nodes in a
when expression - simply b/c it doesn't make any sense.

And anyway, changing this would be backwards incompatible, so I don't
know how constructive this conversion is right now.

At this point, it would be useful to focus on the text in 7.21.5 to
make sure it captures the current semantics.


/martin


From nobody Tue Oct 20 01:18:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41F01B2C63 for ; Tue, 20 Oct 2015 01:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVZ9c_XzDazN for ; Tue, 20 Oct 2015 01:18:15 -0700 (PDT)
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 530B71B2BEE for ; Tue, 20 Oct 2015 01:18:15 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6] (unknown [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6]) by mail.nic.cz (Postfix) with ESMTPSA id C79FB1802CC; Tue, 20 Oct 2015 10:18:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445329093; bh=MYzKJRbT1xRmzkjAqKLP+6hsMborFQVSGE+kl6J3FXw=; h=From:Date:To; b=HPtJB5J5/Ode4MiUwKsQxIw2ipd64YIKUIp77+TMFGNJfT0lfKeLxEs4vke9akhcw ZIQaB3zHJXh6C7eWU3229cS+NvVLMR2eFdcceosHnsFLKADcbahUHiFP0Yq5TJWFxW 3I6/BxC6Fg+Kk13GGNGUfPSUW2EB8QPLVj4k5NOg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151020.100942.1499503452934383865.mbj@tail-f.com>
Date: Tue, 20 Oct 2015 10:18:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BBDF825-7038-4750-91EF-E741585E4E02@nic.cz>
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:18:19 -0000

> On 20 Oct 2015, at 10:09, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 19 Oct 2015, at 21:22, Andy Bierman  wrote:
>>>=20
>>>=20
>>>=20
>>> On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder
>>>  wrote:
>>> On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
>>>> On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka 
>>>> wrote:
>>>>=20
>>>>>=20
>>>>>> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
>>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>>>=20
>>>>>> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>>>>>>=20
>>>>>>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need =
to
>>>>>>> rephrase the intro text in 8.2) But I think Balazs is also =
right.
>>>>>>> Suppose you have:
>>>>>>>=20
>>>>>>> leaf a {
>>>>>>>   when "../b =3D 42";
>>>>>>>   type int32;
>>>>>>> }
>>>>>>> leaf b {
>>>>>>>   type int32;
>>>>>>> }
>>>>>>>=20
>>>>>>> and the db contains b=3D10.
>>>>>>>=20
>>>>>>> Suppose I send an edit-config with a=3D2.  What is the result?
>>>>>>>=20
>>>>>>> 1)  you get an error back
>>>>>>> 2)  you get ok; the request to set a to 2 is silently dropped
>>>>>>> 3)  something else
>>>>>>>=20
>>>>>>=20
>>>>>> Isn't the simplest to always make the changes that were requested =
in
>>>>>> the rpc/action (e.g. edit-config) and then to validate the result =
and
>>>>>> if it fails to validate to return an error? No magic addition or
>>>>>> removal of nodes while trying to guess what the client wanted to
>>>>>> achieve. I am likely missing details since I never implemented =
this
>>>>>=20
>>>>> That would be the type of behaviour I'd prefer. The auto-deletion
>>>>> feature
>>>>> also goes against the principle of least embarrassement - a =
trivial
>>>>> error
>>>>> can inadvertently erase substantial parts of a data tree.
>>>>>=20
>>>>>=20
>>>> This goes against the Postel Principle,
>>>> You can make your code as fragile as possible if you want.
>>>> I have always written servers that try to figure out what the =
client
>>>> is
>>>> doing.
>>>>=20
>>>> It seems obvious to me that when-stmt is applied after edits are
>>>> applied,
>>>> just like a choice-stmt.
>>>>=20
>>>> The server should not be guessing that valid edits from the client
>>>> are really programming errors.
>>>>=20
>>>=20
>>> To me, auto-deletion feels fragile.
>>>=20
>>>=20
>>> Why?  Returning an error seems fragile to me.
>>> What if the client is using a template that creates some data
>>> structure.
>>> The request says "add foo when X is true, add bar when Y is true).
>>> Pruning the false when-stmt is what the client should expect.
>>> Otherwise the template is very fragile and the client has to make a
>>> different
>>> template for every possible permutation of the data structure with
>>> and without false-when nodes.
>>=20
>> I see it otherwise. If a client wants to delete existing
>> configuration, he should do it explicitly, perhaps in the same
>> transaction. With the complexity of "when" evalution, it is way too
>> easy to mess up things. Especially when concurrent clients modify the
>> configuration at the same time, the only correct server behaviour IMO
>> is to return a validity error: "I don't accept your edit because
>> another client did some edits in the mean time that are incompatible
>> with your stuff."
>=20
> I agree with Andy.  This is one of these cases where the feature might
> be complicated in theoretical corner-cases, but extremely useful in
> practice.  People that use YANG try to capture real-world semantics.
> I have never seen anyone trying to refer to the conditional nodes in a
> when expression - simply b/c it doesn't make any sense.

Note that this also applies to cases of a plain choice. If user A adds =
case C1 and user B (who is not aware of A's changes) then adds case C2, =
I don't want the server to automatically nuke A's changes. It's the same =
as in source code management systems - if there is a conflict, it is =
left to human users to resolve it.

>=20
> And anyway, changing this would be backwards incompatible, so I don't
> know how constructive this conversion is right now.

This is not true, if we stick to the YANG 1.1 constraints that are in =
the charter - no 1.0 module becomes invalid.

Lada

>=20
> At this point, it would be useful to focus on the text in 7.21.5 to
> make sure it captures the current semantics.
>=20
>=20
> /martin

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





From nobody Tue Oct 20 01:31:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C71A923D for ; Tue, 20 Oct 2015 01:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWhLnTgQKKXT for ; Tue, 20 Oct 2015 01:31:21 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CF4421A86E8 for ; Tue, 20 Oct 2015 01:31:20 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 815F91CC012C; Tue, 20 Oct 2015 10:31:24 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
In-Reply-To: <20151019.200107.2086521465388935034.mbj@tail-f.com>
References: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz> <20151019.200107.2086521465388935034.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 20 Oct 2015 10:31:17 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] mandatory versus when
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:31:26 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> I can't find any text in 6020bis that deals with the following issue:
>>=20
>> leaf foo {
>>     when "false()";
>>     mandatory true;
>>     type empty;
>> }
>>=20
>> Now, sec. 7.6.5 (The leaf's mandatory Statement) says:
>>=20
>>    o  Otherwise, the leaf MUST exist if the ancestor node exists in the
>>       data tree.
>>=20
>> So, if we assume the ancestor node exists in the data tree, the leaf MUS=
T exist.
>>=20
>> But sec. 8.1 (Constraints on Data) says:
>>=20
>>    The following properties are true in all data trees:
>>=20
>>    =E2=80=A6
>>=20
>>    o  There MUST be no nodes tagged with "when" present if the "when"
>>       condition evaluates to "false" in the data tree.
>>=20
>> The "mandatory" and "when" statements contradict each other. How is
>> this resolved?
>
> The idea is that a false when works like if-feature - if the when
> evaluates to false then the mandatory constraint doesn't apply.

I would personally prefer if "mandatory" was harder than "when" because
it is a schema constraint that can be determined upfront (so is
"if-feature"), whereas "when" needs in principle a complete data tree to
perform the evaluation.

But either way, there should be a text that states that false "when"
wins over mandatory, or the other way around. I can't find any in -08,
section 8 doesn't mention "mandatory" at all.

Lada

>
>
> /martin

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


From nobody Tue Oct 20 01:31:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917A01A86EA for ; Tue, 20 Oct 2015 01:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UyymzzQbSdb for ; Tue, 20 Oct 2015 01:31:42 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949661A86E9 for ; Tue, 20 Oct 2015 01:31:42 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2D1AQDd+iVW/xUHmMZeGQEBAQEOAQEBglwsgUMGuXKEIQENgVqGHgKBNzgUAQEBAQEBAYEKhC0BAQEBAxIoSwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGogOAaY2nXIBAQEBAQEBAwEBAQEBAQEBAQEBGIZ5hHyBPQGDHjgGgxSBFAWWJAGWTZJyHwEBQoJEgT9yhGGBBgEBAQ
X-IPAS-Result: A2D1AQDd+iVW/xUHmMZeGQEBAQEOAQEBglwsgUMGuXKEIQENgVqGHgKBNzgUAQEBAQEBAYEKhC0BAQEBAxIoSwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGogOAaY2nXIBAQEBAQEBAwEBAQEBAQEBAQEBGIZ5hHyBPQGDHjgGgxSBFAWWJAGWTZJyHwEBQoJEgT9yhGGBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,706,1437451200"; d="scan'208";a="142005400"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Oct 2015 04:31:42 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Oct 2015 04:31:41 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 20 Oct 2015 04:31:40 -0400
From: "Romascanu, Dan (Dan)" 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] And another peak of new YANG models just before the submission deadline
Thread-Index: AQHRCwlmPgG56SlLZEKPeNQ+1y354550DQYw
Date: Tue, 20 Oct 2015 08:31:39 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB556B0@AZ-FFEXMB04.global.avaya.com>
References: <5625EDD1.6040808@cisco.com>
In-Reply-To: <5625EDD1.6040808@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] And another peak of new YANG models just before the submission deadline
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:31:43 -0000

The TOTAL/COMPILATION PASSED ratio seems to have improved since April from =
~25% to ~40%. This is good, but there is room for improvement.=20

Regards,

Dan


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Tuesday, October 20, 2015 10:31 AM
> To: NETMOD Working Group
> Subject: [netmod] And another peak of new YANG models just before the
> submission deadline
>=20
> Dear all,
>=20


From nobody Tue Oct 20 01:33:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9371A923D for ; Tue, 20 Oct 2015 01:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8WcicSxTmJ5 for ; Tue, 20 Oct 2015 01:33:01 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274841A86E9 for ; Tue, 20 Oct 2015 01:33:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AcAwBBP8ZV/xUHmMZbGQEBglQsgT0GqXSTNgmHfQKBJjgUAQEBAQEBAYEKhCMBAQEBAxIoSwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGogMAax4oD4BAQEBAQEEAQEBAQEBAQEahh+FMoE9AYMaPoMSgRQFlQsBlVuRBBcPgj+BPm+BSIEEAQEB
X-IPAS-Result: A2AcAwBBP8ZV/xUHmMZbGQEBglQsgT0GqXSTNgmHfQKBJjgUAQEBAQEBAYEKhCMBAQEBAxIoSwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGogMAax4oD4BAQEBAQEEAQEBAQEBAQEahh+FMoE9AYMaPoMSgRQFlQsBlVuRBBcPgj+BPm+BSIEEAQEB
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="124978959"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Oct 2015 04:32:58 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Oct 2015 04:32:58 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 20 Oct 2015 10:32:56 +0200
From: "Romascanu, Dan (Dan)" 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] And another peak of new YANG models just before the submission deadline
Thread-Index: AQHRCwlmPgG56SlLZEKPeNQ+1y354550DQYwgAAAi3A=
Date: Tue, 20 Oct 2015 08:32:55 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB556C3@AZ-FFEXMB04.global.avaya.com>
References: <5625EDD1.6040808@cisco.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] And another peak of new YANG models just before the submission deadline
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:33:02 -0000

COMPILATION PASSED/TOTAL ratio, sorry.

Dan


> -----Original Message-----
> From: Romascanu, Dan (Dan)
> Sent: Tuesday, October 20, 2015 11:32 AM
> To: 'Benoit Claise'; NETMOD Working Group
> Subject: RE: [netmod] And another peak of new YANG models just before
> the submission deadline
>=20
> The TOTAL/COMPILATION PASSED ratio seems to have improved since April
> from ~25% to ~40%. This is good, but there is room for improvement.
>=20
> Regards,
>=20
> Dan
>=20
>=20
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit
> > Claise
> > Sent: Tuesday, October 20, 2015 10:31 AM
> > To: NETMOD Working Group
> > Subject: [netmod] And another peak of new YANG models just before the
> > submission deadline
> >
> > Dear all,
> >


From nobody Tue Oct 20 01:42:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BEA1B2E43 for ; Tue, 20 Oct 2015 01:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKFaHq42_iui for ; Tue, 20 Oct 2015 01:41:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00B1B2E41 for ; Tue, 20 Oct 2015 01:41:54 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4FCC21AE044D; Tue, 20 Oct 2015 10:41:53 +0200 (CEST)
Date: Tue, 20 Oct 2015 10:45:56 +0200 (CEST)
Message-Id: <20151020.104556.485565930610573930.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz> <20151019.200107.2086521465388935034.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=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] mandatory versus when
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 08:42:00 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3JrbHVu
ZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90
a2FAbmljLmN6PiB3cm90ZToNCj4gPj4gSGksDQo+ID4+IA0KPiA+PiBJIGNhbid0IGZpbmQgYW55
IHRleHQgaW4gNjAyMGJpcyB0aGF0IGRlYWxzIHdpdGggdGhlIGZvbGxvd2luZyBpc3N1ZToNCj4g
Pj4gDQo+ID4+IGxlYWYgZm9vIHsNCj4gPj4gICAgIHdoZW4gImZhbHNlKCkiOw0KPiA+PiAgICAg
bWFuZGF0b3J5IHRydWU7DQo+ID4+ICAgICB0eXBlIGVtcHR5Ow0KPiA+PiB9DQo+ID4+IA0KPiA+
PiBOb3csIHNlYy4gNy42LjUgKFRoZSBsZWFmJ3MgbWFuZGF0b3J5IFN0YXRlbWVudCkgc2F5czoN
Cj4gPj4gDQo+ID4+ICAgIG8gIE90aGVyd2lzZSwgdGhlIGxlYWYgTVVTVCBleGlzdCBpZiB0aGUg
YW5jZXN0b3Igbm9kZSBleGlzdHMgaW4gdGhlDQo+ID4+ICAgICAgIGRhdGEgdHJlZS4NCj4gPj4g
DQo+ID4+IFNvLCBpZiB3ZSBhc3N1bWUgdGhlIGFuY2VzdG9yIG5vZGUgZXhpc3RzIGluIHRoZSBk
YXRhIHRyZWUsIHRoZSBsZWFmIE1VU1QgZXhpc3QuDQo+ID4+IA0KPiA+PiBCdXQgc2VjLiA4LjEg
KENvbnN0cmFpbnRzIG9uIERhdGEpIHNheXM6DQo+ID4+IA0KPiA+PiAgICBUaGUgZm9sbG93aW5n
IHByb3BlcnRpZXMgYXJlIHRydWUgaW4gYWxsIGRhdGEgdHJlZXM6DQo+ID4+IA0KPiA+PiAgICDi
gKYNCj4gPj4gDQo+ID4+ICAgIG8gIFRoZXJlIE1VU1QgYmUgbm8gbm9kZXMgdGFnZ2VkIHdpdGgg
IndoZW4iIHByZXNlbnQgaWYgdGhlICJ3aGVuIg0KPiA+PiAgICAgICBjb25kaXRpb24gZXZhbHVh
dGVzIHRvICJmYWxzZSIgaW4gdGhlIGRhdGEgdHJlZS4NCj4gPj4gDQo+ID4+IFRoZSAibWFuZGF0
b3J5IiBhbmQgIndoZW4iIHN0YXRlbWVudHMgY29udHJhZGljdCBlYWNoIG90aGVyLiBIb3cgaXMN
Cj4gPj4gdGhpcyByZXNvbHZlZD8NCj4gPg0KPiA+IFRoZSBpZGVhIGlzIHRoYXQgYSBmYWxzZSB3
aGVuIHdvcmtzIGxpa2UgaWYtZmVhdHVyZSAtIGlmIHRoZSB3aGVuDQo+ID4gZXZhbHVhdGVzIHRv
IGZhbHNlIHRoZW4gdGhlIG1hbmRhdG9yeSBjb25zdHJhaW50IGRvZXNuJ3QgYXBwbHkuDQo+IA0K
PiBJIHdvdWxkIHBlcnNvbmFsbHkgcHJlZmVyIGlmICJtYW5kYXRvcnkiIHdhcyBoYXJkZXIgdGhh
biAid2hlbiINCg0KQnV0IHRoZW4gaXQgd291bGQgbmV2ZXIgYmUgcG9zc2libGUgYXVnbWVudCBt
YW5kYXRvcnkgbm9kZXMgKHNlZSB0aGF0DQpvdGhlciB0aHJlYWQpLg0KDQo+IGJlY2F1c2UNCj4g
aXQgaXMgYSBzY2hlbWEgY29uc3RyYWludCB0aGF0IGNhbiBiZSBkZXRlcm1pbmVkIHVwZnJvbnQg
KHNvIGlzDQo+ICJpZi1mZWF0dXJlIiksIHdoZXJlYXMgIndoZW4iIG5lZWRzIGluIHByaW5jaXBs
ZSBhIGNvbXBsZXRlIGRhdGEgdHJlZSB0bw0KPiBwZXJmb3JtIHRoZSBldmFsdWF0aW9uLg0KPiAN
Cj4gQnV0IGVpdGhlciB3YXksIHRoZXJlIHNob3VsZCBiZSBhIHRleHQgdGhhdCBzdGF0ZXMgdGhh
dCBmYWxzZSAid2hlbiINCj4gd2lucyBvdmVyIG1hbmRhdG9yeSwgb3IgdGhlIG90aGVyIHdheSBh
cm91bmQuIEkgY2FuJ3QgZmluZCBhbnkgaW4gLTA4LA0KPiBzZWN0aW9uIDggZG9lc24ndCBtZW50
aW9uICJtYW5kYXRvcnkiIGF0IGFsbC4NCg0KT2suICBJdCBuZWVkcyB0byBiZSBhZGRlZCBmb3Ig
Im1pbi1lbGVtZW50cyIgYXMgd2VsbDoNCg0KT0xEOg0KDQogICBvICBUaGUgIm1pbi1lbGVtZW50
cyIgYW5kICJtYXgtZWxlbWVudHMiIGNvbnN0cmFpbnRzIGFyZSBlbmZvcmNlZCBmb3INCiAgICAg
IGxpc3RzIGFuZCBsZWFmLWxpc3RzLg0KDQpORVc6DQoNCiAgIG8gIFRoZSAibWFuZGF0b3J5IiBj
b25zdHJhaW50IGlzIGVuZm9yY2VkIGZvciBsZWFmcywgdW5sZXNzIHRoZSBub2RlDQogICAgICBv
ciBhbnkgb2YgaXRzIGFuY2VzdG9ycyBoYXMgYSAid2hlbiIgY29uZGl0aW9uIG9yICJpZi1mZWF0
dXJlIg0KICAgICAgZXhwcmVzc2lvbiB0aGF0IGV2YWx1YXRlcyB0byAiZmFsc2UiLg0KDQogICBv
ICBUaGUgIm1pbi1lbGVtZW50cyIgYW5kICJtYXgtZWxlbWVudHMiIGNvbnN0cmFpbnRzIGFyZSBl
bmZvcmNlZCBmb3INCiAgICAgIGxpc3RzIGFuZCBsZWFmLWxpc3RzLCB1bmxlc3MgdGhlIG5vZGUg
b3IgYW55IG9mIGl0cyBhbmNlc3RvcnMgaGFzDQogICAgICBhICJ3aGVuIiBjb25kaXRpb24gb3Ig
ImlmLWZlYXR1cmUiIGV4cHJlc3Npb24gdGhhdCBldmFsdWF0ZXMgdG8NCiAgICAgICJmYWxzZSIu
DQoNCg0KL21hcnRpbg0K


From nobody Tue Oct 20 02:04:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42C81A86FF for ; Tue, 20 Oct 2015 02:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm5u2csxrRa0 for ; Tue, 20 Oct 2015 02:04:55 -0700 (PDT)
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 445DC1A86FC for ; Tue, 20 Oct 2015 02:04:55 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6] (unknown [IPv6:2001:718:1a02:1:dd3c:d1ca:8b46:7be6]) by mail.nic.cz (Postfix) with ESMTPSA id B5ED1180F1B; Tue, 20 Oct 2015 11:04:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445331893; bh=MOjPFYV+0ULyagpwoHelg577efaUEruZ1FzNntLKhcg=; h=From:Date:To; b=EdRwz2547zkTPhUyLEXuUVkKO2kwgMQ+z4bvD11JvhFcvJnH2j3WSI3sCdvxiwfKG OoVVjmcN4oMITxru1ucsgxT19Ua3uqoiISyxGD/tQXfKHlaMaEByC135SvsPkd5n15 RAGVt1ld5He+n66rN2mnFtiIYqjvmRQxRqQv8ttM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151020.104556.485565930610573930.mbj@tail-f.com>
Date: Tue, 20 Oct 2015 11:04:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1BF3F473-D7B4-43CC-A598-D4277449543F@nic.cz> <20151019.200107.2086521465388935034.mbj@tail-f.com>  <20151020.104556.485565930610573930.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] mandatory versus when
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 09:04:57 -0000

> On 20 Oct 2015, at 10:45, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>=20
>>>> I can't find any text in 6020bis that deals with the following =
issue:
>>>>=20
>>>> leaf foo {
>>>>    when "false()";
>>>>    mandatory true;
>>>>    type empty;
>>>> }
>>>>=20
>>>> Now, sec. 7.6.5 (The leaf's mandatory Statement) says:
>>>>=20
>>>>   o  Otherwise, the leaf MUST exist if the ancestor node exists in =
the
>>>>      data tree.
>>>>=20
>>>> So, if we assume the ancestor node exists in the data tree, the =
leaf MUST exist.
>>>>=20
>>>> But sec. 8.1 (Constraints on Data) says:
>>>>=20
>>>>   The following properties are true in all data trees:
>>>>=20
>>>>   =E2=80=A6
>>>>=20
>>>>   o  There MUST be no nodes tagged with "when" present if the =
"when"
>>>>      condition evaluates to "false" in the data tree.
>>>>=20
>>>> The "mandatory" and "when" statements contradict each other. How is
>>>> this resolved?
>>>=20
>>> The idea is that a false when works like if-feature - if the when
>>> evaluates to false then the mandatory constraint doesn't apply.
>>=20
>> I would personally prefer if "mandatory" was harder than "when"
>=20
> But then it would never be possible augment mandatory nodes (see that
> other thread).

Yes, that's why I think "when" is indispensable only as a substatement =
of "augment", and it is also where the context node problem (Y18) =
doesn't exist at all.

>=20
>> because
>> it is a schema constraint that can be determined upfront (so is
>> "if-feature"), whereas "when" needs in principle a complete data tree =
to
>> perform the evaluation.
>>=20
>> But either way, there should be a text that states that false "when"
>> wins over mandatory, or the other way around. I can't find any in =
-08,
>> section 8 doesn't mention "mandatory" at all.
>=20
> Ok.  It needs to be added for "min-elements" as well:
>=20
> OLD:
>=20
>   o  The "min-elements" and "max-elements" constraints are enforced =
for
>      lists and leaf-lists.
>=20
> NEW:
>=20
>   o  The "mandatory" constraint is enforced for leafs, unless the node
>      or any of its ancestors has a "when" condition or "if-feature"
>      expression that evaluates to "false".
>=20
>   o  The "min-elements" and "max-elements" constraints are enforced =
for
>      lists and leaf-lists, unless the node or any of its ancestors has
>      a "when" condition or "if-feature" expression that evaluates to
>      "false".

OK. Lada

>=20
>=20
> /martin

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





From nobody Tue Oct 20 02:05:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE51A871B for ; Tue, 20 Oct 2015 02:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_SiCV1cw7av for ; Tue, 20 Oct 2015 02:05:12 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 E6C5E1A871F for ; Tue, 20 Oct 2015 02:05:11 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so10108405lbc.3 for ; Tue, 20 Oct 2015 02:05:10 -0700 (PDT)
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=z1vxWjxL5UpAsNO0MAnWtmqHFb2/AXCgEMpy6knhyoA=; b=MwHsEYZTNVHdrSl15a56DO6OnjnWH+XEeMLzCHO0sNjiWndfckI2He4DfR+l9b6GhL PKvgWIlN1wEgEfQHSTduvPwV3hqY63B+8yNVgxiMhulDhU0uoZ+O9S3MPiTr8QMXo+qx odTRfe3JgNnjVxRfC6akPqhn+7xXRn1R4RxbAnQj7/P5cm/Dmj1nUZbhOgRDCQXUaUTI UNOXSy1AkyXKW4RiyNVK/7u9t0VjzwxLqqZlufFF1fKyYDy2HhiQUkaBbflrhT8dKI2d q+IFO/5KWTQE+MNmjuXRZVT5AwvbcMUFidHTL4QA83qSZ0mxMaYBCcmjTuDtSV5QqT6n ICFw==
X-Gm-Message-State: ALoCoQmhjzk4DM/UgoaDBHHdff1OY9qkY5HFNMmWs99Xw5tEeJfN0cYKXfun1Xx+I3x3I3gdQr1q
MIME-Version: 1.0
X-Received: by 10.112.181.71 with SMTP id du7mr1070909lbc.37.1445331909987; Tue, 20 Oct 2015 02:05:09 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Tue, 20 Oct 2015 02:05:09 -0700 (PDT)
In-Reply-To: <20151020.100942.1499503452934383865.mbj@tail-f.com>
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com>
Date: Tue, 20 Oct 2015 02:05:09 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c3715c13ea890522858fd5
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 09:05:15 -0000

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

On Tue, Oct 20, 2015 at 1:09 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> >
> > > On 19 Oct 2015, at 21:22, Andy Bierman  wrote:
> > >
> > >
> > >
> > > On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder
> > >  wrote:
> > > On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
> > > > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka 
> > > > wrote:
> > > >
> > > > >
> > > > > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
> > > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > > >
> > > > > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > > > > >>
> > > > > >> Ok, you're right.  8.2.1 should be kept as it is.  (we may need
> to
> > > > > >> rephrase the intro text in 8.2) But I think Balazs is also
> right.
> > > > > >> Suppose you have:
> > > > > >>
> > > > > >>  leaf a {
> > > > > >>    when "../b = 42";
> > > > > >>    type int32;
> > > > > >>  }
> > > > > >>  leaf b {
> > > > > >>    type int32;
> > > > > >>  }
> > > > > >>
> > > > > >> and the db contains b=10.
> > > > > >>
> > > > > >> Suppose I send an edit-config with a=2.  What is the result?
> > > > > >>
> > > > > >>  1)  you get an error back
> > > > > >>  2)  you get ok; the request to set a to 2 is silently dropped
> > > > > >>  3)  something else
> > > > > >>
> > > > > >
> > > > > > Isn't the simplest to always make the changes that were
> requested in
> > > > > > the rpc/action (e.g. edit-config) and then to validate the
> result and
> > > > > > if it fails to validate to return an error? No magic addition or
> > > > > > removal of nodes while trying to guess what the client wanted to
> > > > > > achieve. I am likely missing details since I never implemented
> this
> > > > >
> > > > > That would be the type of behaviour I'd prefer. The auto-deletion
> > > > > feature
> > > > > also goes against the principle of least embarrassement - a trivial
> > > > > error
> > > > > can inadvertently erase substantial parts of a data tree.
> > > > >
> > > > >
> > > > This goes against the Postel Principle,
> > > > You can make your code as fragile as possible if you want.
> > > > I have always written servers that try to figure out what the client
> > > > is
> > > > doing.
> > > >
> > > > It seems obvious to me that when-stmt is applied after edits are
> > > > applied,
> > > > just like a choice-stmt.
> > > >
> > > > The server should not be guessing that valid edits from the client
> > > > are really programming errors.
> > > >
> > >
> > > To me, auto-deletion feels fragile.
> > >
> > >
> > > Why?  Returning an error seems fragile to me.
> > > What if the client is using a template that creates some data
> > > structure.
> > > The request says "add foo when X is true, add bar when Y is true).
> > > Pruning the false when-stmt is what the client should expect.
> > > Otherwise the template is very fragile and the client has to make a
> > > different
> > > template for every possible permutation of the data structure with
> > > and without false-when nodes.
> >
> > I see it otherwise. If a client wants to delete existing
> > configuration, he should do it explicitly, perhaps in the same
> > transaction. With the complexity of "when" evalution, it is way too
> > easy to mess up things. Especially when concurrent clients modify the
> > configuration at the same time, the only correct server behaviour IMO
> > is to return a validity error: "I don't accept your edit because
> > another client did some edits in the mean time that are incompatible
> > with your stuff."
>
> I agree with Andy.  This is one of these cases where the feature might
> be complicated in theoretical corner-cases, but extremely useful in
> practice.  People that use YANG try to capture real-world semantics.
> I have never seen anyone trying to refer to the conditional nodes in a
> when expression - simply b/c it doesn't make any sense.
>
> And anyway, changing this would be backwards incompatible, so I don't
> know how constructive this conversion is right now.
>
>
+1

The false-when deletion has been there from the start,
and works just like the remove-old-case-stmt if the
client selects a new case from a choice-stmt.

The 'shared candidate  without a lock' argument does not apply at all.
That is fragile with or without when-stmts.

The argument "the client might not know what it is doing"
is also really weak.  How does the server know that?


At this point, it would be useful to focus on the text in 7.21.5 to
> make sure it captures the current semantics.
>
>
> /martin
>


Andy

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




On Tue, Oct 20, 2015 at 1:09 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 19 Oct 2015, at 21:22, Andy Bierman <andy@yumaworks.com> wrote:

> >

> >

> >

> > On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder

> > <j.sch=
oenwaelder@jacobs-university.de> wrote:

> > On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:

> > > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka <lhotka@nic.cz>

> > > wrote:

> > >

> > > >

> > > > > On 18 Oct 2015, at 11:52, Juergen Schoenwaelder &l=
t;

> > > > j.schoenwaelder@jacobs-university.de> wrote:

> > > > >

> > > > > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin B=
jorklund wrote:

> > > > >>

> > > > >> Ok, you're right.=C2=A0 8.2.1 should be ke=
pt as it is.=C2=A0 (we may need to

> > > > >> rephrase the intro text in 8.2) But I think Ba=
lazs is also right.

> > > > >> Suppose you have:

> > > > >>

> > > > >>=C2=A0 leaf a {

> > > > >>=C2=A0 =C2=A0 when "../b =3D 42";

> > > > >>=C2=A0 =C2=A0 type int32;

> > > > >>=C2=A0 }

> > > > >>=C2=A0 leaf b {

> > > > >>=C2=A0 =C2=A0 type int32;

> > > > >>=C2=A0 }

> > > > >>

> > > > >> and the db contains b=3D10.

> > > > >>

> > > > >> Suppose I send an edit-config with a=3D2.=C2=
=A0 What is the result?

> > > > >>

> > > > >>=C2=A0 1)=C2=A0 you get an error back

> > > > >>=C2=A0 2)=C2=A0 you get ok; the request to set =
a to 2 is silently dropped

> > > > >>=C2=A0 3)=C2=A0 something else

> > > > >>

> > > > >

> > > > > Isn't the simplest to always make the changes =
that were requested in

> > > > > the rpc/action (e.g. edit-config) and then to vali=
date the result and

> > > > > if it fails to validate to return an error? No mag=
ic addition or

> > > > > removal of nodes while trying to guess what the cl=
ient wanted to

> > > > > achieve. I am likely missing details since I never=
 implemented this

> > > >

> > > > That would be the type of behaviour I'd prefer. The=
 auto-deletion

> > > > feature

> > > > also goes against the principle of least embarrassement=
 - a trivial

> > > > error

> > > > can inadvertently erase substantial parts of a data tre=
e.

> > > >

> > > >

> > > This goes against the Postel Principle,

> > > You can make your code as fragile as possible if you want.
> > > I have always written servers that try to figure out what th=
e client

> > > is

> > > doing.

> > >

> > > It seems obvious to me that when-stmt is applied after edits=
 are

> > > applied,

> > > just like a choice-stmt.

> > >

> > > The server should not be guessing that valid edits from the =
client

> > > are really programming errors.

> > >

> >

> > To me, auto-deletion feels fragile.

> >

> >

> > Why?=C2=A0 Returning an error seems fragile to me.

> > What if the client is using a template that creates some data

> > structure.

> > The request says "add foo when X is true, add bar when Y is =
true).

> > Pruning the false when-stmt is what the client should expect.

> > Otherwise the template is very fragile and the client has to make=
 a

> > different

> > template for every possible permutation of the data structure wit=
h

> > and without false-when nodes.

>

> I see it otherwise. If a client wants to delete existing

> configuration, he should do it explicitly, perhaps in the same

> transaction. With the complexity of "when" evalution, it is =
way too

> easy to mess up things. Especially when concurrent clients modify the<=
br>
> configuration at the same time, the only correct server behaviour IMO<=
br>
> is to return a validity error: "I don't accept your edit beca=
use

> another client did some edits in the mean time that are incompatible
> with your stuff."



I agree with Andy.=C2=A0 This is one of these cases where the feature might=


be complicated in theoretical corner-cases, but extremely useful in

practice.=C2=A0 People that use YANG try to capture real-world semantics.
I have never seen anyone trying to refer to the conditional nodes in a

when expression - simply b/c it doesn't make any sense.



And anyway, changing this would be backwards incompatible, so I don't
know how constructive this conversion is right now.



+1

The false-=
when deletion has been there from the start,
and works just like =
the remove-old-case-stmt if the
client selects a new case from a =
choice-stmt.

The 'shared candidate =C2=A0witho=
ut a lock' argument does not apply at all.
That is fragile wi=
th or without when-stmts.

The argument "the c=
lient might not know what it is doing"
is also really weak.=
=C2=A0 How does the server know that?



At this point, it would be useful to focus on the text in 7.21.5 to

make sure it captures the current semantics.





/martin




<=
/div>
Andy



--001a11c3715c13ea890522858fd5--


From nobody Tue Oct 20 02:08:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D011B2FEC for ; Tue, 20 Oct 2015 02:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUwVWfkFa2Tz for ; Tue, 20 Oct 2015 02:08:21 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6671B2FE8 for ; Tue, 20 Oct 2015 02:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1774; q=dns/txt; s=iport; t=1445332102; x=1446541702; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=sYeJyh3AVdfzq+sN9/clnt1BYqoW53KGrX6kZEHFPSA=; b=FiCBQIRtOK1QRow97qnGNsU57EkY4+QIshQO2MEknkzzJU/xksEClHT9 anbR1qjgJnix1Nx540jqYeiFEDwvll9oOvtMFPWVLpNWepwd+tOwWwBCA 4VmPdFwY+/eBQv7y874olBF/kK9FER5hbz3ogMTw6HPFbYqbDWfVVZZPE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAQCJAyZW/xbLJq1ehApvuXmEIQENgVohhX0CgXAUAQEBAQEBAYEKhC0BAQEEOE0ECwcKBAEBCh4HDwI1CQgGAQwGAgEBEIgcDcQBAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3hH6BPQGDVgaEKAEEliSFGYgGiRiTCR8BAUKCHiaBQTw0AYVmAQEB
X-IronPort-AV: E=Sophos;i="5.17,706,1437436800"; d="scan'208";a="612294539"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 20 Oct 2015 09:08:20 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9K98Ic0007471; Tue, 20 Oct 2015 09:08:18 GMT
To: "Romascanu, Dan (Dan)" , NETMOD Working Group 
References: <5625EDD1.6040808@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA5CB556C3@AZ-FFEXMB04.global.avaya.com>
From: Benoit Claise 
Message-ID: <56260471.30606@cisco.com>
Date: Tue, 20 Oct 2015 11:08:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB556C3@AZ-FFEXMB04.global.avaya.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] And another peak of new YANG models just before the submission deadline
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 09:08:23 -0000

Dear all,

To extend on Dan's reply: Clearly, there is room for improvement!

The IETF 94 tutorial, 
https://www.ietf.org/meeting/94/tutorials/yang-tutorial-hackathon.html, 
which will explain how to use pyang, should be compulsory for everybody 
posting a YANG model that doesn't compile.  Actually, "must be 
compulsory" :-)

The community has been building all the necessary tools:
- Martin Bjorklund posted pyang version 1.6. Get it from 
https://github.com/mbj4668/pyang
- Carl Moberg built http://www.yangvalidator.com/
- Mahesh and I sent regular direct emails to draft authors, pointing to 
the compilation errors from 
http://www.claise.be/IETFYANGPageCompilation.html
- The tools team (Henrik Levkowetz and Robert Sparks) will be 
incorporating pyang directly in idnits by January.
- And more tools to come at this hackathon.

So no more excuses. At this point, most YANG modules must be compiling.

Regards, Benoit
> COMPILATION PASSED/TOTAL ratio, sorry.
>
> Dan
>
>
>> -----Original Message-----
>> From: Romascanu, Dan (Dan)
>> Sent: Tuesday, October 20, 2015 11:32 AM
>> To: 'Benoit Claise'; NETMOD Working Group
>> Subject: RE: [netmod] And another peak of new YANG models just before
>> the submission deadline
>>
>> The TOTAL/COMPILATION PASSED ratio seems to have improved since April
>> from ~25% to ~40%. This is good, but there is room for improvement.
>>
>> Regards,
>>
>> Dan
>>
>>
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit
>>> Claise
>>> Sent: Tuesday, October 20, 2015 10:31 AM
>>> To: NETMOD Working Group
>>> Subject: [netmod] And another peak of new YANG models just before the
>>> submission deadline
>>>
>>> Dear all,
>>>
> .
>


From nobody Tue Oct 20 03:35:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34E1B3276 for ; Tue, 20 Oct 2015 03:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.168
X-Spam-Level: *
X-Spam-Status: No, score=1.168 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-XZ7lo1qd-U for ; Tue, 20 Oct 2015 03:35:27 -0700 (PDT)
Received: from teledg001ba020.telecomitalia.it (teledg001ba020.telecomitalia.it [156.54.233.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00371B3274 for ; Tue, 20 Oct 2015 03:35:25 -0700 (PDT)
Received: from TELCAH002BA020.telecomitalia.local (10.188.101.216) by teledg001ba020.telecomitalia.it (10.188.101.210) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 Oct 2015 12:35:22 +0200
Received: from TELMBA001BA020.telecomitalia.local ([169.254.1.132]) by TELCAH002BA020.telecomitalia.local ([10.188.101.216]) with mapi id 14.03.0181.006; Tue, 20 Oct 2015 12:35:22 +0200
From: De Noia Giuseppe 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] About correlation between snmp alarms and yang structures
Thread-Index: AdEIGvq/yGk/yTLQRBeWDmLVFSIzlv//46CA//nloiA=
Date: Tue, 20 Oct 2015 10:35:22 +0000
Message-ID: <167E7B4797E08C4DBC40AED09620195944BFFF5E@TELMBA001BA020.telecomitalia.local>
References: <167E7B4797E08C4DBC40AED09620195944BFEEF0@TELMBA001BA020.telecomitalia.local> <20151016141841.GA74475@elstar.local>
In-Reply-To: <20151016141841.GA74475@elstar.local>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.188.101.189]
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: [netmod] R: About correlation between snmp alarms and yang structures
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 10:35:29 -0000

Hi,
thank you Juergen for your reply.
For an interface alarm the standardized YANG module already provide what is=
 needed.
Nevertheless my question addressed a broader scope. SNMP alarms or other ty=
pe of notifications could regard many parts of the network element, so in m=
y opinion, we need a more generic approach to the problem.

Regards,
Giuseppe

-----Messaggio originale-----
Da: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Inviato: venerd=EC 16 ottobre 2015 16:19
A: De Noia Giuseppe
Cc: netmod@ietf.org
Oggetto: Re: [netmod] About correlation between snmp alarms and yang struct=
ures

Hi,

if you implement the ietf-interfaces YANG module including the if-mib featu=
re, then /interfaces-state/interface/if-index provides you the ifIndex valu=
e that MIB modules usually use to identify an interface.

/js

On Fri, Oct 16, 2015 at 02:04:38PM +0000, De Noia Giuseppe wrote:
> Hi guys,
> I have a question about Yang language support for snmp alarm correlation.
> It could be nice if a device supplier, specifying the Yang model of his n=
etwork element, could also specify the correspondence between snmp alarms p=
roduced and affected part of the yang model of its device. This will allow =
for correlation between snmp traps (or other events) affecting a given obje=
ct  and the service instance created (through Netconf/yang) on that object.
>=20
> As for example, let's say a device send the following trap
>=20
> xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/2015=
 14:13:27
>   Time stamp: 0 days 00h:00m:40s.15th
>   Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: =
SNMPv2c Notification
>   Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
>   Community: public
>   Enterprise: enterprises.8072.3.2.10
>   Bindings (8)
>     Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
>     Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
>     Binding #3: ifIndex.6 *** (int32) 6
>     Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
>     Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
>     Binding #6: ifAdminStatus.6 *** (int32) down(2)
>     Binding #7: ifOperStatus.6 *** (int32) down(2)
>     Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10
>=20
> On the same device I created a service instance, which consists on an=20
> interface configuration . The interface, described through the YANG=20
> model is the following=20
> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.=3D'dp0s3']
>=20
> Actually the SNMP trap impacts on the same interface where I configured m=
y service instance, but I have no means to understand it.
>=20
> How can I enrich my YANG model to support the information that a trap wit=
h oid=3D snmpTraps.3 and ifDescr =3D dp0s3 affect the same interface descri=
bed in Yang by the xpath expression /tns:data/tnsA:interfaces/tnsB:dataplan=
e/tnsB:tagnode[.=3D'dp0s3']?
>=20
> Do I need to define a new YANG extension statement to carry on such a cor=
respondence, or can I rely on existing structures?
>=20
> Regards,
> Giuseppe De Noia
>=20
>=20
>=20
>=20
> ------------------------------------------------------------------
> Telecom Italia
> Giuseppe De Noia
> T.TG.NM.OSI,
> Via Reiss Romoli, 274  10148 Torino
> 011 2288887
> 331 6001197
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p=
ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da=
lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a=
bbiate ricevuto questo documento per errore siete cortesemente pregati di d=
arne immediata comunicazione al mittente e di provvedere alla sua distruzio=
ne, Grazie.
>=20
> This e-mail and any attachments is confidential and may contain privilege=
d information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended=
 recipient, please delete this message and any attachments and advise the s=
ender by return e-mail, Thanks.
>=20
> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non=
 ? necessario.
>=20


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


--=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 Oct 20 03:53:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137FD1B32B3 for ; Tue, 20 Oct 2015 03:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMUES8upPW-x for ; Tue, 20 Oct 2015 03:53:21 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03751B32B0 for ; Tue, 20 Oct 2015 03:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5229; q=dns/txt; s=iport; t=1445338400; x=1446548000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GiOw6wSM24u4HRqcil8DjOzyLvi2+P+Fr9l1yVOApRg=; b=kObwJP444Kdt5C6zdmNxvQR+3KzULMJedKtcUdYxs+HeS/tCxoLCuhoP mBXJTR2fjx3RnWSVhn3HUbEemmzKtBaP9FnqAKtx67jhYwYQf2fFXP00H 1f055woap559BYpALoOk2rsIVF/kMBrH+FwcSiik2HxMyIxit7DnnjVma 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D5AQD4GyZW/5ldJa1UBwODNlRvBr4UAQ2BWhcKhTNKAoE7OBQBAQEBAQEBgQqELQEBAQMBAQEBawsFCQICAQgQCCcHGwwLFBECBA4FFIgUCA3EAQEBAQEBAQEBAQEBAQEBAQEBAQEBARgEhnOCEIJuhDALAQEdIwsFBxKDCIEUBYc+jmYBhRiIBoFYhD+JJIF7hnyDbgEfAQFCghEdgVVyhCc6gQYBAQE
X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208";a="199283656"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2015 10:53:19 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9KArJuJ015814 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 10:53:19 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 05:53:01 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 05:53:01 -0500
From: "Carl Moberg (camoberg)" 
To: De Noia Giuseppe 
Thread-Topic: [netmod] About correlation between snmp alarms and yang structures
Thread-Index: AQHRCyV9RWV4acULjEePyiC4bf0Q2w==
Date: Tue, 20 Oct 2015 10:53:01 +0000
Message-ID: <123CAC2D-7B59-4AEB-B32A-85C7896CA228@cisco.com>
References: <167E7B4797E08C4DBC40AED09620195944BFEEF0@TELMBA001BA020.telecomitalia.local> <20151016141841.GA74475@elstar.local> <167E7B4797E08C4DBC40AED09620195944BFFF5E@TELMBA001BA020.telecomitalia.local>
In-Reply-To: <167E7B4797E08C4DBC40AED09620195944BFFF5E@TELMBA001BA020.telecomitalia.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.147.40.135]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] About correlation between snmp alarms and yang structures
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 10:53:23 -0000

Guiseppe,

 Did you review the "YANG Alarm Module=94 (https://tools.ietf.org/html/draf=
t-vallin-alarm-yang-module-00)? Perhaps there are some concepts in there th=
at you might find applicable and useful.

> On Oct 20, 2015, at 12:35 PM, De Noia Giuseppe  wrote:
>=20
> Hi,
> thank you Juergen for your reply.
> For an interface alarm the standardized YANG module already provide what =
is needed.
> Nevertheless my question addressed a broader scope. SNMP alarms or other =
type of notifications could regard many parts of the network element, so in=
 my opinion, we need a more generic approach to the problem.
>=20
> Regards,
> Giuseppe
>=20
> -----Messaggio originale-----
> Da: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
> Inviato: venerd=EC 16 ottobre 2015 16:19
> A: De Noia Giuseppe
> Cc: netmod@ietf.org
> Oggetto: Re: [netmod] About correlation between snmp alarms and yang stru=
ctures
>=20
> Hi,
>=20
> if you implement the ietf-interfaces YANG module including the if-mib fea=
ture, then /interfaces-state/interface/if-index provides you the ifIndex va=
lue that MIB modules usually use to identify an interface.
>=20
> /js
>=20
> On Fri, Oct 16, 2015 at 02:04:38PM +0000, De Noia Giuseppe wrote:
>> Hi guys,
>> I have a question about Yang language support for snmp alarm correlation=
.
>> It could be nice if a device supplier, specifying the Yang model of his =
network element, could also specify the correspondence between snmp alarms =
produced and affected part of the yang model of its device. This will allow=
 for correlation between snmp traps (or other events) affecting a given obj=
ect  and the service instance created (through Netconf/yang) on that object=
.
>>=20
>> As for example, let's say a device send the following trap
>>=20
>> xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/201=
5 14:13:27
>>  Time stamp: 0 days 00h:00m:40s.15th
>>  Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: =
SNMPv2c Notification
>>  Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
>>  Community: public
>>  Enterprise: enterprises.8072.3.2.10
>>  Bindings (8)
>>    Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
>>    Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
>>    Binding #3: ifIndex.6 *** (int32) 6
>>    Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
>>    Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
>>    Binding #6: ifAdminStatus.6 *** (int32) down(2)
>>    Binding #7: ifOperStatus.6 *** (int32) down(2)
>>    Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10
>>=20
>> On the same device I created a service instance, which consists on an=20
>> interface configuration . The interface, described through the YANG=20
>> model is the following=20
>> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.=3D'dp0s3']
>>=20
>> Actually the SNMP trap impacts on the same interface where I configured =
my service instance, but I have no means to understand it.
>>=20
>> How can I enrich my YANG model to support the information that a trap wi=
th oid=3D snmpTraps.3 and ifDescr =3D dp0s3 affect the same interface descr=
ibed in Yang by the xpath expression /tns:data/tnsA:interfaces/tnsB:datapla=
ne/tnsB:tagnode[.=3D'dp0s3']?
>>=20
>> Do I need to define a new YANG extension statement to carry on such a co=
rrespondence, or can I rely on existing structures?
>>=20
>> Regards,
>> Giuseppe De Noia
>>=20
>>=20
>>=20
>>=20
>> ------------------------------------------------------------------
>> Telecom Italia
>> Giuseppe De Noia
>> T.TG.NM.OSI,
>> Via Reiss Romoli, 274  10148 Torino
>> 011 2288887
>> 331 6001197
>>=20
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle =
persone indicate. La diffusione, copia o qualsiasi altra azione derivante d=
alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora =
abbiate ricevuto questo documento per errore siete cortesemente pregati di =
darne immediata comunicazione al mittente e di provvedere alla sua distruzi=
one, Grazie.
>>=20
>> This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, =
printing or use by anybody else is unauthorised. If you are not the intende=
d recipient, please delete this message and any attachments and advise the =
sender by return e-mail, Thanks.
>>=20
>> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se no=
n ? necessario.
>>=20
>=20
>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 20 04:29:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35A41B3320 for ; Tue, 20 Oct 2015 04:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR8GVwJi8NGe for ; Tue, 20 Oct 2015 04:29:21 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5981B331F for ; Tue, 20 Oct 2015 04:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6976; q=dns/txt; s=iport; t=1445340562; x=1446550162; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0OqBMpglv+e5E4I+IuffuHN4VHnjotx5GX9WOu1LX1E=; b=WSZmqzNq6lbvNZcXtaIjURr+/DsuoJe4UQmYJL6rfYMv647Mi9yhcJuM lEkz5pKv2oBTHV268ug13CuX8IdlLQimh0YhpIDs1kAdlL9hjTYJsT79x L5pnv/Mzry+xzbtj4LJu155qprAjJTvEr737W9ICUO7pjLcUb1aHJC8zI o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D7AQBPJCZW/4YNJK1egzZUYA8GvhUBDYFaFwqFM0oCHIEfOBQBAQEBAQEBgQqELQEBAQMBAQEBIBE6BAcFCwIBBgIRAwECAQICHwcCAgIlCxUICAIEAQ0FCYgfCA2TI503kxUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgSKFVoIPgm6CQoFyPhsHgmkxgRQFliQBhRiIBoFYhD+DJJJlAR8BAUKCRIE/coQeQ4EGAQEB
X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208";a="39211593"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 20 Oct 2015 11:29:21 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9KBTKes012419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 11:29:20 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 06:29:01 -0500
Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 06:29:01 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "Carl Moberg (camoberg)" 
Thread-Topic: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Thread-Index: AQHRBbsqf5R98Ya67USKuIH5IQB1mp5roJcAgAE8JgCAAA1iAIAHs1iA
Date: Tue, 20 Oct 2015 11:29:01 +0000
Message-ID: <5069D46B-27C7-4927-8E8A-0253A39F2F38@cisco.com>
References:  <561D0724.1030602@cisco.com>  <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> <561FAFDE.4020007@cisco.com>
In-Reply-To: <561FAFDE.4020007@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.106.13]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 11:29:23 -0000

Q2FybCwNCg0KQSBiaXQgb2YgYSBsYXRlIHJlc3BvbnNlLCBzb3JyeSwgYnV0IHdhcyBvbiB2YWNh
dGlvbi4gUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gT24gT2N0IDE1LCAyMDE1LCBhdCAyOjUzIFBN
LCBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxy
d2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4gT24gMTUvMTAv
MjAxNSAxNDowNSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSB3cm90ZToNCj4+ICBNYXliZSB3ZeKA
mXJlIGNvbWluZyBkb3duIHRvIGEgZGVmaW5pdGlvbiBvZiDigJxyZXF1aXJlbWVudOKAnSBoZXJl
LiBCdXQgdGhlIGlzc3VlIEkgcmFpc2VkIGNhbiBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6DQo+
PiANCj4+IOKAnOKAneKAnQ0KPj4gVGhlIGFzc3VtcHRpb24gb2YgYSAxOjEgbWFwcGluZyBpZ25v
cmVzIHNpdHVhdGlvbnMgd2hlcmUgYSBjaGFuZ2UgdG8gYW4gaW50ZW5kZWQgY29uZmlndXJhdGlv
biBsZWFmIHZhbHVlIG1heSByZXN1bHQgaW4gc2V2ZXJhbCBpbnN0YW5jZXMgb2YgYXBwbGllZCBj
b25maWd1cmF0aW9uIGxlYWYgdmFsdWVzIChvcGVyYXRpb25hbCBzdGF0ZSkgdG8gYmUgdXBkYXRl
ZCBpbiB0aGUgYmFja2VuZCBmcmFtZXdvcmsgYWNyb3NzIHNldmVyYWwgc3Vic3lzdGVtcy4NCj4+
IOKAnOKAnSINCg0KVGhlIG9wZXJhdGlvbmFsIHN0YXRlIHlvdSBhcmUgdGFraW5nIGFib3V0IGhl
cmUgaXMgbm90LCBwZXIgbXkgdW5kZXJzdGFuZGluZyBvZiAiYXBwbGllZCBjb25maWd1cmF0aW9u
IiB3aGF0IGlzIG1lYW50IGJ5IGFwcGxpZWQgY29uZmlndXJhdGlvbi4gVGhlICJzZXZlcmFsIGlu
c3RhbmNlcyIgYXJlIGluc3RlYWQgaW1wbGVtZW50YXRpb24gZGV0YWlsIHRoYXQgYXJlIHBlcmhh
cHMgY2hhbmdlZCBhcyBhIHJlc3VsdCBvZiBjaGFuZ2luZyBhIHNpbmdsZSBpbnRlbmRlZCBjb25m
aWd1cmF0aW9uIGxlYWYuDQoNCkFuZCBhdCB0aGlzIHBvaW50IEkgYWdyZWUgd2l0aCBSb2IgYW5k
IHdpbGwgc2F5IHRoYXQsIGZyb20gYW4gZW5kIHVzZXIncyBwZXJzcGVjdGl2ZSwgaXQgaXMgbm90
IHJlYXNvbmFibGUgdG8gZXhwZWN0IHRoZW0gdG8gcGF0Y2ggdG9nZXRoZXIgdGhlIDE6TiByZWxh
dGlvbnNoaXAgYmV0d2VlbiBpbnRlbmRlZCBjb25maWcgYW5kIHdoYXQgSSB3aWxsIGNhbGwgIm9w
ZXJhdGlvbmFsIHN0YXRlIiAoTk9UIGFwcGxpZWQgY29uZmlndXJhdGlvbikgdG8gZGV0ZXJtaW5l
IGlmIHRoZSBkZXZpY2UgaXMgYWN0dWFsbHkgZG9pbmcgd2hhdCBpdCB3YXMgYXNrZWQgdG8gZG8u
IFRoZSBmYWN0IHRoYXQgdGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgaGF2ZSB0eXBpY2FsbHkgYXNr
ZWQgdXNlcnMgdG8gZG8gaXMsIEkgYmVsaWV2ZSwgb25lIG9mIHRoZSBrZXkgcmVhc29ucyB3aHkg
d2UgYXJlIHNlZWluZyByZXF1aXJlbWVudHMgYXJ0aWN1bGF0ZWQgdGhpcyB3YXkuDQoNCj4+ICBN
eSBpc3N1ZSBpcyB0aGF0IHRoZSByZXF1aXJlbWVudCBzZWVtcyB0byBpZ25vcmUgdGhlIHNpdHVh
dGlvbnMgYW5kIG15IHN1Z2dlc3Rpb24gaXMgdG8gcmVsYXggdGhlIHJlcXVpcmVtZW50Lg0KPiBJ
IHRoaW5rIHRoYXQgdGhlIG9wZXJhdG9yIHJlcXVpcmVtZW50IGlzIHN0YXRpbmcgdGhhdCB0aGUg
bXVsdGlwbGUgYWN0dWFsIGFwcGxpZWQgY29uZmlndXJhdGlvbiBsZWF2ZXMgYWNyb3NzIG11bHRp
cGxlIHN1YnN5c3RlbXMgbmVlZCB0byBiZSBtYXBwZWQgYmFjayB0byBhIHNpbmdsZSBsb2dpY2Fs
IGxlYWYgZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGUgYXBwbGllZCBjb25maWcgbGVhZiB0aGF0IGlz
IGV4cG9zZWQgdG8gdGhlIG9wZXJhdG9ycy4NCj4gDQo+IElmIG5vIHN1Y2ggbWFwcGluZyBpcyBw
b3NzaWJsZSB0aGVuIHRoaXMgd291bGQgaW1wbHkgdGhhdCB0aGVyZSBpcyBubyB3YXkgdGhhdCB0
aGUgb3BlcmF0b3IgY2FuIGRldGVybWluZSB3aGV0aGVyIGEgcGFydGljdWxhciBpdGVtIG9mIGNv
bmZpZ3VyYXRpb24gaXMgYWN0dWFsbHkgaW4gZWZmZWN0IG9uIGEgc3lzdGVtLiAgSXMgdGhpcyBy
ZWFzb25hYmxlIGJlaGF2aW91ciBmb3IgYSBzeXN0ZW0/DQo+IA0KPiBJZiBzdWNoIGEgbWFwcGlu
ZyBpcyBwb3NzaWJsZSwgdGhlbiBJIGNhbiBzZWUgYmVuZWZpdCBpbiBwZXJmb3JtaW5nIHN1Y2gg
YSBtYXBwaW5nIG9uIHRoZSBkZXZpY2UgaXRzZWxmIHJhdGhlciB0aGFuIHJlcXVpcmluZyBlYWNo
IGFuZCBldmVyeSBvcGVyYXRvciB0byBrbm93IGFuZCBwcm9ncmFtIHRoZSBtYXBwaW5nLg0KDQor
MQ0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KPiBJcyB0aGUgbWFpbiBjb25jZXJuIGhlcmUgdGhh
dCB0aGUgY29zdCBvZiBpbXBsZW1lbnRpbmcgdGhpcyBtYXBwaW5nIGluIHRoZSBzeXN0ZW0gbWF5
IGJlIHByb2hpYml0aXZlbHkgZXhwZW5zaXZlPw0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4gDQo+
PiANCj4+ICBJIGRvbuKAmXQgYmVsaWV2ZSAxLkMgYWRkcmVzc2VzIHRoZSBhY3R1YWwgY29uY2Vy
biB3aXRoIHRoZSByZXF1aXJlbWVudC4NCj4+IA0KPj4+IE9uIE9jdCAxNCwgMjAxNSwgYXQgODox
NCBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+IA0KPj4+
IA0KPj4+IEkgYmVsaWV2ZSB0aGF0IHlvdSBhcmUgY29ycmVjdCwgaXQgc2VlbXMgdGhhdCB3ZSd2
ZSBkb3VibGVkLWRvd24gb24gMUMgYW5kIHNvICM1IHNob3VsZCBub3cgYmUgbWFya2VkIGFzIERF
QUQuDQo+Pj4gDQo+Pj4gVGhpcyBhY3Rpb24gd2lsbCBiZSB0YWtlbiBpZiBubyBvYmplY3Rpb24g
aXMgbWFkZSBiZWZvcmUgdG9tb3Jyb3cncyBpbnRlcmltLg0KPj4+IA0KPj4+IFRoYW5rcywNCj4+
PiBLZW50DQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNj
by5jb20+DQo+Pj4gRGF0ZTogVHVlc2RheSwgT2N0b2JlciAxMywgMjAxNSBhdCA5OjI5IEFNDQo+
Pj4gVG86IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiwgIm5ldG1vZEBpZXRmLm9y
ZyIgPG5ldG1vZEBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gb3BzdGF0ZS1y
ZXFzICM1OiBTdXBwb3J0IGZvciBzaXR1YXRpb25zIHdoZW4gc3RydWN0dXJlIG9mIGludGVuZGVk
IGNvbmZpZ3VyYXRpb24gaXMgbm90IHRoZSBzYW1lIGFzIGFwcGxpZWQNCj4+PiANCj4+PiBGcm9t
IHRoZSBpbnRlcmltIG1lZXRpbmcgdHdvIHdlZWtzIGFnbywgaXQgd2FzIGNsYXJpZmllZCB0aGF0
IHRoZSBzY2hlbWEgb2YgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gbm9kZXMgYXJlIGV4cGVj
dGVkIHRvIGJlIHRoZSBzYW1lIGFzIHRoZSBzY2hlbWEgb2YgdGhlIGFwcGxpZWQgY29uZmlndXJh
dGlvbiBub2RlcyBzbyB0aGF0IGNsaWVudHMgY2FuIGVhc2lseSByZWxhdGUgYmV0d2VlbiB0aGUg
dHdvLg0KPj4+IA0KPj4+IEkgdGhpbmsgdGhhdCB0aGUgcmVxdWlyZW1lbnQgdGV4dCBmb3IgMS5D
IGFuZCB0aGUgcHJvcG9zZWQgdXBkYXRlZCB0ZXh0IGZvciAxLkQgbWFrZXMgdGhpcyByZWFzb25h
YmxlIGNsZWFyLg0KPj4+IA0KPj4+IEhlbmNlLCBpcyBpc3N1ZSA1IG5vdyBhdCB0aGUgc3RhdGUg
d2hlcmUgaXMgY2FuIGJlIGNsb3NlZCBhcyBub3QgYmVpbmcgYSByZXF1aXJlbWVudD8gIE9yIGlz
IHRoZXJlIHNvbWV0aGluZyBmdXJ0aGVyIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGZpcnN0
Pw0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiBSb2INCj4+PiANCj4+PiANCj4+PiBPbiAzMC8wOS8y
MDE1IDE2OjQ0LCBLZW50IFdhdHNlbiB3cm90ZToNCj4+Pj4gSXQncyB0aW1lIHRvIHRhY2tsZSBh
bm90aGVyIGlzc3VlLCBqdXN0IGJlZm9yZSB0b21vcnJvdydzIG1lZXRpbmcsIGFuZCB0aGlzIHRp
bWUgSSdtIHBpY2tpbmcgYSBoYXJkIG9uZToNCj4+Pj4gDQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNv
bS9uZXRtb2Qtd2cvb3BzdGF0ZS1yZXFzL2lzc3Vlcy81DQo+Pj4+IA0KPj4+PiBBbHJlYWR5IENh
cmwsIE1haGVzaCwgRWluYXIsIGFuZCBBbmR5IGhhdmUgcG9zdGVkIDE4IGNvbW1lbnRzIG9uIHRo
ZSBHaXRIdWIgaXNzdWUgdHJhY2tlci4gICAgUGxlYXNlIGZpcnN0IHJlYWQgdGhlIGNvbW1lbnRz
IHBvc3RlZCB0aGVyZSBhbmQgdGhlbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBoZXJlIG9uIHRo
ZSBtYWlsaW5nIGxpc3QgKG5vdCBvbiB0aGUgR2l0SHViIGlzc3VlIHRyYWNrZXIpLg0KPj4+PiAN
Cj4+Pj4gTm90ZSB0aGF0IHRoaXMgaXNzdWUgaXMgY2xvc2VseSB0aWVkIHRvIHRoZSBkZWZpbml0
aW9uIG9mICJhcHBsaWVkIGNvbmZpZ3VyYXRpb24iLCB3aGljaCBpcyBleGFjdGx5IHdoYXQgaXNz
dWUgIzQgcmVnYXJkcyAoaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9vcHN0YXRlLXJlcXMv
aXNzdWVzLzQpLCBmb3Igd2hpY2ggTWFoZXNoIGFuZCBFaW5hciBoYXZlIHBvc3RlZCBjb21tZW50
cyBvbiBhbHJlYWR5LiAgIEFzIHRoZXNlIHR3byBpc3N1ZXMgKCM0IGFuZCAjNSkgYXJlIHNvIGhp
Z2hseSByZWxhdGVkLCBJJ20gZ29pbmcgdG8gc2ltdWx0YW5lb3VzbHkgb3BlbiB0aGUgb3RoZXIg
aXNzdWUgZm9yIGRpc2N1c3Npb24gbm93IGFzIHdlbGwuDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+
Pj4+IEtlbnQNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+
PiANCj4+Pj4gbmV0bW9kQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1h
aWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Tue Oct 20 04:44:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF81B3346 for ; Tue, 20 Oct 2015 04:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiLsIywfoa1R for ; Tue, 20 Oct 2015 04:44:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 647051B3342 for ; Tue, 20 Oct 2015 04:44:03 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id C60EC1AE044D; Tue, 20 Oct 2015 13:44:01 +0200 (CEST)
Date: Tue, 20 Oct 2015 13:48:06 +0200 (CEST)
Message-Id: <20151020.134806.403714596465324487.mbj@tail-f.com>
To: einarnn@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5069D46B-27C7-4927-8E8A-0253A39F2F38@cisco.com>
References: <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> <561FAFDE.4020007@cisco.com> <5069D46B-27C7-4927-8E8A-0253A39F2F38@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 11:44:06 -0000

IkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSIgPGVpbmFybm5AY2lzY28uY29tPiB3cm90
ZToNCj4gQ2FybCwNCj4gDQo+IEEgYml0IG9mIGEgbGF0ZSByZXNwb25zZSwgc29ycnksIGJ1dCB3
YXMgb24gdmFjYXRpb24uIFBsZWFzZSBzZWUNCj4gaW5saW5lLg0KPiANCj4gPiBPbiBPY3QgMTUs
IDIwMTUsIGF0IDI6NTMgUE0sIFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQNCj4g
PiBMSU1JVEVEIGF0IENpc2NvKSA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiA+IA0KPiA+
IEhpIENhcmwsDQo+ID4gDQo+ID4gT24gMTUvMTAvMjAxNSAxNDowNSwgQ2FybCBNb2JlcmcgKGNh
bW9iZXJnKSB3cm90ZToNCj4gPj4gIE1heWJlIHdl4oCZcmUgY29taW5nIGRvd24gdG8gYSBkZWZp
bml0aW9uIG9mIOKAnHJlcXVpcmVtZW504oCdIGhlcmUuIEJ1dCB0aGUNCj4gPj4gIGlzc3VlIEkg
cmFpc2VkIGNhbiBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6DQo+ID4+IA0KPiA+PiDigJzigJ3i
gJ0NCj4gPj4gVGhlIGFzc3VtcHRpb24gb2YgYSAxOjEgbWFwcGluZyBpZ25vcmVzIHNpdHVhdGlv
bnMgd2hlcmUgYSBjaGFuZ2UgdG8NCj4gPj4gYW4gaW50ZW5kZWQgY29uZmlndXJhdGlvbiBsZWFm
IHZhbHVlIG1heSByZXN1bHQgaW4gc2V2ZXJhbCBpbnN0YW5jZXMNCj4gPj4gb2YgYXBwbGllZCBj
b25maWd1cmF0aW9uIGxlYWYgdmFsdWVzIChvcGVyYXRpb25hbCBzdGF0ZSkgdG8gYmUgdXBkYXRl
ZA0KPiA+PiBpbiB0aGUgYmFja2VuZCBmcmFtZXdvcmsgYWNyb3NzIHNldmVyYWwgc3Vic3lzdGVt
cy4NCj4gPj4g4oCc4oCdIg0KPiANCj4gVGhlIG9wZXJhdGlvbmFsIHN0YXRlIHlvdSBhcmUgdGFr
aW5nIGFib3V0IGhlcmUgaXMgbm90LCBwZXIgbXkNCj4gdW5kZXJzdGFuZGluZyBvZiAiYXBwbGll
ZCBjb25maWd1cmF0aW9uIiB3aGF0IGlzIG1lYW50IGJ5IGFwcGxpZWQNCj4gY29uZmlndXJhdGlv
bi4gVGhlICJzZXZlcmFsIGluc3RhbmNlcyIgYXJlIGluc3RlYWQgaW1wbGVtZW50YXRpb24NCj4g
ZGV0YWlsIHRoYXQgYXJlIHBlcmhhcHMgY2hhbmdlZCBhcyBhIHJlc3VsdCBvZiBjaGFuZ2luZyBh
IHNpbmdsZQ0KPiBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGxlYWYuDQo+IA0KPiBBbmQgYXQgdGhp
cyBwb2ludCBJIGFncmVlIHdpdGggUm9iIGFuZCB3aWxsIHNheSB0aGF0LCBmcm9tIGFuIGVuZA0K
PiB1c2VyJ3MgcGVyc3BlY3RpdmUsIGl0IGlzIG5vdCByZWFzb25hYmxlIHRvIGV4cGVjdCB0aGVt
IHRvIHBhdGNoDQo+IHRvZ2V0aGVyIHRoZSAxOk4gcmVsYXRpb25zaGlwIGJldHdlZW4gaW50ZW5k
ZWQgY29uZmlnIGFuZCB3aGF0IEkgd2lsbA0KPiBjYWxsICJvcGVyYXRpb25hbCBzdGF0ZSIgKE5P
VCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24pIHRvIGRldGVybWluZSBpZg0KPiB0aGUgZGV2aWNlIGlz
IGFjdHVhbGx5IGRvaW5nIHdoYXQgaXQgd2FzIGFza2VkIHRvIGRvLiBUaGUgZmFjdCB0aGF0DQo+
IHRoaXMgaXMgZXhhY3RseSB3aGF0IHdlIGhhdmUgdHlwaWNhbGx5IGFza2VkIHVzZXJzIHRvIGRv
IGlzLCBJDQo+IGJlbGlldmUsIG9uZSBvZiB0aGUga2V5IHJlYXNvbnMgd2h5IHdlIGFyZSBzZWVp
bmcgcmVxdWlyZW1lbnRzDQo+IGFydGljdWxhdGVkIHRoaXMgd2F5Lg0KDQpPay4gIERvIHlvdSBt
ZWFuIHRoYXQgaW5zdGVhZCB5b3Ugd2FudCB0aGUgc2VydmVyIHRvIGRvIHRoaXMgam9iPw0KSS5l
LiwgaWYgaXQgaGFwcGVucyB0byBkaXN0cmlidXRlIGEgc2luZ2xlIGxlYWYgaW4gTiBpbnRlcm5h
bA0KY29tcG9uZW50cywgaXQgc2hvdWxkIGFnZ3JlZ2F0ZSB0aGUgc3RhdHVzIG9mIHRoZSBsZWFm
J3MgdmFsdWUgaW4NCnRoZXNlIE4gaW50ZXJuYWwgY29tcG9uZW50cyBpbnRvIG9uZSBzaW5nbGUg
dmFsdWUsIGFuZCByZXBvcnQgdGhhdA0KdmFsdWU/DQoNCg0KL21hcnRpbg0KDQoNCg0KDQo+IA0K
PiA+PiAgTXkgaXNzdWUgaXMgdGhhdCB0aGUgcmVxdWlyZW1lbnQgc2VlbXMgdG8gaWdub3JlIHRo
ZSBzaXR1YXRpb25zIGFuZCBteQ0KPiA+PiAgc3VnZ2VzdGlvbiBpcyB0byByZWxheCB0aGUgcmVx
dWlyZW1lbnQuDQo+ID4gSSB0aGluayB0aGF0IHRoZSBvcGVyYXRvciByZXF1aXJlbWVudCBpcyBz
dGF0aW5nIHRoYXQgdGhlIG11bHRpcGxlDQo+ID4gYWN0dWFsIGFwcGxpZWQgY29uZmlndXJhdGlv
biBsZWF2ZXMgYWNyb3NzIG11bHRpcGxlIHN1YnN5c3RlbXMgbmVlZCB0bw0KPiA+IGJlIG1hcHBl
ZCBiYWNrIHRvIGEgc2luZ2xlIGxvZ2ljYWwgbGVhZiBmb3IgdGhlIHB1cnBvc2VzIG9mIHRoZQ0K
PiA+IGFwcGxpZWQgY29uZmlnIGxlYWYgdGhhdCBpcyBleHBvc2VkIHRvIHRoZSBvcGVyYXRvcnMu
DQo+ID4gDQo+ID4gSWYgbm8gc3VjaCBtYXBwaW5nIGlzIHBvc3NpYmxlIHRoZW4gdGhpcyB3b3Vs
ZCBpbXBseSB0aGF0IHRoZXJlIGlzIG5vDQo+ID4gd2F5IHRoYXQgdGhlIG9wZXJhdG9yIGNhbiBk
ZXRlcm1pbmUgd2hldGhlciBhIHBhcnRpY3VsYXIgaXRlbSBvZg0KPiA+IGNvbmZpZ3VyYXRpb24g
aXMgYWN0dWFsbHkgaW4gZWZmZWN0IG9uIGEgc3lzdGVtLiAgSXMgdGhpcyByZWFzb25hYmxlDQo+
ID4gYmVoYXZpb3VyIGZvciBhIHN5c3RlbT8NCj4gPiANCj4gPiBJZiBzdWNoIGEgbWFwcGluZyBp
cyBwb3NzaWJsZSwgdGhlbiBJIGNhbiBzZWUgYmVuZWZpdCBpbiBwZXJmb3JtaW5nDQo+ID4gc3Vj
aCBhIG1hcHBpbmcgb24gdGhlIGRldmljZSBpdHNlbGYgcmF0aGVyIHRoYW4gcmVxdWlyaW5nIGVh
Y2ggYW5kDQo+ID4gZXZlcnkgb3BlcmF0b3IgdG8ga25vdyBhbmQgcHJvZ3JhbSB0aGUgbWFwcGlu
Zy4NCj4gDQo+ICsxDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBFaW5hcg0KPiANCj4gDQo+ID4gSXMg
dGhlIG1haW4gY29uY2VybiBoZXJlIHRoYXQgdGhlIGNvc3Qgb2YgaW1wbGVtZW50aW5nIHRoaXMg
bWFwcGluZyBpbg0KPiA+IHRoZSBzeXN0ZW0gbWF5IGJlIHByb2hpYml0aXZlbHkgZXhwZW5zaXZl
Pw0KPiA+IA0KPiA+IFRoYW5rcywNCj4gPiBSb2INCj4gPiANCj4gPj4gDQo+ID4+ICBJIGRvbuKA
mXQgYmVsaWV2ZSAxLkMgYWRkcmVzc2VzIHRoZSBhY3R1YWwgY29uY2VybiB3aXRoIHRoZSByZXF1
aXJlbWVudC4NCj4gPj4gDQo+ID4+PiBPbiBPY3QgMTQsIDIwMTUsIGF0IDg6MTQgUE0sIEtlbnQg
V2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gDQo+ID4+
PiBJIGJlbGlldmUgdGhhdCB5b3UgYXJlIGNvcnJlY3QsIGl0IHNlZW1zIHRoYXQgd2UndmUgZG91
YmxlZC1kb3duIG9uIDFDDQo+ID4+PiBhbmQgc28gIzUgc2hvdWxkIG5vdyBiZSBtYXJrZWQgYXMg
REVBRC4NCj4gPj4+IA0KPiA+Pj4gVGhpcyBhY3Rpb24gd2lsbCBiZSB0YWtlbiBpZiBubyBvYmpl
Y3Rpb24gaXMgbWFkZSBiZWZvcmUgdG9tb3Jyb3cncw0KPiA+Pj4gaW50ZXJpbS4NCj4gPj4+IA0K
PiA+Pj4gVGhhbmtzLA0KPiA+Pj4gS2VudA0KPiA+Pj4gDQo+ID4+PiANCj4gPj4+IEZyb206IFJv
YmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPg0KPiA+Pj4gRGF0ZTogVHVlc2RheSwgT2N0
b2JlciAxMywgMjAxNSBhdCA5OjI5IEFNDQo+ID4+PiBUbzogS2VudCBXYXRzZW4gPGt3YXRzZW5A
anVuaXBlci5uZXQ+LCAibmV0bW9kQGlldGYub3JnIg0KPiA+Pj4gPG5ldG1vZEBpZXRmLm9yZz4N
Cj4gPj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBvcHN0YXRlLXJlcXMgIzU6IFN1cHBvcnQgZm9y
IHNpdHVhdGlvbnMgd2hlbg0KPiA+Pj4gc3RydWN0dXJlIG9mIGludGVuZGVkIGNvbmZpZ3VyYXRp
b24gaXMgbm90IHRoZSBzYW1lIGFzIGFwcGxpZWQNCj4gPj4+IA0KPiA+Pj4gRnJvbSB0aGUgaW50
ZXJpbSBtZWV0aW5nIHR3byB3ZWVrcyBhZ28sIGl0IHdhcyBjbGFyaWZpZWQgdGhhdCB0aGUNCj4g
Pj4+IHNjaGVtYSBvZiB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBub2RlcyBhcmUgZXhwZWN0
ZWQgdG8gYmUgdGhlIHNhbWUNCj4gPj4+IGFzIHRoZSBzY2hlbWEgb2YgdGhlIGFwcGxpZWQgY29u
ZmlndXJhdGlvbiBub2RlcyBzbyB0aGF0IGNsaWVudHMgY2FuDQo+ID4+PiBlYXNpbHkgcmVsYXRl
IGJldHdlZW4gdGhlIHR3by4NCj4gPj4+IA0KPiA+Pj4gSSB0aGluayB0aGF0IHRoZSByZXF1aXJl
bWVudCB0ZXh0IGZvciAxLkMgYW5kIHRoZSBwcm9wb3NlZCB1cGRhdGVkDQo+ID4+PiB0ZXh0IGZv
ciAxLkQgbWFrZXMgdGhpcyByZWFzb25hYmxlIGNsZWFyLg0KPiA+Pj4gDQo+ID4+PiBIZW5jZSwg
aXMgaXNzdWUgNSBub3cgYXQgdGhlIHN0YXRlIHdoZXJlIGlzIGNhbiBiZSBjbG9zZWQgYXMgbm90
IGJlaW5nDQo+ID4+PiBhIHJlcXVpcmVtZW50PyAgT3IgaXMgdGhlcmUgc29tZXRoaW5nIGZ1cnRo
ZXIgdGhhdCBuZWVkcyB0byBiZQ0KPiA+Pj4gZGlzY3Vzc2VkIGZpcnN0Pw0KPiA+Pj4gDQo+ID4+
PiBUaGFua3MsDQo+ID4+PiBSb2INCj4gPj4+IA0KPiA+Pj4gDQo+ID4+PiBPbiAzMC8wOS8yMDE1
IDE2OjQ0LCBLZW50IFdhdHNlbiB3cm90ZToNCj4gPj4+PiBJdCdzIHRpbWUgdG8gdGFja2xlIGFu
b3RoZXIgaXNzdWUsIGp1c3QgYmVmb3JlIHRvbW9ycm93J3MgbWVldGluZywgYW5kDQo+ID4+Pj4g
dGhpcyB0aW1lIEknbSBwaWNraW5nIGEgaGFyZCBvbmU6DQo+ID4+Pj4gDQo+ID4+Pj4gaHR0cHM6
Ly9naXRodWIuY29tL25ldG1vZC13Zy9vcHN0YXRlLXJlcXMvaXNzdWVzLzUNCj4gPj4+PiANCj4g
Pj4+PiBBbHJlYWR5IENhcmwsIE1haGVzaCwgRWluYXIsIGFuZCBBbmR5IGhhdmUgcG9zdGVkIDE4
IGNvbW1lbnRzIG9uIHRoZQ0KPiA+Pj4+IEdpdEh1YiBpc3N1ZSB0cmFja2VyLiAgUGxlYXNlIGZp
cnN0IHJlYWQgdGhlIGNvbW1lbnRzIHBvc3RlZCB0aGVyZSBhbmQNCj4gPj4+PiB0aGVuIGNvbnRp
bnVlIHRoZSBkaXNjdXNzaW9uIGhlcmUgb24gdGhlIG1haWxpbmcgbGlzdCAobm90IG9uIHRoZQ0K
PiA+Pj4+IEdpdEh1YiBpc3N1ZSB0cmFja2VyKS4NCj4gPj4+PiANCj4gPj4+PiBOb3RlIHRoYXQg
dGhpcyBpc3N1ZSBpcyBjbG9zZWx5IHRpZWQgdG8gdGhlIGRlZmluaXRpb24gb2YgImFwcGxpZWQN
Cj4gPj4+PiBjb25maWd1cmF0aW9uIiwgd2hpY2ggaXMgZXhhY3RseSB3aGF0IGlzc3VlICM0IHJl
Z2FyZHMNCj4gPj4+PiAoaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9vcHN0YXRlLXJlcXMv
aXNzdWVzLzQpLCBmb3Igd2hpY2ggTWFoZXNoDQo+ID4+Pj4gYW5kIEVpbmFyIGhhdmUgcG9zdGVk
IGNvbW1lbnRzIG9uIGFscmVhZHkuICBBcyB0aGVzZSB0d28gaXNzdWVzICgjNA0KPiA+Pj4+IGFu
ZCAjNSkgYXJlIHNvIGhpZ2hseSByZWxhdGVkLCBJJ20gZ29pbmcgdG8gc2ltdWx0YW5lb3VzbHkg
b3BlbiB0aGUNCj4gPj4+PiBvdGhlciBpc3N1ZSBmb3IgZGlzY3Vzc2lvbiBub3cgYXMgd2VsbC4N
Cj4gPj4+PiANCj4gPj4+PiBUaGFua3MsDQo+ID4+Pj4gS2VudA0KPiA+Pj4+IA0KPiA+Pj4+IA0K
PiA+Pj4+IA0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+Pj4+IA0KPiA+Pj4+IG5ldG1v
ZEBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+
ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+
Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4+PiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+IA0KPiA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1h
aWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Tue Oct 20 05:17:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D78F1B33AA for ; Tue, 20 Oct 2015 05:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbmtLtJIebNM for ; Tue, 20 Oct 2015 05:17:33 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F571B33B7 for ; Tue, 20 Oct 2015 05:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9858; q=dns/txt; s=iport; t=1445343452; x=1446553052; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=evLRKDO0jA/iemMxr8iTs7wkw/5yt0tzTEWg/X/Zgzs=; b=cRI3t8TdnPXhCwaOHnKAPer7q/5LhwTY3cfU1qGuE+kQXXClJdj8h/Cu ZIrlWwIOhjKkoVtuubCuV9HL8p5JgjwRNa4XkiKk3BLFFmlFv7i/v+XH/ RdkD85DW9YgkRxKllevAoHG9wefw9BiW8VBpK9hFZyb8Ewt8Qxb4ZlOzX M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D6AQDjLyZW/4oNJK1egzZUbwa+GQENgVoXCoUzSgIcgSM4FAEBAQEBAQGBCoQtAQEBAwEBAQEgEToEBwULAgEGAg4DAwECAQICHwcCAgIlCxUICAIEDgUJiB8IDZMynTeTFgEBAQEBAQEBAQEBAQEBAQEBAQEBARiBIoVWgg+CboJCgXIOMBsHgmkxgRQFliQBhRiIBoFYhD+DJJJlAR8BAUKCRIE/coQeQ4EGAQEB
X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208";a="199678974"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 20 Oct 2015 12:17:31 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9KCHR6j017986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 12:17:31 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 07:17:10 -0500
Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 07:17:10 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Thread-Index: AQHRBbsqf5R98Ya67USKuIH5IQB1mp5roJcAgAE8JgCAAA1iAIAHs1iAgAAFQgCAAAgngA==
Date: Tue, 20 Oct 2015 12:17:10 +0000
Message-ID: <9E55C138-8BA9-4533-96ED-76B66FBE1C82@cisco.com>
References: <098489D2-B136-450E-B5C2-F7508AC0EF66@cisco.com> <561FAFDE.4020007@cisco.com> <5069D46B-27C7-4927-8E8A-0253A39F2F38@cisco.com> <20151020.134806.403714596465324487.mbj@tail-f.com>
In-Reply-To: <20151020.134806.403714596465324487.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.106.13]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 12:17:39 -0000

DQo+IE9uIE9jdCAyMCwgMjAxNSwgYXQgMTI6NDggUE0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0
YWlsLWYuY29tPiB3cm90ZToNCj4gDQo+ICJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubiki
IDxlaW5hcm5uQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBDYXJsLA0KPj4gDQo+PiBBIGJpdCBvZiBh
IGxhdGUgcmVzcG9uc2UsIHNvcnJ5LCBidXQgd2FzIG9uIHZhY2F0aW9uLiBQbGVhc2Ugc2VlDQo+
PiBpbmxpbmUuDQo+PiANCj4+PiBPbiBPY3QgMTUsIDIwMTUsIGF0IDI6NTMgUE0sIFJvYmVydCBX
aWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQNCj4+PiBMSU1JVEVEIGF0IENpc2NvKSA8cndpbHRv
bkBjaXNjby5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIENhcmwsDQo+Pj4gDQo+Pj4gT24gMTUv
MTAvMjAxNSAxNDowNSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSB3cm90ZToNCj4+Pj4gTWF5YmUg
d2XigJlyZSBjb21pbmcgZG93biB0byBhIGRlZmluaXRpb24gb2Yg4oCccmVxdWlyZW1lbnTigJ0g
aGVyZS4gQnV0IHRoZQ0KPj4+PiBpc3N1ZSBJIHJhaXNlZCBjYW4gYmUgc3VtbWFyaXplZCBhcyBm
b2xsb3dzOg0KPj4+PiANCj4+Pj4g4oCc4oCd4oCdDQo+Pj4+IFRoZSBhc3N1bXB0aW9uIG9mIGEg
MToxIG1hcHBpbmcgaWdub3JlcyBzaXR1YXRpb25zIHdoZXJlIGEgY2hhbmdlIHRvDQo+Pj4+IGFu
IGludGVuZGVkIGNvbmZpZ3VyYXRpb24gbGVhZiB2YWx1ZSBtYXkgcmVzdWx0IGluIHNldmVyYWwg
aW5zdGFuY2VzDQo+Pj4+IG9mIGFwcGxpZWQgY29uZmlndXJhdGlvbiBsZWFmIHZhbHVlcyAob3Bl
cmF0aW9uYWwgc3RhdGUpIHRvIGJlIHVwZGF0ZWQNCj4+Pj4gaW4gdGhlIGJhY2tlbmQgZnJhbWV3
b3JrIGFjcm9zcyBzZXZlcmFsIHN1YnN5c3RlbXMuDQo+Pj4+IOKAnOKAnSINCj4+IA0KPj4gVGhl
IG9wZXJhdGlvbmFsIHN0YXRlIHlvdSBhcmUgdGFraW5nIGFib3V0IGhlcmUgaXMgbm90LCBwZXIg
bXkNCj4+IHVuZGVyc3RhbmRpbmcgb2YgImFwcGxpZWQgY29uZmlndXJhdGlvbiIgd2hhdCBpcyBt
ZWFudCBieSBhcHBsaWVkDQo+PiBjb25maWd1cmF0aW9uLiBUaGUgInNldmVyYWwgaW5zdGFuY2Vz
IiBhcmUgaW5zdGVhZCBpbXBsZW1lbnRhdGlvbg0KPj4gZGV0YWlsIHRoYXQgYXJlIHBlcmhhcHMg
Y2hhbmdlZCBhcyBhIHJlc3VsdCBvZiBjaGFuZ2luZyBhIHNpbmdsZQ0KPj4gaW50ZW5kZWQgY29u
ZmlndXJhdGlvbiBsZWFmLg0KPj4gDQo+PiBBbmQgYXQgdGhpcyBwb2ludCBJIGFncmVlIHdpdGgg
Um9iIGFuZCB3aWxsIHNheSB0aGF0LCBmcm9tIGFuIGVuZA0KPj4gdXNlcidzIHBlcnNwZWN0aXZl
LCBpdCBpcyBub3QgcmVhc29uYWJsZSB0byBleHBlY3QgdGhlbSB0byBwYXRjaA0KPj4gdG9nZXRo
ZXIgdGhlIDE6TiByZWxhdGlvbnNoaXAgYmV0d2VlbiBpbnRlbmRlZCBjb25maWcgYW5kIHdoYXQg
SSB3aWxsDQo+PiBjYWxsICJvcGVyYXRpb25hbCBzdGF0ZSIgKE5PVCBhcHBsaWVkIGNvbmZpZ3Vy
YXRpb24pIHRvIGRldGVybWluZSBpZg0KPj4gdGhlIGRldmljZSBpcyBhY3R1YWxseSBkb2luZyB3
aGF0IGl0IHdhcyBhc2tlZCB0byBkby4gVGhlIGZhY3QgdGhhdA0KPj4gdGhpcyBpcyBleGFjdGx5
IHdoYXQgd2UgaGF2ZSB0eXBpY2FsbHkgYXNrZWQgdXNlcnMgdG8gZG8gaXMsIEkNCj4+IGJlbGll
dmUsIG9uZSBvZiB0aGUga2V5IHJlYXNvbnMgd2h5IHdlIGFyZSBzZWVpbmcgcmVxdWlyZW1lbnRz
DQo+PiBhcnRpY3VsYXRlZCB0aGlzIHdheS4NCj4gDQo+IE9rLiAgRG8geW91IG1lYW4gdGhhdCBp
bnN0ZWFkIHlvdSB3YW50IHRoZSBzZXJ2ZXIgdG8gZG8gdGhpcyBqb2I/DQo+IEkuZS4sIGlmIGl0
IGhhcHBlbnMgdG8gZGlzdHJpYnV0ZSBhIHNpbmdsZSBsZWFmIGluIE4gaW50ZXJuYWwNCj4gY29t
cG9uZW50cywgaXQgc2hvdWxkIGFnZ3JlZ2F0ZSB0aGUgc3RhdHVzIG9mIHRoZSBsZWFmJ3MgdmFs
dWUgaW4NCj4gdGhlc2UgTiBpbnRlcm5hbCBjb21wb25lbnRzIGludG8gb25lIHNpbmdsZSB2YWx1
ZSwgYW5kIHJlcG9ydCB0aGF0DQo+IHZhbHVlPw0KDQpUbyBwZXJoYXBzIGJlIGEgbGl0dGxlIG1v
cmUgcHJlY2lzZSwgSSBtZWFuIHRoYXQgaXQgaXMgdGhlIHNlcnZlcidzIGpvYiB0byBtYWtlIHRo
ZSBpbmZvcm1hdGlvbiBhYm91dCB3aGV0aGVyIG9yIG5vdCBpbnRlbmRlZCBjb25maWcgaGFzIGJl
ZW4gaW5zdGFudGlhdGVkIGNvcnJlY3RseSBpbiBhIHdheSB0aGF0IGlzIHJlYWxseSBlYXN5IHRv
IGNvcnJlbGF0ZSB3aXRoIHRoZSBpbnRlbmRlZCBjb25maWcgYXNzZXJ0ZWQgYnkgdGhlIGNsaWVu
dC4gSW4gdGVybXMgb2YgYWdncmVnYXRpbmcgdGhlIHN0YXR1cyBvZiB0aGUgb3BlcmF0aW9uYWwg
bGVhdmVzIGludG8gYSBpbmdsZSB2YWx1ZSB0aGF0IGNvdWxkLCBmb3IgZXhhbXBsZSwgYmUgZGlm
ZidkIHdpdGggdGhlIGludGVuZGVkIGNvbmZpZywgdGhhdCB3b3VsZCBtZWV0IHRoZSBjcml0ZXJp
YSBvZiBiZWluZyBlYXN5IHRvIGNvcnJlbGF0ZSB3aXRoIHRoZSBpbnRlbmRlZCBjb25maWcuDQoN
CldoYXQgd2UgbWF5IGZpbmQgaXMgdGhhdCB0aGlua2luZyBhYm91dCByZXF1aXJlbWVudHMgbGlr
ZSB0aGlzIG1heSBtYWtlIHVzIG1vcmUgbWluZGZ1bCBvZiBob3cgd2UgZGVmaW5lIHRoZSByZWxh
dGlvbnNoaXAgYmV0d2VlbiBpbnRlbmRlZCBjb25maWcgYW5kIGhvdyBvdXIgaW50ZXJuYWwgY29t
cG9uZW50cyB3b3JrIHRvZ2V0aGVyIHRvIGFjaGlldmUgaXQgYW5kIGhvdyB3ZSBleHBvc2UgdGhl
IHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiBjb25maWcgb3BlcmF0aW9ucyBpbiBhIHdheSB0aGF0IGlz
IGVhc2llciBmb3IgdXNlcnMgdG8gbWFrZSBzZW5zZSBvZi4NCg0KQWRkaXRpb25hbGx5LCBJJ20g
bm90IHNheWluZyB0aGF0IHRoZXJlIGlzbid0IG9wZXJhdGlvbmFsIHN0YXRlIHRoYXQgZWFjaCBv
ZiB0aGUgTiBpbnRlcm5hbCBjb21wb25lbnRzIGhhdmUuIFRoYXQgc3RpbGwgZXhpc3RzLCBhbmQg
d2lsbCBjb250aW51ZSB0byBleGlzdCBhcyBwYXJ0IG9mIG9uZ29pbmcgb3BlcmF0aW9uYWwgbWFu
YWdlbWVudC4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCj4gL21hcnRpbg0KPiANCj4gDQo+IA0K
PiANCj4+IA0KPj4+PiBNeSBpc3N1ZSBpcyB0aGF0IHRoZSByZXF1aXJlbWVudCBzZWVtcyB0byBp
Z25vcmUgdGhlIHNpdHVhdGlvbnMgYW5kIG15DQo+Pj4+IHN1Z2dlc3Rpb24gaXMgdG8gcmVsYXgg
dGhlIHJlcXVpcmVtZW50Lg0KPj4+IEkgdGhpbmsgdGhhdCB0aGUgb3BlcmF0b3IgcmVxdWlyZW1l
bnQgaXMgc3RhdGluZyB0aGF0IHRoZSBtdWx0aXBsZQ0KPj4+IGFjdHVhbCBhcHBsaWVkIGNvbmZp
Z3VyYXRpb24gbGVhdmVzIGFjcm9zcyBtdWx0aXBsZSBzdWJzeXN0ZW1zIG5lZWQgdG8NCj4+PiBi
ZSBtYXBwZWQgYmFjayB0byBhIHNpbmdsZSBsb2dpY2FsIGxlYWYgZm9yIHRoZSBwdXJwb3NlcyBv
ZiB0aGUNCj4+PiBhcHBsaWVkIGNvbmZpZyBsZWFmIHRoYXQgaXMgZXhwb3NlZCB0byB0aGUgb3Bl
cmF0b3JzLg0KPj4+IA0KPj4+IElmIG5vIHN1Y2ggbWFwcGluZyBpcyBwb3NzaWJsZSB0aGVuIHRo
aXMgd291bGQgaW1wbHkgdGhhdCB0aGVyZSBpcyBubw0KPj4+IHdheSB0aGF0IHRoZSBvcGVyYXRv
ciBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIGl0ZW0gb2YNCj4+PiBjb25maWd1
cmF0aW9uIGlzIGFjdHVhbGx5IGluIGVmZmVjdCBvbiBhIHN5c3RlbS4gIElzIHRoaXMgcmVhc29u
YWJsZQ0KPj4+IGJlaGF2aW91ciBmb3IgYSBzeXN0ZW0/DQo+Pj4gDQo+Pj4gSWYgc3VjaCBhIG1h
cHBpbmcgaXMgcG9zc2libGUsIHRoZW4gSSBjYW4gc2VlIGJlbmVmaXQgaW4gcGVyZm9ybWluZw0K
Pj4+IHN1Y2ggYSBtYXBwaW5nIG9uIHRoZSBkZXZpY2UgaXRzZWxmIHJhdGhlciB0aGFuIHJlcXVp
cmluZyBlYWNoIGFuZA0KPj4+IGV2ZXJ5IG9wZXJhdG9yIHRvIGtub3cgYW5kIHByb2dyYW0gdGhl
IG1hcHBpbmcuDQo+PiANCj4+ICsxDQo+PiANCj4+IENoZWVycywNCj4+IA0KPj4gRWluYXINCj4+
IA0KPj4gDQo+Pj4gSXMgdGhlIG1haW4gY29uY2VybiBoZXJlIHRoYXQgdGhlIGNvc3Qgb2YgaW1w
bGVtZW50aW5nIHRoaXMgbWFwcGluZyBpbg0KPj4+IHRoZSBzeXN0ZW0gbWF5IGJlIHByb2hpYml0
aXZlbHkgZXhwZW5zaXZlPw0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiBSb2INCj4+PiANCj4+Pj4g
DQo+Pj4+IEkgZG9u4oCZdCBiZWxpZXZlIDEuQyBhZGRyZXNzZXMgdGhlIGFjdHVhbCBjb25jZXJu
IHdpdGggdGhlIHJlcXVpcmVtZW50Lg0KPj4+PiANCj4+Pj4+IE9uIE9jdCAxNCwgMjAxNSwgYXQg
ODoxNCBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+Pj4g
DQo+Pj4+PiANCj4+Pj4+IEkgYmVsaWV2ZSB0aGF0IHlvdSBhcmUgY29ycmVjdCwgaXQgc2VlbXMg
dGhhdCB3ZSd2ZSBkb3VibGVkLWRvd24gb24gMUMNCj4+Pj4+IGFuZCBzbyAjNSBzaG91bGQgbm93
IGJlIG1hcmtlZCBhcyBERUFELg0KPj4+Pj4gDQo+Pj4+PiBUaGlzIGFjdGlvbiB3aWxsIGJlIHRh
a2VuIGlmIG5vIG9iamVjdGlvbiBpcyBtYWRlIGJlZm9yZSB0b21vcnJvdydzDQo+Pj4+PiBpbnRl
cmltLg0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBLZW50DQo+Pj4+PiANCj4+Pj4+IA0K
Pj4+Pj4gRnJvbTogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+DQo+Pj4+PiBEYXRl
OiBUdWVzZGF5LCBPY3RvYmVyIDEzLCAyMDE1IGF0IDk6MjkgQU0NCj4+Pj4+IFRvOiBLZW50IFdh
dHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sICJuZXRtb2RAaWV0Zi5vcmciDQo+Pj4+PiA8bmV0
bW9kQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIG9wc3RhdGUtcmVxcyAj
NTogU3VwcG9ydCBmb3Igc2l0dWF0aW9ucyB3aGVuDQo+Pj4+PiBzdHJ1Y3R1cmUgb2YgaW50ZW5k
ZWQgY29uZmlndXJhdGlvbiBpcyBub3QgdGhlIHNhbWUgYXMgYXBwbGllZA0KPj4+Pj4gDQo+Pj4+
PiBGcm9tIHRoZSBpbnRlcmltIG1lZXRpbmcgdHdvIHdlZWtzIGFnbywgaXQgd2FzIGNsYXJpZmll
ZCB0aGF0IHRoZQ0KPj4+Pj4gc2NoZW1hIG9mIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIG5v
ZGVzIGFyZSBleHBlY3RlZCB0byBiZSB0aGUgc2FtZQ0KPj4+Pj4gYXMgdGhlIHNjaGVtYSBvZiB0
aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIG5vZGVzIHNvIHRoYXQgY2xpZW50cyBjYW4NCj4+Pj4+
IGVhc2lseSByZWxhdGUgYmV0d2VlbiB0aGUgdHdvLg0KPj4+Pj4gDQo+Pj4+PiBJIHRoaW5rIHRo
YXQgdGhlIHJlcXVpcmVtZW50IHRleHQgZm9yIDEuQyBhbmQgdGhlIHByb3Bvc2VkIHVwZGF0ZWQN
Cj4+Pj4+IHRleHQgZm9yIDEuRCBtYWtlcyB0aGlzIHJlYXNvbmFibGUgY2xlYXIuDQo+Pj4+PiAN
Cj4+Pj4+IEhlbmNlLCBpcyBpc3N1ZSA1IG5vdyBhdCB0aGUgc3RhdGUgd2hlcmUgaXMgY2FuIGJl
IGNsb3NlZCBhcyBub3QgYmVpbmcNCj4+Pj4+IGEgcmVxdWlyZW1lbnQ/ICBPciBpcyB0aGVyZSBz
b21ldGhpbmcgZnVydGhlciB0aGF0IG5lZWRzIHRvIGJlDQo+Pj4+PiBkaXNjdXNzZWQgZmlyc3Q/
DQo+Pj4+PiANCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IFJvYg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+
IE9uIDMwLzA5LzIwMTUgMTY6NDQsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPj4+Pj4+IEl0J3MgdGlt
ZSB0byB0YWNrbGUgYW5vdGhlciBpc3N1ZSwganVzdCBiZWZvcmUgdG9tb3Jyb3cncyBtZWV0aW5n
LCBhbmQNCj4+Pj4+PiB0aGlzIHRpbWUgSSdtIHBpY2tpbmcgYSBoYXJkIG9uZToNCj4+Pj4+PiAN
Cj4+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL29wc3RhdGUtcmVxcy9pc3N1ZXMv
NQ0KPj4+Pj4+IA0KPj4+Pj4+IEFscmVhZHkgQ2FybCwgTWFoZXNoLCBFaW5hciwgYW5kIEFuZHkg
aGF2ZSBwb3N0ZWQgMTggY29tbWVudHMgb24gdGhlDQo+Pj4+Pj4gR2l0SHViIGlzc3VlIHRyYWNr
ZXIuICBQbGVhc2UgZmlyc3QgcmVhZCB0aGUgY29tbWVudHMgcG9zdGVkIHRoZXJlIGFuZA0KPj4+
Pj4+IHRoZW4gY29udGludWUgdGhlIGRpc2N1c3Npb24gaGVyZSBvbiB0aGUgbWFpbGluZyBsaXN0
IChub3Qgb24gdGhlDQo+Pj4+Pj4gR2l0SHViIGlzc3VlIHRyYWNrZXIpLg0KPj4+Pj4+IA0KPj4+
Pj4+IE5vdGUgdGhhdCB0aGlzIGlzc3VlIGlzIGNsb3NlbHkgdGllZCB0byB0aGUgZGVmaW5pdGlv
biBvZiAiYXBwbGllZA0KPj4+Pj4+IGNvbmZpZ3VyYXRpb24iLCB3aGljaCBpcyBleGFjdGx5IHdo
YXQgaXNzdWUgIzQgcmVnYXJkcw0KPj4+Pj4+IChodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdn
L29wc3RhdGUtcmVxcy9pc3N1ZXMvNCksIGZvciB3aGljaCBNYWhlc2gNCj4+Pj4+PiBhbmQgRWlu
YXIgaGF2ZSBwb3N0ZWQgY29tbWVudHMgb24gYWxyZWFkeS4gIEFzIHRoZXNlIHR3byBpc3N1ZXMg
KCM0DQo+Pj4+Pj4gYW5kICM1KSBhcmUgc28gaGlnaGx5IHJlbGF0ZWQsIEknbSBnb2luZyB0byBz
aW11bHRhbmVvdXNseSBvcGVuIHRoZQ0KPj4+Pj4+IG90aGVyIGlzc3VlIGZvciBkaXNjdXNzaW9u
IG5vdyBhcyB3ZWxsLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBLZW50DQo+Pj4+
Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+Pj4g
DQo+Pj4+Pj4gbmV0bW9kQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+PiBuZXRtb2RAaWV0Zi5v
cmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+
Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IA0KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5n
IGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Tue Oct 20 06:49:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25E91A8ABE for ; Tue, 20 Oct 2015 06:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrnxfMle-OtR for ; Tue, 20 Oct 2015 06:49:44 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689331A8AC0 for ; Tue, 20 Oct 2015 06:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4131; q=dns/txt; s=iport; t=1445348979; x=1446558579; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=2x3RGCX26mcFT+dOE7SUuFKYWU0JYEcd4JKvbd2W7ps=; b=dJ6xoKfg2IvmcHYz92naLuTYl1p8odT8vo5Ys/KWIsPCakZ6HCmQdjPA nbN+bwCmCXtF9ZrXxAWhZl0Gh/ZWSoHnkiEJ4FEARXSeas/f+jOhv6uah GPx+HxfigzOEuaShLFX/6j1yvn5smEI3jawa9howWaXC9anUN9ggBd8iK c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBADORSZW/xbLJq1ehApvwAcXAQmFM0oCggABAQEBAQGBC4QuAQEEAQEBawoRCwQUCRYPCQMCAQIBFTAGAQwGAgEBiCwNw3ABAQEBAQEBAQEBAQEBAQEBAQEBFgSGd4R+hRSELgWNEokShRmIBokYkwljhAQ9NIVnAQEB
X-IronPort-AV: E=Sophos;i="5.17,707,1437436800";  d="scan'208,217";a="605817060"
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; 20 Oct 2015 13:49:35 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9KDnZ8G005461; Tue, 20 Oct 2015 13:49:35 GMT
To: Andy Bierman , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <5626465D.8080506@cisco.com>
Date: Tue, 20 Oct 2015 14:49:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010706050809000200010602"
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 13:49:45 -0000

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

Hi,

I have one question related to "5.1.  Module Naming Conventions".

Currently, the YANG modules that I have included as part of my 
individual IDs don't currently use an "ietf-" prefix because the drafts 
haven't been adopted as WG documents yet.

However, this means that the pyang tool throws up a warning for this.  E.g.
interfaces-common@2015-10-19.yang:1: warning: RFC 6087: 4.1: no module 
name prefix used, suggest ietf-interfaces-common

So, am I right in not including the ietf prefix for non WG adopted 
drafts?  If so, should the above warning in pyang be made informational 
instead?

Thanks,
Rob


On 20/10/2015 02:41, Andy Bierman wrote:
> Hi,
>
> I updated the YANG guidelines draft.
> All open issues have been addressed in this version.
>
> https://github.com/netmod-wg/rfc6087bis/issues
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    Hi,

    

    I have one question related to "5.1.  Module Naming Conventions".

    

    Currently, the YANG modules that I have included as part of my
    individual IDs don't currently use an "ietf-" prefix because the
    drafts haven't been adopted as WG documents yet.

    

    However, this means that the pyang tool throws up a warning for
    this.  E.g.

    interfaces-common@2015-10-19.yang:1:
      warning: RFC 6087: 4.1: no module name prefix used, suggest
      ietf-interfaces-common

    

    So, am I right in not including the ietf prefix for non WG adopted
    drafts?  If so, should the above warning in pyang be made
    informational instead?

    

    Thanks,

    Rob

    

    

    
On 20/10/2015 02:41, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I updated the YANG guidelines draft.

        
All open issues have been addressed in this version.

        


        

        
        


        

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------010706050809000200010602--


From nobody Tue Oct 20 06:57:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A821A906A for ; Tue, 20 Oct 2015 06:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVS6AXvCXD8k for ; Tue, 20 Oct 2015 06:57:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 613661A21BC for ; Tue, 20 Oct 2015 06:57:49 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id BE7451AE044D; Tue, 20 Oct 2015 15:57:47 +0200 (CEST)
Date: Tue, 20 Oct 2015 16:01:53 +0200 (CEST)
Message-Id: <20151020.160153.1860469323996980043.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5626465D.8080506@cisco.com>
References:  <5626465D.8080506@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 13:57:53 -0000

Robert Wilton  wrote:
> Hi,
> 
> I have one question related to "5.1.  Module Naming Conventions".
> 
> Currently, the YANG modules that I have included as part of my
> individual IDs don't currently use an "ietf-" prefix because the
> drafts haven't been adopted as WG documents yet.
> 
> However, this means that the pyang tool throws up a warning for this.
> E.g.
> interfaces-common@2015-10-19.yang:1: warning: RFC 6087: 4.1: no module
> name prefix used, suggest ietf-interfaces-common
> 
> So, am I right in not including the ietf prefix for non WG adopted
> drafts?  If so, should the above warning in pyang be made
> informational instead?

I think it wiuld be useful if 6087bis provided guidelines for these
kinds of modules as well.

That said, I think that pyang --ietf should still flag this as an
error.  When checking a non-WG module, use --lint instead of --ietf.


/martin


From nobody Tue Oct 20 10:31:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CAC1ACD83 for ; Tue, 20 Oct 2015 10:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AtEHY4XyZxQk for ; Tue, 20 Oct 2015 10:31:14 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id E37301ACD6F for ; Tue, 20 Oct 2015 10:31:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fdw7SSgod8dR+nrYCf9VrloU/jTrfKB/Qwzljgjejncy4yIfEO0Lbbhc5XAj+/qY; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zoake-0001TG-2C for netmod@ietf.org; Tue, 20 Oct 2015 13:31:08 -0400
Received: from 76.254.55.186 by webmail.earthlink.net with HTTP; Tue, 20 Oct 2015 13:31:07 -0400
Message-ID: <16391131.1445362267969.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Date: Tue, 20 Oct 2015 10:31:07 -0700 (GMT-07:00)
From: Randy Presuhn 
To: "netmod@ietf.org" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed780b4b8855201765d486aae7362d481a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.26
Archived-At: 
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 17:31:16 -0000

Hi -

>From: "Einar Nilsen-Nygaard (einarnn)" 
>Sent: Oct 20, 2015 5:17 AM
>To: Martin Bjorklund 
>Cc: "netmod@ietf.org" 
>Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
...
>To perhaps be a little more precise, I mean that it is the
>server's job to make the information about whether or not
>intended config has been instantiated correctly in a way
>that is really easy to correlate with the intended config
>asserted by the client. In terms of aggregating the status
>of the operational leaves into a ingle value that could,
>for example, be diff'd with the intended config, that would
>meet the criteria of being easy to correlate with the intended
>config.

This discussion seems to conflate three distinct problems.

One, which is a classic configuration management problem and
which was one of the operator requirements going into this work
from the beginning, is the ability to compare two configurations.
A special case of this is comparing a system's actual configuration
with an intended configuration.  Should be incredibly straightforward.

The second problem, which was mentioned more-or-less in passing
at the IAB workshop, is in the realm of intention-based management.
One of the tools needed to implemented intention-based management
is the ability to compare a systems actual *operational* state
with an intended operational state.

The similarity between these two problems is superficial; even
with a deep understanding of the relationship between the two
state spaces (including acknowledgement of the fact that operational
state often depends on factors that are outside the configuration)
it can be very difficult to get from A to B.

The third problem arises from excessive complications in the inter-
relationships between model components, resulting in situations
where one can't fully validate a request without actually
trying to activate it.  This largely avoidable problem is a
question of both system and management interface design.  In
legacy environments, however, it may be intractable.

>What we may find is that thinking about requirements like this may
>make us more mindful of how we define the relationship between
>intended config and how our internal components work together
>to achieve it and how we expose the success or failure of config
>operations in a way that is easier for users to make sense of.

Another way of putting it:
  It *is* possible to design management interfaces in such a way
  as to make both kinds of interactions easier.  However, as long
  as the working assumption is that these technologies will
  essentially serve as a wrapper for legacy CLIs, making this work
  will require vast amounts of duct tape.

>Additionally, I'm not saying that there isn't operational state
>that each of the N internal components have. That still exists,
>and will continue to exist as part of ongoing operational management.

Agreed.  But there's going to be tension between supporting what
one might need to handle a modular system designed from the
outset to be managed using this technology, and supporting the
crufty realities of systems where the management interface has
been cobbled together over many years with short-term expediency
as its guiding principle.

Randy


From nobody Tue Oct 20 12:23:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6D91AD070 for ; Tue, 20 Oct 2015 12:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLEYe9vKAkuq for ; Tue, 20 Oct 2015 12:23:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0E01AD2F6 for ; Tue, 20 Oct 2015 12:21:36 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 72CE41AE044D; Tue, 20 Oct 2015 21:21:34 +0200 (CEST)
Date: Tue, 20 Oct 2015 21:25:42 +0200 (CEST)
Message-Id: <20151020.212542.764485703129847252.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 19:23:48 -0000

Andy Bierman  wrote:
> Hi,
> 
> I updated the YANG guidelines draft.

I have a couple of comments.

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

Section 5.14 says:

    The "choice" statement is allowed to be directly present within a
    "case" statement in YANG 1.1.

It is allowed in YANG 1 as well.

    This needs to be considered
    carefully.  Consider simply including the nested "choice" as
    additional "case" statements within the parent "choice" statement.

Ok, but I don't think people use nested choice by accident.  I have
seen it used a handful of times, and there was always a good reason
for doing it.  If you think some warning text like this is needed, I
suggest something along the lines of:

    If a "case" statement contains a single "choice" statement,
    consider simply including ...

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

Section 5.1 says:

           Normative modules contained in Standards Track documents
	   MUST be named according to the guidelines in the IANA
	   Considerations section of [I-D.ietf-netmod-rfc6020bis].


Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
text is not copied to 6020bis.  So either reference 6020, or copy the
rule (use "ietf-" prefix).




/martin


From nobody Tue Oct 20 14:28:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFB31A906D for ; Tue, 20 Oct 2015 14:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level: 
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Do4fqvEFOqh for ; Tue, 20 Oct 2015 14:28:25 -0700 (PDT)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6B32D1A90D1 for ; Tue, 20 Oct 2015 14:28:25 -0700 (PDT)
Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA10975; Tue, 20 Oct 2015 17:28:21 -0400 (EDT)
Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t9KLSKek081699; Tue, 20 Oct 2015 17:28:21 -0400 (EDT) (envelope-from reid@snmp.com)
Message-Id: <201510202128.t9KLSKek081699@mainfs.snmp.com>
To: Juergen Schoenwaelder 
From: David Reid 
In-reply-to: Your message of Sat, 17 Oct 2015 11:05:12 +0200. <20151017090512.GA76449@elstar.local>
Date: Tue, 20 Oct 2015 17:28:20 -0400
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] 6020bis more than one revision of a module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Reid 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Oct 2015 21:28:27 -0000

> On Wed, Oct 14, 2015 at 10:49:02AM -0400, David Reid wrote:
> > > >I'm reviewing 6020bis since it is in working group last call. 
> > > >I see a new requirement that a server MUST NOT implement
> > > >more than one revision of a module. I understand that supporting
> > > >more than one revision can cause problems, but I expect that
> > > >it will happen in practice. I know it happens sometimes with
> > > >MIBs in SNMP. I think MUST NOT is too strong.
> > > 
> > > I've encountered the same phenomenon in the SNMP universe,
> > > so if I expected Netconf to used as a replacement for SNMP
> > > I'd have the same concern.
> > > 
> > > Randy
> > 
> > Here is the situation I face. We put a netconf server in our SNMP Master
> > agent. Using the MIB to YANG conversion rules from RFC 6643 we can provide
> > read-only access (or read-write in a non-standard way) via netconf and yang
> > to all of the MIB data. We have existing customers using different revisions
> > of the same MIB module in different subagents. If they convert those
> > MIB modules to YANG modules and access the information via netconf, it
> > would violate the proposed rule.
> 
> The RFC 6643 translation generates no mandatory statements in YANG and
> the RFC 6643 translation is read-only. So for read-only access, using
> the latest MIB module as a basis should work since SMIv2 has strict
> backwards compatibility rules, no?

For read-only objects, yes. But Andy argued that for read-write objects
I should advertise the oldest revision. This is not a problem in YANG yet
because we don't have multiple versions of YANG modules in the field yet.

Why does yang 1.1 add the new requirement that a server MUST NOT implement
more than 1 revision? If there is an e-mail thread, you can point me at that
rather than re-hash the arguements here.

-David Reid


From nobody Tue Oct 20 23:57:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95351A1BDC for ; Tue, 20 Oct 2015 23:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGKuSw1ZyJ52 for ; Tue, 20 Oct 2015 23:57:21 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB21A1AA1 for ; Tue, 20 Oct 2015 23:57:19 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 141121CC02BB; Wed, 21 Oct 2015 08:57:17 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , andy@yumaworks.com
In-Reply-To: <20151020.212542.764485703129847252.mbj@tail-f.com>
References:  <20151020.212542.764485703129847252.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 21 Oct 2015 08:57:17 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 06:57:23 -0000

Martin Bjorklund  writes:

> Andy Bierman  wrote:
>> Hi,
>> 
>> I updated the YANG guidelines draft.
>
> I have a couple of comments.
>
> --------------------------
>
> Section 5.14 says:
>
>     The "choice" statement is allowed to be directly present within a
>     "case" statement in YANG 1.1.
>
> It is allowed in YANG 1 as well.
>
>     This needs to be considered
>     carefully.  Consider simply including the nested "choice" as
>     additional "case" statements within the parent "choice" statement.
>
> Ok, but I don't think people use nested choice by accident.  I have
> seen it used a handful of times, and there was always a good reason
> for doing it.  If you think some warning text like this is needed, I

But isn't it that in these legitimate cases the inner choice is always
accompanied by other nodes within the same case? The solution to Y29
enables choice as a short-hand case, and this can always be
flattened. Do I miss something?

Lada

> suggest something along the lines of:
>
>     If a "case" statement contains a single "choice" statement,
>     consider simply including ...
>
> --------------------------
>
> Section 5.1 says:
>
>            Normative modules contained in Standards Track documents
> 	   MUST be named according to the guidelines in the IANA
> 	   Considerations section of [I-D.ietf-netmod-rfc6020bis].
>
>
> Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
> text is not copied to 6020bis.  So either reference 6020, or copy the
> rule (use "ietf-" prefix).
>
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Wed Oct 21 00:17:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236E11A1B6D for ; Wed, 21 Oct 2015 00:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbkoRfp2EkaK for ; Wed, 21 Oct 2015 00:17:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1B931A1B6A for ; Wed, 21 Oct 2015 00:17:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 55C011AE0478; Wed, 21 Oct 2015 09:17:47 +0200 (CEST)
Date: Wed, 21 Oct 2015 09:17:46 +0200 (CEST)
Message-Id: <20151021.091746.2085171677282069975.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20151020.212542.764485703129847252.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:17:51 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Andy Bierman  wrote:
> >> Hi,
> >> 
> >> I updated the YANG guidelines draft.
> >
> > I have a couple of comments.
> >
> > --------------------------
> >
> > Section 5.14 says:
> >
> >     The "choice" statement is allowed to be directly present within a
> >     "case" statement in YANG 1.1.
> >
> > It is allowed in YANG 1 as well.
> >
> >     This needs to be considered
> >     carefully.  Consider simply including the nested "choice" as
> >     additional "case" statements within the parent "choice" statement.
> >
> > Ok, but I don't think people use nested choice by accident.  I have
> > seen it used a handful of times, and there was always a good reason
> > for doing it.  If you think some warning text like this is needed, I
> 
> But isn't it that in these legitimate cases the inner choice is always
> accompanied by other nodes within the same case? The solution to Y29
> enables choice as a short-hand case, and this can always be
> flattened. Do I miss something?

No you're right.  It should also be noted that an implementation can
choose to flatten such nested choices.


/martin



> 
> Lada
> 
> > suggest something along the lines of:
> >
> >     If a "case" statement contains a single "choice" statement,
> >     consider simply including ...
> >
> > --------------------------
> >
> > Section 5.1 says:
> >
> >            Normative modules contained in Standards Track documents
> > 	   MUST be named according to the guidelines in the IANA
> > 	   Considerations section of [I-D.ietf-netmod-rfc6020bis].
> >
> >
> > Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
> > text is not copied to 6020bis.  So either reference 6020, or copy the
> > rule (use "ietf-" prefix).
> >
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 


From nobody Wed Oct 21 00:21:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E881AC39A for ; Wed, 21 Oct 2015 00:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbpnQWXaRfBI for ; Wed, 21 Oct 2015 00:21:26 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 68CE91AC408 for ; Wed, 21 Oct 2015 00:21:26 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 69C7CC4175C2; Wed, 21 Oct 2015 09:21:22 +0200 (CEST)
To: Andy Bierman , "netmod@ietf.org" 
References: 
From: Jernej Tuljak 
Message-ID: <56273CF1.3070704@mg-soft.si>
Date: Wed, 21 Oct 2015 09:21:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050307090702050101060307"
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:21:28 -0000

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

Andy Bierman je 20.10.2015 ob 3:41 napisal:
> Hi,
>
> I updated the YANG guidelines draft.
> All open issues have been addressed in this version.
>
> https://github.com/netmod-wg/rfc6087bis/issues

You missed this: 
https://www.ietf.org/mail-archive/web/netmod/current/msg13593.html

Applies to both YANG 1.0 and current 1.1 text.

Jernej

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


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


  
    
  
  
    
Andy Bierman je 20.10.2015 ob
      3:41 napisal:

    

    

      
Hi,
        


        

        
I updated the YANG guidelines draft.

        
All open issues have been addressed in this version.

        


        

        
      

    

    

    You missed this:
    https://www.ietf.org/mail-archive/web/netmod/current/msg13593.html

    

    Applies to both YANG 1.0 and current 1.1 text.

    

    Jernej

    

    

      

        


        

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------050307090702050101060307--


From nobody Wed Oct 21 00:22:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A923F1AD210 for ; Wed, 21 Oct 2015 00:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqadi6IK2Nqp for ; Wed, 21 Oct 2015 00:22:51 -0700 (PDT)
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 AFE921AC408 for ; Wed, 21 Oct 2015 00:22:51 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd] (unknown [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd]) by mail.nic.cz (Postfix) with ESMTPSA id 363A0180F3E; Wed, 21 Oct 2015 09:22:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445412170; bh=IzPMpGcC4YS/0Jz5KF85CF/TQUgMu6NBTsz6DNz+LyQ=; h=From:Date:To; b=rYGfsWn2OEIT30rbDZjHmQ6Z4CRBt96PEWjneTvLUn7FMEc7YUaYrFqpXw0KASD3j xOsQbGInXIcXdkDjk1EFciHwtAwA8JFP4KFFa4DGA4YM6NgDmUzYu/8YG9/IfGS//B +mBF0NWkR/Vw7dVCZ6BVyeQL0pCr09izZ/L7q9wk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151021.091746.2085171677282069975.mbj@tail-f.com>
Date: Wed, 21 Oct 2015 09:22:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151020.212542.764485703129847252.mbj@tail-f.com>  <20151021.091746.2085171677282069975.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:22:53 -0000

> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Andy Bierman  wrote:
>>>> Hi,
>>>>=20
>>>> I updated the YANG guidelines draft.
>>>=20
>>> I have a couple of comments.
>>>=20
>>> --------------------------
>>>=20
>>> Section 5.14 says:
>>>=20
>>>    The "choice" statement is allowed to be directly present within a
>>>    "case" statement in YANG 1.1.
>>>=20
>>> It is allowed in YANG 1 as well.
>>>=20
>>>    This needs to be considered
>>>    carefully.  Consider simply including the nested "choice" as
>>>    additional "case" statements within the parent "choice" =
statement.
>>>=20
>>> Ok, but I don't think people use nested choice by accident.  I have
>>> seen it used a handful of times, and there was always a good reason
>>> for doing it.  If you think some warning text like this is needed, I
>>=20
>> But isn't it that in these legitimate cases the inner choice is =
always
>> accompanied by other nodes within the same case? The solution to Y29
>> enables choice as a short-hand case, and this can always be
>> flattened. Do I miss something?
>=20
> No you're right.  It should also be noted that an implementation can
> choose to flatten such nested choices.

So maybe this was the reason for not allowing choice as a short-hand =
case. I wonder, is Y29-01 a good idea after all? We are encouraging =
people to do convoluted things that have a simpler alternative.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>> suggest something along the lines of:
>>>=20
>>>    If a "case" statement contains a single "choice" statement,
>>>    consider simply including ...
>>>=20
>>> --------------------------
>>>=20
>>> Section 5.1 says:
>>>=20
>>>           Normative modules contained in Standards Track documents
>>> 	   MUST be named according to the guidelines in the IANA
>>> 	   Considerations section of [I-D.ietf-netmod-rfc6020bis].
>>>=20
>>>=20
>>> Note that since 6020bis doesn't obsolete 6020, the IANA =
Considerations
>>> text is not copied to 6020bis.  So either reference 6020, or copy =
the
>>> rule (use "ietf-" prefix).
>>>=20
>>>=20
>>>=20
>>>=20
>>> /martin
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Wed Oct 21 00:36:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954711B2E18 for ; Wed, 21 Oct 2015 00:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exGrXFFEHEPJ for ; Wed, 21 Oct 2015 00:36:43 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A891ACE6F for ; Wed, 21 Oct 2015 00:36:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0033A15D3; Wed, 21 Oct 2015 09:36:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JV9ml1imLYkr; Wed, 21 Oct 2015 09:36:41 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Oct 2015 09:36:41 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 282042005F; Wed, 21 Oct 2015 09:36:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eD3TgfIfzuqI; Wed, 21 Oct 2015 09:36:40 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D30B20060; Wed, 21 Oct 2015 09:36:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5B4BA37EA504; Wed, 21 Oct 2015 09:36:36 +0200 (CEST)
Date: Wed, 21 Oct 2015 09:36:36 +0200
From: Juergen Schoenwaelder 
To: David Reid 
Message-ID: <20151021073635.GB64783@elstar.local>
Mail-Followup-To: David Reid , Randy Presuhn , netmod@ietf.org
References: <20151017090512.GA76449@elstar.local> <201510202128.t9KLSKek081699@mainfs.snmp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201510202128.t9KLSKek081699@mainfs.snmp.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] 6020bis more than one revision of a module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:36:45 -0000

On Tue, Oct 20, 2015 at 05:28:20PM -0400, David Reid wrote:
> 
> Why does yang 1.1 add the new requirement that a server MUST NOT implement
> more than 1 revision? If there is an e-mail thread, you can point me at that
> rather than re-hash the arguements here.
>

How do you implement multiple revisions at the same time? There is
only one path in a namespace. How do you combine must/when constraints
if you implement multiple revisions of a module? I think the one
revision requirement has already been part of YANG 1.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Oct 21 00:50:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277391B3696 for ; Wed, 21 Oct 2015 00:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsRijxifzk-w for ; Wed, 21 Oct 2015 00:50:21 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C69231B3695 for ; Wed, 21 Oct 2015 00:50:20 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 9D13C1AE0478; Wed, 21 Oct 2015 09:50:19 +0200 (CEST)
Date: Wed, 21 Oct 2015 09:50:19 +0200 (CEST)
Message-Id: <20151021.095019.1149181033365523229.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20151021.091746.2085171677282069975.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:50:22 -0000

Ladislav Lhotka  wrote:
> 
> > On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> 
> >>> Andy Bierman  wrote:
> >>>> Hi,
> >>>> 
> >>>> I updated the YANG guidelines draft.
> >>> 
> >>> I have a couple of comments.
> >>> 
> >>> --------------------------
> >>> 
> >>> Section 5.14 says:
> >>> 
> >>>    The "choice" statement is allowed to be directly present within a
> >>>    "case" statement in YANG 1.1.
> >>> 
> >>> It is allowed in YANG 1 as well.
> >>> 
> >>>    This needs to be considered
> >>>    carefully.  Consider simply including the nested "choice" as
> >>>    additional "case" statements within the parent "choice" statement.
> >>> 
> >>> Ok, but I don't think people use nested choice by accident.  I have
> >>> seen it used a handful of times, and there was always a good reason
> >>> for doing it.  If you think some warning text like this is needed, I
> >> 
> >> But isn't it that in these legitimate cases the inner choice is always
> >> accompanied by other nodes within the same case? The solution to Y29
> >> enables choice as a short-hand case, and this can always be
> >> flattened. Do I miss something?
> > 
> > No you're right.  It should also be noted that an implementation can
> > choose to flatten such nested choices.
> 
> So maybe this was the reason for not allowing choice as a short-hand
> case. I wonder, is Y29-01 a good idea after all? We are encouraging
> people to do convoluted things that have a simpler alternative.

IMO Y29 is about having consistent rules in the language.  Allowing
short hand cases for just a subset of the nodes seems like a CLR.


/martin


From nobody Wed Oct 21 00:51:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6EF1B3698 for ; Wed, 21 Oct 2015 00:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_LocqwdUUKv for ; Wed, 21 Oct 2015 00:51:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC01B3695 for ; Wed, 21 Oct 2015 00:51:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 87A951AE0478; Wed, 21 Oct 2015 09:51:47 +0200 (CEST)
Date: Wed, 21 Oct 2015 09:51:47 +0200 (CEST)
Message-Id: <20151021.095147.1079580075249695338.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151021073635.GB64783@elstar.local>
References: <20151017090512.GA76449@elstar.local> <201510202128.t9KLSKek081699@mainfs.snmp.com> <20151021073635.GB64783@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] 6020bis more than one revision of a module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 07:51:51 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Oct 20, 2015 at 05:28:20PM -0400, David Reid wrote:
> > 
> > Why does yang 1.1 add the new requirement that a server MUST NOT implement
> > more than 1 revision? If there is an e-mail thread, you can point me at that
> > rather than re-hash the arguements here.
> >
> 
> How do you implement multiple revisions at the same time? There is
> only one path in a namespace. How do you combine must/when constraints
> if you implement multiple revisions of a module? I think the one
> revision requirement has already been part of YANG 1.

+1

Another example is if the value space for a leaf has been expanded in
the new revision.  What does it mean if you advertise both revisions?


/martin


From nobody Wed Oct 21 01:05:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CD21B36AA for ; Wed, 21 Oct 2015 01:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XWxlMN-hD1Q for ; Wed, 21 Oct 2015 01:05:51 -0700 (PDT)
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 AB2091B36A8 for ; Wed, 21 Oct 2015 01:05:51 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd] (unknown [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd]) by mail.nic.cz (Postfix) with ESMTPSA id 4210B181A2A; Wed, 21 Oct 2015 10:05:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445414750; bh=NnE1OPGz1XdZHfmrz/VV8mg/A2Slj2HXXmMViWgJj9I=; h=From:Date:To; b=H/cQU1SB57UP/jUZZBDA1ivBzXSfeB3VO5pCrXn8ZqfZjUZ99uMpaKCNjF/oAKlru mq3wHdxPhthmfIW0y46GvH/v4Rf5Ki0fJX5++fw4cogCknHVy2UddsEbuKcptmG5Ei QJlOhQqYM7ONLUVIan7iaCG42xeHrG7TZAWQ7f9Y=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151021.095019.1149181033365523229.mbj@tail-f.com>
Date: Wed, 21 Oct 2015 10:05:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151021.091746.2085171677282069975.mbj@tail-f.com>  <20151021.095019.1149181033365523229.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 08:05:53 -0000

> On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>> Martin Bjorklund  writes:
>>>>=20
>>>>> Andy Bierman  wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> I updated the YANG guidelines draft.
>>>>>=20
>>>>> I have a couple of comments.
>>>>>=20
>>>>> --------------------------
>>>>>=20
>>>>> Section 5.14 says:
>>>>>=20
>>>>>   The "choice" statement is allowed to be directly present within =
a
>>>>>   "case" statement in YANG 1.1.
>>>>>=20
>>>>> It is allowed in YANG 1 as well.
>>>>>=20
>>>>>   This needs to be considered
>>>>>   carefully.  Consider simply including the nested "choice" as
>>>>>   additional "case" statements within the parent "choice" =
statement.
>>>>>=20
>>>>> Ok, but I don't think people use nested choice by accident.  I =
have
>>>>> seen it used a handful of times, and there was always a good =
reason
>>>>> for doing it.  If you think some warning text like this is needed, =
I
>>>>=20
>>>> But isn't it that in these legitimate cases the inner choice is =
always
>>>> accompanied by other nodes within the same case? The solution to =
Y29
>>>> enables choice as a short-hand case, and this can always be
>>>> flattened. Do I miss something?
>>>=20
>>> No you're right.  It should also be noted that an implementation can
>>> choose to flatten such nested choices.
>>=20
>> So maybe this was the reason for not allowing choice as a short-hand
>> case. I wonder, is Y29-01 a good idea after all? We are encouraging
>> people to do convoluted things that have a simpler alternative.
>=20
> IMO Y29 is about having consistent rules in the language.  Allowing
> short hand cases for just a subset of the nodes seems like a CLR.

It would be practically useful in cases like this:

grouping foo {
  choice foo {
    ...
  }
}

choice foobar {
  uses foo;
  leaf bar;
}

However, this is not possible because of another CLR that doesn't allow =
"uses" as a substatment of "choice". So if we want consistency, we =
should simply remove short-case-stmt from the ABNF and use data-def-stmt =
instead.

Lada

>=20
>=20
> /martin

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





From nobody Wed Oct 21 01:13:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED2C1B2C99 for ; Wed, 21 Oct 2015 01:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3TvM4-MHyWx for ; Wed, 21 Oct 2015 01:13:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73BBA1B2C5C for ; Wed, 21 Oct 2015 01:13:41 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D8BC1AE0478; Wed, 21 Oct 2015 10:13:40 +0200 (CEST)
Date: Wed, 21 Oct 2015 10:13:39 +0200 (CEST)
Message-Id: <20151021.101339.833162169909437119.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20151021.095019.1149181033365523229.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 08:13:43 -0000

Ladislav Lhotka  wrote:
> 
> > On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> >>> 
> >>> Ladislav Lhotka  wrote:
> >>>> Martin Bjorklund  writes:
> >>>> 
> >>>>> Andy Bierman  wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> I updated the YANG guidelines draft.
> >>>>> 
> >>>>> I have a couple of comments.
> >>>>> 
> >>>>> --------------------------
> >>>>> 
> >>>>> Section 5.14 says:
> >>>>> 
> >>>>>   The "choice" statement is allowed to be directly present within a
> >>>>>   "case" statement in YANG 1.1.
> >>>>> 
> >>>>> It is allowed in YANG 1 as well.
> >>>>> 
> >>>>>   This needs to be considered
> >>>>>   carefully.  Consider simply including the nested "choice" as
> >>>>>   additional "case" statements within the parent "choice" statement.
> >>>>> 
> >>>>> Ok, but I don't think people use nested choice by accident.  I have
> >>>>> seen it used a handful of times, and there was always a good reason
> >>>>> for doing it.  If you think some warning text like this is needed, I
> >>>> 
> >>>> But isn't it that in these legitimate cases the inner choice is always
> >>>> accompanied by other nodes within the same case? The solution to Y29
> >>>> enables choice as a short-hand case, and this can always be
> >>>> flattened. Do I miss something?
> >>> 
> >>> No you're right.  It should also be noted that an implementation can
> >>> choose to flatten such nested choices.
> >> 
> >> So maybe this was the reason for not allowing choice as a short-hand
> >> case. I wonder, is Y29-01 a good idea after all? We are encouraging
> >> people to do convoluted things that have a simpler alternative.
> > 
> > IMO Y29 is about having consistent rules in the language.  Allowing
> > short hand cases for just a subset of the nodes seems like a CLR.
> 
> It would be practically useful in cases like this:
> 
> grouping foo {
>   choice foo {
>     ...
>   }
> }
> 
> choice foobar {
>   uses foo;
>   leaf bar;
> }
> 
> However, this is not possible because of another CLR that doesn't
> allow "uses" as a substatment of "choice". So if we want consistency,
> we should simply remove short-case-stmt from the ABNF and use
> data-def-stmt instead.

The problem with allowing uses as a shorthand is that it is not
directly obvious what it means.  For example:

  grouping foo {
    leaf a { ... }
    leaf b { ... }
  }

  choice x {
    uses foo;
  }


could be equivalent to:

A:

 choice x {
   leaf a { ... }
   leaf b { ... }
 }

or

B:

 choice x {
   case foo {
     leaf a { ... }
     leaf b { ... }
   }
 }



/martin


From nobody Wed Oct 21 01:51:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A717C1A0122 for ; Wed, 21 Oct 2015 01:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRCsAdYvf-5e for ; Wed, 21 Oct 2015 01:51:21 -0700 (PDT)
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 49E341A0121 for ; Wed, 21 Oct 2015 01:51:21 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd] (unknown [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd]) by mail.nic.cz (Postfix) with ESMTPSA id 88A62181486; Wed, 21 Oct 2015 10:51:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445417479; bh=7WaCqIyqzu9QNOIGCdVGcEVdsHZir4xKo9Vq4F0tvko=; h=From:Date:To; b=lqetooj36WkhW7Qat+YEr3TVEHhMJWeU0sOx7bjja2CDG5fjjuisQXq/RSOyOq5YU /Ayw02F0UdG3E8dFR/aTX4GSEclAihTDDugS5q32pXr7gW7tkdbqh6Kg7DNvgvMdf+ 1onLOghQ8zFleesUxrWgofY0mZ1FVLm9HM/qB7so=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: <20151021.101339.833162169909437119.mbj@tail-f.com>
Date: Wed, 21 Oct 2015 10:51:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151021.095019.1149181033365523229.mbj@tail-f.com>  <20151021.101339.833162169909437119.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 08:51:23 -0000

> On 21 Oct 2015, at 10:13, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>>=20
>>>>> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
>>>>>=20
>>>>> Ladislav Lhotka  wrote:
>>>>>> Martin Bjorklund  writes:
>>>>>>=20
>>>>>>> Andy Bierman  wrote:
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> I updated the YANG guidelines draft.
>>>>>>>=20
>>>>>>> I have a couple of comments.
>>>>>>>=20
>>>>>>> --------------------------
>>>>>>>=20
>>>>>>> Section 5.14 says:
>>>>>>>=20
>>>>>>>  The "choice" statement is allowed to be directly present within =
a
>>>>>>>  "case" statement in YANG 1.1.
>>>>>>>=20
>>>>>>> It is allowed in YANG 1 as well.
>>>>>>>=20
>>>>>>>  This needs to be considered
>>>>>>>  carefully.  Consider simply including the nested "choice" as
>>>>>>>  additional "case" statements within the parent "choice" =
statement.
>>>>>>>=20
>>>>>>> Ok, but I don't think people use nested choice by accident.  I =
have
>>>>>>> seen it used a handful of times, and there was always a good =
reason
>>>>>>> for doing it.  If you think some warning text like this is =
needed, I
>>>>>>=20
>>>>>> But isn't it that in these legitimate cases the inner choice is =
always
>>>>>> accompanied by other nodes within the same case? The solution to =
Y29
>>>>>> enables choice as a short-hand case, and this can always be
>>>>>> flattened. Do I miss something?
>>>>>=20
>>>>> No you're right.  It should also be noted that an implementation =
can
>>>>> choose to flatten such nested choices.
>>>>=20
>>>> So maybe this was the reason for not allowing choice as a =
short-hand
>>>> case. I wonder, is Y29-01 a good idea after all? We are encouraging
>>>> people to do convoluted things that have a simpler alternative.
>>>=20
>>> IMO Y29 is about having consistent rules in the language.  Allowing
>>> short hand cases for just a subset of the nodes seems like a CLR.
>>=20
>> It would be practically useful in cases like this:
>>=20
>> grouping foo {
>>  choice foo {
>>    ...
>>  }
>> }
>>=20
>> choice foobar {
>>  uses foo;
>>  leaf bar;
>> }
>>=20
>> However, this is not possible because of another CLR that doesn't
>> allow "uses" as a substatment of "choice". So if we want consistency,
>> we should simply remove short-case-stmt from the ABNF and use
>> data-def-stmt instead.
>=20
> The problem with allowing uses as a shorthand is that it is not
> directly obvious what it means.  For example:
>=20
>  grouping foo {
>    leaf a { ... }
>    leaf b { ... }
>  }
>=20
>  choice x {
>    uses foo;
>  }
>=20
>=20
> could be equivalent to:
>=20
> A:
>=20
> choice x {
>   leaf a { ... }
>   leaf b { ... }
> }
>=20
> or
>=20
> B:
>=20
> choice x {
>   case foo {
>     leaf a { ... }
>     leaf b { ... }
>   }
> }
>=20

The text in sec. 7.13 makes it quite clear that it would be A (The =
effect of a "uses" reference to a grouping is that the nodes defined by =
the grouping are copied into the current schema tree, =E2=80=A6 ).

Moreover, you have a similar dilemma if you augment a choice:

augment x {
  leaf a { ... }
  leaf b { ... }
}

But my point is different: choice as a short-hand case is only possible =
directly, not via "uses":

choice foo {
  choice bar { ... }
  ...
}

However, this really begs the question "Why don't you simply make the =
cases of 'bar' into cases of 'foo'?" I can't see any reasonable answer.

Balazs wanted to add CLRs to ban "complex" choices. I don't know how to =
do it in general but here we are removing one obstacle for defining =
choices that are *needlessly* complex.

Lada

>=20
>=20
> /martin

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





From nobody Wed Oct 21 04:46:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097211A9177 for ; Wed, 21 Oct 2015 04:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFLlkiHE3p8E for ; Wed, 21 Oct 2015 04:46:02 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261471A9149 for ; Wed, 21 Oct 2015 04:46:01 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-82-56277af84473
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.35.17026.8FA77265; Wed, 21 Oct 2015 13:46:00 +0200 (CEST)
Received: from [159.107.197.174] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.248.2; Wed, 21 Oct 2015 13:45:59 +0200
To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>
From: Balazs Lengyel 
Message-ID: <56277AF6.1000300@ericsson.com>
Date: Wed, 21 Oct 2015 13:45:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje6PKvUwg13vpCyubvzJaHFh1Vw2 i/kXG1kdmD2WLPnJ5LHhgKfHpst3GAOYo7hsUlJzMstSi/TtErgynh8qLvggVDHp0FK2BsaT fF2MnBwSAiYSR5tmsUHYYhIX7q0Hsrk4hASOMkrsWtvHAuGsZZR4d+QsC0iVsICxxLH1rWC2 iECZxKnd36CK7jJJnDz7kBEkwSwgKrH+4iUmEJtNwEhiav95sAZeAW2Jv3eXs4PYLAKqEo/2 PgWrERWIkXi/aRUjRI2gxMmZT8DqOQWsJJ5ffQ4U5wCaaS/xYGsZxHh5ie1v5zCD2EICGhIP L/xlncAoOAtJ9yyEjllIOhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzfg1t+6+5g XP3a8RCjAAejEg9vwk61MCHWxLLiytxDjBIczEoivFMS1cOEeFMSK6tSi/Lji0pzUosPMUpz sCiJ87YwPQgVEkhPLEnNTk0tSC2CyTJxcEo1MEad8/ymu/mFdPaPXUqFMgeWV3EfNdhz7+dk B9utb3w3Br/kqsl4zF2ScOmIaGbnzNJyvtb9O5jeF5SGOz+4vta3vlvGk3GJkOdDL5/wL9wX 5GXYtCdu+FIYHdMhsca0P+Nd5mcB45Lfeo+PVCi8fnbkg7xt6lKHdb/mHfj3WtN0/8kQ0dgL 95RYijMSDbWYi4oTAWmcpzdbAgAA
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 11:46:04 -0000

I would love to get rid of the autodelete feature. It really complicates 
things.
regards Balazs

On 2015-10-18 16:43, Ladislav Lhotka wrote:
>> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder  wrote:
>>
>> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
>>> rephrase the intro text in 8.2) But I think Balazs is also right.
>>> Suppose you have:
>>>
>>>   leaf a {
>>>     when "../b = 42";
>>>     type int32;
>>>   }
>>>   leaf b {
>>>     type int32;
>>>   }
>>>
>>> and the db contains b=10.
>>>
>>> Suppose I send an edit-config with a=2.  What is the result?
>>>
>>>   1)  you get an error back
>>>   2)  you get ok; the request to set a to 2 is silently dropped
>>>   3)  something else
>>>
>> Isn't the simplest to always make the changes that were requested in
>> the rpc/action (e.g. edit-config) and then to validate the result and
>> if it fails to validate to return an error? No magic addition or
>> removal of nodes while trying to guess what the client wanted to
>> achieve. I am likely missing details since I never implemented this
> That would be the type of behaviour I'd prefer. The auto-deletion feature also goes against the principle of least embarrassement - a trivial error can inadvertently erase substantial parts of a data tree.
>
> Lada
>
>> but having a processing logic that is simple to understand would be
>> good and I think it is fair to expect that clients send edits that
>> do not require the server to guess what should happen.
>>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Wed Oct 21 04:55:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076661AC3E2 for ; Wed, 21 Oct 2015 04:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZBjsySHBd_j for ; Wed, 21 Oct 2015 04:55:56 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108EF1AC3E1 for ; Wed, 21 Oct 2015 04:55:55 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-69-56277d49805e
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.4C.29154.94D77265; Wed, 21 Oct 2015 13:55:53 +0200 (CEST)
Received: from [159.107.197.174] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Wed, 21 Oct 2015 13:55:53 +0200
To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" 
References:  <20151015.135334.2134677503217017095.mbj@tail-f.com>  <20151015.180357.1644539809319777532.mbj@tail-f.com> <20151018095200.GB78503@elstar.local> <05122A13-3F0D-4089-B195-B75AAA8A96C0@nic.cz>  <20151019190432.GB81250@elstar.local>
From: Balazs Lengyel 
Message-ID: <56277D48.9060903@ericsson.com>
Date: Wed, 21 Oct 2015 13:55:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151019190432.GB81250@elstar.local>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvja5nrXqYwfRPZhYPjsxit7iwai6b xfyLjawOzB5Llvxk8th0+Q6jR0v/RZYA5igum5TUnMyy1CJ9uwSujGnTDzAVXBSuWHArrYFx GX8XIweHhICJxM5utS5GTiBTTOLCvfVsXYxcHEICRxklfl04xgjhrGWUWNOygBmkSljAWOLY +lYWEFtEIFfi7PYXLBBFZ5glbl+ezwqSYBMwkpjafx6siFdAW2LRlDvsIDaLgKrEzQnfwGpE BWIk3m9axQhRIyhxcuYTsHpOoN63PU1sINcxC9hLPNhaBhJmFpCX2P52DtgNQgIaEg8v/GWd wCgwC0n3LISOWUg6FjAyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIDNODW35b7WA8+Nzx EKMAB6MSD2/CTrUwIdbEsuLK3EOMEhzMSiK8UxLVw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInz NjM9CBUSSE8sSc1OTS1ILYLJMnFwSjUw5jeYetXsWe/kvfyj77OnIbwJW4sXr+3NaY/4+USt 7oR5uPmj73pWU0sM9xlpKGifk6y+PUPjnWPF8rmfdUPcJvhtuZ0XvCbzB9/GqCqO+thQ5+ct Xe87GPLn33vr3DRXsCDXceHql3zBMa3LLPRuPuA/JjVLac0Npg5p0fgdr7dvcNjR/+i0Ektx RqKhFnNRcSIA5riZQU8CAAA=
Archived-At: 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 11:55:58 -0000

Fully agree autodelete is fragile. Kill it.

One more reason why it is fragle is that the autodeletion might change 
another "when's" value thereby creating defaults or deleting something 
that can change some other when statement ad infinitum. Detecting such 
possible loops is very difficult.
regards Balazs

On 2015-10-19 21:04, Juergen Schoenwaelder wrote:
> On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote:
>> On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka  wrote:
>>
>>>> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>>>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
>>>>> rephrase the intro text in 8.2) But I think Balazs is also right.
>>>>> Suppose you have:
>>>>>
>>>>>   leaf a {
>>>>>     when "../b = 42";
>>>>>     type int32;
>>>>>   }
>>>>>   leaf b {
>>>>>     type int32;
>>>>>   }
>>>>>
>>>>> and the db contains b=10.
>>>>>
>>>>> Suppose I send an edit-config with a=2.  What is the result?
>>>>>
>>>>>   1)  you get an error back
>>>>>   2)  you get ok; the request to set a to 2 is silently dropped
>>>>>   3)  something else
>>>>>
>>>> Isn't the simplest to always make the changes that were requested in
>>>> the rpc/action (e.g. edit-config) and then to validate the result and
>>>> if it fails to validate to return an error? No magic addition or
>>>> removal of nodes while trying to guess what the client wanted to
>>>> achieve. I am likely missing details since I never implemented this
>>> That would be the type of behaviour I'd prefer. The auto-deletion feature
>>> also goes against the principle of least embarrassement - a trivial error
>>> can inadvertently erase substantial parts of a data tree.
>>>
>>>
>> This goes against the Postel Principle,
>> You can make your code as fragile as possible if you want.
>> I have always written servers that try to figure out what the client is
>> doing.
>>
>> It seems obvious to me that when-stmt is applied after edits are applied,
>> just like a choice-stmt.
>>
>> The server should not be guessing that valid edits from the client
>> are really programming errors.
>>
> To me, auto-deletion feels fragile.
>
> /js
>

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


From nobody Wed Oct 21 05:17:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1481ACEFF for ; Wed, 21 Oct 2015 05:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM0aOduui5BS for ; Wed, 21 Oct 2015 05:17:01 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25581ACEFE for ; Wed, 21 Oct 2015 05:17:00 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-5e-5627823a7369
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.5D.17026.A3287265; Wed, 21 Oct 2015 14:16:59 +0200 (CEST)
Received: from [159.107.197.174] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.248.2; Wed, 21 Oct 2015 14:16:58 +0200
To: Martin Bjorklund , 
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <5627823A.80908@ericsson.com>
Date: Wed, 21 Oct 2015 14:16:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151020.100942.1499503452934383865.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja51k3qYwe6HPBYXVs1ls+jufsZu Mf9iI6sDs8eSJT+ZPDZdvsPosfHXYpYA5igum5TUnMyy1CJ9uwSujP8LnrEUPGCp2Nz+m7GB 8RRzFyMHh4SAicTieyFdjJxAppjEhXvr2boYuTiEBI4ySvy6uw7KWcso0fX2PRNIlbCAscSx 9a0sILaIgJnEp7ZfzBBF9xklehe/YgdJMAuISqy/eAmsgU3ASGJq/3mwBl4BTYmDpzaxgtgs AqoSe19vYwaxRQViJN5vWsUIUSMocXLmE7B6TgFHiYVT3zGCXMosYC/xYGsZxHh5ie1v54C1 CgloSDy88Jd1AqPgLCTdsxA6ZiHpWMDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMIAP bvmtu4Nx9WvHQ4wCHIxKPLwJO9XChFgTy4orcw8xSnAwK4nwTklUDxPiTUmsrEotyo8vKs1J LT7EKM3BoiTO28L0IFRIID2xJDU7NbUgtQgmy8TBKdXAaMO0ZOF5g/n2Ti2VZjYre43E1Rbp Sz3VPurgMulEekH//I9e1jM4GM9J9qSypccW3q4W2V3qsqzra+aJih/PV56/kXNJadOuIJPs aUIzwhWN/XWDQ3duVE2V3t23x+ru+bvzL7RfE+f/ptvyLT7ikKXWm8WRN+q7eeJ3R6YYsm81 CZKX+xunxFKckWioxVxUnAgAmpReR1wCAAA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 12:17:02 -0000

Hello Martin,
I would want to codify this. My earlier proposal was:

- when MUST NOT be dependent on a data node controlled by a when or 
choice statement

Notice the strong MUST NOT statement. This would simplify life greatly.
regards Balazs

On 2015-10-20 10:09, Martin Bjorklund wrote:
> I have never seen anyone trying to refer to the conditional nodes in a
> when expression - simply b/c it doesn't make any sense.

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


From nobody Wed Oct 21 05:33:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E2B1A21A3 for ; Wed, 21 Oct 2015 05:33:52 -0700 (PDT)
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 dVjvUvvJbRXz for ; Wed, 21 Oct 2015 05:33:50 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9501A1B92 for ; Wed, 21 Oct 2015 05:33:50 -0700 (PDT)
Received: by lbbwb3 with SMTP id wb3so37238053lbb.1 for ; Wed, 21 Oct 2015 05:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7CqOIs0SlJzNt8ZO7TVaTOLy5HeIpaGkuGX8litO4OY=; b=T5sP3stLzkuajC5/gCitCzRJI7DrD7O8XrgTE7G7s/CikrEI3jFX+A6dxhzJHEA0lZ n5dvYmGh89jgKJOCPEubrASPYYPWWREp+Ug7kRCk2QiXuEq3CDt7VG3pwujchPz06D+T QlPK3jygh75ck4tFMCrGKe7cgj+wjXBR1b/vEPdr2LPRosMDKllyiL9NeEcydBZIeBmZ hknWiXmHG1wUo8uvnZX/hVNlRLHjZwmPCAJr4p/n6Zleiq9kNtHkuMwlvS2TRV+8DKfV ApGRgqRo3q4YP1+VTPV1/klbxdn6Ci30OtO4WB+URN1fyTu6NmBCHkWG81nb3OMfbgYy W8aA==
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=7CqOIs0SlJzNt8ZO7TVaTOLy5HeIpaGkuGX8litO4OY=; b=Id0kvXbgORcAE66LQcGq7HadDLZ96aGbGp4jXBS+Zr0khar0PPDV0OjfkZR9jngS7O r0xQL8eR7IFYDJd7gLcG1Hdp5BgfmsYkto3hatfvPnuLHcSNt8WMzOWpsTU8zGOa+87Z QVc2CBwCL1VSIN2ayrsXfvLuZJTjU32J1VNx5zLarFHlwGtKLYDvu5eAZsYq//6PZJID VUuY/OlSaHBylcmBXLmKZCyVUPWlvDEkE3DqVX28720syylGs+V3PGfcCpk1E3fCZyBY VrumaMk/Jx903eMlEJYbEdSE8EXK8O7xGtxkovdHcx1q0MS+dtHtVsVZBwqUzRA8nkmK 8d4A==
X-Gm-Message-State: ALoCoQkYgzSA4hlGAQQKLys08T/lituH414nWRx8ibpj9R0UQ+x5nVd6bbm9X+6R0NPZq+ydWx2p
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr5117312lbc.123.1445430827990;  Wed, 21 Oct 2015 05:33:47 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 21 Oct 2015 05:33:47 -0700 (PDT)
In-Reply-To: <5627823A.80908@ericsson.com>
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com> <5627823A.80908@ericsson.com>
Date: Wed, 21 Oct 2015 05:33:47 -0700
Message-ID: 
From: Andy Bierman 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=001a11c266500ce18a05229c97e1
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 12:33:52 -0000

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

Hi,

IMO we do not need lots of rules for when-stmt.
They are harder to enforce than just implementing the auto-deletion.

Note that auto-deletion also applies to nodes already in candidate or
running.
It is just a derivative case to have a newly-created node deleted right
away.
If you add node /foo it may cause node /bar and node /baz to get deleted.

I strongly object to treating a false when-stmt in a datastore validation
as an error.  This is not how YANG 1.0 works, and this is not
backward-compatible.


Andy


On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel  wrote:

> Hello Martin,
> I would want to codify this. My earlier proposal was:
>
> - when MUST NOT be dependent on a data node controlled by a when or choice
> statement
>
> Notice the strong MUST NOT statement. This would simplify life greatly.
> regards Balazs
>
> On 2015-10-20 10:09, Martin Bjorklund wrote:
>
>> I have never seen anyone trying to refer to the conditional nodes in a
>> when expression - simply b/c it doesn't make any sense.
>>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

IMO we do not need lots of rules fo=
r when-stmt.
They are harder to enforce than just implementing th=
e auto-deletion.

Note that auto-deletion also appl=
ies to nodes already in candidate or running.
It is just a deriva=
tive case to have a newly-created node deleted right away.
If you=
 add node /foo it may cause node /bar and node /baz to get deleted.

I strongly object to treating a false when-stmt in a data=
store validation
as an error.=C2=A0 This is not how YANG 1.0 work=
s, and this is not
backward-compatible.

=

Andy

On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengye=
l <balazs.lengyel@ericsson.com> wrote:
Hello Martin,

I would want to codify this. My earlier proposal was:



- when MUST NOT be dependent on a data node controlled by a when or choice =
statement



Notice the strong MUST NOT statement. This would simplify life greatly.

regards Balazs



On 2015-10-20 10:09, Martin Bjorklund wrote:



I have never seen anyone trying to refer to the conditional nodes in a

when expression - simply b/c it doesn't make any sense.





-- 

Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320

Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ema=
il: Balazs=
.Lengyel@ericsson.com



_______________________________________________

netmod mailing list

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





--001a11c266500ce18a05229c97e1--


From nobody Wed Oct 21 05:47:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2F41A6F5D for ; Wed, 21 Oct 2015 05:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDIIxLbrYvm3 for ; Wed, 21 Oct 2015 05:47:00 -0700 (PDT)
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 C10921A6F5B for ; Wed, 21 Oct 2015 05:47:00 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd] (unknown [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd]) by mail.nic.cz (Postfix) with ESMTPSA id C0E5F18195E; Wed, 21 Oct 2015 14:46:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445431618; bh=WqHb3pKkYk2zhOIaN9M1LFPC0e/lryKuiihHKbepSWA=; h=From:Date:To; b=O2GXUu7n+R7nLqC1LlIPNmzn4q4QzSDXUAZKIiIWZk36GCiXwHfyJ06Y2IBsb5gmw wRmSbfJMkPlHW748kC8VHZaZaPpVUHrEnjpU1RBQ9vaXgv92ntWwf0C8KJEKG3VDqy q1kxhVfOrbeohbRu77PNRmO7D41mBy3LVLzlN6cw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 21 Oct 2015 14:46:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com> <5627823A.80908@ericsson.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 12:47:03 -0000

> On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
>=20
> Hi,
>=20
> IMO we do not need lots of rules for when-stmt.
> They are harder to enforce than just implementing the auto-deletion.
>=20
> Note that auto-deletion also applies to nodes already in candidate or =
running.
> It is just a derivative case to have a newly-created node deleted =
right away.
> If you add node /foo it may cause node /bar and node /baz to get =
deleted.
>=20
> I strongly object to treating a false when-stmt in a datastore =
validation
> as an error.  This is not how YANG 1.0 works, and this is not
> backward-compatible.

I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 =
correctly describes this auto-deletion behaviour for "choice" in sec. =
7.9.6 NETCONF  Operations. It is indeed protocol business - =
YANG spec should just define what's valid and what isn't.

IMO RESTCONF spec doesn't require auto-deletion.

Lada

>=20
>=20
> Andy
>=20
>=20
> On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel =
 wrote:
> Hello Martin,
> I would want to codify this. My earlier proposal was:
>=20
> - when MUST NOT be dependent on a data node controlled by a when or =
choice statement
>=20
> Notice the strong MUST NOT statement. This would simplify life =
greatly.
> regards Balazs
>=20
> On 2015-10-20 10:09, Martin Bjorklund wrote:
> I have never seen anyone trying to refer to the conditional nodes in a
> when expression - simply b/c it doesn't make any sense.
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From nobody Wed Oct 21 06:08:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B915C1A6FDA for ; Wed, 21 Oct 2015 06:08:07 -0700 (PDT)
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 Q9FraWmlw4ci for ; Wed, 21 Oct 2015 06:08:06 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5751A6FC2 for ; Wed, 21 Oct 2015 06:07:56 -0700 (PDT)
Received: by lffy185 with SMTP id y185so20658807lff.2 for ; Wed, 21 Oct 2015 06:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kEvys/5iZuzMUwavCLtmdEYomqRin0ImU1XAKMgL+p8=; b=h5KaaBMf9gkp02LGpL2OKCdF+fTO+dNq0iAQf5AGN5cKVfLJjUwgKocbeB3G3x2Ott 81b8HwRwQh0d7TQTqLftrNHRNwyrv0QqT2/roRxhSTw/jpyPB7pjzoYCZv1nlkeHZqLE vhuHyTX6IBLOiHAxIGbIhvsq/b8TCl5/pz8Gyt+QqrFO3dUn7TuNU4/Sgd+6mV0J+K2G LkGjwKwR4tV5MXUJkyB+RbauaG86Vy+OxgB+cKwgfmKoK+EZlLSQXcOpK24tCCNeKOQS acfx8u1naTgLHWle1laLh+j1n0tZd1N6h5+2xv+DjOkfa74mxhefXMWxrmHbe8X5g5wt fQBQ==
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=kEvys/5iZuzMUwavCLtmdEYomqRin0ImU1XAKMgL+p8=; b=MTsJGPM7BM+UItzoDs+MP/+RPF4uAwataxwg6S35ylMaflOYmr77Z+weWolTMEV2S1 LuMDNr3c09aaCY46qIIwKmY9AXvzGulAd2rHmof0cJihWhhLbk1Fw0HDpBtuALcE13iB kkG1u4I6aJdY0VJxmKyWPK2uL9sgF1hh944Xj2KtHf9UAa9F5sprur0kMDpWNoCxuSFZ 065Iyol0xIU06kWs+2nzkB/N88GkEXUn8bYkUjJTi/WFulOOF1SqNqGli4T8JW8aYkA2 2uDNb5j2BPs1aKVLVtuSU99BIKmC+iPA1P+V0PG6/XjjdENgPoXzZgWsMdkeyRIUihKx +MQA==
X-Gm-Message-State: ALoCoQkIG6fVy3TpTadUDzKw93dQYESCmd3X4Sa7N4Pcij+Hacahar7lZo6GbA3ZeHP9cHcDnFOe
MIME-Version: 1.0
X-Received: by 10.25.33.195 with SMTP id h186mr3436611lfh.123.1445432874123; Wed, 21 Oct 2015 06:07:54 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 21 Oct 2015 06:07:53 -0700 (PDT)
In-Reply-To: 
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com> <5627823A.80908@ericsson.com>  
Date: Wed, 21 Oct 2015 06:07:53 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a114114c402638e05229d11d6
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 13:08:07 -0000

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

On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka  wrote:

>
> > On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> >
> > Hi,
> >
> > IMO we do not need lots of rules for when-stmt.
> > They are harder to enforce than just implementing the auto-deletion.
> >
> > Note that auto-deletion also applies to nodes already in candidate or
> running.
> > It is just a derivative case to have a newly-created node deleted right
> away.
> > If you add node /foo it may cause node /bar and node /baz to get deleted.
> >
> > I strongly object to treating a false when-stmt in a datastore validation
> > as an error.  This is not how YANG 1.0 works, and this is not
> > backward-compatible.
>
> I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020
> correctly describes this auto-deletion behaviour for "choice" in sec. 7.9.6
> NETCONF  Operations. It is indeed protocol business - YANG
> spec should just define what's valid and what isn't.
>
> IMO RESTCONF spec doesn't require auto-deletion.
>
>

Our server uses the same validation engine for both protocols.
RESTCONF does not change the behavior of YANG in any way.
I don't see how YANG validation procedures would not apply to RESTCONF.

YANG says that the node semantics apply IFF the when-stmt evaluates to true.
It is up to the implementation to enforce that.  It applies to
server-created
nodes or nodes created via some protocol.


Lada
>

Andy


>
> >
> >
> > Andy
> >
> >
> > On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
> > Hello Martin,
> > I would want to codify this. My earlier proposal was:
> >
> > - when MUST NOT be dependent on a data node controlled by a when or
> choice statement
> >
> > Notice the strong MUST NOT statement. This would simplify life greatly.
> > regards Balazs
> >
> > On 2015-10-20 10:09, Martin Bjorklund wrote:
> > I have never seen anyone trying to refer to the conditional nodes in a
> > when expression - simply b/c it doesn't make any sense.
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 21 Oct 2015, at 14:33, Andy Bierman <andy@yumaworks.com> wrote:

>

> Hi,

>

> IMO we do not need lots of rules for when-stmt.

> They are harder to enforce than just implementing the auto-deletion.
>

> Note that auto-deletion also applies to nodes already in candidate or =
running.

> It is just a derivative case to have a newly-created node deleted righ=
t away.

> If you add node /foo it may cause node /bar and node /baz to get delet=
ed.

>

> I strongly object to treating a false when-stmt in a datastore validat=
ion

> as an error.=C2=A0 This is not how YANG 1.0 works, and this is not

> backward-compatible.



I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 corr=
ectly describes this auto-deletion behaviour for "choice" in sec.=
 7.9.6 NETCONF <edit-config> Operations. It is indeed protocol busine=
ss - YANG spec should just define what's valid and what isn't.



IMO RESTCONF spec doesn't require auto-deletion.




Our server uses the sam=
e validation engine for both protocols.
RESTCONF does not change =
the behavior of YANG in any way.
I don't see how YANG validat=
ion procedures would not apply to RESTCONF.

YANG s=
ays that the node semantics apply IFF the when-stmt evaluates to true.
It is up to the implementation to enforce that.=C2=A0 It applies to s=
erver-created
nodes or nodes created via some protocol.



Lada

Andy
=C2=A0



>

>

> Andy

>

>

> On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> Hello Martin,

> I would want to codify this. My earlier proposal was:

>

> - when MUST NOT be dependent on a data node controlled by a when or ch=
oice statement

>

> Notice the strong MUST NOT statement. This would simplify life greatly=
.

> regards Balazs

>

> On 2015-10-20 10:09, Martin Bjorklund wrote:

> I have never seen anyone trying to refer to the conditional nodes in a=


> when expression - simply b/c it doesn't make any sense.

>

> --

> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> Senior Specialist

> ECN: 831 7320

> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 email: Balazs.Lengyel@er=
icsson.com

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a114114c402638e05229d11d6--


From nobody Wed Oct 21 06:22:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0FB1A8025 for ; Wed, 21 Oct 2015 06:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqQCNzeKiV6d for ; Wed, 21 Oct 2015 06:22:21 -0700 (PDT)
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 65A9B1A7032 for ; Wed, 21 Oct 2015 06:22:21 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd] (unknown [IPv6:2001:718:1a02:1:38e4:f37d:433d:89fd]) by mail.nic.cz (Postfix) with ESMTPSA id D7115181933; Wed, 21 Oct 2015 15:22:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445433739; bh=7XRMfXkW46G5jNhf5dFNDX6x/xsIuZYXNpXvN/NBopA=; h=From:Date:To; b=ALO2TiXXDk/yrNjWYV8aaLQmgRkEDlTZrEXnf6EJ/Yv1rOrVmwkyz8dkoB7sHg55U mGaPu1k8h542bEM8Z6I/cWrjb0OQgcaryBn3tkTLlLp0VFHzqeeWnt0/EElbpXd9xD bjDuKDwDRW/pvb9v43WUCc3edq9hXbhvWB5BFUiI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 21 Oct 2015 15:22:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <11F87652-E95C-43D5-8950-E615E6FB1ED1@nic.cz>
References: <20151019190432.GB81250@elstar.local>   <20151020.100942.1499503452934383865.mbj@tail-f.com> <5627823A.80908@ericsson.com>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 13:22:23 -0000

> On 21 Oct 2015, at 15:07, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> >
> > Hi,
> >
> > IMO we do not need lots of rules for when-stmt.
> > They are harder to enforce than just implementing the auto-deletion.
> >
> > Note that auto-deletion also applies to nodes already in candidate =
or running.
> > It is just a derivative case to have a newly-created node deleted =
right away.
> > If you add node /foo it may cause node /bar and node /baz to get =
deleted.
> >
> > I strongly object to treating a false when-stmt in a datastore =
validation
> > as an error.  This is not how YANG 1.0 works, and this is not
> > backward-compatible.
>=20
> I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 =
correctly describes this auto-deletion behaviour for "choice" in sec. =
7.9.6 NETCONF  Operations. It is indeed protocol business - =
YANG spec should just define what's valid and what isn't.
>=20
> IMO RESTCONF spec doesn't require auto-deletion.
>=20
>=20
>=20
> Our server uses the same validation engine for both protocols.
> RESTCONF does not change the behavior of YANG in any way.
> I don't see how YANG validation procedures would not apply to =
RESTCONF.

The validation procedure does apply (the notion of a valid data tree has =
to be the same) but auto-deletion doesn't because it is specified in =
"NETCONF  ..." sections (7.9.6 and 8.3.2), and RESTCONF =
doesn't use .

>=20
> YANG says that the node semantics apply IFF the when-stmt evaluates to =
true.
> It is up to the implementation to enforce that.  It applies to =
server-created
> nodes or nodes created via some protocol.

Yes, but it can be enforced either by auto-deleting offending nodes, or =
by refusing to accept changes that lead to an invalid configuration.

Lada

>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> > Andy
> >
> >
> > On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel =
 wrote:
> > Hello Martin,
> > I would want to codify this. My earlier proposal was:
> >
> > - when MUST NOT be dependent on a data node controlled by a when or =
choice statement
> >
> > Notice the strong MUST NOT statement. This would simplify life =
greatly.
> > regards Balazs
> >
> > On 2015-10-20 10:09, Martin Bjorklund wrote:
> > I have never seen anyone trying to refer to the conditional nodes in =
a
> > when expression - simply b/c it doesn't make any sense.
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

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





From nobody Wed Oct 21 06:27:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A7A1A8712; Wed, 21 Oct 2015 06:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.59
X-Spam-Level: 
X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS6y4aeAu4f3; Wed, 21 Oct 2015 06:27:01 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176051A8711; Wed, 21 Oct 2015 06:26:59 -0700 (PDT)
Received: from [2601:681:201:5165:3c38:7adb:87c3:3db8] (helo=piccolo.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZotPX-00067T-V5; Wed, 21 Oct 2015 14:26:36 +0100
Date: Wed, 21 Oct 2015 07:26:49 -0600
From: Rob Shakir 
To: "Acee Lindem (acee)" , Ladislav Lhotka 
Message-ID: 
In-Reply-To: 
References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz>      
X-Mailer: Airmail Beta (334)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56279299_465d6579_12fd"
Archived-At: 
Cc: Routing YANG , "=?utf-8?Q?i2rs=40ietf.org?=" , NETMOD WG , Routing WG 
Subject: Re: [netmod] rib-data-model and routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 13:27:02 -0000

--56279299_465d6579_12fd
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 15 October 2015 at 15:13:38, Acee Lindem (acee) (acee@cisco.com) wrote:

Do we really see associating the same interface with different 
routing-instances for IPv4 and IPv6? I can seem to remember the use case 
and it does add complexity forever. 


At least two of the operators for whom I have worked utilise this functionality (providing separate L3VPNs for IPv6 and IPv4) - so in my experience, it is not possible to make this simplification.

r.


--56279299_465d6579_12fd
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


A theme t=
hat appears to have been running through the discussion of languages like Y=
ANG since (at least) 2007 (see draft-schoenw-sming-lessons-01, section 3.1)=
 is that =E2=80=9Cpreference should be give to solutions that simplify the =
task of readers.=C2=A0 Reduction of the efforts required by writers is of s=
econdary importance and the reduction of the efforts required by tool devel=
opers is of least important preference.=E2=80=9D However, it sounds as thou=
gh =E2=80=9Cwhen=E2=80=9D auto-deletion complicates the task for both reade=
rs (e.g. network operators) and tool developers.
 
Jonathan
 
 

From=
: Ladislav Lhotka
Sent: 26 October 2015 10:54
To: A=
ndy Bierman;Juergen Schoenwaelder;Andy Bierman;Martin Bjorklund;Balazs Leng=
yel;netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for=
 when?
 
 
Andy Bierman <andy@yumaworks.com> write=
s:
 
> H=
i,
> 
&g=
t; I buy Martin's argument that "when" stmt is like "choice&=
quot;.
> The draft says exactly what will happen=
 if the constraint
> is not satisfied.=C2=A0 Why=
 don't we require the client to delete
> the old=
 case and create the new case all at once?
> 
> The "when" auto-deleti=
on is no less scary then "case" auto-deletion.
 
Correct.
 
> It has the exact same =
ripple effects.=C2=A0 For that matter, if a client
=
> incorrectly deletes a trunk interface, scary things will happen as wel=
l.
> So why don't we take out the "delete&q=
uot; command?
 
In a delete command, the client has to explicitly identify the node to=

be deleted. With auto-deletion this is not the cas=
e.
 
> A=
 buggy client may get *any* of the commands wrong, so
> better take out all editing commands to protect everyone..
 
It's vulnerable n=
ot only to bugs in client or server code but also to
human errors - an operator might not fully understand the contrived logic=

of the data model.
&n=
bsp;
Lada
 =

> 
> 
> 
> Andy
> <=
/p>
> 
><=
o:p> 
> On Fri, Oct 23, 2015 at 3:09 =
PM, Juergen Schoenwaelder <
> j.schoenwaelder=
@jacobs-university.de> wrote:
> 
>> On Fri, Oct 23, 2015 at 02:42:26PM -07=
00, Andy Bierman wrote:
>> 
>> > Auto-deletion avoids forcing the clien=
t to make multiple edits,
>> > possibly le=
aving the datastore in a vulnerable state in between
>> > edits.
>> 
>> A single edit can say 'delete this, add that=
' and then you validate
>> the result. This i=
s simple to understand and matches the behaviour of
>> other systems people are familiar with. I do not buy your 'vulner=
able
>> state in between argument'. If the cl=
ient prefers to send multiple
>> edits, it be=
tter uses locks anyway.
>> 
>> Right now, we seem to accept 'add that' and=
 when validation of the
>> result fails, the =
server is expected to try 'delete that' in an
>&=
gt; attempt to restore happiness. And this try 'delete that' can have
>> ripple effects. A validate operation that chang=
es was is being
>> validated is scary. Its li=
ke pyang modifying foo.yang while parsing it
>&g=
t; in an attempt to finish without parsing errors...
>> 
>> /js
>> 
>> --=

>> Juergen Schoenwaelder=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:=C2=A0=C2=A0 +49 421 200 3103=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.jacobs-university.de/&g=
t;
>> 
 
-- 
Lad=
islav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
<=
p class=3DMsoNormal> 
_____________=
__________________________________
netmod mailing l=
ist
netmod@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/netmod
 
 
=

--_E8C28FAA-DEC9-44A3-ACE6-FB38CA58DE58_--


From nobody Mon Oct 26 05:48:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F21B3D56 for ; Mon, 26 Oct 2015 05:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfcpBNhKYSh6 for ; Mon, 26 Oct 2015 05:48:40 -0700 (PDT)
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 4767A1B3D54 for ; Mon, 26 Oct 2015 05:48:40 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:868:5f1a:f06b:8a44] (unknown [IPv6:2a01:5e0:29:ffff:868:5f1a:f06b:8a44]) by mail.nic.cz (Postfix) with ESMTPSA id E373D181736; Mon, 26 Oct 2015 13:48:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445863719; bh=eV4Tf4+TeXENW0YoxLlKpV4UD40L33N8JN/DKkfUC38=; h=From:Date:To; b=ejFMTfT4gJ+goEsQjWCOFU/FaliD0GYUbw+RNjlwMfJcD0KtAfki/nTwiEI4kZtsn FvaWHeh6GteepI0hS6kPkJ6q25DVCuWpKNL2X0VcMJv4BCZ4KZRrtEMhQzxe2NfhoS OQQQcxpZIdQ3pHbejo/KjtTKoueh1jmUUL2ktvUg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Ladislav Lhotka 
In-Reply-To: <20151026.125502.2085524998185413165.mbj@tail-f.com>
Date: Mon, 26 Oct 2015 13:48:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <89522132-81E1-4A75-97A2-2FB342FF8BFA@nic.cz>
References: <20151023203615.GA33907@elstar.local> <20151024.150741.949892500214874951.mbj@tail-f.com> <20151026094206.GA42627@elstar.local> <20151026.125502.2085524998185413165.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3096.5)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 12:48:42 -0000

> On 26 Oct 2015, at 12:55, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder  wrote:
>> On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wrote:
>>>>> Martin Bjorklund  writes:
>>>>>=20
>>>>>> auto-deletion in choice/when should be described as a property of =
the
>>>>>> data model for the datastore.  Parts of the text from Section =
8.2.2
>>>>>> should be made more generic and moved, probably to a new section
>>>>>> 8.1.1.   I will have a look at this.
>>>>=20
>>>> [...]
>>>>=20
>>>>> IMO YANG spec should tell what's valid and what isn't, and stop =
there.
>>>>=20
>>>> As technical contributor, I tend to agree. The purpose of =
validation
>>>> should be to return a boolean - datastore is valid or invalid.
>>>=20
>>> Right.  This is what "must" does.  "when" is different.  If a node's
>>> "when" expression becomes false, that node is deleted, and its other
>>> constraints are no longer used (e.g. must, mandatory etc).  These =
are
>>> two different use cases, two different tools available to the data
>>> model designer.
>>>=20
>>> If we put "when" to the side for a moment, do you also think that
>>> there should be no auto-deletion of cases in a choice?
>>=20
>> If I were to start from scratch, my answer would be most likely yes.
>>=20
>>> If this discussion had started from implementation/deployment
>>> experience that said that "when" could not be implemented or that it
>>> made it difficult to write NMS system or something else, things =
would
>>> be different.  But now we have a feature that has been in use for 5+
>>> years, and there are several implementations of it out there, and =
now
>>> we say that it should be removed?  Or worse, keep the syntax but
>>> radically change the semantics.
>>=20
>> Do independent implementations really behave the same? I am not sure,
>> the discussion around this makes me believe that it is somewhat =
likely
>> that they do not all do the same.
>=20
> Apart from the error reporting issue we have discussion, I think at
> least yuma and tail-f behave the same for the use cases that people
> actually use.  I'm sure we don't handle all these corner cases the
> same way, but this should be fixed by adjusting the code to match the
> new text in 6020bis.
>=20
>> Reading section 7.19.5 of RFC 6020 again, I do not find the =
auto-deletion
>> described.
>=20
> It is described in 8.3.2.
>=20
>> I do see auto-deletion defined in section 7.9.6 for
>> NETCONF's edit-config operation. (The text does not say anything =
about
>> what happens if an attempt is made to create multiple cases, I guess
>> it is implementation dependent which choice will become effective but
>> one might also consider this an error - but clearly this is not
>> defined). I note that RFC 6020bis has lifted this auto-deletion up
>> from being a NETCONF edit-config property to a property that applies
>> to all protocols. (It still does not define what happens if an edit
>> creates multiple case branches.)
>>=20
>> A proposal was made to declare "when" auto-deletion to be part of the
>> YANG data store validation process, that is, it applies to every
>> protocol interface. This means that a datastore not only needs to
>> maintain data that is being validated, it also needs to remember the
>> last edit (at least) in order to _guess_ what should be deleted =
during
>> validation.
>=20
> No guessing is involved.  If a node's when expression evaluates to
> false, it is deleted.

Are there any use cases where a client wants to send an edit that makes =
a "when" expression false, in order to remove the instance of the parent =
node, i.e. when it is not a mistake?

In the two use cases that Andy described it is probably not the case - =
e.g., changing the type of an interface in ietf-interfaces is IMO always =
an error, and changing the type of routing protocol in ietf-routing =
isn't possible at all because "type" is part of the list key.

Lada

>=20
>=20
> /martin

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





From nobody Mon Oct 26 08:10:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4F1B491E for ; Mon, 26 Oct 2015 08:10:38 -0700 (PDT)
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 NLqkQeVRrMmQ for ; Mon, 26 Oct 2015 08:10:33 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E85C1B48CF for ; Mon, 26 Oct 2015 08:10:18 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so117226473lfb.2 for ; Mon, 26 Oct 2015 08:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xefRJlxYtFGLWDccVkBgjW3M68p+SgNB61emFBNnM00=; b=M0HAne1UO5CxUSa00fR5AQKK2l9WJRXXR+iDAPMHGV2+79gwC8LLUJzEBiZH8rBaKw dGsXqq7NRbY3QnFcu5ehPN3qJ4Gi7intV7CERYSK5a3B5KdFRTTJ5kEUPN4ZKU7o4BIj kta4IGZyR15shRxPcPw6ZVEJTlODqewrHywWvUjuMjuV74c9h2PUFm4kIVoS1qCM64bt 2Myt73ywJ+Zf2Q/+yQpuJsHSxpchX5vpFLvz0JFAuftM16sk34fkX0RYwCT4YkOm06gg vQQBOyvIKo9XnublCxPY/3+ZnIb9n7Gg4Zt4lx0nXmhOnccMgjq7N1RdshioIWh5Eizn Cdxg==
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=xefRJlxYtFGLWDccVkBgjW3M68p+SgNB61emFBNnM00=; b=JGCL+C0AbpuLr6E4vCe8i/5WHwYbxfAxRCatP1I4r5/wNUgmRkeuKxAVxeHj95Z3tG uq9nJBpuYPkg7c9r0MFb3w3wXLkW2g+SW4B76XX//7G9bKUEil2ITIGHk1fIIWkqm4oN yxJglep73yGT1OgIyFndw1cyWrahkEl1yMfh6D98St+lLdSG3Eb9DSa/iUvo362fD5hc 5sRbCk9rBTz7yPneaVIfFxW14Dwcg/feiXKfD4INwxQfQyu2DfchDOs+/f8ZHz1ZJye7 NEAmyyiQ6PrVzxmmQUxvtcFedEhPpLiwMKHAG3654eyE8YqJ/t2+TVTuDCM94oy5Lt9T QbIg==
X-Gm-Message-State: ALoCoQnAmPseNMoScbQ5AJWi5Dp/e36Eerjou9BpP4iYFW+3/6BeMRYQMlDwshnlqO5IYH2D2wx5
MIME-Version: 1.0
X-Received: by 10.25.143.82 with SMTP id r79mr4277545lfd.123.1445872216370; Mon, 26 Oct 2015 08:10:16 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 26 Oct 2015 08:10:16 -0700 (PDT)
In-Reply-To: <20151026.125502.2085524998185413165.mbj@tail-f.com>
References: <20151023203615.GA33907@elstar.local> <20151024.150741.949892500214874951.mbj@tail-f.com> <20151026094206.GA42627@elstar.local> <20151026.125502.2085524998185413165.mbj@tail-f.com>
Date: Mon, 26 Oct 2015 08:10:16 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11401b1ad90ff40523035bd3
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 15:10:38 -0000

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

On Mon, Oct 26, 2015 at 4:55 AM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wrote:
> > > > > Martin Bjorklund  writes:
> > > > >
> > > > > > auto-deletion in choice/when should be described as a property
> of the
> > > > > > data model for the datastore.  Parts of the text from Section
> 8.2.2
> > > > > > should be made more generic and moved, probably to a new section
> > > > > > 8.1.1.   I will have a look at this.
> > > >
> > > > [...]
> > > >
> > > > > IMO YANG spec should tell what's valid and what isn't, and stop
> there.
> > > >
> > > > As technical contributor, I tend to agree. The purpose of validation
> > > > should be to return a boolean - datastore is valid or invalid.
> > >
> > > Right.  This is what "must" does.  "when" is different.  If a node's
> > > "when" expression becomes false, that node is deleted, and its other
> > > constraints are no longer used (e.g. must, mandatory etc).  These are
> > > two different use cases, two different tools available to the data
> > > model designer.
> > >
> > > If we put "when" to the side for a moment, do you also think that
> > > there should be no auto-deletion of cases in a choice?
> >
> > If I were to start from scratch, my answer would be most likely yes.
> >
> > > If this discussion had started from implementation/deployment
> > > experience that said that "when" could not be implemented or that it
> > > made it difficult to write NMS system or something else, things would
> > > be different.  But now we have a feature that has been in use for 5+
> > > years, and there are several implementations of it out there, and now
> > > we say that it should be removed?  Or worse, keep the syntax but
> > > radically change the semantics.
> >
> > Do independent implementations really behave the same? I am not sure,
> > the discussion around this makes me believe that it is somewhat likely
> > that they do not all do the same.
>
> Apart from the error reporting issue we have discussion, I think at
> least yuma and tail-f behave the same for the use cases that people
> actually use.  I'm sure we don't handle all these corner cases the
> same way, but this should be fixed by adjusting the code to match the
> new text in 6020bis.
>
>

Some of the new text that has been discussed in not implementable.
For example, there are no tools that take an arbitrary set of XPath
expressions
against the same XML instance document, and determine which order
(if any) is the one true correct order that must be used.  Requirements
like this in YANG 1.1 are just not implementable.

The "when" statement is the sharpest knife in the drawer.
If it is too complicated to get right, then it will be
used incorrectly.  Same as the "pattern" statement.
We get those wrong all the time and fix them in Errata.
That doesn't seem to be a problem.  I don't hear calls to
remove pattern-stmt because he syntax is really hard.

We are not going to spend any time coding for
clever corner-cases.  We do spend time coding for use-cases.
I agree the interoperability for use-cases is quite acceptable.
All this fuss over corner-cases is not that interesting.


Andy



> > Reading section 7.19.5 of RFC 6020 again, I do not find the auto-deletion
> > described.
>
> It is described in 8.3.2.
>
> > I do see auto-deletion defined in section 7.9.6 for
> > NETCONF's edit-config operation. (The text does not say anything about
> > what happens if an attempt is made to create multiple cases, I guess
> > it is implementation dependent which choice will become effective but
> > one might also consider this an error - but clearly this is not
> > defined). I note that RFC 6020bis has lifted this auto-deletion up
> > from being a NETCONF edit-config property to a property that applies
> > to all protocols. (It still does not define what happens if an edit
> > creates multiple case branches.)
> >
> > A proposal was made to declare "when" auto-deletion to be part of the
> > YANG data store validation process, that is, it applies to every
> > protocol interface. This means that a datastore not only needs to
> > maintain data that is being validated, it also needs to remember the
> > last edit (at least) in order to _guess_ what should be deleted during
> > validation.
>
> No guessing is involved.  If a node's when expression evaluates to
> false, it is deleted.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Oct 26, 2015 at 4:55 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Juergen Schoenwaelder <=
j.schoenwaelder@jac=
obs-university.de> wrote:

> On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:

> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> > > On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wr=
ote:

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

> > > >

> > > > > auto-deletion in choice/when should be described a=
s a property of the

> > > > > data model for the datastore.=C2=A0 Parts of the t=
ext from Section 8.2.2

> > > > > should be made more generic and moved, probably to=
 a new section

> > > > > 8.1.1.=C2=A0 =C2=A0I will have a look at this.

> > >

> > > [...]

> > >

> > > > IMO YANG spec should tell what's valid and what isn=
't, and stop there.

> > >

> > > As technical contributor, I tend to agree. The purpose of va=
lidation

> > > should be to return a boolean - datastore is valid or invali=
d.

> >

> > Right.=C2=A0 This is what "must" does.=C2=A0 "when=
" is different.=C2=A0 If a node's

> > "when" expression becomes false, that node is deleted, =
and its other

> > constraints are no longer used (e.g. must, mandatory etc).=C2=A0 =
These are

> > two different use cases, two different tools available to the dat=
a

> > model designer.

> >

> > If we put "when" to the side for a moment, do you also =
think that

> > there should be no auto-deletion of cases in a choice?

>

> If I were to start from scratch, my answer would be most likely yes.
>

> > If this discussion had started from implementation/deployment

> > experience that said that "when" could not be implement=
ed or that it

> > made it difficult to write NMS system or something else, things w=
ould

> > be different.=C2=A0 But now we have a feature that has been in us=
e for 5+

> > years, and there are several implementations of it out there, and=
 now

> > we say that it should be removed?=C2=A0 Or worse, keep the syntax=
 but

> > radically change the semantics.

>

> Do independent implementations really behave the same? I am not sure,<=
br>
> the discussion around this makes me believe that it is somewhat likely=


> that they do not all do the same.



Apart from the error reporting issue we have discussion, I think at

least yuma and tail-f behave the same for the use cases that people

actually use.=C2=A0 I'm sure we don't handle all these corner cases=
 the

same way, but this should be fixed by adjusting the code to match the

new text in 6020bis.




Some of the new text th=
at has been discussed in not implementable.
For example, there ar=
e no tools that take an arbitrary set of XPath expressions
agains=
t the same XML instance document, and determine which order
(if a=
ny) is the one true correct order that must be used.=C2=A0 Requirements
like this in YANG 1.1 are just not implementable.

The "when" statement is the sharpest knife in the drawer.<=
/div>
If it is too complicated to get right, then it will be
=
used incorrectly.=C2=A0 Same as the "pattern" statement.
We get those wrong all the time and fix them in Errata.
That do=
esn't seem to be a problem.=C2=A0 I don't hear calls to
r=
emove pattern-stmt because he syntax is really hard.

We are not going to spend any time coding for
clever corner-ca=
ses.=C2=A0 We do spend time coding for use-cases.
I agree the int=
eroperability for use-cases is quite acceptable.
All this fuss ov=
er corner-cases is not that interesting.


Andy

=C2=A0

> Reading section 7.19.5 of RFC 6020 again, I do not find the auto-delet=
ion

> described.



It is described in 8.3.2.



> I do see auto-deletion defined in section 7.9.6 for

> NETCONF's edit-config operation. (The text does not say anything a=
bout

> what happens if an attempt is made to create multiple cases, I guess
> it is implementation dependent which choice will become effective but<=
br>
> one might also consider this an error - but clearly this is not

> defined). I note that RFC 6020bis has lifted this auto-deletion up

> from being a NETCONF edit-config property to a property that applies
> to all protocols. (It still does not define what happens if an edit
> creates multiple case branches.)

>

> A proposal was made to declare "when" auto-deletion to be pa=
rt of the

> YANG data store validation process, that is, it applies to every

> protocol interface. This means that a datastore not only needs to

> maintain data that is being validated, it also needs to remember the
> last edit (at least) in order to _guess_ what should be deleted during=


> validation.



No guessing is involved.=C2=A0 If a node's when expression evaluates to=


false, it is deleted.





/martin



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11401b1ad90ff40523035bd3--


From nobody Mon Oct 26 08:50:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530711B4D51 for ; Mon, 26 Oct 2015 08:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.311
X-Spam-Level: 
X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIV-7XZixbbh for ; Mon, 26 Oct 2015 08:50:46 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FA91B4D4F for ; Mon, 26 Oct 2015 08:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2822; q=dns/txt; s=iport; t=1445874646; x=1447084246; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=W8UyZs9RXSmtiy7CksDnqPbC21in+1PP5V3q79hJYIg=; b=fSyXGMvcoPUIl4qyZutKKZTwqmIan/1Uf7EALUvlSqXwg1PcMKmC6LZl RPbsg1ynXvegiTldBnLLeYxYz0En5OGxrJIGfQbQU4D3HCyeP52lFEF85 rqi1jxw3Oew2WxXkgQjU5A/+Y5s2fi8sI2HV8ihnVvaRQgsv6MnhrtheG I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CmBACZSy5W/xbLJq1VCcUmiBwBAQEBAQGBAAuEXBVANgIFFgsCCwMCAQIBSw0IAQGILKJrj3GSCQEBAQcCASCBIoVVhH6EMYNMgUUFkmKDVHuMJ4kZkxZjhAM+h0wBAQE
X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="scan'208";a="605925208"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2015 15:50:25 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9QFoPks025171 for ; Mon, 26 Oct 2015 15:50:25 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <562E4BA9.4060106@cisco.com>
Date: Mon, 26 Oct 2015 15:50:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 15:50:48 -0000

Hi,

Last week I posted slightly revised version of both 
draft-wilton-netmod-intf-ext-yang-01 and 
draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the 
models contained within these two drafts is very welcome, but I would be 
particularly interested in any opinions regarding some slight changes 
for modelling sub-interfaces in the interfaces-extensions draft.

The main changes that I've made to intf-ext-yang-01 are:

1) I've defined a new "sub-interface" identity to represent the 
behaviour of any interface type that is a representation of a 
sub-interface.  The idea here is to ensure that the common sub-interface 
configuration leaves can be re-used by any other sub-interface types 
that are defined in future models, or possibly vendor specific interface 
types. E.g. the augmentation that adds sub-interface related 
configuration in interfaces-common.yang:


   identity sub-interface {
     description "Base type for generic sub-interfaces.  New or custom
                  interface types can derive from this type to
                  inherit generic sub-interface configuration";
   }

   augment "/if:interfaces/if:interface" {
     when "derived-from(if:type,
                        'ietf-if-cmn',
                        'sub-interface') or
           if:type = 'ianaift:atmSubInterface' or
           if:type = 'ianaift:frameRelay'"  {
       description
         "Any ianaift:types that explicitly represent sub-interfaces
          or any types that derive from the sub-interface identity";
     }

     ... sub-interface specific configuration nodes go here.
   }


If this is accepted as generally a good approach of modelling this in a 
future safe manner, then I was considering also defining an interface 
type that is the common representation of a physical- interfaces for 
some of the other features defined in the interface-extension draft.


2) I've defined a new ethSubInterface identity in interface-common.yang 
that inherits from ianaift:l2vlan and the new sub-interface identity above.
  - Using Yang 1.1 this will allow the augmentation of the 
parent-interface leaf to be marked as mandatory.
  - It also solves a possible concern that some vendors may have a 
different interpretation of what the IANA interface type "l2vlan" 
actually means (noting that the IANA only provides a slightly vague 
definition).

I.e.

   identity ethSubInterface{
     base ianaift:l2vlan;
     base sub-interface;

     description "Sub-interface of any interface types that uses
                  Ethernet framing (with or without 802.1Q tagging)";
   }


3) The features above mean that module is marked a being Yang version 
1.1 only.

Any feedback is appreciated.

Thanks,
Rob


From nobody Mon Oct 26 08:57:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543921B4333 for ; Mon, 26 Oct 2015 08:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abIVSzYSejiv for ; Mon, 26 Oct 2015 08:57:38 -0700 (PDT)
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 070C91B4331 for ; Mon, 26 Oct 2015 08:57:38 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:d0ad:8578:9347:22a9] (unknown [IPv6:2a01:5e0:29:ffff:d0ad:8578:9347:22a9]) by mail.nic.cz (Postfix) with ESMTPSA id 7BBFE181893; Mon, 26 Oct 2015 16:57:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445875056; bh=fTkfWqdzMBq/M5ewdodjqFlDZRPeQJ1epPM/6PPpNwI=; h=From:Date:To; b=nyCghjYXJ1PjSUvqbQry3XYGwpm05lGF+iW24Fk6xTz+BKUNzqs2+INasW8RXEjJ0 Kl0mlu+p8AytWuLw78tgIgvw90cv8KGUf31Wa8hEGpnljm2vVxFqEqckjL/0QqNIl9 QfEXbLVRtnUmotycsMS4doDqLZZ+0Si0P5fOY5Kk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 26 Oct 2015 16:57:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20151023203615.GA33907@elstar.local> <20151024.150741.949892500214874951.mbj@tail-f.com> <20151026094206.GA42627@elstar.local> <20151026.125502.2085524998185413165.mbj@tail-f.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3096.5)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 15:57:40 -0000

> On 26 Oct 2015, at 16:10, Andy Bierman  wrote:
>=20
>=20
>=20
> On Mon, Oct 26, 2015 at 4:55 AM, Martin Bjorklund  =
wrote:
> Juergen Schoenwaelder  wrote:
> > On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  =
wrote:
> > > > On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wrote:
> > > > > Martin Bjorklund  writes:
> > > > >
> > > > > > auto-deletion in choice/when should be described as a =
property of the
> > > > > > data model for the datastore.  Parts of the text from =
Section 8.2.2
> > > > > > should be made more generic and moved, probably to a new =
section
> > > > > > 8.1.1.   I will have a look at this.
> > > >
> > > > [...]
> > > >
> > > > > IMO YANG spec should tell what's valid and what isn't, and =
stop there.
> > > >
> > > > As technical contributor, I tend to agree. The purpose of =
validation
> > > > should be to return a boolean - datastore is valid or invalid.
> > >
> > > Right.  This is what "must" does.  "when" is different.  If a =
node's
> > > "when" expression becomes false, that node is deleted, and its =
other
> > > constraints are no longer used (e.g. must, mandatory etc).  These =
are
> > > two different use cases, two different tools available to the data
> > > model designer.
> > >
> > > If we put "when" to the side for a moment, do you also think that
> > > there should be no auto-deletion of cases in a choice?
> >
> > If I were to start from scratch, my answer would be most likely yes.
> >
> > > If this discussion had started from implementation/deployment
> > > experience that said that "when" could not be implemented or that =
it
> > > made it difficult to write NMS system or something else, things =
would
> > > be different.  But now we have a feature that has been in use for =
5+
> > > years, and there are several implementations of it out there, and =
now
> > > we say that it should be removed?  Or worse, keep the syntax but
> > > radically change the semantics.
> >
> > Do independent implementations really behave the same? I am not =
sure,
> > the discussion around this makes me believe that it is somewhat =
likely
> > that they do not all do the same.
>=20
> Apart from the error reporting issue we have discussion, I think at
> least yuma and tail-f behave the same for the use cases that people
> actually use.  I'm sure we don't handle all these corner cases the
> same way, but this should be fixed by adjusting the code to match the
> new text in 6020bis.
>=20
>=20
>=20
> Some of the new text that has been discussed in not implementable.
> For example, there are no tools that take an arbitrary set of XPath =
expressions
> against the same XML instance document, and determine which order
> (if any) is the one true correct order that must be used.  =
Requirements
> like this in YANG 1.1 are just not implementable.

And even if it is implementable, it would be terribly expensive.

>=20
> The "when" statement is the sharpest knife in the drawer.
> If it is too complicated to get right, then it will be
> used incorrectly.  Same as the "pattern" statement.
> We get those wrong all the time and fix them in Errata.
> That doesn't seem to be a problem.  I don't hear calls to
> remove pattern-stmt because he syntax is really hard.

The difference is that efficient algorithms are available for regex =
matching, and there are no dark corners.
So a pattern may not do exactly what it was intended for but it should =
never cause the server or client software to fail or accidentally erase =
some data.

>=20
> We are not going to spend any time coding for
> clever corner-cases.  We do spend time coding for use-cases.
> I agree the interoperability for use-cases is quite acceptable.
> All this fuss over corner-cases is not that interesting.

I think it is only matter of time when such corner cases show up in the =
wild. People like to use sharp knives.

Lada=20

>=20
>=20
> Andy
>=20
> =20
> > Reading section 7.19.5 of RFC 6020 again, I do not find the =
auto-deletion
> > described.
>=20
> It is described in 8.3.2.
>=20
> > I do see auto-deletion defined in section 7.9.6 for
> > NETCONF's edit-config operation. (The text does not say anything =
about
> > what happens if an attempt is made to create multiple cases, I guess
> > it is implementation dependent which choice will become effective =
but
> > one might also consider this an error - but clearly this is not
> > defined). I note that RFC 6020bis has lifted this auto-deletion up
> > from being a NETCONF edit-config property to a property that applies
> > to all protocols. (It still does not define what happens if an edit
> > creates multiple case branches.)
> >
> > A proposal was made to declare "when" auto-deletion to be part of =
the
> > YANG data store validation process, that is, it applies to every
> > protocol interface. This means that a datastore not only needs to
> > maintain data that is being validated, it also needs to remember the
> > last edit (at least) in order to _guess_ what should be deleted =
during
> > validation.
>=20
> No guessing is involved.  If a node's when expression evaluates to
> false, it is deleted.
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Mon Oct 26 09:14:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A2A1B48DD for ; Mon, 26 Oct 2015 09:14:37 -0700 (PDT)
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 cYiO4jzhjSox for ; Mon, 26 Oct 2015 09:14:35 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4631B4C9E for ; Mon, 26 Oct 2015 09:14:34 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so119856115lfb.2 for ; Mon, 26 Oct 2015 09:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wardrNa8Y/CaLpKYkMFH75F24hqnXKhUDPp9que2eRY=; b=QzQ7xoJyGlVx2TbUrtXEgk3D4zkt6wN/xgz2so+kSruMV4IDA5SpyKZShjAQ5s8Ew8 DmrcHpOXIGqcMeV7AJasL5jAjhY8Z1FACtFuO8hC3qXyW0J4vOEZF7W92ea1GheQZUlt rCHFni28oPCxicRgUHBHKkw9nMAWJeaRHEGEC9IzW16mDqWpBV0ayI/kDUBaOBVWrWgx c7LyarRYF4Re9FqsePv8XitdEZtW4biqPhhidaH8T7m+a9qxXlDnRh2u7X44gC0MzhT5 17lgOGCIL8CyLGuyfrJJvbJVsDu2chODkRoVYkOGzgbyhgYmHeww91d3bggIlnuBOzY/ Js0A==
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=wardrNa8Y/CaLpKYkMFH75F24hqnXKhUDPp9que2eRY=; b=ZiQ+rNOkNqYrcbY4ft5h3mijEA4vvTmnITaZIZCT+KfKrYDyqg1lcb1hDRF5rnn9b0 CegggmZd+5cfwRXdH7ZHYNMKKD5f2jmtzNBNaE3gyciMxin5xQzKkL88Fy0cE2Txhlg4 78An07FFFEFdaAzfkL9hYI4ZRCJG7ILl4t+EHwM4DkWatLkpPWS+f64Iad9U4ZF/SZ+v tP8ZUCrWqE1oPO0JEN04caFiTaaN9VDDrEaygBY0C6H1kkiJgCwn5V7n5Wi9y3zpVdlJ WW2CubgBQIOzwxSi+h0tSoDS4Tjh4Z1HxIfYWIja9LeYytUsJ21SEspCu6cy2qyhKfV6 qDdQ==
X-Gm-Message-State: ALoCoQkUBCX7P7kLnzD9hcuajVC7sC6uSsboNMMiqPdvjR8B/B6xct/OwuFovCVA+Hi94c9bvAqn
MIME-Version: 1.0
X-Received: by 10.25.153.18 with SMTP id b18mr7844670lfe.33.1445876072556; Mon, 26 Oct 2015 09:14:32 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 26 Oct 2015 09:14:32 -0700 (PDT)
In-Reply-To: 
References: <20151023203615.GA33907@elstar.local> <20151024.150741.949892500214874951.mbj@tail-f.com> <20151026094206.GA42627@elstar.local> <20151026.125502.2085524998185413165.mbj@tail-f.com>  
Date: Mon, 26 Oct 2015 09:14:32 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a114730c0b1c62305230441b5
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Order of evaluation for when?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 16:14:37 -0000

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

On Mon, Oct 26, 2015 at 8:57 AM, Ladislav Lhotka  wrote:

>
> > On 26 Oct 2015, at 16:10, Andy Bierman  wrote:
> >
> >
> >
> > On Mon, Oct 26, 2015 at 4:55 AM, Martin Bjorklund 
> wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder  wrote:
> > > > > On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wrote:
> > > > > > Martin Bjorklund  writes:
> > > > > >
> > > > > > > auto-deletion in choice/when should be described as a property
> of the
> > > > > > > data model for the datastore.  Parts of the text from Section
> 8.2.2
> > > > > > > should be made more generic and moved, probably to a new
> section
> > > > > > > 8.1.1.   I will have a look at this.
> > > > >
> > > > > [...]
> > > > >
> > > > > > IMO YANG spec should tell what's valid and what isn't, and stop
> there.
> > > > >
> > > > > As technical contributor, I tend to agree. The purpose of
> validation
> > > > > should be to return a boolean - datastore is valid or invalid.
> > > >
> > > > Right.  This is what "must" does.  "when" is different.  If a node's
> > > > "when" expression becomes false, that node is deleted, and its other
> > > > constraints are no longer used (e.g. must, mandatory etc).  These are
> > > > two different use cases, two different tools available to the data
> > > > model designer.
> > > >
> > > > If we put "when" to the side for a moment, do you also think that
> > > > there should be no auto-deletion of cases in a choice?
> > >
> > > If I were to start from scratch, my answer would be most likely yes.
> > >
> > > > If this discussion had started from implementation/deployment
> > > > experience that said that "when" could not be implemented or that it
> > > > made it difficult to write NMS system or something else, things would
> > > > be different.  But now we have a feature that has been in use for 5+
> > > > years, and there are several implementations of it out there, and now
> > > > we say that it should be removed?  Or worse, keep the syntax but
> > > > radically change the semantics.
> > >
> > > Do independent implementations really behave the same? I am not sure,
> > > the discussion around this makes me believe that it is somewhat likely
> > > that they do not all do the same.
> >
> > Apart from the error reporting issue we have discussion, I think at
> > least yuma and tail-f behave the same for the use cases that people
> > actually use.  I'm sure we don't handle all these corner cases the
> > same way, but this should be fixed by adjusting the code to match the
> > new text in 6020bis.
> >
> >
> >
> > Some of the new text that has been discussed in not implementable.
> > For example, there are no tools that take an arbitrary set of XPath
> expressions
> > against the same XML instance document, and determine which order
> > (if any) is the one true correct order that must be used.  Requirements
> > like this in YANG 1.1 are just not implementable.
>
> And even if it is implementable, it would be terribly expensive.
>
> >
> > The "when" statement is the sharpest knife in the drawer.
> > If it is too complicated to get right, then it will be
> > used incorrectly.  Same as the "pattern" statement.
> > We get those wrong all the time and fix them in Errata.
> > That doesn't seem to be a problem.  I don't hear calls to
> > remove pattern-stmt because he syntax is really hard.
>
> The difference is that efficient algorithms are available for regex
> matching, and there are no dark corners.
> So a pattern may not do exactly what it was intended for but it should
> never cause the server or client software to fail or accidentally erase
> some data.
>
>

If the regex test fails then the leaf or leaf-list will be rejected with
an invalid-value error.  If an invalid pattern passes then it will be
accepted as a valid string for that typedef.

This is bad enough but it can in turn cause ripple effects (e.g. leafref)
that are just as bad as deleting data that the when-stmt says is going
to be deleted.



> >
> > We are not going to spend any time coding for
> > clever corner-cases.  We do spend time coding for use-cases.
> > I agree the interoperability for use-cases is quite acceptable.
> > All this fuss over corner-cases is not that interesting.
>
> I think it is only matter of time when such corner cases show up in the
> wild. People like to use sharp knives.
>
>
And we fix then one at a time when they come up.
As the number of inter-connected modules grows the possibility
for when-stmt race conditions in real modules will also grow.
Hopefully YANG Doctors will be paying attention and identify problems
in IETF modules before they are published.



Lada
>


Andy


>
> >
> >
> > Andy
> >
> >
> > > Reading section 7.19.5 of RFC 6020 again, I do not find the
> auto-deletion
> > > described.
> >
> > It is described in 8.3.2.
> >
> > > I do see auto-deletion defined in section 7.9.6 for
> > > NETCONF's edit-config operation. (The text does not say anything about
> > > what happens if an attempt is made to create multiple cases, I guess
> > > it is implementation dependent which choice will become effective but
> > > one might also consider this an error - but clearly this is not
> > > defined). I note that RFC 6020bis has lifted this auto-deletion up
> > > from being a NETCONF edit-config property to a property that applies
> > > to all protocols. (It still does not define what happens if an edit
> > > creates multiple case branches.)
> > >
> > > A proposal was made to declare "when" auto-deletion to be part of the
> > > YANG data store validation process, that is, it applies to every
> > > protocol interface. This means that a datastore not only needs to
> > > maintain data that is being validated, it also needs to remember the
> > > last edit (at least) in order to _guess_ what should be deleted during
> > > validation.
> >
> > No guessing is involved.  If a node's when expression evaluates to
> > false, it is deleted.
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Mon, Oct 26, 2015 at 8:57 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 26 Oct 2015, at 16:10, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Mon, Oct 26, 2015 at 4:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> > On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote:=


> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhot=
ka wrote:

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

> > > > >

> > > > > > auto-deletion in choice/when should be descri=
bed as a property of the

> > > > > > data model for the datastore.=C2=A0 Parts of =
the text from Section 8.2.2

> > > > > > should be made more generic and moved, probab=
ly to a new section

> > > > > > 8.1.1.=C2=A0 =C2=A0I will have a look at this=
.

> > > >

> > > > [...]

> > > >

> > > > > IMO YANG spec should tell what's valid and wha=
t isn't, and stop there.

> > > >

> > > > As technical contributor, I tend to agree. The purpose =
of validation

> > > > should be to return a boolean - datastore is valid or i=
nvalid.

> > >

> > > Right.=C2=A0 This is what "must" does.=C2=A0 "=
;when" is different.=C2=A0 If a node's

> > > "when" expression becomes false, that node is dele=
ted, and its other

> > > constraints are no longer used (e.g. must, mandatory etc).=
=C2=A0 These are

> > > two different use cases, two different tools available to th=
e data

> > > model designer.

> > >

> > > If we put "when" to the side for a moment, do you =
also think that

> > > there should be no auto-deletion of cases in a choice?

> >

> > If I were to start from scratch, my answer would be most likely y=
es.

> >

> > > If this discussion had started from implementation/deploymen=
t

> > > experience that said that "when" could not be impl=
emented or that it

> > > made it difficult to write NMS system or something else, thi=
ngs would

> > > be different.=C2=A0 But now we have a feature that has been =
in use for 5+

> > > years, and there are several implementations of it out there=
, and now

> > > we say that it should be removed?=C2=A0 Or worse, keep the s=
yntax but

> > > radically change the semantics.

> >

> > Do independent implementations really behave the same? I am not s=
ure,

> > the discussion around this makes me believe that it is somewhat l=
ikely

> > that they do not all do the same.

>

> Apart from the error reporting issue we have discussion, I think at
> least yuma and tail-f behave the same for the use cases that people
> actually use.=C2=A0 I'm sure we don't handle all these corner =
cases the

> same way, but this should be fixed by adjusting the code to match the<=
br>
> new text in 6020bis.

>

>

>

> Some of the new text that has been discussed in not implementable.

> For example, there are no tools that take an arbitrary set of XPath ex=
pressions

> against the same XML instance document, and determine which order

> (if any) is the one true correct order that must be used.=C2=A0 Requir=
ements

> like this in YANG 1.1 are just not implementable.



And even if it is implementable, it would be terribly expensive.



>

> The "when" statement is the sharpest knife in the drawer.
> If it is too complicated to get right, then it will be

> used incorrectly.=C2=A0 Same as the "pattern" statement.

> We get those wrong all the time and fix them in Errata.

> That doesn't seem to be a problem.=C2=A0 I don't hear calls to=


> remove pattern-stmt because he syntax is really hard.



The difference is that efficient algorithms are available for regex matchin=
g, and there are no dark corners.

So a pattern may not do exactly what it was intended for but it should neve=
r cause the server or client software to fail or accidentally erase some da=
ta.




If the regex test fails=
 then the leaf or leaf-list will be rejected with
an invalid-valu=
e error.=C2=A0 If an invalid pattern passes then it will be
accep=
ted as a valid string for that typedef.

This is ba=
d enough but it can in turn cause ripple effects (e.g. leafref)
t=
hat are just as bad as deleting data that the when-stmt says is going
=

to be deleted.

=C2=A0

>

> We are not going to spend any time coding for

> clever corner-cases.=C2=A0 We do spend time coding for use-cases.

> I agree the interoperability for use-cases is quite acceptable.

> All this fuss over corner-cases is not that interesting.



I think it is only matter of time when such corner cases show up in the wil=
d. People like to use sharp knives.



And we fix then one at a time when the=
y come up.
As the number of inter-connected modules grows the pos=
sibility
for when-stmt race conditions in real modules will also =
grow.
Hopefully YANG Doctors will be paying attention and identif=
y problems
in IETF modules before they are published.




Lada


Andy
=C2=
=A0



>

>

> Andy

>

>

> > Reading section 7.19.5 of RFC 6020 again, I do not find the auto-=
deletion

> > described.

>

> It is described in 8.3.2.

>

> > I do see auto-deletion defined in section 7.9.6 for

> > NETCONF's edit-config operation. (The text does not say anyth=
ing about

> > what happens if an attempt is made to create multiple cases, I gu=
ess

> > it is implementation dependent which choice will become effective=
 but

> > one might also consider this an error - but clearly this is not
> > defined). I note that RFC 6020bis has lifted this auto-deletion u=
p

> > from being a NETCONF edit-config property to a property that appl=
ies

> > to all protocols. (It still does not define what happens if an ed=
it

> > creates multiple case branches.)

> >

> > A proposal was made to declare "when" auto-deletion to =
be part of the

> > YANG data store validation process, that is, it applies to every<=
br>
> > protocol interface. This means that a datastore not only needs to=


> > maintain data that is being validated, it also needs to remember =
the

> > last edit (at least) in order to _guess_ what should be deleted d=
uring

> > validation.

>

> No guessing is involved.=C2=A0 If a node's when expression evaluat=
es to

> false, it is deleted.

>

>

> /martin

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a114730c0b1c62305230441b5--


From nobody Mon Oct 26 15:54:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0CD1A7009 for ; Mon, 26 Oct 2015 15:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsQpYeeuqgFE for ; Mon, 26 Oct 2015 15:54:16 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988A01A6FA3 for ; Mon, 26 Oct 2015 15:54:16 -0700 (PDT)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 22:54:14 +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.0306.003; Mon, 26 Oct 2015 22:54:14 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] preliminary agenda for yokohama posted
Thread-Index: AQHRDiXimIGUoQwy9kavTVT8nxC7E55+IxwA
Date: Mon, 26 Oct 2015 22:54:14 +0000
Message-ID: <2513587D-32FA-4F56-B33E-FCEB1FC0D752@juniper.net>
References: <9BE1015D-0711-4A43-8663-161E13BF52E0@juniper.net>
In-Reply-To: <9BE1015D-0711-4A43-8663-161E13BF52E0@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151008
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:H6TxUWmaZLEgLwftwdV9udb0lM/31mmXhGylDYDI4i9/87vRGGlXufJ/DCdABQ+LCaIgKTWltWTFfZDzvzcEZpwgjGrPXkXDQS3tkTretCST+w4JiqwobwOonaXpSg1/B/71M8oyU0LsOwr+EjwnGQ==; 24:d7WhZopkFsnRMWiMIi0b5np84qneuviGLTYaNnMxNVDuAU/0jud0W+pNGtAwgsObwbY2M9r6SmxLBhR6i/bZEmGp+oD4FEjCeg/IBdwqwg0=; 20:NQnUCOOg/hxIjmWmyuxtnJ1fWFFP0m/GjXIuqGEuozOTSoA3MIN4wFepTLUAH+ZgnBhQ7PWXSsfomG390lYv2g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 0741C77572
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(377454003)(189002)(5008740100001)(102836002)(76176999)(92566002)(16236675004)(66066001)(11100500001)(33656002)(5002640100001)(10400500002)(77096005)(5004730100002)(5007970100001)(2351001)(2900100001)(2950100001)(2501003)(107886002)(110136002)(5001960100002)(15975445007)(189998001)(83716003)(19580405001)(81156007)(4001350100001)(19580395003)(83506001)(106356001)(450100001)(82746002)(40100003)(87936001)(86362001)(106116001)(50986999)(101416001)(105586002)(54356999)(122556002)(99286002)(19617315012)(36756003)(97736004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_2513587D32FA4F56B33EFCEB1FC0D752junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2015 22:54:14.5774 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: 
Subject: Re: [netmod] preliminary agenda for yokohama posted
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 22:54:19 -0000

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

RmluYWwgYWdlbmRhIHBvc3RlZDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv
OTQvYWdlbmRhL2FnZW5kYS05NC1uZXRtb2QNCi0gZG9u4oCZdCBmb3JnZXQgdG8gcmVmcmVzaCB5
b3VyIGNhY2hlIDspDQoNClRoYW5rcywNCktlbnQNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg
b2YgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBl
ci5uZXQ+Pg0KRGF0ZTogU2F0dXJkYXksIE9jdG9iZXIgMjQsIDIwMTUgYXQgMjozMyBBTQ0KVG86
ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gcHJlbGlt
aW5hcnkgYWdlbmRhIGZvciB5b2tvaGFtYSBwb3N0ZWQNCg0KSGVyZeKAmXMgYW4gdXBkYXRlIHRv
IHRoZSBhZ2VuZGEgZm9yIHRoZSB0d28gc2Vzc2lvbnMgYXQgOTQ6DQoNClVwZGF0ZXM6DQogIC0g
c3lzbG9nIHJlbW92ZWQgKGJlY2F1c2UgaXTigJlzIHJlYWR5IGZvciBMYXN0IENhbGwpDQogIC0g
ZGlmZnNlcnYgcmVtb3ZlZCAobm90aGluZyB0byByZXBvcnQpDQogIC0gbW9kZWxzIG1vdmVkIHRv
IG1vcm5pbmcgc2xvdA0KICAtIHRpbWVzIGFuZCBwcmVzZW50ZXJzIGxvY2tlZCBpbiAoYWxtb3N0
KQ0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9hZ2VuZGEvYWdlbmRhLTk0
LW5ldG1vZA0KLSBkb27igJl0IGZvcmdldCB0byByZWZyZXNoIHlvdXIgY2FjaGUgOykNCg0KVGhh
bmtzLA0KS2VudCBhbmQgVG9tDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgS2VudCBX
YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+Pg0K
RGF0ZTogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IGF0IDg6MzkgUE0NClRvOiAibmV0bW9kQGll
dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpu
ZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW25ldG1vZF0gcHJlbGltaW5hcnkgYWdlbmRhIGZv
ciB5b2tvaGFtYSBwb3N0ZWQNCg0KDQpUaGUgcHJlbGltaW5hcnkgYWdlbmRhIGZvciB0aGUgdHdv
IHNlc3Npb25zIGF0IFlva29oYW1hIGhhcyBiZWVuIHBvc3RlZCBoZXJlOg0KDQpodHRwczovL3d3
dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9hZ2VuZGEvYWdlbmRhLTk0LW5ldG1vZA0KDQpPYnZp
b3VzbHkgYSBsb3Qgb2YgdW5rbm93bnMsIGJ1dCB0aGF0J3Mgd2hhdCAicHJlbGltaW5hcnkiIG1l
YW5zIHJpZ2h0PyAgOykNCg0KS2VudCAgIC8vIGNoYWlyIGhhdCBvbg0KDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48Zm9u
dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPkZpbmFsIGFnZW5kYSBwb3N0ZWQ6PC9mb250Pjwv
ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48
L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48c3BhbiBjbGFzcz0i
QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5odHRwczovL3d3
dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9hZ2VuZGEvYWdlbmRhLTk0LW5ldG1vZDwvZm9udD48
L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48c3BhbiBjbGFzcz0i
QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj4tIGRvbuKAmXQg
Zm9yZ2V0IHRvIHJlZnJlc2ggeW91ciBjYWNoZSA7KTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg
ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250
IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD48L2Rpdj4NCjxkaXY+PGZv
bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5LZW50PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+
DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+
DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1h
bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF
Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw
aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP
UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2QgJmx0OzxhIGhyZWY9Im1haWx0
bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0
OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1
bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlNhdHVyZGF5LCBPY3RvYmVyIDI0LCAyMDE1
IGF0IDI6MzMgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh
bj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8
L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0
Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0
OiA8L3NwYW4+UmU6IFtuZXRtb2RdIHByZWxpbWluYXJ5IGFnZW5kYSBmb3IgeW9rb2hhbWEgcG9z
dGVkPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Indv
cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp
bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6
ZTogMTRweDsiPkhlcmXigJlzIGFuIHVwZGF0ZSB0byB0aGUgYWdlbmRhIGZvciB0aGUgdHdvIHNl
c3Npb25zIGF0IDk0OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PGJyPg0K
PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5VcGRhdGVzOjwvZGl2Pg0KPGRp
diBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+Jm5ic3A7IC0gc3lzbG9nIHJlbW92ZWQgKGJlY2F1
c2UgaXTigJlzIHJlYWR5IGZvciBMYXN0IENhbGwpJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJm
b250LXNpemU6IDE0cHg7Ij4mbmJzcDsgLSBkaWZmc2VydiByZW1vdmVkIChub3RoaW5nIHRvIHJl
cG9ydCk8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPiZuYnNwOyAtIG1vZGVs
cyBtb3ZlZCB0byBtb3JuaW5nIHNsb3Q8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRw
eDsiPiZuYnNwOyAtIHRpbWVzIGFuZCBwcmVzZW50ZXJzIGxvY2tlZCBpbiAoYWxtb3N0KTwvZGl2
Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl
PSJmb250LXNpemU6IDE0cHg7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk
aW5ncy85NC9hZ2VuZGEvYWdlbmRhLTk0LW5ldG1vZCIgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L2FnZW5kYS9hZ2VuZGEtOTQtbmV0
bW9kPC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PHNwYW4gY2xhc3M9
IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LSBkb27igJl0
IGZvcmdldCB0byByZWZyZXNoIHlvdXIgY2FjaGUgOyk8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls
ZT0iZm9udC1zaXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6
IDE0cHg7Ij5UaGFua3MsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5LZW50
IGFuZCBUb208L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvZGl2
Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i
T0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5
bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7
IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l
ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO
Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1i
b3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs
ZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQi
Pmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IGF0IDg6MzkgUE08
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBo
cmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W25l
dG1vZF0gcHJlbGltaW5hcnkgYWdlbmRhIGZvciB5b2tvaGFtYSBwb3N0ZWQ8YnI+DQo8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13
b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt
d2hpdGUtc3BhY2U7Ij4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij4NCjxicj4NCjwvZGl2
Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZSBwcmVsaW1pbmFyeTwv
Zm9udD48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPiBhZ2VuZGEgZm9yIHRoZSB0d28gc2Vz
c2lvbnMgYXQgWW9rb2hhbWEgaGFzIGJlZW4gcG9zdGVkIGhlcmU6PC9zcGFuPjwvZGl2Pg0KPGRp
diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt
c2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv
cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z
aXplOiAxNnB4OyI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z
cGFjZTpwcmUiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n
cy85NC9hZ2VuZGEvYWdlbmRhLTk0LW5ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl
ZGluZ3MvOTQvYWdlbmRhL2FnZW5kYS05NC1uZXRtb2Q8L2E+PC9kaXY+DQo8ZGl2Pjxmb250IGZh
Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm
YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPk9idmlvdXNseSBhIGxvdCBvZiB1bmtub3ducywgYnV0
IHRoYXQncyB3aGF0ICZxdW90O3ByZWxpbWluYXJ5JnF1b3Q7IG1lYW5zIHJpZ2h0PyAmbmJzcDs7
KTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+
DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+S2Vu
dCAmbmJzcDsgLy8gY2hhaXIgaGF0IG9uPC9mb250PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_2513587D32FA4F56B33EFCEB1FC0D752junipernet_--


From nobody Tue Oct 27 06:26:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317F1A8905 for ; Tue, 27 Oct 2015 06:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0-ZohL9IOqs for ; Tue, 27 Oct 2015 06:25:56 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C575F1A8902 for ; Tue, 27 Oct 2015 06:25:54 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C67721CC0116; Tue, 27 Oct 2015 14:25:56 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" 
In-Reply-To: <562E4BA9.4060106@cisco.com>
References: <562E4BA9.4060106@cisco.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 27 Oct 2015 14:25:52 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 13:25:59 -0000

Hi Rob,

I think both modules are useful extensions to ietf-interfaces, and I
would support adopting it as a NETMOD work item. I have a few
comments/questions:

   1. You are using several YANG 1.1 features (multiple identityref
      bases, mandatory nodes in augments), so you should have 6020bis
      as a normative reference rather than RFC 6020.

   2. "when" expressions in the module "interfaces-ethernet-like"
      demonstrate that IANA interface types are pretty much
      useless. Not only is it necessary to list all ethernet-like
      interface types one by one, but it also isn't extensible: these
      augments won't apply to new ethernet-like types.

      Moreover - and this might actually be a flaw in 6020bis - it is
      not allowed to update the "when" statements in a new revision of
      the module.

      Anyway, I think it is necessary to have an "Ethernet" identity
      from which all ethernet-like interface types would be derived.
      The "when" expressions would then be simple and extensible:

        when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";

   3. How is "l2-mtu" related to L3 MTU (under "ip:ipv[46])? What
      about

        must "not(l2-mtu <= ip:ipv4/ip:mtu)";

      and similarly for IPv6?

   4. I think the name "transport-layer" isn't appropriate for an
      enumeration "layer-1"/"layer-2"/"layer-3" because "Transport
      Layer" is the name for "layer-4" in the ISO OSI model. 

Lada

Robert Wilton  writes:

> Hi,
>
> Last week I posted slightly revised version of both 
> draft-wilton-netmod-intf-ext-yang-01 and 
> draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the 
> models contained within these two drafts is very welcome, but I would be 
> particularly interested in any opinions regarding some slight changes 
> for modelling sub-interfaces in the interfaces-extensions draft.
>
> The main changes that I've made to intf-ext-yang-01 are:
>
> 1) I've defined a new "sub-interface" identity to represent the 
> behaviour of any interface type that is a representation of a 
> sub-interface.  The idea here is to ensure that the common sub-interface 
> configuration leaves can be re-used by any other sub-interface types 
> that are defined in future models, or possibly vendor specific interface 
> types. E.g. the augmentation that adds sub-interface related 
> configuration in interfaces-common.yang:
>
> 
>    identity sub-interface {
>      description "Base type for generic sub-interfaces.  New or custom
>                   interface types can derive from this type to
>                   inherit generic sub-interface configuration";
>    }
>
>    augment "/if:interfaces/if:interface" {
>      when "derived-from(if:type,
>                         'ietf-if-cmn',
>                         'sub-interface') or
>            if:type = 'ianaift:atmSubInterface' or
>            if:type = 'ianaift:frameRelay'"  {
>        description
>          "Any ianaift:types that explicitly represent sub-interfaces
>           or any types that derive from the sub-interface identity";
>      }
>
>      ... sub-interface specific configuration nodes go here.
>    }
> 
>
> If this is accepted as generally a good approach of modelling this in a 
> future safe manner, then I was considering also defining an interface 
> type that is the common representation of a physical- interfaces for 
> some of the other features defined in the interface-extension draft.
>
>
> 2) I've defined a new ethSubInterface identity in interface-common.yang 
> that inherits from ianaift:l2vlan and the new sub-interface identity above.
>   - Using Yang 1.1 this will allow the augmentation of the 
> parent-interface leaf to be marked as mandatory.
>   - It also solves a possible concern that some vendors may have a 
> different interpretation of what the IANA interface type "l2vlan" 
> actually means (noting that the IANA only provides a slightly vague 
> definition).
>
> I.e.
> 
>    identity ethSubInterface{
>      base ianaift:l2vlan;
>      base sub-interface;
>
>      description "Sub-interface of any interface types that uses
>                   Ethernet framing (with or without 802.1Q tagging)";
>    }
> 
>
> 3) The features above mean that module is marked a being Yang version 
> 1.1 only.
>
> Any feedback is appreciated.
>
> Thanks,
> Rob
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Tue Oct 27 08:12:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8895B1A9048 for ; Tue, 27 Oct 2015 08:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.311
X-Spam-Level: 
X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7duUWdxD7cU for ; Tue, 27 Oct 2015 08:12:37 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61891A904E for ; Tue, 27 Oct 2015 08:12:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8963; q=dns/txt; s=iport; t=1445958756; x=1447168356; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W/Lw0osa4Jn3MdL+yrqXxtpMr1ORllk0PLZOTVznnN8=; b=hzQdINH6d0BAR+FA+VUUs6mhLQeEI44BL0Lz+zaeOmw7yioWtB+BAHxG ibwagwxHRkulmkQVT4+FDhBzistMVY1IvWFMMlABh4ICSHRdfAJjM+FwX Vj0gALBF6BXuCZQ8yfDIiHQRgEvoApS4pJW55/uALLr/EuczKlhVBtFyc Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBAB0ky9W/xbLJq1VCYQKb8BtFwqFL0oCgggBAQEBAQGBC4QyAQEBAwEBAQE1LwcKEQsYCRYPCQMCAQIBFTAGAQwGAgEBiCQIDcVcAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIZ3hH6EMWOELgEEjRmJH40kgVmEP4MBikmIUGOEBD40hW4BAQE
X-IronPort-AV: E=Sophos;i="5.20,205,1444694400"; d="scan'208";a="605944996"
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; 27 Oct 2015 15:12:33 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9RFCXhY030783; Tue, 27 Oct 2015 15:12:33 GMT
To: Ladislav Lhotka , "netmod@ietf.org" 
References: <562E4BA9.4060106@cisco.com> 
From: Robert Wilton 
Message-ID: <562F9449.3040504@cisco.com>
Date: Tue, 27 Oct 2015 15:12:09 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 15:12:39 -0000

Hi Lada,

Thanks for the review and comments, please see inline ...

On 27/10/2015 13:25, Ladislav Lhotka wrote:
> Hi Rob,
>
> I think both modules are useful extensions to ietf-interfaces, and I
> would support adopting it as a NETMOD work item. I have a few
> comments/questions:
>
>     1. You are using several YANG 1.1 features (multiple identityref
>        bases, mandatory nodes in augments), so you should have 6020bis
>        as a normative reference rather than RFC 6020.
Yes, I'll fix this.

>
>     2. "when" expressions in the module "interfaces-ethernet-like"
>        demonstrate that IANA interface types are pretty much
>        useless. Not only is it necessary to list all ethernet-like
>        interface types one by one, but it also isn't extensible: these
>        augments won't apply to new ethernet-like types.
Yes, I agree.

The other concern that I have with the IANA interface types is that I 
feel that their importance has changed somewhat.

In the past, it feels like the IANA interface type was just a label to 
attach to an interface to help the operator understand what type of 
interface is was, e.g. a bit like a description.  As such, I think that 
historically vendors may interpret the meaning of the interface types 
somewhat differently and it didn't really matter very much.

However, with YANG, the IANA interface type identities are being used in 
a more fundamental way to define which parts of the data model are 
available and meaningful.  For this to be sane, I think that the 
definitions might need to be clarified or strengthened, and personally I 
wonder whether the list could sensibly be cut down in size.  There are 
280 IANA interface types defined, but I suspect that less than half of 
those are still in common usage.  E.g. in Cisco's IOS XR, I think that I 
only counted 20 that are actually in use.

>
>        Moreover - and this might actually be a flaw in 6020bis - it is
>        not allowed to update the "when" statements in a new revision of
>        the module.
>
>        Anyway, I think it is necessary to have an "Ethernet" identity
>        from which all ethernet-like interface types would be derived.
>        The "when" expressions would then be simple and extensible:
>
>          when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";
Yes, I agree.

I think that it would be useful to define a set of base identities that 
describe the common semantics of interfaces.  E.g. Etherlike, Physical, 
Sub-interface, Aggregate-interface, Optical, Tunnel, etc.

The question is what do we do with the existing IANA types, it would be 
useful if they also inherited from the appropriate base identities 
rather than be carried around as special cases.  Perhaps there is an 
argument for defining a new set of YANG interface identifiers:

E.g.

iana-if-type.yang defines
   identity ethernetCsmacd {
     base iana-interface-type;
     description
       "For all Ethernet-like interfaces, regardless of speed,
        as per RFC 3635.";
     reference
       "RFC 3635 - Definitions of Managed Objects for the
                   Ethernet-like Interface Types";
   }


New base identities could be defined like:

   identity physical {
     description "Base type for physical interfaces";
   }

   identity sub-interface {
     description "Base type for generic sub-interfaces.  New or custom
                  interface types can derive from this type to
                  inherit generic sub-interface configuration";
   }

   identity ethernet-like {
     description "Base type for any interfaces that use Ethernet framing at OSI layer 2";
   }

New interface identities could also be defined like:

   identity ethernet {
     base ianaift:ethernetCsmacd;
     base physical;
     base ethernet-like;

     description "Physical Ethernet interface";
  }

   identity ethSubInterface{
     base ianaift:l2vlan;
     base sub-interface;
     base ethernet-like;

     description "Sub-interface of any interface types that uses
                  Ethernet framing (with or without 802.1Q tagging)";
  }

Ethernet physical interface configuration would use: 
derived-from(if:type, 'ietf-ethernet', 'Ethernet')
Etherlike configuration (e.g. MAC address) would use: 
derived-from(if:type, ..., 'ethernet-like')
Common physical interface configuration would use: derived-from(if:type, 
..., 'physical')
Etc.

>
>     3. How is "l2-mtu" related to L3 MTU (under "ip:ipv[46])? What
>        about
>
>          must "not(l2-mtu <= ip:ipv4/ip:mtu)";
>
>        and similarly for IPv6?
Yes, I agree, although possibly the definitions might be cleaner in the 
ip:ipv4 and ipv6 modules.  I.e. it is better if the higher layers 
reference the lower layers rather than the other way round.

The meaning (and hence name) of the l2-mtu leaf probably needs some more 
refinement.  Basically, I think that we want to have a tight MTU 
definition that always includes any and all appropriate layer 2 
overheads.  Specifically I want to avoid cases were MTUs are sometimes 
defined in terms of the layer 3 payload which then don't play nicely 
with layer 2 services.  But conversely the definition should also work 
for a pure layer 3 service interface that doesn't have any applicable 
layer 2 overheads.

>
>     4. I think the name "transport-layer" isn't appropriate for an
>        enumeration "layer-1"/"layer-2"/"layer-3" because "Transport
>        Layer" is the name for "layer-4" in the ISO OSI model.
Yes, I think that you are right.  We need to come up with a better name 
here.

Thanks,
Rob

>
> Lada
>
> Robert Wilton  writes:
>
>> Hi,
>>
>> Last week I posted slightly revised version of both
>> draft-wilton-netmod-intf-ext-yang-01 and
>> draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the
>> models contained within these two drafts is very welcome, but I would be
>> particularly interested in any opinions regarding some slight changes
>> for modelling sub-interfaces in the interfaces-extensions draft.
>>
>> The main changes that I've made to intf-ext-yang-01 are:
>>
>> 1) I've defined a new "sub-interface" identity to represent the
>> behaviour of any interface type that is a representation of a
>> sub-interface.  The idea here is to ensure that the common sub-interface
>> configuration leaves can be re-used by any other sub-interface types
>> that are defined in future models, or possibly vendor specific interface
>> types. E.g. the augmentation that adds sub-interface related
>> configuration in interfaces-common.yang:
>>
>> 
>>     identity sub-interface {
>>       description "Base type for generic sub-interfaces.  New or custom
>>                    interface types can derive from this type to
>>                    inherit generic sub-interface configuration";
>>     }
>>
>>     augment "/if:interfaces/if:interface" {
>>       when "derived-from(if:type,
>>                          'ietf-if-cmn',
>>                          'sub-interface') or
>>             if:type = 'ianaift:atmSubInterface' or
>>             if:type = 'ianaift:frameRelay'"  {
>>         description
>>           "Any ianaift:types that explicitly represent sub-interfaces
>>            or any types that derive from the sub-interface identity";
>>       }
>>
>>       ... sub-interface specific configuration nodes go here.
>>     }
>> 
>>
>> If this is accepted as generally a good approach of modelling this in a
>> future safe manner, then I was considering also defining an interface
>> type that is the common representation of a physical- interfaces for
>> some of the other features defined in the interface-extension draft.
>>
>>
>> 2) I've defined a new ethSubInterface identity in interface-common.yang
>> that inherits from ianaift:l2vlan and the new sub-interface identity above.
>>    - Using Yang 1.1 this will allow the augmentation of the
>> parent-interface leaf to be marked as mandatory.
>>    - It also solves a possible concern that some vendors may have a
>> different interpretation of what the IANA interface type "l2vlan"
>> actually means (noting that the IANA only provides a slightly vague
>> definition).
>>
>> I.e.
>> 
>>     identity ethSubInterface{
>>       base ianaift:l2vlan;
>>       base sub-interface;
>>
>>       description "Sub-interface of any interface types that uses
>>                    Ethernet framing (with or without 802.1Q tagging)";
>>     }
>> 
>>
>> 3) The features above mean that module is marked a being Yang version
>> 1.1 only.
>>
>> Any feedback is appreciated.
>>
>> Thanks,
>> Rob
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 27 08:29:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC63B1A9088 for ; Tue, 27 Oct 2015 08:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbKGOki7M4N2 for ; Tue, 27 Oct 2015 08:29:24 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782F31A9086 for ; Tue, 27 Oct 2015 08:29:24 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F35A38E5; Tue, 27 Oct 2015 16:29:22 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lFjunfSRXCpP; Tue, 27 Oct 2015 16:29:21 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 Oct 2015 16:29:21 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB8282004E; Tue, 27 Oct 2015 16:29:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IddPfFqPZBjR; Tue, 27 Oct 2015 16:29:20 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35A942003B; Tue, 27 Oct 2015 16:29:20 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 64986386B906; Tue, 27 Oct 2015 16:29:19 +0100 (CET)
Date: Tue, 27 Oct 2015 16:29:18 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20151027152918.GA58184@elstar.local>
Mail-Followup-To: Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" 
References: <562E4BA9.4060106@cisco.com>  <562F9449.3040504@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <562F9449.3040504@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 15:29:27 -0000

On Tue, Oct 27, 2015 at 03:12:09PM +0000, Robert Wilton wrote:
> Hi Lada,
> 
> Thanks for the review and comments, please see inline ...
> 
> On 27/10/2015 13:25, Ladislav Lhotka wrote:
> >Hi Rob,
> >
> >I think both modules are useful extensions to ietf-interfaces, and I
> >would support adopting it as a NETMOD work item. I have a few
> >comments/questions:
> >
> >    1. You are using several YANG 1.1 features (multiple identityref
> >       bases, mandatory nodes in augments), so you should have 6020bis
> >       as a normative reference rather than RFC 6020.
> Yes, I'll fix this.
> 
> >
> >    2. "when" expressions in the module "interfaces-ethernet-like"
> >       demonstrate that IANA interface types are pretty much
> >       useless. Not only is it necessary to list all ethernet-like
> >       interface types one by one, but it also isn't extensible: these
> >       augments won't apply to new ethernet-like types.
> Yes, I agree.
> 
> The other concern that I have with the IANA interface types is that I 
> feel that their importance has changed somewhat.
> 
> In the past, it feels like the IANA interface type was just a label to 
> attach to an interface to help the operator understand what type of 
> interface is was, e.g. a bit like a description.  As such, I think that 
> historically vendors may interpret the meaning of the interface types 
> somewhat differently and it didn't really matter very much.
>

IANA interface types are actually a bit more than just a label since
there are several interface type specific MIB modules that are
registered in the transmission OID branch and the registration number
usually matches the interface type number in the IANA registry. But
yes, for monitoring, a broad classification is usually sufficient.
For configuration, one likes to have more details but then our
understanding of interfaces has evolved a lot over the years (and
producing a new interface classification model that can sustain
another 30+ years is likely tricky).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Oct 27 08:33:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D21A90AA for ; Tue, 27 Oct 2015 08:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.461
X-Spam-Level: 
X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_pCLKTG6SHj for ; Tue, 27 Oct 2015 08:33:09 -0700 (PDT)
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 35C771A9091 for ; Tue, 27 Oct 2015 08:33:09 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:310c:9f6b:3ae3:755c] (unknown [IPv6:2001:718:1a02:1:310c:9f6b:3ae3:755c]) by mail.nic.cz (Postfix) with ESMTPSA id AE98B18190C; Tue, 27 Oct 2015 16:33:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445959987; bh=3pTPaqr/IKOc+Qk7fOdb4QPw8yMe5moes2gBqDuC5uw=; h=From:Date:To; b=A0n9LbOdmYEKYB/uqsoNaIGr0fKH+yL9/nZaUfhwfJch3j7cKzS7kS62v58Lhxp9C LqeMzuQJlLqSeH7hV+4QUoc8+wgrcuOFefdKe8ZWQ8Bp0hdMUGeODJ/IXboNxipQ81 VdKbHnmmI1cHNnOXCa/RM4qtoKvVdOOZxjpW8Ky4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Ladislav Lhotka 
In-Reply-To: <562F9449.3040504@cisco.com>
Date: Tue, 27 Oct 2015 16:33:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CA09F12-7F26-4154-A05A-C5CD6B1899B3@nic.cz>
References: <562E4BA9.4060106@cisco.com>  <562F9449.3040504@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3096.5)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 15:33:12 -0000

> On 27 Oct 2015, at 16:12, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> Thanks for the review and comments, please see inline ...
>=20
> On 27/10/2015 13:25, Ladislav Lhotka wrote:
>> Hi Rob,
>>=20
>> I think both modules are useful extensions to ietf-interfaces, and I
>> would support adopting it as a NETMOD work item. I have a few
>> comments/questions:
>>=20
>>    1. You are using several YANG 1.1 features (multiple identityref
>>       bases, mandatory nodes in augments), so you should have 6020bis
>>       as a normative reference rather than RFC 6020.
> Yes, I'll fix this.
>=20
>>=20
>>    2. "when" expressions in the module "interfaces-ethernet-like"
>>       demonstrate that IANA interface types are pretty much
>>       useless. Not only is it necessary to list all ethernet-like
>>       interface types one by one, but it also isn't extensible: these
>>       augments won't apply to new ethernet-like types.
> Yes, I agree.
>=20
> The other concern that I have with the IANA interface types is that I =
feel that their importance has changed somewhat.
>=20
> In the past, it feels like the IANA interface type was just a label to =
attach to an interface to help the operator understand what type of =
interface is was, e.g. a bit like a description.  As such, I think that =
historically vendors may interpret the meaning of the interface types =
somewhat differently and it didn't really matter very much.
>=20
> However, with YANG, the IANA interface type identities are being used =
in a more fundamental way to define which parts of the data model are =
available and meaningful.  For this to be sane, I think that the =
definitions might need to be clarified or strengthened, and personally I =
wonder whether the list could sensibly be cut down in size.  There are =
280 IANA interface types defined, but I suspect that less than half of =
those are still in common usage.  E.g. in Cisco's IOS XR, I think that I =
only counted 20 that are actually in use.

Absolutely. The IANA interface type registry is a mess with many =
obsolete or weird items, but on the other hand some important types are =
either missing or comprised in a very general type.=20

>=20
>>=20
>>       Moreover - and this might actually be a flaw in 6020bis - it is
>>       not allowed to update the "when" statements in a new revision =
of
>>       the module.
>>=20
>>       Anyway, I think it is necessary to have an "Ethernet" identity
>>       from which all ethernet-like interface types would be derived.
>>       The "when" expressions would then be simple and extensible:
>>=20
>>         when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";
> Yes, I agree.
>=20
> I think that it would be useful to define a set of base identities =
that describe the common semantics of interfaces.  E.g. Etherlike, =
Physical, Sub-interface, Aggregate-interface, Optical, Tunnel, etc.

Agreed.

>=20
> The question is what do we do with the existing IANA types, it would =
be useful if they also inherited from the appropriate base identities =
rather than be carried around as special cases.  Perhaps there is an =
argument for defining a new set of YANG interface identifiers:
>=20
> E.g.
>=20
> iana-if-type.yang defines
>  identity ethernetCsmacd {

In principle, this IANA identity could be used as a base for all =
ethernet-like interfaces, although I don't like the name (invariably =
make a typo in it:-).

>    base iana-interface-type;
>    description
>      "For all Ethernet-like interfaces, regardless of speed,
>       as per RFC 3635.";
>    reference
>      "RFC 3635 - Definitions of Managed Objects for the
>                  Ethernet-like Interface Types";
>  }
>=20
>=20
> New base identities could be defined like:
>=20
>  identity physical {
>    description "Base type for physical interfaces";
>  }
>=20
>  identity sub-interface {
>    description "Base type for generic sub-interfaces.  New or custom
>                 interface types can derive from this type to
>                 inherit generic sub-interface configuration";
>  }
>=20
>  identity ethernet-like {
>    description "Base type for any interfaces that use Ethernet framing =
at OSI layer 2";
>  }
>=20
> New interface identities could also be defined like:
>=20
>  identity ethernet {
>    base ianaift:ethernetCsmacd;
>    base physical;
>    base ethernet-like;
>=20
>    description "Physical Ethernet interface";
> }
>=20
>  identity ethSubInterface{
>    base ianaift:l2vlan;
>    base sub-interface;
>    base ethernet-like;
>=20
>    description "Sub-interface of any interface types that uses
>                 Ethernet framing (with or without 802.1Q tagging)";
> }
>=20
> Ethernet physical interface configuration would use: =
derived-from(if:type, 'ietf-ethernet', 'Ethernet')
> Etherlike configuration (e.g. MAC address) would use: =
derived-from(if:type, ..., 'ethernet-like')
> Common physical interface configuration would use: =
derived-from(if:type, ..., 'physical')
> Etc.
>=20
>>=20
>>    3. How is "l2-mtu" related to L3 MTU (under "ip:ipv[46])? What
>>       about
>>=20
>>         must "not(l2-mtu <=3D ip:ipv4/ip:mtu)";
>>=20
>>       and similarly for IPv6?
> Yes, I agree, although possibly the definitions might be cleaner in =
the ip:ipv4 and ipv6 modules.  I.e. it is better if the higher layers =
reference the lower layers rather than the other way round.
>=20
> The meaning (and hence name) of the l2-mtu leaf probably needs some =
more refinement.  Basically, I think that we want to have a tight MTU =
definition that always includes any and all appropriate layer 2 =
overheads.  Specifically I want to avoid cases were MTUs are sometimes =
defined in terms of the layer 3 payload which then don't play nicely =
with layer 2 services.  But conversely the definition should also work =
for a pure layer 3 service interface that doesn't have any applicable =
layer 2 overheads.

I think ietf-interfaces initially included L2 mtu but then it was =
decided not to use it. I don't remember exactly what the reason was, =
perhaps that the concept of MTU differs among L2 interface types.

Lada=20

>=20
>>=20
>>    4. I think the name "transport-layer" isn't appropriate for an
>>       enumeration "layer-1"/"layer-2"/"layer-3" because "Transport
>>       Layer" is the name for "layer-4" in the ISO OSI model.
> Yes, I think that you are right.  We need to come up with a better =
name here.
>=20
> Thanks,
> Rob
>=20
>>=20
>> Lada
>>=20
>> Robert Wilton  writes:
>>=20
>>> Hi,
>>>=20
>>> Last week I posted slightly revised version of both
>>> draft-wilton-netmod-intf-ext-yang-01 and
>>> draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the
>>> models contained within these two drafts is very welcome, but I =
would be
>>> particularly interested in any opinions regarding some slight =
changes
>>> for modelling sub-interfaces in the interfaces-extensions draft.
>>>=20
>>> The main changes that I've made to intf-ext-yang-01 are:
>>>=20
>>> 1) I've defined a new "sub-interface" identity to represent the
>>> behaviour of any interface type that is a representation of a
>>> sub-interface.  The idea here is to ensure that the common =
sub-interface
>>> configuration leaves can be re-used by any other sub-interface types
>>> that are defined in future models, or possibly vendor specific =
interface
>>> types. E.g. the augmentation that adds sub-interface related
>>> configuration in interfaces-common.yang:
>>>=20
>>> 
>>>    identity sub-interface {
>>>      description "Base type for generic sub-interfaces.  New or =
custom
>>>                   interface types can derive from this type to
>>>                   inherit generic sub-interface configuration";
>>>    }
>>>=20
>>>    augment "/if:interfaces/if:interface" {
>>>      when "derived-from(if:type,
>>>                         'ietf-if-cmn',
>>>                         'sub-interface') or
>>>            if:type =3D 'ianaift:atmSubInterface' or
>>>            if:type =3D 'ianaift:frameRelay'"  {
>>>        description
>>>          "Any ianaift:types that explicitly represent sub-interfaces
>>>           or any types that derive from the sub-interface identity";
>>>      }
>>>=20
>>>      ... sub-interface specific configuration nodes go here.
>>>    }
>>> 
>>>=20
>>> If this is accepted as generally a good approach of modelling this =
in a
>>> future safe manner, then I was considering also defining an =
interface
>>> type that is the common representation of a physical- interfaces for
>>> some of the other features defined in the interface-extension draft.
>>>=20
>>>=20
>>> 2) I've defined a new ethSubInterface identity in =
interface-common.yang
>>> that inherits from ianaift:l2vlan and the new sub-interface identity =
above.
>>>   - Using Yang 1.1 this will allow the augmentation of the
>>> parent-interface leaf to be marked as mandatory.
>>>   - It also solves a possible concern that some vendors may have a
>>> different interpretation of what the IANA interface type "l2vlan"
>>> actually means (noting that the IANA only provides a slightly vague
>>> definition).
>>>=20
>>> I.e.
>>> 
>>>    identity ethSubInterface{
>>>      base ianaift:l2vlan;
>>>      base sub-interface;
>>>=20
>>>      description "Sub-interface of any interface types that uses
>>>                   Ethernet framing (with or without 802.1Q =
tagging)";
>>>    }
>>> 
>>>=20
>>> 3) The features above mean that module is marked a being Yang =
version
>>> 1.1 only.
>>>=20
>>> Any feedback is appreciated.
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From nobody Tue Oct 27 09:34:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA01A92FC for ; Tue, 27 Oct 2015 09:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.311
X-Spam-Level: 
X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D5ur9Ir_A-0 for ; Tue, 27 Oct 2015 09:34:37 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1236D1AC3CB for ; Tue, 27 Oct 2015 09:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11202; q=dns/txt; s=iport; t=1445963677; x=1447173277; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=m8vdfWo1sl6/bMWqlbnCKwjjRbvQ1cxY5Fyz3+SdmZ0=; b=kKjmZ6yxa8kjtwESPySsLlXV2JrBDNg9xSq96XXTwt0NZOZqFlPGq8kY 4/15t5VcoVh3fLbbxJF5MUCUv2P6Gt00F/eDkZaF2YfINcSHVTaEkO6W6 0/JmaHxNcXcwcUl4NaiNVzjQG1pwv8RYmsHkjbMhRA9Cf5rSFJNRHcw91 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DPAQBDpy9W/xbLJq1VCYQKb78HAQ2BWhcKhS9KAoF2FAEBAQEBAQGBCoQyAQEBAwEBAQE1LwcKARALGAkWDwkDAgECARUwBg0GAgEBiCQIDcV+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGd4R+hDFcB4QuAQSHRYVUiR+NJIFZhD+DAYpJiFAfAQFChAQ+NIVuAQEB
X-IronPort-AV: E=Sophos;i="5.20,205,1444694400"; d="scan'208";a="630535273"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 27 Oct 2015 16:34:33 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9RGYXvv016079; Tue, 27 Oct 2015 16:34:33 GMT
To: Ladislav Lhotka 
References: <562E4BA9.4060106@cisco.com>  <562F9449.3040504@cisco.com> <7CA09F12-7F26-4154-A05A-C5CD6B1899B3@nic.cz>
From: Robert Wilton 
Message-ID: <562FA782.6040402@cisco.com>
Date: Tue, 27 Oct 2015 16:34:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7CA09F12-7F26-4154-A05A-C5CD6B1899B3@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 16:34:40 -0000

On 27/10/2015 15:33, Ladislav Lhotka wrote:
>> On 27 Oct 2015, at 16:12, Robert Wilton  wrote:
>>
>> Hi Lada,
>>
>> Thanks for the review and comments, please see inline ...
>>
>> On 27/10/2015 13:25, Ladislav Lhotka wrote:
>>> Hi Rob,
>>>
>>> I think both modules are useful extensions to ietf-interfaces, and I
>>> would support adopting it as a NETMOD work item. I have a few
>>> comments/questions:
>>>
>>>     1. You are using several YANG 1.1 features (multiple identityref
>>>        bases, mandatory nodes in augments), so you should have 6020bis
>>>        as a normative reference rather than RFC 6020.
>> Yes, I'll fix this.
>>
>>>     2. "when" expressions in the module "interfaces-ethernet-like"
>>>        demonstrate that IANA interface types are pretty much
>>>        useless. Not only is it necessary to list all ethernet-like
>>>        interface types one by one, but it also isn't extensible: these
>>>        augments won't apply to new ethernet-like types.
>> Yes, I agree.
>>
>> The other concern that I have with the IANA interface types is that I feel that their importance has changed somewhat.
>>
>> In the past, it feels like the IANA interface type was just a label to attach to an interface to help the operator understand what type of interface is was, e.g. a bit like a description.  As such, I think that historically vendors may interpret the meaning of the interface types somewhat differently and it didn't really matter very much.
>>
>> However, with YANG, the IANA interface type identities are being used in a more fundamental way to define which parts of the data model are available and meaningful.  For this to be sane, I think that the definitions might need to be clarified or strengthened, and personally I wonder whether the list could sensibly be cut down in size.  There are 280 IANA interface types defined, but I suspect that less than half of those are still in common usage.  E.g. in Cisco's IOS XR, I think that I only counted 20 that are actually in use.
> Absolutely. The IANA interface type registry is a mess with many obsolete or weird items, but on the other hand some important types are either missing or comprised in a very general type.
>
>>>        Moreover - and this might actually be a flaw in 6020bis - it is
>>>        not allowed to update the "when" statements in a new revision of
>>>        the module.
>>>
>>>        Anyway, I think it is necessary to have an "Ethernet" identity
>>>        from which all ethernet-like interface types would be derived.
>>>        The "when" expressions would then be simple and extensible:
>>>
>>>          when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";
>> Yes, I agree.
>>
>> I think that it would be useful to define a set of base identities that describe the common semantics of interfaces.  E.g. Etherlike, Physical, Sub-interface, Aggregate-interface, Optical, Tunnel, etc.
> Agreed.
>
>> The question is what do we do with the existing IANA types, it would be useful if they also inherited from the appropriate base identities rather than be carried around as special cases.  Perhaps there is an argument for defining a new set of YANG interface identifiers:
>>
>> E.g.
>>
>> iana-if-type.yang defines
>>   identity ethernetCsmacd {
> In principle, this IANA identity could be used as a base for all ethernet-like interfaces, although I don't like the name (invariably make a typo in it:-).
I think that we need to be able to differentiate between interfaces that 
are physical Ethernet interfaces (such as 1GE, 10GE, 40GE, which are all 
defined by IANA as ethernetCsmacd) vs interfaces that have Ethernet 
framing but are not physical Ethernet interfaces (e.g. a LAG aggregated 
interface, Ethernet sub-interfaces, L3 interface on an VLAN bridge, 
pseudo-wire terminated to L3, etc).

Configuration such as speed/duplex/auto-negotiation is only applicable 
to physical Ethernet interfaces, where as a MAC address is associated 
with all Ethernet-like interfaces.

>
>>     base iana-interface-type;
>>     description
>>       "For all Ethernet-like interfaces, regardless of speed,
>>        as per RFC 3635.";
>>     reference
>>       "RFC 3635 - Definitions of Managed Objects for the
>>                   Ethernet-like Interface Types";
>>   }
>>
>>
>> New base identities could be defined like:
>>
>>   identity physical {
>>     description "Base type for physical interfaces";
>>   }
>>
>>   identity sub-interface {
>>     description "Base type for generic sub-interfaces.  New or custom
>>                  interface types can derive from this type to
>>                  inherit generic sub-interface configuration";
>>   }
>>
>>   identity ethernet-like {
>>     description "Base type for any interfaces that use Ethernet framing at OSI layer 2";
>>   }
>>
>> New interface identities could also be defined like:
>>
>>   identity ethernet {
>>     base ianaift:ethernetCsmacd;
>>     base physical;
>>     base ethernet-like;
>>
>>     description "Physical Ethernet interface";
>> }
>>
>>   identity ethSubInterface{
>>     base ianaift:l2vlan;
>>     base sub-interface;
>>     base ethernet-like;
>>
>>     description "Sub-interface of any interface types that uses
>>                  Ethernet framing (with or without 802.1Q tagging)";
>> }
>>
>> Ethernet physical interface configuration would use: derived-from(if:type, 'ietf-ethernet', 'Ethernet')
>> Etherlike configuration (e.g. MAC address) would use: derived-from(if:type, ..., 'ethernet-like')
>> Common physical interface configuration would use: derived-from(if:type, ..., 'physical')
>> Etc.
>>
>>>     3. How is "l2-mtu" related to L3 MTU (under "ip:ipv[46])? What
>>>        about
>>>
>>>          must "not(l2-mtu <= ip:ipv4/ip:mtu)";
>>>
>>>        and similarly for IPv6?
>> Yes, I agree, although possibly the definitions might be cleaner in the ip:ipv4 and ipv6 modules.  I.e. it is better if the higher layers reference the lower layers rather than the other way round.
>>
>> The meaning (and hence name) of the l2-mtu leaf probably needs some more refinement.  Basically, I think that we want to have a tight MTU definition that always includes any and all appropriate layer 2 overheads.  Specifically I want to avoid cases were MTUs are sometimes defined in terms of the layer 3 payload which then don't play nicely with layer 2 services.  But conversely the definition should also work for a pure layer 3 service interface that doesn't have any applicable layer 2 overheads.
> I think ietf-interfaces initially included L2 mtu but then it was decided not to use it. I don't remember exactly what the reason was, perhaps that the concept of MTU differs among L2 interface types.
An alternative choice is to have a separate mtu leaf defined for each 
interface type, but I would expect that this would be annoying for 
clients because they would need to look up the interface type to be able 
to program the MTU (since the mtu leaves would end up in different 
module namespaces)

So I hope that we can come up with a universal definition across all L2 
interface types.  Certainly the OS that I work on has a well defined MTU 
definition that works across all L2 interfaces.

Thanks,
Rob


>
> Lada
>
>>>     4. I think the name "transport-layer" isn't appropriate for an
>>>        enumeration "layer-1"/"layer-2"/"layer-3" because "Transport
>>>        Layer" is the name for "layer-4" in the ISO OSI model.
>> Yes, I think that you are right.  We need to come up with a better name here.
>>
>> Thanks,
>> Rob
>>
>>> Lada
>>>
>>> Robert Wilton  writes:
>>>
>>>> Hi,
>>>>
>>>> Last week I posted slightly revised version of both
>>>> draft-wilton-netmod-intf-ext-yang-01 and
>>>> draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the
>>>> models contained within these two drafts is very welcome, but I would be
>>>> particularly interested in any opinions regarding some slight changes
>>>> for modelling sub-interfaces in the interfaces-extensions draft.
>>>>
>>>> The main changes that I've made to intf-ext-yang-01 are:
>>>>
>>>> 1) I've defined a new "sub-interface" identity to represent the
>>>> behaviour of any interface type that is a representation of a
>>>> sub-interface.  The idea here is to ensure that the common sub-interface
>>>> configuration leaves can be re-used by any other sub-interface types
>>>> that are defined in future models, or possibly vendor specific interface
>>>> types. E.g. the augmentation that adds sub-interface related
>>>> configuration in interfaces-common.yang:
>>>>
>>>> 
>>>>     identity sub-interface {
>>>>       description "Base type for generic sub-interfaces.  New or custom
>>>>                    interface types can derive from this type to
>>>>                    inherit generic sub-interface configuration";
>>>>     }
>>>>
>>>>     augment "/if:interfaces/if:interface" {
>>>>       when "derived-from(if:type,
>>>>                          'ietf-if-cmn',
>>>>                          'sub-interface') or
>>>>             if:type = 'ianaift:atmSubInterface' or
>>>>             if:type = 'ianaift:frameRelay'"  {
>>>>         description
>>>>           "Any ianaift:types that explicitly represent sub-interfaces
>>>>            or any types that derive from the sub-interface identity";
>>>>       }
>>>>
>>>>       ... sub-interface specific configuration nodes go here.
>>>>     }
>>>> 
>>>>
>>>> If this is accepted as generally a good approach of modelling this in a
>>>> future safe manner, then I was considering also defining an interface
>>>> type that is the common representation of a physical- interfaces for
>>>> some of the other features defined in the interface-extension draft.
>>>>
>>>>
>>>> 2) I've defined a new ethSubInterface identity in interface-common.yang
>>>> that inherits from ianaift:l2vlan and the new sub-interface identity above.
>>>>    - Using Yang 1.1 this will allow the augmentation of the
>>>> parent-interface leaf to be marked as mandatory.
>>>>    - It also solves a possible concern that some vendors may have a
>>>> different interpretation of what the IANA interface type "l2vlan"
>>>> actually means (noting that the IANA only provides a slightly vague
>>>> definition).
>>>>
>>>> I.e.
>>>> 
>>>>     identity ethSubInterface{
>>>>       base ianaift:l2vlan;
>>>>       base sub-interface;
>>>>
>>>>       description "Sub-interface of any interface types that uses
>>>>                    Ethernet framing (with or without 802.1Q tagging)";
>>>>     }
>>>> 
>>>>
>>>> 3) The features above mean that module is marked a being Yang version
>>>> 1.1 only.
>>>>
>>>> Any feedback is appreciated.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Tue Oct 27 09:53:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A41AC40A for ; Tue, 27 Oct 2015 09:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IcHO5cZxjxC for ; Tue, 27 Oct 2015 09:53:49 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB0A1AC40C for ; Tue, 27 Oct 2015 09:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3573; q=dns/txt; s=iport; t=1445964828; x=1447174428; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GvhLny/5bADbeHAid8+PEWA75Tn3BbExK1uoqf6mrEA=; b=FRCvfpMbk6Ne5HUfY5kPPAfDHshS+7WMFN1/nYc6HKWAXOjUJ9ZviWvq YUfKYpxwXJkCUfybrOMLoOoS1e2YFC87npJfOZHLEBgp5HUO7raHpJJYO ILpVpUixSHMQEzLFcsziHDaQXvSjm07fng1NxyAx6TAz9K/wSFRYjE6K4 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CpBACQqy9W/xbLJq1exWiDQ4JXAoILAQEBAQEBgQALhDMBAQQ4QBELGAkWDwkDAgECAUUGDQgBAYgsxgcBAQEBAQEBAQIBAQEBAR6Gd4R+hRSELgEEljiNJIFZhD+DAZMZY4IRHYFWPoYiAQEB
X-IronPort-AV: E=Sophos;i="5.20,205,1444694400"; d="scan'208";a="607814253"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 27 Oct 2015 16:53:45 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9RGrjLC008759 for ; Tue, 27 Oct 2015 16:53:45 GMT
To: "netmod@ietf.org" 
References: <562E4BA9.4060106@cisco.com>  <562F9449.3040504@cisco.com> <20151027152918.GA58184@elstar.local>
From: Robert Wilton 
Message-ID: <562FAC02.3010806@cisco.com>
Date: Tue, 27 Oct 2015 16:53:22 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151027152918.GA58184@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 16:53:50 -0000

On 27/10/2015 15:29, Juergen Schoenwaelder wrote:
> On Tue, Oct 27, 2015 at 03:12:09PM +0000, Robert Wilton wrote:
>> Hi Lada,
>>
>> Thanks for the review and comments, please see inline ...
>>
>> On 27/10/2015 13:25, Ladislav Lhotka wrote:
>>> Hi Rob,
>>>
>>> I think both modules are useful extensions to ietf-interfaces, and I
>>> would support adopting it as a NETMOD work item. I have a few
>>> comments/questions:
>>>
>>>     1. You are using several YANG 1.1 features (multiple identityref
>>>        bases, mandatory nodes in augments), so you should have 6020bis
>>>        as a normative reference rather than RFC 6020.
>> Yes, I'll fix this.
>>
>>>     2. "when" expressions in the module "interfaces-ethernet-like"
>>>        demonstrate that IANA interface types are pretty much
>>>        useless. Not only is it necessary to list all ethernet-like
>>>        interface types one by one, but it also isn't extensible: these
>>>        augments won't apply to new ethernet-like types.
>> Yes, I agree.
>>
>> The other concern that I have with the IANA interface types is that I
>> feel that their importance has changed somewhat.
>>
>> In the past, it feels like the IANA interface type was just a label to
>> attach to an interface to help the operator understand what type of
>> interface is was, e.g. a bit like a description.  As such, I think that
>> historically vendors may interpret the meaning of the interface types
>> somewhat differently and it didn't really matter very much.
>>
> IANA interface types are actually a bit more than just a label since
> there are several interface type specific MIB modules that are
> registered in the transmission OID branch and the registration number
> usually matches the interface type number in the IANA registry. But
> yes, for monitoring, a broad classification is usually sufficient.
> For configuration, one likes to have more details but then our
> understanding of interfaces has evolved a lot over the years (and
> producing a new interface classification model that can sustain
> another 30+ years is likely tricky).
Yes, the problem that I'm trying to solve is that I'm trying to define 
common configuration that spans across multiple interface types (to 
avoid having per interface type configuration in separate modules, so 
that even if they have the same leaf names they would be in different 
module namespaces).

One choice is to just make the configuration available on all interface 
types, but this somewhat pollutes the global YANG structure , and I 
think that it makes the data model harder to use because the client 
can't necessary determine which configuration leaves are really valid.

The alternative choice is to restrict the configuration down to the set 
of interface types that it applies to.  However, the problem here is 
that it is hard to find the correct set of interface types (out of the 
260 that available) to restrict it to.  Especially since quite a few of 
the IANA interface types are vendor specific, and probably meaningless 
to everyone else.

Other than breaking with convention, I can see a clear benefit if all 
new vendor specific interface types were defined in the module that 
defines the associated new interface type specific configuration for 
them rather than being added to the centralized IANA list.

But I also see benefit in having a cleaner way to reference the existing 
interface types in a way that is easy to understand and extensible.

Thanks,
Rob


>
> /js
>


From nobody Tue Oct 27 10:51:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9171ACD7E for ; Tue, 27 Oct 2015 10:51:13 -0700 (PDT)
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 Ri2V3DOdTZQp for ; Tue, 27 Oct 2015 10:51:10 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50911ACD7C for ; Tue, 27 Oct 2015 10:51:09 -0700 (PDT)
Received: by lbbwb3 with SMTP id wb3so69633430lbb.1 for ; Tue, 27 Oct 2015 10:51:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=ap9uYCO6r0luLdzAZUcl65/nTKxf716hP/hAMVVZb4U=; b=1ZPUv3R07rd26i1nfBdimVmF1T7vUdsrSrJQ/TSOuCrdyhLqNTSlJ2qThlNnM5kwFO J8qib1tYwq8nd2EsZl3Y6hVvj/imJQnAniBNiAC2WKwTHCARPz+0VBKsNZanDlvGOeM8 LuavlzFtfDbqOoQw7ws/xKNt5wlNDuLNDsdtcZ4LaXxK4yshCxLEs93eXTbCsmFtlZ26 7ZukFtpSRBN71/p7k9rM6TmFSsYK5sWJ8AyRVOm0YLoQthJ6tsxmWCZeqF/OJDivQa1/ WkNuVSf0tmXaawNRwd1cpUgVsmj6YNLElKTtJmEuhyD0FuwwGjgsb0y36IGS0ul6TAUz x3wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ap9uYCO6r0luLdzAZUcl65/nTKxf716hP/hAMVVZb4U=; b=fh6dxWF9MZM+OEVgQFTos/jiLxAzmxfhC4hZ799hWYuI2x/LxO/YwoDbTRNX0WowXo lFApPTUqpvSjXI9ExbX4zFYqDtmfI9e9OkYXBqFlJ0T+CVZJp+xuLTHnpqzsBAFAty0j Rm5RPMtoX6F7r6j6qIRDa7VDSwL4PHXSJac1VHbffytJkudbtC5FS10TfUWpxecPsy8S aL9ME1XTcbQ+EtSDtvesYNE6NxPcQJ424PagVWTbmsNJyKyCYr4oTIB3OmYjHYRUiJN3 OBLGPrSCkU3vGuBV7w3E32SWrgN7GyPAXlaORJoR2EHuhL7RvFUDq/dmwLFM/z9U2tjs z/OA==
X-Gm-Message-State: ALoCoQktg/27kimEzfRuUXarj+IKhhVQHnot7no9ddPOnAk6swRZ1bDrPY1kifDTL3Wi0fs2KXwL
MIME-Version: 1.0
X-Received: by 10.112.170.165 with SMTP id an5mr21541824lbc.33.1445968267822;  Tue, 27 Oct 2015 10:51:07 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Tue, 27 Oct 2015 10:51:07 -0700 (PDT)
Date: Tue, 27 Oct 2015 10:51:07 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/mixed; boundary=001a11c37a24f61bb3052319b893
Archived-At: 
Subject: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 17:51:13 -0000

--001a11c37a24f61bb3052319b893
Content-Type: multipart/alternative; boundary=001a11c37a24f61bac052319b891

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

Hi,

Here are my review comments on YANG 1.1.
IMO the document is almost ready for publication.
I plan to implement YANG 1.1 in YumaPro tools soon.


Andy

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


Hi,

Here are my review comments on YANG=
 1.1.
IMO the document is almost ready for publication.
I plan to implement YANG 1.1 in YumaPro tools soon.


Andy



--001a11c37a24f61bac052319b891--
--001a11c37a24f61bb3052319b893
Content-Type: text/plain; charset=US-ASCII; name="review1.txt"
Content-Disposition: attachment; filename="review1.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ig9o23ki0

UmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMtMDgudHh0CkFuZHkgQmllcm1h
bgoyMDE1LTEwLTI3CgpTZWMgMToKICAtIHRleHQgYWJvdXQgJ3Byb3Bvc2VkIHRvIGJlIHVzZWQn
IHNob3VsZCBiZSAnZ29pbmcgdG8gYmUgdXNlZCc7CiAgICBSRVNUQ09ORiBhbmQgSlNPTiBkcmFm
dHMgcGFydCBvZiBzYW1lIFdHIGNoYXJ0ZXIgYXMgWUFORyAxLjEKCiAtIFJFU1RDT05GIG5lZWRz
IHRvIGJlIGluIHNjb3BlCiAgICAgIk90aGVyIHByb3RvY29scyBhbmQgZW5jb2RpbmdzIGFyZSBw
b3NzaWJsZSwgYnV0IG91dCBvZiBzY29wZSBmb3IgdGhpcwogICAgICBzcGVjaWZpY2F0aW9uLiIK
ClNlYy4gMS4xCiAgIG8gIE1hZGUgIndoZW4iIGFuZCAiaWYtZmVhdHVyZSIgaWxsZWdhbCBvbiBs
aXN0IGtleXMsIHVubGVzcyB0aGUKICAgICAgcGFyZW50IGlzIGFsc28gY29uZGl0aW9uYWwsIGFu
ZCB0aGUgY29uZGl0aW9uIG1hdGNoZXMgdGhlIHBhcmVudCdzCiAgICAgIGNvbmRpdGlvbi4KCiAg
LSBUaGlzIGNvbnRyYWRpY3RzIHRleHQgaW4KICAgNy4yMC4yOgogICBBIGxlYWYgdGhhdCBpcyBh
IGxpc3Qga2V5IE1VU1QgTk9UIGhhdmUgYW55ICJpZi1mZWF0dXJlIiBzdGF0ZW1lbnRzLgogICA3
LjIxLjU6CiAgIEEgbGVhZiB0aGF0IGlzIGEgbGlzdCBrZXkgTVVTVCBOT1QgaGF2ZSBhICJ3aGVu
IiBzdGF0ZW1lbnQuCgogIC0gV2hpY2ggaXMgY29ycmVjdD8KICAtIFRoZSA3LiogTVVTVCBOT1Qg
dGV4dCBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIFlBTkcgMS4wCiAgICBJIHRoaW5r
IHRoZSBXRyBhZ3JlZWQgb24gd2hhdCB0aGUgYnVsbGV0IGluIDEuMSBzYXlzLCBub3QgdGhlCiAg
ICBuZXcgcmVzdHJpY3Rpb25zIGluIDcuKgoKU2VjLiA0LjIuMSwgcGFyYSAyOgoKICAgQSBzZXJ2
ZXIgbWF5IGltcGxlbWVudCBhIG51bWJlciBvZiBtb2R1bGVzLCBhbGxvd2luZyBtdWx0aXBsZSB2
aWV3cwogICBvZiB0aGUgc2FtZSBkYXRhLCBvciBtdWx0aXBsZSB2aWV3cyBvZiBkaXNqb2ludCBz
dWJzZWN0aW9ucyBvZiB0aGUKICAgc2VydmVyJ3MgZGF0YS4gIEFsdGVybmF0aXZlbHksIHRoZSBz
ZXJ2ZXIgbWF5IGltcGxlbWVudCBvbmx5IG9uZQogICBtb2R1bGUgdGhhdCBkZWZpbmVzIGFsbCBh
dmFpbGFibGUgZGF0YS4KCiAtIFdoYXQgZG9lcyAnbXVsdGlwbGUgdmlld3Mgb2YgdGhlIHNhbWUg
ZGF0YScgcmVhbGx5IG1lYW4/CiAtIFNob3VsZCAnbWF5JyBiZSAnTUFZJz8KClNlYy4gNS42LjQ6
IHBhcmEgMjoKCiAgIEEgc2VydmVyIE1VU1QgTk9UIGltcGxlbWVudCBtb3JlIHRoYW4gb25lIHJl
dmlzaW9uIG9mIGEgbW9kdWxlLgoKIC0gSU1PIHRoaXMgc2hvdWxkIGEgU0hPVUxEIE5PVCBvciAn
TVVTVCBOT1QgYWR2ZXJ0aXNlJyBpbnN0ZWFkCiAgIG9mIE1VU1QgTk9UIGltcGxlbWVudAoKICAg
RXhhbXBsZSBvZiBwb3NzaWJsZSBleGNlcHRpb246CiAgICAtIHJldiBOLTEgaGFzIG9iamVjdCBu
ZWVkZWQgYnkgYXBwbGljYXRpb24KICAgIC0gcmV2IE4gaGFzIHRoYXQgb2JqZWN0IHNldCB0byBz
dGF0dXMgJ29ic29sZXRlJyAoYW5kIHJlbW92ZWQpCiAgICAtIHJldiBOIGFsc28gaGFzIG90aGVy
IG9iamVjdHMgdW5yZWxhdGVkIHRvIHRoZSBvYnNvbGV0ZSBvYmplY3QKICAgICAgYnV0IGRlc2ly
ZWQgZm9yIHRoZSBwcm9kdWN0IGZlYXR1cmUgc2V0CgpTZWMuIDUuNi40OgogIC0gcGFyYSA0OiB0
aGUgcnVsZXMgZm9yIHBvcHVsYXRpbmcgdGhlIFlBTkcgbGlicmFyeSBzaG91bGQgcHJvYmFibHkg
YmUKICAgIGluIHRoZSB5YW5nLWxpYnJhcnkgZHJhZnQKICAtIHRoZSBleGFtcGxlIG9uIHBhZ2Ug
MzUgLSAzNyBzaG91bGQgcHJvYmFibHkgYmUgaW4gdGhlCiAgICB5YW5nLWxpYnJhcnkgZHJhZnQK
ClNlYy4gNS42LjUuICBBbm5vdW5jaW5nIENvbmZvcm1hbmNlIEluZm9ybWF0aW9uIGluIE5FVENP
TkYKCiAgLSBUaGlzIHNob3VsZCByZWFsbHkgYmUgaW4gYSBORVRDT05GIDEuMiBzcGVjCiAgLSBS
RVNUQ09ORiBkcmFmdCBkZWZpbmVzIGlldGYteWFuZy1saWJyYXJ5IHJlcXVpcmVtZW50cyBmb3Ig
UkVTVENPTkYuCiAgICBXaHkgc2hvdWxkIFlBTkcgMS4xIGRlZmluZSBORVRDT05GIGlldGYteWFu
Zy1saWJyYXJ5IHJlcXVpcmVtZW50cz8KClNlYy4gNS43OiBEYXRhc3RvcmUgTW9kaWZpY2F0aW9u
CgogIC0gVGhpcyBzZWN0aW9uIGlzIE5FVENPTkYgc3BlY2lmaWMgZm9yIG5vIGFwcGFyZW50IHJl
YXNvbgoKU2VjLiA2LjQuMTogYnVsbGV0IDUKCiAgIG8gIFRoZSBzZXQgb2YgdmFyaWFibGUgYmlu
ZGluZ3MgaXMgZW1wdHkuCgogIC0gVGhpcyBpcyBub3QgdHJ1ZS4gIFRoZSBOQUNNIGRhdGEgbW9k
ZWwgZGVmaW5lcyB0aGUgVVNFUiB2YXJpYWJsZS4KICAgIFRoaXMgdGV4dCBzaG91bGQgc2F5IHRo
YXQgWUFORyBtb2R1bGVzIE1BWSBkZWZpbmUgdmFyaWFibGUgYmluZGluZ3MKICAgIGFzc29jaWF0
ZWQgd2l0aCBjb25mb3JtYW5jZSBmb3IgdGhhdCBtb2R1bGUgKGxpa2UgTkFDTSBkb2VzKS4KCgpT
ZWMuIDYuNC4xOiBYUGF0aCBhY2Nlc3NpYmxlIHRyZWUKCiAgLSBJIG9iamVjdCB0byBleHBhbmRp
bmcgdGhlIGNvbnRleHQgb2YgWFBhdGggZXZhbHVhdGlvbiBmb3IKICAgIG5vdGlmaWNhdGlvbiBh
bmQgcnBjL2lucHV0LCBycGMvb3V0cHV0LiAgVGhpcyBpcyB0b28gY29tcGxpY2F0ZWQKICAgIHRv
IGltcGxlbWVudCBhbmQgdW5kZXItc3BlY2lmaWVkLCByZXN1bHRpbmcgaW4gcG9vciBpbnRlcm9w
ZXJhYmlsaXR5LgoKICAtIFdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoaXMgZXhwYW5z
aW9uIG9mIGNvbXBsZXhpdHk/CiAgICBBbiB0b29sIGNhbm5vdCByZXByb2R1Y2UgdGhlIHNhbWUg
cmVzdWx0IGFueW1vcmUgZm9yCiAgICA8cnBjPiwgPHJwYy1yZXBseT4gb3IgPG5vdGlmaWNhdGlv
bj4gb2ZmbGluZSB2YWxpZGF0aW9uLgoKIC0gTm90aWZpY2F0aW9uIGNvbnRleHQgZXhwYW5kZWQg
ZnJvbSBub3RpZmljYXRpb24gbWVzc2FnZSB0byBtZXNzYWdlICsKICAgcnVubmluZyBjb25maWcg
KyBvcGVyYXRpb25hbCBzdGF0ZTsgIFdoZW4gaXMgdGhlIHNlcnZlciBzdXBwb3NlZAogICB0byBn
YXRoZXIgYW5kIGNoZWNrIGFsbCB0aGUgZGF0YSBub2Rlcz8gRXZlbnQgdGltZT8gQnVmZmVyIHRp
bWU/CiAgIFNlbmQgdGltZT8gV2hhdCBpZiBvcGVyYXRpb25hbCBzdGF0ZSBvciBjb25maWcgY2hh
bmdlcyB3aGlsZSB0aGUKICAgbm90aWZpY2F0aW9uIGlzIGluIHRoZSByZXBsYXkgYnVmZmVyPwoK
IC0gUlBDIGlucHV0IGNvbnRleHQgZXhwYW5kZWQgZnJvbSBpbnB1dCBtZXNzYWdlIHRvIG1lc3Nh
Z2UgKwogICBydW5uaW5nIGNvbmZpZyArIG9wZXJhdGlvbmFsIHN0YXRlOyAgV2hlbiBpcyB0aGUg
c2VydmVyIHN1cHBvc2VkCiAgIHRvIGdhdGhlciBhbmQgY2hlY2sgYWxsIHRoZSBkYXRhIG5vZGVz
PyBQYXJzZSB0aW1lPyBCdWZmZXIgdGltZT8KICAgSW52b2NhdGlvbiB0aW1lPwoKIC0gUlBDIG91
dHB1dCBjb250ZXh0IGV4cGFuZGVkIGZyb20gaW5wdXQgbWVzc2FnZSB0byBtZXNzYWdlICsKICAg
cnVubmluZyBjb25maWcgKyBvcGVyYXRpb25hbCBzdGF0ZTsgIElzIHRoZSBzZXJ2ZXIgc3VwcG9z
ZWQgdG8KICAgd2FpdCBmb3Igb3BlcmF0aW9uYWwgc3RhdGUgdGhhdCBtYXkgY2hhbmdlIGFzIGEg
cmVzdWx0IG9mIHRoZQogICBhY3Rpb24gb3IgcnBjIGJlaW5nIGludm9rZWQ/CgogLSBUaGUgZXhw
YW5kZWQgY29udGV4dHMgZm9yIG5vdGlmaWNhdGlvbiBhbmQgcnBjIHN0YXRlbWVudHMKICAgcmVx
dWlyZSBjb3VwbGluZyBvZiB0aGUgbm90aWZpY2F0aW9uIGFuZCBSUEMgcHJvY2Vzc2luZwogICBp
bXBsZW1lbnRhdGlvbiBjb21wb25lbnRzIHRvIHRoZSBkYXRhc3RvcmUgYW5kIG9wZXJhdGlvbmFs
IGRhdGEuCiAgIFRoaXMgaXMgYSBiaWcgY2hhbmdlIGZyb20gY3VycmVudCBORVRDT05GIHJlcXVp
cmVtZW50cy4KICAgWUFORyBzaG91bGQgbm90IGJlIG1ha2luZyBhbnkgY2hhbmdlcyB0byBORVRD
T05GLCBidXQgaXQgZG9lcwogICBpbiBzZXZlcmFsIHBsYWNlcywgZWZmZWN0aXZlbHkgY3JlYXRp
bmcgYSBuZXcgdW5kZWNsYXJlZAogICB2ZXJzaW9uIG9mIHRoZSBORVRDT05GIHByb3RvY29sCgog
LSBJdCBpcyBub3QgY2xlYXIgaWYgImFjdGlvbiIgYW5kICJub3RpZmljYXRpb24iIHN0YXRlbWVu
dHMKICAgbmVzdGVkIGluIHRoZSBkYXRhIHRyZWUgYXJlIHZpc2libGUgYXQgYWxsIGZvciBYUGF0
aCBldmFsdWF0aW9uLgogICAoVGhleSBNVVNUIE5PVCBiZSB2aXNpYmxlKQoKIC0gTkVUQ09ORiA8
Z2V0PiBhbmQgPGdldC1jb25maWc+ICJmaWx0ZXIiIGVsZW1lbnQgbmVlZHMgY2xhcmlmaWNhdGlv
bgogICB3cnQvIGFjdGlvbiBhbmQgbm90aWZpY2F0aW9uIHdpdGhpbiB0aGUgZGF0YSB0cmVlCgog
LSBORVRDT05GIGFuZCBSRVNUQ09ORiBub3RpZmljYXRpb25zICJmaWx0ZXIiIGVsZW1lbnQgbmVl
ZHMgY2xhcmlmaWNhdGlvbgogICB3cnQvIGFjdGlvbiBhbmQgbm90aWZpY2F0aW9uIHdpdGhpbiB0
aGUgZGF0YSB0cmVlCgpTZWMuIDcuNS4zOiBtdXN0OiBsYXN0IHBhcmEKCiAgIEFsc28gbm90ZSB0
aGF0IHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGNvbmNlcHR1YWxseSBldmFsdWF0ZWQuICBUaGlz
CiAgIG1lYW5zIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gZG9lcyBub3QgaGF2ZSB0byB1c2UgYW4g
WFBhdGggZXZhbHVhdG9yCiAgIGluIHRoZSBzZXJ2ZXIuICBIb3cgdGhlIGV2YWx1YXRpb24gaXMg
ZG9uZSBpbiBwcmFjdGljZSBpcyBhbgogICBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbi4KCgpTZWMu
IDcuNS40LjIuICBUaGUgZXJyb3ItYXBwLXRhZyBTdGF0ZW1lbnQKCiAgIFRoZSAiZXJyb3ItYXBw
LXRhZyIgc3RhdGVtZW50LCB3aGljaCBpcyBvcHRpb25hbCwgdGFrZXMgYSBzdHJpbmcgYXMKICAg
YW4gYXJndW1lbnQuICBJZiB0aGUgY29uc3RyYWludCBldmFsdWF0ZXMgdG8gZmFsc2UsIHRoZSBz
dHJpbmcgaXMKICAgcGFzc2VkIGFzIDxlcnJvci1hcHAtdGFnPiBpbiB0aGUgPHJwYy1lcnJvcj4g
aW4gTkVUQ09ORi4KCiAtIGFsbCB0aGUgZXJyb3ItbWVzc2FnZSBhbmQgZXJyb3ItYXBwLXRhZyBz
dWItc2VjdGlvbnMgYXBwbHkgdG8KICAgUkVTVENPTkYgYXMgd2VsbCBhcyBORVRDT05GLiAgVGhl
eSBzaGFyZSB0aGUgc2FtZSBlcnJvciByZXBvcnRpbmcKICAgc3RydWN0dXJlCgoKU2VjLiA3LjUu
ODoKU2VjLiA3LjYuNzoKU2VjLiA3LjcuOToKU2VjLiA3LjkuNjoKU2VjLiA3LjEwLjM6ICBORVRD
T05GIDxlZGl0LWNvbmZpZz4gT3BlcmF0aW9ucwoKIC0gQ2FuIHRoZXNlIHNlY3Rpb25zIGJlIGNo
YW5nZWQgdG8gJ0NvbmZpZ3VyYXRpb24gRGF0YXN0b3JlIEVkaXQKICAgT3BlcmF0aW9ucycgYW5k
IGJlIGdlbmVyaWMgc28gdGhleSBmb2N1cyBvbiB0aGUgY29udGVudHMgb2YKICAgdGhlIGRhdGFz
dG9yZSBiZWZvcmUgYW5kIGFmdGVyIHRoZSBlZGl0LCB3aXRob3V0IHNwZWNpZnlpbmcKICAgPGVk
aXQtY29uZmlnPiBhcyB0aGUgZWRpdCBvcGVyYXRpb24KCiAtIFJFU1RDT05GIG5lZWRzIHRvIGJl
IHN1cHBvcnRlZCwgb3IgYWxsIHRoaXMgc2hvdWxkIGJlIG1vdmVkCiAgIHRvIE5FVENPTkYgMS4y
CgpTZWMuIDcuNi4xLiAgVGhlIGxlYWYncyBkZWZhdWx0IHZhbHVlCgogLSB0aGlzIHNlY3Rpb24g
c2hvdWxkIG1lbnRpb24gdGhhdCBhIGZhbHNlIGlmLWZlYXR1cmUKICAgb3IgZmFsc2Ugd2hlbi1z
dG10IHJlbW92ZXMgdGhlIHNjaGVtYSBub2RlIGZyb20gdGhlCiAgIHRyZWUsIHdoaWNoIG92ZXJy
aWRlcyBhbGwgdGhpcyB0ZXh0LiBUaGVyZSBpcyBubyBkZWZhdWx0CiAgIHZhbHVlIGlmIHRoZXJl
IGlzIG5vIHNjaGVtYSBub2RlCgogLSBJdCBpcyBjb25mdXNpbmcgdGhhdCAnbXVzdCcgYW5kICd3
aGVuJyB3b3JrIHZlcnkKICAgZGlmZmVyZW50bHkgd3J0LyBkZWZhdWx0LiBtdXN0LXN0bXQgZG9l
cyBub3QgaWdub3JlIGRlZmF1bHRzCiAgIGJ1dCAnd2hlbicgb3ZlcnJpZGVzIGFuZCByZW1vdmVz
IHRoZSAnd2hlbicsIHNvIGl0IG5lZWRzIHRvCiAgIGJlIGV2YWx1YXRlZCBiZWZvcmUgdGhlICdt
dXN0JyBzdG10OgoKICAgbGVhZiBjb25mdXNpbmcgewogICAgIG11c3QgIi9zb21lL3ZhbD00IjsK
ICAgICB3aGVuICIvc29tZS9vdGhlci92YWx1ZS90ZXN0IjsKICAgICBkZWZhdWx0IDQyOwogICAg
IHR5cGUgaW50MzI7CiAgIH0KCgpTZWMuIDcuNy4yLiAgVGhlIGxlYWYtbGlzdCdzIGRlZmF1bHQg
dmFsdWVzCgogLSB0aGlzIHNlY3Rpb24gcmVwcmVzZW50cyAyIG5ldyByZXF1aXJlbWVudHMgdG8g
Y29tcGlsZXJzCiAgIHRoYXQgc2hvdWxkIGJlIG1vcmUgYXBwYXJlbnQ6CgogICAxKSByZW1lbWJl
cmluZyB0aGUgb3JkZXIgb2YgImRlZmF1bHQiIHN0YXRlbWVudHMKICAgMikgdGhlIGRlZmF1bHQg
b25seSBhcHBsaWVzIGlmICdtaW4tZWxlbWVudHMgMCcgaXMgaW4gZWZmZWN0CgogLSB3aGF0IGlz
IHRoZSByYXRpb25hbGUgZm9yIG5vdCBhcHBseWluZyB0aGUgZGVmYXVsdCBpZgogICBtaW4tZWxl
bWVudHMgaXMgPiAwPyAgSXQgbG9va3MgbGlrZSB0aGUgbGVhZi9jb250YWluZXIgcnVsZQogICB0
aGF0IG1hbmRhdG9yeSBhbmQgZGVmYXVsdCBhcmUgbm90IGFsbG93ZWQgdG9nZXRoZXIgaXMKICAg
YmVpbmcgYXBwbGllZCBoZXJlLiAgVGhpcyBzaG91bGQgYmUgbW9yZSBjbGVhciBoZXJlCgpTZWMu
IDcuMTEuICBUaGUgYW55eG1sIFN0YXRlbWVudAoKIC0gVGhlICdhbnl4bWwnIHN0YXRlbWVudCBz
aG91bGQgYmUgZGVwcmVjYXRlZC4KICAgSWYgbm90LCB0aGlzIHNlY3Rpb24gbmVlZHMgdG8gcHJv
dmlkZSByYXRpb25hbGUgZm9yCiAgIGl0cyAnY3VycmVudCcgc3RhdHVzLCBnaXZlbiB0aGF0ICdh
bnlkYXRhJyBoYXMgYmVlbiBhZGRlZAogICBObyB1c2UgY2FzZXMgYXJlIHByb3ZpZGVkIGZvciBh
bnl4bWwgaW4gdGhlIGRyYWZ0LgoKIC0gVGhlcmUgYXJlIGZldyBpZiBhbnkgc2VydmVycyB0aGF0
IHN1cHBvcnQgYW55eG1sIHRoZSB3YXkKICAgaXQgaXMgZGVmaW5lZCBoZXJlLCBhbmQgdGhhdCBp
cyBub3QgbGlrZWx5IHRvIGNoYW5nZS4KICAgVGhlIGRyYWZ0IGRvZXMgbm90IHNwZWNpZnkgaG93
IHRoZSBYTUwgbXVzdCBiZSBwYXJzZWQsCiAgIHN0b3JlZCwgb3IgcmVuZGVyZWQgbGF0ZXIsIGlm
IGl0IGlzIHBhcnQgb2YgY29uZmlndXJhdGlvbgoKU2VjLiA3LjE1LiAgVGhlIGFjdGlvbiBTdGF0
ZW1lbnQKCiAtIGFuIGFjdGlvbiBtdXN0IGFwcGVhciBkaXJlY3RseSB3aXRoaW4gYSBjb250YWlu
ZXIgb3IgYQogICBsaXN0LCBhbiAnYXVnbWVudCcgb3IgYSAndXNlcycgc3RhdGVtZW50LgogICBX
aHkgaXMgJ2Nhc2UnIHN0YXRlbWVudCBsZWZ0IG91dCBvZiBkaXJlY3QgdXNhZ2UgYW5kCiAgIG9u
bHkgYWxsb3dlZCB2aWEgJ3VzZXMnIG9yICdhdWdtZW50Jz8KCiAtIHBhcmEgMjogZ3JvdXBpbmdz
IGFyZSBub3QgcmV1c2FibGUgaWYgdGhleSBjb250YWluIGFjdGlvbnMsCiAgIHNpbmNlIHRoZXkg
YXJlIG5vdCBhbGxvd2VkIGluIHJwYywgbm90aWZpY2F0aW9uLCBvciBhY3Rpb24KICAgVGhpcyBz
aG91bGQgYmUgcG9pbnRlZCBvdXQgaW4gdGhlIHNlY3Rpb24gb24gZ3JvdXBpbmdzCgogLSB0aGUg
cmVhc29uIGZvciB0aGUgcmVzdHJpY3Rpb24gb24gdG9wLWxldmVsIGFjdGlvbiBpcyBub3QKICAg
Z2l2ZW4uICBUaGUgc3ludGF4IHdvdWxkIHN1cHBvcnQgdGhpcywgYW5kIHRoZSBpZGVudGlmaWVy
CiAgIG5hbWVzcGFjZSBpcyBzaGFyZWQgKHNhbWUgYXMgcnBjKS4KCiAtIHRoZSBjb250ZXh0IG5v
ZGVzIGZvciBhY3Rpb24gaW5wdXQgYW5kIG91dHB1dCBhcmUgdmVyeSBkaWZmZXJlbnQKICAgdGhp
cyBjb3VsZCBiZSBtb3JlIGNsZWFyCgogLSBpcyB0aGUgc2VydmVyIHJlcXVpcmVkIHRvIHByb2Nl
c3MgWFBhdGggb3IgY29uc3RyYWludHMgb24gdGhlCiAgIG91dHB1dCBhdCBzb21lIHBvaW50IGlu
IHRoZSBleGVjdXRpb24gb2YgdGhlIGFjdGlvbj8KCiAtIHRoZXJlIGlzIG5vIHJhdGlvbmFsZSBn
aXZlbiB3aHkgdGhlIHBpbmcgb3BlcmF0aW9uIHNob3VsZAogICBiZSBkb25lIGFzIGFuIGFjdGlv
biBpbnN0ZWFkIG9mIGFuIFJQQwoKICAgbGlzdCBpbnRlcmZhY2UgewogICAgICAga2V5ICJuYW1l
IjsKCiAgICAgICBsZWFmIG5hbWUgewogICAgICAgICB0eXBlIHN0cmluZzsKICAgICAgIH0KCiAg
ICAgICBhY3Rpb24gcGluZyB7CiAgICAgICAgIGlucHV0IHsKICAgICAgICAgICBsZWFmIGRlc3Rp
bmF0aW9uIHsKICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwogICAgICAgICAgIH0K
ICAgICAgICAgfQogICAgICAgICBvdXRwdXQgewogICAgICAgICAgIGxlYWYgcGFja2V0LWxvc3Mg
ewogICAgICAgICAgICAgdHlwZSB1aW50ODsKICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICAg
IH0KICAgICB9CgogV2h5IG5vdCB1c2UgYW4gUlBDPwogTm8gcmF0aW9uYWxlIGZvciBib3RoIHdh
eXMgdG8gaW1wbGVtZW50IGFuIG9wZXJhdGlvbgogbGlrZSAncGluZycgaXMgZ2l2ZW4uCgogICBy
cGMgcGluZyB7CiAgICAgaW5wdXQgewogICAgICAgbGVhZiBpdGYtbmFtZSB7CiAgICAgICAgIG1h
bmRhdG9yeSB0cnVlOwogICAgICAgICB0eXBlIGlmOmludGVyZmFjZS1yZWY7CiAgICAgICB9CiAg
ICAgICBsZWFmIGRlc3RpbmF0aW9uIHsKICAgICAgICAgdHlwZSBpbmV0OmlwLWFkZHJlc3M7CiAg
ICAgICB9CiAgICAgfQogICAgIG91dHB1dCB7CiAgICAgICBsZWFmIHBhY2tldC1sb3NzIHsKICAg
ICAgICAgdHlwZSB1aW50ODsKICAgICAgIH0KICAgICB9CiAgIH0KClNlYy4gNy4xNi4gIFRoZSBu
b3RpZmljYXRpb24gU3RhdGVtZW50CgogICBJZiBhIGxlYWYgaW4gdGhlIG5vdGlmaWNhdGlvbiB0
cmVlIGhhcyBhICJtYW5kYXRvcnkiIHN0YXRlbWVudCB3aXRoCiAgIHRoZSB2YWx1ZSAidHJ1ZSIs
IHRoZSBsZWFmIE1VU1QgYmUgcHJlc2VudCBpbiBhIG5vdGlmaWNhdGlvbgogICBpbnN0YW5jZS4K
CiAtIFdoeSBpcyB0aGlzIGFwcGx5IHRvIGxlYWYgYnV0IG5vdCBjb250YWluZXIgb3IgY2hvaWNl
PwogICBUaGV5IHNob3VsZCBiZSBtZW50aW9uZWQgaGVyZSBhcyB3ZWxsLgoKIC0gTm8gcmF0aW9u
YWxlIGlzIGdpdmVuIGZvciBkZWZpbmluZyBub3RpZmljYXRpb25zIHdpdGhpbiBkYXRhIG5vZGVz
CiAgIHZzLiB0b3AtbGV2ZWwgbm90aWZpY2F0aW9uLXN0bXQKCiAtIEl0IGlzIG5vdCBjbGVhciBo
b3cgUkZDIDUyNzcgPGZpbHRlcj4gY2FuIGJlIGFwcGxpZWQgdG8gdGhlCiAgICBub3RpZmljYXRp
b24gbWVzc2FnZSB0aGF0IGlzIG5lc3RlZCB3aXRoaW4gZGF0YSwgZ2l2ZW4gdGhlCiAgIGxvY2F0
aW9uIG9mIHRoZSAnbm90aWZpY2F0aW9uJyByb290IHdpdGhpbiB0aGUgZGF0YSB0cmVlIGlzCiAg
IG5vdCBzdGF0aWMsIGFuZCBkaWZmZXJlbnQgZm9yIGVhY2ggbm90aWZpY2F0aW9uLgoKU2VjLiA3
LjE3LiAgVGhlIGF1Z21lbnQgU3RhdGVtZW50CgogLSBjYW4gYXVnbWVudCBwYXRoLXN0bXRzIGNv
bnRhaW4gbmVzdGVkICdhY3Rpb24nIG9yICdub3RpZmljYXRpb24nCiAgIG5vZGVzIGFuZCBzdWJu
b2RlcywgbGlrZSBmb3IgcnBjLXN0bXQ/ICBJZiwgc28gdGhlbiB0aGUKICAgc3ViLXN0YXRlbWVu
dHMgYXJlIHJlc3RyaWN0ZWQgYnkgY29udGV4dCwgZS5nLiwgYWN0aW9uLXN0bXQKICAgY2Fubm90
IGJlIGFkZGVkIHRvIC9mb28vYmFyL2FjdGlvbi9pbnB1dC9iYXouCgpTZWMuIDcuMTguMi4gIFRo
ZSBiYXNlIFN0YXRlbWVudAoKICAtIFRoZXJlIGFyZSBubyBleGFtcGxlcyBvciB1c2UtY2FzZXMg
Z2l2ZW4gZm9yIG11bHRpcGxlIGJhc2UKICAgIHN0YXRlbWVudHMuIEFuIGV4YW1wbGUgc2hvdWxk
IGJlIGFkZGVkLgoKIC0gUGFyYSAxIHNheXM6CiAgICAgIElmIG11bHRpcGxlICJiYXNlIiBzdGF0
ZW1lbnRzIGFyZSBwcmVzZW50LCB0aGUgaWRlbnRpdHkgaXMgZGVyaXZlZAogICAgICBmcm9tIGFs
bCBvZiB0aGVtLgoKICAgVGhlIGRyYWZ0IGRvZXMgbm90IHNheSBob3cgdGhpcyBpcyBkb25lLiBJ
dCBpcyBub3QgY2xlYXIgaG93CiAgIGEgcGFydGljdWxhciBpZGVudGl0eS1zdG10IGhhcyBtdWx0
aXBsZSBiYXNlcyBhbmQgaG93IGEgc2VydmVyCiAgIGRldGVybWluZXMgYW4gaWRlbnRpZnkgaXMg
ZGVyaXZlZCBmcm9tIG11bHRpcGxlIGJhc2VzLiBFeGFtcGxlcwogICBvZiBhICdwYXNzJyBhbmQg
J2ZhaWwnIGZvciB0aGlzIHRlc3Qgc2hvdWxkIGJlIGdpdmVuLgoKU2VjLiA3LjE5LiAgVGhlIGV4
dGVuc2lvbiBTdGF0ZW1lbnQKCiAgICJZQU5HIHN0YXRlbWVudHMgaW4gZXh0ZW5zaW9ucyBNVVNU
IGZvbGxvdyB0aGUgc3ludGFjdGljYWwgcnVsZXMKICAgIGluIFNlY3Rpb24gMTQuIgoKICAtIFdo
YXQgaXMgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBydWxlPyBFeHRlbnNpb24gc3RhdGVtZW50cwog
ICAgc2hvdWxkIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIFlBTkcuIFRoZXkgc2hvdWxkIGp1c3Qg
Zm9sbG93IHRoZQogICAgc3ludGF4IHJ1bGVzIGluIHNlYy4gNi4KCiAtIFRoaXMgc2F5cyBZQU5H
IHN5bnRheCBNVVNUIGJlIHByZXNlcnZlZCwgYnV0IFlBTkcgc2VtYW50aWNzCiAgIGNhbiBiZSBp
Z25vcmVkIG9yIGNoYW5nZWQuICBJcyB0aGF0IHRoZSBpbnRlbnQ/CgogICAiQW4gZXh0ZW5zaW9u
IGNhbiBhbGxvdyByZWZpbmVtZW50IChzZWUgU2VjdGlvbiA3LjEzLjIpIGFuZCBkZXZpYXRpb25z
CiAgIChTZWN0aW9uIDcuMjAuMy4yKSwgYnV0IHRoZSBtZWNoYW5pc20gZm9yIGhvdyB0aGlzIGlz
IGRlZmluZWQgaXMKICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiIK
CiAtIFRoaXMgdGV4dCBhYm91dCByZWZpbmVtZW50IGFuZCBkZXZpYXRpb25zIGlzIG5vdCBjbGVh
ci4KICAgSXMgaXQgTVVTVCwgU0hPVUxELCBvciBNQVk/IEl0IGlzIG5vcm1hdGl2ZSwgYnV0IHVu
c3BlY2lmaWVkLgoKU2VjLiA3LjIwLjIuICBUaGUgaWYtZmVhdHVyZSBTdGF0ZW1lbnQKCiAtIFRo
aXMgc2VjdGlvbiBkb2VzIG5vdCBkZWZpbmUgaG93ICIoIiBpZi1mZWF0dXJlLWV4cHIgIikiIGlz
CiAgIGV2YWx1YXRlZCwgb3IgaG93IHRoZSBwcmVjZWRlbmNlIGlzIGV2YWx1YXRlZCBpZiBwYXJl
bnMgYXJlIHVzZWQuCiAgIEV2YWx1YXRlZCBvZiBuZXN0ZWQgcGFyZW5zIGlzIG5vdCBkZWZpbmVk
IGVpdGhlci4KCiAtIEFyZSBvcGVyYXRvcnMgb2YgdGhlIHNhbWUgdHlwZSBldmFsdWF0ZWQgbGVm
dCB0byByaWdodD8KCiAtIHNob3VsZCBiZSBzb21lIGV4YW1wbGVzIHRvIHNob3cgcHJlY2VkZW5j
ZQogICAibm90IGZvbyBvciBiYXIgYW5kIGJheiIKICAgIihub3QgZm9vKSBvciAoYmFyIGFuZCBi
YXopIgogICAibm90IChmb28gb3IgYmFyKSBhbmQgYmF6IgoKClNlYy4gNy4yMS4yLiAgVGhlIHN0
YXR1cyBTdGF0ZW1lbnQKCiAgIElmIGEgZGVmaW5pdGlvbiBpcyAiY3VycmVudCIsIGl0IE1VU1Qg
Tk9UIHJlZmVyZW5jZSBhICJkZXByZWNhdGVkIiBvcgogICAib2Jzb2xldGUiIGRlZmluaXRpb24g
d2l0aGluIHRoZSBzYW1lIG1vZHVsZS4KCiAgIElmIGEgZGVmaW5pdGlvbiBpcyAiZGVwcmVjYXRl
ZCIsIGl0IE1VU1QgTk9UIHJlZmVyZW5jZSBhbiAib2Jzb2xldGUiCiAgIGRlZmluaXRpb24gd2l0
aGluIHRoZSBzYW1lIG1vZHVsZS4KCiAtIEl0IGlzIG5vdCBjbGVhciB3aGF0IGl0IG1lYW5zIGZv
ciBhIGRlZmluaXRpb24gdG8gcmVmZXJlbmNlCiAgIGFub3RoZXIgZGVmaW5pdGlvbi4KCiAtIFdo
eSBpcyB0aGlzIHJlc3RyaWN0aW9uIGxpbWl0ZWQgdG8gdGhlIHNhbWUgbW9kdWxlIGFuZCBub3QK
ICAgaW5jbHVkZSBpbXBvcnRlZCBtb2R1bGVzPwoKIC0gRG9uJ3QgdGhlICdkZXByZWNhdGVkJyBh
bmQgJ29ic29sZXRlJyB2YWx1ZXMgcmlwcGxlIHVwIHRocm91Z2gKICAgdGhlIGRhdGEgdHJlZSwg
YWxsIHRoZSB3YXkgdG8gdGhlIHRvcC1sZXZlbCBub2RlPyBPdGhlcndpc2UKICAgYSBjdXJyZW50
IGxpc3QgY2FuIGhhdmUgZGVwcmVjYXRlZCBvciBvYnNvbGV0ZSBjaGlsZHJlbi4KICAgSXQgc2hv
dWxkIGJlIGV4cGxhaW5lZCBob3cgc3RhdHVzIGlzIGNvbnRhaW5lZCAob3Igbm90KQogICBmb3Ig
bm9kZXMgd2l0aGluIG90aGVyIHN0YXRlbWVudHMuCgogLSBXaGF0IGRvZXMgaXQgbWVhbiB0byB1
c2UgYSBjdXJyZW50IGdyb3VwaW5nIHRoYXQgY29udGFpbnMgZGVwcmVjYXRlZAogICBvciBvYnNv
bGV0ZSBub2Rlcz8gIElzIHRoaXMgYWxsb3dlZD8KClNlYy4gNy4yMS41LiAgVGhlIHdoZW4gU3Rh
dGVtZW50CgogYnVsbGV0IDM6CiAtIEFsdGVyaW5nIHRoZSB0cmVlIGNoYW5nZXMgbWVhbnMgdGhh
dCBlYWNoIHdoZW4tc3RtdCBwcm9jZXNzZXMKICAgYSBkaWZmZXJlbnQgWE1MIGRvY3VtZW50LiAg
SU1PIGl0IGlzIGEgYmFkIGlkZWEgdG8gcmVwbGFjZSBhCiAgIG5vZGUgdGhhdCBpcyBpbiB0aGUg
dHJlZSB3aXRoIGEgZHVtbXkgbm9kZS4gIEl0IGlzIE9LIHRvIGNyZWF0ZQogICBhIHRlbXAgZHVt
bXkgbm9kZSBhcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgdG8gZGVjaWRlIGlmCiAgIGEgd2hl
bi1zdG10IGlzIHRydWUgb3Igbm90LgoKICJJZiB0aGUgWFBhdGggZXhwcmVzc2lvbiByZWZlcmVu
Y2VzIGFueSBub2RlIHRoYXQgYWxzbyBoYXMgYXNzb2NpYXRlZAogIndoZW4iIHN0YXRlbWVudHMs
IHRoZXNlICJ3aGVuIiBleHByZXNzaW9ucyBNVVNUIGJlIGV2YWx1YXRlZCBmaXJzdC4KIFRoZXJl
IE1VU1QgTk9UIGJlIGFueSBjaXJjdWxhciBkZXBlbmRlbmNpZXMgaW4gdGhlc2UgIndoZW4iCiBl
eHByZXNzaW9ucy4iCgogLSBUaGlzIHJlcXVpcmVtZW50IGlzIG5vdCBpbXBsZW1lbnRhYmxlIGFu
ZCBuZWVkcyB0byBiZSByZW1vdmVkLgogICBUaGUgZHJhZnQgc2hvdWxkIGp1c3Qgc2F5IHdoYXQg
dGhlIHJlc3VsdCBpcyBzdXBwb3NlZCB0byBiZQogICAoYW5kIGl0IGRvZXMgLS0gYWxsIG5vZGVz
IHdpdGggZmFsc2Ugd2hlbi1zdG10cyBhcmUgcmVtb3ZlZCkKCiAiTm90ZSB0aGF0IHRoZSBYUGF0
aCBleHByZXNzaW9uIGlzIGNvbmNlcHR1YWxseSBldmFsdWF0ZWQuICBUaGlzIG1lYW5zCiAgdGhh
dCBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBoYXZlIHRvIHVzZSBhbiBYUGF0aCBldmFsdWF0
b3IgaW4gdGhlCiAgc2VydmVyLiAgVGhlICJ3aGVuIiBzdGF0ZW1lbnQgY2FuIHZlcnkgd2VsbCBi
ZSBpbXBsZW1lbnRlZCB3aXRoCiAgc3BlY2lhbGx5IHdyaXR0ZW4gY29kZS4iCgogLSBUaGUgcnVs
ZXMgZm9yIGhvdyB0byBwcm9jZXNzIGEgd2hlbi1zdG10IGNvbnRyYWRpY3QgdGhpcwogICB0ZXh0
IGF0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24gdGhhdCB3aGVuLXN0bXQgaXMgb25seQogICBjb25j
ZXB0dWFsLiAgTm8gaW1wbGVtZW50YXRpb24gZGV0YWlscyBzaG91bGQgYmUgbWFuZGF0ZWQuCgoK
U2VjLiA4LjE6IENvbnN0cmFpbnRzIG9uIERhdGEKCiAtIGJ1bGxldHMgc2F5IGNvbnN0cmFpbnQg
TVVTVCBiZSB0cnVlLCBidXQgdGhpcyBpbmZvIHNob3VsZCByZWFsbHkKICAgYmUgcGFydCBvZiBO
RVRDT05GLCBhbmQgc2hvdWxkIHNheSB3aGF0IGEgTkVUQ09ORiBzZXJ2ZXIgc2hvdWxkCiAgIHNv
IHdoZW4gYSBjb25zdHJhaW50IGlzIGZhbHNlCgpTZWMuIDguMi4xLiAgUGF5bG9hZCBQYXJzaW5n
CgogLSBUaGUgTkVUQ09ORi1zcGVjaWZpYyBlcnJvciBoYW5kbGluZyB0ZXh0IHNob3VsZCBiZSBt
YWRlIG1vcmUgZ2VuZXJpYwoKU2VjLiA4LjIuMi4gIE5FVENPTkYgPGVkaXQtY29uZmlnPiBQcm9j
ZXNzaW5nCgogIC0gVGhpcyB0ZXh0IHNob3VsZCBiZSBtb3JlIGdlbmVyaWMgaWYgcG9zc2libGUu
CiAgLSBXaHkgZG8gYWxsIHRoZSBORVRDT05GIGltcGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cyBh
cHBseSBvbmx5CiAgICB0byA8ZWRpdC1jb25maWc+IGFuZCBub3QgYWxzbyA8Y29weS1jb25maWc+
PwoKU2VjLiA5LjYuNC4xLiAgVGhlIGVudW0ncyBTdWJzdGF0ZW1lbnRzClNlYy4gOS43LjQuMS4g
IFRoZSBiaXQncyBTdWJzdGF0ZW1lbnRzCgogLSBleGFtcGxlIG9mIGlmLWZlYXR1cmUgc2hvdWxk
IGJlIGdpdmVuCiAtIEl0IHNob3VsZCBiZSBleHBsaWNpdGx5IHN0YXRlZCB0aGF0IGlmLWZlYXR1
cmUgaGFzIG5vIGVmZmVjdAogICBvbiBhdXRvLW51bWJlcmluZwogLSB3aGF0IGhhcHBlbnMgaWYg
YSBmZWF0dXJlIHZhbHVlIGlzIGNoYW5nZWQgYXQgYm9vdC10aW1lIG9yIHJ1bi10aW1lLAogICBj
YXVzaW5nIHZhbGlkIGVudW1lcmF0aW9uIG9yIGJpdHMgdmFsdWVzIHdpdGhpbiBhIGRhdGFzdG9y
ZSB0bwogICBzdWRkZW5seSBiZWNvbWUgaW52YWxpZD8gIENoYW5naW5nIHRoZSB2YWx1ZSBzZXQg
b2YgYSBsZWFmIG9yIGxlYWYtbGlzdAogICB3aXRoIGlmLWZlYXR1cmUgaXMgdmVyeSBjb21wbGlj
YXRlZCBhbmQgdW5kZXItc3BlY2lmaWVkCgpTZWMuIDkuOS4xLiAgKExlYWZyZWYpIFJlc3RyaWN0
aW9ucwoKIC0gY2FuIGxlYWZyZWYgcmVxdWlyZS1pbnN0YW5jZSBiZSBjaGFuZ2VkIHZpYSB0eXBl
ZGVmPwoKICAgdHlwZWRlZiBmb28tcHRyIHsKICAgICB0eXBlIGxlYWZyZWYgewogICAgICAgcGF0
aCAiL3NvbWUvbm9kZS9mb28iOwogICAgIH0KICAgfQoKICAgdHlwZWRlZiBmb28tcHRyMiB7CiAg
ICAgdHlwZSBmb28tcHRyIHsKICAgICAgIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2U7CiAgICAgfQog
ICB9CgpTZWMuIDkuMTAuNS4gIChJZGVudGl0eXJlZikgVXNhZ2UgRXhhbXBsZQoKIC0gQWRkIGFu
IGV4YW1wbGUgYW5kIHVzZS1jYXNlIHNob3dpbmcgbXVsdGlwbGUgYmFzZS1zdG10cwogICBmb3Ig
YW4gaWRlbnRpdHlyZWYKClNlYy4gOS4xMi4gIFRoZSB1bmlvbiBCdWlsdC1JbiBUeXBlCgogLSBX
aGF0IGhhcHBlbnMgdG8gYSB1bmlvbiB0eXBlIHdoZW4gYSBmZWF0dXJlIGlzIGVuYWJsZWQgb3Ig
ZGlzYWJsZWQsCiAgIGFuZCB0aGVyZSBhcmUgMSBvciBtb3JlIGJpdHMgb3IgZW51bWVyYXRpb24g
bWVtYmVyIHR5cGVzIHRoYXQgYXJlCiAgIGFmZmVjdGVkLCBzdWNoIHRoYXQgdGhlIG1lbWJlciB0
eXBlIGNoYW5nZXM/IElzIHRoaXMganVzdCBhbgogICBpbXBsZW1lbnRhdGlvbiBkZXRhaWw/CgoK
U2VjLiAxMC4xLjEuICBjdXJyZW50KCkKCiAtIGFuIGV4YW1wbGUgZm9yIGN1cnJlbnQoKSBzaG91
bGQgYmUgZ2l2ZW4KClNlYy4gMTAuMy4xLiAgZGVyZWYoKQoKIC0gd2h5IGlzIHRoaXMgWFBhdGgg
ZnVuY3Rpb24gbmVlZGVkPwogICBObyB1c2UtY2FzZXMgYXJlIGV4cGxhaW5lZC4KICAgVGhlIGV4
YW1wbGUgZ2l2ZW4gc2hvd3MgdGhhdCBkZXJlZiguKSBzYXZlcyBzb21lIGV4dHJhIHR5cGluZwog
ICBmcm9tIHRoZSBwcmV2aW91cyBsaW5lLiAgTm90IHZlcnkgaW50ZXJlc3RpbmcgbmV3IGZlYXR1
cmUuCiAtIHdoYXQgaWYgdGhlIGZpcnN0IG5vZGUgaW4gdGhlIHBhcmFtZXRlciBub2RlLXNldCBp
cyBhbm90aGVyCiAgIGxlYWZyZWY/ICBEb2VzIHRoaXMgZnVuY3Rpb24ga2VlcCBkZS1yZWZlcmVu
Y2luZyB1bnRpbCBpdAogICBnZXRzIHRvIGEgcGxhaW4gbGVhZj8KCgpTZWMuIDEwLjQuMS4gIGRl
cml2ZWQtZnJvbSgpClNlYy4gMTAuNC4yLiAgZGVyaXZlZC1mcm9tLW9yLXNlbGYoKQoKIC0gZXhh
bXBsZSBmb3IgZGVyaXZlZCBmcm9tIGluIHdyb25nIHNlY3Rpb24KIC0gbm8gZXhhbXBsZSBnaXZl
biBmb3IgZGVyaXZlZC1mcm9tLW9yLXNlbGYoKQogLSBubyBleHBsYW5hdGlvbiB3aHkgMSBmdW5j
dGlvbiB3b3VsZCBiZSB1c2VkIGluc3RlYWQgb2YgdGhlIG90aGVyCiAtIHRoZXNlIGZ1bmN0aW9u
cyBkbyBub3QgYWN0dWFsbHkgZGVmaW5lIHdoYXQgaXQgbWVhbnMKICAgdG8gYmUgImRlcml2ZWQg
ZnJvbSIuICBXaGF0IGRvZXMgaXQgbWVhbiBpbiB0ZXJtcyBvZiBiYXNlLXN0bXQgbWF0Y2hpbmcK
ICAgbGlrZSBhbiBpZGVudGl0eXJlZj8KIC0gV2hhdCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgYmFz
ZXM/ICBUaGVzZSBmdW5jdGlvbnMgb25seSBzdXBwb3J0IDEgYmFzZS4KClNlYy4gMTEuICBVcGRh
dGluZyBhIE1vZHVsZQoKIC0gc2VlbXMgYWxsIGluc3RhbmNlcyBvZiAnbWF5JyBuZWVkIHRvIGJl
IGNoYW5nZWQgdG8gJ01BWScKCiAtIGxhc3QgcGFyYToKICAgSW4gc3RhdGVtZW50cyB0aGF0IGhh
dmUgYW55IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIGFzCiAgIHN1YnN0YXRlbWVudHMsIHRo
b3NlIGRhdGEgZGVmaW5pdGlvbiBzdWJzdGF0ZW1lbnRzIE1VU1QgTk9UIGJlCiAgIHJlb3JkZXJl
ZC4KCiAgIFdoeSBpcyB0aGlzIHJlcXVpcmVtZW50IGluIGhlcmU/ICBTZWVtcyBsaWtlIGNoYW5n
aW5nIHRoZQogICBvcmRlciBvZiBjYXNlLXN0bXRzIHdpdGhpbiBhIGNob2ljZS1zdG10IGRvZXMg
bm90IG1hdHRlci4KICAgQ2hhbmdpbmcgdGhlIG9yZGVyIG9mIGF1Z21lbnQtc3RtdHMgZG9lcyBu
b3QgbWF0dGVyLgogICBXaHkgZG9lcyBjaGFuZ2luZyBvcmRlciBvZiBhbnkgZGF0YS1kZWYgc3Rh
dGVtZW50IGJyZWFrIGFuIG9sZCBjbGllbnQ/CgpTZWMgMTIuICBDb2V4aXN0ZW5jZSB3aXRoIFlB
TkcgdmVyc2lvbiAxCgogLSBwYXJhIDQ6IDoic2VydmVyIE1BWSBpbXBsZW1lbnQgYm90aC4uLiIg
Y29udHJhZGljdHMgdGhpcyB0ZXh0IGluIDUuNi40OgogICAiQSBzZXJ2ZXIgTVVTVCBOT1QgaW1w
bGVtZW50IG1vcmUgdGhhbiBvbmUgcmV2aXNpb24gb2YgYSBtb2R1bGUuIgoKIC0gdGhpcyBzZWN0
aW9uIGRvZXMgbm90IGFkZHJlc3Mgd2hhdCBoYXBwZW5zIGlmIHByb3RvY29sLWFjY2Vzc2libGUK
ICAgb2JqZWN0cyBoYXZlIGNoYW5nZWQgYmV0d2VlbiB0aGUgaW1wbGVtZW50ZWQgWUFORyAxLjAg
bW9kdWxlIHJldmlzaW9uCiAgIGFuZCB0aGUgaW1wbGVtZW50ZWQgWUFORyAxLjEgbW9kdWxlIHJl
dmlzaW9uLiAgU2luY2UgTkVUQ09ORiBhbmQKICAgUkVTVENPTkYgZG8gbm90IHNwZWNpZnkgWUFO
RyBsYW5ndWFnZSB2ZXJzaW9uIG9yIFlBTkcgbW9kdWxlIHJldmlzaW9uCiAgIGluIGVkaXQgcGF5
bG9hZHMgb3IgcmV0cmlldmFsIGZpbHRlcnMsIGhvdyBkb2VzIHRoZSBzZXJ2ZXIgZXZlbgogICBr
bm93IGlmIGEgY2xpZW50IGlzIGFza2luZyBmb3IgdGhlIFlBTkcgMS4wIHZzLiBZQU5HIDEuMSAg
aW1wbGVtZW50YXRpb24KICAgb2YgYSBwYXJ0aWN1bGFyIGRhdGEgbm9kZT8KClNlYy4gMTguICBD
b250cmlidXRvcnMKCk9MRDoKICAgIC0gQW5keSBCaWVybWFuIChCcm9jYWRlKQpORVc6CiAgICAt
IEFuZHkgQmllcm1hbiAoWXVtYVdvcmtzKQoKCk5pdHM6CiBwODogcGFyYSAxOiAgcy9wcm9wc2Vk
L3Byb3Bvc2VkLwogcDEwOiBidWxsZXQgMzogcy9kZWZpbnRpb25zL2RlZmluaXRpb25zLwogcDM3
LCBwYXJhIDQ6IHMvZW5jb25kaW5nL2VuY29kaW5nLwogcDQzLCBwYXJhIDM6IHMvU0hPVUxEIG5v
dC9TSE9VTEQgTk9ULwoK
--001a11c37a24f61bb3052319b893--


From nobody Tue Oct 27 14:47:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38F1B29BA for ; Tue, 27 Oct 2015 14:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmxE_0hBggX3 for ; Tue, 27 Oct 2015 14:47:46 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDB71B29B7 for ; Tue, 27 Oct 2015 14:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1445982466; x=1447192066; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=afTA2cRn2Y88zOiLAjC55rxXoasQeOu0NoFGrwrqVZ8=; b=cu8qCjYotwOYxbZhWuOy3Hh4AQ5CtgF3x9l5Mie9tZR/3u6VzDMV1y4a t2eosN65faRoUca3gdDx4pUiLlybPDK0t6DSn3EjGKs6azsRihDjR3b1f SZ1A33SHgN/SQCFnRZ2GgTTli86bzxKPK/9pzbowGKCpfME/tO1r7U1k3 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAgCs8C9W/5RdJa1egzaBSb8EAQ2BWoY4gSo4FAEBAQEBAQF/C4Q5IxFXASICJgIEMBUSBIhDo2iPcZIYAQEBAQEFAQEBAQEBAQEbgSKFVYIQimsxgRQFljgBjSOBWYQ/kiqDbwEfAQFChASFWoEGAQEB
X-IronPort-AV: E=Sophos;i="5.20,207,1444694400"; d="scan'208";a="202605653"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2015 21:47:45 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9RLljFr030440 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Oct 2015 21:47:45 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 16:47:21 -0500
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 16:47:21 -0500
From: "Clyde Wildes (cwildes)" 
To: "netmod@ietf.org" 
Thread-Topic: draft-ietf-netmod-syslog-model-05 Draft Status
Thread-Index: AQHREQEOCecTObUO/E6eRC34AxnLww==
Date: Tue, 27 Oct 2015 21:47:21 +0000
Message-ID: <20E6089B-198B-4086-B7C3-F604A6DB41C5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.157.193]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B5AC2ED35047541985AE8C5ACB7EE55@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] draft-ietf-netmod-syslog-model-05 Draft Status
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 21:47:47 -0000

SGksDQoNClRoaXMgZS1tYWlsIHN1bW1hcml6ZXMgdGhlIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4g
bWFkZSB0byB0aGUgcHJvcG9zZWQgaWV0Zi1zeXNsb2cueWFuZyBtb2RlbCBzaW5jZSB0aGUgSnVs
eSBtZWV0aW5nIHdoZW4gdGhlIHByZXZpb3VzIDA0IGRyYWZ0IHdhcyBwdWJsaXNoZWQuIFRoZSBj
aGFuZ2VzIGFyZSBiYXNlZCBvbiBmZWVkYmFjayByZWNlaXZlZCBhZnRlciB0aGUgbGFzdCBtZWV0
aW5nIGZyb20gTWFydGluIEJqb3JrbHVuZCwgTGFkYSBMaG90a2EsIEphc29uIFN0ZXJuZSwgYW5k
IE1haGVzaCBKZXRoYW5hbmRhbmkuDQoNCkNoYW5nZXMgdG8gaWV0Zi1zeXNsb2ctdHlwZXMueWFu
ZzoNCi0gdXBkYXRlZCBXRyBDaGFpciB0byBLZW50IFdhdHNvbg0KLSB1cGRhdGVkIHRoZSByZXZp
c2lvbiBkYXRlIHRvIDIwMTUtMTAtMTQuDQoNCkNoYW5nZXMgdG8gaWV0Zi1zeXNsb2cueWFuZzoN
Ci0gdXBkYXRlZCBXRyBDaGFpciB0byBLZW50IFdhdHNvbg0KLSB1cGRhdGVkIHRoZSByZXZpc2lv
biBkYXRlIHRvIDIwMTUtMTAtMTQNCi0gbW9kaWZpZWQgbnVtZXJvdXMgZGVzY3JpcHRpb24gZmll
bGRzIHRvIG1vcmUgYWNjdXJhdGVseSByZWZsZWN0IGZpZWxkIGNvbnRlbnRzDQoNCi0gc2ltcGxp
ZmllZCB0aGUgbG9nLXNlbGVjdG9yIGNvbnRhaW5lciBsZWF2ZXMgYnkgdXNpbmcgbGVhZiBuYW1l
cyB0aGF0IG1vcmUgYWNjdXJhdGVseSBkZXNjcmliZSB0aGUgaW50ZW50IGFuZCB1c2luZyBhIHVu
aW9uIHRvIGFkZCBhbiBvcHRpb24gZm9yIGFsbCBmYWNpbGl0aWVzDQotIG1vZGlmaWVkIHRoZSBz
ZXZlcml0eSBmaWVsZCB0byBpbmNsdWRlIGFuIGVudW0gdmFsdWUgZm9yICJub25lIiBpbnN0ZWFk
IG9mIGRlcGVuZGluZyBvbiBub25lIGJlaW5nIGltcGxpZWQgaWYgdGhlIGxlYWYgd2FzIG5vdCBz
cGVjaWZpZWQNCi0gYWRkZWQgIm1hbmRhdG9yeSB0cnVlIiB0byB0aGUgc2VsZWN0b3ItZmFjaWxp
dHkgY2hvaWNlIGFuZCB0aGUgc2V2ZXJpdHkgbGVhZg0KLSBtb3ZlZCB0aGUgInNldmVyaXR5LW9w
ZXJhdG9yIiBsZWFmIGludG8gdGhlIHN5c2xvZy1zZXZlcml0eSBncm91cGluZw0KLSBhZGRlZCAi
cHJlc2VuY2UuLi4iIGZvciB0aGUgc3lzbG9nL2NvbnNvbGUgY29udGFpbmVyDQotIHJlbmFtZWQg
dGhlICJyZW1vdGUtbG9nZ2luZy1kZXN0aW5hdGlvbiIgbGVhZiB0byAiZGVzdGluYXRpb24iIGlu
IHRoZSBzeXNsb2cvcmVtb3RlIGNvbnRhaW5lcg0KLSByZXBsYWNlZCAiZGVmYXVsdCBhbGwtdXNl
cnMiIHdpdGggIm1hbmRhdG9yeSB0cnVlIiBmb3IgdGhlIHN5c2xvZy90ZXJtaW5hbC91c2VyLXNj
b3BlIGNob2ljZS4NCg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdXIgaGF2ZSBxdWVzdGlvbnMg
b3IgY29uY2VybnMuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KDQo=


From nobody Tue Oct 27 23:07:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451B41B4BF2 for ; Tue, 27 Oct 2015 23:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnc0uHmUzH9I for ; Tue, 27 Oct 2015 23:07:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175C91B4BEB for ; Tue, 27 Oct 2015 23:07:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDE24127; Wed, 28 Oct 2015 06:07:14 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 28 Oct 2015 06:07:14 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Wed, 28 Oct 2015 14:07:05 +0800
From: "Dongjie (Jimmy)" 
To: "netmod@ietf.org" 
Thread-Topic: open-source tool for extraction of typedef, grouping and identity
Thread-Index: AdERRt0kM8OOkkdlTWqbfSJmCT/4cw==
Date: Wed, 28 Oct 2015 06:07:04 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927743C3217@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.97.131]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927743C3217nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: Zhoutianran 
Subject: [netmod] open-source tool for extraction of typedef, grouping and identity
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 06:07:19 -0000

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

Hi all,

As one of the outcome in IETE 93 Hackathon, a simple open-source tool for t=
he extraction of typedef, grouping and identity from yang model is availabl=
e on github:

https://github.com/jie-dong/yang/tree/master/extractor

Comments and contributions to it are welcome.

Best regards,
Jie


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











Hi all, 


 


As one of the outcome in IETE 93
Hackathon,=
 a simple open-source tool for the extraction of typedef, grouping and iden=
tity from yang model is available on github:


 


https://github.com/jie-dong/yang/tree/m=
aster/extractor


 


Comments and contributions to i=
t are welcome.


 


Best regards,=



Jie


 






--_000_76CD132C3ADEF848BD84D028D243C927743C3217nkgeml512mbxchi_--


From nobody Wed Oct 28 04:55:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D11B52C2 for ; Wed, 28 Oct 2015 04:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmNwcVw6G_vR for ; Wed, 28 Oct 2015 04:55:46 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DF51B52C1 for ; Wed, 28 Oct 2015 04:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1446033236; bh=yMhh1/4SSLUnNyBLpNGSOiNg4WL19fQrn/KLlv/j9xY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jPlW6KjAhvjtPV0x3WSRVPMoJxOYa7acZLU5uGLnlhmZAPCZPuqI0KN5EH7C/gLF0 USDOkKqD+rdNmfl/2oMk5tUDUecA6tw5ZrHMpgy7f0uCXwQ6o0nZNovYNRCN7H2ukO qLolu/6r5Mj9R/0O7727f+vOCuuuHyeOfVkxwrCE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Wed, 28 Oct 2015 07:55:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=14 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 166, in=2604, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 11:55:51 -0000

> On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman  =
wrote:
>=20
> Hi,
>=20
> Here are my review comments on YANG 1.1.
> IMO the document is almost ready for publication.

	What remains before it is ready?

	=E2=80=94Tom

> I plan to implement YANG 1.1 in YumaPro tools soon.
>=20
>=20
> Andy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 28 09:22:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5021B586E for ; Wed, 28 Oct 2015 09:22:17 -0700 (PDT)
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 VY8YhE67FBuy for ; Wed, 28 Oct 2015 09:22:16 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FC51A8831 for ; Wed, 28 Oct 2015 09:22:16 -0700 (PDT)
Received: by lbbes7 with SMTP id es7so9607641lbb.2 for ; Wed, 28 Oct 2015 09:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=muMqAFossM7oOzksjw913bReo2gx+j8SsM9MgMo1Eps=; b=OXPxKxfTT86X60rLL0YNp7Szfpf/CpPbCy7lsjboyFBgfLmyZJaCYYAMgSDSIZETMW II23WfMHhWU89+qjDnqy4eczOs1pJivyDVEYtq5VkB+FBp6zyp1Ny54XuqbOnf5JulxU rzj6C2Fi+gteJ0ZW6I/sIVWINRCcxiN/YRrZHQzoTzKI019IQmehxoDt+SiQuobO8/Zl 659uSx7venvudZUKbuHSaPeCVEFo3x6S/olmtNCr5M3c7++s/dpgxXDs4uNv8fcKQKlT s6OmJzv5LQMnc7I/7dxjllX6mcECPSgKL8PhfjJvYxq1E72lwO8bJjgDFNN1b8GbdBI4 DkGg==
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=muMqAFossM7oOzksjw913bReo2gx+j8SsM9MgMo1Eps=; b=heGF9+JR6hNpwj2e/QTiqfA6wMUs2f7cCM6xYPUB2PDT+OABFzTVu7H5RCAYYJIepb FdakOMTAWKK5PCtb7h8XOaWPrbFdjER8e1JfSeTV4uYtsLoDtXRNsJ+Sml4u4WYAkTdt RXyywtzsFyduiX2i8Y2nSw2TRmuhMoNJqN298W+e4Lb+Eo/EC4pAsR0/LvusgcyTmWQi hGfKnYWXSm9bOs+UMnv8RUUHbjG5GSRObxyJDN+ug23YjHVsoqOCIRtr1X7f4/2CwEiH poLslVS7OUk+9Esv1l8J3RWmiZHQfCD7phvXCsrWDdm993qmTBAt4hnWAJIFMMRXeWjO epvA==
X-Gm-Message-State: ALoCoQmguPltMyyYTf8Y409+sgTd7nPO5xHSyO7+JcXIzCTCFfw5z3yTfd4MPGKrHOOiK27p9tcD
MIME-Version: 1.0
X-Received: by 10.112.135.136 with SMTP id ps8mr23405019lbb.38.1446049334504;  Wed, 28 Oct 2015 09:22:14 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 28 Oct 2015 09:22:14 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 28 Oct 2015 09:22:14 -0700
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=089e01160712e94db505232c989b
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 16:22:17 -0000

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

On Wed, Oct 28, 2015 at 4:55 AM, Nadeau Thomas 
wrote:

>
>
> > On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman 
> wrote:
> >
> > Hi,
> >
> > Here are my review comments on YANG 1.1.
> > IMO the document is almost ready for publication.
>
>         What remains before it is ready?
>
>
I think my review comments specify that.



>         =E2=80=94Tom
>

Andy


>
> > I plan to implement YANG 1.1 in YumaPro tools soon.
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Wed, Oct 28, 2015 at 4:55 AM, Nadeau Thomas <tnadeau@lucidvis=
ion.com> wrote:




> On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman <andy@yumaworks.com> wrote:

>

> Hi,

>

> Here are my review comments on YANG 1.1.

> IMO the document is almost ready for publication.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 What remains before it is ready?



I think my review comments specify tha=
t.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom

Andy
=C2=A0



> I plan to implement YANG 1.1 in YumaPro tools soon.

>

>

> Andy

>

> <review1.txt>_______________________________________________

> netmod mailing list

> netmod@ietf.org

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






--089e01160712e94db505232c989b--


From nobody Wed Oct 28 09:55:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D971C1AC3A5 for ; Wed, 28 Oct 2015 09:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuDvHnl-vB0v for ; Wed, 28 Oct 2015 09:55:47 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0670D1B5C9A for ; Wed, 28 Oct 2015 09:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1446050768; bh=G6GTz4dF1DHynqEWOcsNoYlWvfmeqyAYGNWEHcM9QEs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=W6CnTF/+xIXAGuv0fcqn+Oj1gSkUnp813XZ4fR8RkoSoeXA583q+dv5/+L3tAfxA2 Z3+HHCt7g6hzfBOfbAlRohLkLGFe7UhogghUj9Jsql/3KsZuuJ8VpLdR93S0CI51v7 vp28bpg55DAQclzuZiCf7Zgrx7Sc1nL+nkhqZPfg=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7AB3A3E8-4F2A-4B7E-9253-C86F3BB04F57"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Wed, 28 Oct 2015 12:47:04 -0400
Message-Id: <95168EB9-E329-482A-A3F7-7CBE850EDE48@lucidvision.com>
References:   
To: Andy Bierman 
X-Mailer: Apple Mail (2.3094)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 166, in=2607, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 16:55:52 -0000

--Apple-Mail=_7AB3A3E8-4F2A-4B7E-9253-C86F3BB04F57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


	I am looking to get a feel for the changes will be ready.  =20
Looking at the comments, these seem to be more or less editorial =
changes.  Can you=20
please give a sense of when they might be ready?

	=E2=80=94Tom

Sent from my Apple ][



> On Oct 28, 2015:12:22 PM, at 12:22 PM, Andy Bierman =
 wrote:
>=20
>=20
>=20
> On Wed, Oct 28, 2015 at 4:55 AM, Nadeau Thomas =
> wrote:
>=20
>=20
> > On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman =
> wrote:
> >
> > Hi,
> >
> > Here are my review comments on YANG 1.1.
> > IMO the document is almost ready for publication.
>=20
>         What remains before it is ready?
>=20
>=20
> I think my review comments specify that.
>=20
> =20
>         =E2=80=94Tom
>=20
> Andy
> =20
>=20
> > I plan to implement YANG 1.1 in YumaPro tools soon.
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netmod =

>=20
>=20


--Apple-Mail=_7AB3A3E8-4F2A-4B7E-9253-C86F3BB04F57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



	I am =
looking to get a feel for the changes will be ready.   
Looking at the comments, these seem to be more or less =
editorial changes.  Can you 
please give =
a sense of when they might be ready?

	=E2=80=94Tom



Sent =
from my Apple ][







On Oct 28, 2015:12:22 PM, at 12:22 PM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Wed, Oct 28, 2015 at 4:55 AM, =
Nadeau Thomas <tnadeau@lucidvision.com> wrote:




> On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman <andy@yumaworks.com> =
wrote:

>

> Hi,

>

> Here are my review comments on YANG 1.1.

> IMO the document is almost ready for publication.



        What remains before it is ready?



I think my review comments specify that.

 

        =E2=80=94Tom

Andy
 



> I plan to implement YANG 1.1 in YumaPro tools soon.

>

>

> Andy

>

> =
<review1.txt>_______________________________________________

> netmod mailing list

> netmod@ietf.org

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








=

--Apple-Mail=_7AB3A3E8-4F2A-4B7E-9253-C86F3BB04F57--


From nobody Wed Oct 28 10:02:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2971A92BA for ; Wed, 28 Oct 2015 10:02:41 -0700 (PDT)
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 E0Ysq3r2eM6p for ; Wed, 28 Oct 2015 10:02:40 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068CE1AC3F5 for ; Wed, 28 Oct 2015 09:59:00 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so6765035lfb.2 for ; Wed, 28 Oct 2015 09:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uob1vszUZunz2Pb3pHXjoWqW2Hu3OR9SAR2oY3U79A4=; b=0pJpmRJlSEsnaMdszhxfD/9R2hygX3tskN9JZKBAdQUBc3dSjHIL4ON9Qx9JcwX+66 nG+wSdn5WOO9P8SpLD/621B/r2VxW5lAQWilhQh7306PUa8YwVuOSdnlpch1igc0tH83 5i2HywS+pFDKny23l4P54YM4fvD61d8ZTm2X7xzMdlemvQYAa3SCmHQ+rHw5KeHaKBZ6 Ux86Tf88LB1XB+BjUkfc6eW6swyM2i1zStKbxNcd2XvHfWLKQ9N5BnFkYuDD7l58VK2R fGjMQlpQUt5iOlPZKgcCMbn6vTI7Q4MAIytyrphHB4sPnDdO6busmJwMos4ojDlkH0RV mn8w==
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=Uob1vszUZunz2Pb3pHXjoWqW2Hu3OR9SAR2oY3U79A4=; b=cdM98ICosQLwpZ/vDPFWXle3hNCCyyzc1BglifNPXIjFVHq6PjBqAF6KxOI3G3sTHu oPChGRgaFCluBvwUJ7jFPKpFc9UZY2ffZjn73eEnEP1JxbUhfCUG8qT4YmM1NWiKBm8b zs7Yj7LbCweNYwWTItiDI2/Nmzq94bryoJQ8v6Sh+OgcwgaQtvf+OnqXe04UeU/FPcFM d6bSN993ys1Ms+uossj8+fzggB9cBvhr7raLyoyf9k6uEqi6EbkNgou+PMWtOAtf55Cz MGd7zGuN0tsMIj0za8Klhv23To3+K0C6N8V0zFKq7Ak8OSY18clc0ZE6giTGqyhTWJx4 rEgg==
X-Gm-Message-State: ALoCoQkUdebnH3WfLaYaxI8V8vtD47fUSS7lpdpBJsdzAPRj/N9Zsnegyq5U7qb03GrwHm6ast7r
MIME-Version: 1.0
X-Received: by 10.25.154.201 with SMTP id c192mr15451986lfe.119.1446051538219;  Wed, 28 Oct 2015 09:58:58 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 28 Oct 2015 09:58:58 -0700 (PDT)
In-Reply-To: <95168EB9-E329-482A-A3F7-7CBE850EDE48@lucidvision.com>
References:    <95168EB9-E329-482A-A3F7-7CBE850EDE48@lucidvision.com>
Date: Wed, 28 Oct 2015 09:58:58 -0700
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a114032d243511005232d1c69
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 17:02:42 -0000

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

Hi,

I don't know when YANG 1.1 will be ready.


Andy


On Wed, Oct 28, 2015 at 9:47 AM, Nadeau Thomas 
wrote:

>
> I am looking to get a feel for the changes will be ready.
> Looking at the comments, these seem to be more or less editorial changes.
> Can you
> please give a sense of when they might be ready?
>
> =E2=80=94Tom
>
> Sent from my Apple ][
>
>
>
> On Oct 28, 2015:12:22 PM, at 12:22 PM, Andy Bierman 
> wrote:
>
>
>
> On Wed, Oct 28, 2015 at 4:55 AM, Nadeau Thomas 
> wrote:
>
>>
>>
>> > On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman 
>> wrote:
>> >
>> > Hi,
>> >
>> > Here are my review comments on YANG 1.1.
>> > IMO the document is almost ready for publication.
>>
>>         What remains before it is ready?
>>
>>
> I think my review comments specify that.
>
>
>
>>         =E2=80=94Tom
>>
>
> Andy
>
>
>>
>> > I plan to implement YANG 1.1 in YumaPro tools soon.
>> >
>> >
>> > Andy
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>

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


Hi,

I don't know when YANG 1.1 will=
 be ready.


Andy


On Wed, Oct=
 28, 2015 at 9:47 AM, Nadeau Thomas <tnadeau@lucidvision.com>=
 wrote:

	I am =
looking to get a feel for the changes will be ready. =C2=A0=C2=A0
Looki=
ng at the comments, these seem to be more or less editorial changes.=C2=A0 =
Can you=C2=A0
please give a sense of when they might be ready?
	=E2=80=94Tom<=
/div>



Sent from my Apple ][
<=
div>






On Oct 28, 2015:12:22 PM, at 12:22 =
PM, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Oct 28, 2015 =
at 4:55 AM, Nadeau Thomas <tnadeau@lucidvision.com> wr=
ote:




> On Oct 27, 2015:1:51 PM, at 1:51 PM, Andy Bierman <andy@yumaworks.com> wrote:
>

> Hi,

>

> Here are my review comments on YANG 1.1.

> IMO the document is almost ready for publication.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 What remains before it is ready?



I think my review comments specify tha=
t.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom

Andy
=C2=A0



> I plan to implement YANG 1.1 in YumaPro tools soon.

>

>

> Andy

>

> <review1.txt>_______________________________________________

> netmod mailing list

> netmod@ietf.org

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










--001a114032d243511005232d1c69--


From nobody Wed Oct 28 11:13:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9B51B5D7D for ; Wed, 28 Oct 2015 11:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AROwEwCO0S3T for ; Wed, 28 Oct 2015 11:13:33 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764A31B5D7C for ; Wed, 28 Oct 2015 11:13:33 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 04F676F47D312 for ; Wed, 28 Oct 2015 18:13:27 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t9SIDTbL009921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Oct 2015 18:13:30 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.182]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 28 Oct 2015 14:13:29 -0400
From: "Sterne, Jason (Jason)" 
To: "netmod@ietf.org" 
Thread-Topic: acl-model-5:  remove time-range and put input-interface behind an if-feature
Thread-Index: AdDCSmd3mYKQXXKSQAekT07WIMveDA7AoRwABRe40hA=
Date: Wed, 28 Oct 2015 18:13:29 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CB50EAEUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] acl-model-5: remove time-range and put input-interface behind an if-feature
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 18:13:36 -0000

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

Hi all,

This comment is still applicable to the recent version 5 draft.

Any other opinions about this ?  Just wanted to bring it up again a little =
before IETF94 since this draft is on the agenda.

Regards,
Jason

From: Sterne, Jason (Jason)
Sent: Friday, October 02, 2015 16:08
To: Sterne, Jason (Jason); netmod@ietf.org
Subject: draft-ietf-netmod-acl-model-03: remove time-range and put input-in=
terface behind an if-feature

(splitting point (A) out of the "RE: [netmod] A few other misc. comments on=
     draft-ietf-netmod-acl-model-03" thread)

Hi all,

I'd propose we remove time-range from the model for a number of reasons:

1)      I don't think we should build individual time-range functions all o=
ver the place in individual modules (likely in slightly different ways).  I=
f we want time-range type functions then I think we should define that in a=
 more generic way that can apply to any configuration items and keep it out=
 of individual modules.

2)      Maybe time range functions are more appropriate up in the client/co=
ntroller layer anyways

3)      This is not standard base functionality that is uniformly supported=
 in devices that use ACLs

The remaining meta-data item (input-interface) should probably also be remo=
ved (same reason #3 as above).  At minimum it should an if-feature.

Regards,
Jason

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (J=
ason)
Sent: Sunday, July 19, 2015 13:43
To: netmod@ietf.org
Subject: [netmod] A few other misc. comments on draft-ietf-netmod-acl-model=
-03

Hi all,

I brought up ACL types and ACE numerical IDs in other separate email thread=
s.  This one is for a set of other misc. comments (one functional, the rest=
 are more editorial).

A) Please make the metadata optional with an if-feature (or make each of in=
put-interface & time-range their own if-features - that is probably better)=
.  Or drop those out of the model and leave them to augmentations.    If we=
 do keep input-interface in the model as an if-feature then:
- should we import ietf-interfaces with just the prefix"if" ?  That is the =
prefix in the ietf-interfaces module and what is used in the routing model =
for example.
- shouldn't the input-interface be a leafref (e.g. if:interface-ref) ?

[>>JTS] ...snip...


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











Hi all,=



 <=
/p>

This comment is still app=
licable to the recent version 5 draft.


 <=
/p>

Any other opinions about =
this ?  Just wanted to bring it up again a little before IETF94 since =
this draft is on the agenda.


 <=
/p>

Regards,


Jason

 <=
/p>





From: Sterne, =
Jason (Jason)


Sent: Friday, October 02, 2015 16:08

To: Sterne, Jason (Jason); netmod@ietf.org

Subject: draft-ietf-netmod-acl-model-03: remove time-range and put i=
nput-interface behind an if-feature






 


(splitting point (A) out =
of the “RE: [netmod] A few other misc. comments on   &=
nbsp; draft-ietf-netmod-acl-model-03” thread)


 <=
/p>

Hi all,=



 <=
/p>

I’d propose we remo=
ve time-range from the model for a number of reasons:


1) =
;    
I don’t thi=
nk we should build individual time-range functions all over the place in in=
dividual modules (likely in slightly different ways).  If we
 want time-range type functions then I think we should define that in a mor=
e generic way that can apply to any configuration items and keep it out of =
individual modules.


2) =
;    
Maybe time range =
functions are more appropriate up in the client/controller layer anyways


3) =
;    
This is not stand=
ard base functionality that is uniformly supported in devices that use ACLs=



 <=
/p>

The remaining meta-data i=
tem (input-interface) should probably also be removed (same reason #3 as ab=
ove).  At minimum it should an if-feature.


 <=
/p>

Regards,


Jason

 <=
/p>





From: netmod [=
mailto:netmod-bounces@ietf.org]
On Behalf Of Sterne, Jason (Jason)

Sent: Sunday, July 19, 2015 13:43

To: netmod@ietf.org

Subject: [netmod] A few other misc. comments on draft-ietf-netmod-ac=
l-model-03






 




Hi all,






 






I brought up ACL types and ACE numerica=
l IDs in other separate email threads.  This one is for a set of other=
 misc. comments (one functional, the rest are more editorial).






 






A) Please make the metadata optional wi=
th an if-feature (or make each of input-interface & time-range their ow=
n if-features – that is probably better).  Or drop those out
 of the model and leave them to augmentations.    If we do k=
eep input-interface in the model as an if-feature then:





- should we import ietf-interfaces with=
 just the prefix"if" ?  That is the prefix in the ietf-inter=
faces module and what is used in the routing model for example.<=
/span>






- shouldn’t the input-interface b=
e a leafref (e.g. if:interface-ref) ?






 






[>>JTS]
…snip…






 








--_000_A125E53CE190A749957C19483DC79F9F5CB50EAEUS70TWXCHMBA11z_--


From nobody Wed Oct 28 11:50:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D81AC42B for ; Wed, 28 Oct 2015 11:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LajKLqG8NkXC for ; Wed, 28 Oct 2015 11:50:36 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAD61A92A9 for ; Wed, 28 Oct 2015 11:50:35 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6BF9E5DA8324F for ; Wed, 28 Oct 2015 18:50:30 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t9SIoWDJ003950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Oct 2015 18:50:32 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.182]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 28 Oct 2015 14:50:32 -0400
From: "Sterne, Jason (Jason)" 
To: "netmod@ietf.org" 
Thread-Topic: syslog-model-05: terminal logging vs session logging
Thread-Index: AdERsYWVK7sAS2a4SZqHoojSAaVlXw==
Date: Wed, 28 Oct 2015 18:50:32 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CB50F1BUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] syslog-model-05: terminal logging vs session logging
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 18:50:38 -0000

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

Hi all,

One of the syslog destinations in the model is the "terminal" (for all user=
s or specific users).

Isn't logging to a terminal more typically enabled on a CLI *session* basis=
 rather than configured against a particular user ?

I believe it is also typical for session logging to stop/disappear when tha=
t session is ended (i.e. it is not persistent config).

I'm not sure it is typical to have configuration in a device that basically=
 instructs the device to enable logging to the terminal for "user x" whenev=
er that user later logs in (and if they had multiple login sessions then pr=
esumably log events would be delivered to each session).

I think session logging is something that is really purely CLI (i.e. intera=
ctive sessions with human users) and maybe not even applicable to configura=
tion via NETCONF (since we'd never want to send a stream of syslog events a=
s text to the NETCONF client/session like we do to the terminal for a CLI u=
ser).

In section 5 of the draft it mentions that syslog:log-actions/terminal maps=
 to Cisco NXOS "logging monitor 2".  I believe that is intended to enable l=
ogs to a particular *session* (not user).   IOS-XR behavior is similar.  Th=
e ALU SR OS logging config has the concept of sending (enabling) log events=
 to a particular session (but not configured against a user).

Jason




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











Hi all,


 


One of the syslog destinations in the model is the “terminalR=
21; (for all users or specific users).


 


Isn’t logging to a terminal more typically enabled on a CLI *=
session* basis rather than configured against a particular user ?


 


I believe it is also typical for session logging to stop/disappear whe=
n that session is ended (i.e. it is not persistent config).


 


I’m not sure it is typical to have configuration in a device tha=
t basically instructs the device to enable logging to the terminal for R=
20;user x” whenever that user later logs in (and if they had multiple=
 login sessions then presumably log events would be
delivered to each session).


 


I think session logging is something that is really purely CLI (i.e. i=
nteractive sessions with human users) and maybe not even applicable to conf=
iguration via NETCONF (since we’d never want to send a stream of sysl=
og events as text to the NETCONF client/session
like we do to the terminal for a CLI user).  


 


In section 5 of the draft it mentions that syslog:log-actions/terminal=
 maps to Cisco NXOS “logging monitor 2”.  I believe that i=
s intended to enable logs to a particular *session* (not user). =
;  IOS-XR behavior is similar.  The ALU SR OS logging
config has the concept of sending (enabling) log events to a particular ses=
sion (but not configured against a user).


 


Jason


 


 


 





--_000_A125E53CE190A749957C19483DC79F9F5CB50F1BUS70TWXCHMBA11z_--


From nobody Wed Oct 28 11:50:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83361A92A9 for ; Wed, 28 Oct 2015 11:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5dFsYad4LRc for ; Wed, 28 Oct 2015 11:50:46 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79AF1AC434 for ; Wed, 28 Oct 2015 11:50:45 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6B36A2D48733E for ; Wed, 28 Oct 2015 18:50:40 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t9SIogCG004346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Oct 2015 18:50:42 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.182]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 28 Oct 2015 14:50:42 -0400
From: "Sterne, Jason (Jason)" 
To: "netmod@ietf.org" 
Thread-Topic: syslog-model-05:  minor editorial comments
Thread-Index: AdERsYuf918fImBvT2emyBZBh/zMjw==
Date: Wed, 28 Oct 2015 18:50:42 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CB50F23US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] syslog-model-05:  minor editorial comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 18:50:51 -0000

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

A few minor editorial comments on syslog-model-05:

- The introduction says "We are using definitions of Syslog protocol from [=
RFC3164] in this draft." but the YANG model mostly references 5424.
- In section 3 maybe use the term "Remote Collector(s)" instead of Server(s=
) ? Collector seems more in line with RFC5424 (or "Remote Receiver" if othe=
rs prefer that).
- In the Section 3 figure make all the Distributors have a common syntax fo=
r plural vs singular "Log Buffer(s)", "Log File(s)", "Remote Collector(s)",=
 "User Terminal(s)"
- Document is missing the standard legend for the PYANG tree

Jason


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











A few minor editorial comments on syslog-model-05:


 


- The introduction says "We are using definitions of Syslog proto=
col from [RFC3164] in this draft." but the YANG model mostly reference=
s 5424.


- In section 3 maybe use the term "Remote Collector(s)" inst=
ead of Server(s) ? Collector seems more in line with RFC5424 (or "Remo=
te Receiver" if others prefer that).


- In the Section 3 figure make all the Distributors have a common synt=
ax for plural vs singular "Log Buffer(s)", "Log File(s)"=
;, "Remote Collector(s)", “User Terminal(s)”


- Document is missing the standard legend for the PYANG tree


 


Jaso=
n


 





--_000_A125E53CE190A749957C19483DC79F9F5CB50F23US70TWXCHMBA11z_--


From nobody Wed Oct 28 12:11:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8531ACCED for ; Wed, 28 Oct 2015 12:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 wPqv0pCFMKzr for ; Wed, 28 Oct 2015 12:11:05 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3D91ACCEF for ; Wed, 28 Oct 2015 12:11:05 -0700 (PDT)
Received: by qkbl190 with SMTP id l190so7682496qkb.2 for ; Wed, 28 Oct 2015 12:11:04 -0700 (PDT)
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=YmbhEPA0mxWKnmgdWDtY+VwQZgDIPkBiuFd5Eyk/JAA=; b=TAQiSk7869CzeKXkWdhm5RzwBHcB/EaccPMXttH7V7C+gomqGX1SstcOtCECUYlk7W dvhDtdwClaWEjrojx/iNJD0Tu+72Lf/ybIg3t4Jt0moEADJ8koKZU71hAu/lGZ501DPt Osg0mdnpwkdtPeXljKm7o4MXKmUPijQqcC9gN4vG8EPVmSdOga1KE5RKzAKxLAFtpB48 vnMdz+/3n5plekJZhcLJ3BaTI0V9b3ARfhiskzKOjLAKVTxEZlmaWI94vOlDLDZ0OCaA ct+uy0mkogcCD7XwERBLxIcRN8foVw7AOGlgBdNOxhySPir9BBmRo1It92jVzIP/xIMA JR/Q==
X-Received: by 10.55.50.149 with SMTP id y143mr59055414qky.86.1446059464299; Wed, 28 Oct 2015 12:11:04 -0700 (PDT)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id b21sm17517748qhc.46.2015.10.28.12.11.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Oct 2015 12:11:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0CAD238D-4687-4FB7-98F5-1ED0A769FC05"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Wed, 28 Oct 2015 15:11:03 -0400
Message-Id: 
References:   
To: "Sterne, Jason (Jason)" 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] acl-model-5: remove time-range and put input-interface behind an if-feature
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 19:11:07 -0000

--Apple-Mail=_0CAD238D-4687-4FB7-98F5-1ED0A769FC05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Jason and I spoke on this issue and the question is

Do we want to add time range directly to the standard model or create a =
separate model for time range that can be then applied to other =
different nodes? If we decide to keep it as is, then the ask is to =
if-feature time range.

If there will not be any replies on the mailing list, this will be one =
question for discussion at the WG mtg

Dean

> On Oct 28, 2015, at 2:13 PM, Sterne, Jason (Jason) =
 wrote:
>=20
> Hi all,
> =20
> This comment is still applicable to the recent version 5 draft.
> =20
> Any other opinions about this ?  Just wanted to bring it up again a =
little before IETF94 since this draft is on the agenda.
> =20
> Regards,
> Jason
> =20
> From: Sterne, Jason (Jason)=20
> Sent: Friday, October 02, 2015 16:08
> To: Sterne, Jason (Jason); netmod@ietf.org 
> Subject: draft-ietf-netmod-acl-model-03: remove time-range and put =
input-interface behind an if-feature
> =20
> (splitting point (A) out of the =E2=80=9CRE: [netmod] A few other =
misc. comments on     draft-ietf-netmod-acl-model-03=E2=80=9D thread)
> =20
> Hi all,
> =20
> I=E2=80=99d propose we remove time-range from the model for a number =
of reasons:
> 1)      I don=E2=80=99t think we should build individual time-range =
functions all over the place in individual modules (likely in slightly =
different ways).  If we want time-range type functions then I think we =
should define that in a more generic way that can apply to any =
configuration items and keep it out of individual modules.
> 2)      Maybe time range functions are more appropriate up in the =
client/controller layer anyways
> 3)      This is not standard base functionality that is uniformly =
supported in devices that use ACLs
> =20
> The remaining meta-data item (input-interface) should probably also be =
removed (same reason #3 as above).  At minimum it should an if-feature.
> =20
> Regards,
> Jason
> =20
> From: netmod [mailto:netmod-bounces@ietf.org =
] On Behalf Of Sterne, Jason (Jason)
> Sent: Sunday, July 19, 2015 13:43
> To: netmod@ietf.org 
> Subject: [netmod] A few other misc. comments on =
draft-ietf-netmod-acl-model-03
> =20
> Hi all,
> =20
> I brought up ACL types and ACE numerical IDs in other separate email =
threads.  This one is for a set of other misc. comments (one functional, =
the rest are more editorial).
> =20
> A) Please make the metadata optional with an if-feature (or make each =
of input-interface & time-range their own if-features =E2=80=93 that is =
probably better).  Or drop those out of the model and leave them to =
augmentations.    If we do keep input-interface in the model as an =
if-feature then:
> - should we import ietf-interfaces with just the prefix"if" ?  That is =
the prefix in the ietf-interfaces module and what is used in the routing =
model for example.
> - shouldn=E2=80=99t the input-interface be a leafref (e.g. =
if:interface-ref) ?
> =20
> [>>JTS] =E2=80=A6snip=E2=80=A6
> =20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =


--Apple-Mail=_0CAD238D-4687-4FB7-98F5-1ED0A769FC05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Jason and I spoke on this issue and the question is

Do we want to add time =
range directly to the standard model or create a separate model for time =
range that can be then applied to other different nodes? If we decide to =
keep it as is, then the ask is to if-feature time range.

If there will not be any =
replies on the mailing list, this will be one question for discussion at =
the WG mtg

Dean

On =
Oct 28, 2015, at 2:13 PM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:

Hi =
all,
 
This comment is still =
applicable to the recent version 5 draft.
 
Any other opinions =
about this ?  Just wanted to bring it up again a little before =
IETF94 since this draft is on the agenda.
 
Regards,
Jason
 
From: Sterne, =
Jason (Jason) 
Sent: Friday, October 02, 2015 =
16:08
To: Sterne, Jason (Jason); netmod@ietf.org
Subject: draft-ietf-netmod-acl-model-0=
3: remove time-range and put input-interface behind an if-feature
 
(splitting point (A) =
out of the =E2=80=9CRE: [netmod] A few other misc. comments =
on     draft-ietf-netmod-acl-model-03=E2=80=9D =
thread)
 
Hi all,
 
I=E2=80=99d propose we =
remove time-range from the model for a number of reasons:
1)      I don=E2=80=99t think we should build =
individual time-range functions all over the place in individual modules =
(likely in slightly different ways).  If we want time-range type =
functions then I think we should define that in a more generic way that =
can apply to any configuration items and keep it out of individual =
modules.
2)      Maybe time range functions are more =
appropriate up in the client/controller layer anyways
3)      This is not standard base functionality =
that is uniformly supported in devices that use ACLs
 
The remaining meta-data =
item (input-interface) should probably also be removed (same reason #3 =
as above).  At minimum it should an if-feature.
 
Regards,
Jason
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf =
Of Sterne, Jason =
(Jason)
Sent: Sunday, July 19, 2015 =
13:43
To: netmod@ietf.org
Subject: [netmod] A few other misc. =
comments on draft-ietf-netmod-acl-model-03
 
Hi all,
 
I brought up ACL types and ACE numerical IDs in =
other separate email threads.  This one is for a set of other misc. =
comments (one functional, the rest are more editorial).
 
A) Please make the metadata optional with an =
if-feature (or make each of input-interface & time-range their own =
if-features =E2=80=93 that is probably better).  Or drop those out =
of the model and leave them to augmentations.    If we do =
keep input-interface in the model as an if-feature then:
- should we import ietf-interfaces with just the =
prefix"if" ?  That is the prefix in the ietf-interfaces module and =
what is used in the routing model for example.
- shouldn=E2=80=99t the input-interface be a =
leafref (e.g. if:interface-ref) ?
 
[>>JTS] =E2=80=A6snip=E2=80=A6
 
_______________________________________________
netmod mailing =
list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

=

--Apple-Mail=_0CAD238D-4687-4FB7-98F5-1ED0A769FC05--


From nobody Thu Oct 29 02:06:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB61B2B64 for ; Thu, 29 Oct 2015 02:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0PdEd9hh-7b for ; Thu, 29 Oct 2015 02:06:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FB61B2B62 for ; Thu, 29 Oct 2015 02:06:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 276BA1246 for ; Thu, 29 Oct 2015 10:06:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id saPhEzU19n0R for ; Thu, 29 Oct 2015 10:06:17 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 29 Oct 2015 10:06:17 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F7262003B for ; Thu, 29 Oct 2015 10:06:17 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HL1TRw0ACc4Q; Thu, 29 Oct 2015 10:06:16 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2736120054; Thu, 29 Oct 2015 10:06:16 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0A7B03871B88; Thu, 29 Oct 2015 10:06:15 +0100 (CET)
Date: Thu, 29 Oct 2015 10:06:15 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20151029090615.GA78922@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] leaf-list uniqueness requirement for non-config nodes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 09:06:21 -0000

Hi,

RFC 6020 say:

   The values in a leaf-list MUST be unique.

While this may have a justification for config true nodes (to allow
modifications of individual elements using edit-config), this
constraint does not seem to make much sense for non-config nodes.

Note that YANG requires keys for lists for config nodes (to allow
modifications of individual elements using edit-config) but it does
not requires keys or uniqueness for for lists for non-config nodes.

In order to be consistent, I think the above requirement should be
changed to this:

   The values in a leaf-list MUST be unique if the nodes represent
   configuration.

I actually think the requirement as stated in RFC 6020 is a bug and I
even considered writing an errata but I thought I get this on the
table here right away.

/js (as technical contributor)

PS: I have a need in LMAP to represent a simple vector of values in an
    RPC and YANG 1 makes this extremely expensive due to this constraint.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Oct 29 02:18:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC31B2B82 for ; Thu, 29 Oct 2015 02:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoA67j3UHxFP for ; Thu, 29 Oct 2015 02:18:03 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BBF1B2B80 for ; Thu, 29 Oct 2015 02:18:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4A0D0770 for ; Thu, 29 Oct 2015 10:18:02 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2RPqThVk8kjW for ; Thu, 29 Oct 2015 10:18:01 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 29 Oct 2015 10:18:01 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3671D2004E for ; Thu, 29 Oct 2015 10:18:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xFVTyle2eadN; Thu, 29 Oct 2015 10:18:00 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F6B32003B; Thu, 29 Oct 2015 10:18:00 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6AC593871BBE; Thu, 29 Oct 2015 10:17:59 +0100 (CET)
Date: Thu, 29 Oct 2015 10:17:58 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20151029091758.GB78922@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 09:18:05 -0000

Hi,

the issues Y09 and Y57 were declared dead after intense discussions of
various solution proposals. It later appeared to me that there is a
solution that we have not considered. The requirement to have a key
for every list and unique values in a leaf-list for config nodes is
essentially there to allow edits on individual elements using
edit-config. The solution not considered so far is simply to give up
the ability to edit invidual elements, that is, a config list without
a key can only be modified as whole and similarily a leaf-list that
allows non-unique values can only be modified as a whole (with
edit-config). Comments?

/js (as technical contributor)

PS: I have been struggling with sending this idea out for a while
    since I am in a conflict here as a technical contributor and user
    of YANG and a WG chair interested to deliver YANG 1.1.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Oct 29 02:53:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55091B2C40 for ; Thu, 29 Oct 2015 02:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Level: 
X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOwhC_Ku77tN for ; Thu, 29 Oct 2015 02:53:48 -0700 (PDT)
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 E87D41B2C3F for ; Thu, 29 Oct 2015 02:53:47 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:3483:300d:8035:432b] (unknown [IPv6:2001:718:1a02:1:3483:300d:8035:432b]) by mail.nic.cz (Postfix) with ESMTPSA id 4FBF7181A63; Thu, 29 Oct 2015 10:53:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1446112425; bh=tLKVh7G0l8mC3HjoJHTo+NWmgqAUfvFHlcesh3FWKe0=; h=From:Date:To; b=GaBrdGmUrfbR8FgGFWdkQeVLodFgEeDCWUcrIvu/bAJkJ2yx+gngHtbsvv/HTjdZG MQDgQdSi7/yk/uB9yDm6HnjNaFJkLMN6mvJuhfmUOs4alOxIAMv3chAgr9mhAdL1iu X3nIjlFaCQzBkcCfzDiSxd3Mq+jCjSQ3z9QuHGeo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Ladislav Lhotka 
In-Reply-To: <20151029091758.GB78922@elstar.local>
Date: Thu, 29 Oct 2015 10:53:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BABC6A6-B5A0-4E78-B2E3-92D0AB7FC5F5@nic.cz>
References: <20151029091758.GB78922@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3096.5)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 09:53:49 -0000

> On 29 Oct 2015, at 10:17, Juergen Schoenwaelder =
 wrote:
>=20
> Hi,
>=20
> the issues Y09 and Y57 were declared dead after intense discussions of
> various solution proposals. It later appeared to me that there is a
> solution that we have not considered. The requirement to have a key
> for every list and unique values in a leaf-list for config nodes is
> essentially there to allow edits on individual elements using
> edit-config. The solution not considered so far is simply to give up
> the ability to edit invidual elements, that is, a config list without
> a key can only be modified as whole and similarily a leaf-list that
> allows non-unique values can only be modified as a whole (with
> edit-config). Comments?

The inability to edit individual list entries may actually apply only to =
NETCONF, because of the dubious design of .
Other protocols (even RESTCONF) might work just fine for keyless config =
lists.

If your proposal is to make the "key" statement optional in config=3Dtrue =
lists, and allow for non-unique leaf lists, then I'd be in favour of it.

Lada

>=20
> /js (as technical contributor)
>=20
> PS: I have been struggling with sending this idea out for a while
>    since I am in a conflict here as a technical contributor and user
>    of YANG and a WG chair interested to deliver YANG 1.1.
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Thu Oct 29 05:14:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321B1B2E2F for ; Thu, 29 Oct 2015 05:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpxIby17TRko for ; Thu, 29 Oct 2015 05:14:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B34971B2E2D for ; Thu, 29 Oct 2015 05:14:41 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id DBA461AE092A; Thu, 29 Oct 2015 13:14:39 +0100 (CET)
Date: Thu, 29 Oct 2015 13:14:39 +0100 (CET)
Message-Id: <20151029.131439.342471494392961439.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151029090615.GA78922@elstar.local>
References: <20151029090615.GA78922@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leaf-list uniqueness requirement for non-config nodes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 12:14:43 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> RFC 6020 say:
> 
>    The values in a leaf-list MUST be unique.
> 
> While this may have a justification for config true nodes (to allow
> modifications of individual elements using edit-config), this
> constraint does not seem to make much sense for non-config nodes.
> 
> Note that YANG requires keys for lists for config nodes (to allow
> modifications of individual elements using edit-config) but it does
> not requires keys or uniqueness for for lists for non-config nodes.
> 
> In order to be consistent, I think the above requirement should be
> changed to this:
> 
>    The values in a leaf-list MUST be unique if the nodes represent
>    configuration.

I think this is kind of ok.  I would prefer to add a new statement
that declares the leaf-list non-unique.   Such a list would be allowed
in non-config scenarios.  And depending on the outcome of the
discussion you just started on Y57, it might be ok also for config
data...


/martin




> 
> I actually think the requirement as stated in RFC 6020 is a bug and I
> even considered writing an errata but I thought I get this on the
> table here right away.
> 
> /js (as technical contributor)
> 
> PS: I have a need in LMAP to represent a simple vector of values in an
>     RPC and YANG 1 makes this extremely expensive due to this constraint.
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Oct 29 05:18:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E431B2E3A for ; Thu, 29 Oct 2015 05:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25KIVFIyB-r2 for ; Thu, 29 Oct 2015 05:17:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D100E1B2E39 for ; Thu, 29 Oct 2015 05:17:57 -0700 (PDT)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id B85811AE092A; Thu, 29 Oct 2015 13:17:56 +0100 (CET)
Date: Thu, 29 Oct 2015 13:17:56 +0100 (CET)
Message-Id: <20151029.131756.1681194827815089398.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151029091758.GB78922@elstar.local>
References: <20151029091758.GB78922@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 12:17:59 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> the issues Y09 and Y57 were declared dead after intense discussions of
> various solution proposals. It later appeared to me that there is a
> solution that we have not considered. The requirement to have a key
> for every list and unique values in a leaf-list for config nodes is
> essentially there to allow edits on individual elements using
> edit-config. The solution not considered so far is simply to give up
> the ability to edit invidual elements, that is, a config list without
> a key can only be modified as whole and similarily a leaf-list that
> allows non-unique values can only be modified as a whole (with
> edit-config). Comments?

How would this look in edit-config?  There are quite a few details to
think through in order to support this.


/martin


From nobody Thu Oct 29 07:42:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251C71A6F53 for ; Thu, 29 Oct 2015 07:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHdyacyucd6y for ; Thu, 29 Oct 2015 07:42:55 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FF31A3B9F for ; Thu, 29 Oct 2015 07:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=183; q=dns/txt; s=iport; t=1446129774; x=1447339374; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=f2dC8jf2uzCtLtC0xc7S3FhZRyssi0OOKGoVML8z8Bc=; b=CjwzNsHuKMMv18V7w6ncNS9G+lXh9rAOfPtjJW23V9BVQWE6WCfvcan8 Jt79VD01ZXphoQW51YoLm3jK2gycpcgBsNvXkqrxDvajM2Ob61reSNnZs Z1URMTc/p9nVRcHO74hTC6vU6qhyMGDOaJpaNGShBVfH0NwQKRPXuW+KN c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CnBAAHMDJW/xbLJq1exgqGDwKCAgEBAQEBAYEAC4RfFXYCBSECEQJMDQgBAYgso3CPcZFnAQEBBwIBIIEihVWMfYFFBZZDjSWJGZMdY4QEPoYyAQEB
X-IronPort-AV: E=Sophos;i="5.20,214,1444694400"; d="scan'208";a="607853575"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Oct 2015 14:42:51 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9TEgpax024652 for ; Thu, 29 Oct 2015 14:42:51 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <56323052.60107@cisco.com>
Date: Thu, 29 Oct 2015 14:42:26 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Is there an interim WG meeting today?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:42:56 -0000

Hi,

Just to check, I presume that there is no interim WG meeting today (I've 
not seen any agenda), and that it been deferred because of the impending 
IETF 94?

Thanks,
Rob


From nobody Thu Oct 29 07:47:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC921A8729 for ; Thu, 29 Oct 2015 07:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ajsHsPIt4Ft for ; Thu, 29 Oct 2015 07:47:15 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5E81A8728 for ; Thu, 29 Oct 2015 07:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1446129924; bh=guBL9tuTU+hD4Pwj/KKHhCTBZfJnGwXZYg3PLGUgQXw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FWY04Sjow6sth4khyBVtN4HvgFNXKce5EEJMg8IylTCGPu1V2LisM0yrKIPtzRENy 3taeUmi/Y5rY3K1mUwB0WCMoR2ELtUjWYpzpJLulhLVYKuwt6U9a/mIw3g6YJVUStY prflxybvvFNNa9EMU615xrTC6JhUij71iPQBO3Lw=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Nadeau Thomas 
In-Reply-To: <56323052.60107@cisco.com>
Date: Thu, 29 Oct 2015 10:46:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56323052.60107@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3094)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 167, in=2619, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Is there an interim WG meeting today?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:47:16 -0000

	There is none. We are not allowed to have them this close to the =
IETF meeting.

	=E2=80=94Tom

Sent from my Apple ][



> On Oct 29, 2015:10:42 AM, at 10:42 AM, Robert Wilton =
 wrote:
>=20
> Hi,
>=20
> Just to check, I presume that there is no interim WG meeting today =
(I've not seen any agenda), and that it been deferred because of the =
impending IETF 94?
>=20
> Thanks,
> Rob
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Oct 29 08:02:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72FD1A876E for ; Thu, 29 Oct 2015 08:02:42 -0700 (PDT)
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 pze-PuWnpqwg for ; Thu, 29 Oct 2015 08:02:36 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C701A8766 for ; Thu, 29 Oct 2015 08:02:35 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so19927767lfb.2 for ; Thu, 29 Oct 2015 08:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EWfaJBu4+xhNujAiy0qxUPqgipuenIJ5A9/MTHBLurE=; b=yVqmANk4rTlR9Maa76M8h3wwGgGHq+ZvFhmMhQSsf6XGKIJJOiczk92dx9s9zEajJB WME+dipYgwoloazAG99Q3zYJYW/c1uAvvxAKwrSyWcWpjzcOKq/D+W9j1v9vm9khba1z 57nH/fKoQws2TeZhC3Ilw6CBxzvpoC3UyD7lmYQn8HZxv5OFS7X9c6oK6Wpxd08itaZX w8rJIFE9NooOYp0WBy/bgRrAJvecg3O+2s0dm325VYj+zQEcTIY5E5vutcJCd2czpi+n Gxwzu46R0feNLi50uwerth3cw5An0CJJSBE3PeG3V3f+gduTVGDuA/y/fh3qQFk45vxB A3hQ==
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=EWfaJBu4+xhNujAiy0qxUPqgipuenIJ5A9/MTHBLurE=; b=N2u6cBR0rqdCRlBMkuT6PY0QyxA1M3qluAyGveMcfiBKx/BE1ko1mHrySlJeAgPOyC gW6s6RTSUZLeeGZxRNjuNMKoM7pe/yF4dSU+Jz/AmP5BNGj8njsNFF13YlxfiQe+Q6NE WR1TgSFaBuV811pPpv0f0BiqnrvLdoMCe2mdB5vCSPCVoaCNGL4TeXvu2DGS2l7megAz oULCQaEw251IV6+HlrMEi16KYvuc77ifcuOA2kYx2qRu98DGbYQwKT8RpZKBQLxQGzpY 6f+wyDMuUTVGBwIn6E6/SU4fHUyXv+MlL9mrWKOn8o7DB1fJ3SerW1SFUsvUs6Rwr4jW Zk7w==
X-Gm-Message-State: ALoCoQmwTDMF1dOJtZ/Tyv9EjmDNCdgz8r9BRUCuQFonPbeJJJ4O8cg1dSGMAyQv7L9DKxoJ5dnG
MIME-Version: 1.0
X-Received: by 10.25.145.209 with SMTP id t200mr832220lfd.88.1446130954176; Thu, 29 Oct 2015 08:02:34 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Thu, 29 Oct 2015 08:02:34 -0700 (PDT)
In-Reply-To: <20151029.131756.1681194827815089398.mbj@tail-f.com>
References: <20151029091758.GB78922@elstar.local> <20151029.131756.1681194827815089398.mbj@tail-f.com>
Date: Thu, 29 Oct 2015 08:02:34 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a114021b0d2a44e05233f99c1
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 15:02:43 -0000

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

Hi,

I prefer to leave this issue as DEAD.
IMO it is a good thing that all key leafs are mandatory.
Adding new protocol operations should be out of scope for YANG 1.1



Andy


On Thu, Oct 29, 2015 at 5:17 AM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > Hi,
> >
> > the issues Y09 and Y57 were declared dead after intense discussions of
> > various solution proposals. It later appeared to me that there is a
> > solution that we have not considered. The requirement to have a key
> > for every list and unique values in a leaf-list for config nodes is
> > essentially there to allow edits on individual elements using
> > edit-config. The solution not considered so far is simply to give up
> > the ability to edit invidual elements, that is, a config list without
> > a key can only be modified as whole and similarily a leaf-list that
> > allows non-unique values can only be modified as a whole (with
> > edit-config). Comments?
>
> How would this look in edit-config?  There are quite a few details to
> think through in order to support this.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I prefer to leave this issue as DEA=
D.
IMO it is a good thing that all key leafs are mandatory.
=

Adding new protocol operations should be out of scope for YANG 1.1



Andy


On Thu, Oc=
t 29, 2015 at 5:17 AM, Martin Bjorklund <mbj@tail-f.com> wrote:=

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university=
.de> wrote:

> Hi,

>

> the issues Y09 and Y57 were declared dead after intense discussions of=


> various solution proposals. It later appeared to me that there is a
> solution that we have not considered. The requirement to have a key
> for every list and unique values in a leaf-list for config nodes is
> essentially there to allow edits on individual elements using

> edit-config. The solution not considered so far is simply to give up
> the ability to edit invidual elements, that is, a config list without<=
br>
> a key can only be modified as whole and similarily a leaf-list that
> allows non-unique values can only be modified as a whole (with

> edit-config). Comments?



How would this look in edit-config?=C2=A0 There are quite a few details to<=
br>
think through in order to support this.





/martin



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a114021b0d2a44e05233f99c1--


From nobody Fri Oct 30 04:37:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE611B3971 for ; Fri, 30 Oct 2015 04:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZobZGxYPOsQ for ; Fri, 30 Oct 2015 04:37:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 232301B3970 for ; Fri, 30 Oct 2015 04:37:53 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 463351AE0494; Fri, 30 Oct 2015 12:37:51 +0100 (CET)
Date: Fri, 30 Oct 2015 12:37:52 +0100 (CET)
Message-Id: <20151030.123752.762442928111905306.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <562E4BA9.4060106@cisco.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 11:37:54 -0000

Hi,

Ladislav Lhotka  wrote:
>       Moreover - and this might actually be a flaw in 6020bis - it is
>       not allowed to update the "when" statements in a new revision of
>       the module.

I think this text should be added to the update rules:

  o  A "when" statement may be removed or its constraint relaxed.

(compare w/ "must")



/martin


From nobody Fri Oct 30 08:45:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D31A8792 for ; Fri, 30 Oct 2015 08:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XLixmTabsrD for ; Fri, 30 Oct 2015 08:45:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E92AD1A879D for ; Fri, 30 Oct 2015 08:45:49 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BDEB1AE0494; Fri, 30 Oct 2015 16:45:47 +0100 (CET)
Date: Fri, 30 Oct 2015 16:45:50 +0100 (CET)
Message-Id: <20151030.164550.141056459871966571.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 15:45:55 -0000

Hi Andy,

Thank you for this review!  Comments inline.

Andy Bierman  wrote:
> Review of draft-ietf-netmod-rfc6020bis-08.txt
> Andy Bierman
> 2015-10-27
> 
> Sec 1:
>   - text about 'proposed to be used' should be 'going to be used';
>     RESTCONF and JSON drafts part of same WG charter as YANG 1.1

The text actually says:

   Since the publication of YANG version 1
   [RFC6020], YANG has been used or proposed to be used for other
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI
              ^^^^

   [I-D.vanderstok-core-comi]).  Further, other encodings than XML have
   been proposed (e.g., JSON [I-D.ietf-netmod-yang-json]).

So I think this is ok.

>  - RESTCONF needs to be in scope
>      "Other protocols and encodings are possible, but out of scope for this
>       specification."

Are you proposing that we should define rules for RESTCONF in this
document?  I don't think that would be a good idea; the consensus is
rather to remove protocol-specific text from this document.

> Sec. 1.1
>    o  Made "when" and "if-feature" illegal on list keys, unless the
>       parent is also conditional, and the condition matches the parent's
>       condition.
> 
>   - This contradicts text in
>    7.20.2:
>    A leaf that is a list key MUST NOT have any "if-feature" statements.
>    7.21.5:
>    A leaf that is a list key MUST NOT have a "when" statement.
> 
>   - Which is correct?

You're right, it seems this issue was never really resolved.

See the thread:
https://www.ietf.org/mail-archive/web/netmod/current/msg11537.html

the last email on this issue is:
https://www.ietf.org/mail-archive/web/netmod/current/msg11570.html

>   - The 7.* MUST NOT text is not backward compatible with YANG 1.0
>     I think the WG agreed on what the bullet in 1.1 says, not the
>     new restrictions in 7.*

In this email thread it was pointed out that this is very
difficult to check for "when", and at least non-trivial for
"if-feature".

> Sec. 4.2.1, para 2:
> 
>    A server may implement a number of modules, allowing multiple views
>    of the same data, or multiple views of disjoint subsections of the
>    server's data.  Alternatively, the server may implement only one
>    module that defines all available data.
> 
>  - What does 'multiple views of the same data' really mean?

I think the idea is that it fine to implement a native module for
e.g. interface config, in addition to the standard model.

>  - Should 'may' be 'MAY'?

Actually, since the enitire section 4 is not marked as:

   This non-normative section is intended to give a high-level overview
   of YANG to first-time readers.

I think we should remove all 2119-keywords from section 4.

> Sec. 5.6.4: para 2:
> 
>    A server MUST NOT implement more than one revision of a module.
> 
>  - IMO this should a SHOULD NOT or 'MUST NOT advertise' instead
>    of MUST NOT implement

There is an ongoing thread on this topic, the last msg is:

https://www.ietf.org/mail-archive/web/netmod/current/msg14211.html

The question in this msg is not yet answered.

>    Example of possible exception:
>     - rev N-1 has object needed by application
>     - rev N has that object set to status 'obsolete' (and removed)
>     - rev N also has other objects unrelated to the obsolete object
>       but desired for the product feature set

In this case revision N should be implemented.

> Sec. 5.6.4:
>   - para 4: the rules for populating the YANG library should probably be
>     in the yang-library draft
>   - the example on page 35 - 37 should probably be in the
>     yang-library draft

Maybe, but I think this document might seem under-specified unless we
define these rules here.

> Sec. 5.6.5.  Announcing Conformance Information in NETCONF
> 
>   - This should really be in a NETCONF 1.2 spec

Maybe, but we need to work with NETCONF 1.1 now.

>   - RESTCONF draft defines ietf-yang-library requirements for RESTCONF.
>     Why should YANG 1.1 define NETCONF ietf-yang-library requirements?

B/c this document defines both the language and the NETCONF mapping.

> Sec. 5.7: Datastore Modification
> 
>   - This section is NETCONF specific for no apparent reason

Ok.  I suggest s/NETCONF protocol messages/network management protocol
messages/

> Sec. 6.4.1: bullet 5
> 
>    o  The set of variable bindings is empty.
> 
>   - This is not true.  The NACM data model defines the USER variable.
>     This text should say that YANG modules MAY define variable bindings
>     associated with conformance for that module (like NACM does).

No, the USER variable is only available in expressions of type
nacm:node-instance-identifier.   It cannot be used in must/when
expressions.

> Sec. 6.4.1: XPath accessible tree
> 
>   - I object to expanding the context of XPath evaluation for
>     notification and rpc/input, rpc/output.  This is too complicated
>     to implement and under-specified, resulting in poor interoperability.

This is issue Y04, and it was discussed at the WG interim 2014-06-11.

>   - What is the justification for this expansion of complexity?
>     An tool cannot reproduce the same result anymore for
>     ,  or  offline validation.

It couldn't do that earlier either, if there were leafrefs in the
data.

I agree with all your concerns below.  I would prefer Y04-01, but that
would brake RFC 6643 :(

Maybe we should consider doing this only for the 'path' statement.  It
has the same set of issues of course.

>  - Notification context expanded from notification message to message +
>    running config + operational state;  When is the server supposed
>    to gather and check all the data nodes? Event time? Buffer time?
>    Send time? What if operational state or config changes while the
>    notification is in the replay buffer?
> 
>  - RPC input context expanded from input message to message +
>    running config + operational state;  When is the server supposed
>    to gather and check all the data nodes? Parse time? Buffer time?
>    Invocation time?
> 
>  - RPC output context expanded from input message to message +
>    running config + operational state;  Is the server supposed to
>    wait for operational state that may change as a result of the
>    action or rpc being invoked?
> 
>  - The expanded contexts for notification and rpc statements
>    require coupling of the notification and RPC processing
>    implementation components to the datastore and operational data.
>    This is a big change from current NETCONF requirements.
>    YANG should not be making any changes to NETCONF, but it does
>    in several places, effectively creating a new undeclared
>    version of the NETCONF protocol
> 
>  - It is not clear if "action" and "notification" statements
>    nested in the data tree are visible at all for XPath evaluation.
>    (They MUST NOT be visible)

Agree.  I think this is covered since the accessible tree is made up
of data nodes, and action/notification are not data nodes.

>  - NETCONF  and  "filter" element needs clarification
>    wrt/ action and notification within the data tree

Why?  These nodes are not part of the data tree (datastore).

>  - NETCONF and RESTCONF notifications "filter" element needs clarification
>    wrt/ action and notification within the data tree
>
> Sec. 7.5.3: must: last para
> 
>    Also note that the XPath expression is conceptually evaluated.  This
>    means that an implementation does not have to use an XPath evaluator
>    in the server.  How the evaluation is done in practice is an
>    implementation decision.

Is there a problem with this text?

> Sec. 7.5.4.2.  The error-app-tag Statement
> 
>    The "error-app-tag" statement, which is optional, takes a string as
>    an argument.  If the constraint evaluates to false, the string is
>    passed as  in the  in NETCONF.
> 
>  - all the error-message and error-app-tag sub-sections apply to
>    RESTCONF as well as NETCONF.  They share the same error reporting
>    structure

Agree.  But this document does not define RESTCONF.

> Sec. 7.5.8:
> Sec. 7.6.7:
> Sec. 7.7.9:
> Sec. 7.9.6:
> Sec. 7.10.3:  NETCONF  Operations
> 
>  - Can these sections be changed to 'Configuration Datastore Edit
>    Operations' and be generic so they focus on the contents of
>    the datastore before and after the edit, without specifying
>     as the edit operation

Hmm, I think these sections are really edit-config-specific.  YANG
Patch defines its own syntax, for example.

>  - RESTCONF needs to be supported, or all this should be moved
>    to NETCONF 1.2

RESTCONF *is* supported, but it is not *specified* in this document.

> Sec. 7.6.1.  The leaf's default value
> 
>  - this section should mention that a false if-feature
>    or false when-stmt removes the schema node from the
>    tree, which overrides all this text. There is no default
>    value if there is no schema node

Howabout:

  Note that if the leaf or any of its ancestors has a "when" condition
  or "if-feature" expression that evaluates to "false", then the
  default value is not in use.

(and ditto for leaf-list default)

>  - It is confusing that 'must' and 'when' work very
>    differently wrt/ default. must-stmt does not ignore defaults
>    but 'when' overrides and removes the 'when', so it needs to
>    be evaluated before the 'must' stmt:
> 
>    leaf confusing {
>      must "/some/val=4";
>      when "/some/other/value/test";
>      default 42;
>      type int32;
>    }

Yes.

> Sec. 7.7.2.  The leaf-list's default values
> 
>  - this section represents 2 new requirements to compilers
>    that should be more apparent:
> 
>    1) remembering the order of "default" statements
>    2) the default only applies if 'min-elements 0' is in effect

Can you suggest some text to clarify this?

>  - what is the rationale for not applying the default if
>    min-elements is > 0?

B/c the default applies only if no instance exists, and if
min-elements is > 0, there MUST exist an instance.

>  It looks like the leaf/container rule
>    that mandatory and default are not allowed together is
>    being applied here.  This should be more clear here
> 
> Sec. 7.11.  The anyxml Statement
> 
>  - The 'anyxml' statement should be deprecated.
>    If not, this section needs to provide rationale for
>    its 'current' status, given that 'anydata' has been added
>    No use cases are provided for anyxml in the draft.

It should be used when you need to model some XML data.  It is used in
RFC 6241.

>  - There are few if any servers that support anyxml the way
>    it is defined here, and that is not likely to change.

Servers support the data models they advertise.  anyxml is almost
never used in any data model, except for ietf-netconf.  A server that
supports ietf-netconf + YANG will support the subset of XML that is
necessary for YANG.

>    The draft does not specify how the XML must be parsed,
>    stored, or rendered later, if it is part of configuration

Do you want to add more rules around this?

> Sec. 7.15.  The action Statement
> 
>  - an action must appear directly within a container or a
>    list, an 'augment' or a 'uses' statement.
>    Why is 'case' statement left out of direct usage and
>    only allowed via 'uses' or 'augment'?

It is explicitly not allowed in uses:

  Since an action cannot be defined an the top-level of a module or in
  a case statement, it is an error if a grouping that contains an
  action at the top of its node hierarchy is used at the top-level of
  a module or in a case definition.

As for augments, the text actually is broken; it doesn't mention
action or notification at all.  I suggest we add:

  If the target node is a container or list node, the "action" and
  "notification" statements can be used within the "augment"
  statement.

to section 7.17.

(and the reason for not allowing it is that it is not clear what it
means.  for example:

    container foo {
      choice c {
        case a {
          action doit { ... }
        }
        case b {
          notification it-happened { ... }
        }
      }
    }
)


>  - para 2: groupings are not reusable if they contain actions,
>    since they are not allowed in rpc, notification, or action
>    This should be pointed out in the section on groupings

How about this NEW text in 7.12 The grouping Statement:

  Note that if a grouping defines an "action" or a "notification" node
  in its hierarchy, then it cannot be used in all contexts.  For
  example, it cannot be used in an rpc definition.  See ^action^ and
  ^notification^.

>  - the reason for the restriction on top-level action is not
>    given.  The syntax would support this, and the identifier
>    namespace is shared (same as rpc).

They are different:

   The "rpc" statement is used to define an RPC operation.

   The "action" statement is used to define an operation connected to a
   specific container or list data node.

>  - the context nodes for action input and output are very different
>    this could be more clear

Can you suggest some text to clarify this?

>  - is the server required to process XPath or constraints on the
>    output at some point in the execution of the action?

This is not different from rpc output (or norifications).  I think it
is the server's responsibility to send output / notifs that are
syntactically and semanticically valid.  *how* this is done is an
implementation detail.  (FWIW our code doesn't check such constraints;
we leave it to the implementor to do the right thing).

>  - there is no rationale given why the ping operation should
>    be done as an action instead of an RPC

It can be done in both ways.  I think such guidelines are out of scope
for this document.

>    list interface {
>        key "name";
> 
>        leaf name {
>          type string;
>        }
> 
>        action ping {
>          input {
>            leaf destination {
>              type inet:ip-address;
>            }
>          }
>          output {
>            leaf packet-loss {
>              type uint8;
>            }
>          }
>        }
>      }
> 
>  Why not use an RPC?
>  No rationale for both ways to implement an operation
>  like 'ping' is given.
> 
>    rpc ping {
>      input {
>        leaf itf-name {
>          mandatory true;
>          type if:interface-ref;
>        }
>        leaf destination {
>          type inet:ip-address;
>        }
>      }
>      output {
>        leaf packet-loss {
>          type uint8;
>        }
>      }
>    }
> 
> Sec. 7.16.  The notification Statement
> 
>    If a leaf in the notification tree has a "mandatory" statement with
>    the value "true", the leaf MUST be present in a notification
>    instance.
> 
>  - Why is this apply to leaf but not container or choice?
>    They should be mentioned here as well.

... and (leaf-)list min-elements.

This sentence (about mandatory leafs) is present also for rpc
output,input and notif.

But maybe the best solution would be to remove this special sentence -
it is already covered by the text in 8.1 - and that text is more
complete.

But I noticed that the text in 8.1 doesn't mention mandatory choices.
I suggest:

OLD:

   o  The "mandatory" constraint is enforced for leafs, unless the node
      or any of its ancestors has a "when" condition or "if-feature"
      expression that evaluates to "false".

NEW:

   o  The "mandatory" constraint is enforced for leafs and choices,
      unless the node or any of its ancestors has a "when" condition
      or "if-feature" expression that evaluates to "false".


>  - No rationale is given for defining notifications within data nodes
>    vs. top-level notification-stmt

See above for actions.

>  - It is not clear how RFC 5277  can be applied to the
>     notification message that is nested within data, given the
>    location of the 'notification' root within the data tree is
>    not static, and different for each notification.

Why wouldn't a normal filter work?

For example, for the last example in 7.16.3 you can do:

  
    
      
        eth1
      
    
  

in order to receive notifs for eth1 only.
     


> Sec. 7.17.  The augment Statement
> 
>  - can augment path-stmts contain nested 'action' or 'notification'
>    nodes and subnodes, like for rpc-stmt?  If, so then the
>    sub-statements are restricted by context, e.g., action-stmt
>    cannot be added to /foo/bar/action/input/baz.

Above I suggested we add:

  If the target node is a container or list node, the "action" and
  "notification" statements can be used within the "augment"
  statement.

I am not sure if that covers your concern?

> Sec. 7.18.2.  The base Statement
> 
>   - There are no examples or use-cases given for multiple base
>     statements. An example should be added.

Ok.

>  - Para 1 says:
>       If multiple "base" statements are present, the identity is derived
>       from all of them.
> 
>    The draft does not say how this is done. It is not clear how
>    a particular identity-stmt has multiple bases and how a server
>    determines an identify is derived from multiple bases. Examples
>    of a 'pass' and 'fail' for this test should be given.

This section simply defines what "derived from" means.  An identity
can be derived from zero, one or many other identites.

> Sec. 7.19.  The extension Statement
> 
>    "YANG statements in extensions MUST follow the syntactical rules
>     in Section 14."
> 
>   - What is the rationale for this rule? Extension statements
>     should be outside the scope of YANG. They should just follow the
>     syntax rules in sec. 6.

The idea is that it is fine to use normal core YANG statements as
substatements to an extension, but then they must follow the rules for
these statements.  If you need some other syntax, then you have to
define a new extension.  For example:

      // legal
      ex:arg-type {
        type enumeration {
          enum "none";
          enum "all";
        }
      }
        
      // illegal
      ex:arg-type {
        type enumeration {
          pattern "none|all";
        }
      }
        
>  - This says YANG syntax MUST be preserved, but YANG semantics
>    can be ignored or changed.  Is that the intent?

Probably not.  I think semantics must be preserved as well.  Do you
agree?

>    "An extension can allow refinement (see Section 7.13.2) and deviations
>    (Section 7.20.3.2), but the mechanism for how this is defined is
>    outside the scope of this specification."
> 
>  - This text about refinement and deviations is not clear.
>    Is it MUST, SHOULD, or MAY? It is normative, but unspecified.

It's like:

  The substatements of an extension are defined by the "extension"
  statement, using some mechanism outside the scope of this
  specification.

How does a parser know whih substatements are allowed in a
specific extension?  There is no standard formal way to define this.
Same with refinement and deviations.

> Sec. 7.20.2.  The if-feature Statement
> 
>  - This section does not define how "(" if-feature-expr ")" is
>    evaluated, or how the precedence is evaluated if parens are used.
>    Evaluated of nested parens is not defined either.

Good catch.  I suggest:

OLD:

   The if-feature boolean expression syntax is formally defined by the
   rule "if-feature-expr" in Section 14.  When this boolean expression
   is evaluated, the operator order of precedence is (highest precedence
   first): "not", "and", "or".

NEW:

   The if-feature boolean expression syntax is formally defined by the
   rule "if-feature-expr" in Section 14.  Parenthesis are used to group
   expressions.  When the expression is evaluated, the order of
   precedence is (highest precedence first): grouping (parenthesis),
   "not", "and", "or".

>  - Are operators of the same type evaluated left to right?

This doesn't matter.

>  - should be some examples to show precedence
>    "not foo or bar and baz"
>    "(not foo) or (bar and baz)"
>    "not (foo or bar) and baz"

Ok.

> Sec. 7.21.2.  The status Statement
> 
>    If a definition is "current", it MUST NOT reference a "deprecated" or
>    "obsolete" definition within the same module.
> 
>    If a definition is "deprecated", it MUST NOT reference an "obsolete"
>    definition within the same module.
> 
>  - It is not clear what it means for a definition to reference
>    another definition.

Do you have any suggestions for more explanatory text?

>  - Why is this restriction limited to the same module and not
>    include imported modules?

An imported defintion might get a new status in a new revision.  If
we has this rule across modules, it would mean that a server wouldn't
be able to implement certain combinations of otherwise legal modules.

>  - Don't the 'deprecated' and 'obsolete' values ripple up through
>    the data tree, all the way to the top-level node?

No.

>    Otherwise
>    a current list can have deprecated or obsolete children.

Sure, don't you think that is ok?  Otherwise a single deprecated node
would essentially deprecate the enitre module.

>    It should be explained how status is contained (or not)
>    for nodes within other statements.

I don't understand what you mean.  Can you suggest some text?

>  - What does it mean to use a current grouping that contains deprecated
>    or obsolete nodes?  Is this allowed?

Sure, this is allowed.

> Sec. 7.21.5.  The when Statement
> 
>  bullet 3:
>  - Altering the tree changes means that each when-stmt processes
>    a different XML document.  IMO it is a bad idea to replace a
>    node that is in the tree with a dummy node.  It is OK to create
>    a temp dummy node as an implementation detail to decide if
>    a when-stmt is true or not.

We've discussed this at length on the ML.  I think the current text
reflects WG consensus.  Without this text, it is not clear how to
interpret the theoretical corner case when the expression references
nodes that are being augmented:

   augment /... {
     when "foo != 42";
     leaf foo {
       type int32;
     }
   }

>  "If the XPath expression references any node that also has associated
>  "when" statements, these "when" expressions MUST be evaluated first.
>  There MUST NOT be any circular dependencies in these "when"
>  expressions."
> 
>  - This requirement is not implementable and needs to be removed.
>    The draft should just say what the result is supposed to be
>    (and it does -- all nodes with false when-stmts are removed)

Would it be ok to write "conceptually evaluated"?

This rule was added as part of fixing Y18.  See the issue list for an
example of why it is needed.


>  "Note that the XPath expression is conceptually evaluated.  This means
>   that an implementation does not have to use an XPath evaluator in the
>   server.  The "when" statement can very well be implemented with
>   specially written code."
> 
>  - The rules for how to process a when-stmt contradict this
>    text at the end of the section that when-stmt is only
>    conceptual.  No implementation details should be mandated.

Agreed.

> Sec. 8.1: Constraints on Data
> 
>  - bullets say constraint MUST be true, but this info should really
>    be part of NETCONF, and should say what a NETCONF server should
>    so when a constraint is false

Do you want to make this text *more* NETCONF-specific?  The idea was
that these conditions hold regardless of which protocol is used.

> Sec. 8.2.1.  Payload Parsing
> 
>  - The NETCONF-specific error handling text should be made more generic

I don't see how this can be made more generic.  The text specifies
which NETCONF error messages should be returned.  The equivalenmt for
RESTCONF is HTTP status codes, for example.

> Sec. 8.2.2.  NETCONF  Processing
> 
>   - This text should be more generic if possible.
>   - Why do all the NETCONF implementation requirements apply only
>     to  and not also ?

 doesn't contain any of the "operation" or "insert"
attributes.

> Sec. 9.6.4.1.  The enum's Substatements
> Sec. 9.7.4.1.  The bit's Substatements
> 
>  - example of if-feature should be given

Ok.

>  - It should be explicitly stated that if-feature has no effect
>    on auto-numbering

Ok.

>  - what happens if a feature value is changed at boot-time or run-time,
>    causing valid enumeration or bits values within a datastore to
>    suddenly become invalid?  Changing the value set of a leaf or leaf-list
>    with if-feature is very complicated and under-specified

I think this is an implementation detail.  Some implementations don't
even support enabling/disabling features.

Compare with this situation:

  leaf foo {
    if-feature foo-feature;
    ...
  }

  leaf my-i-i {
    type instance-idnetifier;
  }

and then the datastore contains:

   my-i-i = /foo

Now suppose you disable 'foo-feature' in your server.  What happens to
the datastore?

> Sec. 9.9.1.  (Leafref) Restrictions
> 
>  - can leafref require-instance be changed via typedef?

Yes; in general all restrictions can be done via a typedef.

>    typedef foo-ptr {
>      type leafref {
>        path "/some/node/foo";
>      }
>    }
> 
>    typedef foo-ptr2 {
>      type foo-ptr {
>        require-instance false;
>      }
>    }
> 
> Sec. 9.10.5.  (Identityref) Usage Example
> 
>  - Add an example and use-case showing multiple base-stmts
>    for an identityref

I will try to come up with something simple.

> Sec. 9.12.  The union Built-In Type
> 
>  - What happens to a union type when a feature is enabled or disabled,
>    and there are 1 or more bits or enumeration member types that are
>    affected, such that the member type changes? Is this just an
>    implementation detail?
> 
> 
> Sec. 10.1.1.  current()
> 
>  - an example for current() should be given

Ok, NEW:

With this list:

  list interface {
    key "name";
    ...
    leaf enabled {
      type boolean;
    }
    ...
  }

the following leaf defines a must expression that ensures that the
referred interface is enabled:

  leaf outgoing-interface {
    type leafref {
      path "/interface/name";
    }
    must '/interface[name=current()]/enabled = "true"';
  }


> Sec. 10.3.1.  deref()
> 
>  - why is this XPath function needed?
>    No use-cases are explained.
>    The example given shows that deref(.) saves some extra typing
>    from the previous line.  Not very interesting new feature.

If the node is an instance-identifier, it is not possible to check the
target node w/o deref().

>  - what if the first node in the parameter node-set is another
>    leafref?  Does this function keep de-referencing until it
>    gets to a plain leaf?

No.

> Sec. 10.4.1.  derived-from()
> Sec. 10.4.2.  derived-from-or-self()
> 
>  - example for derived from in wrong section

Fixed.

>  - no example given for derived-from-or-self()

Fixed.

>  - no explanation why 1 function would be used instead of the other
>  - these functions do not actually define what it means
>    to be "derived from".

This is explained in 7.18.2.  I will add a reference to that section.

>  What does it mean in terms of base-stmt matching
>    like an identityref?
>  - What if there are multiple bases?  These functions only support 1
>    base.

Correct.  If you want to check that it is derived from both "foo" and
"bar", you'll have to write:

     derived-from(x, "ex-module", "foo") and
     derived-from(x, "ex-module", "bar")


> Sec. 11.  Updating a Module
> 
>  - seems all instances of 'may' need to be changed to 'MAY'

Hmm, I think "may" is correct.  Could have been "can" as well.  MAY is
used to denote something OPTIONAL.  (FWIW, this is unchanged from
6020).

>  - last para:
>    In statements that have any data definition statements as
>    substatements, those data definition substatements MUST NOT be
>    reordered.
> 
>    Why is this requirement in here?  Seems like changing the
>    order of case-stmts within a choice-stmt does not matter.
>    Changing the order of augment-stmts does not matter.

An augment is not a data-def stmt.

>    Why does changing order of any data-def statement break an old client?

For NETCONF, the order matters for rpc/action input/output.  Maybe
some other protocol use the specified order to simplify things?

If that is not important, I think we can at least relax this rule to
only apply to rpc/action input/output - and gorupings, since they can
be used in input/output.  Hmm.

> Sec 12.  Coexistence with YANG version 1
> 
>  - para 4: :"server MAY implement both..." contradicts this text in 5.6.4:
>    "A server MUST NOT implement more than one revision of a module."

"both modules" was supposed to mean "A and B".  I will write:

  If a YANG version 1 module A imports module B without revision, and
  module B is updated to YANG version 1.1, a server MAY implement both
  these modules (A and B) at the same time. 

>  - this section does not address what happens if protocol-accessible
>    objects have changed between the implemented YANG 1.0 module revision
>    and the implemented YANG 1.1 module revision.  Since NETCONF and
>    RESTCONF do not specify YANG language version or YANG module revision
>    in edit payloads or retrieval filters, how does the server even
>    know if a client is asking for the YANG 1.0 vs. YANG 1.1  implementation
>    of a particular data node?

What do you mean with 1.0 vs. 1.1 implementation of a data node?  The
data node will have a single implementation in the server.


> Sec. 18.  Contributors
> 
> OLD:
>     - Andy Bierman (Brocade)
> NEW:
>     - Andy Bierman (YumaWorks)

Fixed.

> Nits:
>  p8: para 1:  s/propsed/proposed/
>  p10: bullet 3: s/defintions/definitions/
>  p37, para 4: s/enconding/encoding/
>  p43, para 3: s/SHOULD not/SHOULD NOT/

Fixed.


/martin


From nobody Fri Oct 30 22:03:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2851B3409 for ; Fri, 30 Oct 2015 22:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ2UncckX_qw for ; Fri, 30 Oct 2015 22:03:55 -0700 (PDT)
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 6A1521B3407 for ; Fri, 30 Oct 2015 22:03:55 -0700 (PDT)
Received: from [192.168.11.205] (i223-218-131-178.s41.a014.ap.plala.or.jp [223.218.131.178]) by mail.nic.cz (Postfix) with ESMTPSA id B4A4318C6FC; Sat, 31 Oct 2015 06:03:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1446267832; bh=EOydYl/3QsGM5UpNfcAixZtkb3dj0J1PQalCUuRwKh8=; h=From:Date:To; b=eNumzaqbXavqVG+tBokci3DM0j+qY1P+MryirsqTxPERZZTo/bVY+2hRJhSZaFItD vRcndycg3DWo4qKuFrYAJPqkzNiYSybdf8MvzsSkl4MGE+9Ldlwvq3CnZ32uHO+awC 8WzNqwQq3TVUJrhudc18q2/vJ69x78XBFxRQBYdc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Ladislav Lhotka 
In-Reply-To: <20151030.123752.762442928111905306.mbj@tail-f.com>
Date: Sat, 31 Oct 2015 14:03:47 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <219A1402-C5D3-47A4-B29A-EC83DB41D43E@nic.cz>
References: <562E4BA9.4060106@cisco.com>  <20151030.123752.762442928111905306.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3096.5)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Oct 2015 05:03:57 -0000

> On 30 Oct 2015, at 20:37, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Ladislav Lhotka  wrote:
>>      Moreover - and this might actually be a flaw in 6020bis - it is
>>      not allowed to update the "when" statements in a new revision of
>>      the module.
> 
> I think this text should be added to the update rules:
> 
>  o  A "when" statement may be removed or its constraint relaxed.
> 
> (compare w/ "must")

Agreed.

Lada

> 
> 
> 
> /martin

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





From nobody Sat Oct 31 08:26:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205A1A906E for ; Mon, 19 Oct 2015 06:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkjXeElNfByZ for ; Mon, 19 Oct 2015 06:02:33 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A0C1A6EFC for ; Mon, 19 Oct 2015 06:02:33 -0700 (PDT)
Received: by lffz202 with SMTP id z202so28631752lff.3 for ; Mon, 19 Oct 2015 06:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WhnBR0kg14iLEHxjToBIwvWA5iyPe6ifHf3E8lMK4Yw=; b=EoKEOXxBTvK4TR5j7eSWS363ODnekYIh/Pc3dQ23Aw90or8vsBExekQ4tRtQkj8k+U hj/MW/qWYLf8qbpyvWGIa+FPeL/S7YHZGBGNRVoizub523nQl9T6qgRtT0TrN4KV7wCG 4l0N0x9fdrXs9w99r1wmQh2v64cz1kn4PKXEsVzTSZGBJxsFd72Segc+aPjNKVRAqtSa 3QitzBFhYT8vpKjy2gV5PGWjc0ojow07yA0IT6hlFxUwK2W0UWeTXWaLzI1SS8mE7LIi RAwjBm9U9SnfEbjaTW0/6MX+w3G/3a2YGFRUqFMyp7NaJLojIPjNzJkTxiYKRvAasDac 4Idw==
MIME-Version: 1.0
X-Received: by 10.25.77.133 with SMTP id a127mr9622254lfb.19.1445259751141; Mon, 19 Oct 2015 06:02:31 -0700 (PDT)
Received: by 10.114.77.38 with HTTP; Mon, 19 Oct 2015 06:02:31 -0700 (PDT)
In-Reply-To: <9EABFEDD335B3840A1BEC0C1E838BD295A3D33DA8C@HE113457.emea1.cds.t-internal.com>
References: <9EABFEDD335B3840A1BEC0C1E838BD295A3D33DA8C@HE113457.emea1.cds.t-internal.com>
Date: Mon, 19 Oct 2015 15:02:31 +0200
Message-ID: 
From: Sladjana Zoric 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=001a1141eeec133a5c052274c295
Archived-At: 
X-Mailman-Approved-At: Sat, 31 Oct 2015 08:26:15 -0700
Subject: [netmod] Fwd: New Version Notification for draft-faq-netmod-cpe-yang-profile-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Oct 2015 13:02:34 -0000

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

 Hi all,
We have submitted a new draft =E2=80=9CYANG Models Required for Managing Cu=
stomer
Premises Equipment (CPE) Devices=E2=80=9D - (draft-faq-netmod-cpe-yang-prof=
ile-00).
This document collects together the YANG models necessary for managing a
NETCONF-enabled Customer Premises Equipment (CPE) device.
Any comments or feedback is appreciated.
Thanks,
Sladjana

-----Urspr=C3=BCngliche Nachricht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Gesendet: Freitag, 16. Oktober 2015 09:17
An: Zoric, Sladjana; Farrer, Ian; Qi Sun; Qi Sun; Mikael Abrahamsson;
Mikael Abrahamsson; Farrer, Ian; Zoric, Sladjana
Betreff: New Version Notification for
draft-faq-netmod-cpe-yang-profile-00.txt


A new version of I-D, draft-faq-netmod-cpe-yang-profile-00.txt
has been successfully submitted by Sladjana Zoric and posted to the IETF
repository.

Name:           draft-faq-netmod-cpe-yang-profile
Revision:       00
Title:          YANG Models Required for Managing Customer Premises
Equipment (CPE) Devices
Document date:  2015-10-16
Group:          Individual Submission
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-faq-netmod-cpe-yang-profile-00.t=
xt
Status:
https://datatracker.ietf.org/doc/draft-faq-netmod-cpe-yang-profile/
Htmlized:
https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-00


Abstract:
   This document collects together the YANG models necessary for
   managing NETCONF-enabled Customer Premises Equipment (CPE) devices.




Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat

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




Hi all,

We have submitted a new draft =E2=80=9CYANG Models Required for Managing Cu=
stomer Premises Equipment (CPE) Devices=E2=80=9D - (draft-faq-netmod-cpe-ya=
ng-profile-00). This document collects together the YANG models necessary f=
or managing a NETCONF-enabled Customer Premises Equipment (CPE) device.

Any comments or feedback is appreciated.

Thanks,

Sladjana



-----Urspr=C3=BCngliche Nachricht-----

Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf=
.org]

Gesendet: Freitag, 16. Oktober 2015 09:17

An: Zoric, Sladjana; Farrer, Ian; Qi Sun; Qi Sun; Mikael Abrahamsson; Mikae=
l Abrahamsson; Farrer, Ian; Zoric, Sladjana

Betreff: New Version Notification for draft-faq-netmod-cpe-yang-profile-00.=
txt





A new version of I-D, draft-faq-netmod-cpe-yang-profile-00.txt

has been successfully submitted by Sladjana Zoric and posted to the IETF re=
pository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-faq-netmod-cpe-yang-pro=
file

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG Models Required for Managing =
Customer Premises Equipment (CPE) Devices

Document date:=C2=A0 2015-10-16

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-faq-netmo=
d-cpe-yang-profile-00.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-faq-netmod-cpe-yang-profile/=


Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-00





Abstract:

=C2=A0 =C2=A0This document collects together the YANG models necessary for<=
br>
=C2=A0 =C2=A0managing NETCONF-enabled Customer Premises Equipment (CPE) dev=
ices.









Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







--001a1141eeec133a5c052274c295--