Subject: Updated ITU Alarm IANA Textual Convention

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 27 Jul 2001 08:43:19 -0400

hi

As promised, here is the updated ITU Alarm textual convention.
The values of probable cause have been updated to include
M.3100 as well as X.733 and X.736.

ITU-ALARM-TC DEFINITIONS ::= BEGIN    

IANAItuProbableCause ::= TEXTUAL-CONVENTION   
     STATUS current
     DESCRIPTION
             "ITU probable cause values for the alarms as per M.3100,
             X.733 and X.736."    
     SYNTAX         INTEGER
             {              
              aIS  (1), 
              callSetUpFailure  (2),
              degradedSignal  (3),
              farEndReceiverFailure  (4),
              framingError  (5),
              lossOfFrame (6),
              lossOfPointer  (7),
              lossOfSignal  (8),
              payloadTypeMismatch (9),
              transmissionError (10),
              remoteAlarmInterface (11),
              excessiveBER  (12),
              pathTraceMismatch  (13),
              unavailable  (14),
              signalLabelMismatch (15),
              lossOfMultiFrame (16),
-- Values 17-50 are reserved for communications alarm related probable
causes
-- The following are used with equipment alarm.
              backplaneFailure (51),
              dataSetProblem  (52),
              equipmentIdentifierDuplication  (53),
              externalIFDeviceProblem  (54),
              lineCardProblem (55),
              multiplexerProblem  (56),
              nEIdentifierDuplication  (57),
              powerProblem  (58),
              processorProblem  (59),
              protectionPathFailure  (60),
              receiverFailure  (61),
              replaceableUnitMissing  (62),
              replaceableUnitTypeMismatch (63),
              synchronizationSourceMismatch  (64),
              terminalProblem   (65),
              timingProblem   (66),
              transmitterFailure  (67),
              trunkCardProblem  (68),
              replaceableUnitProblem  (69),
-- Values 70-100 are reserved for equipment alarm related probable causes

-- The following are used with environmental alarm.
              airCompressorFailure  (101),
              airConditioningFailure  (102),
              airDryerFailure   (103),
              batteryDischarging  (104),
              batteryFailure   (105),
              commercialPowerFailure  (106),
              coolingFanFailure  (107),
              engineFailure  (108),
              fireDetectorFailure  (109),
              fuseFailure  (110),
              generatorFailure  (111),
              lowBatteryThreshold (112),
              pumpFailure  (113),
              rectifierFailure  (114),
              rectifierHighVoltage  (115),
              rectifierLowFVoltage  (116),
              ventilationsSystemFailure  (117),
              enclosureDoorOpen  (118),
              explosiveGas  (119),
              fire (120),
              flood   (121),
              highHumidity  (122),
              highTemperature  (123),
              highWind  (124),
              iceBuildUp  (125),
              intrusionDetection  (126),
              lowFuel  (127),
              lowHumidity  (128),
              lowCablePressure  (129),
              lowTemperatue  (130),
              lowWater  (131),
              smoke  (132),
              toxicGas  (133),
-- Values 134-150 are reserved for environmental alarm related probable
causes

-- The following are used with Processing error alarm.
              storageCapacityProblem (151),
              memoryMismatch  (152),
              corruptData  (153),
              outOfCPUCycles   (154),
              sfwrEnvironmentProblem  (155),
              sfwrDownloadFailure  (156),

	        other (255),              
              adapterError (256),
              applicationSubsystemFailure (257),
              bandwidthReduced (258),
              callEstablishmentError (259),
              communicationsProtocolError (260),
              communicationsSubsystemFailure (261),
              configurationOrCustomizationError (262),
              congestion (263),
              cpuCyclesLimitExceeded (264),
              dataSetOrModemError (265),
              dteDceInterfaceError (266),
              equipmentMalfunction (267),
              excessiveVibration (268),
              fileError (269),
              fireDetected (270),
              floodDetected (271),
              heatingVentCoolingSystemProblem (272),
              humidityUnacceptable (273),
              inputOutputDeviceError (274),
              inputDeviceError (275),
              lanError (276),
              leakDetected (277),
              localNodeTransmissionError (278),
              materialSupplyExhausted (279),
              outOfMemory (280),
              ouputDeviceError (281),
              performanceDegraded (282),
              pressureUnacceptable (283),
              queueSizeExceeded (284),
              receiveFailure (285),
              remoteNodeTransmissionError (286),
              resourceAtOrNearingCapacity (287),
              responseTimeExecessive (288),
              retransmissionRateExcessive (289),
              softwareError (290),
              softwareProgramAbnormallyTerminated (291),
              softwareProgramError (292),
              temperatureUnacceptable (293),
              thresholdCrossed (294),
              toxicLeakDetected (295),
              transmitFailure (296),
              underlyingResourceUnavailable (297),
              versionMismatch (298),
              authenticationFailure (299),
              breachOfConfidentiality (300),
              cableTamper (301),
              delayedInformation (302),
              denialOfService (303),
              duplicateInformation (304),
              informationMissing (305),
              informationModificationDetected (306),
              informationOutOfSequence (307),
              keyExpired (308),
              nonRepudiationFailure (309),
              outOfHoursActivity (310),
              outOfService (311),
              proceduralError (312),
              unauthorizedAccessAttempt (313),
              unexpectedInformation (314)
              } 

