Subject: Use of alarmListName

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Apr 2002 10:19:07 -0700

HI,

The alarm draft has the tables indexed by object alarmListName.

However, I cannot figure out how notifications are classified
so that they use appropriate entries in tables based on the
value of alarmListName. That is, what is the classifier from
notifications to values of alarmListName? And how is this
configured?

PS Randy - feel free to restate this as a clearer and simpler 
   question.

Regards,
/david t. perkins

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 12:52:56 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Tue, 23 Apr 2002 11:16:53 -0700
> To: [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re:  Use of alarmListName
> In-Reply-To: <[email-masked]>
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
> 
> HI,
> 
> I was first trying to get clarification on the "simpler" of the three
> ways that alarms are defined. If this could be clarified, then
> the other two ways might be obvious.
> 
> The first was via "existing" notifications. The second was via
> the two new notifications (alarmActiveState and alarmClearState).
> The third is via internal mechanisms (that is, alarmModelNotificationId
> has the value { 0 0 }).
> 
> Did I get this correct?

That's what the draft seems to say.
I think the second is a special case of the first,
and the third just looks like magic.

> One of the fundamental goals of the I-D appears to me to use the
> existing notifications generated by a system, and to create a
> system that mapped these existing notifications to alarm raises
> (with configured severity) or to alarm clears.
> How this is done doesn't seem complete to me. 
...

Yup, I'm inclined to agree.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Apr 2002 14:28:44 +0300

David,

I am not sure what you are asking here. The object that is being used for the mapping is alarmModelNotificationId. What is not complete?

You started with a different question, concerning alarm classification which Randy addressed correctly.

Regards,

Dan

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 9:17 PM
> At 10:32 AM 4/23/2002 -0700, Randy Presuhn wrote:
> >Hi -
> >
> >> Message-Id: <[email-masked]>
> >> Date: Tue, 23 Apr 2002 10:19:07 -0700
> >> To: <[email-masked]>
> >> Subject: Use of alarmListName
> >I think alarmListName has nothing to do with alarm classification.
> >
> >Here's a not-very-useful example of how I think it's supposed
> >to work. If I configure the same models under three different
> >alarmListNames, and if access control policy permits, then I
> >would expect that for any active alarm entry existing under
> >one of the alarmListNames, there should be corresponding
> >entries under both of the other alarmListNames.
> >
> >In short, it's to support sandboxing the users of the
> >alarm facility.  One *could* in a really twisted way use it
> >for alarm classification (different models under different
> >alarmListNames corresponding to alarm classification), but
> >I don't think that that's the motivation for it.
> >
> >(Of course, I could have completely misunderstood the
> >whole thing.  :-)
> 
> Regards,
> /david t. perkins
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 03:05:26 +0300

The alarmAccessResourceId is known by the agent, because it is keeping an internal accounting of who the sends that need to be include in the alarmActiveTable. The agent will perform the matching of the respective resource (id information contained in the notification) to the relevant row(s) in the table. There is no need to duplicate this information in another MIB object.

I assumed this is clear (probably part of the magic;-). If I am wrong appropriate text can be added.

Regards,

Dan

> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 9:59 PM
> Subject: RE: Use of alarmListName
> 
> 
> Hi -
> 
> > Subject: RE: Use of alarmListName
> > Date: Wed, 24 Apr 2002 14:28:44 +0300
> > Message-ID: 
> <[email-masked].
> avaya.com>
> > From: "Romascanu, Dan (Dan)" <[email-masked]>
> > To: "David T. Perkins" <[email-masked]>, 
> <[email-masked]>
> ...
> > I am not sure what you are asking here. The object that is being
> > used for the mapping is alarmModelNotificationId. What is 
> not complete?
> ...
> 
> I think the concern is this:
> 
>   - notification arrives
>   - the implementation searches the alarmModelTable 
>     to find any entries where alarmModelNotificationId matches
>     the notification that arrived
>   - from each of these entries, we extract the tuple
>     <alarmListName, alarmModelIndex> and alarmModelState
>   - we now search the alarmActiveTable, looking for any
>     active alarms matching <alarmListName, alarmModelIndex> so
>     we can apply the new alarmModelState to them.  There's just
>     one problem.  We should only apply this to ones with the
>     "right" alarmActiveResourceId. This is the part of the
>     mapping process that's not complete.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 03:06:16 +0300

What are the two other mechanisms? Dan

> Sent: Wednesday, April 24, 2002 11:10 PM
> To: Randy Presuhn; [email-masked]
> Randy summarized the process below, when notifications are used to
> raise and clear alarms. But, my interpretation of the I-D is that
> two other mechanisms can also be used to raise and clear alarms.
> If this interpretation is correct, then for them, would also like
> to see the logic similar to what Randy has written below.
> 
> At 11:59 AM 4/24/2002 -0700, Randy Presuhn wrote:
> >Hi -
> >

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 24 Apr 2002 17:54:26 -0700 (PDT)

Hi -

> Date: Thu, 25 Apr 2002 03:06:16 +0300
> Message-ID: <[email-masked]>
>         "Randy Presuhn" <[email-masked]>, <[email-masked]>
> 
...

I believe he is referring to the three mechanisms specified in
4.1.3's second paragraph.

|4.1.3 Alarm State Transition Notification
|
|   Alarms are modelled by defining all possible states in the
|   alarmModelTable, as well as defining alarmModelNotificationId,
|   alarmModelVarbindIndex, and alarmModelVarbindValue for each of the
|   possible alarm states.  Optionally, ituAlarmPerceivedSeverity models
|   the states in terms of ITU perceived severity.
|
|   Alarm state transitions can use existing notifications or can use
|   the generic notifications and alarmActiveState and alarmClearState.
|   If the implementation chooses not to alert the management station,
|   then a value of 0.0 can be used for alarmModelNotificationId.
|   Alternatively, a notification can be defined in
|   alarmModeNotifiationId and no hosts specified in the SNMP-TARGET-MIB
|   [RFC2573].

As a technical contributor, I think the second looks like a
special case of the first, and the third appears to me to be
total magic.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 24 Apr 2002 18:01:06 -0700

HI,

for your question...

>What are the two other mechanisms? Dan

In section 3.2.2, Flexible Alarm Modeling, look at the 3rd paragraph
that starts with
   Alarm states can be modelled using traditional notifications,
   generic alarm notifications, or without notifications.

Note that it doesn't seem like the picture in section 3.3 matches the
content of the above paragraph.

Regards,
/david t. perkins

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 07:16:47 +0300

Maybe I start to understand. It looks to me that in all this discussion there is a confusion between the notifications that are received by an agent and need to be interpreted as an alarm condition and the notifications that are being sent by the agent when a change in the alarm state occurs. 

4.1.3 describes the notifications that may be sent by the agent that supports the Alarm MIB. 

Regards,

Dan

> Sent: Thursday, April 25, 2002 3:54 AM
> <[email-masked].
> avaya.com>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 07:22:13 +0300

> > Date: Thu, 25 Apr 2002 03:05:26 +0300
> > Message-ID: 
> <[email-masked].
> avaya.com>
> > To: "Randy Presuhn" <[email-masked]>, 
> <[email-masked]>
> > 
> > The alarmAccessResourceId is known by the agent, because it
> > is keeping an internal accounting of who the sends that need to
> > be include in the alarmActiveTable. The agent will perform the
> > matching of the respective resource (id information contained
> > in the notification) to the relevant row(s) in the table. There
> > is no need to duplicate this information in another MIB object.
> ...
> 
> WG chair wondering aloud: if the WG consensus is to go
> with requiring implementations to know a priori how to
> extract resource IDs from notifications (I'm awaiting
> response to consensus call on *that*), and since what
> one needs to do to extract a resource ID from a notification
> depends on the notification type, do we need to specify
> the set of NOTIFICATION-TYPEs that MUST be understood by
> a conformant implementation, and do we need to specify
> how the resource ID extraction works for these?

Why should it? The agent either knows how to populate the alarmActiveResourceId object, or it does not. The MIB structure does just that - passes alarms and identifies resources described by the OID. The 'magic' of populating the tables are not within the scope of the generic alarm model.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 07:27:35 +0300

Dave,

I think that you are confusing here between the notifications that are being sent by the Alarm MIB agent, and the conditions that lead to the activeAlarmTable being populated. 3.2.2 refers to the first, while 3.3 refer to the later.

Probably the text in 3.2.2 may benefit from some further clarification to avoid confusion.

Regards,

Dan

> Sent: Thursday, April 25, 2002 4:01 AM
> To: Romascanu, Dan (Dan); Randy Presuhn; [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 07:34:19 +0300

> From: Ramanathan Kavasseri [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 4:28 AM
> To: Randy Presuhn
> Cc: [email-masked]
> Randy Presuhn wrote:
> > > Message-ID: <[email-masked]>
> > > Date: Wed, 24 Apr 2002 17:58:40 -0700
> > > From: Ramanathan Kavasseri <[email-masked]>
> > > To: Randy Presuhn <[email-masked]>
> > > Cc: [email-masked]
> > > References: <[email-masked]>
> > ...
> > > Yes.
> > Any thoughts on what that should be in that set?
> > 
> > > Yes.
> > And the rules are... ?
> Was hoping someone would provide this - as I'm scratching
> my head about how to go about it.
> :-(
> 
would be glad to spare you the scratching ;-)

it would not be a problem to specify such a mapping. Avoiding to do this is by design. A generic agent needs not understand the semantics of the alarms. Some agent implementations do not use notifications to populate the alarmActiveTable. If you want to 'hard code' such a mapping you may do it in the model specific Alarm MIB.

> Ram

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 25 Apr 2002 10:45:21 -0700 (PDT)

Hi -

> Date: Thu, 25 Apr 2002 07:22:13 +0300
> Message-ID: <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>, <[email-masked]>
...
...
> Why should it? The agent either knows how to populate
> the alarmActiveResourceId object, or it does not. The MIB
> structure does just that - passes alarms and identifies
> resources described by the OID. The 'magic' of populating
> the tables are not within the scope of the generic alarm model.
...

This provides no assurance that different implementations would
exhibit similar behaviour.  I think interoperability would suffer.
When a management application creates entries in the AlarmModelTable,
does it receive any indication at all regarding whether the MIB
implementation will know what to do with them, or that what one
implementation will use as a resource identification algorithm
will produce the same results as any other implementations?

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 25 Apr 2002 10:52:34 -0700 (PDT)

Hi -

> Date: Thu, 25 Apr 2002 07:34:19 +0300
> Message-ID: <[email-masked]>
> To: "Ramanathan Kavasseri" <[email-masked]>,
>         "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
...
> it would not be a problem to specify such a mapping. Avoiding
> to do this is by design. A generic agent needs not understand
> the semantics of the alarms. Some agent implementations do
> not use notifications to populate the alarmActiveTable. If
> you want to 'hard code' such a mapping you may do it in the
> model specific Alarm MIB.
...

Ok, now I'm really lost.  The only way that I can imagine
a generic implementation doing resource id extraction is to
provide some MIB objects that control how the extraction
is to be performed for the notification types of interest.
Forgive my lack of imagination, but without such objects,
I don't see how a generic, magic-free implementation of the
current MIB is possible.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 26 Apr 2002 14:32:03 +0300

> <[email-masked].
> avaya.com>

If the implementation does not know what to do with an entry in the AlarmModelTable it should reject the row creation. This needs to be documented, if it was not clear. It can happen even if an algorithmic mechanism to extract resource ID from notifications is being defined.

Regards,

Dan