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

[Brian E Carpenter <[e-mail]>]

Thanks. I have captured all this as a DISCUSS comment
but it will be a simple cut and paste to make it into
an RFC Editor note, at which point I can clear.

    Brian

Juergen Quittek wrote:
> 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
> 


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