Subject: Re: review of draft-ietf-disman-event-mib-05.txt

From: Bob Stewart <[email-masked]>
Date: Tue, 01 Dec 1998 10:53:54 -0500

At 10:58 AM 11/16/98 -0500, Mike Daniele wrote:
>>>Well, a guy from Twente also got confused why there is a "link" to the
>>>trigger object table in both the trigger and the event table. It would
>>>probably help to explain the purpose of this construction somewhere.
>
>Some text on how to place the objects in the pdu would certainly help.

I'll see if I can find a good place to say where to stick them.  :-)}

I figure what I'll say is put them in following the objects from the
notification's own definition.

>1) There is an implied state for each trigger. once a threshold has been  
>   reached, events aren't generated until the value falls below the other
>   threshold.
>
>   Why not make this state visible?  It seems like it would be useful to be
>   able to view the trigger's current state (for example, "set" vs "reset"), 
>   and the agent has to implement state per trigger anyway.

Hmmm.  That sounds sort of interesting, but I'm resistant to adding objects
just because they sound interesting.  The mechanism is just like RMON and
as far as I know they haven't felt the need for such a state.

>2) It appears to be necessary to implement some amount of the expression mib
>   in order to implement common comparisons.  Using the event mib alone,
>   one could create these triggers:
>
>	o value of object instance is not 0
>	o value of object instance is >= rising threshold
>	o value of object instance is <= falling threshold

True.

>   There is no way to indicate delta evaluation, or =, >, or <
>   comparisons, except by doing so within the expression mib.

Right.

>   I think it would be helpful to state this in the mib text somewhere.

OK.

>   I also think it would be reasonable to extend this mib just a little
>   to permit creating those other types of triggers.  It just seems  like
>   requiring the agent to implement parsing and the expression mib, just to
>   set up a delta threshold, is a little much.

You know not what you ask.  The > and < are supposed to be covered by the
threshold mechanism and I'm concerned that adding them to remove the
distinction of >= and <= would push us to duplication of that.

If I do = someone will no doubt ask for !=.  I'll consider those anyway and
see if I can do them simply enough.

As to delta, that's a major can of worms.  It's easy to say, harder to
express in MIB objects, and a major implementation.  I agree that depending
on the Expression MIB is asking a lot, but rather than duplicate functions
I'd prefer to see if I can trim the Expression MIB.

Hmmmm.  What if the Expression MIB had an option where you didn't have to
accept more than one object in the expression, and could define it as a
delta?  It seems that would work out to the same place, keep the functions
distinct, and allow for a much simplified Expression MIB that's really only
there for deltas and the state they require to keep.

>3) Textual clarifications:

Will fix them.

	Bob

---

From: Bob Stewart <[email-masked]>
Date: Tue, 01 Dec 1998 11:26:51 -0500

At 11:33 AM 11/17/98 +0100, Juergen Schoenwaelder wrote:
>Bob> For remote objects the remote system is picked with a tag that
>Bob> keys into the Management Target information.
 ...
>The problem is that you need to store credentials (keys) in order to
>talk to remote systems and I am not sure we do have a working solution
>for that. The target MIB pushes this problem away by only defining the
>security name, security model and the security level. So you end up
>looking into the usmUserTable. This one indicates that you can have
>entries for engineIDs that are not local. Whether the KeyChange
>mechanism really works in such a setup remains to be demonstrated.

I'm depending on the intent of the v3 work.  If that work is broken it
needs to be fixed.  Circumventing it is not the job of the DisMan working
group.

>I don't see the big value of short module names. I see however the
>costs associated with name clashes and I am convinced that the price
>for a slightly longer but more likely unique module name is a fair
>trade-off wrt the problems such a longer name helps to avoid.

I don't like making names longer with the artifact of the working group
name they came from.   That's too much like deciding how many modules you
have in your architecture by counting the implementation groups that are
going to build it.

>Bob> I don't think we can specify a much better rule that will work in
>Bob> all *agent* environments.  Agents don't have all the information
>Bob> that's in the MIB.  That's why a wildcard flag is needed.  Agents
>Bob> can't tell a broken OID from a short-terminated one.
>
>The current draft does not even say what a broken OID is and what not.
>I mean, you can make a walk even if you don't know the table
>boundaries. The question is how you deal with data types that do not
>apply for the tests. Or you could say that instances returned in the
>getnext sweep have to be the same object type (sure, this requires MIB
>knowledge). I still believe that we have to define what the behaviour
>should be. Leaving this undefined will result in lots of different
>implementations and this will make it a nightmare to write management
>applications.

As far as I'm concerned what happens is whatever falls out.  I really don't
care what form the garbage takes when people don't use wildcard portions
that have matching semantics and I see no reason to burden implementations
with providing the same, predictable garbage (even if they could).

