> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> 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. > configuration datastore validation and specification of semantics goes > well beyond what you usually find in web interactions, where typically > all semantics are left to the implementor of a service. We validate > configurations (residing in datastores), not the syntactic aspects of > protocol messages. But yes, I am looking forward to a concrete I-D. Where did I write anything about syntactic aspects of protocol messages? Of course we need to validate datastores. In the case of YANG, my point is that its spec could just define what a valid datastore (data tree) is. What it needn't state is that running, intended or whatever MUST be valid - it can be said elsewhere. Lada > > /js > > -- > 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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
