Application-Layer Traffic Optimization (ALTO) Server Discovery
draft-ietf-alto-server-discovery-10

I thought this draft was well-written and clear.

I had two minor and non-blocking comments and would appreciate if they were considered, along with any other comments that may come out of IESG Evaluation.

In 3.1.1.  Step 1, Option 1: User input

   The preferred way to acquire a domain name related to an interface's
   point of network attachment is the usage of DHCP (see Section 3.1.2).
   However, in some network deployment scenarios there is no DHCP server
   available.  Furthermore, a user may want to use an ALTO service
   instance provided by an entity that is not the operator of the
   underlying IP network.  Therefore, we allow the user to specify a DNS
   domain name, for example in a configuration file option.  An example
   domain name is:

      my-alternative-alto-provider.example.org

   Implementations MAY give the user the opportunity (e.g., by means of
   configuration file entries or menu items) to specify an individual
   domain name for every address family on every interface.
   Implementations SHOULD allow the user to specify a default name that
   is used if no more specific name has been configured.

So, if you MAY have the opportunity to specify an individual domain name for every address family on every interface, but you don't, and you SHOULD be able to specify a default name, but you can't, can you still use ALTO?

In 6.1.  Integrity of the ALTO Server's URI

      Due to the nature of the protocol, DHCP is rather prone to
      attacks.  As already mentioned, an attacker that is able to inject
      forged DHCP replies into the network may do significantly more
      harm than only configuring a wrong ALTO server.  Best current
      practices for safely operating DHCP should be followed.

Is there a reference you can point to for best current practices when operating DHCP? 

Your answer may be "not really", of course - RFC 2131, in section 7, just says it's easy for unauthorized servers to forge DHCP replies, and I didn't see any of the RFCs listed as updating RFC 2131 solving that problem.