On Tue, Nov 06, 2018 at 01:51:36AM -0500, Joe Clarke wrote:
> 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?
I would prefer to have the datastore leaf mandatory when data is
associated with a specific datastore. If we do not mandate this, we
need a way to distinguish "I do not know what this is" from "this is
not datastore instance data".
> And it seems like you could provide instance data from <operational> to
> merge ct and cf nodes even without merging DSes.
The <operational> datastore does contain ct and cf data and the ct
data is the ct data that is operationally used (which can be different
from the ct data in <intended>. We went through quite some pain to
sort all of this out as part of the NMDA work and this document should
be consistent with NMDA.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
