Application-Layer Traffic Optimization (ALTO) Server Discovery
Note: This ballot was opened for revision 09 and is now closed.
(Spencer Dawkins) Yes
Comment (2013-08-23 for -09)
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)
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
Version -10 addresses my comments, and thanks for considering them.