Subject: Re: [netmod] enumeration type

From: Randy Presuhn <[email-masked]>
Date: Wed, 22 Jan 2014 02:17:23 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Jan 22, 2014 1:18 AM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] enumeration type
... 
>> Which leads to the question: why does the value
>> field even exist?
>
>I can imagine use cases where the numeric value has some intrinsic meaning, e. g.
>
>enum January {
>    value 1;
>}

I don't really see any "intrinsic meaning" to the value 1
in this case, particularly since that value doesn't show up
"on the wire", nor is it used to, for example, govern sorting.

It sounds like the value is there only to potentially trigger
error messages from compilers, and not to in any way foster
interoperability or affect the operation of gear.

Randy

---

From: Jonathan Hansford <[email-masked]>
Date: Wed, 22 Jan 2014 10:30:41 +0000

On 2014-01-22 10:17, Randy Presuhn wrote:

> Hi -
>
>> From: Ladislav Lhotka <[email-masked] [1]> Sent: Jan 22, 2014 1:18 AM
>> To: Randy Presuhn <[email-masked] [2]> Cc:
>> [email-masked] [3] Subject: Re: [netmod] enumeration type
>
> ...
>
>>> Which leads to the question: why does the value field even exist?
>> I can imagine use cases where the numeric value has some intrinsic
>> meaning, e. g. enum January { value 1; }
>

And if the value has no "intrinsic meaning" then there is no reason 
why, if a value is not specified, the assigned value should be one 
greater than the current highest enum value (other than to make parsing 
the enumeration statement easier). A two-pass parse would allow the 
parser to assign any previously unassigned value (whether explicit or 
implicit) and a parser error would only occur if the full value space 
were used up (perish the thought).

Can anyone explain why enumerations were originally given values, if 
they have no intrinsic meaning (other than the fact that calling them 
enumerations implies that numbers are involved)?

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

Links:
------
[1] mailto:[email-masked]
[2] mailto:[email-masked]
[3] mailto:[email-masked]

---

From: Per Hedeland <[email-masked]>
Date: Wed, 22 Jan 2014 12:03:01 +0100

On 2014-01-22 11:30, Jonathan Hansford wrote:
> And if the value has no "intrinsic meaning" then there is no reason why, if a value is not specified, the assigned value should be one greater than the current highest enum value (other than to make
> parsing the enumeration statement easier). A two-pass parse would allow the parser to assign any previously unassigned value (whether explicit or implicit) and a parser error would only occur if the
> full value space were used up (perish the thought).
> 
> Can anyone explain why enumerations were originally given values, if they have no intrinsic meaning (other than the fact that calling them enumerations implies that numbers are involved)?

Well, 6020 somewhat vaguely says "carried as a convenience to
implementors", which I take to mean implementors of data stores and
instrumentation. It can be a considerable space saving to store (stable)
32-bit integers instead of arbitrary strings, and in (e.g.) C
instrumentation, it is "nice" to be able to switch() on (stable) values
instead of doing a bunch of strcmp()s. Neither of these "conveniences"
apply in the specific case of the timezone enumeration, though.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Jan 2014 12:21:27 +0100

> "on the wire", nor is it used to, for example, govern sorting.

I mean the numbers might sometimes be used instead of names in some contexts, though not in NETCONF. I do admit it is a rather weak use case.
 
> interoperability or affect the operation of gear.

Yes, they can only trigger error messages and complicate updates of modules with such enumerations.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Jan 2014 12:49:39 +0100

> apply in the specific case of the timezone enumeration, though.

Fair enough, but there is no need that everybody uses the same internal name-value mapping.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jan 2014 13:33:53 +0100

On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jonathan Hansford wrote:
> they have no intrinsic meaning (other than the fact that calling
> them enumerations implies that numbers are involved)?
> 

As far as I recall, they were originally designed this way at the
Stockholm meeting (that is months before the YANG work came to the
IETF) in order to support some coexistance with other protocols that
happen to use numbers instead of strings on the wire for enumerations.

Looking at it from today's perspective, I tend to believe the
automatic assignment of values was not a very smart choice (since
using it is very dangerous when it comes to updates) and in hindsight
it might have been better to allow values as an optional feature of an
enum that YANG data model designers can use but are not required to
use.

/js

