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

"Brian F. G. Bidulock" <bidulock@openss7.org> Wed, 12 May 2010 12:01 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 156C33A690F for <disman@core3.amsl.com>; Wed, 12 May 2010 05:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 aiHTqrrDbJNF for <disman@core3.amsl.com>; Wed, 12 May 2010 05:01:20 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AFF4E3A685B for <disman@ietf.org>; Wed, 12 May 2010 05:01:18 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:Y9TxTqzz8FMG9RawE9KeWmtcDgOE1Bv1@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o4CC15eo001027; Wed, 12 May 2010 06:01:05 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:I70ZuNFVnEdqMyMQkncFx4VWaoeP6AmC@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o4CC15Zs000833; Wed, 12 May 2010 06:01:05 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o4CC159O000832; Wed, 12 May 2010 06:01:05 -0600
Date: Wed, 12 May 2010 06:01:05 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Message-ID: <20100512120105.GA551@openss7.org>
References: <EDC652A26FB23C4EB6384A4584434A04021BEA8A@307622ANEX5.global.avaya.com> <003e01caf131$0fef1a20$6801a8c0@oemcomputer> <20100511234401.GA11848@openss7.org> <003401caf195$6e6f75e0$6801a8c0@oemcomputer> <20100512114530.GA32075@openss7.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20100512114530.GA32075@openss7.org>
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)
Cc: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, 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: Wed, 12 May 2010 12:01:22 -0000

Randy,

I should have also given you the comment from the M.3100 GDMOS:

-- 7.3.13 alarmStatus
-- The semantics of alarmStatus defined in ITU-T Recommendation M.3100
-- are different from alarmStatus defined in ITU-T Recommendation X.721
-- and ITU-T Recommendation X.731.  This difference in semantics is
-- deliberate and reflects the requirement of Telecom Operators to have
-- an aggregated or consolidated alarm status for alarm management.

--brian

On Wed, 12 May 2010, Brian F. G. Bidulock wrote:

