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

From: Ramanathan Kavasseri <[email-masked]>
Date: Sun, 02 Dec 2001 23:48:33 -0800

Randy Presuhn wrote:

> Hi -
>
> > To: [email-masked]
> > Subject: Re: RFC 2981 (disman event MIB) Implementation Experience
> > From: Wes Hardaker <[email-masked]>
> > Date: Tue, 20 Nov 2001 16:26:42 -0800
> > Message-ID: <[email-masked]>
> ...
> > 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).
> ...
>
> 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.
>

IMHO, it would be desirable to add StorageType
objects to the core set of tables Randy mentioned above (mteTriggerTable,
mteObjectsTable and mteEventTable).

Several of my company's customers have voiced strong interest in using these

MIBs to help manage their networks. However, till recently, we didn't
persist the configuration of these MIBs across reboots,
and that has prevented adoption of these MIBs by some of our customers.

Ram

>
>  ------------------------------------------------------
>  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: Ramanathan Kavasseri <[email-masked]>
Date: Fri, 07 Dec 2001 16:09:00 -0800

Here's the Event MIB implementation report from Cisco.

Ram Kavasseri

DISMAN EVENT MIB implementation report

Vendor: Cisco Systems, Inc.
Contact: [email-masked]
Platforms: 
7500, 12000, 7200, ubr7200, 5800, 5200, 5400, 3620
Agent Interoperates with: 
Manager Interoperates with: 

For the following, indicate whether each of the
groups identified in the MODULE-COMPLIANCE statement
is supported.  If the COMDULE-COMPLIACE is problematic,
we'd like to know that, too.

Groups                                  Manager         Agent
dismanEventResourceGroup                n                 y
dismanEventTriggerGroup                 n                 y
dismanEventObjectsGroup                 n                 y
dismanEventEventGroup                   n                 y
dismanEventNotificationObjectGroup      n                 y
dismanEventNotificationGroup            n                 y

For the following, indicate whether the full range of syntax
and MAX-ACCESS is supported, or the subset MIN-ACCESS and
refined syntax.

OBJECT                                  Manager         Agent
mteTriggerTargetTag                     -               full
mteEventSetTargetTag                    full/sub/-      full
mteTriggerValueIDWildcard               full/sub/-      full
mteTriggerContextNameWildcard           full/sub/-      sub
mteObjectsIDWildcard                    full/sub/-      full
mteEventSetContextNameWildcard          full/sub/-      sub