For folks that provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft.
Thanks Mahesh Jethanandani [email protected] > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <[email protected]> wrote: > > 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
