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

From: [email-masked]
Date: Tue, 8 Jun 1999 09:00:05 -0400

Hi,

>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

Done.

>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 I mentioned before there is now a 2nd table for storing the results.
There are no StorageType or frequency objects in a ctlEntry since I can't
imagine ever wanting to define a lookup operation as a periodic test.

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

I think we decided at the last working group meeting not to expand
the lookup MIB in these areas.

>Renaming:

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

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

Done as per my response to a similiar comment with respect to the
ping MIB.

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

Same answer as before.

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

As I mentioned before I am thinking about removing them from being part
of the index. Waiting to see if anyone objects.

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

No. Lookup entries are not capable of being periodic tests and don't
need such an object.

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

Changed as per Randy's prior comment.

Regards, Ken