Subject: [netmod] Y25: make enum numbering purely informative and optional

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Mar 2014 12:17:14 +0100 (CET)

Hi,

We had a discussion about this on the ML, leading up to errata 3871,
which clarifies the procedure.

Which problem do we solve by removing this?  Why isn't the
clarification of the procedure good enough?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Mar 2014 13:28:08 +0100

> clarification of the procedure good enough?

I think I explained it in the description:

- Enumerations that don’t have explicit “value” statements are difficult to update, except for appending new enums at the end.

- Putting “value” statements everywhere is a nuisance for both writers and readers, especially with long enumerations.

- Sec. 9.6.4.2 states the values are unused by YANG, which is not true.

- From the interoperability point of view, the values are irrelevant, so it is no clear what problem is solved by having the rule in Sec. 10.

- Removing the auto-numbering procedure simplifies the YANG spec (tiny bit, but still…)

Lada 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Mar 2014 14:10:27 +0100

> clarification of the procedure good enough?

As technical contributor, I tend to agree with Lada that this
auto-numbering feature serves no clear value and has caused
problems. I would not mind getting rid of it in 1.1.

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Mar 2014 15:14:00 +0100 (CET)

> problems. I would not mind getting rid of it in 1.1.

I think this would be problematic.  It is there in 1.0 for
implementations to use, and implementations use it.  Yes, it may put
some additional burden on the module writer if a module is updated,
but I think we can live with that.

Also note that the "bits" type ("position" statement) behaves in a
similar way.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Mar 2014 07:37:37 -0700

On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka <[email-masked]> wrote:

> - Enumerations that don't have explicit "value" statements are difficult
> to update, except for appending new enums at the end.
>
> - Putting "value" statements everywhere is a nuisance for both writers and
> readers, especially with long enumerations.
>
> - From the interoperability point of view, the values are irrelevant, so
> it is no clear what problem is solved by having the rule in Sec. 10.
>
> - Removing the auto-numbering procedure simplifies the YANG spec (tiny
> bit, but still...)
>
>
We went through this before.
The rules in section 10 do not allow a value-stmt or position-stmt value to
change.
There is no problem updating enums. The RFC says how to do this.
Removing the value for some enums does not solve any problem.

> > /martin
Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Mar 2014 15:39:02 +0100

> implementations to use, and implementations use it.  Yes, it may put

I don’t see any risk of interoperability problems because the client and server only talk to each other in terms of enum names. They cannot even tell whether they use the same assignment of values.

If an enumeration doesn’t have the “value” statements and an enum is deleted somewhere in the middle, an implementation can use the original assignment - there is no need for the renumbering that is mandated in 6020.   

> but I think we can live with that.

The burden is also on the module reader side - an enum without a value statement is a one-liner, with it it is three lines.

> Also note that the "bits" type ("position" statement) behaves in a

The bit positions are important for the canonical value, so it is different.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Mar 2014 15:50:30 +0100

On 24 Mar 2014, at 15:37, Andy Bierman <[email-masked]> wrote:

> The rules in section 10 do not allow a value-stmt or position-stmt value to change.

Not true for enums that don’t have the value statement.

> Removing the value for some enums does not solve any problem.

There is no need to remove anything, only writers of new enums will not have to bother with the values where they make no sense.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Mar 2014 07:53:40 -0700

> Also note that the "bits" type ("position" statement) behaves in a

I strongly agree.
I think we need to follow some design principles.

#1 is "Do not break YANG 1.0 clients, except as a last resort"

There is no way this "confusing" enum auto-numbering is breaking the
network.  Errata has been written to clarify the procedure.
Sec 10 says the values are not allowed to change.

IMO this problem has already been solved and breaking YANG 1.0 apps
for no reason is really bad engineering.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Mar 2014 08:03:31 -0700

On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka <[email-masked]> wrote:

> > - Putting "value" statements everywhere is a nuisance for both writers
> and readers, especially with long enumerations.
> >
> Not true for enums that don't have the value statement.
>
>
Are you saying the clarified auto-numbering procedure is broken?
You need to add new enums at the end of the list or the auto-numbering
changes.
Same as it has been for C code forever.

Even if you had explicit value-smts (e.g., 11, 12, 13, 14)
you still cannot add enums in the middle of the list, unless
you plan the numbering in advance to allow it.

> There is no need to remove anything, only writers of new enums will not
> have to bother with the values where they make no sense.
>
>

You seem to be saying that the ability to add enums to the middle of the
list
is more important than having numbers at all.  If so, then the enum and
position
statements should be removed completely.

IMO they are very confusing precisely because they are not used in NETCONF
or RESTCONF at all.  For binary encoding, a tool could easily auto-assign
all the values.  The binary to string mapping just needs to be unique.
Letting the user specify explicit values for properties that do not actually
exist in any protocol seems pointless.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Mar 2014 16:37:16 +0100

