David,
I am still not sure what the problem is. We proposed that the
<operational> datastore always reports the values that are in use,
whatever their origin is. This seems simple and clear if you want to
troubleshoot something.
On Mon, Jul 17, 2017 at 07:28:01PM +0200, David Lamparter wrote:
> Hi all,
>
>
> so, I need to partially walk back my comments made on mic earlier today.
> The context where this came from is section 7.6.1 ("The leaf's default
> value") of both RFCs 7950 and 6020. It says:
>
> When the default value is in use, the server MUST operationally
> behave as if the leaf was present in the data tree with the default
> value as its value.
>
> The point where my earlier arguments fall flat is where it says "the
> server". My memory is that both some servers as well as libraries
> effectively "hard-implement" this paragraph; i.e. when you retrieve a
> value from a loaded configuration, there is no way to distinguish
> between "X passed in" and "the library filled in X from the model's
> default". The library doesn't give you the opportunity to break above
> paragraph.
>
> So, since the discussion was in regard to values read back out from the
> server, the YANG language specs themselves theoretically allow this.
>
> ... if you accept that this only applies to configuration written on the
> server. You could as well read that paragraph to also apply to reading
> out configuration.
>
> And it gets worse. RFC 6243 (with-defaults) starts off with this:
> 1. Data retrieval: A server is normally allowed to exclude data
> nodes that it considers to contain the default value. The actual
> nodes omitted depend on the default-handling behavior used by the
> server.
>
> If this is implemented in an older NETCONF server that does this
> unconditionally, this effectively breaks operational state retrieval
> even if the system software does provide correct data with or without
> defaults. The NETCONF server would just (validly) remove all values
> that are the same as the model's default -- which then the client would
> interpret as "these values are not in use".
RFC 6243 was written before <operational> did exist and we propose
that <operational> always reports the values in use (regardless
whether they match defaults or not).
> In the same way, "report-all" and "trim" modes for with-defaults would
> fundamentally break this model where absence of the value indicates
> not-in-use. "explicit" should work; "report-all-tagged" may work
> depending on the implementation.
>
> ...
>
> This, for me, lends the conclusion that this would be massively fragile,
> even if a specific combination could make it work. My position hence
> changes from "this doesn't work" to "please don't do this, even if it
> may work."
Always reporting the value in use should be fine. If libraries mess up
the data it seems a library issue. Libraries should not mess around
with <operational> data. The data in <operational> data is the ground
truth of what the device is really doing, messing around with it
before passing it to an application is not recommended.
> The solution I would suggest would be to have "is the value in use?" as
> metadata just like the origin. It can either be a new value on the
> "datastore" identity (=> if a value is not in use, there is no way to
> report what datastore it came from), or alternatively it can be a
> separate metadata annotation (=> you can report not-in-use and still
> have the value and its origin - if that makes sense, which...)
>
> (I'm leaning towards adding "not-in-use" on the origin metadata
> annotation, as opposed to a separate boolean metadata annotation.)
But if something is not in use, it may not even have a value. So I end
up reporting fake values for things that are not is use decorated with
metadata that these fake values are not in use? Does not sound very
efficient to me.
> Whether the value would have any meaning if "in-use=false" or
> "datastore=not-in-use" are signalled is an open question with this
> approach. I would argue if the value isn't in use down in the system,
> the value sent to the client (if any) is meaningless (and the system
> usually wouldn't be able to provide it to begin with.) I haven't
> explored the details of this though.
>
>
> Hope this is useful input,
>
> -David
>
>
> P.S.: The original case where I stumbled over this is OpenConfig's BGP
> model having some leaves with default values, and then saying "if the
> value is not present, use the parent's value". This is a hard violation
> of the YANG spec; if a default value is in the model, the server isn't
> permitted to deviate and hunt for the parent's value in lieu of using
> the model default. (This was a year ago, I think/hope the model
> changed.)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
