Hi, Mahesh Jethanandani <[email protected]> wrote: > This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. > > As part of the LC, there were a couple of comments/questions > raised. In particular > > - Vladmir reported an error, which Martin said is fixed in his local copy.
Fixed. > - Robert suggested that “/yang-library/checksum” should be a > reference. Juergen supported that comment, so I am assuming that > that will be incorporated into the draft. Yes, fixed. > - Andy had questions around datastore set to “conventional” Fixed. > , about origin filter limited to 1 source Fixed. > and the behavior of with-defaults. There were no additional changes to the document from the discussion about this. > I see some discussion around it with the authors > agreeing that some of them need some text clarifying the > position. Can the authors please post the suggested text/additions > for the WG to review. > - Anything else?? > > Once an updated draft has been posted, I will do a writeup on the > drafts and send it to IESG. The issues above are now addressed, in draft-ietf-netconf-nmda-netconf-03. There were no additional comments on draft-ietf-netconf-nmda-restconf-02, so I believe this version is ready. /martin > > Thanks. > > > On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > 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 > >> <[email protected] > >> <mailto:[email protected]><mailto:[email protected] > >> <mailto:[email protected]>>> 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 > >> > >> [email protected] <mailto:[email protected]><mailto:[email protected] > >> <mailto:[email protected]>> > >> > >> https://www.ietf.org/mailman/listinfo/netmod > >> <https://www.ietf.org/mailman/listinfo/netmod> > >> > > > >> _______________________________________________ > >> netmod mailing list > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/netmod > >> <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/ > > <https://www.jacobs-university.de/>> > > > > _______________________________________________ > > netmod mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > > <https://www.ietf.org/mailman/listinfo/netmod> > Mahesh Jethanandani > [email protected] > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
