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

Carsten Bormann <cabo@tzi.org> Fri, 11 December 2015 09:55 UTC

Return-Path: <cabo@tzi.org>
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 270811A6F32 for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 01:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 kOB9LFh_ImiB for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 01:55:22 -0800 (PST)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197E71A1BCB for <core@ietf.org>; Fri, 11 Dec 2015 01:55:21 -0800 (PST)
Received: from mfilter46-d.gandi.net (mfilter46-d.gandi.net [217.70.178.177]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 98934A810A; Fri, 11 Dec 2015 10:55:19 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter46-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter46-d.gandi.net (mfilter46-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tVLak-EM8Zhv; Fri, 11 Dec 2015 10:55:18 +0100 (CET)
X-Originating-IP: 134.102.90.119
Received: from eduroam-pool10-120.wlan.uni-bremen.de (eduroam-pool10-120.wlan.uni-bremen.de [134.102.90.119]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 00810A80D0; Fri, 11 Dec 2015 10:55:16 +0100 (CET)
Message-ID: <566A9D84.8020809@tzi.org>
Date: Fri, 11 Dec 2015 10:55:16 +0100
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@nic.cz>
References: <BLUPR06MB176391F16B5E9D6CCC531771FE0E0@BLUPR06MB1763.namprd06.prod.outlook.com> <m2zixhwcl2.fsf@birdie.labs.nic.cz>
In-Reply-To: <m2zixhwcl2.fsf@birdie.labs.nic.cz>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/qujOouxdC6wOmdAJhXhJ8sTwhD4>
Cc: Core <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: Fri, 11 Dec 2015 09:55:24 -0000

my 2 µJ for now...

> 1. Would it make sense to use semantic tagging (major type 6) to
>    distinguish numbers or strings with special semantics? Possible
>    candidates that come to my mind are instance-identifier and
>    identityref values.

In general, the assumption has been that semantic information would come
out of the YANG schema.  Is there a case where that is not so, and we
need to represent it at the representation level?

> 2. Why is the "decimal64" type encoded as an integer and not as "decimal
>    fraction" (major type 6, tag 4)? Whilst the decimal value can be
>    obtained by using the leaf's definition, 

Because we can get the exponent value out of the schema, we don't need
to transmit it.

> perhaps it may simetimes be
>    useful to be able to correctly interpret the values without using a
>    schema.

Right.  We probably have to make up our mind how useful YANG-based
information should be in a schemaless environment.  If we want to make
it useful, that requires quite some different thinking than what we have
now.

> 3. I think it is necessary to include namespaces/module names in the
>    encoding of identitities (sec 3.1.7). It is probably not very likely
>    in that particular example, but somebody could define another
>    "iana-interface-type" identity in another module. Identities were
>    designed to be extensible in a decentralised fashion, so the CBOR
>    encoding should IMO also represent the namespace.

We should take note of this problem and put it as one more objective for
the identifier discussion (the hashes vs. structured IDs vs. ... one).

Grüße, Carsten