PS: I do feel somewhat guilty for this design but I am not sure who
    actually had this automated numbering idea and it probably does
    not matter. Back in London, I started coding what several years
    later became RFC 6643, but for that I did not need automated
    numbering.

-- 
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: Xiang Li <[email-masked]>
Date: Wed, 22 Jan 2014 07:57:49 -0600

While I tend to agree that the automatic numbering is not very useful, but
since it already managed to be there so I prefer to consider it as a
'feature'. When I read the texts in RFC6020 again and again, I actually
think the meaning of "the highest enum value" is arguably clear (that
it is different
from c interpretation), but it may be only me thinks this way...

 -- Xiang Li

---

From: Jonathan Hansford <[email-masked]>
Date: Wed, 22 Jan 2014 15:15:55 +0000

On 2014-01-22 12:33, Juergen Schoenwaelder wrote:

>> them

Having looked through some historical documents, it may also have 
arisen from the draft-bjorklund-yang-requirements-00 response ("SMIv2 
style enumerations are fully supported in YANG.") to RFC 3216 "SMIng 
Objectives", section 4.1.17 "Enumerations":

    Type: basic

    From: SMI, SPPI

    Description: SMIng must provide support for enumerations.  
Enumerated
       values must be a part of the enumeration definition.

    Motivation: SMIv2 already has enumerated numbers.

    Notes: Enumerations have the implicit constraint that the attribute
       is constrained to the values for the enumeration.

---

From: David Spakes <[email-masked]>
Date: Wed, 22 Jan 2014 11:03:07 -0500 (EST)

On Wed, 22 Jan 2014, Ladislav Lhotka wrote:

> I mean the numbers might sometimes be used instead of names in some
> contexts, though not in NETCONF. I do admit it is a rather weak use
> case.

> Objectives", section 4.1.17 "Enumerations":

One of the most important lessons for management architecture design
that resulted from SNMP experience over the past 25 years is that you
should keep the specifications of protocol, data definition language,
and managed objects independent of one another.

If someone were to argue that numeric values for enumerations are not
important because NETCONF doesn't need them, I would reply that their
argument is short-sighted.  YANG modules that are created in the
present may be used with other protocols that emerge in the future or
existing protocols designed in the past.  Design decisions that hinder
multiple uses of a technology can serve to slow or stop enterprises
from adopting that technology.

In my opinion, it would have been better to require that a numeric
value be explicitly defined for every enumeration.  However, the
automatic assignment of numeric values is acceptable as long as the
values are not changed by a subsequent revision of the document.
Also, the procedure to arrive at the automatically assigned values
must be absolutely clear to every reader.

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 08:21:08 -0800

> must be absolutely clear to every reader.

If the numeric values have some semantics (e.g., matching port numbers)
then the value-stmt might help an application.  Otherwise
the value-stmt is just clutter.  Auto-assignment will comply
with sec. 10 (updates) if new enums and bits are always added
at the end of the list.

> -dss

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jan 2014 17:58:39 +0100

> with sec. 10 (updates) if new enums and bits are always added

The problem is that not many people will understand that changing the
order causes interoperability problems. So I would strongly recommend
against the usage of automatic assignments. It is not robust enough.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 09:19:42 -0800

> against the usage of automatic assignments. It is not robust enough.
Either way I have to remember a clever little rule -- always add an
explicit value-stmt, or always add new enums at the end of the list.
I never bother to use the value-stmt if the enum is just an arbitrary
integer.  The auto-assign can do that for me.

/js

Andy

---

From: B Lukovic <[email-masked]>
Date: Wed, 22 Jan 2014 17:24:09 -0500

Could you clarify interoperability problem with changing order of enums?
My understanding is that Netconf mgrs/agents do not use enum value in 
communication.

Borislav

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jan 2014 23:55:52 +0100

On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:

> My understanding is that Netconf mgrs/agents do not use enum value
> in communication.

Correct, it does not impact NETCONF exchanges. But whatever uses the
assigned numerical values may get confused if they change. If nothing
ever uses them, fine. But since YANG 1.0 provides them, there is an
unknown risk. YANG 1.0 makes this promise:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

Once YANG is widely used, I am sure we will find something somewhere
relying on this and then we may see rather obscure and hard to debug
problems. It is not a concrete and urgent issue but I personally am
happy to have this on a list of things to consider should be ever
create YANG > 1.0.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 15:24:35 -0800

Hi,

It is possible tools are already using the value-stmt.
Many tools use YANG modules. They are not just
for the client/server message exchanges.

But I could imagine a mapping to CoAP in which various strings
were automatically converted to numbers somehow.
Most enum values could be expressed in 1 byte in CoAP using the
value integer.

Andy

---

From: B Lukovic <[email-masked]>
Date: Wed, 22 Jan 2014 18:36:22 -0500

Then the argument expressed by David applies even more.
If Yang is going to be used as data modelling language for various 
protocols
then "value" for "enum" must be mandatory.
This would take away any ambiguity, not to mention simplified enum value 
validation by compiler.

Borislav

On 1/22/2014 6:24 PM, Andy Bierman wrote:
> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 16:03:00 -0800

> This would take away any ambiguity, not to mention simplified enum value
I do not agree.  The meaning of "current highest value" seems to be clear
enough to produce consistent implementations.

The RFC says the value/position values are not allowed to change
in a new revision.  I get it that somebody might violate the rules
specified in the RFC, but that is out of scope.  There are lots of
ways bad things happen if sec. 10 is violated.

There is a mandatory algorithm to follow when the value-stmt is missing,
so there is no problem in the RFC that needs fixing here.

Borislav

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 16:14:16 -0800

On Wed, Jan 22, 2014 at 4:12 PM, Jonathan Hansford
<[email-masked]>wrote:

> Just, possibly, an editorial comment confirming that "current" relates to
> those values, implicit or explicit, prior to the current position in the
> enumeration statement.
>

Agreed -- an RFC Errata should be OK for this one.

> Sent from my BlackBerry
>
> -----Original Message-----
> From: Andy Bierman <[email-masked]>
> Sender: "netmod" <[email-masked]>
> Date: Wed, 22 Jan 2014 16:03:00
> To: B Lukovic<[email-masked]>
> Cc: [email-masked]<[email-masked]>

---

From: B Lukovic <[email-masked]>
Date: Wed, 22 Jan 2014 20:04:29 -0500

I don't disagree with auto-numbering.
But, there is no guarantee that all C/C++/Java/... compilers would 
produce the enum sequence that correspond to Yang rules,
so in the end implementation would have explicitly assigned values 
(according to Yang rules) to avoid possible bug.
If this is the case, why not specify those values in Yang module itself.

Also,  when Yang module is created from existing "other" data models, in 
particular SNMP MIB,
enumerations should have values specified exactly as in the 
corresponding MIB.
This is not the case in the current release of ietf-snmp Yang modules.

Borislav

On 1/22/2014 7:03 PM, Andy Bierman wrote:
>
>
>
> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This would take away any ambiguity, not to mention simplified enum
>     value validation by compiler.
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 17:25:07 -0800

Hi,

If JAVA or other compilers implement the RFC correctly, then they will
have the correct value numbers for all enums.  This cannot be changed
with an RFC Errata -- the auto-correct can be clarified but the text is
very clear that the value-stmt is optional, so changing it to mandatory
would break existing compliant implementations.

Andy

On Wed, Jan 22, 2014 at 5:04 PM, B Lukovic <[email-masked]> wrote:

> But, there is no guarantee that all C/C++/Java/... compilers would produce
> the enum sequence that correspond to Yang rules,
> enumerations should have values specified exactly as in the corresponding
> MIB.
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Jan 2014 09:10:44 +0100

> Once YANG is widely used, I am sure we will find something somewhere

But I think it is important to clarify and rectify things where possible *before* this happens. In my view, it is possible to interpret the above sec. 10 rule so that it only pertains to old enum values that are explicitly present in previous module revisions. This also makes sense: If a modeller wants to have the values fixed and standardised, he can use the “value” statement. Otherwise, the values may be assigned at each implementor’s discretion, or not assigned at all.

> happy to have this on a list of things to consider should be ever

+1

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Jan 2014 09:59:06 +0100 (CET)

I fully agree with Andy.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jan 2014 11:29:49 +0100

On Wed, Jan 22, 2014 at 08:04:29PM -0500, B Lukovic wrote:
 
> Also, when Yang module is created from existing "other" data models,
> in particular SNMP MIB, enumerations should have values specified
> exactly as in the corresponding MIB.  This is not the case in the
> current release of ietf-snmp Yang modules.

Good catch.

I just went through all enumerations in the ietf-snmp-* modules making
sure they have explicit value assignments and that the values match
the values assigned in the MIB modules.

/js

---

From: B Lukovic <[email-masked]>
Date: Thu, 23 Jan 2014 09:23:50 -0500

It seems to me that the whole thread is related to use of Yang data 
model with protocols other than NetConf.
Yet, rfc 6020 states :

YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

I am not proposing changing rfc 6020, but since there is an interest in 
using Yang for other protocols,
next revision of it should take into account this discussion.

     Borislav

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jan 2014 16:37:01 +0100

> model with protocols other than NetConf.

No, this thread is (was) about whether the text in RFC 6020 is clear
enough or not. And we should wrap that discussion up with either the
conclusion that the text is good enough or with a concrete proposal to
improve clarity that we can agree on and post it at an appropriate
place.

/js

---

From: David Spakes <[email-masked]>
Date: Thu, 23 Jan 2014 11:24:35 -0500 (EST)

On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland <per at tail-f.com> wrote:

> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>
> > ... I think "current highest value"
> > really was meant to be "the last value (in the order of enum
> > definition)".
>
> Yes, it could also use clarification of "current highest".
>
> --Per

