On 06/02/2016 00:41, Andy Bierman wrote:
On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder
<[email protected]
<mailto:[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.
Obviously the client knows that it is making a request using this
encoding, and looking at the information contained in an RPC reply I
can't see how a client can usefully process an RPC reply unless they
also have the request context.
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?
IMO, this solution is a non-starter.
OK, and yet my understanding is that the folks requesting a solution to
the opstate problem are saying that the applied datastore approach is
also a non-starter, or at least very undesirable. (Note - I don't
actually know whether they regard the solution in
draft-wilton-netmod-opstate-yang to be any more palatable.)
From a clients operational perspective I can see how the OpenConfig
model, with separate intended config and applied config leaves that are
co-located in the schema tree makes life easy for the client in a way
that having a separate applied configuration datastore doesn't seem to.
Rob
/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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
