On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balázs Lengyel wrote:
I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet again
means something different than the same config true leaf in operational.
/js
BALAZS: As I understood the WG decided that this draft should only be about
the format of the yang instance data. What the SW does with it is out of
scope. So considerations whether instance data should be loaded into running
or candidate or not at all, are outside the scope.
If you do not know what the instance data means, any attempt to use it
is kind of broken.
I want to provide a datastore indicator, but how that should be used (and
thus what is exactly means) is out of scope.
I disagree. The datastore indicator is needed to understand what the
data means, i.e., to do anything meaningful with it.
I think that a datastore indicator is useful sometimes. E.g. it might
be helpful in some cases to know that the data was associated with a
particular datastore.
But in the general case I think that this is just "data at rest", and
probably the key thing to know is whether (i) the data relates to
configuration, or (ii) the data relates to operational state.
This could potentially be inferred from a datastore leaf, or perhaps
this distinction could more explicitly be made by a separate field,
which I would make an enumeration or identity, since there might be
other types of data in future, such as capability information or
diagnostics.
Thanks,
Rob
Anyway in some cases it would be problematic to define a single datastore
parameter. E.g. the draft allows the real world use case of putting config
and state data in the same file. In this case state data is associated with
operational while config data is with running/candidate. In the non-NMDA
case I do not even know what the correct daatastore is for state data.
We created NMDA because mixing <running> with <operational> is broken
in a number of cases. I am fine to accept that the datastore indicator
may be absent paired with a clear warning that in this case it is
undefined what the data means. (And I will hope that robust
implementations will avoid working with data that has unclear
semantics or at least generate warnings.)
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
