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

peter van der Stok <stokcons@xs4all.nl> Tue, 12 July 2016 10:18 UTC

Return-Path: <stokcons@xs4all.nl>
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 0BD7C12D791 for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 03:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 vwRxgQa7oMag for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 03:18:28 -0700 (PDT)
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 5266012D78F for <core@ietf.org>; Tue, 12 Jul 2016 03:18:28 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id HmJS1t00E4K0fSy01mJS9Y; Tue, 12 Jul 2016 12:18:26 +0200
Received: from 2001:983:a264:1:dbf:8e04:7626:a035 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 12:18:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 12 Jul 2016 12:18:26 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com>
Message-ID: <0ab68685ab75d14335cb130faa1f5722@xs4all.nl>
X-Sender: stokcons@xs4all.nl (LwgAYANbM4p6i6xfXMiVDDDCreLEIF3K)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/I0QZtY3vfJhu9SbA8zOwPVUZz_8>
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
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: Tue, 12 Jul 2016 10:18:30 -0000

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