Re: [core] YANG to CBOR mapping version 1

Hi Alexander

I want to be sure of your answer.
The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see example for RFC 8049 section 2.4.3 bellow.
This is the tag you are proposing?
This tag will be used all the time (within the context of a union and without)?

C4             # Tag 4
  82           # Array of length 2
    21         # -2
    19 0101    # unsigned(257)

Regards,
Michel

From: core [mailto:core-bounces@ietf.org] On Behalf Of Alexander Pelov
Sent: Tuesday, July 12, 2016 9:50 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Carsten,

Yes, you are right. I thought that we could keep this representation outside of unions. But of course, we need to balance the complexity of doing this.

There could be a confusion if the server and the client have different versions of the same module (rare, but must be taken care of). Which is of course, the thing we’ve always tried to avoid.. So yeah, for the moment we could keep the CBOR decimal tag.

Best,
Alexander

Le 12 juil. 2016 à 12:59, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> a écrit :

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 <stokcons@xs4all.nl<mailto:stokcons@xs4all.nl>> 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
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core