Re: Defvalues of Enums

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Cc: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Sent: Wednesday, April 14, 2004 1:15 PM
> Subject: Re: Defvalues of Enums


...
> >And I'll point out that this is true, but the SMI's
> >enumerated integers is patterned after the ASN.1 enumerated type, and
> >for the enumerated type values can only be expressed as "labels".
...

If this had really been the intent, then it would have made much
more sense to USE the ASN.1 enumerated type, rather than
reinventing it.  The argument about "that would mean using another
tag" wouldn't hold water, in the face of what was done with
Counter, Gauge, etc. way back in the days of RFC 1155.
The current definitions just say that the value notation needs
to be appropriate to the object's type, and in this case that
underlying type is INTEGER rather than ENUMERATION.

I do agree that it's probably better from a human point of view
to use the labels, but there is nothing in the current documents
to support requiring it.  *If * there is a consensus that labels are
the preferred way to go, then the review guidelines should be
updated accordingly, and tool providers can decide whether
there is value in generating an appropriate warning.

>Note that if you want to follow Randy's argument, then one
>should allow SYNTAX clauses like the following, since they
>are valid ASN.1:
>  SYNTAX Integer32 { negone(-1), zero(0), ninety(90) } (-100..100)
...

There is a *lot* of value to being able to do this, especially when
there are "sentinel values" in a range for cases like "any" or "none"
or "unknown."  However, this would be a whole 'nother discussion.

Randy