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
>
>
>