Subject: [core] ietf-cool YANG module

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2015 18:37:35 -0800

Hi,

I noticed in this YANG module in draft-veillette-core-cool-00,
there are YANG extensions to put the module-id and object IDs in the
YANG module.  If the numbering comes from these extensions,
what is to prevent 2 different modules from assigning the same module-id?

I see there is a patch-request and patch-response that look rather similar
to the ietf-yang-patch module being developed by the NETCONF WG.
There is also an ietf-cool-library module that looks rather similar to the
ietf-yang-library module being developed by the NETCONF WG.
Neither of these drafts are mentioned anywhere, such as the reference
section.

Andy

---

From: Michel Veillette <[email-masked]>
Date: Thu, 17 Dec 2015 15:34:31 +0000

Hi Andy

We are currently evaluating a solution to address two of your previous comments:
- The number of objects per YANG module should not be limited to 1024
- IDs assigned to an object shall never change between versions.

To address the first one, we are proposing the use of variable size allocation blocs and the ability to assign more that one bloc to the same module. In practice, this means that we move away of the concept of Module ID and this 20 bits / 10 bits structure within the data node identifier. To maintain and even improve message compactness, we are adopting delta encoding, a solution proposed by Laurent in Prague.

To address your second comment, we propose to introduce the .sid file. This file will contain the list of objects allocated. This file can be automatically generated by a YANG validator. This file can be publish by registrars and is used as input when a new revision is released, to extend the list of objects while preserving those already allocated.

You will find more details about these concepts and the .sid file format at the following link:
https://www.dropbox.com/s/2akirh2l8k4648i/ietf%2095%20structured%20identifiers.pptx?dl=0

Now back to your current questions:
About "what is to prevent 2 different modules from assigning the same module-id"

With the introduction of the .sid file, all proposed extensions will be removed.
The question remain, how two objects don't get the same ID.
Allocation ranges need to be managed by the different tiers involved (IANA, registrars and developers).
This is not novel, ZigBee and LWM2M do the same.
What is novel is the use of the YANG modeling language and the automatic assignment of IDs.

About "Neither of these drafts are mentioned anywhere, such as the reference section"
Effectively, references and justifications need to be added.
The current development effort is on the mapping and problem statement but I'll keep this
in mind when it will be time to address the function set.

Thanks for your comments
Michel

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: December-16-15 9:38 PM
To: Core <[email-masked]>
Subject: [core] ietf-cool YANG module

Hi,

Neither of these drafts are mentioned anywhere, such as the reference section.

Andy