Re: [Disman] [Errata Rejected] RFC3877 (1652)

"Brian F. G. Bidulock" <bidulock@openss7.org> Tue, 11 May 2010 14:55 UTC

Return-Path: <bidulock@openss7.org>
X-Original-To: disman@core3.amsl.com
Delivered-To: disman@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1021B28C184 for <disman@core3.amsl.com>; Tue, 11 May 2010 07:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyEYkd3ciHY4 for <disman@core3.amsl.com>; Tue, 11 May 2010 07:55:16 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id CAFB23A6960 for <disman@ietf.org>; Tue, 11 May 2010 07:55:02 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:RJ65J53gzMIQBu/CkcamZpf6DkOoY9fS@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o4BEsR8v012071; Tue, 11 May 2010 08:54:27 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:VU/HVT2w6SleYF57xCZDmudhpgR+xRBw@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o4BEsRTd028209; Tue, 11 May 2010 08:54:27 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o4BEsQth028208; Tue, 11 May 2010 08:54:26 -0600
Date: Tue, 11 May 2010 08:54:26 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Message-ID: <20100511145426.GA28093@openss7.org>
References: <20100511102109.B1C2BE0672@rfc-editor.org> <20100511125110.GA23969@openss7.org> <EDC652A26FB23C4EB6384A4584434A04021BEA8A@307622ANEX5.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04021BEA8A@307622ANEX5.global.avaya.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Mailman-Approved-At: Tue, 11 May 2010 10:20:51 -0700
Cc: Disman <disman@ietf.org>, schishol@nortelnetworks.com
Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/disman>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 14:55:21 -0000

Romascanu,,

Perhaps the errata should add a statement then, that
the order is, and will remain, in error.

--brian

On Tue, 11 May 2010, Romascanu, Dan (Dan) wrote:

>  Brian,
> 
> (the distribution list slightly changes)
> 
> 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 mention the
> differences between the order in the two models - this text would
> include your observation about the order of severity not being the same
> as the one defined in the ITU-T document. 
> 
> Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] 
> > Sent: Tuesday, May 11, 2010 3:51 PM
> > To: RFC Errata System
> > Cc: schishol@nortelnetworks.com; Romascanu, Dan (Dan); iesg@iesg.org
> > Subject: Re: [Errata Rejected] RFC3877 (1652)
> > 
> > Let me try one more time; read my lips:
> > 
> > It is not the enumerated value that need to change.
> > 
> > The document states that the alarm states are ordered from 
> > least severe to most severe, but (without the correction) 
> > they are not.
> > 
> > --brian
> > 
> > On Tue, 11 May 2010, RFC Errata System wrote:
> > 
> > > 
> > > The following errata report has been rejected for RFC3877, "Alarm 
> > > Management Information Base (MIB)".
> > > 
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata_search.php?rfc=3877&eid=1652
> > > 
> > > --------------------------------------
> > > Status: Rejected
> > > Type: Technical
> > > 
> > > Reported by: Brian Bidulock <bidulock@openss7.org> Date Reported: 
> > > 2009-01-13 Rejected by: Dan Romascanu (IESG)
> > > 
> > > Section: 5.4
> > > 
> > > Original Text
> > > -------------
> > > alarmModelState -> ituAlarmPerceivedSeverity
> > >        1        ->         clear (1)
> > >        2        ->         indeterminate (2)
> > >        3        ->         warning (6)
> > >        4        ->         minor (5)
> > >        5        ->         major (4)
> > >        6        ->         critical (3)
> > > 
> > > Corrected Text
> > > --------------
> > > alarmModelState -> ituAlarmPerceivedSeverity
> > >        1        ->         clear (1)
> > >        2        ->         warning (6)
> > >        3        ->         indeterminate (2)
> > >        4        ->         minor (5)
> > >        5        ->         major (4)
> > >        6        ->         critical (3)
> > > 
> > > Notes
> > > -----
> > > alarmModelState requires that the states be defined from 
> > less severe to more severe; however, under ITU-T 
> > PerceivedSeverity from ITU-T Rec. X.721 | ISO/IEC 10165-2 
> > "indeterminate" is more severe than "warning".  This change 
> > corrects the order to match the 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 
> > values to be identical, nor is there a technical requirement 
> > for the labels to be identical, even though there is 
> > obviously considerable documentation value in avoiding 
> > gratuitous differences.
> > > 
> > > What *is* technically important is that the MIB be able to 
> > uniquely represent all the cases from M.3100, and it 
> > accomplishes that goal.
> > > 
> > > In a future version of the document we can add an 
> > informative note alerting implementors to the discrepancies 
> > in numbering and spelling, so their implementations can 
> > include appropriate mapping functions to avoid losing information.
> > >    
> > > 
> > > --------------------------------------
> > > 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
> > 
> > -- 
> > Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> > bidulock@openss7.org    | 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 |
> > 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ 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 ¦