IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Tue, 08 December 2015 17:26 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 216B11A0368 for <core@ietfa.amsl.com>; Tue, 8 Dec 2015 09:26:05 -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 jLG33yPr3Ve7 for <core@ietfa.amsl.com>; Tue, 8 Dec 2015 09:26:03 -0800 (PST)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7277D1A0102 for <core@ietf.org>; Tue, 8 Dec 2015 09:26:03 -0800 (PST)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 88463C5A53; Tue, 8 Dec 2015 18:26:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eOvctXT5CB4t; Tue, 8 Dec 2015 18:26:00 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id CD3F2C5A73; Tue, 8 Dec 2015 18:25:58 +0100 (CET)
Message-ID: <566712A4.7060900@tzi.org>
Date: Tue, 08 Dec 2015 18:25:56 +0100
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: <20151207091044.GA59864@elstar.local> <BLUPR06MB1763ABFE8DE1E0E18F5F06A5FE090@BLUPR06MB1763.namprd06.prod.outlook.com> <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> <5666D6D4.3090006@ackl.io> <CABCOCHSWb1p65UjKNVnn4nPLMqhmLnGyuDSxYZYhT5S5HWjkSA@mail.gmail.com> <BLUPR06MB17639C65F2BDBB8E1795DDBEFE080@BLUPR06MB1763.namprd06.prod.outlook.com>
In-Reply-To: <BLUPR06MB17639C65F2BDBB8E1795DDBEFE080@BLUPR06MB1763.namprd06.prod.outlook.com>
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/L-wAg-aOo_vd34hgXwgJjEkFPr0>
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: Tue, 08 Dec 2015 17:26:05 -0000

Michel Veillette wrote:
> About "YANG allows new nodes to be added anywhere."
> 
> The proposed algorithm require that those data nodes are manually
> assigned if they affect
> 
> already assigned IDs. 

Doesn't that mean we no longer can maintain the property that this
scheme can be applied to all the YANG modules out there?

(We can separately discuss whether we do need this property, but given
that it is a major selling point of the COMI approach, I would like to
know what approaches keep it and which ones don't.)

Grüße, Carsten

v2.29.0 | Report a Bug | By Email | System Status