[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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