Re: [Errata Rejected] RFC3877 (1652)

Indeed - the confusion is mine and I apologize.=20

Did the WG reach a recommendation for Errata #1652? I cannot find it in
my archives.

My opinion as a contributor is that we still better reject the errata
but the comment should prompt on the discrepancy between the different
standards, and show that it is not clear from the ITU-T standards the
value 'indeterminate' should be used in ordering relative to the other
levels and in masking.=20

Brian, please submit again your errata - so that we can append the
appropriate comment and resolution.=20

Thanks and Regards,

Dan


> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]=20
> Sent: Tuesday, May 11, 2010 8:41 PM
> To: Romascanu, Dan (Dan); [email protected]
> Cc: Disman; [email protected]
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>=20
> Hi -
>=20
> The "verifier notes" look strangely familiar to me.  My=20
> recollection is that they were written in response to a=20
> DIFFERENT erratum, namely number 1819, NOT number 1652, and=20
> thus do not address Brian's comment.  Did the "verifier=20
> notes" for *this* erratum get lost somewhere along the way?
>=20
> Randy
>=20
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email protected]>
> To: <[email protected]>
> Cc: "Disman" <[email protected]>; <[email protected]>
> Sent: Tuesday, May 11, 2010 6:01 AM
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>=20
>=20
> Brian,
>=20
> (the distribution list slightly changes)
>=20
> I think that we understand this. What you proposed is a change in the
> mapping, which would not be backwards compatible with the current
> deployment. What is suggested is that the text is changed to=20
> mention the
> differences between the order in the two models - this text would
> include your observation about the order of severity not=20
> being the same
> as the one defined in the ITU-T document.=20
>=20
> Regards,
>=20
> Dan
>=20
>=20
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]=20
> > Sent: Tuesday, May 11, 2010 3:51 PM
> > To: RFC Errata System
> > Cc: [email protected]; Romascanu, Dan (Dan); [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=20
> > least severe to most severe, but (without the correction)=20
> > 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 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 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=20
> > less severe to more severe; however, under ITU-T=20
> > PerceivedSeverity from ITU-T Rec. X.721 | ISO/IEC 10165-2=20
> > "indeterminate" is more severe than "warning".  This change=20
> > corrects the order to match the requirement for order of=20
> > severity for alarmModelState.
> > >  --VERIFIER NOTES--
> > > While the discrepancy between the documents is unfortunate,=20
> > there is not a technical requirement for the enumeration=20
> > values to be identical, nor is there a technical requirement=20
> > for the labels to be identical, even though there is=20
> > obviously considerable documentation value in avoiding=20
> > gratuitous differences.
> > >=20
> > > What *is* technically important is that the MIB be able to=20
> > uniquely represent all the cases from M.3100, and it=20
> > accomplishes that goal.
> > >=20
> > > In a future version of the document we can add an=20
> > informative note alerting implementors to the discrepancies=20
> > in numbering and spelling, so their implementations can=20
> > include 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 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
>=20