Subject: [core] YANG encoding issue for CoMI

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 09:08:07 -0800

Hi,

One significant issue not addressed in the CoMI draft is
the encoding of the 'enumeration' and 'bits' data types.
Currently, the identifier names are encoded as a string.

If the 'value' or 'position' numeric values were used instead,
the binary encoding would be about 10X smaller for enums
and 10X - 100X smaller for bits.

Since CoMI will use its own YANG-to-CBOR mapping,
this change would not impact the YANG RFC.

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Feb 2015 18:13:51 +0100

Hi Andy,
> Currently, the identifier names are encoded as a string.

What is the extension model here?
I.e., how can we expect the set of enumeration values, or the set of
bits, to evolve over time?  Is the addition linear, or do we have to
cope with cacti?

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Feb 2015 18:16:23 +0100

> this change would not impact the YANG RFC.

Not sure everybody understands but in YANG 1.0, there is a defined
numeric value for enums and bits. There is a proposal to change that
in YANG 1.1 but the final call on this has not been made. The outcome
of this decision may impact the CBOR encoding decision.

/js

-- 
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: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 09:25:29 -0800

> bits, to evolve over time?  Is the addition linear, or do we have to

YANG 1.0 has auto-numbering of enums and bits that do not explicitly
define a number. Once a number has been assigned (auto or manual)
it can never be changed.

YANG 1.1 is considering the removal of this permanent numbering,
which would not be good for CoMI.

The enumeration or bits definitions have to be directly edited in
a new revision of the module, which can only add previously
unused values. They cannot be extended from another module.

It is a data model designer decision whether to extend enum or bits vs.
define a new typedef with a new name.  I am not convinced that
the former should even be allowed in YANG.

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Feb 2015 18:30:12 +0100

> which would not be good for CoMI.

Is there an issue tracker or some other document/message that explains
the rationale for this proposal?

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 10:01:02 -0800

> the rationale for this proposal?

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-26

The rationale is that is more user-friendly to readers/writers of YANG modules
to be able to insert new enums/bits in the middle of an auto-numbered list
(causing it to renumber).

Currently, a new value has to put at the end, or explicit (non-sequential)
numbering added to existing nodes.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 00:01:05 +0100

> numbering added to existing nodes.

I think the real concern is that the order in which enums are defined
must never be changed. If someone inserts something new instead of
appending or for some other reasons enum definitions are reordered,
interoperability is lost. Since NETCONF and RESTCONF never use the
number on the wire, the proposal was to get rid of the autonumbering
feature. With a CBOR encoding, the assumption that these numbers are
never used on the wire might change.

Another option is to 'deprecate' auto-numbering and to force module
writers to explicitly assign values since this is less brittle when it
comes to module updated.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Feb 2015 08:03:14 +0100

> With a CBOR encoding, the assumption that these numbers are

Indeed.  The functionality of YANG seems to fit our needs here very
well.  Having been there for half a decade, it should not be removed for
convenience reasons now (and, conversely, it is no longer true that this
functionality is just "for the convenience of implementers").

Of course, we have lots of experience demonstrating how maintaining a
linear number space during the evolution of a protocol is a pain, so I
feel with the proposers of Y25.  If there is some possible innovation in
the YANG format that might help with this, that should be pursued (I'm
skeptical though whether a good solution will be found in time for Yang
1.1).  Much of this could be automated in tools, by the way; having the
number assignment look a bit less intrusive might help with acceptance
of that automation.

Another hack to ease the pain would be requiring to maintain the
evolutionary path only for specifications that need to be efficient for
constrained nodes.  It may be hard to reliably keep apart the spaces,
though.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 08:12:58 +0100

> number assignment look a bit less intrusive might help with acceptance

I do not understand you comment about 'linear space'. YANG supports
identities in case a centrally maintained set of enums does not work.
The concern behind Y25 is that auto-numbering can lead to subtle
errors while updating a YANG module.
 
> constrained nodes.  It may be hard to reliably keep apart the spaces,

I think this is to be avoided.

/js