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

peter van der Stok <stokcons@xs4all.nl> Wed, 09 December 2015 08:55 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 3850C1B2A7F for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 00:55:28 -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 e6jqnbAQ6gvB for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 00:55:25 -0800 (PST)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976CA1B2A7D for <core@ietf.org>; Wed, 9 Dec 2015 00:55:23 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud3.xs4all.net with ESMTP id rLvL1r00F4aYjWA01LvLB5; Wed, 09 Dec 2015 09:55:21 +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 09:55:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Wed, 09 Dec 2015 09:55:20 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Andy Bierman <andy@yumaworks.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <CABCOCHRnojCtSfAKYsDjy5mNygco=3Kj5QMN6r=6-efKWiyYGA@mail.gmail.com>
References: <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> <5666D6D4.3090006@ackl.io> <20151208140158.GA21630@elstar.local> <5666EF1F.6090204@ackl.io> <20151208151402.GA21810@elstar.local> <CABCOCHRnojCtSfAKYsDjy5mNygco=3Kj5QMN6r=6-efKWiyYGA@mail.gmail.com>
Message-ID: <aa16626dd11ae62fedf95c2cfd1f3d9d@xs4all.nl>
X-Sender: stokcons@xs4all.nl (6YqdQ9epqxDg45WOGzesn8p9hhrKp5wY)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/iYhDy0IMtB171Cw_0j9ZWODgTx4>
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
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 08:55:28 -0000

Hi Juergen,

Can we concentrate on the YANG to CBOR mapping and the representation of 
the YANG names?
Can you explain to me where the problem lies exactly?
If the YANG to CBOR mapping (Y2C) depends on the n bit representations 
of the YANG names, we have interesting consequences for 
inter-operability.
In my opinion a Y2C mapping should include YANG name strings and their n 
bit identifiers because they will both be present; although not in the 
same payload.

Peter

Andy Bierman schreef op 2015-12-08 16:48:
> On Tue, Dec 8, 2015 at 7:14 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> wrote:
> 
>> On Tue, Dec 08, 2015 at 03:54:23PM +0100, Alexander Pelov wrote:
>>> Le 08/12/2015 15:01, Juergen Schoenwaelder a écrit :
>>>> On Tue, Dec 08, 2015 at 02:10:44PM +0100, Alexander Pelov wrote:
>>>>> Dear Juergen,
>>>>> 
>>>>> Thanks for the great remarks! Indeed, we have had lots of
>> lengthy
>>>>> discussions on the way structured data node IDs work, and there
>> are
>>>>> several ways to handle the situations you describe.
>>>>> 
>>>>> We've reached a consensus to first detail the most demanded and
>> least
>>>>> controversial part - the YANG-CBOR mapping. Having structured
>> data node
>>>>> IDs allows for all existing designs to operate with this.
>>>> Who is 'we'?
>>> The WG during the last IETF, and the main contributors to the CoMI
>> and
>>> CoOL drafts.
>> 
>> For me, a YANG to CBOR mapping without a definition how names are
>> represented in CBOR is incomplete, not interoperable, and hence not
>> a useful result. Hard problems are not solved by pushing them
>> around.
> 
> +1
> 
> I do not think the CoMI authors agree that managed IDs will work.
> The technical issues with YANG have not been addressed.
> 
>> /js
> 
> Andy
> 
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>> Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core