Re: [Errata Rejected] RFC3877 (1652)

Brian,

Please use my first name and not the family name.=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, May 11, 2010 5:54 PM
> To: Romascanu, Dan (Dan)
> Cc: Disman; [email protected]
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>=20
> Romascanu,,
>=20
> Perhaps the errata should add a statement then, that the=20
> order is, and will remain, in error.
>=20
> --brian
>=20
> On Tue, 11 May 2010, Romascanu, Dan (Dan) wrote:
>=20
> >  Brian,
> >=20
> > (the distribution list slightly changes)
> >=20
> > I think that we understand this. What you proposed is a=20
> change in the=20
> > mapping, which would not be backwards compatible with the current=20
> > deployment. What is suggested is that the text is changed=20
> to mention=20
> > the differences between the order in the two models - this=20
> text would=20
> > include your observation about the order of severity not being the=20
> > same as the one defined in the ITU-T document.
> >=20
> > Regards,
> >=20
> > Dan
> >=20
> >=20
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: Tuesday, May 11, 2010 3:51 PM
> > > To: RFC Errata System
> > > Cc: [email protected]; Romascanu, Dan (Dan);=20
> [email protected]
> > > Subject: Re: [Errata Rejected] RFC3877 (1652)
> > >=20
> > > Let me try one more time; read my lips:
> > >=20
> > > It is not the enumerated value that need to change.
> > >=20
> > > The document states that the alarm states are ordered from least=20
> > > severe to most severe, but (without the correction) they are not.
> > >=20
> > > --brian
> > >=20
> > > On Tue, 11 May 2010, RFC Errata System wrote:
> > >=20
> > > >=20
> > > > The following errata report has been rejected for=20
> RFC3877, "Alarm=20
> > > > Management Information Base (MIB)".
> > > >=20
> > > > --------------------------------------
> > > > You may review the report below and at:
> > > > =
http://www.rfc-editor.org/errata_search.php?rfc=3D3877&eid=3D1652
> > > >=20
> > > > --------------------------------------
> > > > Status: Rejected
> > > > Type: Technical
> > > >=20
> > > > Reported by: Brian Bidulock <[email protected]> Date=20
> Reported:=20
> > > > 2009-01-13 Rejected by: Dan Romascanu (IESG)
> > > >=20
> > > > Section: 5.4
> > > >=20
> > > > Original Text
> > > > -------------
> > > > alarmModelState -> ituAlarmPerceivedSeverity
> > > >        1        ->         clear (1)
> > > >        2        ->         indeterminate (2)
> > > >        3        ->         warning (6)
> > > >        4        ->         minor (5)
> > > >        5        ->         major (4)
> > > >        6        ->         critical (3)
> > > >=20
> > > > Corrected Text
> > > > --------------
> > > > alarmModelState -> ituAlarmPerceivedSeverity
> > > >        1        ->         clear (1)
> > > >        2        ->         warning (6)
> > > >        3        ->         indeterminate (2)
> > > >        4        ->         minor (5)
> > > >        5        ->         major (4)
> > > >        6        ->         critical (3)
> > > >=20
> > > > Notes
> > > > -----
> > > > alarmModelState requires that the states be defined from
> > > less severe to more severe; however, under ITU-T=20
> PerceivedSeverity=20
> > > from ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more=20
> > > severe than "warning".  This change corrects the order to=20
> match the=20
> > > requirement for order of severity for alarmModelState.
> > > >  --VERIFIER NOTES--
> > > > While the discrepancy between the documents is unfortunate,
> > > there is not a technical requirement for the enumeration=20
> values to=20
> > > be identical, nor is there a technical requirement for=20
> the labels to=20
> > > be identical, even though there is obviously considerable=20
> > > documentation value in avoiding gratuitous differences.
> > > >=20
> > > > What *is* technically important is that the MIB be able to
> > > uniquely represent all the cases from M.3100, and it accomplishes=20
> > > that goal.
> > > >=20
> > > > In a future version of the document we can add an
> > > informative note alerting implementors to the discrepancies in=20
> > > numbering and spelling, so their implementations can include=20
> > > appropriate mapping functions to avoid losing information.
> > > >   =20
> > > >=20
> > > > --------------------------------------
> > > > RFC3877 (draft-ietf-disman-alarm-mib-18)
> > > > --------------------------------------
> > > > Title               : Alarm Management Information Base (MIB)
> > > > Publication Date    : September 2004
> > > > Author(s)           : S. Chisholm, D. Romascanu
> > > > Category            : PROPOSED STANDARD
> > > > Source              : Distributed Management
> > > > Area                : Operations and Management
> > > > Stream              : IETF
> > > > Verifying Party     : IESG
> > >=20
> > > --=20
> > > Brian F. G. Bidulock    | The reasonable man adapts=20
> himself to the |
> > > [email protected]    | world; the unreasonable one=20
> persists in  |
> > > http://www.openss7.org/ | trying  to adapt the  world  to=20
> himself. |
> > >                         | Therefore  all  progress =20
> depends on the |
> > >                         | unreasonable man. -- George=20
> Bernard Shaw |
> > >=20
>=20
> --=20
> Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> [email protected]    | world; the unreasonable one persists in  |
> http://www.openss7.org/ | trying  to adapt the  world  to himself. |
>                         | Therefore  all  progress  depends on the |
>                         | unreasonable man. -- George Bernard Shaw |
>=20