RE: The ITU-ALARM-MIB and SpecificProblems.

Hi

Just to clarify, are you requesting an update to the document to add one
new field?

Back when I was involved in the ITU-T, there was work going on around
replacing probable cause with a hierarchical 'reason' field that was
both organized and easier to extend. Do you know the status of that
work?=20

I'd personally rather see an update to support 'reason' for problem
identification rather then the 'specific problem' field. 'Specific
problem' seems a bit of a hack or perhaps a way to do proprietary
extensions. We have defined a vendor-specific extension to the Alarm MIB
to capture stuff we wish was in the MIB and this isn't there.=20

Sharon

> -----Original Message-----
> From: Gamet, Thomas [mailto:[email protected]]=20
> Sent: Monday, December 04, 2006 11:31 AM
> To: [email protected]
> Subject: RE: [Disman] The ITU-ALARM-MIB and SpecificProblems.
>=20
> Randy:  Thank you for asking me to provide comments that may=20
> be relevant to the DISMAN regarding the ITU-T.  I would like=20
> to acknowledge that the DISMAN's contributors have produced a=20
> strong and useful document, and that I look forward to seeing=20
> it become stronger.
>=20
> I continue to stand by the X.733 Corrigendum 2 definition=20
> that requires uniqueness of ITU-T alert records based on=20
> sharing the same managed object, event type, probable cause,=20
> and if present specific problems, as cause to have a distinct=20
> set of rows representing an alarm.  However, may be the Y=20
> Series work for NGN will change that someday.  Specific=20
> problems does not have to expand the tree exponentially (it=20
> should be more of a polynomial function).  In practice, I'd=20
> be surprised to see it more than double the number of rows=20
> relative to the number of probable causes listed between the=20
> M.3000 Series and X.700 Series work per type of resource=20
> being managed.  I think it would be reasonable to add a=20
> clause stating that managed systems may add a new set of=20
> model rows, given a model entry that has a matching event=20
> type and probable cause already exist, and then include the=20
> specific problems in the new rows.
> Management systems, upon detecting a new model pointer index,=20
> would then go to 'learn' about the specific problems by=20
> interrogating (via get or
> getBulk) the ITU compliant managed system.  Odds are that=20
> this will be appropriate for the ITU managed systems, given=20
> that the probable cause of the event type is already of=20
> interest to the management system.
>=20
> The ITU-T additional text field is meant to contain a human=20
> readable string.  The ITU-T X.733 does state:
> "The Additional text parameter may be used to identify and=20
> communicate additional or more specific alarm information.=20
> However, the preferred method is by registration and use of=20
> additional values for the Probable cause and/or Specific=20
> problems and/or Additional information parameters."
> Specific problems, per ITU-T, are meant to be machine=20
> readable and per pure ITU-T definition is a set of integers=20
> and/or object identifiers.
> Corrigendum 2 allows subset comparison to cause the clearing=20
> of multiple alarm records based on the specific problems. =20
> This is quite a bit more machine friendly than human=20
> friendly.  Post corrigendum 2, additional text may provide=20
> the specific problems in a human readable fashion, but need=20
> not do so.  In fact, an ITU-T managed system can put=20
> arbitrary text into its additional text field, which may have=20
> nothing to do with establishing the uniqueness of an alert=20
> record, and still be fully conformant.
>=20
> TMF 608, version 3, includes specific problems for ITU-T=20
> interoperability.  For example, TMF 608 states...
> "The optional Specific Problems parameter, when present in an=20
> alarm notification, identifies further refinements to the=20
> Probable Cause of the alarm.=20
> Note: It is similar to ProbableCauseQualifier, but this=20
> parameter is designed to be human readable and compatible=20
> with ITU usage.=20
> This is consistent with the ITU-T X.733 definition."
>=20
> For alarm management interoperability with both CMISE and TMF=20
> solutions, I think it will be beneficial to explicitly=20
> include specific problems in the DISMAN ALARM-MIB.
>=20
> Tom=20
>=20
> -----Original Message-----
> From: Gamet, Thomas
> Sent: Monday, November 27, 2006 5:54 PM
> To: Randy Presuhn; [email protected]
> Subject: RE: [Disman] The ITU-ALARM-MIB and SpecificProblems.
>=20
> Hi,
>=20
> First, my apologies for misusing this forum.
>=20
> Second, please see ITU-T Recommendation X.733 - Corrigendum 2...
>=20
> Subclause 8.1.2.3
> Replace paragraph 2 with the following:
> - cleared: The Cleared severity level indicates the clearing=20
> of one or more previously reported alarms. The alarms to be=20
> cleared are indicated by the managed object, Event type,=20
> Probable cause, Specific problems (if present) and Correlated=20
> notifications parameters as follows:
> A....
> b) If the Specific problems parameter is present and not=20
> empty, and the Correlated notifications is not present or=20
> empty, then only previous alarms that have an exact match on=20
> managed object, Probable cause, Event type, and have a=20
> matching set or subset of Specific problems will be cleared.
> C....
>=20
> Reason b) restricts the clearing of alerts to only clear=20
> alerts that also match the specific problems reported when=20
> they are reported.  This is particularly useful when the=20
> probable cause given is "unknown", but may also be useful=20
> when distinguishing alarm reports for still rather abstract=20
> probable causes such as transmitterFailure (when the hardware=20
> provides details that are more specific and make sense to the=20
> manufacturer to report as distinct.)
>=20
> Regards,
>=20
> Tom
>=20
> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]
> Sent: Monday, November 27, 2006 2:37 PM
> To: [email protected]
> Subject: Re: [Disman] The ITU-ALARM-MIB and SpecificProblems.
>=20
> Hi -
>=20
> > 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=20
> > what makes an alarm unique but it is not provided in the=20
> definitions=20
> > 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=20
> optional parameter, so it would hardly be suitable for use in naming.
>=20
> ...
> > (the ITU uses
> > a SET OF construct.)  May be the reason this item was=20
> omitted is that
> an
> > accurate representation is difficult to achieve with SNMP?
>=20
> No.  There are (ugly) ways to handle this in SNMP MIBs.
> But in this particular case, this sounds like it should be=20
> handled just like any of the other additional parameters, via=20
> alarmActiveVariableEntry, for example.
>=20
> >  Or, was
> > there some other mechanism in the minds of the original contributors
> for
> > covering the purpose of specificProblems in the ITU standards?
>=20
> No.  No one asked for it, as far as I can recall.
>=20
> >  In
> > either event, it needs to be available in the alarm model=20
> in order for=20
> > the alarmActiveState and alarmClearState notification types=20
> to provide=20
> > sufficient detail when sending notifications of alarm state changes.
>=20
> Quoting the DIS text (which probably hasn't changed):
> |   This parameter, when present, identifies further=20
> 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...
>=20
> In other words, this is an optional parameter which can be=20
> interpreted only by looking at the definition of the managed=20
> object class that emitted the alarm.  I understand the value=20
> of having locale-independent identifiers to permit further=20
> qualification of the Probable cause, but it's not surprising=20
> that later specifications relegated this information to a=20
> text string.  It really sounds like it should be handled=20
> using the alarmActiveVariableEntry mechanism.
>=20
> | If possible, I'd like to see the following added to the
> ITU-ALARM-MIB's
> | ItuAlarmEntry...
> |   ituAlarmSpecificProblemsString SnmpAdminString
>=20
> 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=20
> was needed,
>          based on implementation / deployment / operational experience
>    (3) there'd need to be agreement that the existing=20
> ituAlarmGenericModel /
>          alarmActiveVariableEntry mechanism was inadequate=20
> for this case
>=20
> > And
> > ituAlarmSpecificProblemsString OBJECT-TYPE
> >   SYNTAX SnmpAdminString
> >   MAX-ACCESS read-write
> >   STATUS current
> >   DESCRIPTION
> > "String version of the ITU SET OF specificProblems using=20
> ASN.1 Value=20
> > Notation."
> >   REFERENCES
> > "ITU Recommendation X.733,"
> >   ::=3D { ituAlarmEntry 6 }
> >
> > This should keep the data type simple for SNMP to handle and still=20
> > 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.
>=20
> Why not use the ituAlarmGenericModel mechanism?
>=20
> ...
> > *****Confidentiality Notice*****
> ...
>=20
> These are most unwelcome on IETF mailing lists.
>=20
> Randy
>=20
>=20
>=20
>=20
>=20