Re: Alarm Mib
"Romascanu, Dan (Dan)" <[email protected]> Mon, 23 Apr 2012 19:40:16 +0200
| Newsgroups | gmane.ietf.disman |
|---|---|
| Message-ID | <EDC652A26FB23C4EB6384A4584434A04015319B2@307622ANEX5.global.avaya.com> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2178.CD2F0BAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.=20 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.=20 Regards, Dan -----Original Message----- From: Randy Presuhn [mailto:[email protected]] Sent: Mon 4/23/2012 8:35 PM To: Romascanu, Dan (Dan); April Pennisi Cc: [email protected] Subject: Re: [Disman] Alarm Mib =20 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 -----=20 From: "Romascanu, Dan (Dan)" <[email protected]> To: "April Pennisi" <[email protected]> Cc: <[email protected]> Sent: Monday, April 23, 2012 5:46 AM Subject: Re: [Disman] Alarm Mib Hi April, =20 I hope that you do not mind if I am copying the disman WG list.=20 =20 I do not remember why we skipped this value, it may just have been a miss. Maybe Sharon or Randy remember.=20 =20 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 [email protected].=20 =20 Regards, =20 Dan =20 =20 =20 From: April Pennisi [mailto:[email protected]]=20 Sent: Tuesday, April 10, 2012 1:02 AM To: Romascanu, Dan (Dan) Subject: Alarm Mib =20 Hi Dan -=20 =20 I've been working on mapping alarms from a device to appropriate probable causes defined in RFC 3877. =20 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.) =20 From M3100: =20 lossOfRealTime ProbableCause <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D localValue:157 =20 -- A processing error alarm to be issued if the system detects that it has lost the time in=20 -- the real time clock but the clock itself is working. This could happen e.g. during a power=20 -- 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> ::=3D localValue:158 =20 -- A processing error alarm to be issued after the system has reinitialised. This will indicate=20 -- to the management systems that the view they have of the managed system may no longer=20 -- be valid. Usage example: The managed=20 -- 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> ::=3D localValue:159 =20 configurationOrCustomisationError ProbableCause <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D localValue:160 =20 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), =20 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)? =20 I don't know if there are ways to update these things... =20 Thx! =20 =20 =20 ------_=_NextPart_001_01CD2178.CD2F0BAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7655.11"> <TITLE>RE: [Disman] Alarm Mib</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>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.<BR> <BR> 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.<BR> <BR> Regards,<BR> <BR> Dan<BR> <BR> <BR> <BR> -----Original Message-----<BR> From: Randy Presuhn [<A = HREF=3D"mailto:[email protected]">mailto:randy_presuhn@mindspr= ing.com</A>]<BR> Sent: Mon 4/23/2012 8:35 PM<BR> To: Romascanu, Dan (Dan); April Pennisi<BR> Cc: [email protected]<BR> Subject: Re: [Disman] Alarm Mib<BR> <BR> Hi -<BR> <BR> The omission was the subject of a proposed eratum reported July 29, = 2009.<BR> Section 5.2 of RFC 3877 notwithstanding, the view that prevailed at the = time was:<BR> "Technically the submitter is right. However, the change = cannot be made<BR> the way suggested in the Errata, but only by = deprecating the object and<BR> defining a new object with correct enumerated values. = This can be done<BR> only in a future version of the MIB module."<BR> <BR> This eventually concluded with a recommendation of "hold for = document update."<BR> <BR> It looks like we, as a WG, may have blown it on this one. There = are really<BR> two problems itentified in the original report: the missing enumeration = value,<BR> and the wrong explanatory text. Both need to be fixed, and the = IANA mechanism<BR> seems appropriate.<BR> <BR> Randy<BR> <BR> ----- Original Message -----<BR> From: "Romascanu, Dan (Dan)" <[email protected]><BR> To: "April Pennisi" <[email protected]><BR> Cc: <[email protected]><BR> Sent: Monday, April 23, 2012 5:46 AM<BR> Subject: Re: [Disman] Alarm Mib<BR> <BR> <BR> Hi April,<BR> <BR> <BR> <BR> I hope that you do not mind if I am copying the disman WG list.<BR> <BR> <BR> <BR> I do not remember why we skipped this value, it may just have been a<BR> miss. Maybe Sharon or Randy remember.<BR> <BR> <BR> <BR> In any case, according to section 5.2 in RFC 3877 this may be fixed<BR> rather easily by requesting to add one new enumerated value in the = IANA<BR> maintained TC at <A = HREF=3D"http://www.iana.org/assignments/ianaitualarmtc-mib">http://www.ia= na.org/assignments/ianaitualarmtc-mib</A> by<BR> sending a mail to [email protected].<BR> <BR> <BR> <BR> Regards,<BR> <BR> <BR> <BR> Dan<BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> From: April Pennisi [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]= m</A>]<BR> Sent: Tuesday, April 10, 2012 1:02 AM<BR> To: Romascanu, Dan (Dan)<BR> Subject: Alarm Mib<BR> <BR> <BR> <BR> Hi Dan -<BR> <BR> <BR> <BR> I've been working on mapping alarms from a device to appropriate<BR> probable causes defined in RFC 3877.<BR> <BR> <BR> <BR> I notice there is one from M3100 missing from the list<BR> IANAItuProbableCause in the Alarm MIB. Reinitialized is = missing. (It<BR> occurred to me because I'd like to use it.)<BR> <BR> <BR> <BR> From M3100:<BR> <BR> <BR> <BR> lossOfRealTime ProbableCause<BR> <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-= AS<BR> N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D<BR> localValue:157<BR> <BR> -- A processing error alarm to be issued if the system detects that = it<BR> has lost the time in<BR> -- the real time clock but the clock itself is working. This = could<BR> happen e.g. during a power<BR> -- cut in a small NE which does not have battery backup for the real<BR> time clock.<BR> reinitialized ProbableCause<BR> <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-= AS<BR> N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D<BR> localValue:158<BR> <BR> -- A processing error alarm to be issued after the system has<BR> reinitialised. This will indicate<BR> -- to the management systems that the view they have of the managed<BR> system may no longer<BR> -- be valid. Usage example: The managed<BR> -- system issues this alarm after a reinitialization with severity<BR> warning to inform the<BR> -- management system about the event. No clearing notification will = be<BR> sent.<BR> applicationSubsystemFailure ProbableCause<BR> <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-= AS<BR> N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D<BR> localValue:159<BR> <BR> configurationOrCustomisationError ProbableCause<BR> <http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-= AS<BR> N1Module.html#Attribute-ASN1Module.ProbableCause> ::=3D = localValue:160<BR> <BR> From the Alarm MIB:<BR> = lossOfRealTimel (157),<BR> --A processing error alarm to be issued after the system has<BR> --reinitialised. This will indicate<BR> --to the management systems that the view they have of the = managed<BR> --system may no longer<BR> --be valid. Usage example: The managed<BR> --system issues this alarm after a reinitialization with = severity<BR> --warning to inform the<BR> --management system about the event. No clearing = notification will<BR> --be sent.<BR> = applicationSubsystemFailure (158),<BR> = configurationOrCustomisationError (159),<BR> <BR> <BR> <BR> How can I add it? I would think we cannot now insert it, but = instead<BR> add to the end of this list?<BR> <BR> As reinitialized (616)?<BR> <BR> <BR> <BR> I don't know if there are ways to update these things...<BR> <BR> <BR> <BR> Thx!<BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CD2178.CD2F0BAC--