Re: [netmod] Datastore leaf for yang instance data

[Juergen Schoenwaelder <[e-mail]>]

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.

> 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>