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

From: Alan Luchuk <[email-masked]>
Date: Thu, 6 Jan 2000 09:56:22 -0500 (EST)

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
>> for the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum
>> 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.

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

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

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

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

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

>The comments are greatly appreciated.  I just wish they had come
>two years ago.

Me too.  But I was asked to review this at the 11th hour and 59th
minute.  

Two years ago, my coefficient of cluelessness was even higher :-)

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.