Re: [core] YANG to CBOR mapping version 1

[Andy Bierman <[e-mail]>]

On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette <
[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]]
> *Sent:* Tuesday, July 12, 2016 12:10 PM
> *To:* Michel Veillette <[e-mail]>
> *Cc:* Carsten Bormann <[e-mail]>; Core <[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]> 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] <[e-mail]>] *On
> Behalf Of *Alexander Pelov
> *Sent:* Tuesday, July 12, 2016 9:50 AM
> *To:* Carsten Bormann <[e-mail]>
> *Cc:* Core <[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]> 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]> 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]
> https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
>