RE: The ITU-ALARM-MIB and SpecificProblems.

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 protected]]=20
Sent: Monday, November 27, 2006 2:37 PM
To: [email protected]
Subject: Re: [Disman] The ITU-ALARM-MIB and SpecificProblems.

Hi -

> From: "Gamet, Thomas" <[email protected]>
> To: <[email protected]>
> 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
> part of what makes an alarm unique but it is not provided in the
> definitions given in RFC 3877. =20

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
> a SET OF construct.)  May be the reason this item was omitted is that
an
> 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
> there some other mechanism in the minds of the original contributors
for
> covering the purpose of specificProblems in the ITU standards?

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

>  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.

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

> And=20
> 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,"
>   ::=3D { 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.

Why not use the ituAlarmGenericModel mechanism?

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

These are most unwelcome on IETF mailing lists.

Randy