Re: [core] YANG to CBOR mapping

[Michel Veillette <[e-mail]>]

Hi Carson

I already sent an email about the reasons why we need to define a direct mapping (YANG -> CBOR) instead of a two step mapping (YANG -> JSON -> CBOR). I hope the reasons provided are satisfactory to you.

It's important to note and realize that the actual CoMI draft already don't comply with draft-ietf-netmod-yang-json (e.g. list mapping)
The implement of bits using a CBOR byte string won’t also be aligned with draft-ietf-netmod-yang-json
Defining a two step mapping (YANG -> JSON -> CBOR) make things more complex and might not produce the most efficient encoding.

This doesn't means we design this from starch.
The draft-ietf-netmod-yang-json draft is used as a template to defined the (YANG -> CBOR) mapping.

Thanks for your comment about decimal64 and the typo.

Regrads

Michel

-----Original Message-----
From: Carsten Bormann [mailto:[e-mail]] 
Sent: November-19-15 9:55 AM
To: Michel Veillette <[e-mail]>
Cc: [e-mail]; Core <[e-mail]>; [e-mail]
Subject: Re: [core] YANG to CBOR mapping

Hi Michel,

I'm not Peter, but:

{ "hat": "chair", "message": "
We get to do COMI in CoRE (we hope -- the charter is still in process) because we have promised to work closely with the relevant network management groups.  This means we'll need good reasons to deviate from what NETMOD etc. already have agreed to do.
"}

So I think that Peter's reminder to stay close to draft-ietf-netmod-yang-json -- unless we do need to deviate -- is quite germane.

(If I were designing this from scratch, I would ask myself whether we shouldn't stay closer to the schemaless roots of JSON, e.g. by exposing the exponent in the representation data and not just in the YANG schema.
 But that is a discussion that maybe should be had in NETMOD, if at all.)

I think the specific observation about decimal64 is that it is based on signed integers as the mantissae, so we need to allow negative numbers in CBOR as well as unsigned ones.

To contrast this to a place where we may want to deviate, doing "bits"
as an (unsigned) integer sounds right (at least until we need more than
64 of them in one "bits" item).  This runs into the same numbering issues we have with the intra-module names, though.

Grüße, Carsten

PS.: Typo:
   Leafs of type binary MUST be encoded using a CBOR byte string data
   item (major type 0).
(CBOR byte strings are major type 2.)