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

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

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 ¦