Re: [core] CBOR Encoding of Data Modeled with YANG
Michel Veillette <Michel.Veillette@trilliantinc.com> Wed, 09 December 2015 18:39 UTC
Return-Path: <Michel.Veillette@trilliantinc.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 1A8E61A877F for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 10:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.144
X-Spam-Level:
X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, 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 d57-_qGq7bda for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 10:39:46 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DA11A0031 for <core@ietf.org>; Wed, 9 Dec 2015 10:39:44 -0800 (PST)
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.337.19; Wed, 9 Dec 2015 18:39: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.0337.015; Wed, 9 Dec 2015 18:39:19 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: [core] CBOR Encoding of Data Modeled with YANG
Thread-Index: AdEtPHYWp5+Kr9OtQ0Oj//Irn0p12QDkrIIAAAzxqKAACR5VgAAAPE1QAAG37gAAAP5qIAAaFoAAAAGBWAAAC66EgAAJfYHQABj2foAADi0ysAAHO5oAAAA6byA=
Date: Wed, 09 Dec 2015 18:39:19 +0000
Message-ID: <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>
In-Reply-To: <CABCOCHQbEOJT-XEpTrbWN7rSOSmcgcPhcgqafAReKm2VVCZing@mail.gmail.com>
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-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:3LLVNtMrj+/O80cPfdR1UuzY9lMQCzsL/kdA+pgALpxBhm0exuSdialQXvuwDRBA7tYc43gkpfM65UKXyH7SCQgU/Bg2d07S+Wh6IpGVlftSSzO1kp7garpEdglE4Oy0dP8monQ4FQFcNsV6MwtiNQ==; 24:kf7A27xX2hXeb00KQ7zmC1nqK0saopWIKXPKdM9+Q4hwN9Y77ZX9REEiHTu0nHs6VmM/GnuM0m7BgyFoTXOGwZGJTSN142nkzW0g6Cf0S/0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764;
x-microsoft-antispam-prvs: <BLUPR06MB17640A70073C373B16C4C6D0FEE80@BLUPR06MB1764.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(256376046250027);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764;
x-forefront-prvs: 0785459C39
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(199003)(51444003)(377454003)(24454002)(189002)(13464003)(97736004)(92566002)(33656002)(74316001)(1096002)(102836003)(110136002)(5008740100001)(5004730100002)(790700001)(586003)(54356999)(50986999)(3846002)(76176999)(11100500001)(81156007)(86362001)(19580405001)(99286002)(10400500002)(66066001)(105586002)(19300405004)(106356001)(6116002)(101416001)(5001960100002)(40100003)(93886004)(1220700001)(122556002)(19580395003)(87936001)(19625215002)(2950100001)(77096005)(16236675004)(2900100001)(5003600100002)(19617315012)(76576001)(15975445007)(189998001)(5002640100001)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763392BE08C23ECFC05EDA0FEE80BLUPR06MB1763namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2015 18:39:19.7430 (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: <http://mailarchive.ietf.org/arch/msg/core/nf5NrPXgDx_O7CqUq6yOa19mRLQ>
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 18:39:54 -0000
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<mailto: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<mailto:lhotka@nic.cz>] Sent: December-09-15 3:18 AM To: Michel Veillette <Michel.Veillette@trilliantinc.com<mailto:Michel.Veillette@trilliantinc.com>>; Alexander Pelov <a@ackl.io<mailto:a@ackl.io>>; core@ietf.org<mailto:core@ietf.org> Subject: RE: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette <Michel.Veillette@trilliantinc.com<mailto: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<mailto: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