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

[Juergen Quittek <[e-mail]>]

Joel,

Thank you for your comments.
Please see replies inline.

--On 3/6/06 6:10 PM -0500 Joel M. Halpern wrote:

> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> This document is nearly ready for publication as a Proposed Standard.
> I have one concern, described below, and a few minor comments.
>
> The definition of the lookup tables bothers me.
> The short form:
>      The name of the MIB is NSLOOKUP.  The name of the operation is dns.

The MIB module specification does not necessarily require an implementation
to use DNS.  So the operation is name lookup.

>      But the definition is not "perform a dns A or AAAA lookup."  It is,
>      "do the equivalent of some API" that the host may or may not have.
>      This is not a good functional definition.

Indeed.  But this is the intention of the MIB module.  Usually, there
is more value in finding out with what result an actual name is resolved
at a remote host than what DNS delivers to this host as resolution.

> The function is defined in very general terms.  It performs either a
> symbolic lookup to get an IP address, with further definition only in
> terms of the name of common API functions, or a reverser lookup to get
> from IP address to name, again with the functional requirement given in
> terms of an API name.  Given that these APIs are not standardized 9and
> no particular implementation is referenced) this is not a clear,
> implementable, interoperable definition.  I suspect that the intent here
> is to allow whatever the host would do with a typical application request
> to get this kind of information.  And that it is specifically vague so as
> to allow reference to caches or local configuration tables, as the host
> would perform.
> However, the text does not say "Do what you would do for a local application."
> It says "do something like these APIs."

I see the problem and agree that it should be fixed.

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

?

> Minor: The description of the pingResultsTable refers to the
> pingPastProbeTable.  There is no such table.  Presumably, the
> pingProbeHistoryTable is intended.

That's right.  Thanks for this catch.

> Minor:  Could the first sentence of 3.1.4 on pingProbeHistoryTable be:
>      The results of each past ping probe is stored in this table on a
>      per pingCtlEntry basis.
> ?

I would be fine with this change if we replace "is" with "are".

Thanks,

    Juergen

> Minor: What is the purpose of traceRouteCtlByPassRouteTable?  I can
> understand with ping needing to be able to say "ping this neighbor,
> even if routing is confused.  However, why is there a similar entry
> in the traceroute control table?  Given that the restriction is that
> one is talking to a neighbor, what is the point of sending a traceroute?
>
>
>
> At 04:50 PM 3/1/2006, Mary Barnes wrote:
>> ---------------------------
>> Reviewer: Joel Halpern
>>
>> - 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
>>    Operations '
>>    <draft-ietf-disman-remops-mib-v2-09.txt> as a Proposed Standard
>>
>> IETF LC ends on 2006-03-09.
>>
>> The file can be obtained via
>> <http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt>http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt
>>
>



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art