Joel,
Thank you for your comments.
Please see replies inline.
--On 3/6/06 6:10 PM -0500 Joel M. Halpern wrote:
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.
The MIB module specification does not necessarily require an implementation
to use DNS. So the operation is name lookup.
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.
Indeed. But this is the intention of the MIB module. Usually, there
is more value in finding out with what result an actual name is resolved
at a remote host than what DNS delivers to this host as resolution.
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."
I see the problem and agree that it should be fixed.
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.
As stated above, my view is that the MIB module should return whatever an
application would receive. This should be clarified in section 3.3.3.
What about
OLD:
3.3.3. lookupResultsTable
The lookupResultsTable is used to store the results of lookup
operations. The lookupResultsTable is initially indexed by the same
index elements that the lookupCtlTable contains (lookupCtlOwnerIndex
and lookupCtlOperationName) but has a third index element,
lookupResultsIndex (Unsigned32 textual convention), in order to
associate multiple results with the same lookupCtlEntry.
NEW:
3.3.3. lookupResultsTable
The lookupResultsTable is used to store the results of lookup
operations. Results to be reported here SHOULD be results of
a lookup function that is commonly used by applications at the
managed node. This implies that results are not necessarily
consistent with the results of a pure DNS lookup at the
managed node, but may be influenced by local lookup tables or
other source of information, depending on the configuration of
the managed node.
The lookupResultsTable is initially indexed by the same
index elements that the lookupCtlTable contains (lookupCtlOwnerIndex
and lookupCtlOperationName) but has a third index element,
lookupResultsIndex (Unsigned32 textual convention), in order to
associate multiple results with the same lookupCtlEntry.
?
Minor: The description of the pingResultsTable refers to the
pingPastProbeTable. There is no such table. Presumably, the
pingProbeHistoryTable is intended.
That's right. Thanks for this catch.
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.
?
I would be fine with this change if we replace "is" with "are".
Thanks,
Juergen
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