>I am not so sure the MIB does say what is garbage and what not. This
>is what causes my concerns. If you add a clear statement (or point me
>to the statement I have missed) what garbage means in the context of
>wildcarded OIDs, I would be happy.

I'll see if I can make that more clear.  The idea is that the objects that
go together to make up an instance of a wildcarded expression all end up
with the same OID fragment matching for the wildcarded portion.  That's a
simple comparison where you trim of the part that wasn't wildcarded and
compare the rest.  If it matches, you've got a (supposedly) usable instance
of the object.  If that match is purely accidental because of bad choices
for the non-wild part of the OID, then you get garbage results.  I claim
knowing much more than that is somewhere between difficult and impossible
even if you have full information from the MIB definition.

>If it were true that people do not read the conformance statements,
>then why do we define conformance statements at all? Once again,
>putting conformance requirements into the DESCRIPTION makes it very
>hard to express different conformance levels. We should not make this
>mistake and instead use the mechanisms defined in the SMI to express
>conformance requirements.

I'll see what I can do.

>I am concerned that a manager can't figure out what a wildcard
>actually resolves to.

Without knowing everything the agent knows it probably can't.

>Several years ago, people thought that 32 bit numbers are enough.
>Later, they added Counter64 but they could not find a reason why other
>64 bit numbers might be needed. Now we are having endless discussions
>on how to add the remaining 64 bit numbers without breaking too
>much. Sure, the thresholds you can think of now may all be in the
>signed Integer32 range. Whether this is still true with 100 GBit
>networks in a few years remains to be seen.

We'll find out then.  And in the meantime there's the Expression MIB.

	Bob

---

From: Mike Daniele <[email-masked]>
Date: Wed, 02 Dec 1998 15:16:41 -0500

> I'll see if I can find a good place to say where to stick them.  :-)}

Thanks so much! :-)

> notification's own definition.

and that the objects pointed to by mteEventObjects should be added to
the notification's defined objects first, then the objects pointed to by
mteTriggerObjectName, and that all these objects should be added in the order
listed, and even for duplicated objects... right?

or something like that?

> as far as I know they haven't felt the need for such a state.

I would think it very useful to be able to know why a trigger isn't firing
even when thresholds are exceeded, and even to manually reset the trigger
so it will fire next time.   Fwiw,  such an object has been implemented in
Compaq's (then Digital's)  server management MIB.

> distinction of >= and <= would push us to duplication of that.

I see your point.  See below for a different take on < and > outside of
the thresholding definitions.

> see if I can do them simply enough.

Absolutely!  Fwiw, we've had customer feedback that this is a nice
simple way to set triggers on status values (without going thru gyrations of
making rising and falling threshold the same, etc.)

> I'd prefer to see if I can trim the Expression MIB.

Again fwiw, both  pre-merger Digital and Compaq have implemented thresholds
on delta values.  So I don't think it's all that bad.

> there for deltas and the state they require to keep.

Or how about the Event MIB's triggers have an object like this?

mteTriggerEvaluation OBJECT-TYPE
  SYNTAX INTEGER {
               absoluteValue (1),
               deltaValue (2),
               expressionMIB (3)
 }

the first 2 are defined in this mib, the other means that mteTriggerValueID
points into the expression MIB.

Cindy Schlener at Compaq (then Digital) designed a general purpose
thresholding MIB with these objects:

ValueType:  absoluteValue or deltaValue
AlarmType: greaterThan (1),
                     greaterThanOrEqualTo (2),
                     equalTo (3),
                     lessThanOrEqualTo (4),
                     lessThan (5)
ThresholdValue
ResetValue
LastValue: last sampled value
AlarmState: set or reset

The alarm fires when

  for >,  sampled value >ThresholdValue AND state is reset
  for >=, sampled value >= Threshold AND state is reset

  when the alarm fires, state is set and notification may be sent (based on
  other objects).  it will be reset if sampled value falls below (or = for
>=) the
  resetvalue.

  for < and <=, same idea except the reset is done if the sampled value is
  > (or >=) the resetvalue.

  for equalTo,  the alram fires when sampled value == Threshold value
  AND state is reset.  this causes state to be set.  it is reset whenever
  sampled value != resetvalue

If ValueType is deltaValue, you replace "sampled value" everywhere above
with "delta value", where that is calculated by subtracting last value
from sampled value.

You have a threshold and reset event (instead of rising and falling events).

you don't need "startup" objects to control what happens on row creation, since
you
can effect this by the initial value of alarmstate.

All in all it seemed to me like a good general mechanism.  I know
it's a little different than what's in RMON, but hopefully the goal is to
have a good general-purpose event mib, not simply to replicate RMON
functionality.

Something like this would, I believe, provide most if not all
(you know, 80 or 90% :-) of widely used thresholding capabilities
without requiring implementation of any of the Expression MIB.

