On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, > > On 07/02/2018 02:33, Andy Bierman wrote: > > > > On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < > [email protected]> wrote: > >> For folks that provided comments as part of LC, please verify that your >> comments have been adequately addressed by -03 version of the draft. >> >> > > Most comments have been addressed. > > > The "with-defaults" parameter does not apply when interacting with an > > operational datastore. > > > There is no explanation of why the with-defaults parameter does not apply > to <operational>. > This is confusing. The solution that has been a standard for years still > applies to > all datastores, except a completely different mechanism (origin-filter) is > used instead > for 1 datastore. > > If the server code can identify a default so it can be tagged > origin=or:default, then it can > also support with-defaults. > > I prefer the sentence above be changed, so that a server MAY implement > with-defaults > for <operational>. If the client sends <with-defaults> it should be OK to > honor it instead > of returning an error. > > I have two concerns with changing this to a MAY: > > (1) The most useful "with-defaults" behavior differs for <operational> vs > the configuration datastores, but with-defaults only allows a single > standard behavior to be specified. > > E.g. for configuration datastores the most appropriate semantics (if the > client doesn't explicitly ask for something else) is "explicit". i.e. you > give back exactly what was put in. > > But, for operational, the most appropriate semantics (if the client > doesn't explicitly ask for something else) is something like "report-all", > i.e. the device reports the precise current state including any defaults. > However, we felt that this would return too much unnecessary data, hence > why the datastore architecture defines "in-use" data, allowing the server > to prune out any data that is clearly irrelevant. > > (2) <operational> is a new datastore. I personally don't want each server > choosing how the data is returned, which requires that clients must handle > all variants. It would be better for the draft to specify the standard > semantics to use unless a client has explicitly requested something else. > > I'm not opposed to a "with-defaults-bis", or a new draft covering > "with-defaults" for <operational>", but I think that: > (i) We shouldn't delay the NMDA protocol drafts for this, this can be done > as separate draft adding extra optional functionality. > (ii) The semantics for retrieving data from operational (or notifications) > should be as defined by "in-use" in the NMDA architecture, unless a client > has explicitly specified, or configured, a different behavior. > (iii) Probably the only existing option defined in "with-defaults" that > makes sense for <operational> is a variant of "trim" that is specified to > return what is defined as returning the "in-use" values, but also excluding > any values that match a default value specified in the schema. > > I think your approach violates the Postel Principle. "Be liberal in what you accept" is about robustness. Rejecting parameters for no good reason is about fragility. I never said change the behavior for <operational> if no <with-defaults> is present. If the parameter is provided it is trivial for the server to honor it. The most useful value (report-all) is the default, not leave out all defaults, like <get-config>. > Thanks, > Rob > > > Andy > > > Andy > > > > >> 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:j.schoenwaelder@jacobs >> -university.de><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] >> >> >> >> _______________________________________________ >> Netconf mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netconf >> > > > > _______________________________________________ > Netconf mailing > [email protected]https://www.ietf.org/mailman/listinfo/netconf > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
