[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 protected]
NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