And it's a reasonably easy implementation.

A final note: Both the Compaq and DEC MIBs mentioned above used
a integer to index the threshold  table, and also contained
a scalar object holding the next available index to help command generator
applications avoid collisions.  Perhaps a TestandIncr object in
the event mib would be a good idea?

Regards,
Mike

---

From: Bob Stewart <[email-masked]>
Date: Wed, 02 Dec 1998 16:55:15 -0500

RMON Alert:  This covers issues where we need some RMON experience
regarding threshold checking.

>listed, and even for duplicated objects... right?

I was going to argue then checked the OBJECTS clause.  Since it specifies
order I will, too.

>Compaq's (then Digital's)  server management MIB.

You can tell by looking at the various object values, so this is
computable.  I'd rather not add more objects now unless there's a really
strong case for them.

>making rising and falling threshold the same, etc.)

I agree that using rising and falling seems a bit complicated for a status
value check.

>points into the expression MIB.

I don't see the point of the expressionMIB enumeration.  The output values
in the Expression MIB are ordinary MIB objects.

>thresholding MIB with these objects:

Your argument is persuasive.  I'm nervous about abandoning the tried and
relatively true RMON model, but if we're going to, this is the time.

I am sympathetic to meeting as many needs as we reasonably can without
having to resort to the Expression MIB.

I seriously need some guidance from some of the RMON oldtimers to see if
we're about to make a mistake they avoided.

HEY!  ANDY!  Are you here?  (I'll CC him explicitly to make sure, and leave
the suggestion following.)

>have a good general-purpose event mib, not simply to replicate RMON

You got the goal right.  The key idea is to learn from RMON experience but
not be chained to its approach.

>the event mib would be a good idea?

I went with names to provide a hook for view-based access control and the
RowStatus mechanism is supposed to take care of collisions.

	Bob

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Dec 1998 23:06:03 -0800

Bob Stewart wrote:
>....

sorry for the delay... IETF week is bad for email.

There are many applications fielded that use the RMON thresholding feature.
I do not want to see this 'design' abandoned for the thresholding
of counters. The rising/falling 're-arm mechanism' is simple and effective.

I would like to see a 'percent-changed' threshold-type added 
e.g.,  { absolute, delta, percent }, since you're updating the 
feature anyway.

Why not add a separate table for equal/not-equal tests?
This type of thresholding needs only one operand instead of two,
and the 're-arm' is implicit (i.e. reverse polarity).

As for a manual re-arm mechanism, you just need to
set the RowStatus to 'notInService' and then back to 'active'.

I can tell from this thread that there is some interest is
adding all kinds of bells and whistles to an otherwise
simple feature, but I think the mechanism described
below is over-engineered (a common IETF malady ;-)

Andy

---

From: [email-masked]
Date: Sun, 13 Dec 1998 19:02:06 -0500 (EST)

>e.g.,  { absolute, delta, percent }, since you're updating the 

Please forgive a simple question from a naive novice:

As long as we are asking about thresholds in the first derivative;
is there at present any capability to express a threshold as a true
or false result of an arbitrary algebraic expression? 

If not, would this be a simple way to support all of the bells and
whistles that one could think of, including correlations, higher
order derivatives, etc., all in a single mechanism?

Mitch Nelson

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Dec 1998 21:51:50 -0800

> As long as we are asking about thresholds in the first derivative;

Jon Saperia suggested the percent threshold-type awhile back.
This is desperately needed for RMON alarms, since it's
quite likely a policy for a threshold will be expressed
in a percentage (e.g., percent of failed call attempts per total call
attempts, per interval; same deal for queue drops, etc.).

> or false result of an arbitrary algebraic expression?

no. the DISMAN Expression MIB could probably be used for this,
but the implementation cost (agent & NMS) is much higher than
for a simple threshold feature. Scripts can be used instead
of MIB objects, of course, with ot without the DISMAN Script/Schedule
MIBs.

> order derivatives, etc., all in a single mechanism?

There are different mechanisms for different environments and
problem complexity.  A 'one-size-fits-all' solution won't
be very easy or effective.

Andy

---

From: "Dr. M. C. Nelson" <[email-masked]>
Date: Thu, 17 Dec 1998 10:35:44 -0500 (EST)

>of MIB objects, of course, with ot without the DISMAN Script/Schedule

Why would it be expensive?  Algebraic parsing of itself, is simple,
quick, compact, and easy to do and the software environment already
knows how to get data by name.  It seems like the cost/benefit would
be quite low, especially compared to the other cost/benefit's already
present in implementing any snmp system.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 1998 09:08:19 -0800

> present in implementing any snmp system.

I'm talking about the relative implementation cost (agent and NMS)
of specific MIBs in various stages of standardization, not the
absolute complexity of algebraic parsing. 

Andy