Subject: Alarm definitions

From: "David T. Perkins" <[email-masked]>
Date: Wed, 07 Mar 2001 12:16:33 -0800

HI,

I sent in an update to the alarm MIB I-D last week. It hasn't shown
up yet. There were very few changes, except for the addition 
below.

Note that I've decoupled alarm definitions from alarm reporting,
and from suppression of alarm reporting. Having a formal approach
to defining alarms ideally would improve the communication between
the designer of alarms and the user of alarms (both network operators
and management application designers). Also, standard definitions
of alarms should improve interoperation between managed devices
and management applications.

-----------------

3.2  Alarm Definitions 
    
   Each type of an alarm needs to be well specified. Ideally, a new 
   construct (or template) would be added to the MIB module language, 
   which is specified by SNMP's SMI. Unfortunately, this is not 
   possible. Since alarms are identified with an OID value, the best 
   choice of construct to use is OBJECT-IDENTITY. This construct allows 
   a descriptor to be defined, a status and description specified, and 
   an OID value assigned. The contents of the DESCRIPTION text must be 
   structured to specify the attributes of an alarm type. The 
   attributes include: 
    
   Raise Conditions 
        What set of conditions or events cause the alarm to be raised? 
         
   Clear Conditions 
        What must occur to cause the alarm to be cleared? 
         
   Source Identification 
        How are the sources of the alarm identified (a source can be 
        physical (such as port), or logical, such as a session)? 
         
   Perceived Severity 
        How is the perceived severity of the alarm determined (it may 
        be statically specified or dynamically determined)? 
         
   Service Affecting 
        How is it determined if the condition is service affecting (it 
        may be statically specified or dynamically determined)? 
         
   Associated Information 
        What additional information is associated, if any, with the 
        alarm? For example, if the alarm is due to a threshold being 
        crossed, the additional information could be the threshold 
        value and the current value. 
         
   Class (Category) 
        What is the class (category) of the alarm using the ITU-T 
        terminology? 
         
   Probable Cause 
        How is the probable cause of the alarm determined (it may be 
        statically specified or dynamically determined)? 
         
   Dependencies 
        What are the dependencies, if any, between this alarm and other 
        alarms. For example, a loss of signal alarm on a network 
        interface would probably also result in a network interface 
        down alarm. 
         
   In summary, instead of adding a new construct like the following: 
    
   TemperatureAlarm ALARM-TYPE 
       STATUS       current 
       DESCRIPTION  "The current temperature outside of the 
                    acceptable operating range" 
       RAISED-BY    "The measured temperature has been outside of the 
                    acceptable operating range for the last 5 seconds." 
       CLEARED-BY   "The measure temperature has been within the 
                    acceptable range for the last 15 seconds." 
       . . . 
       ::= { myAlarms 1 } 
    
   the existing OBJECT-IDENTITY construct must be used and the 
   DESCRIPTION field structured like in the following: 
    
   TemperatureAlarm OBJECT-IDENTITY 
       STATUS       current 
       DESCRIPTION  "An Alarm 
    
                    Description: 
                      The current temperature outside of the 
                      acceptable operating range 
    
                    RAISED-BY: 
                      The measured temperature has been outside of the 
                      acceptable operating range for the last 5 
                      seconds. 
    
                    ClEARED-BY: 
                      The measure temperature has been within the 
                      acceptable range for the last 15 seconds. 
                     . . . " 
       ::= { myAlarms 1 } 

Regards,
/david t. perkins

---

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Thu, 15 Mar 2001 18:15:07 -0500

I believe that the terms "fault" and "error" as used by Tammy are consistent
with several
standards, including the ISO terminology.

The word "alarm" is the troublesome one, and X.733 uses it very loosely.  It
is really a
significant asynchronous event report which somewone may want to look at.

Threshold crossing events cause alarms, even though they may have nothing to
do with
faults or errors.

We should try to use the "alarm" word very cautiously, and define our own
terms "alarm record"
etc as needed.

Tom Rutt

