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