Robert Varga <[email protected]> writes: > On 11/05/2015 09:56 AM, Ladislav Lhotka wrote: >>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode >>> >anyxml as a string that has XML inside makes sense. >> The possibility of sending arbitrary (non-YANG) data in the native encoding >> can occassionally be useful, and even more so in JSON. For example, I have >> to work with a JSON-based format for specifying DNSSEC signing policies. >> While my plan is to eventually replace this format with YANG-modelled data, >> it would help me, as an interim solution, to simply send the data in the >> legacy format. That's why I want to retain the existing rules for JSON >> encoding of anyxml, unless something else is available. Sending XML >> documents as strings is still possible although IMO next to useless. > > I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies > non-transparent in case the sender (a NETCONF NE) and receiver (an > RESTCONF application) have out-of-band knowledge of the data being sent > over anyxml. Given the proxy does not have this knowledge, it cannot > reliably deal with lists, as they lack a container element in XML > encoding.
My view of anyxml is that it is a "controlled loophole" that allows arbitrary non-YANG stuff to be sent. The only requirement is that it won't break the syntax of the document in which it is embedded - and this of course depends on the encoding used. It should be used scarcely, and yes, it generally isn't interoperable and encoding-transparent. Whenever it is needed, the implementations should deal with these issues on an ad hoc basis. So far it has mostly been used in specifications (NETCONF, yang-patch, zerotouch), i.e. outside the network management context, where YANG serves as an encoding-independent schema language. I think it *may* occassionally be useful but it is also true that it can always be substituted with a string or binary leaf. The only advantage of sending such data in the "native" encoding is that it can be parsed in one go. > > Can we perhaps indicate the encoding of the anyxml data chunk in JSON as > a separate well-known attribute? I don't think this could be useful because I believe such schema-less chunks really make sense only if their encoding is the same as that of the outer document. Lada > > Bye, > Robert -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
