Re: [core] YANG to CBOR mapping
Michel Veillette <Michel.Veillette@trilliantinc.com> Thu, 19 November 2015 13:54 UTC
Return-Path: <Michel.Veillette@trilliantinc.com>
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 DE78B1AC3CB for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 05:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 OvVRCgiopOEd for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 05:54:49 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1281B29B0 for <core@ietf.org>; Thu, 19 Nov 2015 05:54:48 -0800 (PST)
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB307.namprd06.prod.outlook.com (10.141.23.147) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 13:54:46 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 13:54:45 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0325.019; Thu, 19 Nov 2015 13:54:44 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Core <core@ietf.org>
Thread-Topic: [core] YANG to CBOR mapping
Thread-Index: AQHRIrFRDohJFilcHkWMJpxQ90rIt56jTpSA
Date: Thu, 19 Nov 2015 13:54:44 +0000
Message-ID: <BLUPR06MB1763C6BBEEE42279A79A8F30FE1B0@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl>
In-Reply-To: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [24.225.215.88]
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:ZeAu0tGTwPs3SN42st1oBP8nPcl5f9CBNtSp/2OV8nOaakJWkFWz/oYGfOPhUJFYQFMYNZFZ0g+5z5sWq/JXoMPMQ2hg168iemL3z2OzYW3CqplcwMH+NKgF0jERyvl/AAcLC456Ckjkcob1mROZLA==; 24:Kx8aNI9DoGOM/sJmGYrSuADfMXHbXG/jXsIkpsL9MfeYLOoQTPaXRS6qxubCrxuBqVjIGccNkAZD8I7JsBQ24zGtxdaL7WutjhZ3j8tWl9k=; 20:RhQnaZ+LthowLFi0x+AKzarqdfxVkKiMHkTzbYVdWMsTCyhGEomVsIEJlxGQE3Kc3ISoL6q+oaROVUERWyMfUw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763;
x-microsoft-antispam-prvs: <BLUPR06MB176305A0D95C2E0FF3D9DE6CFE1B0@BLUPR06MB1763.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763;
x-forefront-prvs: 07658B8EA3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(66066001)(5008740100001)(5002640100001)(5007970100001)(5003600100002)(76576001)(586003)(15975445007)(101416001)(87936001)(5004730100002)(76176999)(50986999)(2950100001)(6116002)(3846002)(2900100001)(54356999)(77096005)(2501003)(102836003)(33656002)(86362001)(10400500002)(92566002)(122556002)(99286002)(74316001)(106356001)(5001960100002)(40100003)(189998001)(81156007)(105586002)(106116001)(19580405001)(97736004)(5001770100001)(19580395003)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2015 13:54:44.8319 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763
X-Microsoft-Exchange-Diagnostics: 1; BLUPR06MB307; 2:HhojDf7BwPfzFxz4Tjwp21YrbrBT5+H0iGm0RVK9Sgh/7DBl1d6RVyucuT+4b88Z4SfVmgRvJJ/uHFRrcop7zIsAAy60tH5ayfO7yESHBOzQ6sznP5R0PLuraOPYCFq01a0lTZMBalK5q2htiXhqLjzbxNHl2FyHje8OKY02IgU=; 23:C0C2aB0OFQqSBOYdK7flyahQOkXA8ascpX2s7Mup6Q8YqA5F/4tQiy+CRbQYNgASOvrjJbmjWqOJI/atU+AkvZHUJKGlb4gqVn4yhn8bLmG3oljSZwM2MZcgLsal7AjmG18SzVhJFp0cUvzU2iMzLUbkR6jX2qvNnzY37UeEqYCgtif7qrxjOJKfJwgMUTKn
X-OriginatorOrg: trilliantinc.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/dKepFjAKxXySaW7bjVHXE9aBIUY>
Cc: "lhotka@nic.cz" <lhotka@nic.cz>
Subject: Re: [core] YANG to CBOR mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 13:54:52 -0000
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:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: November-19-15 5:00 AM To: Core <core@ietf.org> Cc: lhotka@nic.cz 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: consultancy@vanderstok.org _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core
- [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