On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
[email protected]> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.
e.g. <enabled> leaf: If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)
I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.
<foo-config> vs <foo-oper>. If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.
The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.
correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules. The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.
But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the
data tree.
If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy". I think that there
would be key information that clients would expect to be available in a
model but wouldn't be easily retrievable without supporting the
operational state datastore. Specifically you lose the ability to
easily query an operational property of a system that can be configured,
but hasn't been configured.
Example: Consider an Ethernet interface speed leaf that in the running
ds represents the configured speed, and in the operational state ds
represents the actual operational speed in use. Normally, the
operational speed would default to the maximum speed supported by the
hardware (or the negotiated value if auto-neg is in effect). If a device
doesn't support the operational state datastore then you wouldn't be
able to query the operational speed of an interface if it hasn't also
been configured.
If the device support the with-defaults extension and appropriate
options then they could presumably retrieve the "complex default" value
from the device using one of the with-default query parameters.
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
