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