Re: [core] YANG to CBOR mapping

[Michel Veillette <[e-mail]>]

Hi Peter

Would you please explain your specific concerns about the YANG to CBOR mapping of decimal64?

YANG define decimal as follow:
   The decimal64 type represents a subset of the real numbers, which can
   be represented by decimal numerals. The value space of decimal64 is
   the set of numbers that can be obtained by multiplying a 64-bit
   signed integer by a negative power of ten, i.e., expressible as
   "i x 10^-n" where i is an integer64 and n is an integer between 1 and
   18, inclusively.

CoOL propose the use of CBOR unsigned integer

   Leafs of type decimal64 MUST be encoded using a CBOR unsigned integer
   data item (major type 0).
   Definition example [RFC7317]:

   leaf my-decimal {
     type decimal64 {
       fraction-digits 2;
       range "1 .. 3.14 | 10 | 20..max";
     }
   }

   Textual form: 257 (Represents decimal value 2.57)

   CBOR encoding: 19 0101

What is wrong in this mapping?

Regards,

Michel

-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of peter van der Stok
Sent: November-19-15 5:00 AM
To: Core <[e-mail]>
Cc: [e-mail]
Subject: [core] YANG to CBOR mapping

Hi CoOL authors.

I have looked at your section 5, and see an enormous overlap with the CoMI section 6. Actually the two proposals are almost completely interoperable, with a few exceptions. Much of the CoMI proposal is based on the work of Ladislav Lhotka, described in draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it extensively. In the CoOL draft the yang-json draft is ignored. That is a pity because you are redoing much of the work already done in the yang-json draft. In the CoMI draft we used the results of yang-json draft, exchanged the YANG name by the hash value, and passed it through the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant solution.
Below, I have summarized my comparison between CoMI YANG to CBOR and CoOL YANG to CBOR. Please check for omissions and mistakes.
Differences concern Binary byte string and Bits. The CoMI choice of CBOR type is derived from yang-json, and I should like to hear the opinion of Ladislav on this aspect.
Other differences concern decimal64, and int; but I expect that is an oversight in the CoOL draft.
A major difference is the encoding of lists and list instances; I discuss that in a separate e_mail.
Given the overlap of work and the need for the expertise of the netmod WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and uses as much as possible the contents of yang-json draft. Alternatively, I can imagine that CBOR mapping is added to the yang-json draft if the author, Ladislav Lhotka, and the WGs agree with that.

Greetings,

Peter
______________________________________________________________________________
Comparison of draft veillette-core cool, denoted with CoOL With draft vanderstok-core-comi, denoted with CoMI And draft ietf-netmod-yang-json, denoted with yang-json Simple YANG type can be :
Binary byte string:                   CoMI, major type 2;                
          CoOL,  major type 0
Bits:                                 CoMI, array of text;               
          CoOL, major type 0
Boolean:                              CoMI, major type 7 (20,21);        
          CoOL, major type 7 (20,21)
decimal64:                            CoMI, major type 0 (pos) and 
1(neg);        CoOL major type 0
empty:                                CoMI major type 7(22);             
          CoOL major type 7(22)
enumeration:                          CoMI, major type 0;                
          CoOL major type 0
  identityref:                         CoMI, major type 3;                
           CoOL major type 3
  int8, int16, int32, int64:           CoMI, major type 0 (pos) and 
1(neg);         CoOL major type 0
  leafref:                             CoMI, follows leaf type;           
           CoOL follows leaf type
  string:                              CoMI, major type 3,                
           CoOL major type 3
  uint8, uint16, uint32, uint64:       CoMI, major type 0;                
           CoOL major type 0

In netmod-yang-json draft  JSON objects are used:
JSON object := { name: JSON object}, where name is a string. For CoMI and CoOL the name can be an integer which is valid for diagnostic JSON used for CBOR, giving:
CBOR object := {integer: CBOR object}

Leaf:
Yang-json,  Name : value, where name is the string identifier of the leaf, and value of Simple YANG type
CoMI: major type 5 containing: uint64, value;      CoOL: not defined

Union:
Yang-json,  use corresponding media type for type of value CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type

anyxml,
YANG-json, value can be of any type.
CoMI, not applicable; CoOL, can be any CBOR type

Anydate,
Yang-json, follows container
CoMI, not applicable,                           CoOL, not applicable

container,
yang-json,	 name:  JSON object
CoMI: major type 5;                             CoOL, major type 5

leaf-list
yang-json, name: [ value 1, value 2,……]
CoMI, major type 4,                             CoOL, major type 4

List
Yang-json, name:[ JSON object1, JSON object2, ….]
CoMI, major type 5 of major type 5,             CoOL, major type 4 of 
major type 5



--
Peter van der Stok
vanderstok consultancy
mailto: [e-mail]

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