Subject: RE: disman alarm mib comments

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 3 Jan 2002 09:30:03 -0500

hi

Thanks a lot for taking the time to provide this level of
comments. My comments are inline:

<Stefan>
============
Alarm States
============
Can an active alarm have different states then active and cleared?
</Stefan>

Yes, that is the intent.

<Stefan>
It is not really clear which model the Disman Alarm Mib supports/recommends:
the generic traps seems to imply model 1, since there is no changedAlarm 
notification.
</Stefan>

Oops. We should then change the name of the generic notification to
alarmActive to imply this.

A lot of systems are able to handle alarms changing state. Systems
that prefer a simple raise/clear model can always model their alarms
in this manner.

<Stefan>
Even if we stick to model 2 the alarmModelState OBJECT-TYPE models severity
so 
the model
is easier to understand if we use that name.
</Stefan>

We specifically used a term other than severity for reasons I'm trying
to remember. I think part of it was to avoid confusion with
ituPerceivedSeverity.
I think it might also be because of cases like RMON where the states don't
really model well the severities, but as the value of state has an applied
severity, I'm not sure how well that argument holds up.

<Stefan>
====================
Notification design
====================

<clip>

The alarmRaise and alarmClear traps almost fulfil these requirements but c)
is 
missing.
There are two existing OBJECT-TYPES that could be used for this purpose:
- alarmModelDescription		(SnmpAdminString)
- ituAlarmAdditionalText        (DisplayString)
</Stefan>

I'm actually not a fan of attaching everything to trap varbinds. As you
mentioned, alarmModelDescription is static and the manager can read it
in well before it receives the notification and display it. 

The ituAlarmAdditionalText would only be supported by systems using the
ITU-ALARM-MIB, so it can't really be sent as part of these varbinds. Plus,
in practice, I've never really seen any useful information in this field.

<Stefan>
Solution 3: define a new columnar object-type, included in the
alarmActiveTable:

alarmInformation OBJECT-TYPE
      SYNTAX     SnmpAdminString
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
          "...."
      ::= { alarmActiveEntry ... }
</Stefan>

Do you really think systems will code this level of granularity into
their alarm Descriptions? 

<Stefan>
Issue 1b: user-friendly resource identification
-----------------------------------------------
The reference to the resource emitting the alarm should of course be a valid

reference
to an object as done in the current alarm MIB. 
</Stefan>

This is currently being discussed. Can you elaborate on the bits you like
about what's currently being done?

<Stefan>
But again, traps are displayed in 
real-time
for end-users and it is critical for them to quickly identify the resource.

Example: an ifIndex does not tell the typical alarm operator that much...
The alarm should say: "Slot 1, port 17, link is down administratively."

My recommendation is that the user-friendly var-bind above has this
information 
embedded.
</Stefan>

I disagree that this should be done in the agent, especially if it ends up
being
done somewhere like a text string. The result of this approach can be seen
with
fields such as ifName and ifDescription. No agent gives either consistent 
information or consistent format. I've even seen systems where it isn't even
consistent for its different ifTypes. My approach is that base information 
should be given in a consistent, hard to mess up format such as an integer,
and the manager does the mapping to get physical components or other
information
it needs and then displays it in a nice consistent format to the user. In my
experience, this is the only way this sort of thing works.

<Stefan>
Issue 2: index variables in notifications
-----------------------------------------
Notifications should not be carried by traps, see "7.7.  Mapping of the
INDEX 
clause", rfc2578.
If we go for Solution 1 above, sending the alarmModelDescription in the
traps, 
we would implicit send 
the index variables in the var bind:
alarmModelDescription.<alarmModelIndex>.<alarmModelState> = "Toaster
burning"

The definition would be:
alarmRaise NOTIFICATION-TYPE
    OBJECTS     { alarmModelDescription,
                  alarmActiveResourceType,
                  alarmActiveResourceId }
    STATUS      current
</Stefan>

This goes back to how annoying it is that table indices are not accessible
in SMIv2. Annoying, Annoying, Annoying. It looks like we should be fixing
this in SMIng.
 
