On Fri, May 8, 2020 at 8:51 AM Andy Bierman <[email protected]> wrote:
> > > 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 } > > oops: correction: (bit 0 in byte 500000) { 500000, 1, 0x1 } > > >> Grüße, Carsten >> >> > > Andy > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
