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