On Thu, Aug 3, 2017 at 11:29 PM, Juergen Schoenwaelder <
[email protected]> wrote:
> On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote:
> >
> > So you are saying there is no such thing as an NMDA-compliant server.
> > There are protocols that may use specific datastores in various ways.
> > Different protocols can have different behavior for the same datastore.
> > Sounds very fun for client developers to figure out.
> >
>
> This is what I wrote:
>
> The protocols (with their various capabilities) expose different sets
> of datastores. I agree, the protocol documents should state clearly
> what is required to expose for the different protocols and what is
> optional to expose.
>
> I did not write that different protocols can have different behavior
> for the same datastore. I did not write that protocols may use
> specific datastores in various ways.
>
>
So the protocol designers will some how agree on the properties of a
standard datastore?
Actually it seems much worse than that. It seems each server implementation
decides what it wants to support and just lists that.
The 7895bis draft proposes that each server will list the properties it
supports for each datastore
container properties {
leaf-list property {
type identityref {
base ds:property;
}
description
"A property of the datastore.";
}
description
"A list of properties supported by this datastore.";
}
Of course, these properties are just a list of identityrefs that match the
base 'ds:property'.
There is no official list of properties that a datastore is expected to
support.
There is this list in ietf-datastores that seems to be intended to replace
the existing capability URIs for various NETCONF capabilities:
There does not seem to be any guidance or normative text.
NMS developers should take notice of these changes because the
impact on code design could be significant.
identity property {
description
"Abstract base identity for datastore identities.";
}
identity writable {
base property;
description
"Used on the 'running' datastore to indicate that it can be
written to."
}
identity auto-persist {
base property;
description
"Used on the 'running' datastore to indicate that writes to
it will be automatically persisted.
If the 'startup' datastore is also supported, clients may
query its contents to ensure its synchronization.
If the 'startup' datastore is not supported, and this
property is not set, then clients must use a mechanism
provided by the protocol to explicitly persist the
'running' datastore's contents.";
}
identity rollback-on-error {
base property;
description
"Used on either the 'running' or 'candidate' datastores to
indicate that clients may request atomic update behavior.";
}
identity confirmed-commit {
base property;
description
"Used on the 'candidate' datastore to indicate that
clients may request confirmed-commit update behavior.";
}
identity validate {
base property;
description
"Used on the 'candidate' datastore to indicate that
clients may request datastore validation.";
}
> /js
>
Andy
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