ter

	----------
	From:  David T. Perkins [SMTP:[email-masked]]
	Sent:  Thursday, March 15, 2001 5:44 PM
	To:  Tammy Ferris; [email-masked]
	Subject:  Re: alarm definitions

	HI,

	Tammy - there are three different proposals for an Alarm MIB. There
	are some major differences and some similarities. It would be
helpful
	if you read and commented on all three.

	Secondly, I believe that the ITU-T alarm model and description as
	specified by X.733 is fatally flawed. So, the assumption that we
would
	try to duplicate it is certainly not one of my goals. Others
	do not understand why I believe that it is flawed, and this it
	not the place to describe the flaws. Note that Q.821 does not
	define "alarm". This is VERY curious.

---

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Thu, 15 Mar 2001 19:10:54 -0500

Tammy Ferris writes

>All,
In reviewing the alarm definition in the Alarm MIB and also used in the ITU
Alarm MIB, I had the following questions/comments/conerns:
1)	The current definition of Fault is:  Lasting error or warning
condition.  I am uncomfortable with the word lasting.  A fault need not be
persistent and it is not clear what is meant by lasting.  X.733 defines a
Fault as the cause of a malfunction which may be manifest by errors.  I
interpret a fault to be the root cause of possibly many symptoms using the
X.733 definition.
---------------

I agree.   The definition of fault should be as tammy states.  This does not
change anything
in the MIB.

The definition of alarm is not that important, but I tend to think we can
relate it to "potential
fault indication" or something like that.  Maybe we just can let the
definition be loose.

