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 <Michel.Veillette@trilliantinc.com> 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:core-bounces@ietf.org <mailto:core-bounces@ietf.org>] On Behalf Of Alexander Pelov
> Sent: Tuesday, July 12, 2016 9:50 AM
> To: Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>>
> Cc: Core <core@ietf.org <mailto: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 <https://www.ietf.org/mailman/listinfo/core>
> 
> _______________________________________________ 
> core mailing list 
> core@ietf.org <mailto:core@ietf.org> 
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>