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!
- Re: [Disman] Alarm Mib Romascanu, Dan (Dan)
- Re: [Disman] Alarm Mib Randy Presuhn
- Re: [Disman] Alarm Mib Romascanu, Dan (Dan)
- Re: [Disman] Alarm Mib Randy Presuhn