> improve clarity that we can agree on and post it at an appropriate

I also agree with Per Hedeland that the text needs to be clarified.
Here is a proposal for sec. 9.6.4.2:

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value; i.e., the previously encountered or
   previously assigned highest value in order of enum definition.

-dss

---

From: David Harrington <[email-masked]>
Date: Thu, 23 Jan 2014 12:16:33 -0500

Hi,

I have a concern with changing value of enums and the impact on interoperability between NMS applications and YANG modules.

Drawing on SNMP experience, we have one case that has been especially problematic - the dynamic assignment of ifIndex values. NMS applications that cache information (or build database records of information) provided by the IF-MIB, or any MIB that uses ifIndex as a way to create a relation between sets of data, have had problems with the discontinuity and subsequent changes to remotely-assigned ifIndex values. 

Interoperability for both SNMP and NETCONF (and other NMS protocols) is often related to being able to store and reference data on the NMS side by enumerated values contained in the data assigned by the agent (server).
I recommend that the interoperability issues associated with dynamically changing enums be discussed, possibly in an "operations and management considerations" section.

dbh

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jan 2014 10:01:53 -0800

Hi,

You seem to be referring to server-assigned ifIndex values.
I agree that persistence of such values should be addressed
in our standards. IMO, NETCONF does not deal with server-assigned
values very well. (is it config, is it state? We do not agree even on that).

