Subject: Re: [netmod] JSON encoding of anyxml

From: Randy Presuhn <[email-masked]>
Date: Wed, 11 Nov 2015 12:09:02 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Nov 11, 2015 5:44 AM
>To: Ladislav Lhotka <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] JSON encoding of anyxml
...
>Observations:
>
> - Except b), none of the options is interoperable. Option d) is
>   interoperable for the anydata subset of anyxml.
> - It seems a) is simplest to implement, b) might be expensive to
>   implement and use.
> - Some implementations use internal data stores that can only deal
>   with data that can be modelled with YANG and for those implementations
>   anyxml is effectively the same as anydata and d) migth be close to
>   a) in terms of implementation costs.
>
>Any other observations missing?

The problem is similar to the ones that show up with ASN.1 "ANY"
(but *not* "ANY DEFINED BY") in environments supporting multiple
encoding rules / transfer syntaxes.

For a recipient to *fully* decode something in such an environment,
either the encoding has unambiguously identify the grammar of the
bits in question, or the recipient has to have complete a priori
knowledge of everything that could possibly be encountered in that
context, along with any disambiguation logic.

The "ANY DEFINED BY" construct meets that requirement, as long as
each set of encoding rules properly supports the abstract syntax.
ASN.1 "ANY" doesn't meet that requirement as soon as things like,
for example, IMPLICIT tagging come into play.

Netmod and netconf have painted themselves into a corner here:
  (1) the grammar can't be deduced from an encoding
  (2) the information identifying the grammar of the payload
      is not present on the wire, nor is it available in
      machine-readable form in the data model.  At best it'll
      be handled on an ad hoc basis if a developer gets around
      to it for a given leaf.

This means that, as a practical matter, it's not going to be
practical or interoperable to treat the payloads of these types
as anything other than (octet) strings for transport.  Attempts
to convert a value based on the (wrapping) transfer syntax will
only work for senders that know the payload's grammar.  Generic
recipients and particularly relays would be Simply Out of Luck.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Nov 2015 07:51:37 +0100

>       be handled on an ad hoc basis if a developer gets around

Right, that's exactly how I see it. Even if anyxml is deprecated in
standard modules, I believe it may be useful if an implementation has
the possibility to send some non-YANG data, for one reason or
another. The vendor can then write a one-off module for this purpose
and that's all.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C