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.