Re: [core] CBOR Encoding of Data Modeled with YANG
Andy Bierman <andy@yumaworks.com> Wed, 09 December 2015 19:45 UTC
Return-Path: <andy@yumaworks.com>
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 693221A19F8 for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 11:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=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 SoIGWNY3CwGT for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 11:44:57 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12031A1A03 for <core@ietf.org>; Wed, 9 Dec 2015 11:44:55 -0800 (PST)
Received: by lfdl133 with SMTP id l133so41779489lfd.2 for <core@ietf.org>; Wed, 09 Dec 2015 11:44:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CmFqtEFdxMtqsi/Tu0oYB2z+wnzonz4g/+BN1PQrhu0=; b=GcTTmGSXjhQTHA3LsEQ/R44/Qtr890OWTwbmFwW/Tlk6PWsfxc3osdDsKmNZEakx6U VRKRom03TDZrMKtQ6AWaBy4biM5559f1hy+nSsvpudbv7X4/AKk9isLb5sPMlUknt/iA J5zyob3xMR2Ug0V2Hkf6yhJbl5CWyaaNYbX/T5NRaerhpC3tbRRqZYOjT8Feagsy3mB1 TJavQAa8b9SSSrDdbBNsTXg4Ullpg1dYOB1WYShH5T1stPPtTwX9JydO6aoalhX0OaSs l8Bl8lcacDPwQ4dJkt26Zu59xgTNaooOosYHD56sQ9T1ndKvoa3XsWiTkiU4gdm27rGb V/0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CmFqtEFdxMtqsi/Tu0oYB2z+wnzonz4g/+BN1PQrhu0=; b=SxKUpwK4grAg1igNbfCvgM9z+WM2sr0KzKp5twqa2p72sPHgMQeXb1l72VHAjnKSxN Iw76hs+RTL3A3ZqcfWr11I01ImcoAN87Q/T3JjHrMuMnETmaaOJ3ib7FOHrTtx9cF3Ug mAVsN7baYe6acINBC3g23U9hA9C52YTBYU9apx93Y8ILjfwQCAxxw/kU7pHp8UGsYK74 bb0PS77FdOlwTCpxvqx0MZKKLPWAulgPPPKCjcSM7/Ikvz4/CrYa7xTolFqbUzV5BjIV htrST3vB/a+3o98PORLOJ+PylXYDg8RzeHpWkvreLX2r+dubcI8v8Our3JU+8JiLyDCC uUrg==
X-Gm-Message-State: ALoCoQk+/Js+TmvV1c/TYepA7ziKSLqT2XGWIPKFW1+fCQMcT0gfErT0NyF6J5T8M9Qd22Y4asrQbvAFX6+ZNEYHMOxAR7ItJQ==
MIME-Version: 1.0
X-Received: by 10.25.35.194 with SMTP id j185mr3422171lfj.62.1449690293784; Wed, 09 Dec 2015 11:44:53 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 9 Dec 2015 11:44:53 -0800 (PST)
In-Reply-To: <BLUPR06MB1763392BE08C23ECFC05EDA0FEE80@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <BLUPR06MB176391F16B5E9D6CCC531771FE0E0@BLUPR06MB1763.namprd06.prod.outlook.com> <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> <m28u55lz0g.fsf@birdie.labs.nic.cz> <BLUPR06MB1763F77EC35C38FE64265C73FE080@BLUPR06MB1763.namprd06.prod.outlook.com> <m2io48ox1m.fsf@birdie.labs.nic.cz> <BLUPR06MB17639FD1577077587EC75CBBFEE80@BLUPR06MB1763.namprd06.prod.outlook.com> <CABCOCHQbEOJT-XEpTrbWN7rSOSmcgcPhcgqafAReKm2VVCZing@mail.gmail.com> <BLUPR06MB1763392BE08C23ECFC05EDA0FEE80@BLUPR06MB1763.namprd06.prod.outlook.com>
Date: Wed, 09 Dec 2015 11:44:53 -0800
Message-ID: <CABCOCHRkLFdasj0c_3qy1Pn+HFqcH+bD4Ncz4vvnqmp01dAmvQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Content-Type: multipart/alternative; boundary="001a113a9f04fef9ee05267c5210"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/4Hexwyajs3hnO2Zukxm5V3kUW9I>
Cc: "core@ietf.org" <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: Wed, 09 Dec 2015 19:45:02 -0000
Hi, Let's say version 1 of module 42 has 1 object /B leaf B { type int32; } Seems like it's order will be 1 in version 1. Now in version 2, leaf /A is added. leaf B { type int32; } leaf A { type int32; } Now /B is #2 in the sort order, and #1 is now assigned to /A Andy On Wed, Dec 9, 2015 at 10:39 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > New objects can be added to the list but the order stay the same. > > Why this won’t be the case? > > > > Regards, > > Michel > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* December-09-15 1:31 PM > *To:* Michel Veillette <Michel.Veillette@trilliantinc.com> > *Cc:* Ladislav Lhotka <lhotka@nic.cz>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>; core@ietf.org > *Subject:* Re: [core] CBOR Encoding of Data Modeled with YANG > > > > Hi, > > > > Doesn't alphabetical sort mean the order will change for every revision > > of the module? > > > > > > Andy > > > > > > On Wed, Dec 9, 2015 at 10:20 AM, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > Hi Ladislav, Hi Juergen > > > > In order to address yesterday comments about the data node ID assignment > algorithm, > > I'm proposing the following changes to the algorithm defined in > > https://tools.ietf.org/html/draft-veillette-core-cool-00#section-6. > > > > Proposed changes: > > · IDs are assigned sequentially based on the schema tree sorted in > alphabetical ordered. > This guaranty that the same IDs are assigned independently of the order of > the statements > in definition file(s) and independently of the use of group(s) and > submodule(s). > > > > · All extensions proposed in the draft are removed > (cool:module-id, cool:id, ...) > Any extra information required by the assignment algorithm need to be > provided out of band. > This approach enables the use of any existing YANG modules without any > update of the definition file(s). > > > > · The algorithm should also support ID assignment of subsequent > version(s) > The ID generator (e.g. updated pyang) will produce an output file > containing the different IDs assigned. > This file will be provided as input to the ID generator for the subsequent > version of this YANG module. > This information will be used by the ID generator to preserve IDs already > assigned. > The ID generation should either generate a warning or reject a revised > module without an associated ID file. > > > > · import without revision will be rejected > The list of data nodes must be known and can't change over time to make > the algorithm unambiguous. > In this context, import of modules without revision can't be supported. > > > > For example: > > The schema tree of the YANG module > http://www.netconfcentral.org/modulereport/example-jukebox is as follow: > > > > *Object type* > > *Path* > > *YANG type* > > *Version * > > *ID* > > Data node > > /jukebox > > container > > 2014-07-03 > > Data node > > /jukebox/library > > container > > 2014-07-03 > > Data node > > /jukebox/library/artist > > list > > 2014-07-03 > > Data node > > /jukebox/library/artist/name > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album > > list > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/name > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/genre > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/year > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/admin > > container > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/admin/label > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/admin/catalogue-number > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/song > > list > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/song/name > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/song/location > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/song/format > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist/album/song/length > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/artist-count > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/album-count > > leaf > > 2014-07-03 > > Data node > > /jukebox/library/song-count > > leaf > > 2014-07-03 > > Data node > > /jukebox/playlist > > list > > 2014-07-03 > > Data node > > /jukebox/playlist/name > > leaf > > 2014-07-03 > > Data node > > /jukebox/playlist/description > > leaf > > 2014-07-03 > > Data node > > /jukebox/playlist/song > > list > > 2014-07-03 > > Data node > > /jukebox/playlist/song/index > > leaf > > 2014-07-03 > > Data node > > /jukebox/playlist/song/id > > leaf > > 2014-07-03 > > Data node > > /jukebox/player > > container > > 2014-07-03 > > Data node > > /jukebox/player/gap > > leaf > > 2014-07-03 > > Protocol operation > > /play > > rpc > > 2014-07-03 > > Input parameter > > /play/input/playlist > > leaf > > 2014-07-03 > > Input parameter > > /play/input/song-number > > leaf > > 2014-07-03 > > > > This schema tree is sorted and ID are assigned for each namespace. > > > > *Object type* > > *Path* > > *YANG type* > > *Version * > > *ID* > > Data node > > /jukebox > > container > > 2014-07-03 > > 1 > > Data node > > /jukebox/library > > container > > 2014-07-03 > > 2 > > Data node > > /jukebox/library/album-count > > leaf > > 2014-07-03 > > 3 > > Data node > > /jukebox/library/artist > > list > > 2014-07-03 > > 4 > > Data node > > /jukebox/library/artist/album > > list > > 2014-07-03 > > 5 > > Data node > > /jukebox/library/artist/album/admin > > container > > 2014-07-03 > > 6 > > Data node > > /jukebox/library/artist/album/admin/catalogue-number > > leaf > > 2014-07-03 > > 7 > > Data node > > /jukebox/library/artist/album/admin/label > > leaf > > 2014-07-03 > > 8 > > Data node > > /jukebox/library/artist/album/genre > > leaf > > 2014-07-03 > > 9 > > Data node > > /jukebox/library/artist/album/name > > leaf > > 2014-07-03 > > 10 > > Data node > > /jukebox/library/artist/album/song > > list > > 2014-07-03 > > 11 > > Data node > > /jukebox/library/artist/album/song/format > > leaf > > 2014-07-03 > > 12 > > Data node > > /jukebox/library/artist/album/song/length > > leaf > > 2014-07-03 > > 13 > > Data node > > /jukebox/library/artist/album/song/location > > leaf > > 2014-07-03 > > 14 > > Data node > > /jukebox/library/artist/album/song/name > > leaf > > 2014-07-03 > > 15 > > Data node > > /jukebox/library/artist/album/year > > leaf > > 2014-07-03 > > 16 > > Data node > > /jukebox/library/artist/name > > leaf > > 2014-07-03 > > 17 > > Data node > > /jukebox/library/artist-count > > leaf > > 2014-07-03 > > 18 > > Data node > > /jukebox/library/song-count > > leaf > > 2014-07-03 > > 19 > > Data node > > /jukebox/player > > container > > 2014-07-03 > > 20 > > Data node > > /jukebox/player/gap > > leaf > > 2014-07-03 > > 21 > > Data node > > /jukebox/playlist > > list > > 2014-07-03 > > 22 > > Data node > > /jukebox/playlist/description > > leaf > > 2014-07-03 > > 23 > > Data node > > /jukebox/playlist/name > > leaf > > 2014-07-03 > > 24 > > Data node > > /jukebox/playlist/song > > list > > 2014-07-03 > > 25 > > Data node > > /jukebox/playlist/song/id > > leaf > > 2014-07-03 > > 26 > > Data node > > /jukebox/playlist/song/index > > leaf > > 2014-07-03 > > 27 > > Input parameter > > /play/input/playlist > > leaf > > 2014-07-03 > > 1 > > Input parameter > > /play/input/song-number > > leaf > > 2014-07-03 > > 2 > > Protocol operation > > /play > > rpc > > 2014-07-03 > > 1 > > > > The previous ID file is provided as input of the next version to continue > the ID assignment. > > > > *Object type* > > *Path* > > *YANG type* > > *Version * > > *ID* > > Data node > > /jukebox > > container > > 2014-07-03 > > 1 > > Data node > > /jukebox/library > > container > > 2014-07-03 > > 2 > > Data node > > /jukebox/library/album-count > > leaf > > 2014-07-03 > > 3 > > Data node > > /jukebox/library/artist > > list > > 2014-07-03 > > 4 > > Data node > > /jukebox/library/artist/album > > list > > 2014-07-03 > > 5 > > Data node > > /jukebox/library/artist/album/admin > > container > > 2014-07-03 > > 6 > > Data node > > /jukebox/library/artist/album/admin/catalogue-number > > leaf > > 2014-07-03 > > 7 > > Data node > > /jukebox/library/artist/album/admin/label > > leaf > > 2014-07-03 > > 8 > > Data node > > /jukebox/library/artist/album/album-cover-art > > leaf > > 2015-12-09 > > 28 > > Data node > > /jukebox/library/artist/album/genre > > leaf > > 2014-07-03 > > 9 > > Data node > > /jukebox/library/artist/album/name > > leaf > > 2014-07-03 > > 10 > > Data node > > /jukebox/library/artist/album/song > > list > > 2014-07-03 > > 11 > > Data node > > /jukebox/library/artist/album/song/format > > leaf > > 2014-07-03 > > 12 > > Data node > > /jukebox/library/artist/album/song/length > > leaf > > 2014-07-03 > > 13 > > Data node > > /jukebox/library/artist/album/song/location > > leaf > > 2014-07-03 > > 14 > > Data node > > /jukebox/library/artist/album/song/name > > leaf > > 2014-07-03 > > 15 > > Data node > > /jukebox/library/artist/album/year > > leaf > > 2014-07-03 > > 16 > > Data node > > /jukebox/library/artist/country > > leaf > > 2015-12-09 > > 29 > > Data node > > /jukebox/library/artist/name > > leaf > > 2014-07-03 > > 17 > > Data node > > /jukebox/library/artist-count > > leaf > > 2014-07-03 > > 18 > > Data node > > /jukebox/library/song-count > > leaf > > 2014-07-03 > > 19 > > Data node > > /jukebox/player > > container > > 2014-07-03 > > 20 > > Data node > > /jukebox/player/gap > > leaf > > 2014-07-03 > > 21 > > Data node > > /jukebox/playlist > > list > > 2014-07-03 > > 22 > > Data node > > /jukebox/playlist/description > > leaf > > 2014-07-03 > > 23 > > Data node > > /jukebox/playlist/name > > leaf > > 2014-07-03 > > 24 > > Data node > > /jukebox/playlist/song > > list > > 2014-07-03 > > 25 > > Data node > > /jukebox/playlist/song/id > > leaf > > 2014-07-03 > > 26 > > Data node > > /jukebox/playlist/song/index > > leaf > > 2014-07-03 > > 27 > > Input parameter > > /play/input/playlist > > leaf > > 2014-07-03 > > 1 > > Input parameter > > /play/input/song-name > > leaf > > 2015-12-09 > > 3 > > Input parameter > > /play/input/song-number > > leaf > > 2014-07-03 > > 2 > > Notification > > /playing > > notification > > 2015-12-09 > > 1 > > Notification parameter > > /playing/song-name > > leaf > > 2015-12-09 > > 1 > > Notification parameter > > /playing/song-number > > leaf > > 2015-12-09 > > 2 > > Protocol operation > > /play > > rpc > > 2015-12-09 > > 1 > > > > This process is performed for each subsequent versions of the module. > > > > Regards, > > Michel > > > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: December-09-15 3:18 AM > > To: Michel Veillette <Michel.Veillette@trilliantinc.com>; Alexander Pelov > <a@ackl.io>; core@ietf.org > > Subject: RE: [core] CBOR Encoding of Data Modeled with YANG > > > > Michel Veillette <Michel.Veillette@trilliantinc.com> writes: > > > > > Hi Ladislav > > > > > > About "consecutive revisions of a module have the same definitions of > sibling data nodes ordered differently" > > > > > > I don’t see this case specifically addressed in RFC 6020 section 10. > > > > Section 12 says: In YANG, almost all statements are unordered. And section > 10 has these two bullets that provide a strong indication: > > > > o Any set of data definition nodes may be replaced with another set > > of syntactically and semantically equivalent nodes. For example, > > a set of leafs may be replaced by a uses of a grouping with the > > same leafs. > > > > o A module may be split into a set of submodules, or a submodule may > > be removed, provided the definitions in the module do not change > > in any other way than allowed here. > > > > Given that the order of siblings is explicitly unspecified for instance > documents (except RPCs), I think that swapping definitions of sibling leafs > has to be considered syntactically and semantically equivalent. > > > > > Andy seem to interpret the spec differently "Only the relative order of > nodes is maintained across revisions" > > > > > > If re-ordering of data nodes is allowed, we can fix this issue by > > > assigning IDs based on an alphabetically ordered schema tree. > > > > You can try this but it has to work reliably with module revisions, > augments and groupings. It is difficult because (unlike the MIB) a stable > order of siblings wasn't part of YANG design. > > > > Lada > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > >
- [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG weigengyu
- Re: [core] CBOR Encoding of Data Modeled with YANG Kepeng Li
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok