Subject: [Disman] The ITU-ALARM-MIB and SpecificProblems.

From: "Gamet, Thomas" <[email-masked]>
Date: Mon, 27 Nov 2006 10:51:04 -0500

We are considering the use of the ituAlarmTable as an extension to the
alarmMobelTable's rows that would give us the ability to report alarm
data from an EMS function to an NMS using ITU standardized alarm
information.  The problem is that specificProblems, from X.721/X.733, is
part of what makes an alarm unique but it is not provided in the
definitions given in RFC 3877.  

The TMF 814 (the probable cause qualifier), and CIM from the DMTF (the
probable cause description), also provide mechanisms for extending a
probable cause with more detailed or specific problem descriptions.
Unlike the ITU, these other standards use only a string to provide the
additional qualification/description on the probable cause (the ITU uses
a SET OF construct.)  May be the reason this item was omitted is that an
accurate representation is difficult to achieve with SNMP?  Or, was
there some other mechanism in the minds of the original contributors for
covering the purpose of specificProblems in the ITU standards?  In
either event, it needs to be available in the alarm model in order for
the alarmActiveState and alarmClearState notification types to provide
sufficient detail when sending notifications of alarm state changes.

If possible, I'd like to see the following added to the ITU-ALARM-MIB's
ItuAlarmEntry...
  ituAlarmSpecificProblemsString	SnmpAdminString

And 
ituAlarmSpecificProblemsString OBJECT-TYPE
  SYNTAX	SnmpAdminString
  MAX-ACCESS	read-write
  STATUS	current
  DESCRIPTION
	"String version of the ITU SET OF specificProblems using ASN.1
Value Notation."
  REFERENCES
	"ITU Recommendation X.733,"
  ::= { ituAlarmEntry 6 }

This should keep the data type simple for SNMP to handle and still
preserve the meaning of ITU specificProblem information.  It should also
be data that can be shared with CIM and TMF compliant systems.
Comments, suggestions and corrections are welcome.

Regards,

Thomas Gamet
Interim Manager - Systems Engineering
Harris Corporation, Microwave Communications Division, NetBoss Business
Unit
Tel:  321-724-3260 (USA, Eastern Time, -05:00 GMT)
Fax: 321-724-3940
E-mail:  [email-masked]

	*****Confidentiality Notice*****
	This message is confidential. If you are not the intended
recipient, you may not copy or otherwise disclose the contents of this
message to any other person. If you have received this message in error,
please contact the sender immediately by return e-mail. Thank you.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Nov 2006 11:36:30 -0800

Hi -

> From: "Gamet, Thomas" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 27, 2006 7:51 AM
> Subject: [Disman] The ITU-ALARM-MIB and SpecificProblems.
...
> The problem is that specificProblems, from X.721/X.733, is

Perhaps we have a different understanding of "unique", but in my
(1991 DIS 10164-4) copy of X.733, specificProblems is an optional
parameter, so it would hardly be suitable for use in naming.

...
> (the ITU uses
> accurate representation is difficult to achieve with SNMP?

No.  There are (ugly) ways to handle this in SNMP MIBs.
But in this particular case, this sounds like it should be
handled just like any of the other additional parameters,
via alarmActiveVariableEntry, for example.

>  Or, was
> covering the purpose of specificProblems in the ITU standards?

No.  No one asked for it, as far as I can recall.

>  In

Quoting the DIS text (which probably hasn't changed):
|   This parameter, when present, identifies further refinements to the
|   Probable cause of the alarm.  This parameter qualifies the chosen
|   Probable cause and may be used by the managed object class definer
|   to specify a set of identifiers for use in managed object classes.
|
|   This parameter is either a set of integers or a set of object identifiers.
|   However, only object identifiers shall be used within the Systems
|   management context...

In other words, this is an optional parameter which can be interpreted
only by looking at the definition of the managed object class that
emitted the alarm.  I understand the value of having locale-independent
identifiers to permit further qualification of the Probable cause,
but it's not surprising that later specifications relegated
this information to a text string.  It really sounds like it should be handled
using the alarmActiveVariableEntry mechanism.

| If possible, I'd like to see the following added to the ITU-ALARM-MIB's
| ItuAlarmEntry...
|   ituAlarmSpecificProblemsString SnmpAdminString

There are two things that would need to happen -
   (1) there'd need to be agreement to produce an update to RFC 3877
   (2) there'd need to be agreement that this specific change was needed,
         based on implementation / deployment / operational experience
   (3) there'd need to be agreement that the existing ituAlarmGenericModel /
         alarmActiveVariableEntry mechanism was inadequate for this case

> Comments, suggestions and corrections are welcome.

Why not use the ituAlarmGenericModel mechanism?

...
> *****Confidentiality Notice*****
...

These are most unwelcome on IETF mailing lists.

Randy

---

From: "Gamet, Thomas" <[email-masked]>
Date: Mon, 27 Nov 2006 17:54:01 -0500

Hi,

First, my apologies for misusing this forum.

Second, please see ITU-T Recommendation X.733 - Corrigendum 2...

Subclause 8.1.2.3
Replace paragraph 2 with the following:
- cleared: The Cleared severity level indicates the clearing of one or
more previously reported alarms. The
alarms to be cleared are indicated by the managed object, Event type,
Probable cause, Specific problems
(if present) and Correlated notifications parameters as follows:
A....
b) If the Specific problems parameter is present and not empty, and the
Correlated notifications is not
present or empty, then only previous alarms that have an exact match on
managed object, Probable
cause, Event type, and have a matching set or subset of Specific
problems will be cleared.
C....

Reason b) restricts the clearing of alerts to only clear alerts that
also match the specific problems reported when they are reported.  This
is particularly useful when the probable cause given is "unknown", but
may also be useful when distinguishing alarm reports for still rather
abstract probable causes such as transmitterFailure (when the hardware
provides details that are more specific and make sense to the
manufacturer to report as distinct.)

Regards,

Tom

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, November 27, 2006 2:37 PM
To: [email-masked]
Subject: Re: [Disman] The ITU-ALARM-MIB and SpecificProblems.

Hi -

...

...

|   This parameter is either a set of integers or a set of object
identifiers.

this information to a text string.  It really sounds like it should be
handled

| If possible, I'd like to see the following added to the
ITU-ALARM-MIB's
| ItuAlarmEntry...
|   ituAlarmSpecificProblemsString SnmpAdminString

There are two things that would need to happen -
   (1) there'd need to be agreement to produce an update to RFC 3877
   (2) there'd need to be agreement that this specific change was
needed,
         based on implementation / deployment / operational experience
   (3) there'd need to be agreement that the existing
ituAlarmGenericModel /
         alarmActiveVariableEntry mechanism was inadequate for this case

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Nov 2006 17:57:35 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Monday, November 27, 2006 2:54 PM
> Subject: RE: [Disman] The ITU-ALARM-MIB and SpecificProblems.
...
...

Thanks, that explains why the parameter is more interesting now than
it was when the ISO/ITU alarm stuff was originally written.

It doesn't, however, explain why it needs its own column in the table.
Couldn't it be handled just like any other variable binding by using the
alarmModelTable to indicate that it is "interesting"?  In particular, the
exact match requirement seems to rule out the combinatorial complications
that would otherwise make using the existing mechanism hard.

Randy