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".
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."
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.)
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.)
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
