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

If we go for this, as I’m proposing in <https://mailarchive.ietf.org/arch/msg/netmod/hRMjLIIpOyTNtmkv4yd3gyjd_gA>:

I think we should require that

— the offsets are (unsigned and) divisible by 8;
— the byte strings do not overlap.

I’m also not sure we wouldn’t want to require the offset/bitstring pairs to be in order, which would need an array instead of a map (as maps are not ordered).

Grüße, Carsten

> On 2020-05-06, at 18:17, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
> 
> That's an interesting problem. I would use a tagged map where the key is an integer offset in bytes from the beginning of the sparse array, and the value would be the byte(s) from that position.
> 
> i.e.
> 
> 2020({0: h'0107', 4000000000: h'15'})
> 
> D9 07E4           # tag(2020)
>    A2             # map(2)
>       00          # unsigned(0)
>       42          # bytes(2)
>          0107     # "\x01\a"
>       1A EE6B2800 # unsigned(4000000000)
>       41          # bytes(1)
>          15       # "\x15"
> 
> 
> 
> My thinking in this is that bit flags would tend to cluster together in practice.
> 
> It does have one problem in that it is possible to create overlapping byte sequences.
> 
> The decoder would not need to allocate much space.
> 
> Cheers,
> 
> Kio
> 
> 
> 
> On 2020-05-06 16:38, Carsten Bormann wrote:
> 
>> 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
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor