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

From: Michel Veillette <[email-masked]>
Date: Wed, 2 Dec 2015 20:08:49 +0000

For those interested to the development of the "CBOR Encoding of Data Modeled with YANG" draft. 

The current document is available at:
https://core-wg.github.io/yang-cbor/ 

Proposed changes to the Reference, Introduction and Security Considerations sections are available at:
https://github.com/core-wg/yang-cbor/pull/2/files

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2015 10:10:46 +0100

A few notes:

- The document talks about a 'node ID' in several places but never
  defines this concept nor does it explain how these node IDs are
  created.

- Your ID should normatively depend on YANG 1.1 and cover all the YANG
  1.1 constructs, that is, include anydata.

- I am not sure I understand the anyxml encoding.

- I guess I am having an issue with yet another ad-hoc namespace
  notation invention in 3.1.7. YANG type: identityref. Why not use the
  <module>:<identifier> notation used by the JSON encoding?

- The document confuses YANG types and YANG data node definition
  statements. I suggest to follow the structure of
  draft-ietf-netmod-yang-json-06.txt.

/js

On Wed, Dec 02, 2015 at 08:08:49PM +0000, Michel Veillette wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 7 Dec 2015 17:48:14 +0800

Hi Juergen,

There had been a draft about "Node ID“, CoAP Option Extension: NodeId,
draft-li-core-coap-node-id-option-02.
It was expired June 19, 2015.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Juergen Schoenwaelder
Sent: Monday, December 07, 2015 5:10 PM
To: Michel Veillette
Cc: Core
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

A few notes:

/js

On Wed, Dec 02, 2015 at 08:08:49PM +0000, Michel Veillette wrote:
> Proposed changes to the Reference, Introduction and Security 
> Considerations sections are available at:

---

From: "Kepeng Li" <[email-masked]>
Date: Mon, 07 Dec 2015 18:48:56 +0800

This is a good requirement for us to revise the "Node ID“ draft and keep
it alive.

Kind Regards
Kepeng

---

From: Michel Veillette <[email-masked]>
Date: Mon, 7 Dec 2015 16:40:52 +0000

Hi Juergen and thanks for your comments.

See [MV] inline.

Michel Veillette

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: December-07-15 4:11 AM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

A few notes:

[MV] To give you some context, the current document (https://core-wg.github.io/yang-cbor/) 
[MV] is an extract of section 4 and 5 of (https://datatracker.ietf.org/doc/draft-veillette-core-cool/),
[MV] some works are still require to make it a standalone document.
[MV]
[MV] About the 'node ID', the terminology used in the current document is in fact 'data node ID'.
[MV] This is the equivalent to the 'member-name' used in 'draft-ietf-netmod-yang-json-06'.
[MV] In the context of CoMI and CoOL, data node IDs are always encoded as unsigned integer.
[MV] If we want to make this mapping also compatible with RESTCONG, we need to support 'member-name' encoded as string.
[MV]
[MV] My questions to you are:
[MV] - Which terminology we should use (tag, data node identifier, ...)?
[MV] - Should we support both data node ID (encoded as unsigned integer) and object name (encoded as string)?

[MV] The current version is based on YANG 1.0 but I agree we now need to extend it to support YANG 1.1.

[MV] The proposed encoding of anyxml allows the encoding of any valid CBOR objects.
[MV] In the context of YANG 1.1, this definition should be moved to anydata.
[MV] The anyxml should be defined as a string carrying any valid xml content.
[MV] Make sense?

[MV] The intent was to adopt a more compact encoding but the proposed solution don't really archive this goal.
[MV] Unless we find something more compact, I agree that the JSON encoding should be used.

[MV] Make sense, I'll adjust the table of content to be aligned with 'draft-ietf-netmod-yang-json-06'

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2015 20:42:29 +0100

Hi,

can you configure you mail client to produce traditional quotings?

Concerning your questions, I suggest you use the terminology of RFC
6020bis wherever possible. Concerning the data node ids, I am clueless
how those numeric IDs will be managed since this has been left
out. YANG provides names. Additional numeric assignments do not
scale. Anyway, the way things are named should be part of the document
since otherwise things are incomplete.

/js

---

From: Michel Veillette <[email-masked]>
Date: Mon, 7 Dec 2015 20:31:03 +0000

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. 

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.

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

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: December-07-15 2:42 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Hi,

Concerning your questions, I suggest you use the terminology of RFC 6020bis wherever possible. Concerning the data node ids, I am clueless how those numeric IDs will be managed since this has been left out. YANG provides names. Additional numeric assignments do not scale. Anyway, the way things are named should be part of the document since otherwise things are incomplete.

/js

On Mon, Dec 07, 2015 at 04:40:52PM +0000, Michel Veillette wrote:
> [mailto:[email-masked]]
> [MV] is an extract of section 4 and 5 of 
> (https://datatracker.ietf.org/doc/draft-veillette-core-cool/),

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2015 21:38:26 +0100

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

>    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, ...?

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

---

From: Michel Veillette <[email-masked]>
Date: Mon, 7 Dec 2015 21:31:37 +0000

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:[email-masked]] 
Sent: December-07-15 3:38 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

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

>    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, ...?

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 10:33:52 +0100

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

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Dec 2015 11:16:58 +0100

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 11:55:30 +0100

> new data node IDs at the end of the numbering.

So I need access to the complete revision history in order to determine
data node IDs, correct? What about imports without a revision (a nasty
source of ambiguity)?

/js

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Dec 2015 12:11:00 +0100

Dear Juergen,

See inline.

> Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder <[email-masked]> a écrit :
> 
> data node IDs, correct?

It is not a must. You can manually indicate the node IDs of the newly added elements. If you want a completely automated allocation of IDs, then yes. The way I think this will work is - the publisher of a module will use the automatic tool to generate the statements, which will then be indicated in the YANG definition.

> What about imports without a revision (a nasty
> source of ambiguity)?
> 

There are two points in your question. The first is straightforward - Data node IDs make sense within the scope of a module. Changing a module does not affect the different modules which import it, with the possible exception of groupings, where the classical data node ID algorithm assignment kicks in (or manual ID assignment if the module author prefers so). In any case, I would refer you to RFC 6020, section 5.1.1. where the question of acceptability of imported modules is treated. 

Best,
Alexander

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 12:53:10 +0100

> It is not a must. You can manually indicate the node IDs of the newly added elements. If you want a completely automated allocation of IDs, then yes. The way I think this will work is - the publish…

I want independently developed systems to interoperate. In general, I
can't assume modules have data node IDs (since a YANG module like lets
say ietf-interfaces simply does not define them).

> There are two points in your question. The first is straightforward - Data node IDs make sense within the scope of a module. Changing a module does not affect the different modules which import it,…

I am talking about imports _into_ a module that may be ambigous from
the viewpoint of the importing module. Section 5.1.1 is about import
by revision, my question was about what happens if there is an import
without revision. We had lengthy discussions in NETMOD what this means
for conformance and the outcome roughly is that this requires a
runtime lookup to find out which module revisions have been used by a
given implementation, that is, your algorithm would not only need the
complete revision history but also runtime information in order to
calculate unique data node ids.

There are alternate designs possible in the solution space. I like to
understand the trade-offs between them.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 08 Dec 2015 13:34:24 +0100

> say ietf-interfaces simply does not define them).

One discussion we haven't had is whether we can combine COMI-style
identifier hashing as the general solution with optional use of manually
managed identifiers.  This would give us the coverage of "any item from
any YANG module" that we would like to have, but still provide the
opportunity for more optimization in specific modules that can benefit
from tighter representation (including the external/internal identifier
split), which we might be able to subject to a tighter development regime.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 14:09:44 +0100

> split), which we might be able to subject to a tighter development regime.

I prefer one solution instead of multiple solutions. I think we should
try to understand the pros/cons of the various possible solutions and
try to take an informed decision.

The solution space is even bigger than the two proposals on the table.
For example, an implementation could simply use locally assigned data
node IDs and publish a dictionary mapping names to data node ids. Yes,
there are downsides with this as well. (Or, as a variation, you
include the dictionary in the encoding, then it looks a bit like
compression.)

So far, the decision tree I have in my mind roughly looks like this:

a) use identifier strings (+simple, -verbose)
b) use data node identifiers (-more complex, +compact)
   b1) derive data node identifiers algorithmically from YANG data models
       (-might be tricky in certain cases)
   b2) use a hash algorithm to derive data node identifiers from the set of
       announced YANG data models
       (-need to deal with hash collisions, slightly larger numbers)
   b3) use locally assigned data node identifiers and provide a cachable
       mapping dictionary
       (-different data node identifiers for each device, data without
         dictionary is meaningless)

/js

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Dec 2015 14:10:44 +0100

Dear Juergen,

Thanks for the great remarks! Indeed, we have had lots of lengthy 
discussions on the way structured data node IDs work, and there are 
several ways to handle the situations you describe.

We've reached a consensus to first detail the most demanded and least 
controversial part - the YANG-CBOR mapping. Having structured data node 
IDs allows for all existing designs to operate with this.

I've provided you with the baseline algorithm, which covers one aspect 
of the data node IDs. Structured data node IDs also allow for private 
module ID space, and for non-managed modules (e.g. as the example you 
provide). They also allow for having COMI-style hashes if you need them. 
The draft which will describe the full operation will come shortly after 
the YANG-CBOR draft.

I think that it would be nice if you can contribute, as your remarks can 
help clear the readability of the document and point on examples that 
must be provided to cover the full spectrum of YANG use-cases.

Best,
Alexander

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 15:01:58 +0100

> IDs allows for all existing designs to operate with this.

Who is 'we'?

> must be provided to cover the full spectrum of YANG use-cases.

OK - I will then sit back and wait. As said earlier, I prefer one way
to do things and I prefer to have one document that provides a
complete and self-contained definition of CBOR encoding of YANG
defined data.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 06:51:54 -0800

Hi,

It is not clear to me how manual numbering of objects can be practical.
Automatic numbering really means "write a program that does the manual
numbering".  YANG allows new nodes to be added anywhere.
Only the relative order of nodes is maintained across revisions.
Some nodes, like "augment" are not ordered at all and they
can change order from 1 revision to the next.  If a grouping in an
external module is extended, then all "uses" of the grouping will be
extended.
If "import without revision" is used, then the specific external grouping
is not even knowable and it is impossible to number the expanded "uses"
correctly.
If any module ever has more than 1024 objects, they will be ignored,
since the numbering has a hard limit on objects per module.

These seem like significant issues that cannot be ignored.

Andy

On Tue, Dec 8, 2015 at 5:10 AM, Alexander Pelov <[email-masked]> wrote:

> discussions on the way structured data node IDs work, and there are several
> ways to handle the situations you describe.
>
> controversial part - the YANG-CBOR mapping. Having structured data node IDs
> allows for all existing designs to operate with this.
>
> I've provided you with the baseline algorithm, which covers one aspect of
> the data node IDs. Structured data node IDs also allow for private module
> ID space, and for non-managed modules (e.g. as the example you provide).
> They also allow for having COMI-style hashes if you need them. The draft
> which will describe the full operation will come shortly after the
> YANG-CBOR draft.
>
> help clear the readability of the document and point on examples that must
> be provided to cover the full spectrum of YANG use-cases.
>
> Best,
> Alexander
>
>
>>> Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder <
>>>> [email-masked]> a écrit :
>>>>
>>> It is not a must. You can manually indicate the node IDs of the newly
>>> added elements. If you want a completely automated allocation of IDs, then
>>> yes. The way I think this will work is - the publisher of a module will use
>>> the automatic tool to generate the statements, which will then be indicated
>>> in the YANG definition.
>>>
>>>> There are two points in your question. The first is straightforward -
>>> Data node IDs make sense within the scope of a module. Changing a module
>>> does not affect the different modules which import it, with the possible
>>> exception of groupings, where the classical data node ID algorithm
>>> assignment kicks in (or manual ID assignment if the module author prefers
>>> so). In any case, I would refer you to RFC 6020, section 5.1.1. where the
>>> question of acceptability of imported modules is treated.
>>>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Dec 2015 15:54:23 +0100

>> IDs allows for all existing designs to operate with this.
The WG during the last IETF, and the main contributors to the CoMI and 
CoOL drafts.

> complete and self-contained definition of CBOR encoding of YANG
I'll be happy if you can contribute to the draft!

Best,
Alexander

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 07:02:27 -0800

On Tue, Dec 8, 2015 at 2:16 AM, Alexander Pelov <[email-masked]> wrote:

> 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.
>
> *# pyang -f tree YANG_MODULE.yang | grep '+' | grep -n '+' *pyang -f tree
> YANG_MODULE-OLD-VERSION.yang >> OLD-VERSION.tree

You realize this does not work at all if a "uses" expands differently from
1 revision to the next, right?
You have to make manual assignments at the end and remember them going
forward
for all new revisions.

> I'm currently working on a pyang version of the algorithm. There is no
> and the starting point is YANG-CBOR mapping.
>
> Best,
> Alexander
>
>
Andy

> The algorithm proposed to generate IDs  is described inhttps://tools.ietf.org/html/draft-veillette-core-cool-00#section-6.
>
> From: Juergen Schoenwaelder [mailto:[email-masked] <[email-masked]>]
> To: Michel Veillette <[email-masked]> <[email-masked]>
> Cc: Core <[email-masked]> <[email-masked]>
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/> <http://www.jacobs-university.de/>
>
>
>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Dec 2015 16:05:23 +0100

Dear Andy,

It was my understanding that we have agreed to advance on the YANG-CBOR 
mapping. Having Structured Data Node IDs allows for both YANG hashes and 
deterministic Data Node IDs.

The questions you ask have been answered repeatedly in previous mails. 
Of course, I think that we must be even more thorough in the future 
draft, as to avoid any possibility of confusion.

I propose that we continue on the current collaborative effort (which 
happens on the github and is public to anyone that wants to see the 
progress). Let's keep the detailed discussion on how the full 
deterministic Data Node IDs for the second stage.

Best,
Alexander

Le 08/12/2015 15:51, Andy Bierman a écrit :
> is not even knowable and it is impossible to number the expanded 
> "uses" correctly.
> On Tue, Dec 8, 2015 at 5:10 AM, Alexander Pelov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear Juergen,
>
>     discussions on the way structured data node IDs work, and there
>     are several ways to handle the situations you describe.
>
>     We've reached a consensus to first detail the most demanded and
>     least controversial part - the YANG-CBOR mapping. Having
>     structured data node IDs allows for all existing designs to
>     operate with this.
>
>     I've provided you with the baseline algorithm, which covers one
>     aspect of the data node IDs. Structured data node IDs also allow
>     for private module ID space, and for non-managed modules (e.g. as
>     the example you provide). They also allow for having COMI-style
>     hashes if you need them. The draft which will describe the full
>     operation will come shortly after the YANG-CBOR draft.
>
>     I think that it would be nice if you can contribute, as your
>     remarks can help clear the readability of the document and point
>     on examples that must be provided to cover the full spectrum of
>     YANG use-cases.
>
>     Best,
>     Alexander
>
>
>                 Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder
>                 <[email-masked]
>                 <mailto:[email-masked]>> a écrit :
>
>             It is not a must. You can manually indicate the node IDs
>             of the newly added elements. If you want a completely
>             automated allocation of IDs, then yes. The way I think
>             this will work is - the publisher of a module will use the
>             automatic tool to generate the statements, which will then
>             be indicated in the YANG definition.
>
>             There are two points in your question. The first is
>             straightforward - Data node IDs make sense within the
>             scope of a module. Changing a module does not affect the
>             different modules which import it, with the possible
>             exception of groupings, where the classical data node ID
>             algorithm assignment kicks in (or manual ID assignment if
>             the module author prefers so). In any case, I would refer
>             you to RFC 6020, section 5.1.1. where the question of
>             acceptability of imported modules is treated.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2015 16:14:04 +0100

> The WG during the last IETF, and the main contributors to the CoMI and 

For me, a YANG to CBOR mapping without a definition how names are
represented in CBOR is incomplete, not interoperable, and hence not
a useful result. Hard problems are not solved by pushing them around.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 07:48:36 -0800

> a useful result. Hard problems are not solved by pushing them around.
+1

I do not think the CoMI authors agree that managed IDs will work.
The technical issues with YANG have not been addressed.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Dec 2015 16:51:27 +0100

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

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 08:29:34 -0800

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

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.

Lada
Andy

> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>>     Only IDs  associated with module names are registered, IDs
> associated to data node identifiers are automatically generated.
> >>>>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Dec 2015 17:01:06 +0000

Hi Andy

I'll try to answer you different interrogations / questions one by one.

About " Automatic numbering really means write a program that does the manual numbering"
Manual numbering means that somebody assign an ID to each object manually
(data node, notification, notification parameter, rpc, input parameter, output parameter).
This assignment is completely arbitrary. This is the approach implemented by LWM2M.

Automatic numbering means that IDs are assigned using an algorithm.
https://tools.ietf.org/html/draft-veillette-core-cool-00#section-6 defines such algorithm.
It might be possible to improve this algorithm if we identify what is wrong about it.

About "Only the relative order of nodes is maintained across revisions"
The proposed algorithm is based on this property to keep the same IDs between versions.

About "YANG allows new nodes to be added anywhere."
The proposed algorithm require that those data nodes are manually assigned if they affect
already assigned IDs. We always argue that the approach need to be friendly to constrained
devices and constrained network, not to people.

About "augment are not ordered at all and they can change order from 1 revision to the next"
Data nodes added using the "augment" statement are part of the namespace of the module
defining these data nodes and as such have no impacts on the IDs of the target module(s).
This is not different to how object names of these data nodes are defined in
draft-ietf-netmod-yang-json-06, see "barmod:bar": true in page 6.

About "If a grouping in an external module is extended, then all uses of the grouping will be extended"
This is why the cool:id extension is defined at the top level of the module instead of as leaf sub-statement.
The different data nodes impacted by the addition of a leaf within a group can be assigned individually.
An example of this scenario have been provided, see attachment.

About "If import without revision is used, then the specific external grouping
is not even knowable and it is impossible to number the expanded uses correctly."
If I understand correctly the rules defined in YANG section 10 (Updating a Module)
previous versions always define the same set or a subset of the data nodes.
If IDs of each of these versions are consistent, importing any of the revision
should not cause any impacts. The only constrain should be that module
importing other module(s) without revision contain an up to date list of cool:id extensions.

For example:
Module A with import module B version "20150101" is the base line, all objects are automatically generated.

Module A with import module B version "20150201" introduce two data nodes which need to be manually assigned.
cool:id "/container-a/leaf-b 500";
cool:id "/container-a/leaf-c 501";

Module A with import module B version "20160101" introduce one more data node which need to be manually assigned.
cool:id "/container-a/leaf-b 500";
cool:id "/container-a/leaf-c 501";
cool:id "/list-d/leaf-e 502";

The latest list of cool:id containing 3 entries can be applied to both module B version "20150201" and
version "20160101". The resulting IDs will be the same in both cases except that the third
entry won’t be used in the case of module B version "20150201".

About " If any module ever has more than 1024 objects, they will be ignored"
If this limit is a real life problem, we have multiple options:

·        Specify a range of module IDs supporting more objects.

·        Using a different data type for these jumbo modules (e.g. 64 bits unsinged integer)

Regards,

Michel Veillette
Tel: 450-531-3109

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: December-08-15 9:52 AM
To: Alexander Pelov <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Hi,

external module is extended, then all "uses" of the grouping will be extended.
is not even knowable and it is impossible to number the expanded "uses" correctly.

Andy

On Tue, Dec 8, 2015 at 5:10 AM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:
Dear Juergen,

Thanks for the great remarks! Indeed, we have had lots of lengthy discussions on the way structured data node IDs work, and there are several ways to handle the situations you describe.

We've reached a consensus to first detail the most demanded and least controversial part - the YANG-CBOR mapping. Having structured data node IDs allows for all existing designs to operate with this.

I've provided you with the baseline algorithm, which covers one aspect of the data node IDs. Structured data node IDs also allow for private module ID space, and for non-managed modules (e.g. as the example you provide). They also allow for having COMI-style hashes if you need them. The draft which will describe the full operation will come shortly after the YANG-CBOR draft.

I think that it would be nice if you can contribute, as your remarks can help clear the readability of the document and point on examples that must be provided to cover the full spectrum of YANG use-cases.

Best,
Alexander

See inline.
Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> a écrit :

/js

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

Subject: RE: CoMI / CoOL merge process
From: Michel Veillette <[email-masked]>
To: Andy Bierman <[email-masked]>
Cc: Carsten Bormann <[email-masked]>, peter van der Stok <[email-masked]>, Alexander Pelov <[email-masked]>, "Turner, Randy" <[email-masked]>, Somaraju Abhinav <[email-masked]>
Date: Tue, 10 Nov 2015 03:03:47 +0000

As mentioned, data nodes added within the schema tree need to be manually assigned.

In the proposed example, If the “address-family” grouping is updated as follow:

    grouping address-family {

      description

        "This grouping provides a leaf identifying an address

       family.";

      leaf address-family {

        type identityref {

          base address-family;

        }

        mandatory true;

        description "Address family.";

      }

      leaf new-field {

        type uint8;

        mandatory false;

        description "Field added in this revision.";

      }

}  // grouping address-family

The following statements need to be added to the update YANG module to maintain the original IDs.

cool:id "/routing-state/routing-instance/default-ribs/default-rib/new-field 200";

cool:id "/routing-state/ribs/rib/new-field 201";

cool:id "/routing/routing-instance/default-ribs/default-rib/new-field 202";

cool:id "/routing/ribs/rib/new-field 203";

cool:id "/active-route/input/destination-address/new-field 204";

The resulting IDs for the new version of ietf-routing.yang will be:

ID            Data node

1              container /routing-state

2              list /routing-state/routing-instance

3              leaf /routing-state/routing-instance/name

4              leaf /routing-state/routing-instance/id

5              leaf /routing-state/routing-instance/type

6              leaf /routing-state/routing-instance/router-id

7              container /routing-state/routing-instance/default-ribs

8              list /routing-state/routing-instance/default-ribs/default-rib

9              leaf /routing-state/routing-instance/default-ribs/default-rib/address-family

200         leaf /routing-state/routing-instance/default-ribs/default-rib/new-field

10           leaf /routing-state/routing-instance/default-ribs/default-rib/rib-name

11           container /routing-state/routing-instance/interfaces

12           list /routing-state/routing-instance/interfaces/interface

13           leaf /routing-state/routing-instance/interfaces/interface/name

14           container /routing-state/routing-instance/routing-protocols

15           list /routing-state/routing-instance/routing-protocols/routing-protocol

16           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/name

17           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/type

18           container /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs

19           list /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib

20           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/rib-name

21           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/import-filter

22           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/export-filter

23           container /routing-state/ribs

24           list /routing-state/ribs/rib

25           leaf /routing-state/ribs/rib/name

26           leaf /routing-state/ribs/rib/id

27           leaf /routing-state/ribs/rib/address-family

201         leaf /routing-state/ribs/rib/new-field

28           container /routing-state/ribs/rib/routes

29           list /routing-state/ribs/rib/routes/route

30           leaf /routing-state/ribs/rib/routes/route/id

                choice /routing-state/ribs/rib/routes/route/next-hop-options

                case /routing-state/ribs/rib/routes/route/next-hop-options/special-next-hop

31           leaf /routing-state/ribs/rib/routes/route/next-hop-options/special-next-hop/special-next-hop

                case /routing-state/ribs/rib/routes/route/next-hop-options/simple-next-hop

32           leaf /routing-state/ribs/rib/routes/route/next-hop-options/simple-next-hop/outgoing-interface

                case /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list

33           container /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list

34           list /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop

35           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/id

36           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/outgoing-interface

37           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/priority

38           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/weight

39           leaf /routing-state/ribs/rib/routes/route/source-protocol

40           leaf /routing-state/ribs/rib/routes/route/last-updated

41           container /routing-state/ribs/rib/recipient-ribs

42           list /routing-state/ribs/rib/recipient-ribs/recipient-rib

43           leaf /routing-state/ribs/rib/recipient-ribs/recipient-rib/rib-name

44           leaf /routing-state/ribs/rib/recipient-ribs/recipient-rib/filter

45           container /routing-state/route-filters

46           list /routing-state/route-filters/route-filter

47           leaf /routing-state/route-filters/route-filter/name

48           leaf /routing-state/route-filters/route-filter/type

49           container /routing

50           list /routing/routing-instance

51           leaf /routing/routing-instance/name

52           leaf /routing/routing-instance/type

53           leaf /routing/routing-instance/enabled

54           leaf /routing/routing-instance/router-id

55           leaf /routing/routing-instance/description

56           container /routing/routing-instance/default-ribs

57           list /routing/routing-instance/default-ribs/default-rib

58           leaf /routing/routing-instance/default-ribs/default-rib/address-family

202         leaf /routing/routing-instance/default-ribs/default-rib/new-field

59           leaf /routing/routing-instance/default-ribs/default-rib/rib-name

60           container /routing/routing-instance/interfaces

61           list /routing/routing-instance/interfaces/interface

62           leaf /routing/routing-instance/interfaces/interface/name

63           container /routing/routing-instance/routing-protocols

64           list /routing/routing-instance/routing-protocols/routing-protocol

65           leaf /routing/routing-instance/routing-protocols/routing-protocol/name

66           leaf /routing/routing-instance/routing-protocols/routing-protocol/description

67           leaf /routing/routing-instance/routing-protocols/routing-protocol/enabled

68           leaf /routing/routing-instance/routing-protocols/routing-protocol/type

69           container /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs

70           list /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib

71           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/rib-name

72           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/import-filter

73           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/export-filter

74           container /routing/routing-instance/routing-protocols/routing-protocol/static-routes

75           container /routing/ribs

76           list /routing/ribs/rib

77           leaf /routing/ribs/rib/name

78           leaf /routing/ribs/rib/address-family

203         leaf /routing/ribs/rib/new-field

79           leaf /routing/ribs/rib/description

80           container /routing/ribs/rib/recipient-ribs

81           list /routing/ribs/rib/recipient-ribs/recipient-rib

82           leaf /routing/ribs/rib/recipient-ribs/recipient-rib/rib-name

83           leaf /routing/ribs/rib/recipient-ribs/recipient-rib/filter

84           container /routing/route-filters

85           list /routing/route-filters/route-filter

86           leaf /routing/route-filters/route-filter/name

87           leaf /routing/route-filters/route-filter/description

88           leaf /routing/route-filters/route-filter/type

89           rpc /active-route

90           container /active-route/input

91           leaf /active-route/input/routing-instance-name

92           container /active-route/input/destination-address

93           leaf /active-route/input/destination-address/address-family

204         leaf /active-route/input/destination-address/new-field

94           container /active-route/output

95           container /active-route/output/route

96           leaf /active-route/output/route/address-family

205         leaf /active-route/output/route/new-field

                choice /active-route/output/route/next-hop-options

98           case /active-route/output/route/next-hop-options/special-next-hop

97           leaf /active-route/output/route/next-hop-options/special-next-hop/special-next-hop

                case /active-route/output/route/next-hop-options/simple-next-hop

98           leaf /active-route/output/route/next-hop-options/simple-next-hop/outgoing-interface

                case /active-route/output/route/next-hop-options/next-hop-list

99           container /active-route/output/route/next-hop-options/next-hop-list/next-hop-list

100         list /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop

101         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/id

102         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/outgoing-interface

103         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/priority

104         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/weight

105         leaf /active-route/output/route/source-protocol

106         leaf /active-route/output/route/last-updated

107         rpc /route-count

108         container /route-count/input

109         leaf /route-count/input/rib-name

110         container /route-count/output

111         leaf /route-count/output/number-of-routes

I hope this example will help clarify the proposed solution.

Regards,

Michel Veillette

Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com/>

From: Andy Bierman [mailto:[email-masked]]
Sent: 9 novembre 2015 18:47
To: Michel Veillette <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; peter van der Stok <[email-masked]>; Alexander Pelov <[email-masked]>; Turner, Randy <[email-masked]>; Somaraju Abhinav <[email-masked]>
Subject: Re: CoMI / CoOL merge process

So what happens if an object is added to the grouping in the next release?

It renumbers your strings.  The old numbers after this uses-stmt expansion point

will all be changed.  YANG allows new objects to be added anywhere

in a new revision of a module.  Your auto-numbering only works for the first

revision of a module.

Andy

On Mon, Nov 9, 2015 at 3:37 PM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

   About “YANG allows objects to be added in groupings”

   draft-veillette-core-cool-00 section 6.2 say “When assigned automatically, data nodes are numbered based on their location in the schema tree.”

   The use of “schema tree” in this sentence should address your concerns about grouping and uses.

   If we take the YANG module http://www.netconfcentral.org/modules/ietf-routing/2014-05-24#router-id.236 as example.

   This module defines the following grouping:

   ·         grouping address-family

   ·         grouping state-entry-id

   ·         grouping router-id

   ·         grouping outgoing-interface

   ·         grouping special-next-hop

   ·         grouping next-hop-classifiers

   ·         grouping next-hop-content

   ·         grouping route-metadata

   The schema tree of this module is show below.

   Data node identifiers can be automatically assigned as follow.

   ID            Data node

   1              container /routing-state

   2              list /routing-state/routing-instance

   3              leaf /routing-state/routing-instance/name

   4              leaf /routing-state/routing-instance/id

   5              leaf /routing-state/routing-instance/type

   6              leaf /routing-state/routing-instance/router-id

   7              container /routing-state/routing-instance/default-ribs

   8              list /routing-state/routing-instance/default-ribs/default-rib

   9              leaf /routing-state/routing-instance/default-ribs/default-rib/address-family

   10           leaf /routing-state/routing-instance/default-ribs/default-rib/rib-name

   11           container /routing-state/routing-instance/interfaces

   12           list /routing-state/routing-instance/interfaces/interface

   13           leaf /routing-state/routing-instance/interfaces/interface/name

   14           container /routing-state/routing-instance/routing-protocols

   15           list /routing-state/routing-instance/routing-protocols/routing-protocol

   16           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/name

   17           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/type

   18           container /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs

   19           list /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib

   20           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/rib-name

   21           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/import-filter

   22           leaf /routing-state/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/export-filter

   23           container /routing-state/ribs

   24           list /routing-state/ribs/rib

   25           leaf /routing-state/ribs/rib/name

   26           leaf /routing-state/ribs/rib/id

   27           leaf /routing-state/ribs/rib/address-family

   28           container /routing-state/ribs/rib/routes

   29           list /routing-state/ribs/rib/routes/route

   30           leaf /routing-state/ribs/rib/routes/route/id

                   choice /routing-state/ribs/rib/routes/route/next-hop-options

                   case /routing-state/ribs/rib/routes/route/next-hop-options/special-next-hop

   31           leaf /routing-state/ribs/rib/routes/route/next-hop-options/special-next-hop/special-next-hop

                   case /routing-state/ribs/rib/routes/route/next-hop-options/simple-next-hop

   32           leaf /routing-state/ribs/rib/routes/route/next-hop-options/simple-next-hop/outgoing-interface

                   case /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list

   33           container /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list

   34           list /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop

   35           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/id

   36           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/outgoing-interface

   37           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/priority

   38           leaf /routing-state/ribs/rib/routes/route/next-hop-options/next-hop-list/next-hop-list/next-hop/weight

   39           leaf /routing-state/ribs/rib/routes/route/source-protocol

   40           leaf /routing-state/ribs/rib/routes/route/last-updated

   41           container /routing-state/ribs/rib/recipient-ribs

   42           list /routing-state/ribs/rib/recipient-ribs/recipient-rib

   43           leaf /routing-state/ribs/rib/recipient-ribs/recipient-rib/rib-name

   44           leaf /routing-state/ribs/rib/recipient-ribs/recipient-rib/filter

   45           container /routing-state/route-filters

   46           list /routing-state/route-filters/route-filter

   47           leaf /routing-state/route-filters/route-filter/name

   48           leaf /routing-state/route-filters/route-filter/type

   49           container /routing

   50           list /routing/routing-instance

   51           leaf /routing/routing-instance/name

   52           leaf /routing/routing-instance/type

   53           leaf /routing/routing-instance/enabled

   54           leaf /routing/routing-instance/router-id

   55           leaf /routing/routing-instance/description

   56           container /routing/routing-instance/default-ribs

   57           list /routing/routing-instance/default-ribs/default-rib

   58           leaf /routing/routing-instance/default-ribs/default-rib/address-family

   59           leaf /routing/routing-instance/default-ribs/default-rib/rib-name

   60           container /routing/routing-instance/interfaces

   61           list /routing/routing-instance/interfaces/interface

   62           leaf /routing/routing-instance/interfaces/interface/name

   63           container /routing/routing-instance/routing-protocols

   64           list /routing/routing-instance/routing-protocols/routing-protocol

   65           leaf /routing/routing-instance/routing-protocols/routing-protocol/name

   66           leaf /routing/routing-instance/routing-protocols/routing-protocol/description

   67           leaf /routing/routing-instance/routing-protocols/routing-protocol/enabled

   68           leaf /routing/routing-instance/routing-protocols/routing-protocol/type

   69           container /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs

   70           list /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib

   71           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/rib-name

   72           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/import-filter

   73           leaf /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/export-filter

   74           container /routing/routing-instance/routing-protocols/routing-protocol/static-routes

   75           container /routing/ribs

   76           list /routing/ribs/rib

   77           leaf /routing/ribs/rib/name

   78           leaf /routing/ribs/rib/address-family

   79           leaf /routing/ribs/rib/description

   80           container /routing/ribs/rib/recipient-ribs

   81           list /routing/ribs/rib/recipient-ribs/recipient-rib

   82           leaf /routing/ribs/rib/recipient-ribs/recipient-rib/rib-name

   83           leaf /routing/ribs/rib/recipient-ribs/recipient-rib/filter

   84           container /routing/route-filters

   85           list /routing/route-filters/route-filter

   86           leaf /routing/route-filters/route-filter/name

   87           leaf /routing/route-filters/route-filter/description

   88           leaf /routing/route-filters/route-filter/type

   89           rpc /active-route

   90           container /active-route/input

   91           leaf /active-route/input/routing-instance-name

   92           container /active-route/input/destination-address

   93           leaf /active-route/input/destination-address/address-family

   94           container /active-route/output

   95           container /active-route/output/route

   96           leaf /active-route/output/route/address-family

                   choice /active-route/output/route/next-hop-options

   98           case /active-route/output/route/next-hop-options/special-next-hop

   97           leaf /active-route/output/route/next-hop-options/special-next-hop/special-next-hop

                   case /active-route/output/route/next-hop-options/simple-next-hop

   98           leaf /active-route/output/route/next-hop-options/simple-next-hop/outgoing-interface

                   case /active-route/output/route/next-hop-options/next-hop-list

   99           container /active-route/output/route/next-hop-options/next-hop-list/next-hop-list

   100         list /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop

   101         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/id

   102         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/outgoing-interface

   103         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/priority

   104         leaf /active-route/output/route/next-hop-options/next-hop-list/next-hop-list/next-hop/weight

   105         leaf /active-route/output/route/source-protocol

   106         leaf /active-route/output/route/last-updated

   107         rpc /route-count

   108         container /route-count/input

   109         leaf /route-count/input/rib-name

   110         container /route-count/output

   111         leaf /route-count/output/number-of-routes

   About “It also allows objects to be added anywhere inline in a new revision of the module.”

   This question have been already answer in my email of 2015-11-04 13:53

   draft-veillette-core-cool-00 section 6.2<https://tools.ietf.org/html/draft-veillette-core-cool-00#section-6.2>, address this point specifically.

   “When a module is updated, old Data node IDs can be preserved by

   adding top level data nodes to the end of the module or by

   manually assigning new data nodes within the schema tree.”

   Similarly, RPCs or notifications can be added to the end.
   Since there order of these objects have no semantic meaning, manual assignment

   of Protocol operation ID and Notification ID is not required during a revision of the YANG module.

   Further clarifications have been provided in my email of 2015-11-04 14:09

   The text take into consideration the fact that “YANG is hierarchical”, this is why there is two cases.

   ·         For “top level data nodes”, added to the end

   ·         For non “top level data nodes”, manually assign

   So only non “top level data nodes” need to be manually assigned when added during a YANG module update.

   It is important to note that data nodes added using the augment statement have no effect since they are allocated using a different module ID.