> Randy,
> 
> On Tue, 11 May 2010, Randy Presuhn wrote:
> 
> > Hi -
> > 
> > > From: "Brian F. G. Bidulock" <bidulock@openss7.org>
> > > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > > Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>om>; "Disman" <disman@ietf.org>rg>; <schishol@nortelnetworks.com>
> > > Sent: Tuesday, May 11, 2010 4:44 PM
> > > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> > >
> > > Randy,
> > > 
> > > Actually, the severity levels from M.3100 are completely different.
> > > This MIB models the ITU-T Rec. X.721 ISO/EIC 10165-2 severities (OSI
> > > severities, not telco severities).
> > 
> > They're the same thing.  M.3100 IMPORTS PerceivedSeverity from X.721  
> > The tables in M.3100 for handling PerceivedSeverity appear to
> > be consistent with X.721 and X.733  (Which is not surprising,
> > since some of the same people were involved in writing all three.)
> 
> You still don't get it: I am not talking about enumerations of
> perceivedSeverity.  I am talking about the severity levels of
> alarmStatus:
> 
> This from the M.3100 GDMOs: (alarmStatus ATTRIBUTE DEFINED AS)
> 
>     "The Alarm Status attribute type indicates the occurrence of an
>      abnormal condition relating to an object. This attribute may also
>      function as a summary indicator of alarm conditions associated with
>      a specific resource. It is used to indicate the existence of an
>      alarm condition, a pending alarm condition such as threshold
>      situations, or (when used as a summary indicator) the highest
>      severity of active alarm conditions. When used as a summary
>      indicator, the order of severity (from highest to lowest) is:
> 
> 	activeReportable-Critical
> 	activeReportable-Major
> 	activeReportable-Minor
> 	activeReportable-Indeterminate
> 	activeReportable-Warning
> 	activePending
> 	cleared."
> 
> And from the M.3100 ASN:
> 
> AlarmStatus ::= ENUMERATED {
> 	cleared(0),
> 	activeReportable-Indeterminate(1),
> 	activeReportable-Warning(2),
> 	activeReportable-Minor(3),
> 	activeReportable-Major(4),
> 	activeReportable-Critical(5),
> 	activePending(6) }
> 
> Now, just in the MIB:
> 
>     "Entries appear in this table whenever an entry is created
>      in the alarmModelTable with a value of alarmModelState in
>      the range from 1 to 6.  Entries disappear from this table
>      whenever the corresponding entries are deleted from the
>      alarmModelTable, including in cases where those entries
>      have been deleted due to local system action.  The value of
>      alarmModelSpecificPointer has no effect on the creation
>      or deletion of entries in this table.  Values of
>      alarmModelState map to values of ituAlarmPerceivedSeverity
>      as follows:
> 
>        alarmModelState -> ituAlarmPerceivedSeverity
> 	      1        ->         clear (1)
> 	      2        ->         indeterminate (2)
> 	      3        ->         warning (6)
> 	      4        ->         minor (5)
> 	      5        ->         major (4)
> 	      6        ->         critical (3)
> 
>      All other values of alarmModelState MUST NOT appear
>      in this table.
> 
> And alarmModelState
> 
>         "A value of 1 MUST indicate a clear alarm state.
>         The value of this object MUST be less than the
>         alarmModelState of more severe alarm states for
>         this alarm.  The value of this object MUST be more
>         than the alarmModelState of less severe alarm states
>         for this alarm."
> 
> 
> So, the alarm model state values must be ordered in order of severity,
> otherwise, masking occurs.  However, the alarmModelState value
> mapping from perceivedSeverity do no match the M.3100 alarmStatus
> severity levels.  INDETERMINATE AND WARNING ARE REVERSED.  Therefore
> the mapping does not follow the MUST rules for alarmModelState per
> M.3100 alarmStatus which is NOT the same as the X.721 alarmStatus.
> 
> > 
> > > Nevertheless, if one follows the alarm states in the document, a
> > > more severe alarm (indeterminate(2)) will be masked by a less
> > > severe alarm (warning(6)), making it largely unusable for the
> > > purpose for which it was intended.
> > 
> > X.721 specifically comments (page 41) that "indeterminate" is
> > only used when it is not possible to assign one of the other values.
> > The semantics nailed down in X.733, in clause 8.1.2.3, only
> > specify the relative severity of the other values, not for "indeterminate".
> > Likewise, 8.1.2.6, "Trend Indication", also does not include
> > "indeterminate" in the ordering.  Consequently, I do not see how
> > either the current ordering, nor the proposed change, could be
> > supported by citing M.3100 or X.733.
> 
> See M.3100 alarmStatus, per above.  Because the alarmModelState
> rule (MUST) is violated, and alarm of activeReportable-Warning
> will mask more severe alarms of activeReportable-Indeterminate.
> 
> > 
> > > I submitted this errata over a year ago.  In the meantime I have
> > > found this MIB so lacking that I implemented alarms management
> > > completely in private MIBs.
> > > 
> > > So, do what you want with it: it is useless to me.
> > ...
> > 
> > I'm not arguing your point.  I'm just saying that the "verifier notes"
> > that accompanied the rejection appear to belong to a DIFFERENT
> > erratum, and did not address the point of your comments.  I'm
> > AGREEING with you that there is (at least) a documentation problem,
> > in that the mapping does not fit X.721 /  X.733.  M.3100 merely imports
> > the definition from X.721, and does NOT, as far as I can see, do anything
> > to "indeterminate" to justify the proposed change in order.  However, it
> > also makes it clear that the existing order, while perhaps sensible for
> > some application, is not justified by the base standards.
> > 
> > Randy
> 
> 
> Again, read my lips: not perceivedSeverity enumerations, but
> M.3100 alarmStatus to alarmModelState mapping.
> 
> --brian
> 
> -- 
> 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 ¦