Re: [core] YANG to CBOR , identification of objects

Michel Veillette <Michel.Veillette@trilliantinc.com> Tue, 12 July 2016 15:40 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A24712D196 for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 08:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
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 43APKzx31x7w for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 08:40:28 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0125.outbound.protection.outlook.com [104.47.40.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530DF12D956 for <core@ietf.org>; Tue, 12 Jul 2016 08:28:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rli6LJlLMdZczTPCq4yA45sgrRdmTwAffm4CLNRVt78=; b=elQ/UFqf5sYeyF8Q+r2CmQ/LOGEN9Xo6fQtBrg3eg51XaUYCWvYVs8a+cHBYhzJguAgXVlg24ypUQILzYnsg+nMn8bf2C/iBtXKkMDuwPz/huELPAQRj0lktpOP79q0DbGTqQa058h9qxTvjCjC/CmOYDueJ0UgBL+VqRTvKFOM=
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.539.14; Tue, 12 Jul 2016 15:28:44 +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.0539.019; Tue, 12 Jul 2016 15:28:44 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Alexander Pelov <alexander.pelov@telecom-bretagne.eu>
Thread-Topic: [core] YANG to CBOR , identification of objects
Thread-Index: AQHR3Ca9mBIkuJzWoUeQAVKUrHr926AU6aiQ
Date: Tue, 12 Jul 2016 15:28:44 +0000
Message-ID: <BLUPR06MB176358F95C56C70A91ECB672FE300@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl>
In-Reply-To: <0ab68685ab75d14335cb130faa1f5722@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: [207.96.192.122]
x-ms-office365-filtering-correlation-id: a1e95204-d95f-475a-b6dc-08d3aa693651
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:awd4McXa7ilX6S8i0Rvqpt8J2mjYJ8o39q8mwbnTPZmw+BXk0L9Y/S8JilJ3K5kkRmU5ihpt8pRslsHM8yHR+F4DKxtq4E7p0oScA1m2u0fEa5TKKoFxs+LegMW2wYVuWutSeqA9h648nJa59AWYfJyiOZnwgxtWRl8A0LRqWQe6W/hc4WW7y7rlSTVRsyMZ5xTyJNow40zJQcaaniwoNWHqldSrJR9PWYtp+xj5q68365AenhbZZEQ/2Br9U9cBqiw1uI3ImRpzRlaZViu1naR6nz32icTFqc0g+WS0Wwg=; 5:wJqxQ5i+QpROS7W1lZkepT7b2js6TgZKxThKN5/ywrBj+EKO+BRWL/GYNR7AUT9PshFeaQSMS+DiDfE26rAA/mSPqFsBKXbtx8Gn6YCcyhuUopEQ+rBFAtbCdDU8leRexD9WuL+PRKlvmgHtN1REyg==; 24:HnCIR+ObPppop+r9F/1A5BwgSvMrOZHvZxQaH/lqIKX9leLAaXIy3ZGeDBBqAmYML/qfCV8kJ3k+uwZOZ31L9HtaggMRcOoY9MAUMqXKN0o=; 7:k0nwicQ6nWiTXjUNoV69oGcmuU7Zi5y6HOLKmgHj/fOI+KIXFAqvvJwpSN4eCTUUPS0AblhG/iulF08CzMZ1UUeLDVMyCp80u0peTW2wdGuQ9JJfXLmW1RWau+zhxLX8iSUKhSxNSu0l7kfC5MdCYEjkFI3AWaSSF93GbC+A4oxcouuOz6HOzHv69i8YxdL+BNIjeMR0blxvnqQTuxVcE7cjI9i/XdjD7ivvb7ivRijA54tmOHtMb1eLoGAOGg8o
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: <BLUPR06MB1761B4A12FD05A9F2F6E4333FE300@BLUPR06MB1761.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(4326007)(2900100001)(2906002)(92566002)(2950100001)(99286002)(76576001)(50986999)(2501003)(3280700002)(3660700001)(81166006)(81156014)(3846002)(6116002)(8936002)(74316002)(122556002)(5002640100001)(102836003)(586003)(11100500001)(19580395003)(19580405001)(66066001)(9686002)(305945005)(8676002)(7696003)(68736007)(7736002)(5003600100003)(10400500002)(87936001)(33656002)(106116001)(101416001)(106356001)(86362001)(77096005)(105586002)(5001770100001)(54356999)(189998001)(76176999)(7846002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 15:28:44.6242 (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: <https://mailarchive.ietf.org/arch/msg/core/Yw21hJXgV-wXDGd5yL4egXH-9SA>
Cc: Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR , identification of objects
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 12 Jul 2016 15:40:33 -0000

Hi Peter

Transferring the concept of parent deltas from "draft-ietf-core-yang-cbor" to "draft-veillette-core-cool" is technically possible.
This change require some level of effort so I will prefer to get a consensus from a larger group before moving ahead.
Carsten, Alexander, Abhi, Randy, Ana, ... do you have a strong opinion about the approach proposed by Peter?

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl] 
Sent: Tuesday, July 12, 2016 6:18 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: consultancy@vanderstok.org; Core <core@ietf.org>
Subject: RE: [core] YANG to CBOR , identification of objects

Hi Michel,

Here we have a point where my vision on this document differs from yours.

> 
> Section 3: “the specification supports three types of keys.”
> I would suggest only 2: character strings and numbers.
> The use of deltas is either application (CoOL) specific or YANG to 
> CBOR mapping specific.
> If it is YANG to CBOR specific, I would encourage the use of another 
> CBOR type that specifies a delta. As specified here its use is 
> ambiguous; and forces each application to specify explicitly what is 
> meant.
> In the case that the delta is CoOL specific, I recommend to remove it 
> completely from this draft, and explain the use of Deltas in the 
> appropriate CoOL draft.
> In the latter case: What remains are two key types: number and 
> character string.
> 
> [MV] The use of delta to encode integer based keys (SIDs) is an 
> integral part of the YANG to CBOR mapping.
> [MV] This optimization is part of the encoding and independent of the 
> application.
> [MV] The document is updated to keep only 2 type of keys
> 

I am preparing a third document that describes a local numbering scheme for YANG identifiers based on discovery.
The numbers will be quite small and I like to encode them as unsigned integers.
However, with the present YANG to CBOR document some numbers must be encoded as Deltas, and that is not what I want.

Therefore I recommend that all hash conversion to CBOR goes to the yang-hash document and the SID conversion to CBOR goes to an appropriate CoOL document.
and the coming numbering conversion to CBOR also treats it in an appropriate document

This document can then specify that identifiers can be strings and numbers, where for example numbers are encoded as unsigned integers.

Greetings,

Peter