Re: [Errata Rejected] RFC3877 (1652)

Hi -

> From: "Brian F. G. Bidulock" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: "Romascanu, Dan (Dan)" <[email protected]>; "Disman" <[email protected]>; <[email protected]>
> 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.)

> 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.

> 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