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

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,

[cid:image001.jpg@01C868D8.BF0BB7E0]

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-531-3109

From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: December-08-15 9:52 AM
To: Alexander Pelov <a@ackl.io>
Cc: Core <core@ietf.org>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

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 <a@ackl.io<mailto:a@ackl.io>> 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

Le 08/12/2015 12:53, Juergen Schoenwaelder a écrit :
On Tue, Dec 08, 2015 at 12:11:00PM +0100, Alexander Pelov wrote:
Dear Juergen,

See inline.
Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> a écrit :

On Tue, Dec 08, 2015 at 11:16:58AM +0100, Alexander Pelov 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.
So I need access to the complete revision history in order to determine
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.
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).
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.
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

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core

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

Attachment: image001.jpg

Attachment: image001.jpg