Subject: RE: time stamp of alarms in ALARM MIB

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Jan 2002 19:29:07 +0200

I do not think that we can do much more in this document than putting a
SHOULD in the DESCRIPTION clause.

The issue seems more general, it applies not only for this MIB, but for
all applications that use agents distributed in different time zones.
Maybe we should define a new TC ZoneDateAndTime, that is similar with
DateAndTime, with the exception of the last two infamous rows in the TC
DESCRIPTION.

Regards,

Dan

> -----Original Message-----
> From: Stefan Wallin [mailto:[email-masked]]
> Sent: Wednesday, January 09, 2002 1:26 PM
> To: [email-masked]
> Subject: time stamp of alarms in ALARM MIB
> 
> 
> 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
> 
> 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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jan 2002 19:09:37 +0100

>>>>> Romascanu, Dan (Dan) writes:

Dan> I do not think that we can do much more in this document than
Dan> putting a SHOULD in the DESCRIPTION clause.

And I think that is appropriate and enough.

Dan> The issue seems more general, it applies not only for this MIB,
Dan> but for all applications that use agents distributed in different
Dan> time zones.  Maybe we should define a new TC ZoneDateAndTime,
Dan> that is similar with DateAndTime, with the exception of the last
Dan> two infamous rows in the TC DESCRIPTION.

I do not think there is a problem with the DateAndTime TC. It says:

            Note that if only local time is known, then timezone
            information (fields 8-10) is not present."

Perhaps the language could be stronger, but it basically says the
right thing to me: Report the timezone except in cases where the
timezone information is not available.

Defining a ZoneDateAndTime which requires to report the timezone even
if your box has no clue about the timezone is not a step forward and
people will just report GMT or something like that which is worse.

/js

---

From: Stefan Wallin <[email-masked]>
Date: Thu, 10 Jan 2002 07:32:05 +0100 (CET)

I agree, in the context of the alarm mib, all that is needed is a SHOULD clause 
in the description so that I can hit people implementing agents without tz info.
/stefan

> > Anyhow, I recommend that we reuse the values and possibly move

Stefan Wallin
Data Ductus AB
+46 70 5233262
[email-masked]