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

[Andy Bierman <[e-mail]>]

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.


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
>