On Tue, Jul 25, 2017 at 12:47 PM, Kent Watsen <kwat...@juniper.net> wrote:
> > > > > > 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. > The YANG identityref allows any identity that is derived from the same base. You keep talking about "the" operational datastore when in fact your YANG definitions require no such thing. They merely require any identify with the proper base (i.e, edit-config, get-data operations) > > > > > > 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? > > > You are right that interoperability is the same either way (very weak IMO). The client can read the list of datastores. If 3rd-party clients are viable (not likely) then they will be able to print an error message "Operational datastore not supported" either way.. > > > Andy > > > > Kent // contributor > > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
