I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
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?
At 04:50 PM 3/1/2006, Mary Barnes wrote:
---------------------------
Reviewer: Joel Halpern
- 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
Operations '
<draft-ietf-disman-remops-mib-v2-09.txt> as a Proposed Standard
IETF LC ends on 2006-03-09.
The file can be obtained via
<http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt>http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
