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

JFYI: Interesting discussion in core/netmod about potentially needing to represent sparse bit sets.
Anything we (cbor WG) can contribute to that?

Grüße, Carsten

> Begin forwarded message:
> 
> From: "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org>
> Subject: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]
> Date: 2020-05-06 at 12:43:49 CEST
> To: "core@ietf.org" <core@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-core-yang-cbor@ietf.org" <draft-ietf-core-yang-cbor@ietf.org>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zaAtN5l8NuXUT1u3oj3qy9UG_m8>
> 
> 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]
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod