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. - 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. - Andy had questions around datastore set to “conventional”, about origin filter limited to 1 source and the behavior of with-defaults. 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. 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
