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: Wednesday, May 12, 2010 5:01 AM
> Subject: Re: [Disman] [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.
...

Two observations:
   (1)  The working group was specifically chartered:
   "The work on the Alarm MIB will take into consideration existing
   standards and practices, such as ITU-T X.733.  Whether any mappings to
   these other standards appear in the Alarm MIB or in separate documents
   will be decided by the WG.  The WG will actively seek participation
   from ITU participants to make ensure that the ITU work is correctly
   understood."   So, I wondered, why does section 3.1 in its definition
   of "Alarm State" (NOT "Status") give M.3100 as an example rather
   than X.733?  Turns out it was in response to my comment requesting
   that *a* reference be given  (October 7, 2003) but there was no
   discussion whether one or the other would have been a better example
   to cite.

  (2) RFC3877 never mentions alarmStatus.  Is your issue that you'd expect the
  ituAlarmTable in RFC 3877 to emulate the behaviour of an ITU (pick your
  standard) alarmStatus?  Sharon, Dan, was that the intent?

Randy