Subject: <draft-ietf-disman-remops-mib-04.txt>

From: [email-masked]
Date: Thu, 3 Jun 1999 11:42:31 -0400 (EDT)

Hello all,

After reading <draft-ietf-disman-remops-mib-04.txt> at least twice,
here are my comments about the DISMAN-LOOKUP-MIB.  I believe this'll 
be my last installment of comments.  Thanks for your patience with
all of my comments.....   I hope they've added value to the MIB 
design and not just wasted network bandwidth and peoples' time.  

Thanks, Ken, for your ongoing work on these MIBs and the document
draft!

Here goes:

Section 3.3, Page 9, First textual paragraph in this section
------------------------------------------------------------

before>  maximum number of concurrent requests that an agent
after>   maximum number of concurrent active requests that an agent

In the DISMAN-LOOKUP-MIB itself:
--------------------------------

I believe the utility of this MIB would be increased by making
it similar to the DISMAN-PING-MIB and DISMAN-TRACEROUTE-MIB.
I believe it should have a control table that can be stored in 
NV-storage, triggered at periodic intervals, collect the results
in one/more results tables, and send notifications when lookups 
fail (or possibly when the lookup results change, etc.)

As written, the DISMAN-LOOKUP-MIB can provide a "lookup succeeded/
lookup failed" indication at the remote host.  I believe the utility 
of this MIB would be enhanced if it contained more objects for 
analyzing/isolating/resolving lookup problems at the remote host.

Would it make sense to add an object so the user can specify the
IP address of the domain name resolver to use?   I believe this 
implies that resolver functions other than gethostbyname() or 
gethostbyaddr() must be used to do the lookup.

Would it make sense to provide objects for returning other results 
returned by the lookup operation?   For example, I can imagine 
situations where E-mail is not working correctly from a remote host 
to a target host, and the network analysts might want to look up 
the MX records seen by the remote host.

Renaming:

      lookupAddressType  --->  lookupTargetAddressType
      lookupAddress      --->  lookupTargetAddress

might clarify these slightly given the block diagram shown at the
top of page 4 in the draft.

It's unclear to me why the second index in the traceRouteCtlTable
is an SnmpAdminString, instead of something that's easier to implement
and use or something more meaningful to the user like an IP address.

I'm unclear what function the lookupAddressType and lookupAddress
indices in the lookupTable provide.  Are these necessary?  Would 
someone please help me understand?  

Would it make sense to add a lookupDescr octet-string MIB object
to the lookupTable simply to provide a user-documentation field?

The lookupMaxConcurrentRequests again is an Integer32, when Unsigned32
would be more semantically correct.  The justification for the range
restriction on lookupMaxConcurrentRequests is unclear to me.  Would it
make sense to eliminate the subrange?

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