[core] YANG to CBOR mapping
peter van der Stok <stokcons@xs4all.nl> Thu, 19 November 2015 10:00 UTC
Return-Path: <stokcons@xs4all.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0981B3121 for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 02:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dx0vlIfeNVn for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 02:00:06 -0800 (PST)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A311B3125 for <core@ietf.org>; Thu, 19 Nov 2015 02:00:05 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud3.xs4all.net with ESMTP id jN031r00D4d84Ai01N032d; Thu, 19 Nov 2015 11:00:03 +0100
Received: from [2001:983:a264:1:5cbf:6d13:c88d:6742] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Nov 2015 11:00:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Thu, 19 Nov 2015 11:00:03 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Core <core@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl>
X-Sender: stokcons@xs4all.nl (z+DecrVnU1T1CqbFVLylf6gT1tEAc20k)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/ZlDGNh8OYWny6JNMK8nCg4I0OYU>
Cc: lhotka@nic.cz
Subject: [core] YANG to CBOR mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2015 10:00:08 -0000
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: consultancy@vanderstok.org
- [core] YANG to CBOR mapping peter van der Stok
- Re: [core] YANG to CBOR mapping Somaraju Abhinav
- Re: [core] YANG to CBOR mapping Juergen Schoenwaelder
- Re: [core] YANG to CBOR mapping Juergen Schoenwaelder
- Re: [core] YANG to CBOR mapping Michel Veillette
- Re: [core] YANG to CBOR mapping Carsten Bormann
- Re: [core] YANG to CBOR mapping Juergen Schoenwaelder
- Re: [core] YANG to CBOR mapping Michel Veillette
- Re: [core] YANG to CBOR mapping Ladislav Lhotka
- Re: [core] YANG to CBOR mapping Ladislav Lhotka
- Re: [core] YANG to CBOR mapping Carsten Bormann
- [core] YANG to CBOR mapping peter van der Stok
- Re: [core] YANG to CBOR mapping Carsten Bormann
- Re: [core] YANG to CBOR mapping peter van der Stok
- Re: [core] YANG to CBOR mapping Michel Veillette
- Re: [core] YANG to CBOR mapping peter van der Stok
- Re: [core] YANG to CBOR mapping Michel Veillette