[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
FYI. I guess MArgaret, Bob and I should work out if a
few small clarifcations make sense.
Thanks,
Bert
-----Original Message-----
From: Bob Ray [mailto:rray@pesa.com]
Sent: donderdag 16 oktober 2003 17:25
To: Bert (Bert) Wijnen
Cc: Mike Sneed (E-mail)
Subject: Re: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
On Thu, 2003-10-16 at 05:19, Wijnen, Bert (Bert) wrote:
> Mike, Bob, can you check my responses and elaborate where needed?
>
> Thanks,
> Bert
Looks right on to me, Bert.
15 minute intervals are old magic numbers for sure. They
date back to the very first T1 lines and are VERY common
in the telecommunications world. If someone really isn't
happy with 15 minute intervals (or 96 of them), they are
free to use a manager application to poll and collect data
at whatever interval pleases them. That's my opinion and
I'm sticking to it.
The issue "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" is curious.
a) I would expect the AGENT to always know if a proxy is in use.
The MANAGER might not know if a proxy is in use. So what?
b) that data may be unavailable for some interval makes a
lot of sense if/when a line goes down. Then data is available
at one end but not from the other end. That is, say the embedded
agent resides on the central office side of a line (smart modem
on one end, dumb/cheap consumer model at the other end) and the
line is cut by some guy with a shovel (who is ignoring the signs
that say "data cable right HERE - call before digging"). The
smart end of the line acts as a proxy for the other end, for which
data is unavailable as the line is cut.
The issue "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" doesn't bother me at all.
>From my limited experience, lots of words, repetitive in the large,
are desirous in these documents, especially since they are so often
machine processed. A user EXPECTS to click on an object in a list
and get a description of that object, its data type, a description of
its data type, etc. Having a description that says, in effect, "go
see this other thing" isn't quite what they expect.
The issue "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." doesn't concern me. When one has a line with things
at each end (and sometimes in the middle, aka. repeaters), and possible
agents on each end, then the near is simply the end that the agent
is on. The far end is the other end. Technical terms. :)
The third end is something Jerry Pournelle and Larry Niven might
be able to explain.
Hope this helps! Note I didn't copy Ms. Wasserman as I'm in enough
email debates these days.
Bob
>
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: donderdag 16 oktober 2003 12:17
> To: 'Margaret.Wasserman@nokia.com'; iesg@ietf.org
> Subject: 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
--
Bob Ray <rray@pesa.com>