Re: Gauge32 as an INDEX (was: Index values of zero)

[Andy Bierman <abierman@cisco.com>]

At 02:53 PM 1/2/2003 -0800, C. M. Heard wrote:
>On Thu, 2 Jan 2003, Randy Presuhn wrote:
>> > Date: Sun, 29 Dec 2002 12:04:31 -0800 (PST)
>> > From: "C. M. Heard" <heard@pobox.com>
>> > To: "Mreview (E-mail)" <mreview@ops.ietf.org>
>> > Subject: Re: Index values of zero
>> > In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15583D7A5@nl0006exch001u.nl.lucent.com>
>> > Message-ID: <Pine.LNX.4.10.10212291159550.26846-100000@shell4.bayarea.net>
>> ...
>> >    The above is a direct translation of the INDEX rules in RFC 2578
>> >    Section 7.7 up to and including bullet (1).  Although not forbidden
>> >    by RFC 2578,  using objects of type Gauge32 in an INDEX clause is NOT
>> >    RECOMMENDED under these guidelines.
>> ...
>> 
>> What is so dangerous about the use of Gauge32 as an
>> index that it should warrant a "NOT RECOMMENDED"?
>
>The original text treated Gauge32 and Unsigned32 as synonymous, and
>both Juergen and Bert voiced objections on the grounds that the special
>semantics attached to Gauge32 make it an inappropriate SYNTAX for a
>variable that appears in an INDEX clause.  That is, it was perceived as
>something that you SHOULD NOT do.  I had to agree with that, because I
>can't think of a situation where I would want to use Gauge32 in an INDEX
>clause other than in a MIB module that was translated from SMIv1.

And thus another crappy little rule is born!

I think we should not add this CLR.  There are 2 independent decisions
to be made here by a MIB designer; (1) the appropriate data type for
a specific object and (2) the appropriate choice of INDEX components
for a specific table.  Although unlikely, it is possible a gauge
could be used in an INDEX for a table with multiple INDEX components,
in order to achieve a particular sort order.  For example, a gauge
representing the number of fizbins in use could be used in an INDEX
for a table so the NMS can retrieve only the entries above or below
a specific fizbin-in-use threshold.

I agree with Randy on this one.


>//cmh

Andy