Subject: comments on event draft

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Mar 1999 16:53:34 +0100

I am now reading the documents under last call. Here are my comments
on the event MIB draft:

1) The Security section says:

: Security of Event MIB entries depends on SNMPv3 access control for the
: entire MIB or for subsets based on substrings of trigger and event
: names.

Is the "or for subsets based on substrings" still needed? Perhaps you
may want to clone some text from the Security Considerations section
of the Script/Schedule MIBs.

2) The definition of mteResourceSampleMinimum is of SYNTAX Integer32
   (-1 | 1..600). The text gives the value 1 a special meaning and
   does not even mention the value -1. Perhaps -1 should be used in
   the text?

3) The MIB does not use StorageType. (This is more an observation
   since I get more and more afraid of Bob's dog.)

4) Change mteOwner to mteTriggerOwner.

5) The enumeration of mteTriggerDeltaDiscontinuityIDType allows to
   select dateAndTime as a discontinuity indicator type. The
   description of mteTriggerDeltaDiscontinuityID only talks about
   TimeTicks and TimeStamp objects.

6) Add an mteObjectsOwner and use it instead of mteOwner in the
   INDEX clause of mteObjectsEntry.

7) Add mteEventOwner and use it instead of mteOwner in the INDEX
   clause of mteEventEntry, mteEventNotificationEntry,
   mteEventSetEntry.

8) mteHotValue uses SYNTAX Integer32. The description of
   mteTriggerValueID says that "the object at mteTriggerValueID must
   evaluate to an integer, that is, anything that ends up encoded for
   transmission as an integer." I guess you mean an ASN.1 INTEGER.

   Note that this causes problems if mteTriggerValueID points to an
   unsigned type (e.g. Gauge32). A similar argument could be made for
   the thresholds themself, but I can live with the fact that you
   can't set a threshold outside of the Integer32 range. I am however
   concerned that the value of mteTriggerValueID can prevent a
   notification from being emitted at all since mteHotValue is a
   required varbind element.

9) There are notifications for boolean triggers (mteTriggerFired) and
   threshold triggers (mteTriggerRising, mteTriggerFalling). There
   seems to be no notification for existance triggers.

10) Typo in reference 17: "SYSTEMS<"

11) The Security Considerations section refers to the Overview. You
    probably want to refer to the security section instead.

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Rob Frye <[email-masked]>
Date: Tue, 23 Mar 1999 13:46:51 -0500

> I am now reading the documents under last call. Here are my comments
...
>    does not even mention the value -1. Perhaps -1 should be used in

The range on mteResourceSampleMinimum was brought up in the meeting.
Bob Stewart agreed to investigate why that range.

>    clause of mteEventEntry, mteEventNotificationEntry,

Why?  What do these do for us that mteOwner does not?

-- Rob.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Mar 1999 21:33:54 +0100

>>>>> Rob Frye writes:

>> clause of mteEventEntry, mteEventNotificationEntry,

Rob> Why?  What do these do for us that mteOwner does not?

I had the impression that the various *Owner objects have different
scopes and semantics. For example, the cross table "pointers" all use
a *Owner/*Name pair. This suggests to me that the owner of an entry in
the mteEventTable is likely to be different from (and have different
meaning than) the owner of the mteTriggerTable.

I believe that different owners adds clarity since it makes it obvious
that the mteOwner "bar" in the mteTriggerTable may be different from
the mteOwner "bar" in the mteEventTable. The WGs mileage may vary.

							Juergen