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

[Ladislav Lhotka <[e-mail]>]

> On 08 Dec 2015, at 17:29, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Tue, Dec 8, 2015 at 7:51 AM, Ladislav Lhotka <[e-mail]> wrote:
> Alexander Pelov <[e-mail]> writes:
> 
> > Dear Juergen,
> >
> > The algorithm is straightforward - assign in increasing order a data
> > node ID to each element on the schema tree. If you have a revision of a
> > module, you do the diff between the old and the new tree, and add the
> > new data node IDs at the end of the numbering.
> 
> IMO this is not going to work: sibling data nodes do not have any
> fixed order. Different tools may print the tree in different ways, and
> it is also possible that consecutive revisions of a module
> have the same definitions of sibling data nodes ordered differently.
> 
> I'd suggest to use a hash of the schema node identifier as the numeric ID.
> 
> 
> This is what the CoMI draft does.
> The instance-identifier encoding in your YANG-to-JSON draft is used
> (except there will be no predicates in a schema-node identifier)

Instance identifiers also don't include non-data nodes such as "choice" or "case". I am not sure whether they would needed here or not. 

> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#section-6.11
> 
> The JSON instance-identifier is needed instead of XML because YANG prefixes can change
> over time (as clarified in YANG 1.1).  Your encoding only relies on module names
> which are never allowed to change, and it is also simpler to code.

There is still some uncertainty due to module revisions that cannot be specified this way.

Lada

> 
> 
> Lada
> 
> 
> Andy
>  
> >
> > If you want a short version that would allow you to play with this
> > numbering, try the following:
> >
> > Data Node ID generation for a module YANG_MODULE:
> > *# pyang -f tree YANG_MODULE.yang | grep '+' | grep -n '+'
> >
> > *pyang -f tree YANG_MODULE-OLD-VERSION.yang >> OLD-VERSION.tree
> > pyang -f tree YANG_MODULE-NEW-VERSION.yang >> NEW-VERSION.tree
> > *# ( cat **OLD-VERSION.tree ; diff **OLD-VERSION.tree **NEW-VERSION.tree
> > ) | grep '+' | grep -n '+'*
> > *
> > *I'm currently working on a pyang version of the algorithm. There is no
> > problem on that point. We cannot produce all documents in the same time,
> > and the starting point is YANG-CBOR mapping. *
> >
> > *Best,
> > Alexander
> >
> >
> > Le 08/12/2015 10:33, Juergen Schoenwaelder a écrit :
> >> Hi Michel,
> >>
> >> I am looking for a precise description of the _algorithm_, I am not so
> >> much looking for an example. Has someone implemented this numbering
> >> algorithm in pyang and verified that the algorithm always produces the
> >> same data node ids for all the possible changes I can make to a YANG
> >> model? See section 10 of RFC 6020 as a starting point what is allowed
> >> to change in module revisions. See also section 11 of
> >> draft-ietf-netmod-rfc6020bis-08.txt.
> >>
> >> /js
> >>
> >> On Mon, Dec 07, 2015 at 09:31:37PM +0000, Michel Veillette wrote:
> >>> Hi Juergen
> >>>
> >>> The algorithm proposed to generate IDs  is described in
> >>> https://tools.ietf.org/html/draft-veillette-core-cool-00#section-6.
> >>>
> >>> - IDs are assigned based on there location in the schema tree.
> >>>
> >>> - Each type of object (Data node IDs, Notification IDs, Notification parameter IDs,
> >>>     Protocol Operation IDs, Input parameter IDs, Output parameter IDs)
> >>>     have a different namespace.
> >>>
> >>>     This approach help keeping the same IDs  when updating a module.
> >>>     New objects can be added at the end of each list without affecting the existing IDs.
> >>>
> >>> - When an object is added within a list or within the schema tree, its ID can be
> >>>     manually assigned using a YANG extension to avoid braking backward compatibility.
> >>>     Alternatively, data nodes can be added using the augment statement.
> >>>     In this case, IDs are associated to a different module ID.
> >>>
> >>>    https://tools.ietf.org/html/draft-veillette-core-cool-00#section-7.3 show an
> >>>    example of use of the augment statement, see data node ID 68620 bellow.
> >>>
> >>>     CoAP response:
> >>>       2.05 Content Content-Format(application/cbor)
> >>>       {
> >>>         66560 : {
> >>>           1 : {
> >>>             2 : [
> >>>               {
> >>>                 3 : "eth0",
> >>>                 4 : "Ethernet adapter Local Area Connection",
> >>>                 5 : "ethernetCsmacd",
> >>>                 6 : true,
> >>>                 68620 : {
> >>>                   13 : true,
> >>>                   14 : true,
> >>>                   15 : 1280,
> >>>                   16 : [
> >>>                     {
> >>>                       17 : "fe80::200:f8ff:fe21:67cf",
> >>>                       18 : 10
> >>>                     }
> >>>                   ]
> >>>                 }
> >>>               }
> >>>             ]
> >>>           }
> >>>         }
> >>>       }
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Juergen Schoenwaelder [mailto:[e-mail]]
> >>> Sent: December-07-15 3:38 PM
> >>> To: Michel Veillette <[e-mail]>
> >>> Cc: Core <[e-mail]>
> >>> Subject: Re: [core] CBOR Encoding of Data Modeled with YANG
> >>>
> >>> On Mon, Dec 07, 2015 at 08:31:03PM +0000, Michel Veillette wrote:
> >>>> Hi Juergen
> >>>>
> >>>> My "smart" quote are now disabled.
> >>>> Thanks to motivate me to turn off this nonsense.
> >>>>
> >>>> About the format/assignment of the numeric data node IDs, the consensus is to keep them out of the YANG to CBOR mapping draft in order to make progress.
> >>>>
> >>> But this does not make sense. The naming must be settled, even if it is painful.
> >>>
> >>>> Peoples agree that names encoded as string represents too much overhead to address the needs of constrained devices and constrained networks as defined by RFC 7228. However, there are lots of discussions about how those names can be associated with small IDs encoded as integers and how small those integers need to be.
> >>>>
> >>>> The CoOL draft proposes structured IDs based on the following concept:
> >>>>
> >>>>     Only IDs  associated with module names are registered, IDs associated to data node identifiers are automatically generated.
> >>>>
> >>>>     e.g. draft-ietf-netmod-yang-json-06 page 5
> >>>>     for the member-name "foomod:top"
> >>>>     the ID associated with the name of the module "foomod" is registered,
> >>>>     the ID associated with the data node identifier "top" is auto-generated.
> >>> How do you auto-generate data node identifiers? Does the algorithm work with module revisions, augmentations, features, ...?
> >>>
> >>>> To simplify scaling of the registered module names, different approaches have been proposed:
> >>>> - Possibility to allocation ranges of IDs (bundle) to developers and SDOs for distributed assignment.
> >>>> - Possibility to define a range of private IDs (IDs locally assigned
> >>>> and used, not globally unique, same concept as IPv4 10.x.x.x)
> >>>> - Possible to define disjoint registries, implemented using a
> >>>> different resource type & default URI path
> >>> I need to understand the algorithm for assigning data node identifiers first to see whether this approach makes sense.
> >>>
> >>> /js
> >>>
> >>> --
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > core mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C