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

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    alto mailing list <alto@ietf.org>,
    alto chair <alto-chairs@tools.ietf.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.