Subject: RE: Examples and Potential Delta for Alarm & ITU Alarm MIBs

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 12 Mar 2001 08:10:28 -0500

hi

Frank> Sorry, I have some more doubts about your `favorite example'. ;-)

Frank>You are mapping a group individual notifications that have rather
Frank>individual characteristics to the values of an enumeration type that
Frank>is defined in the Alarm MIB, right?

Frank> I think this not a good idea.

Frank> Furthermore, I think it would not be the appropriate MIB design to
Frank> define the four notifications of your example in a MIB module.
Usually,
Frank> you would have only one notification definition and an object
Frank> assigned to that notification that denotes the current state (in this
Frank> example the temperature value).

Frank> Hence, it's not appropriate to build your example on an untypical
Frank> basis.  Maybe, there are real examples from standard MIBs that are
Frank> more appropriate.

I don't agree that encoding the severity into the OID is a bad thing.
But, since the Alarm MIB works with either design, I guess we just
need to agree on which examples we use.  I can look again in the
standard MIBs to see if there is something we can all like.  In
the meantime:

6) Single Notification with multiple severity levels

   Assume AcmeWidgetTemperature Notification with two varbinds
	{ acmeWidgetNumber, acmeWidgetSeverity } = acme.traps.5

    alarmDetailsIndex                  8
    alarmDetailsState		         cleared (1)
    alarmDetailsNotificationId         acme.traps.5
    alarmDetailsModelPointer           ituAlarmEntry.5
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  8
    alarmDetailsState		         minor (5)
    alarmDetailsNotificationId         acme.traps.5
    alarmDetailsModelPointer           ituAlarmEntry.6
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  8
    alarmDetaisState		         major (4)
    alarmDetailsNotificationId         acme.traps.5
    alarmDetailsModelPointer           ituAlarmEntry.7
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  8
    alarmDetailsState			   critical (3)
    alarmDetailsNotificationId         acme.traps.5
    alarmDetailsModelPointer           ituAlarmEntry.8
    alarmDetailsRowStatus              active (1)
    ituAlarmEventState                 environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

Sharon

---

From: Frank Strauss <[email-masked]>
Date: 12 Mar 2001 15:23:58 +0100

Hi!

Frank> You are mapping a group individual notifications that have
Frank> rather individual characteristics to the values of an
Frank> enumeration type that is defined in the Alarm MIB, right?

Frank> Furthermore, I think it would not be the appropriate MIB design
Frank> to define the four notifications of your example in a MIB
Frank> module. Usually, you would have only one notification
Frank> definition and an object assigned to that notification that
Frank> denotes the current state (in this example the temperature
Frank> value).

Frank> Hence, it's not appropriate to build your example on an
Frank> untypical basis.  Maybe, there are real examples from standard
Frank> MIBs that are more appropriate.

Sharon> I don't agree that encoding the severity into the OID is a bad
Sharon> thing.  

In your example, you are encoding a piece of information that
distinguishes different NOTIFICATION-TYPEs into the values of the
enumeration type object alarmDetailsState (not an OID). In your
specific example this piece of information is a severity level of the
notification that is mapped to a severity level of an alarm type. I
agree, that alarm records need a severity attribute. But I do not
agree that this mapping is *generally* applicable.

Sharon> But, since the Alarm MIB works with either design, I
Sharon> guess we just need to agree on which examples we use.  I can
Sharon> look again in the standard MIBs to see if there is something
Sharon> we can all like.  In the meantime:

Sharon> 6) Single Notification with multiple severity levels

Sharon>    Assume AcmeWidgetTemperature Notification with two varbinds
Sharon> 	{ acmeWidgetNumber, acmeWidgetSeverity } = acme.traps.5

Sharon>     alarmDetailsIndex                  8
Sharon>     alarmDetailsState		         cleared (1)
Sharon>     alarmDetailsNotificationId         acme.traps.5
Sharon> [...]

So, you suggest to have a number of alarm types in the
alarmDetailsTable each with a different alarmDetailsState.

What I would prefer is to have a severity column in the table
of alarm *instances*, so that you need only a single alarm type.

[If you are looking for temperature related examples based on the
 standard notifications, you might want to look at the UPS-MIB and
 the Printer-MIB. BTW, the UPS-MIB contains a upsAlarmTable. ;-)]

 -frank