[netmod] Datastore leaf for yang instance data

[Balázs Lengyel <[e-mail]>]

BALAZS: "Instance data associated with a datastore" may mean many things, that's why this relatively loose term is used. It may mean:

• Data was read from that datastore
• Data is intended to be fed into that datastore
• Something else ???

This can be useful if data is read from a datastore, but in a number of cases it is not useful:

• Preloading configuration data: datastore may be running or candidate.
  
• Preloading mixed config and state data: We do have state data that is very stable and thus it is documented as instance data, and the instance data file is actually used to feed the state data into the SW. So datastore is: running, candidate + operational if NMDA is supported or state datastore (whatever that is) if NMDA is not supported

regards Balazs

On 2018. 11. 06. 11:03, Ladislav Lhotka wrote:

On Tue, 2018-11-06 at 10:41 +0100, Martin Bjorklund wrote:

Ladislav Lhotka <[e-mail]> wrote:

On Tue, 2018-11-06 at 07:36 +0100, Juergen Schoenwaelder wrote:

I agree that

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore for which
            the instance data is documented for config=true data nodes.
            The leaf MAY be absent in which case the running dtastore or
            if thats not writable, the candidate datastore is implied.

            For config=false data nodes always the operational
            data store is implied.";
    }

is pretty confusing. It should be something like this:

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore holding
            the instance data. If the instance data is not associated

Or rather the datastore that the instance data was extracted from.

I prefer "associated with".  There are other uses cases than just
holding data "extracted from", e.g., data that is supposed to "be
inserted into" a datastore.  "associated with" is less resrictive.

It unclear what "associated with" means in this context.

Lada

After that,
the data exists on its own and the originating datastore may later be

holding

something else.

        with a datastore, then this leaf MUST be absent.";

RFC 2119 language would make sense if there is anything that could break if

that

MUST isn't observed. But we even didn't know what the data is going to be

used

for.

I would treat the "datastore" item as a purely optional information

I agree.


/martin

that, if
present, was provided for some reason. If it is false, what can we do?

    }

I am against merging data from different datastores together, which
the last sentence of the original text seems to imply.

Both config true and config false data may come from <operational>, so it
doesn't necessarily mean any mixing of datastores. But then again, I think

that

the datastore information isn't in most cases that interesting.

Lada

/js

On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:

Joe Clarke <[e-mail]> writes:

===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can

assume

the source datastore for config=true nodes.

The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data

will

eventually be fed into the indicated datastore, but I don't see any
reason for such an assumption.

I can see that "datastore" can be occasionally useful as auxiliary
metadata but, in my view, this document addresses also instance data
that is not necessarily bound to any datastore.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]