I  generally like the Dave Perkins mib, but I note He is also using the
integer probable
cause, like the Nortel MIB

   SnmpItuAlarmProbCause ::= TEXTUAL-CONVENTION 
       STATUS      current 
       DESCRIPTION "The probable cause of the alarm as 
                   specified in [X.733] and [X.736]. 
                   <expand this>" 
       SYNTAX      INTEGER { 
                   other (1), 
                   adapterError (2), 
                   applicationSubsystemFailure (3), 

I think this is problematic.  Either use a string, or an ObjectIdentifier,
for greater flexibility
is needed than can be offered by named numbers hard coded in the
specification of the MIB.

Look forward to talking about this at the meeting.

Tom Rutt

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 16 Mar 2001 07:44:14 -0500

hi 

Tammy> Is it the goal of this group to create new and different definitions
for old
Tammy> terms?
The goal is come up with definitions that make sense within the SNMP
framework
as well as existing alarm management frameworks.

Tammy> It seems to me that the idea of the event pre-processing function
defined in the
Tammy> ITU is missing from our discussions and a mapping of that 'framework'
to an SNMP
Tammy> interface.

The primary goal of the Alarm MIB is to provide Alarm Management for SNMP.
We 
recognize the install base of the ITU and the work the ITU has done in this
area.  In an effort to not re-invent the wheel and to provide some mapping
mechanisms for people using ITU management we have included some ITU
modelling
information in the various forms of the MIB.  I don't believe the goal was
ever to do a literal mapping from the ITU framework into SNMP.  As Dave
mentioned,
you don't necessary end up with something which works well in the SNMP
world.

If we will be looking at a more complete ITU model, then we might then want
to give more thought to the model-neutral vs. model-specific architecture
since this could end up adding enough complexity to make the modular
architecture make (even) more sense.

Tammy> I cannot support a definition of an alarm that requires duration.  

Our use of the term duration for an alarm means that it occurs as long
as the fault does.  Our use of duration for a fault is simply to
differentiate
it from an event which has no duration.  Perhaps removing the word "lasting"
from fault will remove this confusion.

Tammy> In an SNMP context and as you understand and have defined it, is an
alarm logged
Tammy> or the notification?  Where/how is correlation information identified
and
Tammy> provided?  Does the alarm or the notification trigger an audible
and/or visual
Tammy> alarm?  And so on... I think all of these questions need to be
answered.

We are still discussing the first question.  For the second question, alarm 
correlation has been defined as out of scope of this work (at least no one
has
disagreed with this in the compliance matrix)  The third question is
interesting,
but based on previous notification vs. non-notification discussions, not
something
we will likely reach any agreement on.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 16 Mar 2001 10:51:24 -0600

> From: Tammy Ferris [mailto:[email-masked]]
> 
> Mike,
> Is it the goal of this group to create new and different 
> definitions for old
> terms?

	Gee, could you load that question a little more?

	When we first got started on this project, one of the things that
quickly became clear was that participants were using many key words, such
as "alarm" (especially "alarm") to mean slightly different things.  Since we
are defining an information model for alarms, it was important to have an
agreed upon explicit definition.  We begun work on that definition, but at
some point it fell to the wayside, and now we are once again suffering from
confusion because of the lack of that definition.

	Such definitions are common practice in standards.  X.733, for
instance, contains references for 20 definitions.

> It seems to me that the idea of the event pre-processing 
> function defined in the
> ITU is missing from our discussions and a mapping of that 
> 'framework' to an SNMP
> interface.

	That's probably outside our scope, at least for now.

> As I understand the ITU definitions, instantaneous nor any concept of
> time/duration is associated to the definition of a 
> notification.  It is simply
> an unsolicited message sent from a managed object.

	That's true, but if you associate a notification with a state, then
the notification will flood the wire once the state is entered - you need to
associate the notification with the *transition* into or out of the state.
This is somewhat obvious, perhaps, but we had (and continue to have) so much
confusion about this that it needs to be stated explicitly - often.

> I cannot support a definition of an alarm that requires 
> duration.  It flies in
> the face of too many existing implementations and 
> expectations in the Telecom
> world.  I have worked with many systems that report system 
> initialization alarms
> after the system is fully (re)initialized, and other systems 
> that report certain
> significant activities/events as alarms such as automatic 
> gain adjustments,
> ranging, dropped calls, etc.  Whether or not a clear is sent 
> for such alarms is
> typically implementation specific.

	I think you are confusing the alarm itself with its method of
propogation.  The alarm persists until cleared, acked, superceded, etc.  If
the alarm had no duration, it would just blink up on the console and vanish
(autoclear?).  It is the notification indicating the alarm's transitions
which has no duration.

> In an SNMP context and as you understand and have defined it, 
> is an alarm logged
> or the notification?

	In the context we are trying to define, the alarm is logged.  One
way to log the alarm is by listening for the notifications.  Another way is
by polling devices which support the alarm MIB.  These methods apply to
managers.  Managed devices may choose to self-source the alarm MIB without
sending notifications, or they may send the notifications without presenting
the MIB, or (probably most common) they may support the MIB and send
notifications.

	Note that the end user may also wish to use the Notification Log MIB
to log notifications which indicate alarm transitions.

>  Where/how is correlation information 
> identified and
> provided?

	Correlation is outside our scope.

>  Does the alarm or the notification trigger an 
> audible and/or visual
> alarm?

	That is the end user's configuration decision.

>  And so on... I think all of these questions need to 
> be answered.

	Have I answered them?

/|/|ike

---

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

> From: Sharon Chisholm [mailto:[email-masked]]

> architecture make (even) more sense.

	You mean it might give a glimmer of sensibility to multi-MIB.  So
far there has been no other justification.  I think we can devise better
means to handle this situation, such as stringified parameters in the extra
text field.

/|/|ike

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Mar 2001 10:54:18 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> Date: Thu, 15 Mar 2001 14:43:32 -0800
> To: Tammy Ferris <[email-masked]>, [email-masked]
> From: "David T. Perkins" <[email-masked]>
> In-Reply-To: <[email-masked]>
...
> specified by X.733 is fatally flawed. So, the assumption that we would
...

The disman WG chair speaketh:

Dave, repeated whining about "fatal flaws" without any
substantive arguments to back up those claims is simply not
helpful.  You have been asked multiple times to substantiate
these claims, and have failed to do so.

Our charter explicitly requires to *consider* existing
standards and practices.  Rejecting them out-of-hand as
"fatally flawed" does not amount to consideration.  A
great deal of thought and experience went into these
standards; we would be ill-advised to ignore them or to
introduce gratuitous incompatibilities.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Fri, 16 Mar 2001 14:12:10 -0500

I agree with Randy.

I was around in ISO thru the progression of the "alarm reporting functinon"

At one point it was the fault reporting function ,then the event reporting
function. etc.

The "Alarm" report is an event report.   The concept of Clearing a previous
alarm is what
brings in the concept of "alarm condition".

The "Alarm" report is an event indication, and so is the alarm report with
clear severity.

The Alarm condition, or fault state is another matter.

Rememember, an intermittent fault condition can be responsible for several
errors at different
times which go away (The solder only has trouble when it is at a particular
temperature).

Tom Rutt

ter

	----------
	From:  Randy Presuhn [SMTP:[email-masked]]
	Sent:  Friday, March 16, 2001 1:54 PM
	To:  [email-masked]
	Subject:  Re: alarm definitions

	Hi -

	...
would
	...

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 16 Mar 2001 11:23:35 -0800

HI,

Finally some light here with a model and explanation that make sense.

How all we need to do is figure out a way to define alarms,
and make sure that readers do not come to the conclusion
that all notifications are reports of alarms, then it looks
like we will be done.

Thanks Leen.

Regards,
/david t. perkins

At 03:48 PM 3/16/2001 +0100, Mak, L (Leen) wrote:

>Just FYI, let me explain some work done in the pre internet 
>age. Maybe it helps.
>
>The basic observation is that, from a fault management point
>of view, an entity can behave satisfactorily (be in the ok_state), 
>or can behave unsatisfactorily (be in the not_ok_state). 
>Leaving out some details, we call the transition from the 
>ok_state to the not_ok_state: "declaring a failure";
>the other way around it is called "clearing the failure".
>Between declaration and clearing, the entity has a "fault".
>Note that this is just an internal condition of the entity, no-one
>knows yet about it.
>
>Now (again leaving out some details) if the entity is configured
>to inform the outside world about these things, it will
>emit a "notification" for each failure declaration and clearing.
>This notification in general carries info about the nature
>of the fault and whether the failure was declared or cleared,
>and probably some more data.
>
>Usually, such notification will finally cause some form of 
>alerting on a display (simple lamp, or nice GUI) or ring a bell. 
>This alerting is what is called an "alarm". 
>
>In general, the alarm is on the display as long as the fault exists.
>However, sometimes, people want to silence the alarm, even 
>before the failure has been cleared. 
>In other cases, systems are configured such that the alarm 
>will stay on ("latching"), even after the failure has been cleared  
>(you would like the burglar alarm to continue to sound, even 
>when the intruder very quickly closed the door after he/she 
>stepped into the kitchen, wouldn't you?).
>In such cases the observer has to tell the display to shut up. 
>This is called "acknowledgment".
>
>A basically different form of malfunction is that the entity
>burps. Then there is no such thing as declaration and clearing 
>of a failure, no fault, there is just an event.
>Again, the entity will communicate this to the outside world 
>by means of a notification, which contains the info that there 
>was a hickup.
>This notification will also end up on some display and be shown 
>as an alarm. This will remain there until the observer 
>acknowledges the alarm.
>This may happen a second or an hour or a day after the
>hickup occured.
>
>So, an alarm is the presentation to an observer that there is
>or was a malfunction, and from these various scenarios it is 
>clear that the alarm is and should be distinguished from the 
>events and/or conditions causing the alarm.
>
>BTW, in the same project we concluded that carrying strings 
>indicating faulttypes over management interfaces is not
>a very good idea.
>We used integers, and the displaying machines used 
>a lookup table to find the correct string. This is very handy
>if the users of the system want the strings in another
>language.
>
>Leen.

---

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Fri, 16 Mar 2001 14:52:26 -0500

Arif asked:
...
b) Is it possible to define a set of 'must have' details or 'should have'
details, common to all notifications that signify alarms ?

<Steve>
IMO, NO.  Perhaps I am misunderstanding what you mean.  This sounds like you
are heading towards a single universal alarm detail and notification
description.  If you are including all of the variables that may/will be
applicable for each different alarm, then I don't think this is practical,
even if it is possible.

I think that there are some alarm attributes and details in these
categories:
1) Universal attributes (or close enough to universal) including timestamp,
severity, location, etc.
2) Model-specific attributes - I like the flexibility that having model
specific attributes provides us (regardless of 1 MIB or 2 or n)
3) System or vendor specific variables - provided with all or most alarm
conditions
4) Alarm specific variables - associated with the specific alarm type

