Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
Robert Wilton <rwilton@cisco.com> Wed, 31 January 2018 11:32 UTC
Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4462131A3E; Wed, 31 Jan 2018 03:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57jh5x_pgABK; Wed, 31 Jan 2018 03:32:27 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0CA131A3F; Wed, 31 Jan 2018 03:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17286; q=dns/txt; s=iport; t=1517398284; x=1518607884; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=w4Ydop+F9EYjvECr2jDuFQktOhfqNbqL4mXxbAywVOg=; b=VzPAYkFSEw5bR58V58KuH5QDHw+tLqpYmmWAqday71oPzAjRK15xzmSm tN2EL8f3tjLxIjcCY86AFl1FpG0whKF2cExN+xlESXg2hdp4Qf+N2vC4G 8jbicEYQFpcUUKjEXr8Q2RX7cZJXDoyDGSEsS11i4TJP1Uppzd5KLM2lD U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B6AQA6qHFa/xbLJq1SBgMZAQEBAQEBAQEBAQEBBwEBAQEBgxGBF3Uog2CLGI96kXKFaYICChgBCoM6gQ9PAoMiFAEBAQEBAQEBAmsohSMBAQEDAQEBIUsLBQkCCQIQAgYnAwICGwwfAw4GAQwGAgEBFQKKEggQiGOdcYInJoo9AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFhFaDbIFoKYMFgy8BAQKBRQMPAjcmglCCZQWaAooclWyMMIFlhhiPVIgVgTw2IoFQMxoIGxU9giqCHDkcggZBN4lpgksBAQE
X-IronPort-AV: E=Sophos;i="5.46,439,1511827200"; d="scan'208,217";a="1714250"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 11:31:21 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0VBVLSe001928; Wed, 31 Jan 2018 11:31:21 GMT
To: Andy Bierman <andy@yumaworks.com>, netconf <netconf@ietf.org>, NETMOD Working Group <netmod@ietf.org>
References: <CF60B198-564B-499A-9B17-E992569074CB@gmail.com> <D3BBAA02-AA28-4E13-A8CF-9B7925DEE2FF@gmail.com> <CABCOCHTgYWgFNZNi-x5V5uErgd331=y9j-mW=xvFnEArLdykzw@mail.gmail.com> <20180131081118.uqxivaxbkbbzzmji@elstar.local> <CABCOCHRWZPO=d4gXTEXRL4vY3MNEwMGJi3+Ug3q_GVwJcNFYWw@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com>
Date: Wed, 31 Jan 2018 11:31:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CABCOCHRWZPO=d4gXTEXRL4vY3MNEwMGJi3+Ug3q_GVwJcNFYWw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------059635660E4F88B64D01C962"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ID8juJGbGC9Wii_416rZGy1G_yg>
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 11:32:31 -0000
Hi Andy, On 31/01/2018 09:22, Andy Bierman wrote: > > > On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>> wrote: > > On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: > > Hi, > > > > I have some questions about these drafts. > > > > 1) what if datastore set to "conventional"? > > There are many places where a datastore-ref type is used. > > However, "conventional" is valid for base "datastore", even > though > > it is ambiguous as a datastore selector. > > We can add explicit text that an identity that does not resolve to a > datastore implemented by the server results in an invalid value error. > > > > OK > > > 2) origin filter is limited to 1 source > > This filtering seems rather limited. A client must retrieve > > <with-origin> and check > > all the values in use, then make repeated requests for each > source as a > > different > > <origin-filter> leaf > > If the client does <with-origin>, then it has all origin information > and it can filter locally. That said, we could make origin-filter a > leaf-list which is logically ORed so that one can retrieve > origin-filter=or:system or origin-filter=or:learned in one request. > > > > OK > > > 3) with-defaults broken > > The operational datastore does not support with-defaults. > > Instead, the client must use origin-filter=or:default or > with-origin > > and check all the origin attributes. Since a client needs > to use > > with-defaults for other datastores, this special handling of > > <operational> > > seems unhelpful. > > I think the with-defaults semantics for conventional configuration > datastores are much more complicated than necessary for the > operational state datastore. Note that that the operational state > datastore reports in-use values not really defaults: > > <leaf or:origin='default'>foo</leaf> > > This reports that the value 'foo' is in use and that it originates > from a default value. Note that this could also be > > <leaf or:origin='intended'>foo</leaf> > > in case the intended configuration datastore configured the value > 'foo' (despite this value matching the default). The with-defaults > solution is pretty complex because it tries to handle how different > systems deal with configuration defaults. The idea is to not carry > this complexity over to in-use values in the operational state > datastore. > > > > Before NMDA, the client could decide if it wanted to retrieve default > nodes or not. > This client-choice has been removed from NMDA, which is a problem. We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture): - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value). - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data. In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use). Some examples to illustrate the behavior: (i) If a protocol, e.g. OSPF, is not enabled/running then <operational> does not need to return any data for it. It would be reasonable to return a flag to indicate that OSPF is not enabled/running. (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data for it. (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off. (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported. This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores. As I recall, there were a couple of reasons that we decided to have a different behavior for <operational>: (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants). (b) to remove any potential ambiguity if data isn't returned. I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled. If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it. In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities. Hence being explicit about stuff that is in use seems more robust. 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 <https://www.jacobs-university.de/ > <https://www.jacobs-university.de/>> > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] LC of NDMA NETCONF/RESTCONF drafts Mahesh Jethanandani
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Kent Watsen
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Vladimir Vassilev
- [netmod] WG LC comment on draft-ietf-netconf-nmda… Robert Wilton
- Re: [netmod] [Netconf] WG LC comment on draft-iet… Juergen Schoenwaelder
- Re: [netmod] LC of NDMA NETCONF/RESTCONF drafts Mahesh Jethanandani
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Kent Watsen
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] LC of NDMA NETCONF/RESTCONF drafts Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Ladislav Lhotka
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Eric Voit (evoit)
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Eric Voit (evoit)
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Mahesh Jethanandani
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Mahesh Jethanandani
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Robert Wilton
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Mahesh Jethanandani
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Phil Shafer
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Juergen Schoenwaelder
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Martin Bjorklund
- Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCON… Andy Bierman