Re: [Errata Rejected] RFC3877 (1652)

"Romascanu, Dan (Dan)" <[email protected]> Thu, 13 May 2010 09:14:22 +0200
Newsgroups gmane.ietf.disman
Message-ID <EDC652A26FB23C4EB6384A4584434A04021BEE63@307622ANEX5.global.avaya.com>
(speaking as a contributor and co-author of RFC 3877)

Our intention with ituAlarmTable was stated in 4.1.3=20

> Optionally, ituAlarmPerceivedSeverity models
   the states in terms of ITU perceived severity.=20

and then in 5.1:

> The ituAlarmTable contains information from the ITU Alarm Model about
   possible alarms in the system.

My recollection is that we did not seek exact emulation, but a mapping
that makes sense for the severity levels. We looked at the ITU-T
standards because we did not want to reinvent the wheel. I personally
was not aware about the differences between M.3100 and X.733 on this
respect, but frankly I was relying on Sharon who was at that time
directly involved in the ITU-T work.=20

Dan


> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]=20
> Sent: Wednesday, May 12, 2010 9:23 PM
> To: [email protected]
> Cc: Romascanu, Dan (Dan); Disman; [email protected]
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>=20
> Hi -
>=20
> > From: "Brian F. G. Bidulock" <[email protected]>
> > To: "Randy Presuhn" <[email protected]>
> > Cc: "Romascanu, Dan (Dan)" <[email protected]>; "Disman"=20
> > <[email protected]>; <[email protected]>
> > Sent: Wednesday, May 12, 2010 5:01 AM
> > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> >
> > Randy,
> >=20
> > I should have also given you the comment from the M.3100 GDMOS:
> >=20
> > -- 7.3.13 alarmStatus
> > -- The semantics of alarmStatus defined in ITU-T=20
> Recommendation M.3100
> > -- are different from alarmStatus defined in ITU-T Recommendation=20
> > X.721
> > -- and ITU-T Recommendation X.731.  This difference in semantics is
> > -- deliberate and reflects the requirement of Telecom Operators to=20
> > have
> > -- an aggregated or consolidated alarm status for alarm management.
> ...
>=20
> 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=20
> mappings to
>    these other standards appear in the Alarm MIB or in=20
> 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=20
> 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=20
> better example
>    to cite.
>=20
>   (2) RFC3877 never mentions alarmStatus.  Is your issue that=20
> you'd expect the
>   ituAlarmTable in RFC 3877 to emulate the behaviour of an=20
> ITU (pick your
>   standard) alarmStatus?  Sharon, Dan, was that the intent?
>=20
> Randy
>=20
>=20
>=20