[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
- To: "Mreview (E-mail)" <mreview@ops.ietf.org>
- Subject: FW: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Fri, 17 Oct 2003 20:29:01 +0200
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