Re: [core] YANG to CBOR mapping

Somaraju Abhinav <abhinav.somaraju@tridonic.com> Thu, 19 November 2015 10:37 UTC

Return-Path: <abhinav.somaraju@tridonic.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 D89BB1B31AC for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 02:37:43 -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, 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 C1h-Nl2YWQG4 for <core@ietfa.amsl.com>; Thu, 19 Nov 2015 02:37:37 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224971B31A1 for <core@ietf.org>; Thu, 19 Nov 2015 02:37:36 -0800 (PST)
Received: from HE1PR06CA0039.eurprd06.prod.outlook.com (10.162.181.177) by DB4PR06MB159.eurprd06.prod.outlook.com (10.242.155.145) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 10:37:18 +0000
Received: from AM1FFO11FD002.protection.gbl (2a01:111:f400:7e00::114) by HE1PR06CA0039.outlook.office365.com (2a01:111:e400:51fa::49) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 10:37:17 +0000
Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=bestguesspass action=none header.from=tridonic.com;
Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net;
Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD002.mail.protection.outlook.com (10.174.64.84) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Thu, 19 Nov 2015 10:37:16 +0000
Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 11:37:15 +0100
From: Somaraju Abhinav <abhinav.somaraju@tridonic.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [core] YANG to CBOR mapping
Thread-Index: AQHRIrFTXNOJF8VKB0ykgcqez4yUdJ6jDz2AgAAXLvU=
Date: Thu, 19 Nov 2015 10:37:15 +0000
Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACEDF@ATBRAGMSX02.itiso.net>
References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl>, <20151119101143.GA2107@elstar.local>
In-Reply-To: <20151119101143.GA2107@elstar.local>
Accept-Language: en-US, de-AT
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [146.108.8.124]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD002; 1:LXwAJDku2rFCTlFbJlyzkjKmPv3STGgRYJJF+yxyTBao4jAIxTUJ/2lYmuMN0eZIlaD17/TBg39pI9BRvwUGuLmCQL1p4ChRtn5y20sGNDRMwwVCOX0DY+XYqS5gCIqtIn3BS/Usloj+SYWX+YWN0RA5PbW9YszwnRLSSO4LWe+Asv8xUnj1N6iJxtLTmF4hUiWB9WpiGBM0vT0bnjtiWdF9s2vAsZNyHZmjAKGonEDGuFQp379Z3Yu0z6v2TZ9fe/onFg2yCBAKhHGkrjaKAX0iXzb3QvU0OdE8cyiSNYgRDDuRlaHZ8MICoSN+gRJAvAq/rNykONQQyu9gd8w+0r+o5YLGQFssvb8ADjWwvQI=
X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(24454002)(189002)(199003)(51444003)(561944003)(33656002)(53416004)(87936001)(5890100001)(104016004)(189998001)(86362001)(69596002)(5008740100001)(6116002)(15975445007)(102836003)(2501003)(23746002)(55846006)(106466001)(5004730100002)(3846002)(2900100001)(81156007)(2920100001)(54356999)(5003600100002)(6806005)(26826002)(47776003)(5001770100001)(50466002)(50986999)(106116001)(5001960100002)(92566002)(5007970100001)(19580405001)(76176999)(2950100001)(5001920100001)(19580395003)(586003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB159; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 2:+/DTlCLvZ47Son4u9q/sStCvVOLyS0dzl7kq9tjZKaC4ptvRDdbkNX4t+i3HXACcdwFauZn+jH63PeYMq7xJ/IP/6rPc9Tj6crzyGTQKQdvJQPH+H3PENXXgvCJMvy4pnGp4PTDoBEwJl1qcj0jk/q9F52zrooCqfJpZJ6qydLo=; 3:ixJEAlBc75y1fRVRBmOsMzu6fq9W4qCjPFk1qQV196R/11kU4cn8k9q2xnWJfDiPCySgP/PdnXQ0FdpiuTg3EJU0WRt2xT4DI1e/9dBXlWKhmnlKtfqovTFVUeVCrpOcinjkw8PsIcTxROWUlh5NIKN+pKqqfKrSOnfv2Z5bXzlaDpciEj4Xo/PA4pWVAMlEUgYyUsD4HUdcIeDes7JPde+9rzWyEizrHgWnGUvrNl8JfVIzjB+CIht4nulm4lRF1T/qVbSLe86I5YzLDIeL+Q==; 25:MtcViKZuhmPpXvbW4FvEQgjcNNXw4hJwxjrOis2jvSVYiZ/u0Y31q9e0ZvJqYreMskPWud0nUvR+oGft0nD1sI7TVY6WapKdduLfJej3VT36YgcB0fHnRy/cgsJ9XgA7Myt6GGv9yjkc+fnofSVpBQQs4Dr8nxrv7TbPHFryLYdA5Lb08vnyL663JA5dbwYAhoNqMYHCCtIayRUWW6KH9LLS7ZvA0pDvBM939PF+cQr1urQk1ZKihc/OnmDhZmz4mJsIJ8GGMs9eagtwZL1Y3A==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB159;
X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 20:OIYBTu3nZSXmI4UCdPFlV4xi7o6RhOG/YjRKxybpPtDauP2+XtJ/oWqW8wp4bN59Cqv9IbHLxVC6x//fhR+eqQ0jb07bhcz4ve33T3CHaV6Oj9uSsrwqQUb+uTEZmzCiCwlQ6XrxVdMzEI8m9S/DnqrIsRasyVVFMs73M1Xd8mj1r/IA+BGPoiYwPuIziTf+WdaTN67nz5lYnP3lto3oX4CPrjY/w5d3Uo0k5EwC2RV9TcIR8BUU6vR7SMJbJvIJ7tXu84avRSZamddLEIuXNJQWTDbDnxq2CddybyKKnrK3apFbwYyTTLPeLtsjuWN6dHvhR8LQLbqPM0YctuzG0Mn1Pc1oQZWvPfPvqDyBlVdcYmA+YA5sPtvKSNA9CDCusfqFBdiU4AdFSYHBZF6Qz04himH1jdpmi53iCZghtnhXOml5tEA1h9a3diWUehxJWwaq/fsOlEULhkC63x8dv2ClxRo0Eu8c3e2XglUrezlSi8weS4jE3pS/zF3Cj2YT; 4:nvofuHIel6WTIleZIpZ+wF+jesjS2pwfrmBt0LulUKt/jtR6CoAfegVqhOSU/8AXnLAVtIKWVJ0cG9N1VIoqdpcxAM7HVBMguGBO8zi0F6Jg22yl3Nk1Sk4ioB6bAgcB7bRC1h9+CwwxxuPGjnc7oYPDeFDFBRkcCVY9wo6xVyeHObE4C80F0BblE4naPVXPWv9FJ5jjuldmXAHsOIP5lJ6Fh9m1IqkNF4J7XaTTjMKUmMDe8f9R8qHOv5iMnb2OYN6GEGXWNJMTHsd90xeLjXcws50M/4QK31S8Ap5PapefQwbE8HjzbnZ9OAdASp4Xg8ApGUkoSkrcz+4YGjnxcue5MYQ4642aNNY/Tjbe0UUPyVOCoE2n6bLzMB+e1/+0
X-Microsoft-Antispam-PRVS: <DB4PR06MB1593AE3B0B4D464C98E2366FC1B0@DB4PR06MB159.eurprd06.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB4PR06MB159; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB159;
X-Forefront-PRVS: 07658B8EA3
X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 23:K7EKELEmRPPMd0Lt6z1MxKadFy2zeAbOM2Yd9jBmx3T4BWOP4eYXA6ALtuTTkshyctYOwpSrwTQDdCAJs500k5uJ8B4SaKHi6GlSGIZDDCtmICTBhUbNyWkzLoCUAUQ4KpQzBpvholVnEsJvZEs/y5gffxvd/OldPS4ZgcEWUgFP1tMA1PvZuTbdPfGjNWkrR4dNkv0P5V9BtECR3lTrtiZkLhqRnHsXyGKAY0LzCpXa5tMC9gDKQHxHtr7vzR3Gp7NRM5Jrs6JkB4mCP2TXFzYURQbtmLXYZU6qoOCLB2GeRwlVQlf9AXaAD2s+f5031SbyaUcf4pkK83FZyYCbT2ensgOvrPr3DKc/s0Bd1qQksfLdsTQFiATzDMkw9GT3rCRtEOCCA5oaw88ZtgCn3CDOCyx1eqoLS3iyBYi8CaW69ScP5XzBEa8tcgrI1mfSYhzcFPZRAI4U1qF4CWKOUEeZu6kvpGd+nbX9Fd8F4HJJkDpgcq3ogVi756XB4qmTjHb3KIKoGGCR4mQ0Jyo/wgtF5167vpE7FTQMpDEQS9RIfsJEq4u8QOrP71j9nKut0LtX7WuckrgVTNRJPDoR8nNrFlwbQ01cRGILzhy8hKsGqQeznKbSgVx0Js0nrPPF9T5FlVwnXLjDUIuOpp06Bt/dQ7/QgksleZ7XZicTMrlqCyBeIdr/84/PbdDhHHute4gYVIAj8EzUwJiLqZy4KtsBR4KpfYGB1r9W/yXJZAp9kJEHN3AytrPplh5k1lxEgPYyGe36PJ0c7WLWWACnfe09GH3q830wAxQWZrF7kI65QW0A2PsoMSTQK8z6SWCwFAntKWMPw6GGl9ozsow/35J+jYYZAj3/JDGwM7eWVJk571P3bvH/u6GZlGSUSGrvnU4QMEeBM3zLUbFXdo3NtR/kxEkWh5O9hc4yYxwHAGAEW9WjSmjAcW5mLBoic6cT6KxQiz6U0W8As3TDbCpQEHsdpKpS/An51dvaEMO0e08u7cySPKPEVg2z4GqyGwNDbqcLyvXGvKItmqR+LLkT/2dWcwFF78tG/kWm8xwzTbWhXfpZpnp0l65KscR1IAJbkahZiWWyTGVFB0Mf2f0WMZNA7xmDc+pNbxpx5KnjoFCNPLb+wiWtGrPBavWWLa5bNG//teQA89fyW7fJrGwRPJck1F6hzJpJHAHVKJrm/h2NQRL0nDY5f5gixKl2BciLgEcUR1xsJ4kY0/rloekwMrPapX/kbthKLxYmuf6V7Am6hScKelSqqi6m60fEiyf8qbCq+1NmD4BCOMxzkwf3W8lxblD0oGeEUdFJZtog2WQ=
X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 5:wSCHT+AgTX0tfWZNFei+pMn/Z9f1cCqMyobOt9T11R8cIwsEmfWTu4YP+uYojFMogqm8+QtveKQLFfjbe8i3VdbBxEc/u/xbTNvv77s0Zo04ecE0NDOYjwjb/lS+aRzfESDfhK9SxQyg1h65i1ZQsA==; 24:RhZd0bcuzQhQS1lamqBOw43K+C+olYExfH13cGuHSTTTERfeIoxVleOivQ8bRCfi3w6OcVFpXg7RphYsmCI1RiOhyTv1nUZJwFhDkpVkfrw=; 20:n9dz4w25pK3ME5xS4mgsdx+DuKH5KhTxXqD0z2LJL5v4d/zbDH+stIw5ss7eZUtmFtNKq6RWR6lbkPsmqfcKsw==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: tridonic.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 10:37:16.7228 (UTC)
X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB159
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/vWtKW9BsPDUw1MrUSEg3gFstkgo>
Cc: "lhotka@nic.cz" <lhotka@nic.cz>, Core <core@ietf.org>
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 10:37:44 -0000

Hi Juergen,

I agree with you about the modularity and like your proposal. However, there is one issue we need to watch out for. The CBOR spec. [RFC7049] already says something about converting from JSON to CBOR. So, we should probably be careful that we do not have two ways of getting to CBOR from YANG - via YANG to JSON to CBOR vs YANG to CBOR.

Abhinav
________________________________________
From: core [core-bounces@ietf.org] on behalf of Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
Sent: Thursday, November 19, 2015 11:11 AM
To: consultancy@vanderstok.org
Cc: lhotka@nic.cz; Core
Subject: Re: [core] YANG to CBOR mapping

I am not CoOL but as contributor I think that the CBOR encoding of
YANG data should follow in style the JSON encoding document but it
should not normatively depend on the JSON encoding document. The
reason is modularity. There are systems that only want JSON and there
are systems that only want CBOR.

>From the NETMOD perspective, I am pretty sure CBOR is _not_ added to
the JSON encoding document. The reasons is modularity (see above) and
also the fact that the JSON document is pretty much done and several
other documents depend on it and we won't hold things off for another
N months.

Whether the CBOR encoding is done in CORE or NETMOD can be discussed.
I guess this is a decision whether this requires more CBOR expertise
or more YANG expertise. Given that this work started being discussed
in CORE, I personally would not mind to leave the work in CORE and to
ensure that NETMOD is kept updated when things become stable (e.g.,
the CBOR encoding document goes to WG last call).

/js

On Thu, Nov 19, 2015 at 11:00:03AM +0100, peter van der Stok wrote:
> 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
>

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.