<deleted stuff>

<arif>

Is it not, then , possible for us to combine the two cases above, and
conclude that some event was being signalled by the notifications, and
comparisions with a pre-defined set of events gave us an idea of whether or
not this event is alarming, and if so to what degree. If such is the case,
then it may not really be possible to delink alarms for their basic events -
what can be debated is the nature of notifications signalling the alarm, and
the amount and form of the information contiained therein.

<Steve> 
you seem to be saying that an alarm is based on an event and is a category
or subset of the events on a system. I would not agree that an alarm is an
event.  Events are certainly what trigger the reporting of an alarm.  I
prefer to view alarms as the recognition of a fault, error event, warning.
So the "recognition" of the "alarm condition" (e.g. fault, error event,
threshold crossing, etc.) is usually/always associated with an event.  But
the alarm has meaning independent of the events which may trigger its
recognition.  

Perhaps I'm tilting at windmills here...

<arif>

<deleted stuff>
 The point I'm trying to make is that events are notified, some of
them are alarms, some burps, some pleseant happenings, and therefore alarms
can best be represented by the basic events that cause them - we really
cannot seperate alarms from their root events.

<Steve> See above, I disagree.  I think that we can and should distinguish
between alarms and the events which cause the system to notice them.  I
don't think these events are necessarily "root events".  I prefer to use the
fuzzier term of "faults" to describe the root cause.

