Subject: Division of Labor - Event vs Expression

From: Bob Stewart <[email-masked]>
Date: Tue, 12 Jan 1999 11:38:28 -0500

I've thought a lot about issues raised with the Event and Expression MIBs
about what functions belong in which one.  This is to say where I'm going
so I can make progress but provide a chance to convince me otherwise if I'm
heading a bad direction.

The idea that a useful Event MIB requires a full-blown Expression MIB is
indeed a problem.  It can't be that way.

On the other hand, the combination of requirements (such as delta samples
for counters and wildcarding) and creeping features (such as checking for
equality or inequality) threatens a large overlap of non-trivial code.

The combination of wildcarding and delta samples in particular is an area
that results in code that is not especially simple.  It has to run
periodically and do samples with a GetNext-based algorithm, clearing
obsolete ones, creating new ones, and updating existing ones.  It's not
horribly difficult, but it's rather harder than the old RMON single,
specific object delta sample.

So my plan is to do what I suggested at the meeting.  I'll keep functions
divided.

The Event MIB will check either a boolean or an RMON-style threshold for a
single object or a wildcard.

The Expression MIB will cover wildcarded deltas and more complex
expressions.  A well-defined subset Expression MIB will support wild-carded
deltas for minimal expressions containing only a single object.  It will be
possible to query the Expression MIB for it's level of functions provided.

Yes, that means the Event MIB will depend on the Expression MIB, but the
sum of the code will avoid duplication while providing the minimum
requirements, and the Expression MIB will remain the proper place to get
really fancy with expressions.

	Bob

---

From: Mike Daniele <[email-masked]>
Date: Wed, 13 Jan 1999 09:21:09 -0500

Bob,

> really fancy with expressions.

I don't understand the code duplication issue.
If an implementation does both "simple" Event MIB stuff and
complex Expression MIB stuff, it can be designed to share code
where it makes sense.

It seems to me that what might end up being a larger issue is that
of requiring most/all implementations to read, understand
the linkage between, and implement (pieces of) 2 different
MIBs in order to provide basic features (like delta evaluation of single
objects)
that are already supported in various standards-track and enterprise MIBs.

It would be helpful to be able to review the (subset) Expression MIB
along with the Event MIB, to understand what an implementation
really will have to do.

Regards,
Mike