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

Hi -

More comments.  Reponses, particularly from implementors, would be
most welcome.

Randy

----- Original Message ----- 
> From: "Brian E Carpenter" <[email protected]>
> To: "Joel M. Halpern" <[email protected]>
> Cc: "Randy Presuhn" <[email protected]>; "Bert Wijnen" <[email protected]>; "Dan > Romascanu" <[email protected]>;
<[email protected]>; <[email protected]>
> Sent: Monday, March 13, 2006 4:35 AM
> Subject: Re: [Gen-art] Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt
>

> All,
>
> I have tuned the cc list.
>
> Is there any reason the draft doesn't simply cite the socket API
> standard to define the lookup functions? I'm a bit confused
> about versions, but I believe that the latest version of
> the Open Group/POSIX 'Networking Services' standard is the right one.
>
> RFC 3493 could also be cited for IPv6 but isn't standards track.
>
> Anyway, a firm citation, and clarification of the caching vs direct
> resolution issue seems to be needed.
>
> Rapid comments, before I cast my IESG ballot, would be helpful.
>
>      Brian
>
> 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.
> > 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-re
mops-mib-v2-09.txt
> >>
> >
> >
> >
> > _______________________________________________
> > Gen-art mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/gen-art
> >
>