Subject: RE: alarm definitions

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 16 Mar 2001 11:04:30 -0600

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> 
> 
> >>>>> Ayers, Mike writes:
> 
> Mike> Also, if we want to sort (and ARC) on severity, integer is the
> Mike> best way to go.  I was thinking about this recently, and I'd
> Mike> like to have:
> 
> Mike> 	clear: 0 informational: 25 indeterminate: 50 
> warning: 100
> Mike> minor: 150 major: 200 critical: 250
> 
> Mike> this would permit (non-ITU) users to choose appropriate
> Mike> numbers for finer-grained severity levels while still being
> Mike> amenable to a simple sort for severity ranking and single
> Mike> compare for ARC filtering.  Sound good?
> 
> I tend to disagree unless someone can reasonably explain to me the
> difference between the perceived severity values 82 and 83.

	I can think of automated prioritization, but that may be a stretch.
However, this could realistically be done by administrative reassignment so
that a list of alarms get handled in the desired order, so that the 83
priority item must be addressed before the 82 priority item.

> The added value of having a perceived severity attribute is IMHO lost
> when we allow implementors to choose from a nearly open ended set of
> values. In other words, it is IMHO a feature to force implementors to
> stick to a limited well defined set of perceived severity levels.

	I can see your point, but I must respectfully disagree.  If we were
ahead of the game, this would make sense.  We're not - we're way behind.
There are a boatload of alarm model implementations out in the field
already.  If this MIB is to be successful, it must permit conversion of
those existing systems.  If those systems don't fit into our model, our
model won't get used.  So how many severity states do we need to support
them all?  5? 7?  22?  We don't know, so why guess?

	Also, I'd like to point out that there is no implementation penalty
for using full integer range, since we can simply specify that bigger
numbers are more severe.

	The only situation where this would incur a penalty is when two
alarm domains meet.  However, since we're working on a model which is MLM
friendly, renormalization shouldn't be too difficult.

/|/|ike

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Mar 2001 18:21:17 +0100

>>>>> Ayers, Mike writes:

Mike> 	I can see your point, but I must respectfully disagree.  If we
Mike> were ahead of the game, this would make sense.  We're not -
Mike> we're way behind.  There are a boatload of alarm model
Mike> implementations out in the field already.  If this MIB is to be
Mike> successful, it must permit conversion of those existing systems.
Mike> If those systems don't fit into our model, our model won't get
Mike> used.  So how many severity states do we need to support them
Mike> all?  5? 7?  22?  We don't know, so why guess?

I am looking at it from a manager's point of view. A severity level of
42 which just means it is worse than 41 and nothing else is just
useless for me since I do not know whether the possible range for the
implementation that generated this alarm^H^H^H^H^Hsomething is 1-42,
1-100, 1-1000 or 1-2147483647 nor do I know that the values are evenly
distributed in the ranges and so on.

syslog for example has 8 severity levels and I can life with anything
which is in this order of magnitude and where the levels have well
defined semantics that implementors can understand use sufficiently
well. Sure, some implementations might need to do some additional work
to map their numbering scheme into the standard one. But this is added
value in order to achieve interoperability.

/js