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

Ladislav Lhotka <lhotka@nic.cz> Fri, 11 December 2015 09:37 UTC

Return-Path: <lhotka@nic.cz>
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 B5F801ACED7 for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 01:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jgAJnO-4wlba for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 01:37:20 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F21ACE84 for <core@ietf.org>; Fri, 11 Dec 2015 01:37:20 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6CF2E1CC01A5; Fri, 11 Dec 2015 10:37:15 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>, Core <core@ietf.org>
In-Reply-To: <BLUPR06MB176391F16B5E9D6CCC531771FE0E0@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <BLUPR06MB176391F16B5E9D6CCC531771FE0E0@BLUPR06MB1763.namprd06.prod.outlook.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 11 Dec 2015 10:37:13 +0100
Message-ID: <m2zixhwcl2.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/R_0ZNLxlkSeYBs0sbE6hEMt-WRY>
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:37:22 -0000

Hi,

I have a few additional comments/questions regarding the CBOR encoding:

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.

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, perhaps it may simetimes be
   useful to be able to correctly interpret the values without using a
   schema.

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.

Lada

Michel Veillette <Michel.Veillette@trilliantinc.com> writes:

> For those interested to the development of the "CBOR Encoding of Data Modeled with YANG" draft. 
>
> The current document is available at:
> https://core-wg.github.io/yang-cbor/ 
>
> Proposed changes to the Reference, Introduction and Security Considerations sections are available at:
> https://github.com/core-wg/yang-cbor/pull/2/files
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C