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

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 3 Jan 2007 14:38:59 -0500

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? 

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. 

Sharon

> -----Original Message-----
> From: Gamet, Thomas [mailto:[email-masked]] 
> Sent: Monday, December 04, 2006 11:31 AM
> To: [email-masked]
> Subject: RE: [Disman] 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. 
> Note: It is similar to ProbableCauseQualifier, but this 
> parameter is designed to be human readable and compatible 
> with ITU usage. 
> 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 
> 
> -----Original Message-----
> From: Gamet, Thomas
> Sent: Monday, November 27, 2006 5:54 PM
> To: Randy Presuhn; [email-masked]
> 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-masked]]
> Sent: Monday, November 27, 2006 2:37 PM
> To: [email-masked]
> Subject: Re: [Disman] The ITU-ALARM-MIB and SpecificProblems.
> 
> 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 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
> 
> 
> 
> 
>