Re: [Disman] [Errata Rejected] RFC3877 (1652)

["Brian F. G. Bidulock" <[e-mail]>]

Randy,

I should have also given you the comment from the M.3100 GDMOS:

-- 7.3.13 alarmStatus
-- The semantics of alarmStatus defined in ITU-T Recommendation M.3100
-- are different from alarmStatus defined in ITU-T Recommendation X.721
-- and ITU-T Recommendation X.731.  This difference in semantics is
-- deliberate and reflects the requirement of Telecom Operators to have
-- an aggregated or consolidated alarm status for alarm management.

--brian

On Wed, 12 May 2010, Brian F. G. Bidulock wrote:

> Randy,
> 
> On Tue, 11 May 2010, Randy Presuhn wrote:
> 
> > Hi -
> > 
> > > From: "Brian F. G. Bidulock" <[e-mail]>
> > > To: "Randy Presuhn" <[e-mail]>
> > > Cc: "Romascanu, Dan (Dan)" <[e-mail]>; "Disman" <[e-mail]>; <[e-mail]>
> > > Sent: Tuesday, May 11, 2010 4:44 PM
> > > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> > >
> > > Randy,
> > > 
> > > Actually, the severity levels from M.3100 are completely different.
> > > This MIB models the ITU-T Rec. X.721 ISO/EIC 10165-2 severities (OSI
> > > severities, not telco severities).
> > 
> > They're the same thing.  M.3100 IMPORTS PerceivedSeverity from X.721  
> > The tables in M.3100 for handling PerceivedSeverity appear to
> > be consistent with X.721 and X.733  (Which is not surprising,
> > since some of the same people were involved in writing all three.)
> 
> You still don't get it: I am not talking about enumerations of
> perceivedSeverity.  I am talking about the severity levels of
> alarmStatus:
> 
> This from the M.3100 GDMOs: (alarmStatus ATTRIBUTE DEFINED AS)
> 
>     "The Alarm Status attribute type indicates the occurrence of an
>      abnormal condition relating to an object. This attribute may also
>      function as a summary indicator of alarm conditions associated with
>      a specific resource. It is used to indicate the existence of an
>      alarm condition, a pending alarm condition such as threshold
>      situations, or (when used as a summary indicator) the highest
>      severity of active alarm conditions. When used as a summary
>      indicator, the order of severity (from highest to lowest) is:
> 
> 	activeReportable-Critical
> 	activeReportable-Major
> 	activeReportable-Minor
> 	activeReportable-Indeterminate
> 	activeReportable-Warning
> 	activePending
> 	cleared."
> 
> And from the M.3100 ASN:
> 
> AlarmStatus ::= ENUMERATED {
> 	cleared(0),
> 	activeReportable-Indeterminate(1),
> 	activeReportable-Warning(2),
> 	activeReportable-Minor(3),
> 	activeReportable-Major(4),
> 	activeReportable-Critical(5),
> 	activePending(6) }
> 
> Now, just in the MIB:
> 
>     "Entries appear in this table whenever an entry is created
>      in the alarmModelTable with a value of alarmModelState in
>      the range from 1 to 6.  Entries disappear from this table
>      whenever the corresponding entries are deleted from the
>      alarmModelTable, including in cases where those entries
>      have been deleted due to local system action.  The value of
>      alarmModelSpecificPointer has no effect on the creation
>      or deletion of entries in this table.  Values of
>      alarmModelState map to values of ituAlarmPerceivedSeverity
>      as follows:
> 
>        alarmModelState -> ituAlarmPerceivedSeverity
> 	      1        ->         clear (1)
> 	      2        ->         indeterminate (2)
> 	      3        ->         warning (6)
> 	      4        ->         minor (5)
> 	      5        ->         major (4)
> 	      6        ->         critical (3)
> 
>      All other values of alarmModelState MUST NOT appear
>      in this table.
> 
> And alarmModelState
> 
>         "A value of 1 MUST indicate a clear alarm state.
>         The value of this object MUST be less than the
>         alarmModelState of more severe alarm states for
>         this alarm.  The value of this object MUST be more
>         than the alarmModelState of less severe alarm states
>         for this alarm."
> 
> 
> So, the alarm model state values must be ordered in order of severity,
> otherwise, masking occurs.  However, the alarmModelState value
> mapping from perceivedSeverity do no match the M.3100 alarmStatus
> severity levels.  INDETERMINATE AND WARNING ARE REVERSED.  Therefore
> the mapping does not follow the MUST rules for alarmModelState per
> M.3100 alarmStatus which is NOT the same as the X.721 alarmStatus.
> 
> > 
> > > Nevertheless, if one follows the alarm states in the document, a
> > > more severe alarm (indeterminate(2)) will be masked by a less
> > > severe alarm (warning(6)), making it largely unusable for the
> > > purpose for which it was intended.
> > 
> > X.721 specifically comments (page 41) that "indeterminate" is
> > only used when it is not possible to assign one of the other values.
> > The semantics nailed down in X.733, in clause 8.1.2.3, only
> > specify the relative severity of the other values, not for "indeterminate".
> > Likewise, 8.1.2.6, "Trend Indication", also does not include
> > "indeterminate" in the ordering.  Consequently, I do not see how
> > either the current ordering, nor the proposed change, could be
> > supported by citing M.3100 or X.733.
> 
> See M.3100 alarmStatus, per above.  Because the alarmModelState
> rule (MUST) is violated, and alarm of activeReportable-Warning
> will mask more severe alarms of activeReportable-Indeterminate.
> 
> > 
> > > I submitted this errata over a year ago.  In the meantime I have
> > > found this MIB so lacking that I implemented alarms management
> > > completely in private MIBs.
> > > 
> > > So, do what you want with it: it is useless to me.
> > ...
> > 
> > I'm not arguing your point.  I'm just saying that the "verifier notes"
> > that accompanied the rejection appear to belong to a DIFFERENT
> > erratum, and did not address the point of your comments.  I'm
> > AGREEING with you that there is (at least) a documentation problem,
> > in that the mapping does not fit X.721 /  X.733.  M.3100 merely imports
> > the definition from X.721, and does NOT, as far as I can see, do anything
> > to "indeterminate" to justify the proposed change in order.  However, it
> > also makes it clear that the existing order, while perhaps sensible for
> > some application, is not justified by the base standards.
> > 
> > Randy
> 
> 
> Again, read my lips: not perceivedSeverity enumerations, but
> M.3100 alarmStatus to alarmModelState mapping.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [e-mail]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[e-mail]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