IETF Logo Mail Archive

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

Michel Veillette <Michel.Veillette@trilliantinc.com> Tue, 12 July 2016 16:29 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
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 E5B2612D559 for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 09:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
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 zGsQjwoi3XMQ for <core@ietfa.amsl.com>; Tue, 12 Jul 2016 09:29:27 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB1412D548 for <core@ietf.org>; Tue, 12 Jul 2016 09:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2yDhJj41H+cnKWyhah2AVGdN6BCryi+uDaCP/J/8Jak=; b=lkDuLHGbhbcJGg2NkbFifLFqt6wO0Vzjq57bz+4/32mrHZP0gwZ81Jtu9M318mxvYxBXHDS7tyx4tFuAzI5uStzsu3pt/6WE00Zjw1CUQr+YRToaIhzeZkMVDrbVPz51mmU7rqUb1D90wjZpb2LMyoKnhjNjkNG0NJnvupKtDVE=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 16:29:19 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 16:29:19 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Carsten Bormann <cabo@tzi.org>
Thread-Topic: [core] YANG to CBOR , identification of objects
Thread-Index: AQHR3Ca9mBIkuJzWoUeQAVKUrHr926AU6aiQgAALL4CAAATzQA==
Date: Tue, 12 Jul 2016 16:29:19 +0000
Message-ID: <BLUPR06MB17639F91DFFBE299A695DA30FE300@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com> <0ab68685ab75d14335cb130faa1f5722@xs4all.nl> <BLUPR06MB176358F95C56C70A91ECB672FE300@BLUPR06MB1763.namprd06.prod.outlook.com> <57851437.2070405@tzi.org>
In-Reply-To: <57851437.2070405@tzi.org>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: 0d10bc2a-f650-4829-0924-08d3aa71ac99
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:RJwvoMSb62U637AKyofw11xeOeoEY+KNkjudvP+aSksbULze1nqK/VntFvVV5eCL8esqqcDyAU9ZzDYsJ6aRjFyVGtE1QzsjAI8KuACySy7jnBuQg9+LxMA2FdwS9x7m6y2VhANxdJHDpTYMyFoDw+TEZK4sCerMJ8n+DBcPuyxLI5+LEs0Igd7wA8bWdlqP/BcchSfCpR3HeQLUBHxpehTKlN09CU97nMKWzski3V8kWNGTxAzD5BhR52kzdX/GDSe21CGKqjUE0EF24De3MjpdHhP5MEF+J3DRCtvc/9A=; 5:rJuEKQori3l5qeW4eo09tjO5Otb3hXWGE50ooOJDBsRIp0ccV/HI2vtWh2GD8K0A03n9T+HFBMwVO4fY/rD8yC+9TXX1stoG4wUrYowq35T8OkB5meY9DMzP3gaYXYNAPUjfoXsPlrdaLM7g9LLYlQ==; 24:jJY5VySSxXOLWz1q68vPf+gJ9eyi12iI3nsOXWkjkH3y3+xyiHX3iLt/md0qXtlQjbqNNnc1chBkVBXh4kOUWRvJk7/slxU1bkUWAqwXD2Q=; 7:nNH8kuQu/nFSVI1+3OOvz6bGF40nKSPTWKMWiKrM/7lfiASrFQ9aJvyRvreUBWrPjRZydvsEXY8mSYr2bCfQ6LzK1ujkYYJb5oIA7LUhbrWiUApjRo9fOn647rpbtk3C3TZq+fpc3mLsZN+kHvU5Nv7vftzFqLaCUyYKxmz7DOPakLIW/2HkLMkXq73ALWZbNGovFZKY5W9V9ERkPnZ6FnWjMukqPmQHZH+k5j3YYUE+BEPtc3nNi9fl28B4B5jp
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764;
x-microsoft-antispam-prvs: <BLUPR06MB17645F2FB631E9DC18AC7C67FE300@BLUPR06MB1764.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(13464003)(199003)(10400500002)(33656002)(8676002)(86362001)(8936002)(105586002)(11100500001)(87936001)(66066001)(81156014)(81166006)(189998001)(110136002)(97736004)(5003600100003)(7846002)(7736002)(7696003)(50986999)(76176999)(74316002)(68736007)(19580405001)(6116002)(305945005)(76576001)(54356999)(99286002)(101416001)(3846002)(9686002)(15975445007)(102836003)(2950100001)(5002640100001)(586003)(2900100001)(19580395003)(77096005)(93886004)(3660700001)(92566002)(106116001)(106356001)(3280700002)(2906002)(4326007)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 16:29:19.0996 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wEfC9n6hjUcibMRTPpNtkoTwzk0>
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:29:29 -0000

Hi Carsten

About " is buried further into another one that itself doesn't have a SID".

No sure what do you means by "doesn't have a SID".
Do you means that the associated SID is encoded as a delta?

Each data node is associated to a SID.
SIDs of data node children are encoded using a delta from the parent SID (independently if this parent SID in also encoded as a delta).
The example https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.1 should be enhanced to show thiscase.
The description can also be enhanced, I'll check what I can do for the algorithm.

(Carsten) Do you have an example of a similar type of algorithm (serialization) to share?

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: Tuesday, July 12, 2016 12:01 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: consultancy@vanderstok.org; Alexander Pelov <alexander.pelov@telecom-bretagne.eu>; Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR , identification of objects

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

v2.23.0 | Report a Bug | By Email