Michel Veillette

Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com/>

   From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
   Sent: 9 novembre 2015 17:41
   To: Michel Veillette <[email-masked]<mailto:[email-masked]>>
   Subject: Re: CoMI / CoOL merge process

   YANG allows objects to be added in groupings.

   It also allows objects to be added anywhere inline

   in a new revision of the module.

   Andy

   On Mon, Nov 9, 2015 at 2:35 PM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

      Can you provide at least one example where these rules doesn`t work.

Michel Veillette

Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com/>

      From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
      Sent: 9 novembre 2015 16:44
      To: Michel Veillette <[email-masked]<mailto:[email-masked]>>
      Cc: Carsten Bormann <[email-masked]<mailto:[email-masked]>>; peter van der Stok <[email-masked]<mailto:[email-masked]>>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>; Somaraju Abhinav <[email-masked]<mailto:[email-masked]>>
      Subject: Re: CoMI / CoOL merge process

      On Mon, Nov 9, 2015 at 1:25 PM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

         The only ID which need to be registered is the module ID.

         Section 6 of draft-veillette-core-cool-00 defines the rules to automatically assign IDs to the data nodes, RPCs, Input parameters, Output parameters, notification and notification parameters.

      these don't work.

         Data node IDs are based on the schema tree (see section 3 of RFC 6020 - The definition hierarchy specified within a module.). The schema tree is independent of the order the statements in YANG files and independent of the use of grouping and sub-modules.  Grouping can be introduce or remove without affecting the schema tree.

         Tools like http://www.netconfcentral.com/run_yangdump  (Great tool I’m sure you known very well) automatically output this schema tree.

Michel Veillette

Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com/>

         From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
         Sent: 9 novembre 2015 16:02
         To: Michel Veillette <[email-masked]<mailto:[email-masked]>>
         Cc: Carsten Bormann <[email-masked]<mailto:[email-masked]>>; peter van der Stok <[email-masked]<mailto:[email-masked]>>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>; Somaraju Abhinav <[email-masked]<mailto:[email-masked]>>
         Subject: Re: CoMI / CoOL merge process

         Hi,

         I don't think this will work.

         IMO manual numbering will be needed but missed or mismanaged.

         E.g., objects added to an external grouping get expanded at run-time.

         There is no way to number them in the "uses" statement.

         I don't see how the registry approach can possibly work.

         Also in order to support unregistered managed IDs, there needs

         to be a mapping between object ID strings and numbers.  If the server has to

         provide this, then why bother with registered numbers at all?

         And if the server provides any mapping whatsoever, then that means

         the numbers are not universal and maybe not even permanent.

         It also means the client has to store and understand all the strings, in order to

         resolve the numeric mappings.

         Andy

         On Mon, Nov 9, 2015 at 12:48 PM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

            IETF uses an automated system to register thousands of participants for each IETF meeting.

            Can we use the same type of system to register these Module IDs?

            Can we charge a reasonable fee (e.g. 20$) to pay for this infrastructure and avoid malicious peoples to starve the available ID space?

Michel Veillette

Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com/>

            From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
            Sent: 9 novembre 2015 05:22
            To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
            Cc: Michel Veillette <[email-masked]<mailto:[email-masked]>>; peter van der Stok <[email-masked]<mailto:[email-masked]>>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>; Somaraju Abhinav <[email-masked]<mailto:[email-masked]>>
            Subject: Re: CoMI / CoOL merge process

            On Fri, Nov 6, 2015 at 3:07 PM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

               Andy Bierman wrote:
               > Hi,
               >
               > The CORE WG is very skilled at optimizing bytes on the wire,

               That is not the only objective; CoRE is also about reducing complexity
               at the constrained nodes.

               > but IMO there are some "forest" type questions that are unanswered,
               > like "what organization is going to register YANG module and object IDs?"

               Indeed, this is the most interesting question when we go to a registered
               appraoch.  Not just "which organization", but "what is the workflow" and
               "who ensures the stability of the code point space".

            It seems like a waste of time to develop a hard-wired numbering approach

            while ignoring this question.  IANA is going to be advised not to accept

            this new registry, not that they would accept it anyway.  Given the comments

            in the meeting that registrations doesn't work because about half the IDs

            will never get registered, it is not even clear that an IANA registry is sufficient.

            Andy

               > "if JSON is already required, it is a good idea to require CBOR as well"

               Who says JSON is required (on the constrained node)?

               > "If there are only 11 or so attributes everybody agrees on, then why
               > is a complex protocol and YANG language needed?"

               If you need 11 variables (is that what you mean?), OMA LWM2M is probably
               a good framework.  COMI is more about networks with specific management
               requirements (think LORA/LP-WAN), and about integrating network
               management, application management, and even some application semantics.

               > It seems everybody in the WG has a different view, depending
               > on their own use-cases (including me).

               Yes, we have to work on creating consensus wrt our assumptions and
               goals. Maybe writing a document (or more likely a section in one of the
               documents) would help.

               > But mostly, "If full RESTCONF is the goal, then why bother defining
               > a new protocol?

               Is it?  I think the "full" comes in where we want to allow a
               permissionless path to using variables from YANG modules that may not
               have been written with COMI in mind.  I don't think this will be a "full
               RESTCONF".

               > Isn't the HTTP to CoAP proxy translation good enough?

               The way RESTCONF is defined today (with XPath and all), no.
               That is what gives us the opportunity to go full way to a COMI/COOL-like
               appraoch.

               > I already have to implement a gateway because many RESTCONF clients
               > are not going to be rewritten just for CoMI.  If the native CoAP server
               > is way different then it will double the development effort.

               Ah, but then you can charge twice as much :-)
               Keeping the complexity down is still the main goal.  With a focus on the
               constrained node, but complexity on cross-protocol proxies also needs to
               be kept down.

               Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 08 Dec 2015 18:25:56 +0100

Michel Veillette wrote:
> already assigned IDs. 

Doesn't that mean we no longer can maintain the property that this
scheme can be applied to all the YANG modules out there?

(We can separately discuss whether we do need this property, but given
that it is a major selling point of the COMI approach, I would like to
know what approaches keep it and which ones don't.)

Grüße, Carsten

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 Dec 2015 18:49:15 +0100

> On 08 Dec 2015, at 17:29, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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. 

> 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

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

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 09:58:02 -0800

On Tue, Dec 8, 2015 at 9:49 AM, Ladislav Lhotka <[email-masked]> wrote:

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

I don't see why they are needed.
The object identifier hash is for nodes that can appear in an instance
document.
The nice predictable aspect of YANG Hash is that it never
depends on any other objects except the one being hashed.
The quantity and order of other objects has no affect on the algorithm.

> There is still some uncertainty due to module revisions that cannot be
What uncertainty?
Why would the /path/from/root/to/node/foo change from 1 release to the next?
This is not allowed in YANG.

Andy

> > >>> I need to understand the algorithm for assigning data node
> identifiers first to see whether this approach makes sense.
> > >>>
> > >>> /js
> > >>>
> > >>> --

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Dec 2015 19:02:50 +0000

Hi Carsten

This scheme can be applied to any YANG modules if the list of manual assigned objects can be provided out of band to the ID generator. We can also investigate how these objects added by new versions of a module can be also automatically assigned. This will require that all versions of a module be provided as input to the ID generator.

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: December-08-15 12:26 PM
To: Michel Veillette <[email-masked]>
Cc: Andy Bierman <[email-masked]>; Alexander Pelov <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

> The proposed algorithm require that those data nodes are manually 

Doesn't that mean we no longer can maintain the property that this scheme can be applied to all the YANG modules out there?

(We can separately discuss whether we do need this property, but given that it is a major selling point of the COMI approach, I would like to know what approaches keep it and which ones don't.)

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Dec 2015 19:54:24 +0000

Hi Ladislav

Hashes have advantages, no doubts. However, IMO they are irrelevant since they don’t address the needs
of the constrained devices and constrained networks which is the goal of this exercise.

With hashes:
- Clients must be aware of both object names and hashes in order to interact with objects and resolve rehash.
  This is worse than member-name (draft-ietf-netmod-yang-json-06 section 4)

- Extra handshakes are required to resolve rehash
  This is worse than member-name

- Clients must store the rehash table for each peer
  This is worse than member-name

- Hashes don't significantly reduce de size of messages
  For existing modules, the average saving is around 30% compared to member-name
  For modules specifically written for constrained  devices, member-names can easily outperform hashes.

To develop a successful protocol for constrained devices, we should judge solutions based on
resource requirements on devices and networks, not just in the abstract.

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: December-08-15 10:51 AM
To: Alexander Pelov <[email-masked]>; [email-masked]
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Alexander Pelov <[email-masked]> writes:

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

Lada

> *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
> *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
>
>
>> 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 
>>>> - Possibility to define a range of private IDs (IDs locally 
>>>> assigned and used, not globally unique, same concept as IPv4 
>>>> 10.x.x.x)

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Dec 2015 20:23:42 +0000

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

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: December-08-15 10:51 AM
To: Alexander Pelov <[email-masked]>; [email-masked]
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Dec 2015 08:35:06 +0100

> This is not allowed in YANG.

Yes, but there may be new nodes unknown to a user of an old revision.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Dec 2015 09:17:57 +0100

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

> 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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 09 Dec 2015 09:55:20 +0100

Hi Juergen,

Can we concentrate on the YANG to CBOR mapping and the representation of 
the YANG names?
Can you explain to me where the problem lies exactly?
If the YANG to CBOR mapping (Y2C) depends on the n bit representations 
of the YANG names, we have interesting consequences for 
inter-operability.
In my opinion a Y2C mapping should include YANG name strings and their n 
bit identifiers because they will both be present; although not in the 
same payload.

Peter

Andy Bierman schreef op 2015-12-08 16:48:
> On Tue, Dec 8, 2015 at 7:14 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> 
>> are
>> least

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Dec 2015 10:14:35 +0100

> Can we concentrate on the YANG to CBOR mapping and the representation of 

We do.

> Can you explain to me where the problem lies exactly?

Here is an example:

  3.1.15. YANG type: container

  A container MUST be encoded using a CBOR map data item (major type
  5). A map is comprised of pairs of data items, with each data item
  consisting of a key and a value. CBOR map keys MUST be encoded using
  a CBOR unsigned integer (major type 0) and set to a data node ID or
  a fully-qualified data node ID. Data node IDs MUST be used when a
  parent node exists and this parent shares the same module ID as the
  current data node. CBOR map values MUST be encoded using the rules
  associated with the data node type.

This can't be implemented since it is unclear what a data node ID is.

> If the YANG to CBOR mapping (Y2C) depends on the n bit
> representations of the YANG names, we have interesting consequences
> for inter-operability.

The I-D that started this thread apparently assumes CBOR unsigned
integer (major type 0) as names and without defining how these numbers
are generated, the I-D is incomplete.

> In my opinion a Y2C mapping should include YANG name strings and
> their n bit identifiers because they will both be present; although
> not in the same payload.

I commented on <https://core-wg.github.io/yang-cbor/> and I think this
document has problems. That's all.

/js

---

From: peter van der Stok <[email-masked]>
Date: Wed, 09 Dec 2015 10:21:27 +0100

Hi Juergen, see below.

>> split), which we might be able to subject to a tighter development 

I think this is certainly worth looking into.

> So far, the decision tree I have in my mind roughly looks like this:

The decision tree looks very much to what's in my mind.
Agreeing on the measures to compare them is another matter:
- Size of identifiers coupled to when is reduction from n to m bits 
worth while the overhead
- Exception space and counter measure overhead
- Run-time overhead
- number of repositories and their sizes
- and probably others.

Peter

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Dec 2015 09:42:51 -0800

> Yes, but there may be new nodes unknown to a user of an old revision.

But this is exactly the same implementation detail whether the new node is
a string,
a hash, or an assigned number. IMO, only permanent IDs are useful
here, so a hash that included the module revision date would not help.

Andy

> >> > >>> - Each type of object (Data node IDs, Notification IDs,
> Notification
> >> parameter IDs,
> >> https://tools.ietf.org/html/draft-veillette-core-cool-00#section-7.3
> show
> >> an
> >> > >>> But this does not make sense. The naming must be settled, even if
> it
> >> is painful.
> >> > >>>
> assigned
> >> > >>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
> >
> >> > >

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Dec 2015 18:20:26 +0000

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

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:[email-masked]]

Sent: December-09-15 3:18 AM

To: Michel Veillette <[email-masked]>; Alexander Pelov <[email-masked]>; [email-masked]

Subject: RE: [core] CBOR Encoding of Data Modeled with YANG

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

      same leafs.

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.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Dec 2015 10:30:58 -0800

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 <
[email-masked]> wrote:

> 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
>
> *Object type*
> *Path*
> *YANG type*
> *Version *
> *ID*
> *Object type*
> *Path*
> *YANG type*
> *Version *
> *ID*
> Section 12 says: In YANG, almost all statements are unordered. And section
> 10 has these two bullets that provide a strong indication:
>
>
>
> documents (except RPCs), I think that swapping definitions of sibling leafs
> has to be considered syntactically and semantically equivalent.
>
>
>
> augments and groupings. It is difficult because (unlike the MIB) a stable
> order of siblings wasn't part of YANG design.
>
>
>
> Lada
>
>
>

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Dec 2015 18:39:19 +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:[email-masked]]
Sent: December-09-15 1:31 PM
To: Michel Veillette <[email-masked]>
Cc: Ladislav Lhotka <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; [email-masked]
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Hi,

Andy

On Wed, Dec 9, 2015 at 10:20 AM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ladislav, Hi Juergen

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)

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

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

leaf

2014-07-03

Data node

list

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

container

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

list

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

/jukebox/playlist

list

2014-07-03

Data node

/jukebox/playlist/name

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

/jukebox/playlist/song

list

2014-07-03

Data node

leaf

2014-07-03

Data node

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

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

leaf

2014-07-03

3

Data node

/jukebox/library/artist

list

2014-07-03

4

Data node

list

2014-07-03

5

Data node

container

2014-07-03

6

Data node

leaf

2014-07-03

7

Data node

leaf

2014-07-03

8

Data node

leaf

2014-07-03

9

Data node

leaf

2014-07-03

10

Data node

list

2014-07-03

11

Data node

leaf

2014-07-03

12

Data node

leaf

2014-07-03

13

Data node

leaf

2014-07-03

14

Data node

leaf

2014-07-03

15

Data node

leaf

2014-07-03

16

Data node

leaf

2014-07-03

17

Data node

leaf

2014-07-03

18

Data node

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

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

leaf

2014-07-03

26

Data node

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

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

leaf

2014-07-03

3

Data node

/jukebox/library/artist

list

2014-07-03

4

Data node

list

2014-07-03

5

Data node

container

2014-07-03

6

Data node

leaf

2014-07-03

7

Data node

leaf

2014-07-03

8

Data node

leaf

2015-12-09

28

Data node

leaf

2014-07-03

9

Data node

leaf

2014-07-03

10

Data node

list

2014-07-03

11

Data node

leaf

2014-07-03

12

Data node

leaf

2014-07-03

13

Data node

leaf

2014-07-03

14

Data node

leaf

2014-07-03

15

Data node

leaf

2014-07-03

16

Data node

leaf

2015-12-09

29

Data node

leaf

2014-07-03

17

Data node

leaf

2014-07-03

18

Data node

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

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

leaf

2014-07-03

26

Data node

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

Regards,

Michel

-----Original Message-----

From: Ladislav Lhotka [mailto:[email-masked]<mailto:[email-masked]>]

To: Michel Veillette <[email-masked]<mailto:[email-masked]>>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

      same leafs.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Dec 2015 19:45:20 +0100

> In this context, import of modules without revision can't be supported.

Almost all published YANG modules so far use import without revision...

I am also concerned tracking all revisions in order to produce the
correct numbers in not very robust. I have seen proprietary MIB
modules with revisions in the hundreds and if it is necessary to
obtain all revisions in order to compute node ids, this will be a
major hurdle in practice. Well, in the IoT space, perhaps we end up
only with revisions in the 20s or 30s but again obtaining all
revisions to get the numbers will be painful. And since humans are
involved, there is also a change for subtle errors that are difficult
to spot.

/js

PS: We had some discussion about the auto-numbering of enum and bits
    values in YANG 1.1. Automatic numbering algorithms are subtle.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Dec 2015 11:44:53 -0800

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 <
[email-masked]> wrote:

> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* December-09-15 1:31 PM
> *To:* Michel Veillette <[email-masked]>
> *Cc:* Ladislav Lhotka <[email-masked]>; Juergen Schoenwaelder <
> [email-masked]>; [email-masked]
> *Subject:* Re: [core] CBOR Encoding of Data Modeled with YANG
>
>
>
> Hi,
>
>
>

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Dec 2015 20:48:02 +0000

Hi Juergen

A possible solution to this issue (revisions in the hundreds) is to provide the base line version
when registering for a module ID.

IDs will be generated only for the specify version and any subsequent versions.
In practice, the latest version can be the base line and access to the previous definition files won't be necessary.
Since each version always represent a superset of the previous ones, IDs generated using the latest version
cover all objects already defined in any previous versions.

Thanks again for your comments
I things we're making progress.

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: December-09-15 1:45 PM
To: Michel Veillette <[email-masked]>
Cc: Ladislav Lhotka <[email-masked]>; [email-masked]
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

On Wed, Dec 09, 2015 at 06:20:26PM +0000, Michel Veillette wrote:
> 
> *        import without revision will be rejected

I am also concerned tracking all revisions in order to produce the correct numbers in not very robust. I have seen proprietary MIB modules with revisions in the hundreds and if it is necessary to obtain all revisions in order to compute node ids, this will be a major hurdle in practice. Well, in the IoT space, perhaps we end up only with revisions in the 20s or 30s but again obtaining all revisions to get the numbers will be painful. And since humans are involved, there is also a change for subtle errors that are difficult to spot.

/js

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Dec 2015 21:02:10 +0000

Hi Andy

The third bullet or the original email address this issue (Now /B is #2 in the sort order, and #1 is now assigned to /A).

In the case of your example:

The ID file generated when parsing version 1 will contain something equivalent to:
"data node", "B", 1, "xxxx-xx-xx"

This file will be provided as input when parsing version 2.
A new ID file will be generated containing something equivalent to:
"data node", "B", 1, "xxxx-xx-xx"
"data node", "A", 2, "yyyy-yy-yy"

As mentioned in the previous email to Juergen, the version use as baseline and an optional list of objects preassigned
for specific optimization need to be provided when registering for a module ID.

Hope this start to make some sense.

Regards,
Michel

Sent: December-09-15 2:45 PM

Hi,

  leaf B { type int32; }

 leaf B { type int32; }
 leaf A { type int32; }

Andy

On Wed, Dec 9, 2015 at 10:39 AM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:
New objects can be added to the list but the order stay the same.
Why this won’t be the case?

Regards,
Michel

Cc: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi,

Andy

Hi Ladislav, Hi Juergen

Proposed changes:

For example:

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

leaf

2014-07-03

Data node

list

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

container

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

list

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

/jukebox/playlist

list

2014-07-03

Data node

/jukebox/playlist/name

leaf

2014-07-03

Data node

leaf

2014-07-03

Data node

/jukebox/playlist/song

list

2014-07-03

Data node

leaf

2014-07-03

Data node

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

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

leaf

2014-07-03

3

Data node

/jukebox/library/artist

list

2014-07-03

4

Data node

list

2014-07-03

5

Data node

container

2014-07-03

6

Data node

leaf

2014-07-03

7

Data node

leaf

2014-07-03

8

Data node

leaf

2014-07-03

9

Data node

leaf

2014-07-03

10

Data node

list

2014-07-03

11

Data node

leaf

2014-07-03

12

Data node

leaf

2014-07-03

13

Data node

leaf

2014-07-03

14

Data node

leaf

2014-07-03

15

Data node

leaf

2014-07-03

16

Data node

leaf

2014-07-03

17

Data node

leaf

2014-07-03

18

Data node

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

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

leaf

2014-07-03

26

Data node

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

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

leaf

2014-07-03

3

Data node

/jukebox/library/artist

list

2014-07-03

4

Data node

list

2014-07-03

5

Data node

container

2014-07-03

6

Data node

leaf

2014-07-03

7

Data node

leaf

2014-07-03

8

Data node

leaf

2015-12-09

28

Data node

leaf

2014-07-03

9

Data node

leaf

2014-07-03

10

Data node

list

2014-07-03

11

Data node

leaf

2014-07-03

12

Data node

leaf

2014-07-03

13

Data node

leaf

2014-07-03

14

Data node

leaf

2014-07-03

15

Data node

leaf

2014-07-03

16

Data node

leaf

2015-12-09

29

Data node

leaf

2014-07-03

17

Data node

leaf

2014-07-03

18

Data node

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

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

leaf

2014-07-03

26

Data node

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

Regards,

Michel

-----Original Message-----

      same leafs.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Dec 2015 10:37:13 +0100

Hi,

I have a few additional comments/questions regarding the CBOR encoding:

1. Would it make sense to use semantic tagging (major type 6) to
   distinguish numbers or strings with special semantics? Possible
   candidates that come to my mind are instance-identifier and
   identityref values.

2. Why is the "decimal64" type encoded as an integer and not as "decimal
   fraction" (major type 6, tag 4)? Whilst the decimal value can be
   obtained by using the leaf's definition, perhaps it may simetimes be
   useful to be able to correctly interpret the values without using a
   schema.

3. I think it is necessary to include namespaces/module names in the
   encoding of identitities (sec 3.1.7). It is probably not very likely
   in that particular example, but somebody could define another
   "iana-interface-type" identity in another module. Identities were
   designed to be extensible in a decentralised fashion, so the CBOR
   encoding should IMO also represent the namespace.

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Dec 2015 10:55:16 +0100

my 2 µJ for now...

>    candidates that come to my mind are instance-identifier and

In general, the assumption has been that semantic information would come
out of the YANG schema.  Is there a case where that is not so, and we
need to represent it at the representation level?

>    obtained by using the leaf's definition, 

Because we can get the exponent value out of the schema, we don't need
to transmit it.

> perhaps it may simetimes be

Right.  We probably have to make up our mind how useful YANG-based
information should be in a schemaless environment.  If we want to make
it useful, that requires quite some different thinking than what we have
now.

>    encoding should IMO also represent the namespace.

We should take note of this problem and put it as one more objective for
the identifier discussion (the hashes vs. structured IDs vs. ... one).

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Fri, 11 Dec 2015 14:50:34 +0000

Hi Ladislav

About tagging and tag 4 specifically, the overhead require by them will need to be justified.
We need to identify which specific applications require schemaless processing of unknown data nodes.

About identitities
This issue have already been mentioned by Juergen and the current intent is to adopt the same
representation as draft-ietf-netmod-yang-json-06

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: December-11-15 4:55 AM
To: Ladislav Lhotka <[email-masked]>
Cc: Michel Veillette <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

my 2 µJ for now...

>    candidates that come to my mind are instance-identifier and

In general, the assumption has been that semantic information would come out of the YANG schema.  Is there a case where that is not so, and we need to represent it at the representation level?

>    obtained by using the leaf's definition,

Because we can get the exponent value out of the schema, we don't need to transmit it.

>    useful to be able to correctly interpret the values without using a

Right.  We probably have to make up our mind how useful YANG-based information should be in a schemaless environment.  If we want to make it useful, that requires quite some different thinking than what we have now.

>    encoding should IMO also represent the namespace.

We should take note of this problem and put it as one more objective for the identifier discussion (the hashes vs. structured IDs vs. ... one).

Grüße, Carsten

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Dec 2015 16:05:05 +0100

> On 11 Dec 2015, at 15:50, Michel Veillette <[email-masked]> wrote:
> 
> Hi Ladislav
> 

Fair enough.

> representation as draft-ietf-netmod-yang-json-06

Juergen questioned the need for a new namespace notation but if I understand correctly the example in sec. 3.1.7, in

  iana-interface-type.ethernetCsmacd

there is no namespace at all: iana-interface-type is an identity, and so is ethernetCsmacd.

Lada

---

From: Michel Veillette <[email-masked]>
Date: Fri, 11 Dec 2015 15:22:10 +0000

I plan to propose an update to section 3.1.7 based on the text of draft-ietf-netmod-yang-json-06 section 6.8.
I can either use the module name or the module ID as namespace identifier.
For compactness, I intent to initially propose the module ID.

For example, if the module ID registered for iana-if-type is 72, we will have "72:ethernetCsmacd".

Is this make sense?

Regards,
Michel

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: December-11-15 10:05 AM
To: Michel Veillette <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Fair enough.

> 
> About identitities
> This issue have already been mentioned by Juergen and the current 
> intent is to adopt the same representation as 
> draft-ietf-netmod-yang-json-06

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Dec 2015 16:31:52 +0100

> On 11 Dec 2015, at 16:22, Michel Veillette <[email-masked]> wrote:
> 

Sure, but my impression from sec. 3.1.7 is that the encoding attempts to alleviate the need for determining the chain of identity derivations from a data model and simply encode the chain in the identityref value. But maybe I am just confused.

Cheers, Lada

---

From: Michel Veillette <[email-masked]>
Date: Fri, 11 Dec 2015 19:19:09 +0000

Hi Lada

A possible solution is the assignment of an unique ID to each identify.
We already assign IDs to:
- Data nodes
- RPCs
- Input parameters
- Output parameters
- Notifications
- Notification parameters

Adding an other type of object doesn’t seem to be a big issue.
Each type of objects are managed using a different name space.

For example, with 1024 IDs assigned to a module, we can support:
- 1024 data nodes
- 1024  RPCs
- unlimited number of Input parameters (local name space always allocated from 1)
- unlimited number of Output parameters  (local name space always allocated from 1)
- 1024  Notifications
- unlimited number of Notification parameters (local name space always allocated from 1)
- 1024  Identities

We can also allocate consecutive or disjoint ranges of IDs to the same module which avoid the issue
of establishing a hard limit of objects within a module.

Regards,
Michel

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: December-11-15 12:01 PM
To: Michel Veillette <[email-masked]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Hi Michel,

> On 11 Dec 2015, at 17:24, Michel Veillette <[email-masked]> wrote:
> 
> Hi Lada
> 
> I things I will need some help with identity ref.
> 
> If I take the example in RFC6020:
> 
>  "des3" identity defined in the "des" module is encoded as follow:
>   <crypto xmlns:des="http://example.com/des">des:des3</crypto>
> 
> What is the corresponding encoding in JSON?
> 
>   Is it "des:des3" ?

Yes, but the example is in fact quite confusing because "des" is the the module name, prefix and identity name. So the XML encoding is in fact "des-prefix:des3", and JSON encoding is "des-module-name:des3"

> 
> What is the impacts of not encoding the chain of identity derivations on the target device?

The device has to look up in the data model whether the identityref value is an identity that is derived (transitively) from the base identity specified for that identityref leaf. In the crypto example, if we have

leaf algorithm {
  type identityref {
    base "crypto:crypto-alg";
  }
}

then permissible values for an "algorithm" instance are: "des", "des3" and "aes", provided that the server advertised all three modules.

Note also that in YANG 1.1 "multiple inheritance" of identities is allowed, so in general it won't be a linear chain but a directed acyclic graph.
  
> Why we have this chain of identity derivations at the first place?

It enables some kind of object-orientation with inheritance. 

> Is it require only by the source device to known the list of available identities?

Available identities are those defined in modules advertised by the server/device.

Cheers, Lada

> 
> Thanks for your help
> Regards,
> Michel
> 
> ============================================================
> 
> module crypto-base {
>  namespace "http://example.com/crypto-base";  prefix "crypto";
> 
>  identity crypto-alg {
>    description "Base identity from which all crypto algorithms are 
> derived.";  } }
> 
> module des {
>  namespace "http://example.com/des";
>  prefix "des";
>  import "crypto-base" {
>    prefix "crypto";
>  }
> 
>  identity des {
>    base "crypto:crypto-alg";
>    description "DES crypto algorithm";  }
> 
>  identity des3 {
>    base "crypto:crypto-alg";
>    description "Triple DES crypto algorithm";  } }
> 
> module my-crypto {
>  namespace "http://example.com/my-crypto";  prefix mc;  import 
> "crypto-base" {
>    prefix "crypto";
>  }
> 
>  identity aes {
>    base "crypto:crypto-alg";
>    }
>    leaf crypto {
>      type identityref {
>      base "crypto:crypto-alg";
>    }
>  }
> }
> 
> ============================================================
> 
> Sent: December-11-15 10:32 AM
>> Juergen questioned the need for a new namespace notation but if I 
>> understand correctly the example in sec. 3.1.7, in
>> 
>>>> 2. Why is the "decimal64" type encoded as an integer and not as 
>>>> "decimal  fraction" (major type 6, tag 4)? Whilst the decimal value 
>>>> can be  obtained by using the leaf's definition,
>>> 
>>>> 3. I think it is necessary to include namespaces/module names in 
>>>> the encoding of identitities (sec 3.1.7). It is probably not very 
>>>> likely in that particular example, but somebody could define 
>>>> another "iana-interface-type" identity in another module. 
>>>> Identities were designed to be extensible in a decentralised 
>>>> fashion, so the CBOR encoding should IMO also represent the namespace.
>>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Dec 2015 16:29:42 -0800

> split), which we might be able to subject to a tighter development regime.

IMO this is the only realistic path to cover the wide range of use-cases.
Some outside organization (not IANA) can number modules and objects based on
the expected frequency of use, alphabetical sort, or whatever.

There has been some discussion offline, and some text in the CoMI draft.
2 approaches have been discussed:

  1) different entry points  (/mg or /cool, maybe both in the same server)
      pros: simple and low impact
      cons: not flexible enough if managed and hashed objects depend on
each other
      (e.g., standard module is registered/managed and vendor extension is
hashed)

  2) use a bit in the object ID to tell the ID types apart
      pros: allows seamless integration of both types of modules
      cons: adds 1 bit to every ID; neither type wants bit 31 always set;
                not really needed if the server only has 1 kind of module

Andy

---

From: peter van der Stok <[email-masked]>
Date: Mon, 14 Dec 2015 09:13:08 +0100

> the expected frequency of use, alphabetical sort, or whatever.

I would be very disappointed by a solution that does not at least cover
the currently known representations of YANG object identifiers.

Peter