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

[Andy Bierman <[e-mail]>]

On Fri, May 8, 2020 at 8:51 AM Andy Bierman <[e-mail]> wrote:

>
>
> On Thu, May 7, 2020 at 11:22 PM Carsten Bormann <[e-mail]> wrote:
>
>> On 2020-05-08, at 05:27, Andy Bierman <[e-mail]> wrote:
>> >
>> > Why is the bit position allowed to be a uint32 in YANG? Who knows, but
>> it has to be supported.
>>
>> If we think that is the way to go, I like Kio’s proposal over in the CBOR
>> list:
>> <https://mailarchive.ietf.org/arch/msg/cbor/3sZ4YfWLzmVVnNnQbttkovgjTP8>
>>
>>
>
> Yes -- this encoding should work well
>
>
>> We probably should arm that with some text that says (in nicer words)
>> that this is an emergency representation and implementations should not
>> invoke it for sane YANG models (with an operable definition of sane).
>>
>>
>
> Not sure what this means.
> Wouldn't this map approach be used all the time for a bits type?
> The "normal" case would be a small number of octets representing all the
> bits present
>  (e..g 0x7 for 3 bits : bit 0 to bit 2)
> This would simply be 1 map entry with {offset=0,length=1,value=0x7}
>
> The actual bitmap is conceptually constructed by starting with an array of
> zero bytes.
> Overlapping offsets are allowed. Duplicate offsets are allowed.
> There is no requirement to list offsets in ascending order.
> There is no canonical representation.
>
> Each map entry is added to the array using a "bit or" operator.
> After all map entries are processed the full bits value is known.
> This allows an implementation to encode bits serially (often done this way
> with YANG bit names)
>
> So the same bitset 0x7 could be sent different ways including:
>
>   { 0, 1, 0x1 }
>   { 0, 1, 0x2 }
>   { 0, 1, 0x4 }
>
> If the position is really bit 4 million (bit 1 in byte 500,000)
>
>   { 0, 500000, 0x1 }
>
>
oops: correction:  (bit 0 in byte 500000)

  { 500000, 1, 0x1 }


>
>
>> Grüße, Carsten
>>
>>
>
> Andy
>
>