I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team). Please
resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-alto-reqs-11
Reviewer: Ted Hardie
Review Date: September 15, 2011

Summary:

I believe that this document needs further work before publication as an
Informational RFC.

Major Issues:

Section 5.2.1 on Classification of Information Disclosure Scenarios
has no scenarios relating to the user privacy aspects of disclosure.  There
is a great deal of work on the potential privacy threats related to
correlation of data; some reference to that threat, and any mitigation
available, seems required.  The privacy discussion in ARv11-49 also does
not discuss this, but it is a basic part of the risk here, since an ALTO
server
could theoretically see a much broader set of resource requests than
a single server.


Minor Issues:

REQ ARv11-8 says:

   ARv11-8: For host group descriptor types other than "IPv4
   address prefix" and "IPv6 address prefix", the host group descriptor
   type identification MUST be supplemented by a reference to a
   facility, which can be used to translate host group descriptors of
   that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
   table or an algorithm.

I did not see a justification for this limitation here or in RFC 5693.
A host group identifier that contained, for example, an AS number
seems to be within the scope of the protocol (though admittedly harder
to populate in a query).  If this limitation is driven by an
underlying requirement, I believe it should be made explicit.  If this
is intended to be allowed under REQ. ARv11-13, then a forward pointer
that states that host group descriptors that are not immediately
mappable to IP addresses should be extended with a different type would be
useful.

[Though AS number may not seem to be immediately practical, it might
actually
be faster to populate in ALTO queries than the current external IP of
a NATted or double NATted host.  By identifying the AS, the ALTO
service provider may be able to identify peering and transit
relationships between resource providers and the node making the query--thus
helping
identify the appropriate choice. ]

In ARv11-12, the document is indicating that the preferences expressed
are relative, but it does not say whether they are pure ordinals or
whether they are weighted.  If this is not yet decided, that's fine.
But if the intent is to say that they are pure ordinals, it might be
good to make that explicit.  There's a lot of experience in CONNEG
contexts that says implementors will attempt to infer weights and
engage is some mighty dodgy math if this is not clear.

REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require
that the two modes must be distinguishable, so that a client can avoid
sending targets to ALTO services that do not support them.  If this is
the case, an explicit statement of this in one of the two would be
useful.

ARv11-27 is unclear as to whether ALTO transactions populated only
with RFC1918 addresses are what must be supported or whether the
intent is integration with methods for determining external addresses.

The document currently says:

   In particular, as a simple way of achieving some basic form of
   throttling, an ALTO server MAY answer ALTO queries with a "Retry
   After: {point in time | time delta}" message.  This "Retry After" MAY
   be sent as part of the ALTO reply together with the requested guiding
   information, or as a standalone (error) message not giving the
   requested guidance.

The first form creates an implicit requirement for a synchronized
clock, which should either be made explicit or eliminated in favor of
the second form.

REQ. ARv11-47 is not clear on the threat being addressed, so it is not
clear whether the messages themselves must be encrypted or encryption
of the hop-by-hop transport is sufficient.  Some clarification would
be useful.

In REQ. ARv11-50, the document says:

   An ALTO server MUST provide adequate guidance even if the ALTO
   client prefers not to specify the desired resource (e.g., keeps the
   data field empty).

Depending on the data distribution method, this may not be possible.
I assume that this is meant to cover only target cases where both the
resource and target host are mentioned.  It would be helpful to
clarify this.

Editorial:

I believe the abstract is difficult to parse.  I personally would find
something like the following more readable:

Certain resources, such as pieces of information or server processes,
are available from multiple hosts on the network.  Applications which
access those resources currently have no guidance on the likely
performance of different potential sources.  The goal of ALTO is to
provide guidance for selecting among candidates sources to
applications consuming multiply homed resources.  This guidance shall
be based on parameters that affect performance and efficiency of the
data transmission between the hosts, e.g., the topological distance.
The ultimate goal is to improve performance (or Quality of Experience)
in the application while reducing resource consumption in the
underlying network infrastructure.


The Introduction says:

   The logical entities that provide the ALTO service do not take part
   in the actual user data transport, i.e., they do not implement
   functions for relaying user data.  They may be placed on various
   kinds of physical nodes, e.g., on dedicated servers, as auxiliary
   processes in routers, on "trackers" or "super peers" of a P2P
   application, etc.

I believe the phrase "logical entities" here is meant to imply that
these functions are separable and that there is no necessary
relationship between the entities providing the ALTO service and those
providing the access to resources.  If this is the case, some
clarification may be useful.

In section 2.3, I originally read the "see section 2.2" as refering to
section 2.2 of RFC 5693 (see section 2.2. above) would be mildly
better.  Since there is no Section 2.2 in RFC 5693, though, this is a
self-correcting problem.