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

"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 11 May 2010 17:40 UTC

Return-Path: <randy_presuhn@mindspring.com>
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 9CD2B3A69F7 for <disman@core3.amsl.com>; Tue, 11 May 2010 10:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.503
X-Spam-Level:
X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_20=-0.74]
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 jFvj7-XwBR+f for <disman@core3.amsl.com>; Tue, 11 May 2010 10:40:44 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 4A0A228C195 for <disman@ietf.org>; Tue, 11 May 2010 10:40:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KuJL9RWtV2AWRm+kjV30NKwBAh4YNKcv71jWPkq7Y0/VLc8NN/tU32Bp0AHPSZcx; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.41.49.152] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1OBtRX-0006lg-El; Tue, 11 May 2010 13:40:31 -0400
Message-ID: <003e01caf131$0fef1a20$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, bidulock@openss7.org
References: <20100511102109.B1C2BE0672@rfc-editor.org><20100511125110.GA23969@openss7.org> <EDC652A26FB23C4EB6384A4584434A04021BEA8A@307622ANEX5.global.avaya.com>
Date: Tue, 11 May 2010 10:40:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035312a1c5a7799bae15f48f5bfa13e3bbd350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.41.49.152
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
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 17:40:45 -0000

Hi -

The "verifier notes" look strangely familiar to me.  My recollection
is that they were written in response to a DIFFERENT erratum,
namely number 1819, NOT number 1652, and thus do not address
Brian's comment.  Did the "verifier notes" for *this* erratum get lost
somewhere along the way?

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <bidulock@openss7.org>
Cc: "Disman" <disman@ietf.org>; <schishol@nortelnetworks.com>
Sent: Tuesday, May 11, 2010 6:01 AM
Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)


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 |
>