Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <[e-mail]> wrote:
> 
> >
> >
> > On 07/02/2018 14:23, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <[e-mail]> wrote:
> >
> >> Hi Andy,
> >>
> >> On 07/02/2018 02:33, Andy Bierman wrote:
> >>
> >>
> >>
> >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> >> [e-mail]> 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
> >>> [e-mail]
> >>>
> >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <[e-mail]> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Mahesh Jethanandani <[e-mail]> 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 <
> >>> [e-mail]> 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 <
> >>> [e-mail] <mailto:j.schoenwaelder@jacobs
> >>> -university.de><mailto:[e-mail] <mailto:
> >>> [e-mail]>>> 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: [phone]         Campus Ring 1 | 28759 Bremen |
> >>> Germany
> >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> >>> >>>> Fax:   [phone]         <https://www.jacobs-university.de/>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>>
> >>> >>>> netmod mailing list
> >>> >>>>
> >>> >>>> [e-mail] <mailto:[e-mail]><mailto:[e-mail]
> >>> <mailto:[e-mail]>>
> >>> >>>>
> >>> >>>> https://www.ietf.org/mailman/listinfo/netmod <
> >>> https://www.ietf.org/mailman/listinfo/netmod>
> >>> >>>>
> >>> >>>
> >>> >>>> _______________________________________________
> >>> >>>> netmod mailing list
> >>> >>>> [e-mail] <mailto:[e-mail]>
> >>> >>>> https://www.ietf.org/mailman/listinfo/netmod <
> >>> https://www.ietf.org/mailman/listinfo/netmod>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> >>> Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> >>> Germany
> >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> >>> >>> Fax:   [phone]         <https://www.jacobs-university.de/ <
> >>> https://www.jacobs-university.de/>>
> >>> >>>
> >>> >>> _______________________________________________
> >>> >>> netmod mailing list
> >>> >>> [e-mail] <mailto:[e-mail]>
> >>> >>> https://www.ietf.org/mailman/listinfo/netmod <
> >>> https://www.ietf.org/mailman/listinfo/netmod>
> >>> >> Mahesh Jethanandani
> >>> >> [e-mail]
> >>> >>
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Netconf mailing [e-mail]://www.ietf.org/mailman/listinfo/netconf
> >>
> >>
> >>
> >
> >