Dear all,
Thank you for spotting this issue and discussing a possible solution. I
finally managed to dedicate enough time to try to properly understand it.
If my understanding is correct, the problem we are discussing is that in
some rare cases the proposed encoding of 'bits' might be really
inefficient. I have attempted to capture the discussed solution with this
change [1]. The proposed change is replacing the following text:
Leafs of type bits MUST be encoded using a CBOR byte string data item (major
type 2). Bits position are either explicitly assigned using the YANG
statement
'position' or automatically assigned based on the algorithm defined in
{{RFC7950}} section 9.7.4.2.
Bits position 0 to 7 are assigned to the first byte within the byte
string, bits 8 to 15 to the second byte, and subsequent bytes are assigned
similarly. Within each byte, bits are assigned from least to most
significant.
The following example shows the encoding of an 'alarm-state' leaf instance
with the 'under-repair' and 'critical' flags set.
Definition example from {{RFC8348}}:
~~~~ yang
typedef alarm-state {
type bits {
bit unknown;
bit under-repair;
bit critical;
bit major;
bit minor;
bit warning;
bit indeterminate;
}
}
leaf alarm-state {
type alarm-state;
}
~~~~
CBOR diagnostic notation: h'06'
CBOR encoding: 41 06
with
Keeping in mind that bit positions are either explicitly assigned using the
YANG statement 'position' or automatically assigned based on the algorithm
defined in {{RFC7950}} section 9.7.4.2, each element of type bits could be
seen
as a set of bit offsets that have a value of ether 1, which represents the
bit
being set or 0, which represents that the bit is not set.
Leafs of type bits MUST be encoded using a CBOR array where each element is
either an unsigned integer that can be used to calculate the offset, or a
byte
string (major type 2) that carries the information whether certain bits are
set
or not. The initial offset value is 0 and each unsigned integer modifies the
offset value of the next byte string by the integer value multiplied by 8.
For
example, if the bit offset is 0 and there is an integer with value 5, the
first
byte of the byte string that follows will represent bit positions 40 to 47
both
ends included. If the byte string has a second byte, it will carry
information
about bits 48 to 55 and so on. Within each byte, bits are assigned from
least
to most significant. After the byte string the offset is modified by the
number
of bytes in the byte string multiplied by 8. An example follows.
The following example shows the encoding of an 'alarm-state' leaf instance
with
the 'critical', 'warning' and 'indeterminate' flags set.
~~~~ yang
typedef alarm-state {
type bits {
bit unknown;
bit under-repair;
bit critical;
bit major;
bit minor;
bit warning {
position 8;
}
bit indeterminate {
position 128;
}
}
}
leaf alarm-state {
type alarm-state;
}
~~~~
CBOR diagnostic notation: [h'0401', 14, h'01']
CBOR encoding: 83 42 0401 0E 41 01
Having two consecutive unsigned integers, byte strings or having elements
that
are neither unsigned integer nor byte string inside the array SHOULD be
considered an error.
Please let me know if I have managed to capture the essence of the problem
and the proposed solution or if you believe this could be written in a more
clear way.
Thanks,
Ivaylo
[1]:
https://github.com/core-wg/yang-cbor/commit/6bcea062224537c2e792756818898f764b03d5b7
On Fri, May 8, 2020 at 8:13 PM Juergen Schoenwaelder <
[email protected]> wrote:
> On Fri, May 08, 2020 at 10:48:06AM -0700, Jim Schaad wrote:
>
> > Does yang consider that there is a difference between a bit being
> > present and zero and a bit being absent?
>
> In YANG every bit in the bit set is either 0 or 1. The xml / json
> encodings send the position of the 1 bits (actually the names bound to
> the position). All other bits default to 0.
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>
> _______________________________________________
> core mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/core
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
