Subject: Re: RFC 2981 (disman event MIB) Implementation Experience

From: Wes Hardaker <[email-masked]>
Date: Thu, 08 Nov 2001 15:03:30 -0800

>>>>> On Wed, 31 Oct 2001 16:38:40 -0800 (PST), Randy Presuhn <[email-masked]> said:

Randy> Our charter says it's time to call for implementation
Randy> experience with RFC 2981, the Event MIB.

Randy et al,

I implemented a good portion of the event mib (but never finished it
entirely) a while back.  I'll try to fill out your implementation
report shortly.

However, it should be noted that on 30 Jan 2001 I posted a note
entitled "event-mib issues/questions" (which you then forwarded to the
list due to my email address not being the one registered with the
list server).  The questions and comments were never responded to and
discussions of the event mib were never brought up in meetings or on
the list again, so I assumed the MIB was "kind of dead".  Granted, I
haven't been able to make the last few disman meetings due to
conflicts, but a discussion about it never appeared on the agenda nor
in the minutes...
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Nov 2001 15:25:03 -0800 (PST)

Hi -

> To: Randy Presuhn <[email-masked]>
> Cc: [email-masked]
> Subject: Re: RFC 2981 (disman event MIB) Implementation Experience
> References: <[email-masked]>
> From: Wes Hardaker <[email-masked]>
> Date: Thu, 08 Nov 2001 15:03:30 -0800
> In-Reply-To: <[email-masked]> (Randy Presuhn's
>  message of "Wed, 31 Oct 2001 16:38:40 -0800 (PST)")
> Message-ID: <[email-masked]>
...
> entirely) a while back.  I'll try to fill out your implementation

Great!

> conflicts, but a discussion about it never appeared on the agenda nor
...

For those who may have missed it, I'm attaching the relevant
portions of that message.

> To: [email-masked]
> Subject: event-mib issues/questions:
> From: Wes Hardaker <[email-masked]>
> Date: 29 Jan 2001 17:47:32 -0800
> Message-ID: <[email-masked]>
...
> Recently, when implementing the event mib, I've run across a few
> questions:
>
> 0) For mteTriggerTargetTag values of '' (ie, the local agent) is the
>    context name for the request to be the context name as defined
>    later using mteTriggerContextName or the contextName of the
>    incoming request:
>
>      In this case, access to the objects indicated by
>      mteTriggerValueID is under the security credentials of the
>      requester that set mteTriggerEntryStatus to 'active'.  Those
>      credentials are the input parameters for isAccessAllowed from the
>      Architecture for Describing SNMP Management Frameworks.
>
>    I would think it should be the value of mteTriggerContextName that
>    is used, but the isAccessAllowed ASI has the contextName listed as
>    an argument, so the above text would lead me to question if I
>    should be pulling the context name from the packet that set the row
>    active instead?
>
> 1) why don't the tables have a StorageType column?  Specifically, I
>    expect to have some rows that won't be writable via network SETs
>    since they'll be derived from other configuration methods.  It
>    would be nice for that information to be retrievable/usable from
>    the protocol standpoint.
>
> 2) The odd combination of mteTriggerEnabled/mteTriggerEntryStatus
>    works, certainly, but seems counter-intuitive compared to other
>    MIBs I've seen.  Why is there a separate column for enabling a row
>    (as opposed to using notInService)?  Why can't a row be put into
>    notInService (the mib states that the only legal value after action
>    is destroy).
>
> 3) if an existence test row is turned from Enabled to Disabled to
>    Enabled, is state supposed to be kept such that previously existing
>    rows are remembered to have been in existence?  (I'd say no, simply
>    because it sort of implies starting over and similarly doing
>    thresholding based on delta values would probably trigger an event
>    when it was re-enabled since the delta is quite possibly going to
>    be large if a large time had elapsed).
>
> 4) mteTriggerThresholdStartup doesn't properly describe the case where
>    new objects come into play after the row has been active for a
>    while.  What if a newly discovered item exists that previously
>    didn't for a running row?  If it is above the rising threshold,
>    does a rising threshold event get triggered?
>
> 4b) If an object is above the threshold and drops below the rising
>     threshold but not below the falling threshold and then winks out
>     of existence for at least one test and finally rises above the
>     rising threshold again, does an event get fired (ie, is state kept
>     for objects winking in/out of existence).
>
> 5) If mteTriggerExistenceStartup is "absent" and
>    mteTriggerValueIDWildcard is "true", does an event get triggered
>    when a row becomes active and no sub-tree matches are found?  (I
>    would think yes, but its unclear).
>
>    (I can't help but chuckle that the statement "Each instance of a
>    wildcard is treated as if it were a separate entry" might mean that
>    I should send out an infinite number of traps at startup for all
>    possible OIDs that I didn't receive values for).
>
> Some of these were thought up when I was lucid without a cold
> affecting my thoughts.  Some weren't (sorry).  Unfortunately, all of
> them were written up when I did have said cold.  (I think I've
> forgotten some other items as well).
...

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Nov 2001 16:30:05 -0800 (PST)

Hi -

...
...

There were rather heated discussions of this issue.  The
document's editor at the time was vehemently opposed to
the use of StorageType, and there were few alternatives.
Juergen Schoenwaelder was one of the participants in that
discussion, and has been recently looking at the questions
surrounding StorageType.

As a technical contributor, I think a StorageType column
would be a reasonable solution to your requirement, and
would also give some control over persistance.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Nov 2001 16:43:21 -0800 (PST)

Hi -

These remaining items from Wes sound like they'll need some
serious thought to fix.  Any concrete proposals?  How have
implementations handled these cases?

...
...

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 20 Nov 2001 16:26:42 -0800

>>>>> On Thu, 8 Nov 2001 16:30:05 -0800 (PST), Randy Presuhn <rpresuhn@dorothy. bmc.com> said:

>> would be nice for that information to be retrievable/usable from

Randy> There were rather heated discussions of this issue.

I have no doubt ;-)

Randy> As a technical contributor, I think a StorageType column would
Randy> be a reasonable solution to your requirement, and would also
Randy> give some control over persistance.

Well, I understand the political arguments I think but the end result
is that without it there is no way to access information about how the
row was created.  In my case, some of the rows have been instantiated
via configuration files and thus can't be deleted (ie, they are
read-only).  Currently without a StorageType column there is no way to
know this from the management side of things (without attempting to
delete it or modify it).
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 20 Nov 2001 17:13:30 -0800 (PST)

Hi -

> Date: Tue, 20 Nov 2001 16:26:42 -0800
> Message-ID: <[email-masked]>
...
...

This might be hair-splitting, but I think that from an
operational perspective it may be even more important to be
able to *configure* whether an entry is supposed to survive
a reboot.  Even if the StorageType is neither permanent nor
readOnly, other factors (e.g. access control) may cause a
deletion request to fail.

So, is the proposal to add StorageType columns to 
mteTriggerTable, mteObjectsTable, and mteEventTable?

Presumably the persistance of mteTriggerDeltaEntry,
mteTriggerExistenceEntry, mteTriggerBooleanEntry,
and mteTriggerThresholdEntry would be controlled
by the corresponding mteTriggerEntry.

The persistance of mteEventNotificationEntry and
mteEventSetEntry would be controlled by the corresponding
mteEventEntry.

Comments, especially from those who have implemented or
used this MIB, would be appreciated.