Subject: [netconf] Guidelines for YANG anyxml/anydata statements in RFC8040 (Restconf)

From: Henning Rogge <[email-masked]>
Date: Wed, 29 Apr 2020 15:16:49 +0200

Hi,

I have some trouble with the anyxml/anydata YANG statements in
Restconf... to be more precise in a Restconf-server that accepts both
XML and JSON transport encoding.

The anydata issue is that there are some "data resources" that have
the same XML transport encoding but different JSON encoding. Which
means I cannot "guess" the YANG schema of incoming XML data for an
anyxml statement.

If I read RFC 7950 and 7951 correctly, then a (as an example)
leaf-list with a single entry has the same encoding in XML as a leaf
of the same name... but not in JSON. Same is true for a list with one
element and a container.

The problem with anyxml is the same and worse... RFC 7951 section 5.6
demands transporting the data encoded in JSON (and not in a string
that contains the XML data), but does not define how to encode the XML
data into JSON and the other way around.

Are there any guidelines/best-practices for this problem?

Thanks

Henning Rogge

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Apr 2020 15:30:21 +0000

Hi Henning,

> XML and JSON transport encoding.

Is the server bound to an application that can provide supplemental schema for the anyxml/anydata schema?

> means I cannot "guess" the YANG schema of incoming XML data for an

Is the issue *only* with incoming XML data?  That is, is incoming JSON data always mappable to conforming XML data?  I think that this almost true, but my spider-sense is tingling.  Something beyond the XML-encoding’s [seemingly unnecessary] requirement that list keys are encoded first and in order...

> of the same name... but not in JSON. Same is true for a list with one

Can the server mandate some limitations/conventions/annotations that would enable transcoding?    For instance, could the server require that "xsi:schemaLocation” be set in order to grok incoming XML ‘any’ data?    Or, alternately, define a proprietary XML-attriibute where needed?

If not, likely all that can be done is to treat the XML ‘any’ data as an opaque blob.   FWIW, this is in effect what RFC 8572 does by using “binary” instead of “anydata” for its “configuration” leaf:

          leaf configuration {
            type binary;
            description
              "Any configuration known to the device.  The use of
               the 'binary' type enables content (e.g., XML) to be
               embedded into a JSON document.  The exact encoding
               of the content, as with the scripts, is vendor
               specific.";
          }

          Note: the middle sentence should’ve been written: "The use of the
                   'binary' type enables content (e.g., XML) to be embedded
                    into a document with an alternate encoding (e.g., JSON).

> data into JSON and the other way around.

Does “anyxml” have to be supported, given that it’s effectively (albeit not yet officially) deprecated?

> Are there any guidelines/best-practices for this problem?

Not yet that I’m aware of, but it might make a nice I-D if we can come up with some.

Kent // contributor

---

From: Martin Björklund <[email-masked]>
Date: Wed, 29 Apr 2020 17:40:41 +0200 (CEST)

> means I cannot "guess" the YANG schema of incoming XML data for an

In order to properly convert between JSON/XML for anydata in the
general case, you need the YANG model that describes the anydata
content.

I don't think anyxml can be converted in the general case; remember
that it can contain *any* XML, including processing instructions,
mixed content etc.

/martin

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Henning Rogge <[email-masked]>
Date: Wed, 29 Apr 2020 19:30:06 +0200

> Is the server bound to an application that can provide supplemental schema for the anyxml/anydata schema?

No, I am working on a generic Python server library... based on the
yangson (https://github.com/CZ-NIC/yangson) library for the data
model.
Currently I am patching yangson for XML support (and hope I can
upstream the code later).

> Is the issue *only* with incoming XML data?  That is, is incoming JSON data always mappable to conforming XML data?  I think that this almost true, but my spider-sense is tingling.  Something beyon…

I think there is a 1-to-1 mapping between RFC 7951 JSON encoding and
the internal state of the Netconf/Restconf data model.
This is not true for the XML encoding described in RFC 7950 (If I got
it right). There is a "collision" between 1-entry leaf-lists and
normal leaf nodes... and between a list with one entry and a
container. This means there is a definite mapping from the data state
to XML... but no definite way to guess the structure from reading the
XML data. Which leads to the "anydata" trouble when receiving XML.

> Can the server mandate some limitations/conventions/annotations that would enable transcoding?    For instance, could the server require that "xsi:schemaLocation” be set in order to grok incoming X…

I am trying to write a generic server.

> If not, likely all that can be done is to treat the XML ‘any’ data as an opaque blob.   FWIW, this is in effect what RFC 8572 does by using “binary” instead of “anydata” for its “configuration” lea…

Yes, binary would be a replacement... as would be "store anyxml in a
string for JSON transport". But RFC 7951 definitely says "encode in
I-JSON"... whatever that means (see RFC 7951, section 5.6).

> Does “anyxml” have to be supported, given that it’s effectively (albeit not yet officially) deprecated?

Good to know that its really deprecated, maybe I will just skip the
support for anyxml... (at least for the XML transport).

That sounds like I good advice. Thank you.

> general case, you need the YANG model that describes the anydata

Yes... but RFC 7950 and RFC 7951 seem to suggest otherwise... most
likely it was easy to do before the JSON based encoding was
introduced.

> that it can contain *any* XML, including processing instructions,

So the best solution might be "demand YANG schema for anydata nodes"
and "just ignore anyxml". Thank you.

Henning Rogge

---

From: Martin Björklund <[email-masked]>
Date: Wed, 29 Apr 2020 20:33:36 +0200 (CEST)

Hi,

There are some other constructs that also cannot be properly
translated w/o the YANG modules; specifically values of type
"identityref" and "instance-identifier".

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Apr 2020 18:55:00 +0000

Hi Henning,

> support for anyxml... (at least for the XML transport).

It’s not officially deprecated, but no one uses it anymore that I’m aware of.  The only *standard* modules that use it are "ietf-netconf" and "ietf-netconf-monitoring”, both a decade old, long before “anydata” was defined.

FWIW, I just added a YANG-next issue for this: https://github.com/netmod-wg/yang-next/issues/105 <https://github.com/netmod-wg/yang-next/issues/105>.

Kent // contributor

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Apr 2020 15:34:49 +0200

> that it can contain *any* XML, including processing instructions,

Right. This issue was discussed quite heavily during the preparation of RFC 7951. Randy Presuhn summarized it nicely at that time:

https://mailarchive.ietf.org/arch/msg/netmod/INVRhYLrnkfeFVtRUlp__JUD8E0/

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Henning Rogge <[email-masked]>
Date: Thu, 30 Apr 2020 16:00:49 +0200

> https://mailarchive.ietf.org/arch/msg/netmod/INVRhYLrnkfeFVtRUlp__JUD8E0/

Yes... did I mention yes? Or maybe YES?

AnyXML is broken for anything beyond XML encoding... no way to fix it.
Anydata is broken if you don't have the YANG schema.

At least I have a plan how to deal with Anydata... I will ignore Anyxml for now.

Thank you for all the comments...

Henning Rogge