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

Carsten Bormann <cabo@tzi.org> Tue, 12 July 2016 16:01 UTC

Return-Path: <cabo@tzi.org>
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 C4E3912D1AE for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 09:01:07 -0700 (PDT)
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 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 4biG6NI09C6m for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 09:01:06 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A9A12D1BD for <core@ietf.org>; Tue, 12 Jul 2016 09:01:02 -0700 (PDT)
Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B87A441C0B8; Tue, 12 Jul 2016 18:01:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter39-d.gandi.net (mfilter39-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qa-_AsrIhqUW; Tue, 12 Jul 2016 18:00:59 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7DEBC41C0C0; Tue, 12 Jul 2016 18:00:57 +0200 (CEST)
Message-ID: <57851437.2070405@tzi.org>
Date: Tue, 12 Jul 2016 18:00:55 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> <BLUPR06MB176358F95C56C70A91ECB672FE300@BLUPR06MB1763.namprd06.prod.outlook.com>
In-Reply-To: <BLUPR06MB176358F95C56C70A91ECB672FE300@BLUPR06MB1763.namprd06.prod.outlook.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/f_JPYVZdBrH8TQKyt9gYIAB_qhM>
Cc: Alexander Pelov <alexander.pelov@telecom-bretagne.eu>, 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 16:01:08 -0000

Michel Veillette wrote:
> do you have a strong opinion about the approach proposed by Peter?

Actually I'm intrigued as to what that approach will be; until we know
that, I'd be a bit weary about moving things around.

So far, I have been quite happy with the parent delta approach, but I'm
not sure we have really succeeded in explaining it succinctly and
unambiguously.
For instance, what happens if a data structure is buried further into
another one that itself doesn't have a SID?

I'm not a big fan of specification-by-algorithm, but here it probably
*would* help to phrase this as an algorithm (preferably functional).
Cf. RFC 7396: The pseudo-code on page 4 really helps understanding the
obtuse language around it.

Given that the CBOR data model maps right into data structures that can
be addressed by pseudo code, specifying the "decoder" (as is usual for
compression algorithms) should be lean and precise.

Grüße, Carsten