Re: [Disman] Alarm Mib

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 23 April 2012 17:45 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: disman@ietfa.amsl.com
Delivered-To: disman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0916E21F8759 for <disman@ietfa.amsl.com>; Mon, 23 Apr 2012 10:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.516
X-Spam-Level:
X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=-1.510, BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnZYeUqODxWj for <disman@ietfa.amsl.com>; Mon, 23 Apr 2012 10:45:02 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B4CFC21F875A for <disman@ietf.org>; Mon, 23 Apr 2012 10:45:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACSUlU+HCzI1/2dsb2JhbABEsVGBB4IJAQEBAQMSChEDSQwEAgEIDQQEAQELBgwLAQYBRQkIAQEEARIIARmHbQudPJ0vineFdWMEiC+TYYoogmuBWg
X-IronPort-AV: E=Sophos; i="4.75,468,1330923600"; d="scan'208,217"; a="343848765"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Apr 2012 13:44:41 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Apr 2012 13:28:16 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2178.CD2F0BAC"
Date: Mon, 23 Apr 2012 19:40:16 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04015319B2@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Disman] Alarm Mib
Thread-Index: Ac0hdz2z+6yVk8xsRbm7Ohkjeqgq2AAAOeM6
References: <FBE0F7DF3682DF4B9D0176228D9DF5B3B3DEB3AB@gbplmail02.genband.com> <EDC652A26FB23C4EB6384A4584434A04078107E5@307622ANEX5.global.avaya.com> <009c01cd2177$6d2e7b40$6b01a8c0@oemcomputer>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>, "April Pennisi" <april.pennisi@genband.com>
Cc: disman@ietf.org
Subject: Re: [Disman] Alarm Mib
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 23 Apr 2012 17:45:03 -0000

Well, yes, the resolution proposed to the errata was correct if we are to align the values of the enumeration in the TC and M3100 - for this we would need to deprecate the TC and define a new one - same with the object(s) using the TC. 

However, if we just want to add the missing value for reinitialize as April suggests and fix the comment which is obviously wrong I believe that the IANA mechanism would work. 

Regards,

Dan



-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: Mon 4/23/2012 8:35 PM
To: Romascanu, Dan (Dan); April Pennisi
Cc: disman@ietf.org
Subject: Re: [Disman] Alarm Mib
 
Hi -

The omission was the subject of a proposed eratum reported July 29, 2009.
Section 5.2 of RFC 3877 notwithstanding, the view that prevailed at the time was:
  "Technically the submitter is right. However, the change cannot be made
    the way suggested in the Errata, but only by deprecating the object and
    defining a new object with correct enumerated values. This can be done
    only in a future version of the MIB module."

This eventually concluded with a recommendation of "hold for document update."

It looks like we, as a WG, may have blown it on this one.  There are really
two problems itentified in the original report: the missing enumeration value,
and the wrong explanatory text.  Both need to be fixed, and the IANA mechanism
seems appropriate.

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "April Pennisi" <april.pennisi@genband.com>
Cc: <disman@ietf.org>
Sent: Monday, April 23, 2012 5:46 AM
Subject: Re: [Disman] Alarm Mib


Hi April,

 

I hope that you do not mind if I am copying the disman WG list. 

 

I do not remember why we skipped this value, it may just have been a
miss. Maybe Sharon or Randy remember. 

 

In any case, according to section 5.2 in RFC 3877 this may be fixed
rather easily by requesting to add one new enumerated value in the IANA
maintained TC at http://www.iana.org/assignments/ianaitualarmtc-mib by
sending a mail to iana@iana.org. 

 

Regards,

 

Dan

 

 

 

From: April Pennisi [mailto:april.pennisi@genband.com] 
Sent: Tuesday, April 10, 2012 1:02 AM
To: Romascanu, Dan (Dan)
Subject: Alarm Mib

 

Hi Dan - 

 

I've been working on mapping alarms from a device to appropriate
probable causes defined in RFC 3877.

 

I notice there is one from M3100 missing from the list
IANAItuProbableCause in the Alarm MIB.  Reinitialized is missing.  (It
occurred to me because I'd like to use it.)

 

>From M3100:

 

lossOfRealTime ProbableCause
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:157
 
-- A processing error alarm to be issued if the system detects that it
has lost the time in 
-- the real time clock but  the clock itself is working. This could
happen e.g. during a power 
-- cut in a small NE which does not have battery backup for the real
time clock.
reinitialized ProbableCause
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:158
 
-- A processing error alarm to be issued after the system has
reinitialised. This will indicate 
-- to the management systems that the view they have of the managed
system may no longer 
-- be valid. Usage example: The managed 
-- system issues this alarm after a reinitialization with severity
warning to inform the
-- management system about the event. No clearing notification will be
sent.
applicationSubsystemFailure ProbableCause
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:159
 
configurationOrCustomisationError ProbableCause
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::= localValue:160
 
>From the Alarm MIB:
            lossOfRealTimel (157),
 --A processing error alarm to be issued after the system has
 --reinitialised.  This will indicate
 --to the management systems that the view they have of the managed
 --system may no longer
 --be valid.  Usage example: The managed
 --system issues this alarm after a reinitialization with severity
 --warning to inform the
 --management system about the event.  No clearing notification will
 --be sent.
             applicationSubsystemFailure (158),
             configurationOrCustomisationError (159),

 

How can I add it?  I would think we cannot now insert it, but instead
add to the end of this list?

As reinitialized (616)?

 

I don't know if there are ways to update these things...

 

Thx!