Re: [netmod] Datastore leaf for yang instance data

[Balázs Lengyel]

On 2018. 11. 28. 16:43, Robert Wilton wrote:

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


/js

different than the same config true leaf in running and this yet again means something different than the same config true leaf in operational.

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.


future, such as capability information or diagnostics.

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

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.

Thanks,
Rob

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.

regards balazs

--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: balazs.leng...@ericsson.com

BALAZS: You are right, that these areas are not worked out. That is exactly why they are out of scope. This is only about the format, and not about the usage. As we already have about 10 use cases with different needs, none of which are specified exactly, I want to avoid defining specific metadata for use cases we don't fully understand. Note: it is possible and documented that the metadata can be extended/augmented.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod