Re: [Disman] Alarm Mib

["Romascanu, Dan (Dan)" <[e-mail]>]

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:[e-mail]]
Sent: Mon 4/23/2012 8:35 PM
To: Romascanu, Dan (Dan); April Pennisi
Cc: [e-mail]
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)" <[e-mail]>
To: "April Pennisi" <[e-mail]>
Cc: <[e-mail]>
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 [e-mail]. 

 

Regards,

 

Dan

 

 

 

From: April Pennisi [mailto:[e-mail]] 
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!