Subject: Re: [alto] AD review of draft-ietf-alto-server-discovery-08

From: Martin Stiemerling <[email-masked]>
Date: Wed, 8 May 2013 16:25:14 +0200

[writing without my AD hat on]

Hi Richard,

On 04/17/2013 06:53 PM, Richard Barnes wrote:
> Dear ALTO WG,
>
> Since Martin is an author on this document, I'm acting as responsible AD
> during its IESG evaluation.  I've reviewed the document, and have a few
> questions before IETF LC.
>
> Major:
>
> To be blunt, I'm a little puzzled by why this document isn't much
> shorter.  It seems like it could just say "Follow the procedure of RFC
> 5986, except use different tags in the U-NAPTR lookup."  Possibly with
> some additional deployment / UI considerations.  As it is, it seems like
> this document re-states a lot of what's in RFC 5986.  For the rest of
> this review, however, I'll assume we're not going to re-write in the
> above form.

The document has a long and not easy history, as the whole space of 
server discovery seems to be not optimal. Re-writing could be one 
option, but we prefer to just get it going as it is.

>
> In Section 3.1.2., RFC 2132 "still may be useful".  Does that mean that
> a client MAY use it if the RFC 5986 option is not available?  For
> comparison, in RFC 5986: "DHCPv4 option 15 [RFC2132] provides an
> indication of the domain name that a host uses when resolving hostnames
> in DNS.  This option is used when the DHCPv4 access domain name is not
> available."

There is this text just below the cited paragraph explaining this 
(hopefully in an understandable way):

    For IPv6, the ALTO server discovery procedure MUST try to retrieve
    DHCP option 57 (OPTION_V6_ACCESS_DOMAIN).  If no such option can be
    retrieved the procedure fails for this interface.  For IPv4, the ALTO
    server discovery procedure MUST try to retrieve DHCP option 213
    (OPTION_V4_ACCESS_DOMAIN).  If no such option can be retrieved, the
    procedure SHOULD try to retrieve option 15 (Domain Name).  If neither
    option can be retrieved the procedure fails for this interface.  If a
    result can be retrieved it will be used as an input for the next step
    (U-NAPTR resolution).  One example result could be:

       example.net

>
>
> Minor:
>
> In the discussion of PTR lookups in Section 2, it might be helpful to
> refer to draft-ietf-geopriv-res-gw-lis-discovery, which extends RFC 5986
> to cover this problem.  For example, "Clients MAY employ a mechanism
> based on the reverse DNS, such as the one defined in
> [I-D.ietf-geopriv-res-gw-lis-discovery].  However, client developers
> should also note the caveats in that document as to how such mechanisms
> can fail, for example due to network address translation (NAT) devices."
>

draft-ietf-geopriv-res-gw-lis-discovery differs from what we are
describing (and advising not to do) in section 2: the geopriv draft
looks for an U-NAPTR RR in the in-addr.arpa tree.  we write that one
should not attempt to do a PTR lookup and use the result as input
for our algorithm.

Thanks,

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014