Re: [core] Comments on draft-ietf-core-yang-cbor-00

[Carsten Bormann <[e-mail]>]

Ladislav Lhotka wrote:
> The receiving side will resolve the union type by the first union member
> type that matches the CBOR-encoded value. It's the same as in JSON encoding.

Or, at least, similar -- we are not always making the same serialization
decisions.

The weird aspect of this part of YANG is that the actual validity (and
specific semantics and thus usefulness) of a union in the YANG module
depends on the specifics of the serialization below.
More frankly: Tying the semantics of a modeling language to one specific
serialization mechanism is an utterly broken design.
I'm not sure that it can be fixed, though, so we'll likely have to work
around this breakage.

What we were trying to figure out was the extent of the situations where
a YANG module specifier might rely on the XML-specific way of resolving
unions.

Examples that seem painful:

1)

 type union {
      type enumeration {
         enum one; /* value 0 */
         enum two; /* value 1 */
      }
      type uint32;
 }

Here, the XML will have the string "one" or "two", or a decimal string,
which is unambiguous.  The JSON encoding also has the string for
enumerations, which we obviously want to replace by the numeric value in
a compact encoding.

We were thinking about possibly adding CBOR tags to disambiguate this.
This becomes more insidious if this is an evolution from an earlier
version that just said:

 type enumeration {
   ...
 }

(We wouldn't want to sprinkle in tags just in case a type might possibly
evolve into a union later.)

2)

Also, just having a tag saying "this is an enumeration value" does not
work for this case:

 type union {
      type enumeration {
         enum one; /* value 0 */
         enum two; /* value 1 */
      }
      type enumeration {
         enum alpha; /* value 0 */
         enum beta; /* value 1 */
      }
 }

We haven't found a way yet to tag this case that is robust against
further evolution of the YANG module.

Clearly, YANG module specifiers will not rely on this when they are
cognizant of concise encodings.  However, relying on specification
writers not doing this would mean that YANG modules have to be vetted
for mistakes of this kind before they can be used in a CBOR environment
after an exclusively XML/JSON life.  (Maybe that actually *is* the
answer -- if we could get pyang to detect this case and issue a warning,
that might be enough.)

Grüße, Carsten