[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: vrijdag 17 oktober 2003 21:02
> To: Mreview (E-mail)
> Subject: Re: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
>
>
> 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.
>
Maybe the solution is as simple to add some explanatory text.
> The "HC" in the names is there because of naming recommentations
> in appendix C of the mib review guidelines.
>
> Randy
>
Bert
> > 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
> >
>
>
>