Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

Hi Carsten

The current solution is based on the following line in the file "20160525 – minutes.docx".
"DECIMAL – use CBOR’s DECIMAL Tag (we lose one byte, but there are only 5 values of this type)

Since tag 4 (Decimal fraction) require at least 3 bytes of overhead, I assumed the introduction of a new tag used sorely in the context of the union datatype.
(Similar approach as the other 4 tags used in unions)

The use of tag 4 (decimal fraction) for decimal64 values inside or outside the context of an union is another viable solution I will support.

Any strong opinion?

Michel

From: core [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: Tuesday, July 12, 2016 7:00 AM
To: Alexander Pelov <[e-mail]>
Cc: Core <[e-mail]>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Alexander,

This is right. However, I thought that in the discussion of unions we had arrived at encoding decimals as CBOR decimal fraction tags. But maybe I'm misremembering.

Grüße, Carsten

On 12 Jul 2016 12:04, Alexander Pelov wrote:

Dear Peter,

In this case you can infer the decimal point position from the YANG definition, e.g. the statement "fraction-digits 2;"

Which indicates that 257 represents the number 2.57. 2 represents 0.02, 50 represents 0.50, 1000 represents 10.00

I think that you are right that we should provide more examples to be clear on this point.

Best,
Alexander

Le 12 juil. 2016 à 11:58, peter van der Stok <[e-mail]<mailto:[e-mail]>> a écrit :

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>

_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core