On 24 Mar 2014, at 16:03, Andy Bierman <[email-masked]> wrote:

> You need to add new enums at the end of the list or the auto-numbering changes.

But you cannot delete an enum, which is sometimes needed.

> Same as it has been for C code forever.

Some languages (even older than C) define enumerations without numeric values.

> you plan the numbering in advance to allow it.

Why not? There is no requirement that the values must be increasing.

> You seem to be saying that the ability to add enums to the middle of the list
> is more important than having numbers at all.  If so, then the enum and position

Do you mean “… value and position statements …”? We cannot remove them because that could break existing modules. Also, the bit positions are different because their relative order determines the canonical value that appears on the wire.

> exist in any protocol seems pointless.

Agreed, and since we cannot remove the statement due to backward compatibility requirement, my proposal just tries to make it harmless.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Mar 2014 09:11:53 -0700

On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > - Enumerations that don't have explicit "value" statements are
> difficult to update, except for appending new enums at the end.
> > >
> > > - From the interoperability point of view, the values are irrelevant,
> so it is no clear what problem is solved by having the rule in Sec. 10.
> > >

You cannot delete an enum, with or without explicit value-stmts.
It would break old clients (by taking away a value that used to work)
and violate sec. 10 rules.  The only change allowed
is to deprecate or obsolete the definition and create a new one.

> Why not? There is no requirement that the values must be increasing.

true -- if you want to do this, you could add explicit value-stmts to
the auto-numbered enums that follow the new enum.  So there is
a way in YANG to add enums to the middle of a list if you want.

I've run into enum additions many times over the years in MIB modules,
and adding new enums at the end was never seen as a problem.
Why is it a problem for YANG?

> Do you mean "... value and position statements ..."? We cannot remove them
> because that could break existing modules. Also, the bit positions are
> different because their relative order determines the canonical value that
> appears on the wire.
>
> >
> Agreed, and since we cannot remove the statement due to backward
> compatibility requirement, my proposal just tries to make it harmless.
>
>

I think they are already harmless.
They are carried over from SMIv2, where the values actually mattered.

The current scheme provides 1 mandatory-to-implement auto-numbering
scheme.  I don't see how I would get the same behavior from every YANG tool
if this was made optional.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Mar 2014 17:44:08 +0100

> It would break old clients (by taking away a value that used to work)

I don’t think this is much different from the case when a new enum is added that used to be illegal.

Without intelligent conformance statements, a mismatch in module versions is IMO always risky.

> Why is it a problem for YANG?

I understood it was a problem for the timezone enumeration.

> if this was made optional.

Why do you need a universal numbering scheme if the numeric values have only local meaning and are never exchanged between the server and client?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Mar 2014 10:25:37 -0700

On Mon, Mar 24, 2014 at 9:44 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > > - Putting "value" statements everywhere is a nuisance for both
> writers and readers, especially with long enumerations.
> > > >
> > > > - From the interoperability point of view, the values are
> irrelevant, so it is no clear what problem is solved by having the rule in
> Sec. 10.
> > > >
> > > > - Removing the auto-numbering procedure simplifies the YANG spec
> (tiny bit, but still...)
> > > >
> > > >
> I don't think this is much different from the case when a new enum is
> added that used to be illegal.
>
>

It is much different.  We even have a name for it -- the Bonica Principle
(since it was described by Ron at an early YANG interim meeting).

Basically, you can expand the value set over time but you cannot contract
it.
This is core old-manager/new-agent stuff. An old manager will not use the
new values
it does not know about.  As long as the old values don't change, new values
can be added at any time.

> Without intelligent conformance statements, a mismatch in module versions
Not if sec. 10 rules are followed.

> I understood it was a problem for the timezone enumeration.

Now that it is gone -- problem solved ;-)

I agree keeping enums in some sorted order is more reader-friendly.

Maybe we are forgetting that an old YANG 1.0 tool will never read a YANG
1.1 module.

What if we eliminate auto-numbering in YANG 1.1?
Only explicit value/position statements declare any value.
There are no auto-assigned numbers at all. (Not optional).

IMO, the value/position stmts are misleading unless they have some
correlation value
to the operational network.  They should be explicit when they have meaning
and they should be absent if they have no meaning (other than arbitrary
numbering).

> > > There is no need to remove anything, only writers of new enums will
> not have to bother with the values where they make no sense.
> > >
> > >
> > >
> Why do you need a universal numbering scheme if the numeric values have
> only local meaning and are never exchanged between the server and client?
>
>
Because automation tools use YANG in protocol implementations?
(IMO, they could auto-generate code-point values, and the YANG module
does not need to provide them).

If they have explicit values (especially bits) then I can see how this info
could directly map to binary implementations.

Lada
Andy