Subject: Re: comments on event draft

From: Bob Stewart <[email-masked]>
Date: Fri, 25 Jun 1999 15:43:00 -0400

At 09:33 PM 3/23/99 +0100, Juergen Schoenwaelder wrote:
>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.

I believe the owner indexing concept is a kluge and creates too much
complexity in the wrong place, including the high probability of unintended
"features."  It was my intent that ownership be a relatively simple
concept, and not overly flexible.

	Bob

---

From: Bob Stewart <[email-masked]>
Date: Fri, 25 Jun 1999 15:57:30 -0400

I'm replying to Juergen's message in light of discussion he had with Rob
Frye and Randy.

At 04:53 PM 3/23/99 +0100, Juergen Schoenwaelder wrote:
>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.

Offending, vestigial text removed.

>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?

Modified to be like recently edited, similar DESCRIPTION in Expression MIB.
 The -1 business is gone.  It was a cut & paste artifact.

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

Over my dead body.  WOOF!

I added text like I did in Expression.

>4) Change mteOwner to mteTriggerOwner.

I took no action on this or the related suggestions as I don't believe they
are neccessary or go in a direction I want to go.

>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.

Agreed, fixed.

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

See 4.

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

See 4.

>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.

Resolved by referring this to the BER encoding rather than the ASN.1 syntax.

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

The intention was to have just one event for either 'boolean' or
'existence' so I added 'existence' to the existing one.

>10) Typo in reference 17: "SYSTEMS<"

Removed in change to new reference form.

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

Agreed, fixed.

Those could have been worse...

	Bob