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

peter van der Stok <stokcons@xs4all.nl> Wed, 09 December 2015 09:21 UTC

Return-Path: <stokcons@xs4all.nl>
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 988401B2AB8 for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 01:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 NciGIjN09nw9 for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 01:21:29 -0800 (PST)
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 5230A1B2AB7 for <core@ietf.org>; Wed, 9 Dec 2015 01:21:29 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud3.xs4all.net with ESMTP id rMMT1r00D4aYjWA01MMTrW; Wed, 09 Dec 2015 10:21:27 +0100
Received: from 2001:983:a264:1:5915:b32c:8ab0:a979 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 Dec 2015 10:21:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 09 Dec 2015 10:21:27 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Carsten Bormann <cabo@tzi.org>, core@ietf.org
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <20151208130943.GA65029@elstar.local>
References: <20151207194229.GA61491@elstar.local> <BLUPR06MB1763B7F9EBF812C06DB04252FE090@BLUPR06MB1763.namprd06.prod.outlook.com> <20151207203826.GA61647@elstar.local> <BLUPR06MB1763E9AB0D1E4A0478D47C05FE090@BLUPR06MB1763.namprd06.prod.outlook.com> <20151208093350.GA62650@elstar.local> <5666AE1A.2040908@ackl.io> <20151208105530.GA62785@elstar.local> <64B950CF-863D-4440-AF7A-F8DF79C80409@telecom-bretagne.eu> <20151208115310.GA62928@elstar.local> <5666CE50.90008@tzi.org> <20151208130943.GA65029@elstar.local>
Message-ID: <8738f0165f4ab11aedb015df417ab59a@xs4all.nl>
X-Sender: stokcons@xs4all.nl (Aja6dAY+f+VfH5l82lxok3957hxOscGg)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/UmsVM874av9ADZljQWjtgaRP5Zs>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 09 Dec 2015 09:21:31 -0000

Hi Juergen, see below.

Juergen Schoenwaelder schreef op 2015-12-08 14:09:

>> 
>> One discussion we haven't had is whether we can combine COMI-style
>> identifier hashing as the general solution with optional use of 
>> manually
>> managed identifiers.  This would give us the coverage of "any item 
>> from
>> any YANG module" that we would like to have, but still provide the
>> opportunity for more optimization in specific modules that can benefit
>> from tighter representation (including the external/internal 
>> identifier
>> split), which we might be able to subject to a tighter development 
>> regime.

I think this is certainly worth looking into.

>> 
> 
> I prefer one solution instead of multiple solutions. I think we should
> try to understand the pros/cons of the various possible solutions and
> try to take an informed decision.
> 
> The solution space is even bigger than the two proposals on the table.
> For example, an implementation could simply use locally assigned data
> node IDs and publish a dictionary mapping names to data node ids. Yes,
> there are downsides with this as well. (Or, as a variation, you
> include the dictionary in the encoding, then it looks a bit like
> compression.)
> 
> So far, the decision tree I have in my mind roughly looks like this:

The decision tree looks very much to what's in my mind.
Agreeing on the measures to compare them is another matter:
- Size of identifiers coupled to when is reduction from n to m bits 
worth while the overhead
- Exception space and counter measure overhead
- Run-time overhead
- number of repositories and their sizes
- and probably others.

> 
> a) use identifier strings (+simple, -verbose)
> b) use data node identifiers (-more complex, +compact)
>    b1) derive data node identifiers algorithmically from YANG data 
> models
>        (-might be tricky in certain cases)
>    b2) use a hash algorithm to derive data node identifiers from the 
> set of
>        announced YANG data models
>        (-need to deal with hash collisions, slightly larger numbers)
>    b3) use locally assigned data node identifiers and provide a 
> cachable
>        mapping dictionary
>        (-different data node identifiers for each device, data without
>          dictionary is meaningless)

> 
> /js

Peter