Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

Hi Andy

The current solution consist of tagging decimal64 only when used in the context of a union.
Same for bits, enumeration, identityref and instance-identifier.
(https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-5.12)
With this solution, the 2 or 3 bytes overhead is present only in the context of a union.

If the group prefer to serialize decimal64 using decimal fractions
(https://tools.ietf.org/html/rfc7049#section-2.4.3)
The 3 bytes overhead will always be present.

I like the second approach but users of more constrained networks might prefer the current solution.

Regards,
Michel

From: Andy Bierman [mailto:[e-mail]]
Sent: Friday, July 15, 2016 4:16 PM
To: Michel Veillette <[e-mail]>
Cc: Alexander Pelov <[e-mail]>; Core <[e-mail]>
Subject: Re: [core] YANG to CBOR mapping version 1



On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alexander

To simplify the implementation, I'll prefer to keep the same representation for decimal64 within or without a union (2.57 or 257)
We simply need to select one.
I'm find with either ones but LPWAN implementers might prefer the CBOR unsigned integer representation.



So how is this union supported with the 2nd option?
2.57 seems the obvious choice if robustness is a concern.


   leaf foo {
      type union {
         type decimal64 {
             fraction-digits 2;
          }
          type decimal64 {
             fraction-digits 4;
          }
      }
   }


Regards,
Michel

Andy


From: Alexander Pelov [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, July 12, 2016 12:10 PM
To: Michel Veillette <[e-mail]<mailto:[e-mail]>>
Cc: Carsten Bormann <[e-mail]<mailto:[e-mail]>>; Core <[e-mail]<mailto:[e-mail]>>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Michel,

If there is a way to unambiguously differentiate between union and non-union, then we should use the most efficient representation. However, I get the impression that you can modify locally a module, which could change the type of a leaf from decimal to union.. which could then lead to confusion.

One of the main issues we’re having is the possible mismatch between the module versions on a server and a client. How about this -
1) we define a (lightweight) mechanism for ensuring the matching of the module versions
2) if matching, then use most efficient representation (e.g. encode 2.57 as 257)
3) if not matching, then use tags for all representations

How does this sound?

Alexander


Le 12 juil. 2016 à 16:57, Michel Veillette <[e-mail]<mailto:[e-mail]>> a écrit :

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:[e-mail]] On Behalf Of Alexander Pelov
Sent: Tuesday, July 12, 2016 9:50 AM
To: Carsten Bormann <[e-mail]<mailto:[e-mail]>>
Cc: Core <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[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


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