Subject: RE: Latest Alarm Drafts

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 1 Feb 2001 09:28:44 -0600

Hi.

I have a few questions regarding Alarm MIB.

1. What is the linkage - relationships between Alarm Details Table
and Active Alarm Table / Active Alarm Variable Table. I mean the
relationship
between Active Alarm and Active Alarm Variable is clear - they share 2
indices:
activeAlarmIndex and alarmListName. However, I missed how I relay
the particular active alarm instance to the details table.

2. alarmActiveLastChange.
   The description clause says :

	    "The value of sysUpTime at the time of the last
          creation or deletion of an entry in the alarmActiveTable.
          If the number of entries has been unchanged since the
          last re-initialization of the local network management
          subsystem, then this object contains a zero value."

If I understand correctly it will have non zero value ONLY if number of
entries
has not changed. But, what if number has not changed, but the actual content
of a few entries did. Consider the scenario when equal amount of entries got
deleted and created.

What I am missing here ?

Thanks,
Eugene.

Eugene Golovinsky
BMC Software, Inc.
SNMP Technology Group.

[email-masked]
Voice +(713)-9181816
Mobile +(713)-8598281

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 6:40 AM
> To: [email-masked]
> Subject: Latest Alarm Drafts
>
>
>
> hi
>
> I just sent in the new versions of the Alarm MIBs to
> internet-drafts.
> Copies can be found at
>
> http://members.attcanada.ca/~chiz/draft_ietf_disman_alarm_mib_00.txt
> 	and
>
> http://members.attcanada.ca/~chiz/draft_ietf_disman_itualarm_m
ib_00.txt

Please excuse the _ instead of -.  Web server quirk.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Feb 2001 18:17:02 +0200

[Dan]  Hi,
	 
> the particular active alarm instance to the details table.
	[Dan]  The connection between alarmActiveTable and alarmDetailsTable
is through the alarmActiveDetailsIndex object. alarmActiveTable and
alarmActiveVariableTable share the first two indices.
	  
> of a few entries did. Consider the scenario when equal amount of entries
	[Dan]  Content of entries will change through delete / create rows -
thus the value of alarmActiveLastTime changes.

	Regards,

	Dan

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Feb 2001 19:13:38 +0200

> > > of a few entries did. Consider the scenario when equal
> > amount of entries
> > > got
> > > deleted and created.
> > >
> > > What I am missing here ?
> [Eugene]
> Thanks, but this is not clear from the description, as it refers ONLY
> to the number of entries. The first and the second sentences of the clause
> seem a bit contradictory to me.
	[Dan]  maybe this can be better explained - but actually if you make
a change by deleting a row and then writing a new one, you change twice the
number of entries and the value of alarmActiveLastChange.

	Regards,

	Dan

> Thanks a lot,
> --Eugene

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 1 Feb 2001 11:09:38 -0600

Hi, please see below