IANAItuEventType ::= TEXTUAL-CONVENTION   
     STATUS current
     DESCRIPTION
             "The ITU event Type values as per []"    
     SYNTAX         INTEGER
            { 
            other (1),  
            communicationsAlarm (2),
            qualityOfServiceAlarm (3),
            processingErrorAlarm (4),
            equipmentAlarm (5),
            environmentalAlarm (6),
            integrityViolation (7),
            operationalViolation (8),
            physicalViolation (9),
            securityServiceOrMechanismViolation (10),
            timeDomainViolation (11)
            } 	

END

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 27 Jul 2001 12:49:25 -0400

hi

Well, with the given architecture, you could easily use the
ALARM-MIB with a TELCORDIA-ALARM-MIB of your own invention.

We have gone with ITU as the initial model offering due to
its widespread deployment and demand. We have not heard
much demand in the discussions for the Telcordia model.

To turn the question around, do you have data that says we 
should be looking at using the Telcordia model?

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Friday, July 27, 2001 12:38 PM
To: Chisholm, Sharon [CAR:5K85:EXCH]; [email-masked]'
Subject: Re: Updated ITU Alarm IANA Textual Convention

HI,

Can someone provide data to make me feel comfortable about using ITU
instead of Telcordia models? In the customers interactions where I've
participated, ITU is not an issue. Telcordia and their applications
are.

Regards,
/david t. perkins

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 27 Jul 2001 14:56:53 -0400

hi

My personal experience is that there has
been more interest in the ITU model.  Aside from 
the deployed systems using ITU concepts in data networks,
there seems to be plenty of industry interest, in both the ITU
and the IETF, for bringing some of these modelling concepts
to the world of SNMP.

There has been some interest in the Telcordia model, 
just not as much.  I have no objection to doing a
Telcordia model, but I think it makes sense to
finish off the ITU model first, since we are almost
done.

I personally have not been OSMINEd, although I believe
other parts of the organization have been. 

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Friday, July 27, 2001 1:07 PM
To: Chisholm, Sharon [CAR:5K85:EXCH]; [email-masked]'
Subject: RE: Updated ITU Alarm IANA Textual Convention

HI,

Sharon - the data is participation in interactions with potential
customers. They want software that works in the Telcordia management
space. Have you been OSMINED yet? Is there any deployment of
ITU-based management for devices that implement SNMP and are
part of data-com networks? I haven't seen data - one way or
the other, but I guess I haven't gone to the appropriate conferences,
read the appropriate magazines, or paid for the appropriate
industry reports. I'm just looking for a reality check here.
My personal experience over the last few months since the last
IETF have had a big impact on my outlook.

Regards,
/david t. perkins

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 27 Jul 2001 16:32:39 -0500

> From: Sharon Chisholm [mailto:[email-masked]] 

> ALARM-MIB with a TELCORDIA-ALARM-MIB of your own invention.

	"Do it my way or write your own" is a poor attitude for any
standards work.  Besides, we've *already* got a model like that: no
document, no imlementation details, supported in every agent - just add your
own alarm MIB!

	If someone could provide Telcordia documentation, I'd like to take a
look.

	There are also a host of proprietary alarm, alert and event models.

	So far we have not even attempted to define a model that could
support the majority of such implementations.  We owe it to the user
community to at least try.

/|/|ike

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 29 Jul 2001 19:56:30 +0200

Mike,

Please let us avoid making attitude judgments! I do not think that Sharon
intended to say 'do it my way or...'. I think that she is pointing to the
fact that the Alarm MIB model proposed in our draft allows for modular
extensibility to other alarms model, including Telecordia. 

So, can anybody provide this Telecordia documentation? Is it freely
available, and devoid of IP (Intellectual Property!) constraints? I would
also like to have a look at it. Maybe somebody from Telecordia is willing to
support our WG effort?

