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

[Andy Bierman <[e-mail]>]

On Wed, Feb 7, 2018 at 1:58 PM, Mahesh Jethanandani <[e-mail]
> wrote:

> It appears that there is some consensus around the issue of
> “with-defaults” for operational datastore. Andy, would you agree with what
> has been suggested?
>
>
Yes.



> It also appears that text needs to be added to explain the behavior w.r.t.
> operational datastore. If everyone agrees, authors, can you propose the
> text that needs to be updated.
>
> Thanks.
>
>
Andy


> On 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.
>
> 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 |
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
>
> Germany
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> <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 |
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
>
> 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
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> [e-mail]
>
>