Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

Hi Peter

Multiple aspects of YANG assume that the entities which serialize and de-serialize are schema aware.
This knowledge is used for example to apply default values where needed (see rfc6020bis section 7.6.1)
This knowledge is also used to perform all kings of validations
(range, pattern, length, min-elements, max-elements, must, when, if-feature)

The proposed mapping, as stated by https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-3
use this awareness to minimize the information transferred.

In the example

    leaf temperature {
      type decimal64 {
        fraction-digits 2;
        range "1 .. 3.14 | 10 | 20..max";
        units "°C";
      }
    }

This information is used to serialize 2.57 °C into a CBOR unsigned integer 257 (3bytes).
The same information is used to de-serialize to the CBOR unsigned integer 257 back to 2.57 °C

This encoding is less friendly to schema unaware debugging tools (e.g. wireshark).
If the group believe we need to be more friendly to such tools, we can adopt the CBOR tag 4 (Decimal fraction) as defined in RFC7049 section 2.4.3.
However, this encoding will require 6 bytes in the case of "2.57" which is more than the textual form.
This significant overhead is the main reason why peoples have agreed to adopt the current encoding.

Can you propose some texts to clarify this topic?

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[e-mail]] 
Sent: Tuesday, July 12, 2016 5:58 AM
To: Michel Veillette <[e-mail]>
Cc: [e-mail]; Core <[e-mail]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

I separated my answer into three parts to simplify the discussion.

> Section 5.3;
> In the example, where do I find in the CBOR encoding that the fraction 
> is 2 digits?
> 
> [MV] The number of digits is not encoded. This information is 
> considered an unnecessary metadata [MV] similar to "units", text of an 
> enumeration, name of a flag within bits. This was the consensus [MV] 
> of the group which is aligned with the statement in section 3 (In 
> order to minimize the size of [MV] the encoded data, the proposed 
> mapping avoid any unnecessary meta-information beyond [MV] those 
> natively supported by CBOR.) [MV] It might be worth it to raise this 
> topic within a larger audience.
> 

The following example shows the encoding of leaf 'my-decimal' set to
    2.57.

    Definition example from [RFC7317]:

    leaf my-decimal {
      type decimal64 {
        fraction-digits 2;
        range "1 .. 3.14 | 10 | 20..max";
      }
    }

    CBOR diagnostic notation: 257

<pvds>
Should it not be pointed out more strongly that the yang to cbor conversion fails in this case?
I don't see how a change from 2.57 or 257 represents loosing unnecessary meta information.
Unless I completely miss the point of the example.
</pvds>