Application-Layer Traffic Optimization (ALTO) Server Discovery
RFC 7286
Yes
No Objection
Abstain
Recuse
Note: This ballot was opened for revision 09 and is now closed.
(Spencer Dawkins; former steering group member) Yes
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.
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) (was Discuss) No Objection
Version -10 addresses my comments, and thanks for considering them.
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stewart Bryant; former steering group member) No Objection
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 =======
(Ted Lemon; former steering group member) No Objection
(Joel Jaeggli; former steering group member) Abstain
(Martin Stiemerling; former steering group member) Recuse