Regards,

Dan

> From: Ayers, Mike [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 11:33 PM
> To: [email-masked]'

---

From: "Ayers, Mike" <[email-masked]>
Date: Mon, 30 Jul 2001 13:28:43 -0500

> From: Dan Romascanu [mailto:[email-masked]] 

> Please let us avoid making attitude judgments! I do not think 
> that Sharon intended to say 'do it my way or...'. I think 
> that she is pointing to the fact that the Alarm MIB model 
> proposed in our draft allows for modular extensibility to 
> other alarms model, including Telecordia. 

	I had not intended to make such a judgement - rather, I was trying
(unsuccessfully) to point out that what she views as "extensibility", I view
as "lack of support".  When I said, "Do it my way or write your own", I
intended to ascribe that attitude to the draft, not the person - my
apologies for any confusion.  More accurately, I was trying to point out
that implementors reading the draft would read that attitude in the draft,
whether or not it was put in there.  I still believe that this proposed
method for alarm handling will be solidly rejected by the user community for
this simple reason - much implementation work with little to no return.

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 30 Jul 2001 21:16:21 -0400

hi

Dan> Please let us avoid making attitude judgments! I do not think 
Dan> that Sharon intended to say 'do it my way or...'. I think 
Dan> that she is pointing to the fact that the Alarm MIB model 
Dan> proposed in our draft allows for modular extensibility to 
Dan> other alarms model, including Telecordia. 

Mike>	I had not intended to make such a judgement - rather, I was trying
Mike> (unsuccessfully) to point out that what she views as "extensibility",
I view
Mike> as "lack of support".  When I said, "Do it my way or write your own",
I
Mike> intended to ascribe that attitude to the draft, not the person - my
Mike> apologies for any confusion.  More accurately, I was trying to point
out
Mike> that implementors reading the draft would read that attitude in the
draft,
Mike> whether or not it was put in there.  I still believe that this
proposed
Mike> method for alarm handling will be solidly rejected by the user
community for
Mike> this simple reason - much implementation work with little to no
return.

Dan is correct. My original post was trying to demonstrate the flexibility 
of the model.  The core of the alarm model can be implemented regardless of
what alarm model is already in use within your organization. Somewhat ironic

the model got interpreted as "my way or the highway".

I've read quickly through the Telcordia draft, and it seemed quite similar
to 
the ITU model.  Tammy mentioned in another post that they have some common
history.
People who are looking for the features of an alarm model will, I suspect,
find the
functionality they need in either model.  The need for replacing the ITU
Alarm portion
of the alarm solution with a Telcordia model would be specifically for
people who
want *exactly* the Telcordia model. 

Two questions:

1. What features exactly do you feel are not being supported?

2. Can you expand on "much implementation work with little to no return"?
One of the
   design goals of the solution was for a cheap cost of entry with
increasing cost with
   increasing functionality. How do you feel this was not achieved.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 30 Jul 2001 21:21:20 -0400

hi

Dan> So, can anybody provide this Telecordia documentation? Is it freely
available, and devoid of IP (Intellectual 
Dan> Property!) constraints? I would also like to have a look at it. Maybe
somebody from Telecordia is willing to 
Dan> support our WG effort?

I seem to remember from a previous discussion a few months back that the
document has
a copy right preventing distribution, but is available for >$100US.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 31 Jul 2001 14:18:30 -0500

> the model got interpreted as "my way or the highway".

	Hardly.  Consider:  potential implementors, if they wish to use this
MIB, will have a three-way choice.  One:  hammer their proposed or existing
implementation into the ITU model.  Two:  write a MIB which contains their
model and plugs into the Alarm MIB, then write the NMS support for it.
Three:  use a proprietary solution.

	I assert that option two is a semi-proprietary option, the worst of
both worlds.  Not only is their a need to maintain a complete MIB on both
the NMS and the managed devices, but there is exposure to changes in the
base code on both ends.  This isn't really an option, which leaves only
options one and three, "my way" and "highway".

	My fears are born of experience.  A former employer of mine chose to
leverage a "standard" alarm management model (from a well known NMS) for
deployment support of their featured product.  Within a short time, that
support product represented nearly half the engineering staff and the
majority of firedrills.  The problems weren't all due to the leveraged
architecture, but a great many of them were.

> 1. What features exactly do you feel are not being supported?

	Alarm models other than ITU, for starters - at least not in any
practical sense.

>    increasing functionality. How do you feel this was not achieved.

	An alarm model which requires modification of the management system
in order to support any variation from ITU functionality is not cheap by any
measure - unless either (1) you're already using the ITU model or (2) even
your friends call you "Mr. Gates".

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 31 Jul 2001 16:44:48 -0400

hi

Mike>	Hardly.  Consider:  potential implementers, if they wish to use this
Mike> MIB, will have a three-way choice.  One:  hammer their proposed or
existing
Mike> implementation into the ITU model.  Two:  write a MIB which contains
their
Mike> model and plugs into the Alarm MIB, then write the NMS support for it.
Mike> Three:  use a proprietary solution.

You forgot option zero, which I suspect will be quite common, which is to
simply
implement the ALARM-MIB without a supplemental model.

Mike>	My fears are born of experience.  A former employer of mine chose to
Mike> leverage a "standard" alarm management model (from a well known NMS)
for
Mike> deployment support of their featured product.  Within a short time,
that
Mike> support product represented nearly half the engineering staff and the
Mike> majority of firedrills.  The problems weren't all due to the leveraged
Mike> architecture, but a great many of them were.

Is this a vote for not using any existing alarm models and making up our
own?
We had discussed this earlier and opted to leverage work the ITU had done
instead.
I still think this decision makes sense.

One option of course would be to lose the ITU prefix on all the objects
within the
ITU MIB and append any values from other models to things like severity and
probable
cause.  This has a certain best of both worlds quality to it, but I suspect
that
merging the alarm models in this manner may be less trivial then it
originally seems.
It is more straightforward to just support the ITU parameters.

Sharon> Two questions:
Sharon> 
Sharon> 1. What features exactly do you feel are not being supported?

Mike>	Alarm models other than ITU, for starters - at least not in any
Mike> practical sense.

What alarm models were you thinking of?  It might be worth noting that
most alarm models can be mapped into both the ALARM-MIB and the
ITU-ALARM-MIB.

Sharon> 2. Can you expand on "much implementation work with little to 
Sharon> no return"?
Sharon> One of the
Sharon>    design goals of the solution was for a cheap cost of entry with
Sharon> increasing cost with
Sharon>    increasing functionality. How do you feel this was not achieved.

Mike>	An alarm model which requires modification of the management system
Mike> in order to support any variation from ITU functionality is not cheap
by any
Mike> measure - unless either (1) you're already using the ITU model or (2)
even
Mike> your friends call you "Mr. Gates".

Support of ITU-ALARM-MIB is completely optional.  The ALARM-MIB stands on
its own
as a basic alarm management solution.  In fact, I think the alarmActiveTable
stands
on its own as the bare bones alarm management solution.  The ITU-ALARM-MIB
simply
adds additional information and modelling for implementations which require
it.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 31 Jul 2001 16:39:59 -0500

> adds additional information and modelling for implementations 

	Those "bare bones" belong in an oblong box.  Lacking even a severity
indicator, which means that "excessive idle time detected on processor X"
and "unauthorized entry detected in password database" are equally important
issues, this method does not seem very viable.

	For more details, please see the thread "Notifications != alarms"
from last fall, in which I gave a trivial example of an alarm set which
cannot be supported by your proposal.

	In the meantime, I'm going to give some thought to clarifying my
vision to the group.  I believe that I am not getting my points across very
well.

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 31 Jul 2001 20:34:22 -0400

hi

Mike>	Those "bare bones" belong in an oblong box.  Lacking even a severity
Mike> indicator, which means that "excessive idle time detected on processor
X"
Mike> and "unauthorized entry detected in password database" are equally
important
Mike> issues, this method does not seem very viable.

There is severity in the ALARM-MIB, it just isn't called severity.  It is
called
alarmModelState

   alarmModelState OBJECT-TYPE
      SYNTAX  Integer32 ( 1..4294967295 )
      MAX-ACCESS	read-write
      STATUS       current
      DESCRIPTION
           "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."
       ::= { alarmModelEntry 2 } 

It is meant to be more flexible than severity.

Of course, I said bare bones was just the alarmActiveTable which, I guess
would not give you severity, which may have been what you were referring to.
I just want to make sure we don't confuse people.  The conformance to the
ALARM-MIB
also includes alarmModelTable though, so it does go beyond bare bones.
The bare bones method does not give anywhere near a complete solution, but
it
is the part that I can't really get today.  The rest of the solution we can
already
do today "manually" in the management station.

Mike>	For more details, please see the thread "Notifications != alarms"
Mike> from last fall, in which I gave a trivial example of an alarm set
which
Mike> cannot be supported by your proposal.

The temperature one?  I thought we covered that one. We actually use that as
the
example in the draft.  Was your scenario different than the one in the ID?

Sharon