On 11/6/18 01:36, 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
> with a datastore, then this leaf MUST be absent.";
> }
>
> I am against merging data from different datastores together, which
> the last sentence of the original text seems to imply.
This is better.
In the case where the data does come from a datastore would this leaf
need to be there? Meaning, is there an assumption that when it's not
present then the data did NOT come from a DS?
And it seems like you could provide instance data from <operational> to
merge ct and cf nodes even without merging DSes.
Joe
>
> /js
>
> On Tue, Nov 06, 2018 at 11:51:26AM +0700, 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.
>>
>> Lada
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
