Andy Bierman <a...@yumaworks.com> wrote: > On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwil...@cisco.com> wrote: > > > > > > > On 07/02/2018 14:23, Andy Bierman wrote: > > > > > > > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwil...@cisco.com> wrote: > > > >> Hi Andy, > >> > >> On 07/02/2018 02:33, Andy Bierman wrote: > >> > >> > >> > >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < > >> mjethanand...@gmail.com> 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>. > > > > OK, so one option is to allow the "with-defaults" parameter for the > > <operational> datastore, but specify in both the NETCONF NMDA and RESTCONF > > NMDA drafts how "with-defaults" semantics apply to any operational > > datastore: > > > > 1) Regardless of what is reported in the "basic-mode" capability > > parameter, the default behavior for <operational> is "report-all", with > > semantics as described below: > > 2) "report-all" for operational datastores is defined as returning all "in > > use" values (i.e. as specified in section 5.3 of the NMDA architecture, so > > default values that are not "in use" are not returned). > > 3) "trim" for operational datastores is defined as returning all "in-use" > > values (... as 5.3) except that values that match the value specified in > > the schema "default" statement are omitted. Note, clients cannot > > distinguish between a value that is omitted because it is not in use, vs a > > value that is omitted because it matches the schema default. > > 4) "explicit" for operational datastores is defined as returning the same > > as "report-all", defined above. > > 5) "report-all-tagged" for operational datastores is defined as returning > > the same as "report-all", except that all values that match the values > > specified in the schema "default" statement are tagged, as described in > > with-defaults (RFC 5243). > > > > Also note - there is no change in semantics or behavior to how > > "with-defaults" works for conventional datastores. > > > > Thoughts? > > > > > This looks good. > > Showing the work... > > 1) there is no YANG default for <with-defaults> parameter. > The behavior if this parameter is missing is determined by the operation
Right. So in this case (get-data of operational), it would return all default values in use. > 2) The <get-data> operation returns all values in use. > The only way to suppress defaults is to use <origin-filter> > (e.g., request all origins except 'default') Or use with-defaults = trim. > 3) The <with-defaults> parameter for <operational> is mostly a NO-OP. > It does not add or remove any nodes that would be returned. > The "report-all-tagged" value does add the "default> attribute, which > is useful > for clients that process these attributes already > > 4) The values that are tagged default are the same ones that the server tags > as origin=default. > > 5) It still seems to up to the server "basic-mode" as to what is considered > "set by default". This messy aspect of NETCONF is minimized in > <get-data> because > the server usually returns all values in use. /martin > > > Thanks, > > Rob > > > > > > Andy > > > > > > > > > > > >> Thanks, > >> Rob > >> > >> > >> > > Andy > > > > > >> > >> > >> Andy > >> > >> > >> > >> > >>> Thanks > >>> > >>> Mahesh Jethanandani > >>> mjethanand...@gmail.com > >>> > >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <m...@tail-f.com> wrote: > >>> > > >>> > Hi, > >>> > > >>> > Mahesh Jethanandani <mjethanand...@gmail.com> 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 < > >>> j.schoenwael...@jacobs-university.de> 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 < > >>> j.schoenwael...@jacobs-university.de <mailto:j.schoenwaelder@jacobs > >>> -university.de><mailto: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 > >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g> > >>> >>>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> _______________________________________________ > >>> >>>> > >>> >>>> netmod mailing list > >>> >>>> > >>> >>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org > >>> <mailto:netmod@ietf.org>> > >>> >>>> > >>> >>>> https://www.ietf.org/mailman/listinfo/netmod < > >>> https://www.ietf.org/mailman/listinfo/netmod> > >>> >>>> > >>> >>> > >>> >>>> _______________________________________________ > >>> >>>> netmod mailing list > >>> >>>> netmod@ietf.org <mailto:netmod@ietf.org> > >>> >>>> 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 > >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g> > >>> >>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/ < > >>> https://www.jacobs-university.de/>> > >>> >>> > >>> >>> _______________________________________________ > >>> >>> netmod mailing list > >>> >>> netmod@ietf.org <mailto:netmod@ietf.org> > >>> >>> https://www.ietf.org/mailman/listinfo/netmod < > >>> https://www.ietf.org/mailman/listinfo/netmod> > >>> >> Mahesh Jethanandani > >>> >> mjethanand...@gmail.com > >>> >> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> netc...@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > >> > >> > >> > >> _______________________________________________ > >> Netconf mailing > >> listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > >> > >> > >> > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod