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

[Juergen Quittek <[e-mail]>]

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