Re: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt

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

Hi -

I don't see the case for changing them from Gauge32 to INTEGER,
particularly when the corresponding examples in the MIB review guidelines
use Gauge32.

The "templates" Margaret refers to are just ASN.1 comments describing
the conventions used within RFC 3593.  I don't see how there would be
a compliance requirement between an ASN.1 comment in that document
and this one.

The "HC" in the names is there because of naming recommentations
in appendix C of the mib review guidelines.

Randy

> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Friday, October 17, 2003 11:29 AM
> Subject: FW: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
>

> Nobody worried about this during IETF Last Call (or WG Last Call).
>
> Do we see this as an issue or is it OK and do we just need to add
> some explanatory text.
>
> I could see the case to change the TCs for
>     - HCPerfTimeElapsed, Gauge32 (0...86399)
>     - HCPerfValidIntervals, Gauge32 (0...96)
>     - HCPerfInvalidIntervals, Gauge32 (0...96)
> to become INTEGERs
>
> I can also see the case to rename them to
>     - PerfTimeElapsed, Integer32 (0...86399)
>     - PerfValidIntervals, Integer32 (0...96)
>     - PerfInvalidIntervals, Integer32 (0...96)
> (which is same datatype as INTEGER)
>
> Comments/viewpoints pls
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Margaret.Wasserman@nokia.com [mailto:Margaret.Wasserman@nokia.com]
> Sent: vrijdag 17 oktober 2003 19:09
> To: rray@pesa.com; bwijnen@lucent.com
> Cc: sneedmike@hotmail.com
> Subject: RE: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
>
>
>
> Hi Bob,
>
> > If I had to guess, I believe Ms. Wasserman's issue is that RFC3593
> > (and RFC2493) uses templates while the HC-TC (and RFC2856) uses
> > textual conventions.
>
> Please call me Margaret.  This Ms. Wasserman stuff is making
> me nervous... :-).
>
> Yes, this is one part of my concern.  What I am trying to
> understand is what happens when I create a MIB module that has
> both 32-bit and 64-bit counters, possibly in the same table,
> that I want to monitor in 15-minute intervals.
>
> It is not evident to me what types of variables I need to
> define in my MIB if I want to monitor a set of information
> on 15-minute intervals that includes both 32-bit and
> 64-bit counters.
>
> In particular, RFC3593 has templates that require that I have
> three variables in my MIB if I will do monitoring of 32-bit
> counters based on 15-minute intervals:
>
>     - xyzTimeElapsed, INTEGER (0...899)
>     - xyzValidIntervals, INTEGER (0...<n>), 1 <= n <= 96
>     - xyzInvalidIntervals, INTEGER (0...<n>), 1 <= n <= 96
>
> Please note that RFC 3593 did not choose to hardcode 96 intervals,
> only to indicate that 96 is a maximum.  Some MIBs could define
> xyzValidIntervals and xyzInvalidIntervals to have smaller maximums,
> I'm not sure why...
>
> The HC-TC document gives TCs for the same types of variables:
>
>     - HCPerfTimeElapsed, Gauge32 (0...86399)
>     - HCPerfValidIntervals, Gauge32 (0...96)
>     - HCPerfInvalidIntervals, Gauge32 (0...96)
>
> Please note some differences:  These are defined as Gauge32, not
> as INTEGER.  The value of 96 is a hard-coded maximum.  The
> HCPerfTimeElapsed value can be used for 24-hour buckets, not just
> 15 minute ones.
>
> So, if I have a MIB with both 32-bit and 64-bit counters that I
> want to monitor on 15-minute intervals, which model should I
> follow?
>
> Personally, I like the model in the new HC-TC better, although I
> don't know why it has been specified as specific to HC counters.
> From a technical standpoint, I think that either model will work.
> But, I'm just not sure that we should standardize two subtely
> incompatible models for doing the same thing within a few months
> of each other.
>
> The HC-TC also adds one additional concept that could be useful
> in these types of MIBs: HCPerfIntervalThreshhold.  Is there some
> reason why this would only apply to 64-bit counters?
>
> Did the WG consider the case of a single table that contains
> both 32-bit and 64-bit counters when writing this set of TCs?  If
> so, what was the conclusion?  Possibilities include:  (1) there
> is an obvious and efficient way to monitor 32-bit and 64-bit
> counters within a single table on 15-minute intervals using
> these the HC-TC and RFC 3593, and I'm just missing something,
> (2) there is some reason why no one would ever put both 32-bit
> and 64-bit counters in the same table, or (3) something else
> that I'm missing altogether.
>
> If the WG didn't consider this situation, do you agree that
> there is a valid incompatibility here that we should resolve?
> If not, why not?  If so, what do we do to resolve it?
>
> Personally, I'd rather see a single RFC (that obsoletes
> RFC 3593) that contains:
>
>     - Generic TCs for Time Elapsed, Valid Intervals,
>       Invalid Intervals and Interval Threshhold that
>       are not different for 32-bit vs. 64-bit counters.
>     - TCs for both 32-bit and 64-bit versions of
> the Current Count, Interval Count and Total Count.
>
> But, I can picture other possibilities, such as:  (1) changing
> the definitions in the HC-TC document to match RFC 3593, or
> (2) explaining in HC-TC which model should be used when both
> 32-bit and 64-bit counters are included in the same 15-minute
> interval buckets, and stating that this document updates
> RFC 3593...
>
> Maybe there are other choices?
>
> Margaret
>