Ladislav Lhotka <[email protected]> wrote: > > > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >> > >> I think we need protocol and YANG specs that are not tied to any > >> particular model and that are thus capable of matching unforeseen > >> real-world implementations. This is no sci-fi, HTTP and XML schema > >> languages work this way. > >> > > > > I disagree that HTTP and XML schema languages do the same thing. Our > > goal is interoperable configuration of network devices; the notion of > > Even now, a client that's programmed to write straight to running > isn't interoperable with a server that has candidate and read-only > running. A RESTCONF server that supports only JSON isn't interoperable > with a client that supports only XML. > > We are not in a situation that every pair of a randomly chosen server > and client need to be interoperable. It's IMO perfectly fine if IoT > and ISP networks use different clients. Yet, both can still use the > same RESTCONF, same YANG, and even same YANG modules.
The fact is that that data models are written with a certain set of protocol features and datastores in mind (the "meta-model"). Some examples: If we had an "operational-state" datastore like the one proposed, we would not see the /foo vs /foo-state split. If SNMP would have had a CREATE operation, MIBs would not have used RowStatus. If NETCONF didn't have a way to create instances, we would have seen something similar in YANG models. If NETCONF had a way to add comments to any node in a datastore, we wouldn't have "leaf description" sprinkled throughout the models. If NETCONF didn't have a generic way to filter retreived data, we'd see lots of specific get-* rpcs in YANG models. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
