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

[Andy Bierman <[e-mail]>]

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 }



> Grüße, Carsten
>
>

Andy