Re: [Errata Rejected] RFC3877 (1652)

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,
>=20
> On Tue, 11 May 2010, Randy Presuhn wrote:
>=20
> > Hi -
> >=20
> > > From: "Brian F. G. Bidulock" <[email protected]>
> > > To: "Randy Presuhn" <[email protected]>
> > > Cc: "Romascanu, Dan (Dan)" <[email protected]>; "Disman" <disman@i=
etf.org>; <[email protected]>
> > > Sent: Tuesday, May 11, 2010 4:44 PM
> > > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> > >
> > > Randy,
> > >=20
> > > Actually, the severity levels from M.3100 are completely different.
> > > This MIB models the ITU-T Rec. X.721 ISO/EIC 10165-2 severities (OS=
I
> > > severities, not telco severities).
> >=20
> > They're the same thing.  M.3100 IMPORTS PerceivedSeverity from X.721 =
=20
> > 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.)
>=20
> You still don't get it: I am not talking about enumerations of
> perceivedSeverity.  I am talking about the severity levels of
> alarmStatus:
>=20
> This from the M.3100 GDMOs: (alarmStatus ATTRIBUTE DEFINED AS)
>=20
>     "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 wit=
h
>      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:
>=20
> 	activeReportable-Critical
> 	activeReportable-Major
> 	activeReportable-Minor
> 	activeReportable-Indeterminate
> 	activeReportable-Warning
> 	activePending
> 	cleared."
>=20
> And from the M.3100 ASN:
>=20
> AlarmStatus ::=3D ENUMERATED {
> 	cleared(0),
> 	activeReportable-Indeterminate(1),
> 	activeReportable-Warning(2),
> 	activeReportable-Minor(3),
> 	activeReportable-Major(4),
> 	activeReportable-Critical(5),
> 	activePending(6) }
>=20
> Now, just in the MIB:
>=20
>     "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:
>=20
>        alarmModelState -> ituAlarmPerceivedSeverity
> 	      1        ->         clear (1)
> 	      2        ->         indeterminate (2)
> 	      3        ->         warning (6)
> 	      4        ->         minor (5)
> 	      5        ->         major (4)
> 	      6        ->         critical (3)
>=20
>      All other values of alarmModelState MUST NOT appear
>      in this table.
>=20
> And alarmModelState
>=20
>         "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."
>=20
>=20
> 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.
>=20
> >=20
> > > 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.
> >=20
> > 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 "indetermi=
nate".
> > 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.
>=20
> 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.
>=20
> >=20
> > > 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.
> > >=20
> > > So, do what you want with it: it is useless to me.
> > ...
> >=20
> > 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 impor=
ts
> > the definition from X.721, and does NOT, as far as I can see, do anyt=
hing
> > to "indeterminate" to justify the proposed change in order.  However,=
 it
> > also makes it clear that the existing order, while perhaps sensible f=
or
> > some application, is not justified by the base standards.
> >=20
> > Randy
>=20
>=20
> Again, read my lips: not perceivedSeverity enumerations, but
> M.3100 alarmStatus to alarmModelState mapping.
>=20
> --brian
>=20
> --=20
> Brian F. G. Bidulock    =A6 The reasonable man adapts himself to the =A6
> [email protected]    =A6 world; the unreasonable one persists in  =A6
> http://www.openss7.org/ =A6 trying  to adapt the  world  to himself. =A6
>                         =A6 Therefore  all  progress  depends on the =A6
>                         =A6 unreasonable man. -- George Bernard Shaw =A6

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