On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
> Andy Bierman <[email protected]> wrote:
> > On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga <[email protected]> wrote:
> > 
> > > Hello,
> > >
> > > I am not favor of it, either, but RFC6020 is here and is being widely
> > > deployed. So is RESTCONF+JSON, which is favored by application developers
> > > in the field today, as is NETCONF devices producing anyxml. We do need a
> > > reasonable way of bridging the two -- no matter whether it is 
> > > configuration
> > > or operational data.
> > >
> > >
> > 
> > I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> > I do not agree that all the "extra XML bits" that are causing so much
> > concern
> > are ever saved in a datastore.  Martin says we need anyxml for RPC input
> > and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> > operation depends on anything except elements and attributes.
> 
> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> supposedly data modeling language agnostic.
> 
> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> if we ever do a new version of NETCONF, we use anydata instead.
>

We are effectively deprecating anyxml in YANG 1.1. We have reached
agreement on Y34-05 and I do not see any new arguments popping up.

The JSON encoding document has to specify the encoding of an
effectively deprecated construct that was designed to encode any XML.

/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

Reply via email to