Cheers,
Steve

---

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Fri, 16 Mar 2001 14:54:14 -0500

ter

	----------
	From:  Ayers, Mike [SMTP:[email-masked]]
	Sent:  Thursday, March 15, 2001 8:10 PM
	To:  'Rutt, T E (Tom)'; [email-masked]; 'Tammy Ferris'
	Subject:  RE: alarm definitions

	> From: Rutt, T E (Tom) [mailto:[email-masked]]
	> 
	> Tammy Ferris writes
	> 
	> 

		Awww, for Pete's sake!

		The definiton of "alarm" is the only thing that matters
here!  It's
	the thing we're trying to model!  All these definitions were brought
about
	in an effort to clarify the difference between "alarm" and
"notification",
	which is thus:  notifications represent instantaneous things, and
alarms
	represent things which have a duration.  All the other definitions
of
	events, faults, etc. can (and should, given the confusion that they
have
	generated just within this group) be discarded.

	I guess I mean to clarify there are alarm conditions which may be
cleared and
	their are alarm reports, which are events indicating transfer into
an alarm condition or
	clearing an alarm condition.

	The reason for the Alarm is up to the implementation, that that is
why we need flexible
	but understandable probable causes.

	I think that string is too loose, I prefer Object identifier.
Integer is too fixed and hard
	to administer for many product environments.

	Tom Rutt

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 16 Mar 2001 11:57:06 -0800

HI,

Some more reasons from tom explaining how the document became
fatally flawed.

Randy - I'm sorry that I offend you by describing the X.733 documents
as fatally flawed and not explaining the reasons in a way that you
understand. However, I believe that I have explained the reasons.
Again - confusion and lack of clarity.
 
Regards,
/david t. perkins

---

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Fri, 16 Mar 2001 15:09:17 -0500

I think to make progress we need to be distinguish event reports and
notifications from
conditions which can be queried.

