Re: [core] CBOR Encoding of Data Modeled with YANG

Andy Bierman <andy@yumaworks.com> Wed, 09 December 2015 18:31 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 B6A741A066C for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 10:31:15 -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 cgmDGW3_QvEt for <core@ietfa.amsl.com>; Wed, 9 Dec 2015 10:31:11 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 B38EB1B2C5E for <core@ietf.org>; Wed, 9 Dec 2015 10:31:00 -0800 (PST)
Received: by lbbkw15 with SMTP id kw15so35588353lbb.0 for <core@ietf.org>; Wed, 09 Dec 2015 10:30:58 -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=+64yvt/5VCtFderw3Ok2AGV7Z0Zen+itP96zGnPVjU0=; b=ap5OYD6X6V7ayipBwnLeAqMMphi+Di0aIH6HennVJpztMQUBrnnP3R0ZsxeiDACUIu Syl+AHPXQjAWj9extt9kuQE2NyVy5AlR4GJuPi74ZiuMsB8tkeV/MjCGIzwO0WKbTz15 BVL5MQkBrYQmMa0AjlTiAh7cEnF5809rHEjAXqzV1gNAf71X0rdmeXThDoVvCMiwgax1 rwlsSuabe1xUdYST3LemNYyRxr6ZaBtPO+LZLsi54zh6YIhZ5yjk1c5lmqQZIkt/Qm3w d6AifJO0YQVcVRakRnwiCGWlY8DiX4OTRWNh+qsWkJw7iZ2GyVsiQOrmyhUY8YmvoNJt u2GA==
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=+64yvt/5VCtFderw3Ok2AGV7Z0Zen+itP96zGnPVjU0=; b=FkAY+u76GEET1DPRptonBrWJLk2u5CU5htVFgakaP/292CKCxUYSXse7tIEiw9YA3D RMSSCQ7gLxDG3Z6/rYbaKliJv0O817f7e/Cs+L/iysaT7FXNIZcpJHp/kzTtatYVTPLQ hhK4k4C8iOpQoEVPmB/Pl3ugptjUyhkPbI/1XQIrN10gY7nOFSnbYhygJPOrX+Kh1l5u EbUegrdrZcJraYZW7HVoPROQVo47unlEV73v7N6TERoaymjhgFW9u4UOo8fjGb3aBZSY Io5eUuwDxmicKzf67PV5dL+0nW9CikRl4lSAZbSDG8uT4YoBWTpHNABQw0+Y0u6JzsX/ oZZQ==
X-Gm-Message-State: ALoCoQn9+TyMG6kASRAg7930eVMGXuHikf0XNW4+b2H4AVI5WfDjcEKDA1fEblxwXyHIWiJqDf1+qRiOi6spHGPI+I+3zrnZ1g==
MIME-Version: 1.0
X-Received: by 10.112.134.169 with SMTP id pl9mr3133549lbb.145.1449685858663; Wed, 09 Dec 2015 10:30:58 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 9 Dec 2015 10:30:58 -0800 (PST)
In-Reply-To: <BLUPR06MB17639FD1577077587EC75CBBFEE80@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>
Date: Wed, 09 Dec 2015 10:30:58 -0800
Message-ID: <CABCOCHQbEOJT-XEpTrbWN7rSOSmcgcPhcgqafAReKm2VVCZing@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Content-Type: multipart/alternative; boundary="089e011767e9a45d3105267b4aae"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/5OOeh2ngS-3IQdAAYzA0VwpyJ2o>
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:31:15 -0000

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