Re: [core] YANG to CBOR mapping

[Carsten Bormann <[e-mail]>]

Hi Peter,

> The SID and and hash are both numbers, why not map them both to unsigned
> integer (major type 0)?

SIDs benefit from compression by delta encoding (turning them into
signed integers in the actual delta).
Delta encoding does not make sense for hashes (just spreads the numbers
further out).
So it is useful to be able to *distinguish* the two, specifically before
the delta encoding kicks in.

One way that came up for this in discussions about how to best use CBOR
for YANG data representation is to represent the hashes as binary
strings.  E.g., if the hash value is 1234567890, what might have been

1a 499602d2 # unsigned(1234567890)

becomes h'499602d2' or

44          # bytes(4)
   499602d2 # "I\x96\x02\xD2"

Since hashes are evenly distributed in the 30-bit space, there is no
change in the number of bytes needed (except maybe for the p = 1/16384
case that the hash happens to be < 65536).

With this way of distinguishing identifiers, in the end, we can have a
mapping of CBOR data types to identifiers:

CBOR type     meaning
integer       delta encoded SID
byte string   hash
text string   native YANG identifier

(It is then a matter of design and/or deployment which of these kinds of
identifiers are actually used in a specific instance.)

> The server does not care how these numbers are produced, it only needs
> to map the number to the memory locations in the server.

Exactly.

Grüße, Carsten