The "alarm clearing" is associated with a transition from an "alarm
condition".  The alarm
condition, if in the mib in the first place, was probable signalled by an
"alarm Notification".

The reason for the title "alarm" was because it was widely used in existing
products
at the time.  It was needed to distinguish itself from other generic
notification types, such
as attribute change, object creation, object deletion etc.

The implementation of the network element is what decides warrants an
"alarm" report
and what brings the resource into an "alarm" condition.

The MIBs as presented in the three or four I/Ds are not that far apart.
Lets not get bogged down
by the exact definition of what warrants an "alarm" condition.

Tom Rutt

ter

	----------
	From:  David T. Perkins [SMTP:[email-masked]]
	Sent:  Friday, March 16, 2001 2:57 PM
	To:  Rutt, T E (Tom); [email-masked]; 'Randy Presuhn'
	Subject:  RE: alarm definitions

	HI,

	Randy - I'm sorry that I offend you by describing the X.733
documents
	as fatally flawed and not explaining the reasons in a way that you
	understand. However, I believe that I have explained the reasons.
	Again - confusion and lack of clarity.
	 
	Regards,
	/david t. perkins

	At 02:12 PM 3/16/2001 -0500, Rutt, T E (Tom) wrote:

	>        > Message-Id:
<[email-masked]>

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 16 Mar 2001 15:37:28 -0500

Hi.

Terminilogy is a big issue.  We have the discussion twice since January(?)
May I suggest one thing for our alarm mib modeling discussion on Sunday?

*	Let's pick a set of terms with a description describing what the
terms mean, (for instance, David Perkin's  or Sharon's or ....),
so that we can work on modeling the alarm mib.

*	Maybe another sub-team (comprising experts of standard terminology)
will come up a set of terminology to be used in the WG documents.

Regards,

Anni

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 16 Mar 2001 22:56:33 +0200

Due to the IEEE meeting, I was practically away from e-mail for a few days.
You guys seem to have so much fun :-)

I think that I agree with Anni's proposal. The alarms terminology, as well
as the requirements issues seem to have become hard to crack coconuts. We
should be spending most of the time before, during and around the next week
meetings trying to reach some convergence on these issues - otherwise
attempts to make progress are futile. Sub-teams or design groups might be
the way to go.

Of course, this proposal needs to be agreed by the community, and sanctioned
by the Chair.

Regards,

Dan

> -----Original Message-----
> From:	Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> Sent:	Fri March 16 2001 22:37

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 16 Mar 2001 12:37:26 -0500

hi

> >>>>> 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?

Interesting, but how about something like this:

  alarmDetailsState Integer32 ( 1 .. infinity )
     where 1 MUST indicate a clear alarm state and severity
	increases from there.

  Then we can still have our
    ituAlarmPerceivedSeverity  { 
		cleared (1),
            indeterminate (2),
            critical (3),
            major (4),
            minor (5),
            warning (6)
	}
   which we can optionally map into.

  This leaves room to map to alarms with lots of severity levels.

	acmeWidgetSeverity 1 = ituAlarmPerceivedSeverity 1
	acmeWidgetSeverity 2 = ituAlarmPerceivedSeverity 2
	acmeWidgetSeverity 3 = ituAlarmPerceivedSeverity 2
	acmeWidgetSeverity 4 = ituAlarmPerceivedSeverity 3
	acmeWidgetSeverity 5 = ituAlarmPerceivedSeverity 3
	acmeWidgetSeverity 6 = ituAlarmPerceivedSeverity 3
	acmeWidgetSeverity 7 = ituAlarmPerceivedSeverity 4
	acmeWidgetSeverity 8 = ituAlarmPerceivedSeverity 5
	acmeWidgetSeverity 9 = ituAlarmPerceivedSeverity 5
	acmeWidgetSeverity 10 = ituAlarmPerceivedSeverity 6
	acmeWidgetSeverity 11 = ituAlarmPerceivedSeverity 6
	acmeWidgetSeverity 12 = ituAlarmPerceivedSeverity 6
	acmeWidgetSeverity 13 = ituAlarmPerceivedSeverity 6

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 16 Mar 2001 13:21:08 -0500

