On Tue, Feb 09, 2016 at 11:17:13AM +0000, Robert Wilton wrote: > > > On 08/02/2016 16:20, Juergen Schoenwaelder wrote: > >On Mon, Feb 08, 2016 at 01:21:52PM +0000, Robert Wilton wrote: > >>So, IIRC, your concern is specifically that a generic YANG client > >>library cannot validate that the RPC reply is well formed against the > >>schema without knowledge about the request. Is that correct? > >> > >None of the existing tools that assume YANG defined data is XML > >encoded according to RFC 6020 will not be able to process data in a > >new encoding. > OK. > > As Lou indicates, the proposed protocol schema encoding could also be > generated by tooling (i.e. a pyang plugin). > > I.e. a client can take the source YANG models (e.g. as defined by IETF) > and apply a transformation to them that would generate a set of YANG > models that are the same except that they have the extra applied > configuration nodes added to them. > > An opstate aware client could use the generated YANG models to both > internally manage the manageability data, and also to validate that the > messages sent to/from the server conform with the extended schema. >
I fail to see how on the fly schema translations makes things simpler (and I am sure there are a number of little questions that pop up if you really do this). I am still waiting for the argument that convinces me that merging datastores into a single tree makes the writing of clients orders of magnitude simpler. If the only real technical argument is "I need to be able to retrieve data from multiple datastores in a single RPC operation", then lets simply define such an RPC (that works for arbitrary combinations of datastores and not just two specific ones) and move on. If the problem is in the existing RPC primitives, then lets extend them instead of building hacks around them using on the fly schema translations and what not. /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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