<Stefan>    
============================
Notification sequence number
============================
In order for the manager and agent to be synchronized regarding alarms a 
sequence number
mechanism of alarms are useful. Every alarmRaise carries a sequence number 
which also is
stored in the alarmActiveTable.
Why is it useful:

a) It is a useful index for the manager to map its alarms to the ones in 
alarmActiveTable.
b) It can be used as an indicatin of missed alarms if there are wholes in
the 
sequence.
(Of course trap filtering makes this not too useful...)
</Stefan>

Well, the alarmActiveLogIndex can serve as this.

<Stefan>
==============================
OBJECT-TYPE descriptions
============================

Below follows some, I hope ;) , improvements on the object descriptions:
<clip>
</Stefan>

Thanks for the suggestions. We'll give them a bit more a read and see if
there is stuff we should incorporate.

<Stefan>
*********************
* ITU-ALARM modules *
*********************

Severity TC
-------------------
What is the motivation for not using the same values as X733?
See below.
I assume one of the reasons is not having 0 as value in the enumerated
since it is not recommended in SMIv1.
Anyhow, I recommend that we reuse the values and possibly move
indeterminate(0) 
to
something else.

X733			ITU-ALARM-TC
====================================
indeterminate(0),	cleared (1),
critical(1),		indeterminate (2),
major(2),		critical (3),
minor(3),		major (4),
warning(4),		minor (5),
cleared(5)		warning (6)

</Stefan>

Hmm. The no enumerated 0 was a factor. I also think this is
an attempt to be able to use the same indices in the 
alarmModelTable as in the ituAlarmTable. There are rowPointers
between the two, but I still think this is a good goal and
if we don't use 0 we can never match the X733 anyways.

<Stefan>
ituAlarmAdditionalText 
-------------------------
Change DisplayString to SNMPAdminString.
</Stefan>

Thanks. I didn't realize I'd missed that one.

<Stefan>
IANAItuProbableCause 
----------------------
I have serious problems with probable cause both in the old ITU standards
and 
now when
applied to SNMP.
The problem is that the definition lacks extensibility. The values in X733 
M3100 etc
are for transmission systems and not useful for modern systems. But since it
is 
not
an OID structure it is impossible to extend for new standards and enterprise

specific values. This has resulted in different vendors just added to the
enum, 
which typically implies collisions when integrating several MIBs.

Any thoughts?
</Stefan>

Well, I hate identifying things via OIDs. My preferred solution, and what
we've done here, is to create an IANA owned enumerated list. It provides
one stop shopping for values and extensibility.

Thanks again for all the comments,

Sharon

---

From: "Stefan Wallin" <[email-masked]>
Date: Wed, 9 Jan 2002 12:26:17 +0100

Hi!
The time stamps of alarms are using the DateAndTime TC.
It is of vital importance that the agents use the optional time zone
information.
We have stumbled across problems in this area since agents usually omit this
part and the alarm manager have serious problems in synchronizing alarms
etc.

Can this requirement be inserted in the OBJECT-TYPES which uses DateAndTime.
best regards Stefan Wallin

-----Ursprungligt meddelande-----
Från: [email-masked]
[mailto:[email-masked]]För Sharon Chisholm
Skickat: den 3 januari 2002 15:30
Till: [email-masked]; Stefan Wallin
Ämne: RE: disman alarm mib comments

hi

<Stefan>
============
Alarm States
============

Yes, that is the intent.

<Stefan>

<Stefan>

<Stefan>
====================
Notification design
====================

<clip>

<Stefan>

<Stefan>

reference

<Stefan>

<Stefan>

The definition would be:

<Stefan>

<Stefan>

<Stefan>
*********************
* ITU-ALARM modules *
*********************

Severity TC
-------------------

X733			ITU-ALARM-TC

</Stefan>

<Stefan>
ituAlarmAdditionalText

<Stefan>
IANAItuProbableCause
----------------------

Any thoughts?
</Stefan>

Sharon