On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: > > I do have one additional thought below on > draft-ietf-netmod-revised-datastores section 5.3 default handling process. > See in-line... >
Well, this document is with the RFC editor now. I do not think it needs clarification. It already has text in 5.3 such as: Requests to retrieve nodes from <operational> always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device. /js > From: Robert Wilton -X, January 31, 2018 6:31 AM > > > Hi Andy, > > On 31/01/2018 09:22, Andy Bierman wrote: > > > On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@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. > > <eric> These are good examples. It would be great if section 5.3 could be > tweaked to make clearer the relationship between running datastore defaults > and other operational datastore defaults for the same tree. > > For example, let’s say I create a configured subscription, and the default > transport protocol is NETCONF. NETCONF will be used for that subscription > even though the node might not be populated. In this case, the object would > not appear in the running datastore, but MUST* appear in the operational > datastore with the default origin (as it is in-use). > > This to me is the desired behavior as it doesn’t incorrectly add information > to the running datastore, but shows what is in-use within operational. I > suspect other such relationships for other operational tree defaults could be > asserted, perhaps based on the origin. > > (* Maybe ‘MUST eventually’, as obviously there is a temporal relationship > between the two datastores.) > > Eric > > 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/> > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org<mailto:netmod@ietf.org> > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > 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 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
