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

That would be good enough for me.
(The real call here of course is up to Brian, but I think you have 
addressed the problem.)

Thank you,
Joel

At 07:47 PM 3/14/2006, Juergen Quittek wrote:
>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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art