[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Discuss on draft-ietf-adslmib-hc-tc-06.txt
Inline
> -----Original Message-----
> From: Margaret.Wasserman@nokia.com
> [mailto:Margaret.Wasserman@nokia.com]
> Sent: woensdag 15 oktober 2003 20:22
> To: iesg@ietf.org
> Subject: Discuss on draft-ietf-adslmib-hc-tc-06.txt
>
> I have entered a discuss on draft-ietf-adslmib-hc-tc-06.txt.
> Please see my comments below.
>
> Margaret
>
> DISCUSS comments on draft-ietf-adslmib-hc-tc-06.txt:
>
> > This document presents a set of High Capacity Textual Conventions
> > for use in MIB modules which require performance history based upon
> > 15 minute intervals. The Textual Conventions defined in this
> > document extend the conventions presented in RFC 3593 to 64 bit
> > resolution using the conventions presented in RFC 2856.
>
> This isn't really true. This document takes an entirely
> different approach from RFC 3593, which only specifies two
> TCs, and provides a template for three variables that
> every MIB must contain that uses the RFC 3593 TCs. I
> believe that the 32-bit and 64-bit mechanisms for handling
> 15-minute counters should be consistent.
>
For all I can tell THEY ARE consistent in the sense that you can do
the same with these TCs as you can do with the TCs in 3593, but then
for 64bit values.
It adds a few things that allows you to do extra things.
I do not see what problem that creates?
> IMO, both this document and RFC 3593 are overly restrictive.
> Why are "15 minutes" or "96 intervals" magic numbers? Do
> they come from some telecommunications requirements?
>
It is an old telecom thing indeed. And the 3593 came from the old
trunkmib work to represent data that these people use.
So they are indeed magic numbers in that industry.
Are they still usefull? It was questioned in the atommib WG
a few years back, but as far as I can tell there is consensus in
those WGs that they indeed still do make sense.
So do we want to make 3593 historic because we find this "strange" ??
> > hcPerfHistTCMIB MODULE-IDENTITY
> [...]
> > In certain cases (e.g., in the case where the agent is a
> > proxy) it is possible that some intervals are unavailable.
> > In this case, this interval is the maximum interval number
> > for which data is available."
>
> There is no explanation for why the use of a proxy would
> cause information for some intervals to be unavailable
> and/or how the agent would know that a proxy was in use,
> so that it could report a different value. Please explain.
>
The above text is from HCPerfValidIntervals DESCRIPTION clause.
I believe such can be the case if the "proxy" did not have access
to the real data (agent) for some intervals. I will check with
author(s).
> EDITORIAL COMMENTS on draft-ietf-adslmib-hc-tc-06.txt:
>
> >Since RFC 3593 was only published in Sept 2003, I wonder
> >the authors of this document decided to depart so far from
> >it.
> >
I do not see they do. Maybe you can be more explicit why you think they do.
> > HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
> > STATUS current
> > DESCRIPTION
> > "The number of near end intervals for which no data is
>
> The term "near end intervals" isn't meaningful to me. Is
> this a technical term from another context? If so, a reference
> might be helpful.
>
I will ask for clarification.
Pls do realize that the same/similar text exists in RFC3593, albeit in
ASN.1 comment lines:
-- xyzValidIntervals OBJECT-TYPE
-- SYNTAX INTEGER (0..<n>)
-- MAX-ACCESS read-only
-- STATUS current
-- DESCRIPTION
-- "The number of previous near end intervals
-- for which data was collected.
> > This count represents a non-negative integer, which
> > may increase or decrease, but shall never exceed 2^64-1
> > (18446744073709551615 decimal), nor fall below 0.
>
> It seems unnecessary to define the range that an unsigned
> 64-bit integer can assume, and it is especially wordy to
> do this in three separate places in this MIB.
>
Matter of taste I guess, no?
Bert