> From: Dan Romascanu [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 10:17 AM
> To: 'Golovinsky, Eugene'; 'Sharon Chisholm'; [email-masked]
> Subject: RE: Latest Alarm Drafts
>
>
>
> 	[Dan]  Hi,
>

[Eugene]

Thanks a lot,
--Eugene

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 1 Feb 2001 11:18:45 -0600

Thanks, I did get it from your first explanation. I just suggest to modify
description the way, Dan, you explained it to me to eliminate possible
future confusions like mine.

Best,
--Gene

> Sent: Thursday, February 01, 2001 11:14 AM
> > > > has not changed. But, what if number has not changed,
> but the actual
> > > > content

---

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 21 Feb 2001 16:43:27 -0600

It looks like we still need to do some work in separating alarms and
notifications - much of the original confusing language from the first draft
still exists.  I think that may just be because most of the editorial effort
went into splitting the document (was that really necessary?).

	Specific comments:

ALARM MIB

In many places

	"Alarms management" s/b "alarm management".

Section 3.1, "Terminology"

	"A deviation of a system from normal operation."  Don't we mean a
deviation from intended operation?

	"Something which happens" - May I suggest "An instantaneous
occurence of interest to the management system"?

Section 3.3, "Relation to Notification Log MIB"

	"compliment" s/b "complement"

Section 3.4, "Relation to Model Specific Alarm MIBs"

	For ease of implementation, I think the document should specify
exactly where to place the mirrored rows.  Currently, even though the
details table of the specific MIB is known via alarmDetailsModelPointer,
there is no requirement on where to place the active entry table.  These two
tables should be required to be at fixed subids from a node so that, given
the location of the details table, the location of the active entry table is
immediately known.

Section 4, "MIB Overview"

	More detail is needed on the alarmDetailsTable.  Specifically, the
way alarms appear in the log is still "magic".  If the alarmDetailsTable is
the way to register groups of sniffed notifications to constitue an alarm
behavior, please say so.  If it is merely information for manager
applications reading the alarm MIB, then say that.  Can alarms appear which
are not in the table?  Do notificationless (self-sourced) alarm MIBs have to
populate this table? How do we represent M:N raise/clear relationships?
Must the ITU alarm MIB display ALL of its possible combinations of event
type/probable cause?  Can the entries appear only when a corresponding alarm
is active and not appear otherwise (bandwidth reduction)?  Etc., etc.,
etc....

	There is, here and elsewhere, reference to "raise alarms" and "clear
alarms", but they are never defined.  I suspect that this is actually
referring to notifications which indicate the raising and clearing of a
given alarm, but I am not sure.  Much more clarity is needed.

Section 5, "Definitions"

	In the DESCRIPTION clause of the MODULE-IDENTITY macro, there is a
spurious second "to".

	alarmDetailsType - barring a sensible definition of "raise alarm"
and "clear alarm", this should be removed.

	alarmActiveTime - Should be DateAndTime, not TimeStamp (and all of
its problems).  Also, support of time of day should be required (i.e. MUST).

	alarmActiveContextName - "If the alarm's source SNMP engine is known
not to support multiple contexts, this object is not instantiated."
Wouldn't a zero length string be a better way to handle this case?

	alarmActiveLogIndex - "This number can be considered a sequence
number for the trap."  HUH?  Sequence of what?  I smell arbitrary
justification.  "It should be the same as the log index in the notification
log MIB, if used."  Either use MUST or expunge this sentence.  There is no
benefit to "should" here, since managers will still have to explicitly check
both indices.  If it says "MUST", then blind gets can be done.  If it is not
possible to require the same indices (most likely - what about independent
subagents for notification log MIB and alarm MIB?), then there is no benefit
to suggesting this (or am I missing something?).

	alarmActiveDetailsIndex - "If the alarmDetails table is not
supported this object should have a value of 0."  The alarmDetailsGroup is
listed as mandatory, so this sentence is moot.

	alarmActiveVariableTable - This is still the inefficient data
structure.  It should be the optimized structure, so that the entire MIB can
be slurped efficiently.

ITU ALARM MIB

Section 5, "Definitions"

	ituAlarmCompliance - shouldn't alarmActiveGroup and
alarmDetailsGroup from the Alarm MIB be mandatory here?

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 26 Feb 2001 19:12:06 -0500

hi

Apologies if this gets sent twice, but I got a bounce
message and have not seen it on the list.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:5K32:EXCH]
Sent: Friday, February 23, 2001 11:11 AM
To: 'Ayers, Mike'; [email-masked]
Subject: RE: Latest Alarm Drafts

hi Mike,

> From: Ayers, Mike [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 5:43 PM
> To: Chisholm, Sharon [CAR:5K32:EXCH]; [email-masked]
> <clip>
Aren't there cases where the system is behaving like you intended, but
you still get alarms?  Like, linkDown for example.  I think that's
the problem ARC is trying to address

> occurrence of interest to the management system"?
How about "something that happens which may be of interest to
a management system".

<clip>
> is active and not appear otherwise (bandwidth reduction)?  Etc., etc.,
I'll just second what Dan said about trying to keep the model-neutral
MIB flexible enough to do whatever the various models require.

We support M:1 relationship ship (many raises, 1 clear), but I'll have to go
back and look to see how we stand up to M:N (many raises, many clears)
> given alarm, but I am not sure.  Much more clarity is needed.
How's this?
   Alarm
      Persistent indication of a fault.

   Alarm Raise
      The initial detection of the fault indicated by an alarm. A
Notification
      SHOULD be sent on alarm raise.

   Alarm Clear
      The detection that the fault indicated by an alarm no longer exist.
      A Notification SHOULD be sent on alarm clear.
<clip>
> Wouldn't a zero length string be a better way to handle this case?
Yeah, I'd probably agree.  That was an attempt to be consistent with
the Notification Log MIB.

> to suggesting this (or am I missing something?).
The sequence number is referring to implementations which use actual
sequence numbers in their traps.  Again, not really explained properly.

Changing to the "should" to MUST  makes sense.

> listed as mandatory, so this sentence is moot.
Right, originally the alarmDetailsGroup was not mandatory.  Part of me still
likes the idea of not making it mandatory.  Any thoughts?

> structure.  It should be the optimized structure, so that the entire MIB
can
Love the term :-), but I'm still looking to be consistent with the
Notification
Log MIB.  We have added the TimeFilter object and some statistics to help
you
consume more intelligently.  You had suggested at one point of changing the
order
the type field so offsets could easily calculated.  Are there other
suggestions
for performance improvements?

<clip>

Sharon

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Feb 2001 11:00:32 +0200

> back and look to see how we stand up to M:N (many raises, many clears)
	[Dan] I think that this is already supported.  In alarmDetailsTable
you may have multiple rows with alarmDetailsType clear, different
alarmDetailsClearNotificationId corresponding to the same raise alarm.
> likes the idea of not making it mandatory.  Any thoughts?
	[Dan]  I seem to agree with your other side :-) Without
alrmDetailsGroup, how would one know what is the type (raise/clear) and
relationship?

	Regards,

	Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 27 Feb 2001 09:23:07 -0500

> the location of the details table, the location of the active entry table
is
Or how about a similar pointer in the alarmActiveTable?
alarmActiveModelPointer.
This keeps things flexible, but also tells you where to find the
information.

Sharon