Subject: RE: Examples and Potential Delta for Alarm & ITU Alarm MIBs

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 9 Mar 2001 10:04:46 -0500

hi

Juergen> I am confused.

Juergen> The alarmDetailsTable is used in
<draft-ietf-disman-alarm-mib-01.txt>
Juergen> as "a table of information about possible alarms on the system."
Now
Juergen> you want to have an alarmDetailsState in there, which is in my view
an
Juergen> attribute of a concrete instance of an alarm. Or do you propose to
Juergen> have entries for all possible states just in case you need to point
to
Juergen> such an entry? In fact, I believe the name "alarmDetailsTable" is a
Juergen> confusing name in <draft-ietf-disman-alarm-mib-01.txt>. (But
perhaps I
Juergen> am just mis-understanding the document?)

The alarmDetailTable is potential alarms and the idea is to list all the
states that are applicable to that alarm.  If you consider alarms
as entities having state, previously we had been listing the arrows
which transition between the states, where now we are discussing
the nodes/states.  

Would alarmDefinitionTable be a better name?  

(I have been giving thought to whether probably
cause should be part of the concrete instance information, though)

Juergen> What precisely is the relationship between the alarmDetailsTable
and
Juergen> the alarmActiveTable table? 

alarmDetailsTable defines possible alarms.  alarmActiveTable identifies
those alarms which are currently active/raised.  This supports 1:0, 1:1,
1:N.
The alarmActiveTable has a pointer back to its appropriate alarmDetailsEntry

Juergen> And why do both tables have an
Juergen> alarmActiveModelPointer? Can they be different? 

There are currently two ModelPointers.  One is alarmDetailsModelPointer
which points to further information about potential alarms.  The
other is alarmActiveDetailsModelPointer which points to further
information about specific alarm instances.

Juergen> And if the ituAlarm*
Juergen> objects are so useful for all the examples, why do we not put them
Juergen> into the alarm MIB tables right away? There are already "don't
care"
Juergen> defaults (zeroDotZero) and we can always use the compliance
statements
Juergen> to indicate the subset of objects that are required for compliance.

Well, this is still an open issue, so we might well
end up doing it that way.  But, although my favourite alarm example,
acmeWidgetTemperature*, can map into the ITU model, it does not mean the
model works for everybody and every alarm system.

Juergen> I think it would be really helpful to draw UML diagrams for the
Juergen> various proposals in order to compare them. I tried to do so (since
we
Juergen> have tools to semi-automatically generate UML diagrams from MIBs)
but
Juergen> I was not able to cleanup things as I am obviously lacking some
Juergen> understanding how things are supposed to work together.

Juergen> If you can't do a diagram, can you perhaps expand the examples so
that
Juergen> they show the instance identifiers for the variables? Can you add
all
Juergen> the additional details that are needed to represent a concrete
Juergen> instance of an active alarm? This might help me to get the big
picture
Juergen> which I am obviously missing.

I was worried that expanding the examples to include the alarm instance,
alarmActiveTable, it would become to big.  We can certainly expand
the examples if you think it would help.

Sharon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2001 16:41:17 +0100

>>>>> Sharon Chisholm writes:

Sharon> The alarmDetailTable is potential alarms and the idea is to
Sharon> list all the states that are applicable to that alarm.  If you
Sharon> consider alarms as entities having state, previously we had
Sharon> been listing the arrows which transition between the states,
Sharon> where now we are discussing the nodes/states.

Sharon> Would alarmDefinitionTable be a better name?

Well, the model still does not match what I have in mind. I do not
think that the alarmDetailTable defines an alarm. It defines a
predefined alarm type and state. The actual alarm is listed in the
active alarm table which points to the currently applicable predefined
alarm tyep and state, right? Having predefined alarm types may be
OK. Mixing them together with a state attribute however concerns me.

Are we really gaining much by having predefined alarm states and
having pointers back to that table for the active alarms? Why is the
state not just an attribute of the active alarm? What happens if I
have a sub-agent which wants to report an alarm? How does the subagent
find the right entry in the alarmDetailTable? Or is it just throwing
in its own one ignoring what is there (which means that the argument
of saving space would not really hold anymore)?

Given this, the name should probably be alarmTypeTable and all state
attributes removed...

Sharon> alarmDetailsTable defines possible alarms.  alarmActiveTable
Sharon> identifies those alarms which are currently active/raised.
Sharon> This supports 1:0, 1:1, 1:N.  The alarmActiveTable has a
Sharon> pointer back to its appropriate alarmDetailsEntry

OK, I got that.

Juergen> And why do both tables have an alarmActiveModelPointer? Can
Juergen> they be different?

Sharon> There are currently two ModelPointers.  One is
Sharon> alarmDetailsModelPointer which points to further information
Sharon> about potential alarms.  The other is
Sharon> alarmActiveDetailsModelPointer which points to further
Sharon> information about specific alarm instances.

Thanks, I now see the difference.

Juergen> And if the ituAlarm* objects are so useful for all the
Juergen> examples, why do we not put them into the alarm MIB tables
Juergen> right away? There are already "don't
Sharon> care"
Juergen> defaults (zeroDotZero) and we can always use the compliance
Sharon> statements
Juergen> to indicate the subset of objects that are required for
Juergen> compliance.

Sharon> Well, this is still an open issue, so we might well end up
Sharon> doing it that way.  But, although my favourite alarm example,
Sharon> acmeWidgetTemperature*, can map into the ITU model, it does
Sharon> not mean the model works for everybody and every alarm system.

But this is not a problem. You can report a NULL value for things that
do not apply and if you are worried about implementation complexity,
then make some attributes not required for conformance. Much easier to
deal with than multiple tables with forward pointers. If you need to
extend the IETF alarm model attributes, then you can augment the alarm
tables with your own proprietary attributes. Can you give a good
reason why this would not work?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>