hi

> 
> > From: Juergen Schoenwaelder [mailto:[email-masked]]
> >
> > 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.

Yes, that's why I want to define all possible states in the
alarmDetailsTable
for the manager to read when it discovers the device.  The proposed change
is to index alarmDetailsTable with ( alarmList, alarmDetailsIndex,
alarmDetailsState}.
With all of this you not only know the all the applicable state values, you
also know how you transition into each state.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 16 Mar 2001 13:27:21 -0500

hi

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Friday, March 16, 2001 12:39 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]; Tammy Ferris; Ayers, Mike
Cc: 'Rutt, T E (Tom)'; [email-masked]
Subject: RE: alarm definitions

> architecture make (even) more sense.

<mikeA>
</mikeA>

Sorry, which situation?  I thought I had been commenting
on a general comment that we weren't mapping well from the ITU Alarm
framework.  

I will mention though, that "stringified parameters in the extra text field"
sounds like something we want to avoid in a big way.

Sharon

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Mar 2001 13:22:06 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> Date: Fri, 16 Mar 2001 11:57:06 -0800
> To: "Rutt, T E (Tom)" <[email-masked]>, [email-masked],
>         "'Randy Presuhn'" <[email-masked]>
> In-Reply-To: <[email-masked]
>  .lucent.com>
...
> Some more reasons from tom explaining how the document became

Huh?  I suspect you're using the phrase "fatally flawed" in a
rather peculiar way.  Tom's recounting of the history (as well
postings by others) explains why the terminology used there
has some problems.  But "fatally flawed"?  Corpus delicti?

...

As WG chair, I don't have a stake in the extent to which
this work is (or is not) aligned with other standards, though
I will admit to a personal bias in favor of avoiding gratuitous
incompatibilities.

HOWEVER, as WG chair it is my job to make sure that we live
up to our charter.  Dismissing documents wholesale with little
more than hyperbole and innuendo is NOT "consideration."

These discussions are reaching the point where most of
the parties involved have a feeling for how the same words
are used (possibly in multiple senses) differently in the
various communities.  It may be that the best we can do is to
publish a "magic decoder ring" as part of our description of
the relationship of our work to other standards, and perhaps
even with respect to some of the ways in which these terms
have been used in the SNMP community, itself not exactly a
paragon of consistency or clarity, especially given the
evolution of notification processing.

I would like the WG to take full advantage of the IDEAS
and CAPABILTIES from these other standards that have proven
useful in actual implementation and deployment.  When we are
able to use the same words with the same meanings, great.
When not, then we need to describe the mappings.

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 16 Mar 2001 16:55:33 -0500

Hi, I disagree to have finer-grained standardized severity levels.
I prefer to keep the finite set of severity levels (~ itu perceivedSevrity).

So in Sharon's example below, the widgetSeverity levels are specific
to one alarm type.  It should be described in the alarm definition of widget
alarm(s).
The mapping of widgetSeverity to perceivedSeverity is left to the users or
vendors.

Anni

> ----------
> From: 	Sharon Chisholm[SMTP:[email-masked]]
> Sent: 	Friday, March 16, 2001 12:37 PM
> To: 	Ayers, Mike; 'Juergen Schoenwaelder'
> Cc: 	[email-masked]; [email-masked]; [email-masked]

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 16 Mar 2001 16:14:26 -0600

> on a general comment that we weren't mapping well from the ITU Alarm

	So was I.  Not only are we not mapping completely to the ITU
framework, but to almost all of the other formal and informal frameworks out
there.  You and I seem to agree that there must be a way to handle the
object in the existing alarm models, but disagree about how to handle them.

> sounds like something we want to avoid in a big way.

	I expected it to be shot down the first time I lobbed it up (you're
slow!).  Realistically, augmentation can handle the extra objects.

/|/|ike