Re: [netmod] Datastore leaf for yang instance data

[Robert Wilton <[e-mail]>]

On 28/11/2018 15:32, Juergen Schoenwaelder wrote:
> On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
>> 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.
>>
> I do not understand why a datastore leaf is not sufficient and why we
> need yet something new. If ever needed, NMDA does allow us to define
> new datastores.

Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.

The second reason is that I don't know whether things like capabilities 
and diagnostics will be new datastores or just part of operational.  I 
don't think that either of these two areas have really been properly 
worked out yet.  I presume that they will come over time, once more 
network management becomes more automated.

Thanks,
Rob


>
> /js
>