On 11/5/18 23:51, Ladislav Lhotka wrote: > Joe Clarke <[email protected]> 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.
I agree. In some cases, I won't have a datastore, and that shouldn't mean the consumer assumes running (or candidate). Joe _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
