RE: The ITU-ALARM-MIB and SpecificProblems.

Randy:  Thank you for asking me to provide comments that may be relevant
to the DISMAN regarding the ITU-T.  I would like to acknowledge that the
DISMAN's contributors have produced a strong and useful document, and
that I look forward to seeing it become stronger.

I continue to stand by the X.733 Corrigendum 2 definition that requires
uniqueness of ITU-T alert records based on sharing the same managed
object, event type, probable cause, and if present specific problems, as
cause to have a distinct set of rows representing an alarm.  However,
may be the Y Series work for NGN will change that someday.  Specific
problems does not have to expand the tree exponentially (it should be
more of a polynomial function).  In practice, I'd be surprised to see it
more than double the number of rows relative to the number of probable
causes listed between the M.3000 Series and X.700 Series work per type
of resource being managed.  I think it would be reasonable to add a
clause stating that managed systems may add a new set of model rows,
given a model entry that has a matching event type and probable cause
already exist, and then include the specific problems in the new rows.
Management systems, upon detecting a new model pointer index, would then
go to 'learn' about the specific problems by interrogating (via get or
getBulk) the ITU compliant managed system.  Odds are that this will be
appropriate for the ITU managed systems, given that the probable cause
of the event type is already of interest to the management system.

The ITU-T additional text field is meant to contain a human readable
string.  The ITU-T X.733 does state:
"The Additional text parameter may be used to identify and communicate
additional or more specific alarm information. However, the preferred
method is by registration and use of additional values for the Probable
cause and/or Specific problems and/or Additional information
parameters."
Specific problems, per ITU-T, are meant to be machine readable and per
pure ITU-T definition is a set of integers and/or object identifiers.
Corrigendum 2 allows subset comparison to cause the clearing of multiple
alarm records based on the specific problems.  This is quite a bit more
machine friendly than human friendly.  Post corrigendum 2, additional
text may provide the specific problems in a human readable fashion, but
need not do so.  In fact, an ITU-T managed system can put arbitrary text
into its additional text field, which may have nothing to do with
establishing the uniqueness of an alert record, and still be fully
conformant.

TMF 608, version 3, includes specific problems for ITU-T
interoperability.  For example, TMF 608 states...
"The optional Specific Problems parameter, when present in an alarm
notification, identifies further refinements to the Probable Cause of
the alarm.=20
Note: It is similar to ProbableCauseQualifier, but this parameter is
designed to be human readable and compatible with ITU usage.=20
This is consistent with the ITU-T X.733 definition."

For alarm management interoperability with both CMISE and TMF solutions,
I think it will be beneficial to explicitly include specific problems in
the DISMAN ALARM-MIB.

Tom=20

-----Original Message-----
From: Gamet, Thomas=20
Sent: Monday, November 27, 2006 5:54 PM
To: Randy Presuhn; [email protected]
Subject: RE: [Disman] 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