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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 06 Mar 2006 18:10:07 -0500

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

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

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

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 
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Mar 2006 01:10:35 +0100

Joel,

Thank you for your comments.
Please see replies inline.

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

> This document is nearly ready for publication as a Proposed Standard.
> I have one concern, described below, and a few minor comments.
>
>      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.

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.

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

?

> pingProbeHistoryTable is intended.

That's right.  Thanks for this catch.

>      The results of each past ping probe is stored in this table on a

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

Thanks,

    Juergen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Mar 2006 19:23:23 -0500

(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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Mar 2006 01:47:17 +0100

Joel,

--On 3/14/06 7:23 PM -0500 Joel M. Halpern wrote:

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Mar 2006 20:05:17 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2006 10:57:57 +0100

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:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gen-art
>

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 16 Mar 2006 00:44:02 +0100

Joel,

So far, I did not answer the last question of your initial email.
Please find an answer inline.

> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

 [...]

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

It is a common option of existing traceroute implementations.
For the BSD traceroute it reflects the -r option:

     -r      Bypass the normal routing tables and send directly to a host on
             an attached network.  If the host is not on a directly-attached
             network, an error is returned.  This option can be used to ping a
             local host through an interface that has no route through it
             (e.g., after the interface was dropped by routed(8)).

Object traceRouteCtlByPassRouteTable gives access to this option.
I agree that it is not really needed if also the PING MIB is available.
It might be useful, however, if not.  Anyway, it is contained in the first
version of the TRACEROUTE MIB in RFC 2925 and it would create an unnecessary
incompatibility if we removed it.

Thanks,

    Juergen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Mar 2006 19:10:29 -0500

That's a good enough reason to keep it.
I think that all the functionality is provided by the ping portion, 
but a little duplication to avoid an incompatibility mess is fine.

Yours,
Joel