Re: Hank Nussbacher comments on the OPSTAT draft.

boss@sunic.sunet.se Fri, 06 March 1992 08:15 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00360; 6 Mar 92 3:15 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00916; 6 Mar 92 3:16 EST
Received: from wugate.wustl.edu by NRI.Reston.VA.US id aa00905; 6 Mar 92 3:16 EST
Received: by wugate.wustl.edu (5.65c+/WUSTL-0.3) with SMTP id AA08497; Fri, 6 Mar 1992 01:40:36 -0600
Message-Id: <199203060740.AA08497@wugate.wustl.edu>
Date: Fri, 06 Mar 1992 08:40:10 +0100
From: boss@sunic.sunet.se
Sender: "ONC List Processor V0.2" <listserv@wugate.wustl.edu>
Reply-To: oswg-l@wugate.wustl.edu
To: oswg-l@wugate.wustl.edu
Errors-To: oswg-l-errors@wugate.wustl.edu
Subject: Re: Hank Nussbacher comments on the OPSTAT draft.

Hank,

Here are my comments to your review of the OPSTAT draft.

> Don't leave in "etc."

Removed!

> I think we should use the standard RFC1156 names here like ifInOctets
> and not arbitrary names.  Better yet:
>
>           ifInOctets - octets in

Personally I have no problems with this. Have to check with the
others. Please comment!

> Why would aggregate errors be listed as "sometimes in private MIB"
> and not in section 3.3.1?  I am referring to ifInErrors and ifOutErrors.

I am not sure why we decided to have it here. IF it is the case that
there is a standard MIB aggregate error variable it should be
moved to 3.3.1. Have to check that!

> Can you be more specific about per protocol variables?  Are you
> referring to IP (Telnet, FTP, SMTP) or IP, vs. DECNET vs. Appletalk?

This refters to IP vs DECNET etc. I will include a sentence on that
in the draft.

> I would very much like to see ifInErrors and ifOutErrors included
> here - even more so than discards!

OK. Any comments on Hanks proposal here?

> I would very much like to see DayofWeek included in the Time Section.
> Almost all analysis I do at some point or another requires me to
> determine whether the data collected was on a weekday or weekend.  When
> examining data from a month ago or a year ago I would very much like
> to easily see whether the data is from a weekend or weekday without
> having to run the timestring through an algorithm.  This would add
> only two octets: Su, Mo, Tu, We, Th, Fr, Sa.

Strikes me, I beleive exactly that was suggested at an early stage
but I may have forgotten to include it. I propose to add this.

>` Bandwidth should be more fixed in nature.  It should not be left as
> examples but rather stated "The valid bandwidth types are: bps, Kbps,
> Mbps, Gbps, and Tbps.
> ...
> Same with proto-type.  Be specific and don't let people use TCPIP
> instead of IP or add in new and unknown types.

Fully agree!

> I think that in addition, the bandwidth should be used here to
> determine the maximum load of the link and that an upper scale can
> then be drawn on the barchart to dramatize how close an interface
> is to total saturation.

I will propose this. As a matter of fact that is what I am already
is doing in NORDUnet and SUNEt statistical diagrams as you may
have seen at RIPE meetings.

Bernhard.