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

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

Why not use the ituAlarmGenericModel mechanism?

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

These are most unwelcome on IETF mailing lists.

Randy