Re: [core] YANG to CBOR mapping

[peter van der Stok <[e-mail]>]

Hi Carsten,

thanks, see below.

Carsten Bormann schreef op 2016-03-10 10:31:
> 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"
<pvds>
Is misinterpreted this in the draft as a rather long "character" string
thanks for the explanation
</pvds>
> 
> 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
<pvds>
like the table
</pvds>
> 
> (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