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

[Andy Bierman <[e-mail]>]

On Wed, Feb 7, 2018 at 10:28 AM, Martin Bjorklund <[e-mail]> wrote:

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


OK



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


Yes -- because the definition in RFC 6243 is worded to exclude nodes.

It should be clear in some draft how basic-mode applies to origin=default
within <operational>.

Applying sec 2 of 6243...

config=true:

If basic-mode=report-all then origin=default will never be present

If basic-mode=trim then origin=default is only possible if the value-in-use
is the YANG default

If basic-mode=explicit then origin=default is only possible if the
configured value was not
explicitly set by a client.  Sec 2.3.1 is not clear if the YANG default
value is relevant or not.
It could be that if the configured value not explicitly set, then any
value-in-use (not just the
YANG default) could be tagged origin=default.


config=false:

report-all: default ignored, no nodes treated as default
trim: node removed if value=YANG default
explicit: all config=false nodes are set by the server, so no nodes treated
as default


This draft makes with-defaults mandatory-to-implement.
It is a SHOULD implement now.  (I approve!).

The with-defaults capability MUST be advertised by the NMDA server,
including
the basic-mode parameter. The also-supported parameter MAY be included.

Is it possible for report-all-tagged to apply to nodes that are learned
(i.e., not origin=default)?



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

Andy



>
> >
> >
> > 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]://ww
> w.ietf.org/mailman/listinfo/netconf
> > >>
> > >>
> > >>
> > >
> > >
>