Application-Layer Traffic Optimization (ALTO) Server Discovery
RFC 7286

Note: This ballot was opened for revision 09 and is now closed.

(Spencer Dawkins) Yes

Comment (2013-08-23 for -09)
No email
send info
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.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2013-08-27 for -09)
No email
send info
I have no objection to the publication of this document, but I do have a comment and a nit.

=====

I find the following text strange:

"In other words, this document
 tries to meet requirement AR-32 in [RFC6708] while AR-33 is out of
 scope.  A different approach, which tries to meet requirement AR-33,
 i.e., third-party ALTO server discovery, is addressed in
 [I-D.kist-alto-3pdisc]."

What does it mean to "try to meet"?

If the RFC meets the requirement, then it is useful for the reader to be left in no doubt. If on the other hand it only partially succeeds, it would be useful to the reader to know this early in the text together with a list of issues with the approach.

This may of course be a case of modesty, in which case I suggest s/tries to meet/meets/

========

i.e., a PTR lookup

PTR is used without a definition

=======

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2013-09-09)
No email
send info
Version -10 addresses my comments, and thanks for considering them.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Sean Turner) (was Discuss) No Objection

(Joel Jaeggli) Abstain

(Martin Stiemerling) Recuse