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

["C. M. Heard" <heard@pobox.com>]

>>>>> On Thu, 2 Jan 2003, Presuhn, Randy wrote:

Randy> Reasoning like this led to the unfortunate situation
Randy> with 64-bit integers.  We shouldn't use our lack of
Randy> imagination as the reason for a prohibition.  When
Randy> someone *does* come up with a reason to want to do it,
Randy> we'll be guilty of yet another CLR.

You are right, of course.

Randy> Contrived Example:
Randy>
Randy> Track the topN most over-heated components in a system.
Randy> The obvious indexes for such a dynamically changing table
Randy> would be the temperature (Gauge32) and the component's
Randy> id.
Randy>
Randy> I'm sure someone else can come up with something less
Randy> contrived, or will make the argument that the Gauge32
Randy> should be Unsigned32, but my point remains: we should
Randy> not be making recommendations against a particular
Randy> construct unless we can explain exactly why using a
Randy> construct would be a bad idea.

Actually I don't find the example all that contrived.
Nor would I care to argue that Unsigned32 would be a
better choice than Gauge32.  It clearly wouldn't if
the components could be hotter than indicated because
the temperature sensors are of the sort that "max out").

>>>>> On Thu, 2 Jan 2003, Andy Bierman wrote:

Andy> I think we should not add this CLR.  There are 2 independent decisions
Andy> to be made here by a MIB designer; (1) the appropriate data type for
Andy> a specific object and (2) the appropriate choice of INDEX components
Andy> for a specific table.  Although unlikely, it is possible a gauge
Andy> could be used in an INDEX for a table with multiple INDEX components,
Andy> in order to achieve a particular sort order.
[ ... ]
Andy> I agree with Randy on this one.

I'm convinced.  I've rewritten the text in question as follows:

   - For integer-valued objects that appear in an INDEX clause or for
     integer-valued TCs that are to be used in an index column:

     - Use of Unsigned32 with a range that excludes 0 is RECOMMENDED,
       provided that the object in question does not have gauge
       semantics.  If 0 is included in the range, then a good reason
       MUST be specified.

     - Integer32 or INTEGER with a non-negative range is acceptable.
       Again, if 0 is included in the range, then a good reason MUST be
       specified.

     - Use of Gauge32 is appropriate for index objects that have gauge
       semantics.

   The above is a direct translation of the INDEX rules in RFC 2578
   Section 7.7 up to and including bullet (1) plus the penultimate
   paragraph on page 28.

//cmh