> On 11 Nov 2015, at 13:26, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Nov 11, 2015 at 11:54:58AM +0100, Ladislav Lhotka wrote: >> >>> On 11 Nov 2015, at 09:07, Juergen Schoenwaelder >>> <[email protected]> wrote: >>> >>> 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. >> >> There is nothing in 6020bis indicating that "anyxml" is being deprecated. >> > > I wrote 'effectively deprecated' and here is the text in 6020bis. > > Since the use of anyxml limits the manipulation of the content, it is > RECOMMENDED that the "anyxml" statement not be used to define > configuration data. > > It should be noted that in YANG version 1, anyxml was the only > statement that could model an unknown hierarchy of data. In many > cases this unknown hierarchy of data is actually modelled in YANG, > but the exact YANG model is not known at design time. In these > situations, it is RECOMMENDED to use anydata (Section 7.10) instead > of anyxml.
The first paragraph is for config data and the second for data that can modelled with YANG. If we want to deprecate "anyxml" for use with data that are neither of these, 6020bis should say so. I'd be fine with that. > > There is more text in Y34-05 that will go into the guidelines. I call > this "effectively deprecated", you can call it differently if you > want. Frankly, this thread is about how to encode anyxml in JSON not > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what > we ended up with. I am strongly against encoding serialized XML as JSON strings. It is IMO totally useless and the spec would have to deal with awkward complications because it is not true that arbitrary XML-encoded anyxml content can be used without changes in JSON encoding. Perhaps the best solution would be to state that JSON encoding is incompatible with data models that use "anyxml". 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: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
