Draft:  draft-ietf-disman-remops-mib-v2-09.txt
Reviewer: Joel M. Halpern [joel@stevecrocker.com]
Review Date:  Monday 3/6/2006 5:10 PM CST
IETF LC Date: 9 March 2006

Summary: This document is nearly ready for publication as a Proposed 
Standard.  I have one concern, described below, and a few minor comments.

The definition of the lookup tables bothers me.
The short form:
     The name of the MIB is NSLOOKUP.  The name of the operation is 
dns.  But the definition is not
     "perform a dns A or AAAA lookup."  It is, "do the equivalent of 
some API" that the host may or may not have.
     This is not a good functional definition.
The function is defined in very general terms.  It performs either a 
symbolic lookup to get an IP address, with further definition only in 
terms of the name of common API functions, or a reverser lookup to 
get from IP address to name, again with the functional requirement 
given in terms of an API name.  Given that these APIs are not 
standardized 9and no particular implementation is referenced) this is 
not a clear, implementable, interoperable definition.
I suspect that the intent here is to allow whatever the host would do 
with a typical application request to get this kind of 
information.  And that it is specifically vague so as to allow 
reference to caches or local configuration tables, as the host would perform.
However, the text does not say "Do what you would do for a local 
application."  It says "do something like these APIs."
If the intent is explicitly to cause local caching / config tables to 
be visible to the MIB, then we MUST say that.
If the intent is to perform a DNS lookup from that host (forward or 
reverse) then we need to say that.


Minor: The description of the pingResultsTable refers to the 
pingPastProbeTable.  There is no such table.  Presumably, the 
pingProbeHistoryTable is intended.

Minor:  Could the first sentence of 3.1.4 on pingProbeHistoryTable be:
     The results of each past ping probe is stored in this table on a 
per pingCtlEntry basis.
?

Minor: What is the purpose of traceRouteCtlByPassRouteTable?  I can 
understand with ping needing to be able to say "ping this neighbor, 
even if routing is confused.  However, why is there a similar entry 
in the traceroute control table?  Given that the restriction is that 
one is talking to a neighbor, what is the point of sending a traceroute?