Subject: disman WG last call: event MIB

From: Randy Presuhn <[email-masked]>
Date: Wed, 10 Mar 1999 17:51:23 -0800 (PST)

Hi -

There have been no issues raised since the posting on Feburary 22 of
<draft-ietf-disman-event-mib-06.txt>, so I'm now issuing a working
group last call, to expire on 1999-03-25 01:00:00 UTC (that's 5 pm
PST on Wednesday, March 24).

If you are committed to reviewing this material but need additional
time, please contact me before the working group meeting in Minneapolis.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 24 Mar 1999 17:38:01 -0800 (PST)

Hi -

> Date: Wed, 10 Mar 1999 17:51:23 -0800 (PST)
> From: Randy Presuhn <rpresuhn>
> To: [email-masked]
> Subject: disman WG last call: event MIB
> 
> Hi -
> 
...

The disman chair says:

No one has requested additional time.  The only issues raised on the
working group mailing list are those in Juergen Schoewaelder's message
of March 23.  The working group last call for this document will
remain open until these issues have been resolved and, if necessary,
a new draft issued.  I would like to do this quickly, but it all
depends on our editor and technical contributors to reach closure
on these 11 points.

As a technical contributor, I suggest:

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

We discussed some of the subtle points of the substring approach at
the working group meeting in Minneapolis, which are hinted at (but
not as explicit as they could be) in the current draft.  I think we
should either thoroughly explain the implications of substringing or
else not mention it at all.

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

As Rob Frye has already observed, Bob Stewart has an action item
to figure out what he meant here.

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

If I were implementing this MIB, I'd probably end up using an
enterprise MIB to augment this one in order to provide persistance
control.  Ugly.  It would be prefereable to have the storage type
as part of "control" entries, with the conformance material
making it perfectly clear that for some implementations the only
value supported might be "volatile".

|4) Change mteOwner to mteTriggerOwner.

Is the issue here that the owners are likely to by Groups rather
than Users?

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

This should be fixed.

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

Same as for 4.  I'm not sure I see what the problem is, but I'm
trying to understand.

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

Same as 4.

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

I had read this differently.  I had assumed that the choice of
"integer" rather than INTEGER was deliberate, since the signed
and unsigned forms are specializations (constrained subranges)
of the generic type.  Since we read it in totally different
ways (I read it as "mathematical integer", Juergen read it as
"SMI integer") I guess some clarification is needed.

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

This seems like an oversight.  I'd support adding notification for
existance triggers.

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

Should be fixed.  :-)

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

Yes.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Mar 1999 10:41:14 -0800 (PST)

Hi -

Non-subscriber submission forwaded.

> Received: from tangelo.bmc.com ([email-masked] [172.17.7.166])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA13925
> 	for <[email-masked]>; Mon, 29 Mar 1999 09:45:07 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250])
> 	by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA12773
> 	for <[email-masked]>; Mon, 29 Mar 1999 11:45:01 -0600 (CST)
> Received: from henkell.ibr.cs.tu-bs.de (strauss@henkell [134.169.34.191])
> 	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id TAA27034;
> 	Mon, 29 Mar 1999 19:44:54 +0200 (MET DST)
> Received: from strauss@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA28625; Mon, 29 Mar 1999 19:44:53 +0200
> From: Frank Strauss <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: disman WG last call: event MIB
> References: <[email-masked]>
> Mime-Version: 1.0 (generated by tm-edit 7.106)
> Content-Type: text/plain; charset=US-ASCII
> Date: 29 Mar 1999 19:44:53 +0200
> In-Reply-To: [email-masked]'s message of "11 Mar 1999 02:55:26 +0100"
> Message-ID: <[email-masked]>
> Lines: 10
> X-Mailer: Gnus v5.5/Emacs 20.3
> 
> Hi!
> 
> draft-ietf-disman-event-mib-06.txt:
> 
> > dismanEventNotificationGroup NOTIFICATION-GROUP
> >         OBJECTS {
> 
> s/OBJECTS/NOTIFICATIONS/
> 
>  Frank
>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Mar 1999 11:20:10 -0800 (PST)

Hi -

Another forwarded posting for the disman list.

> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA14358
> 	for <[email-masked]>; Mon, 29 Mar 1999 10:28:44 -0800 (PST)
> 	by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA20657
> 	for <[email-masked]>; Mon, 29 Mar 1999 12:28:42 -0600 (CST)
> 	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id UAA28105;
> 	Mon, 29 Mar 1999 20:28:33 +0200 (MET DST)
> Received: from strauss@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA00473; Mon, 29 Mar 1999 20:28:29 +0200
> Date: 29 Mar 1999 20:28:29 +0200
> Message-ID: <[email-masked]>
> Lines: 28
> > mteEventActions OBJECT-TYPE
> >     SYNTAX      BITS { notification(0), set(1) }
> > [...]
> >     DEFVAL { { 0 } }
> 
> SMIv2 (draft-ops-smiv2-smi-01.txt, RFC1902 is not that clear):
> 
> > [...]
> >     Defvalue ::=  -- must be valid for the type specified in
> >                   -- SYNTAX clause of same OBJECT-TYPE macro
> >                   value(ObjectSyntax)
> >                 | "{" BitsValue "}"
> > 
> >     BitsValue ::= BitNames
> >                 | empty
> > 
> >     BitNames ::=  BitName
> >                 | BitNames "," BitName
> > 
> >     BitName ::= identifier
> 
> So, the DEFVAL clause should be ``{ { notification } }''.
> 
>  Frank
>