Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt

"Joel M. Halpern" <[email protected]> Tue, 14 Mar 2006 19:23:23 -0500
Newsgroups gmane.ietf.disman
Message-ID <7.0.1.0.0.20060314191951.032f1038__20993.647844489$1142382249$gmane$org@stevecrocker.com>
(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.

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