On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote: > > Hi Juergen, > > > > I don't really follow your point. > > > > The solution is fully backward compatible - in that only clients that > > make use of the protocol extension would see the new encoding. Existing > > clients would continue to see the encoding as directly defined in the > > YANG schema, and a server would be able to support old and new clients > > concurrently. > > > > The YANG RFC details how data is encoded in XML. People have written > and deployed code against based on this RFC. I do not accept an > approach where an RPC option can simply request that the encoding > defined in the YANG RFC is ignored and replaced with a very different > encoding. > > +1 I brought this up awhile back. Not only is the YANG schema replaced by some "formula", there is no indication in the <rpc-reply> at all that this is being done. Only the sender of the <rpc> knows that the special encoding rules are used instead of the YANG rules. IMO, this solution is a non-starter. > /js (stating a clear opinion as a technical contributor) > > -- > 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/> > > Andy > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
