Re: Alarms oddity ...
Robin Iddon <robini@spider.co.uk> Tue, 10 December 1991 11:56 UTC
Received: from mtigate.mti.com by NRI.NRI.Reston.VA.US id aa02734; 10 Dec 91 6:56 EST
Received: by mtigate.mti.com id AA03563 (5.65+/IDA-1.3.5); Tue, 10 Dec 91 03:23:10 -0800
Received: from eros.uknet.ac.uk by mtigate.mti.com with SMTP id AA03559 (5.65+/IDA-1.3.5); Tue, 10 Dec 91 03:22:51 -0800
Received: from castle.ed.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP) id <7335-0@eros.uknet.ac.uk>; Tue, 10 Dec 1991 10:58:33 +0000
Received: from spider.co.uk by castle.ed.ac.uk id aa24367; 10 Dec 91 10:56 WET
Received: by widow.spider.co.uk; Tue, 10 Dec 91 10:59:43 GMT
From: Robin Iddon <robini@spider.co.uk>
Date: Tue, 10 Dec 1991 10:55:36 +0000
Message-Id: <26123.9112101055@orbweb.spider.co.uk>
Received: by orbweb.spider.co.uk; Tue, 10 Dec 91 10:55:36 GMT
To: rmonmib@lexcel.com
In-Reply-To: Gary Ellis's message of Mon, 09 Dec 91 23:37:18 GM
Subject: Re: Alarms oddity ...
Hi, [My message deleted] [Some of Gary's message deleted] The other thing that occurs to me is that the meaning of (risingThreshold > fallingThreshold) is fairly obvious, while the meaning (or subsequent behaviour) of (risingThreshold == fallingThreshold) in the above context, is not quite so clear. Coming from a long line of network analyzer products (yawn ...) I always took risingThreshold == fallingThreshold to mean that there is a single threshold which when crossed in either direction generates an event; like what we had before someone invented hysteresis :-) So I tend to favor Robin's solution #3, in which the equality case is not allowed. Is manager workload that much of an issue?... it seems that all it has to do is detect equality and either increment risingThreshold or decrement fallingThreshold. If we go for this one then we'll have to add that constraint into the MIB. The other solutions didn't require any modifications to the MIB. Agent implementors could pick either 1 or 2. By the way, I think it is incumbent on all vendors to caution their users about setting up alarm entries with parameters such that normal value swings would cause lots of traps to be emitted. Couldn't agree more. --------------------------------------------------------- Gary Ellis (garye@hpspd.spd.hp.com) Hewlett-Packard Company -- Intelligent Networks Operation Robin Robin Iddon (robini@spider.co.uk) Spider Systems Ltd Edinburgh Scotland
- Re: Alarms oddity ... Gary Ellis
- Re: Alarms oddity ... Robin Iddon
- Re: Alarms oddity ... Steven L. Waldbusser
- Re: Alarms oddity ... Robin Iddon