This thread is about the schema definitions of enumeration values
that are auto-assigned by the YANG compiler.

Andy

On Thu, Jan 23, 2014 at 9:16 AM, David Harrington <[email-masked]>wrote:

> Hi,
>
> I have a concern with changing value of enums and the impact on
> interoperability between NMS applications and YANG modules.
>
> Drawing on SNMP experience, we have one case that has been especially
> problematic - the dynamic assignment of ifIndex values. NMS applications
> that cache information (or build database records of information) provided
> by the IF-MIB, or any MIB that uses ifIndex as a way to create a relation
> between sets of data, have had problems with the discontinuity and
> subsequent changes to remotely-assigned ifIndex values.
>
> Interoperability for both SNMP and NETCONF (and other NMS protocols) is
> often related to being able to store and reference data on the NMS side by
> enumerated values contained in the data assigned by the agent (server).
> I recommend that the interoperability issues associated with dynamically
> changing enums be discussed, possibly in an "operations and management
> considerations" section.
>
> dbh
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Jan 2014 08:53:27 +0100

On 23 Jan 2014, at 15:23, B Lukovic <[email-masked]> wrote:

> 
> It seems to me that the whole thread is related to use of Yang data model with protocols other than NetConf.
> Yet, rfc 6020 states :
> 

It is not only this verbal definition, other fundamental YANG concepts are defined using NETCONF-specific terms. For example, second bullet in sec. 8.1:

   o  If the constraint is defined on state data, it MUST be true in a
      reply to a <get> operation without a filter.

> 
> I am not proposing changing rfc 6020, but since there is an interest in using Yang for other protocols,

In Berlin (IETF 87), I proposed to start work on a new YANG spec that would, among other things, remove such NETCONF dependences.

Lada