Re: [core] YANG to CBOR mapping version 1
peter van der Stok <stokcons@xs4all.nl> Thu, 14 July 2016 15:39 UTC
Return-Path: <stokcons@xs4all.nl>
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 7714D12D0F9 for <core@ietfa.amsl.com>; Thu, 14 Jul 2016 08:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 3hB8hKWc1QiY for <core@ietfa.amsl.com>; Thu, 14 Jul 2016 08:39:51 -0700 (PDT)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806BE12D0BB for <core@ietf.org>; Thu, 14 Jul 2016 08:39:51 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id Jffp1t00Y4WfiVN01ffpkS; Thu, 14 Jul 2016 17:39:50 +0200
Received: from 2001:983:a264:1:4563:dcea:23df:e56a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 17:39:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 14 Jul 2016 17:39:49 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <BLUPR06MB176328C63F415719D140489BFE320@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com> <e18f0f45bfae89fc55df444fdd957550@xs4all.nl> <BLUPR06MB17638EB4CCB4235B5101D540FE300@BLUPR06MB1763.namprd06.prod.outlook.com> <d58ca58bd8f89b9856a2e23290a18ba8@xs4all.nl> <BLUPR06MB1763A212CD1C3386722B88D9FE310@BLUPR06MB1763.namprd06.prod.outlook.com> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl> <BLUPR06MB1763D6B8ADAE036D5E63FBA3FE310@BLUPR06MB1763.namprd06.prod.outlook.com> <43805298839959a534d83c720ac6239c@xs4all.nl> <BLUPR06MB176328C63F415719D140489BFE320@BLUPR06MB1763.namprd06.prod.outlook.com>
Message-ID: <8a6ece7e540f02c064c8d638b2d83463@xs4all.nl>
X-Sender: stokcons@xs4all.nl (tESzVuV9u4rSpl/inKNdSKHHp//Qa6k6)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7qLAIzvHMOOHc2GkiglFl8pSABk>
Cc: Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR mapping version 1
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 14 Jul 2016 15:39:53 -0000
Hi Michel, > In this case, you propose to add more meta data than > "draft-ietf-netmod-yang-json" > which don't share the same limitations on the payload size. > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 I don't think extra meta-data is needed (depending on your definition of meta-data) > > Regards, > Michel Greetings, Peter > > > -----Original Message----- > > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday, July 14, 2016 3:57 AM > To: Michel Veillette <Michel.Veillette@trilliantinc.com> > Cc: consultancy@vanderstok.org; Core <core@ietf.org> > Subject: RE: [core] YANG to CBOR mapping version 1 > > Hi Michel, > > IMO, an error is an error and should be treated as such. Trying to > salvage unhealthy situations leads to worse problems. > > My approach would be that servers and clients are simple and don't > need to parse the yang modules during operation; and keep extensive > state information about each other. > > The discussion seems to confirm my growing conviction that the CoMI > and CoOL approaches are fundamentally different. > > Peter > > Michel Veillette schreef op 2016-07-13 19:06: >> Hi Peter >> >> I'm not convinced that Including in the encoding which data nodes are >> the keys completely solve the issue. >> If the client transmit a payload with one key and the server required >> two keys, the payload will be rejected. >> If the client transmit a payload with two keys (marked as such) and >> the server require one key, the payload will be rejected. >> To work, both sides need to known the number of keys used by the other >> side and only 'ietf-cool-library' can resolve that. >> >> Also, not making which data nodes are keys might help during the >> migration. >> >> Regards, >> Michel >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Wednesday, July 13, 2016 12:55 PM >> To: Michel Veillette <Michel.Veillette@trilliantinc.com> >> Cc: consultancy@vanderstok.org; Core <core@ietf.org> >> Subject: RE: [core] YANG to CBOR mapping version 1 >> >> Hi Michel, >> >> That looks pretty complex to me; while the keys can be elegantly >> expressed in the CBOR contents. >> >> Peter >> >> Michel Veillette schreef op 2016-07-13 16:36: >>> Hi Peter >>> >>> The scenario you described is part of the generic discovery problem. >>> To perform its tasks, clients typically need to known the list of >>> modules, features, deviations implemented by a server and associated >>> versions. >>> This problem is addressed in >>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library- >>> l >>> atest.html >>> which is the constrained version of >>> https://datatracker.ietf.org/doc/rfc7895/ >>> >>> module: ietf-cool-library >>> +--ro modules-state >>> +--ro module-set-id union >>> +--ro module* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> +--ro feature* sid >>> +--ro deviation* [sid revision] >>> | +--ro sid sid >>> | +--ro revision revision >>> +--ro conformance-type enumeration >>> +--ro submodules >>> +--ro submodule* [sid revision] >>> +--ro sid sid >>> +--ro revision revision >>> notifications: >>> +---n yang-library-change >>> +--ro module-set-id -> /modules-state/module-set-id >>> >>> Regards >>> Michel >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Wednesday, July 13, 2016 2:34 AM >>> To: Michel Veillette <Michel.Veillette@trilliantinc.com> >>> Cc: consultancy@vanderstok.org; Core <core@ietf.org> >>> Subject: RE: [core] YANG to CBOR mapping version 1 >>> >>> Hi Michel, >>> >>> When a specification changes it set of of keys, I don't think the >>> SIDs will change. >>> It is for sure that the hashes are not affected by the attribution of >>> a key. >>> >>> Therefore, what happens when client and server use different keys in >>> otherwise identical list specification? >>> >>> Peter >>> >>> Michel Veillette schreef op 2016-07-12 17:07: >>>> Hi Peter >>>> >>>> The validations performed by the entity which de-serialize the CBOR >>>> payload is based on the YANG schema. >>>> This validation is based on all king of YANG statements such as: >>>> key, unique, range, pattern, length, min-elements, max-elements, >>>> must, when, if-feature >>>> >>>> The identification of which data nodes are keys is considered >>>> unnecessary meta-data since available in the schema. >>>> Even more heavy weight representations such as xml and json don't >>>> include this meta-data in the encode payload. >>>> >>>> Regards, >>>> Michel >>>> >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Tuesday, July 12, 2016 6:08 AM >>>> To: Michel Veillette <Michel.Veillette@trilliantinc.com> >>>> Cc: consultancy@vanderstok.org; Core <core@ietf.org> >>>> Subject: RE: [core] YANG to CBOR mapping version 1 >>>> >>>> Hi Michel, >>>> >>>>> >>>>> However, I am missing how to transport a given list instance with >>>>> its key values in the CBOR encoding. Section 4.4 describes the >>>>> encoding of a complete list not a subset of its instances. >>>>> >>>>> [MV] A list instance is a collection which is described in section >>>>> 4.2. >>>>> ___________________________________________________________________ >>>>> _ >>>>> _ >>>>> _ >>>>> _______________________ >>>> >>>> With the current text I don't see how you distinguish instances with >>>> the same key from instances with different keys. >>>> >>>> Example: >>>> >>>> list server { >>>> key name; >>>> >>>> leaf name { >>>> type string; >>>> } >>>> leaf iburst { >>>> type boolean; >>>> default false; >>>> } >>>> >>>> How to distinguish that in the list below that two instances are >>>> identical (should not occur) >>>> [ >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : false, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ] >>>> >>>> And the following two instances are different (valid array) >>>> >>>> [ >>>> { >>>> 1755 : "NRC TAC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> }, >>>> { >>>> 1755 : "NRC TIC server", # name (SID 1755) >>>> 1754 : true, # iburst (SID 1754) >>>> } >>>> ]
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Andy Bierman
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Alexander Pelov
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR , identification of objec… peter van der Stok
- Re: [core] YANG to CBOR , identification of objec… Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Alexander Pelov
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR , identification of objec… Carsten Bormann
- Re: [core] YANG to CBOR , identification of objec… Alexander Pelov
- Re: [core] YANG to CBOR , identification of objec… Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Paul Duffy
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Alexander Pelov
- Re: [core] YANG to CBOR mapping version 1 Michel Veillette
- Re: [core] YANG to CBOR mapping version 1 Carsten Bormann
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR , identification of objec… peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok
- Re: [core] YANG to CBOR mapping version 1 Alexander Pelov
- Re: [core] YANG to CBOR mapping version 1 peter van der Stok