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.