[netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

[Cross posting to Netmod for wider YANG expertise.]

I had a couple of questions on the CBOR YANG encoding of bits and unions (based on draft-ietf-core-yang-cbor-12).  Apologies if these have already been discussed/closed in the WGLC.

1) Regarding the encoding of the bits datatype:
[draft-ietf-core-yang-cbor-12, section 6.7]

The CBOR YANG encoding of the bits datatype is defined as a byte string encoding of a bitfield.  However, my concern here is that YANG bit positions are allowed to be up 2^32-1.

E.g. the following, pathologically bad, bits definition would seem to have a very inefficient encoding in CBOR:

   typedef alarm-state {
     type bits {
       bit unknown {
         position 4000000000;
       }
       bit under-repair;
       bit critical;
       bit major;
       bit minor;
       bit warning;
       bit indeterminate;
     }
   }


How much should we be concerned about this pathological case?  Would it be reasonable for implementations to reject bitfields larger than a small set size (e.g. perhaps 256 bits)?

Or, if it is supported by the language then is it reasonable that implementation SHOULD support it?  In which case I think that we might need a second encoding of bits that supports this pathological case.  Perhaps an array of 'set' bit positions, or alternatively the union string encoding of bits could be used.


2) Regarding the encoding of unions:

I was questioning whether the special encoding of bits type within a union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7].  Am I right to presume that this is to ensure that the CBOR encoding of unions is always at least as specific as XML?  If so, this seems like a reasonable design choice.  But that leads on to these general YANG questions:

Should the value encoding of a YANG union type behave the same way regardless of whether the encoding is XML/JSON/CBOR?  Or is it reasonable for there to be differences in the case of conflicting values?  Perhaps this is already answered by RFC 7951 that can behave differently from the XML encoding of unions.

Longer term, should YANG be looking for a discriminated-union type?  Or perhaps it would be sufficient for tooling to flag up potentially ambiguous union definitions, particularly those that may be encoding dependent.


Regards,
Rob

[As an individual contributor]