[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
Bert and Margaret,
Speaking as AToM MIB WG member and technical advisor, I would
strongly object to any solution that obsoletes RFC 3593 and forces
us to recycle RFC 3592 back to PS. The methods chosen in RFC 3593
are not perfect, but they do work and are widely deployed ... see
the implementation reports for RFCs 2558 and 2493 (predecessors of
RFCs 3592 and 3593).
Addressing the main question, I think that a reasonable fix would be
to change SYNTAX values of the three TCs as Bert suggests below,
because it would then be possible to use those TCs and conform to
the templates in RFC 3593.
Mike
On Fri, 17 Oct 2003, Wijnen, Bert (Bert) wrote:
> 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
>