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

[Andy Bierman <[e-mail]>]

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>.



> 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
>> >>>> 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
>> >>> 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
>
>
>