Joel,
--On 3/14/06 7:23 PM -0500 Joel M. Halpern wrote:
(Not copying the agreements...)
This is progress. I actually was not clear reading the MIB whether
the local lookup or the DNS lookup was expected.
Something similar needs to be done to the earlier references to gethostbyName()
etc.
A little bit of text about the number->name direction would also be helpful,
to explain why that is needed here.
We could do the following:
OLD:
1.3. Lookup
The Lookup operation enables remote lookup of addresses for a
symbolic name as it is, for example, performed by functions
getnameinfo() or gethostbyaddr() and lookup of symbolic names for a
addresses as it is, for example, performed by functions getaddrinfo()
or gethostbyname(). The lookup capability can be used to determine
the symbolic name of a hop in a traceroute path.
NEW:
1.3. Lookup
The Lookup operation enables remote lookup of addresses for a
symbolic name as it is, for example, performed by functions
getnameinfo() or gethostbyaddr() and lookup of symbolic names for a
addresses as it is, for example, performed by functions getaddrinfo()
or gethostbyname(). Note that whatever lookup function is chosen,
results are not necessarily consistent with the results of a pure
Domain Name Service (DNS) lookup, but may be influenced by local
lookup tables or other sources of information. The lookup capability
can be used to determine the symbolic name of a hop in a traceroute
path. Also the reverse lookup can be used, for example, for analyzing
name lookup problems.
Would this address your concerns?
Thanks,
Juergen
Yours,
Joel
At 07:10 PM 3/14/2006, Juergen Quittek wrote:
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.
?
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
