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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I asked Keith what he thinks about this (Keith was one of the
3 STD58 editors) that I checked with when I came up with
my guidelines that Mike used as a basis for the initial
draft. Here is his response.

Thanks,
Bert 

-----Original Message-----
From: Keith McCloghrie [mailto:kzm@cisco.com]
Sent: vrijdag 3 januari 2003 16:56
To: bwijnen@lucent.com
Cc: kzm@cisco.com
Subject: Re: FW: Gauge32 as an INDEX (was: Index values of zero)


> Any opinion?
 
On Gauge32, I agree with Randy.  Using a Gauge32 as an auxiliary object
is a matter of MIB design; it may be bad in some/most cases, but that
doesn't necessarily mean it's always bad.

As for 0, I think "a good reason MUST be specified" is bogus; where
must it be specified ?  and who decides whether it's good or not ??
If someone does use 0, they presumably have a reason which they think
is a good reason, and if they specify it in private, then they have
complied with this rule.  Thus, all the rule really means is that the
index value of 0 shouldn't be used arbitrarily, which I think is
already better expressed in the SMI as:
                                               ...  The use of zero as
   a value for an integer-valued index object should be avoided, except
   in special cases.

If there's anything lacking in that sentence from the SMI, it's that
there are two types of special cases:

1. when 0 is semantically meaningful (e.g., a temperature of 0, or 
   an IP-address of 0.0.0.0)
2. when 0 has a special meaning (e.g., InterfaceIndexOrZero).

> I do not have you on mreview team at the moment.
> I could of course add you as a reader of the mailing list.
> Let me know if you want that.

As they say: thanks, but no thanks :-).

Keith.

> Thanks,
> Bert 
> 
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: vrijdag 3 januari 2003 4:35
> To: mreview@ops.ietf.org
> Subject: RE: Gauge32 as an INDEX (was: Index values of zero)
> 
> 
> >>>>> 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
> 
>