On Thu, May 7, 2020 at 11:22 PM Carsten Bormann <[email protected]> wrote:
> On 2020-05-08, at 05:27, Andy Bierman <[email protected]> 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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
