Subject: Re: <draft-ietf-disman-event-mib-09.txt>

From: Randy Presuhn <[email-masked]>
Date: Thu, 6 Jan 2000 11:13:19 -0800 (PST)

Hi -

> From: Alan Luchuk <[email-masked]>
> Date: Thu, 6 Jan 2000 09:56:22 -0500 (EST)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Re:  <draft-ietf-disman-event-mib-09.txt>
> Cc: [email-masked], [email-masked]
> 
> Hello all,
> 
> I've made my technical comments about draft 9 of the DISMAN-EVENT-MIB.
> I'm not going to argue for changing anything in draft 9, but I would 
> like to explain my points a little, if/when there is another doc cycle.
> 
> 
> >> Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement
>> MIB objects.
> >
> >I don't see what problem or requirement this would address.
> >Let's leave this question for the future based on implementation
> >and deployment experience.
> 
> Adding a "MIN-ACCESS read-only" clause in the compliance statement
> would let the DISMAN-EVENT-MIB _implementation_ specify the 
> mteResourceSampleMinimum and mteResourceSampleInstanceMaximum
> values, instead of allowing the _user_ to specify them.

I think the current object definitions already cover
this, where it has words to the effect "A system may use
the larger values of this minimum to lessen the impact of
constant sampling."  No matter what the user asks for, the
implementation can impose any lower bound it wants.

> >> In real-world implementations, the mteResourceSampleMinimum will
> >> always have seconds values that are zero or positive.  I suggest
> >> that changing its syntax to "Unsigned32" better reflects the real-
> >> world values it can take on.  Also, what is the rationale for the
> >> upper bound of 600 on mteResourceSampleMinimum?
> >
> >Changing the datatype from Integer32 to Unsigned32 would have
> >no effect on capability, but would change what shows up on the
> >wire.  It's not a change we need to make.
> 
> 
> I can align with 'no changes'.  
> 
> I tend to be compulsive about choosing the MIB object data type to best 
> reflect the real-world data for a two reasons.  First, it seems incon-
> sistent that human beings must use the user-hostile, very formal, ASN.1 
> grammer to accurately specify the SNMP data objects, then negate some of 
> the benefits of the formal ASN.1 grammer by choosing data types that are 
> not the best fit with the real-world data.  Second, my MIB compiler 
> automatically generates code that range-checks the incoming data.  With 
> accurate ASN.1 specifications of the data-types, I do not have to manually 
> code additional range checks to eliminate data values supported by the 
> ASN.1 definition, but not supported by the real-world.  Example:  What 
> does a mteResourceSampleMinimum of -1 seconds mean?

I could sell you a MIB compiler that generates the correct checks.  :-)
The SYNTAX clause clearly specifies that -1 would be a bad value.

> >Bob subsequently identified the -1 as a cut-and-paste
> >error.  The upper bound of 600 was never justified.
> >It looks like our agreement was to get rid of the upper
> >bound, i.e., make it 2147483647.  Comments?
> 
> Personally I don't care either way.  600 just seems arbitrary.

That was the sense of the room at the WG meeting.
Since this appears to be an agreed change that
wasn't applied, Let's make it 2147483647. 

> >> Should the DISMAN-EVENT-MIB have the capability to wildcard the
> >> mteTriggerTargetTag?   I can envision that DISMAN-EVENT-MIB users
> >> would want to monitor the same MIB objects on different IP hosts.
> >
> >The mteTriggerTargetTag is already capable of specifying
> >multiple ip hosts through the normal operation of the
> >target MIB.  The need for yet another layer of wildcarding
> >hasn't been established (yet).  Let's defer this.
> 
> Works for me.  Call me clueless, but I was unaware the target MIB
> supported specifying multiple IP hosts.  (Although I did give the
> target MIB a quick scan before I wrote this comment.)

One would do this by using a tag which appeared in multiple
instances of snmpTargetAddrTagList in the snmpTargetAddrTable
in RFC 2573.

Conceptually, it's like have another (invisible) table which
has the individual tags from each of the snmpTargetAddrTagLists
as one its first index, and snmpTargetAddrName as its second
index, serving as an associative memory representing the
1:N relationship.

> 
> >It's nice to know what object triggered the notification
> >as well as the values of potentially related objects.
> 
> I believe that most existing (uncustomized) SNMP management stations 
> can only log the variable-content notifications.  I believe that most
> existing (uncustomized) SNMP management stations cannot graphically 
> render the variable-content notifications.  Because I believe that
> most management stations cannot parse and present variable-content
> notifications to their users, I suspect this capability in the DISMAN-
> EVENT-MIB will be unused (while adding complexity to the MIB.)  There-
> fore, in future doc cycles of the DISMAN-EVENT-MIB, I believe the issue
> of having all of the xxxObjectOwner/xxxObject MIB objects in the
> trigger class/subclass tables should be carefully considered.

It'd be nice to hear from dbh and other manager folks on this.

> 
> >> Can someone give me examples where I would want to allow one
> >> user access to another user's entries in the mteObjectsTable
> >> and the mteEventTable?
> >
> >That's up to your security administrator.  For example, the
> >head network administrator probably should have sufficient
> >rights to turn off any of the monitors his/her minions
> >have created.
> 
> I suspect the capability of DISMAN-EVENT-MIB for Alan to generate
> triggers that reference Randy's objects and events will largely
> be unused in practice.  Eliminating this capability could simplify 
> the DISMAN-EVENT-MIB.
...

That could be.  We won't know until we get some experience with
the thing.   I think part of the rationale was that, in order to
conserve resources, an administration would define common events
(and payloads) to which individual operators would "subscribe"
through their trigger setups.  It'll be interesting to see
what, if anything, is done with this.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Thu, 06 Jan 2000 14:48:11 -0800

>implementation can impose any lower bound it wants.

I agree. Since the choice is left to the implementation to
choose a "saner" value, we should leave this as is...

Also you can still implement the object as read-only, and supply 
a CAPABILITY MIB indicating that it is a read-only implementation, right?

>wasn't applied, Let's make it 2147483647. 

Done.

[...snip...]

>> be unused in practice.  Eliminating this capability could simplify 

That could very well be, but we should wait for implementation
feedback on this before modifying behaviour...Sharing events
and object entries across multiple owners may be necessary
in resource constrained implementations, or to limit the
number of events/object entries in order to simplify
management.

Ram