Re: [core] CBOR Encoding of Data Modeled with YANG

Michel Veillette <Michel.Veillette@trilliantinc.com> Wed, 09 December 2015 20:48 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 8B6681A92E0 for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 12:48:08 -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 qqKQ0iWr_pPS for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 12:48:06 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1347E1A21AD for <core@ietf.org>; Wed, 9 Dec 2015 12:48:05 -0800 (PST)
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 20:48:02 +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.0337.015; Wed, 9 Dec 2015 20:48:02 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [core] CBOR Encoding of Data Modeled with YANG
Thread-Index: AdEtPHYWp5+Kr9OtQ0Oj//Irn0p12QDkrIIAAAzxqKAACR5VgAAAPE1QAAG37gAAAP5qIAAaFoAAAAGBWAAAC66EgAAJfYHQABj2foAADi0ysAAHvA0AAAREnoA=
Date: Wed, 09 Dec 2015 20:48:02 +0000
Message-ID: <BLUPR06MB17635817CA9A16E880F5BB55FEE80@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <20151207194229.GA61491@elstar.local> <BLUPR06MB1763B7F9EBF812C06DB04252FE090@BLUPR06MB1763.namprd06.prod.outlook.com> <20151207203826.GA61647@elstar.local> <BLUPR06MB1763E9AB0D1E4A0478D47C05FE090@BLUPR06MB1763.namprd06.prod.outlook.com> <20151208093350.GA62650@elstar.local> <5666AE1A.2040908@ackl.io> <m28u55lz0g.fsf@birdie.labs.nic.cz> <BLUPR06MB1763F77EC35C38FE64265C73FE080@BLUPR06MB1763.namprd06.prod.outlook.com> <m2io48ox1m.fsf@birdie.labs.nic.cz> <BLUPR06MB17639FD1577077587EC75CBBFEE80@BLUPR06MB1763.namprd06.prod.outlook.com> <20151209184520.GB24514@elstar.local>
In-Reply-To: <20151209184520.GB24514@elstar.local>
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; BLUPR06MB1761; 5:kMmzMUaxiz33kNnQ8Mkuxix4lB8bF8hofc0L6x07WB/XUhZTezINgyy+bqpX9BhH1DQJw37zA7ZIexlhdhSowAiLXZfy04ncPiQeO/JfUffxJ94tHQf2Kc+vIXdy5Fcx4wa8FZlS82eFMUxCxVrgGA==; 24:5phcwWIzCd8NA3EERyf+AJfZTPl4oLctq88ZJYiRWliOT/8QX4n4yz0xBvwyDkoycHVlsmc4nuh2atXtL/kzTCZQDSdGZ+Z4sgthE1lVJ68=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: <BLUPR06MB17613A4836BFFE073E2E9F04FEE80@BLUPR06MB1761.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(256376046250027);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761;
x-forefront-prvs: 0785459C39
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(43784003)(189002)(13464003)(199003)(377454003)(99286002)(5008740100001)(11100500001)(5002640100001)(1220700001)(66066001)(81156007)(54356999)(76576001)(93886004)(97736004)(5003600100002)(33656002)(92566002)(10400500002)(50986999)(189998001)(110136002)(586003)(3846002)(5001960100002)(102836003)(6116002)(15975445007)(5004730100002)(19580395003)(77096005)(86362001)(2900100001)(101416001)(2950100001)(76176999)(19580405001)(1096002)(40100003)(74316001)(87936001)(122556002)(106356001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2015 20:48:02.6284 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/G1I0t4irzTFnPBccfzD9BliJ9AI>
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG
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: Wed, 09 Dec 2015 20:48:08 -0000

Hi Juergen

A possible solution to this issue (revisions in the hundreds) is to provide the base line version
when registering for a module ID.

IDs will be generated only for the specify version and any subsequent versions.
In practice, the latest version can be the base line and access to the previous definition files won't be necessary.
Since each version always represent a superset of the previous ones, IDs generated using the latest version
cover all objects already defined in any previous versions.

Thanks again for your comments
I things we're making progress.

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: December-09-15 1:45 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>; core@ietf.org
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

On Wed, Dec 09, 2015 at 06:20:26PM +0000, Michel Veillette wrote:
> 
> *        import without revision will be rejected
> The list of data nodes must be known and can't change over time to make the algorithm unambiguous.
> In this context, import of modules without revision can't be supported.
>

Almost all published YANG modules so far use import without revision...

I am also concerned tracking all revisions in order to produce the correct numbers in not very robust. I have seen proprietary MIB modules with revisions in the hundreds and if it is necessary to obtain all revisions in order to compute node ids, this will be a major hurdle in practice. Well, in the IoT space, perhaps we end up only with revisions in the 20s or 30s but again obtaining all revisions to get the numbers will be painful. And since humans are involved, there is also a change for subtle errors that are difficult to spot.

/js

PS: We had some discussion about the auto-numbering of enum and bits
    values in YANG 1.1. Automatic numbering algorithms are subtle.

-- 
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/>