> I am still concerned that the datastore conformance requirements are > under-specified and too server-centric.
Okay. > The YANG definitions defined for NETCONF and RESTCONF operations > do not actually require the "real" datastore identities to be used by a > server. > The server implementer has the freedom to replace all of the standard > datastores > with proprietary definitions. While this provides unlimited flexibility for > the > server, it also provides unlimited complexity for the client. I don't understand this. > I think the existing :candidate, :writable-running, and :startup capabilities > cover the standard conventional datastores. What about <intended>? - and let's not forget the dynamic datastores... > IMO the MUST be a new capability for the :operational datastore and the > exact identityref and semantics for this datastore MUST be supported > if the :operational:1.0 capability is advertised. > > Both NETCONF and RESTCONF can list capabilities so both protocols > can advertise this capability URI. We agree that the client needs to be able to discover which datastores are available. Already there is a proposal to update YANG Library to provide this data. It seems redundant to also have capabilities, but I can see the argument that it has to be done for completeness too. So is the proposal for 1) the netconf-nmda draft to define NETCONF capabilities for :intended and :operational, 2) the restconf-nmda draft to define RESTCONF capabilities for :running, :startup, :intended, and :operational, and 3) future dynamic datastore drafts to define a capability URI that can be used by both NETCONF and RESTCONF? > Andy Kent // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
