Application-Layer Traffic Optimization (ALTO) Server Discovery
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, alto mailing list <email@example.com>, alto chair <firstname.lastname@example.org> Subject: Protocol Action: 'ALTO Server Discovery' to Proposed Standard (draft-ietf-alto-server-discovery-10.txt) The IESG has approved the following document: - 'ALTO Server Discovery' (draft-ietf-alto-server-discovery-10.txt) as Proposed Standard This document is the product of the Application-Layer Traffic Optimization Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/
Technical Summary The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. Working Group Summary The draft was discussed extensively in the WG meetings as well as on the mailing list. This particular document was the result of a merge of a draft discussing first-party discovery and another draft discussing third party discovery. However, as the merged draft proceeded through the WG, it became clear that unifying first- and third-party discovery in a single draft is problematic. Therefore, the first- and third-party server discovery are now separate drafts, with the third-party server discovery appearing in its own draft. This implies that the draft under consideration (draft-ietf-alto-server-discovery) is focused on first-party ALTO server discovery. During the Atlanta IETF meeting (IETF 85, November 2012) it was pointed out that there is some work on using HTTPS GET mechanism to discover the location of a given type of service (draft-jones-simple-web-discovery), and perhaps draft-ietf-alto-server-discovery could use the mechanism mentioned in draft-jones-... instead of requiring a U-NAPTR lookup as is currently done. Discussion on the mailing list on this seem to weigh in favour of not using draft-jones-... since it is in its formative stages and there is nothing technically wrong with the specifications currently contained in draft-ietf-alto-server-discovery. At things stand right now, the WG is proceeding with draft-ietf-alto-server-discovery in its current state; proponents of the mechanism mentioned in draft-jones-... will describe in a draft on how they forsee using it in the general problem of ALTO server discovery. Subsequent to this, the WG can decide on next steps, i.e., whether to update the RFC that results from draft-ietf-alto-server-discovery or whether to publish a new and alternate first-party ALTO server discovery mechanism. Document quality: There are no known implementations of the mechanism specified in draft-ietf-alto-server-discovery, however, since this is a crucial aspect before ALTO services can be consumed, the WG believes that implementations will be forthcoming once the mechanism is stable (as it appears now to be). The document itself is well-written and reasonably precise. There is no need for a MIB doctor, or a media type expert. The document has been shared with a DNS expert who weighed in appropriately on Section 3 of the document. More specifically, Olafur Gudmundsson provided an expert review on November 16, 2011 addressing shortcomings in the -00 version of this draft. The authors addressed the comments from Olaf in -03 of the draft, and those changes have since been maintained as the draft progressed. Personnel Vijay K. Gurbani is the document shepherd and Spencer Dawkins is the responsible AD.