Application-Layer Traffic Optimization (ALTO) Requirements
draft-ietf-alto-reqs-16

Thanks for addressing my Discuss and Comments

Substantive suggestions; please adopt or respond to these:

   REQ.  ARv14-9: An ALTO client protocol specification MUST define
   mechanisms, which can be used by the ALTO client to indicate

This looks like it was meant to be restrictive, not non-restrictive (as it's written).  Need to remove the comma and preferably change "which" to "that".  This applies to Req 16 also.  This really is an important distinction in English, so please fix this.  (You got it right in Req 8.)

NEW
   REQ.  ARv14-9: An ALTO client protocol specification MUST define
   mechanisms that can be used by the ALTO client to indicate

-- Req 13 --
This isn't a requirement on the client protocol, but one on the client implementations.  That's a different thing.  I don't object to those being recorded in this document also, but they should be in a separate section, and not intermixed with protocol requirements.  (The way Req 3 is written, it's that way as well, though it might best be rephrased to clearly be a requirement on the protocol.)

-- Req 28 --
Why is this a requirement?  It may well be that the protocol(s) that get specified use TCP, but what's the reason to *forbid* the development of one that uses, say, SCTP?

========
Editorial suggestions.  No need to respond to these; take them or modify them as you please:

-- Section 2.2 --
OLD
      Some rating criteria, such as "low
      topological distance", need to include a reference point, i. e.,
      "low topological distance from a given resource consumer".

I presume that should be "e.g.", not "i.e.".  That is, there are other possibilities.  There's another instance of this as well.  I actually recommend forgoing the Latin abbreviations, and just using "that is" instead of "i.e." and "for example" instead of "e.g.". It avoids this confusion.

-- requirements --

General: some of the requirements seem a bit silly... Req 1 is especially so, and 21 seems like another.  But I suppose it's harmless to put some obvious things in as requirements, so I don't object.  Req 4 is another example...not really "silly", but more in the line of protocol *specification* than requirements.  There are a few others of these, too (24 is doing a lot of protocol specification while it's stating its requirement).

-- Req 12 --
What is the purpose of the indentation of the second paragraph?  It looks like a blockquote, but there's no citation, so I suspect there's another purpose... but the purpose isn't clear.

-- Req 29, 30, 31 --
I think these would be clearer if they were in one requirement (and the extraneous implementation info in the second paragraph of 29 were removed).  Something like this:
NEW
   REQ. ARv14-29: An ALTO client protocol specification MUST
   specify mechanisms, or detail how to leverage appropriate
   mechanisms provided by underlying protocol layers, that can
   be used by an ALTO server to inform ALTO clients about an
   impending or occurring overload situation, and provide all of the
   following options to the server:
   - request the client to throttle its query rate
   - redirect the client to another ALTO server
   - terminate the conversation with the client

-- Req 32, 33, 34 --
Same comment as for 29-31.  And the note after 33 is also a protocol specification issue, not a requirement on the protocol.

-- Section 4 --
This seems unnecessary.  Subsequent documents may always have IANA actions.  Please just say "This document has no IANA actions, and the RFC Editor should remove this section prior to publication."

-- Section 5 --
Just a comment that this section looks very well thought out.  Thanks for putting the effort into this.

Substantive suggestions; please adopt or respond to these:

- Section 1. Introduction

   Usually, it would be difficult or even impossible for application
   entities to acquire this information by other mechanisms, e.g., using
   measurements between the peers of a P2P overlay, because of
   complexity or because it is based on network topology information,
   network operational costs, or network policies, which the respective
   network provider does not want to disclose in detail.


"difficult or even impossible", "because it is based on network topology information, network operational costs, or network policies, which the respective network provider does not want to disclose in detail. "
TWAMP type probes, even at the applications level, are possible, and not difficult.
However, I believe that the real issue is the scalability: way too many peers in a P2P. That would imply network operational costs, sure.
But you don't always need the network topology information, if you "just" want to test for the nearest peer.
It would be great if you could update the text.

- Section 2.3

   This document itemizes requirements for the following components:
   ALTO client protocols, ALTO server discovery mechanisms, host group
   descriptors, rating criteria, and host characteristics attributes.
   Furthermore, requirements regarding the overall architecture,
   especially with respect to security and privacy issues, are
   presented.

I was confused by the plurals of these terms. Are you actually proposing multiple solutions?
I found my answer later in the doc.:

   The detailed specification of an ALTO client protocol is out of the
   scope of this document.  In fact, this document does not even assume
   that there is only one single protocol specification.  However, this
   document enumerates requirements for ALTO, to be considered when
   specifying, assessing, or comparing protocols and implementations.

You should move this paragraph in section 2.3, or at least put a similar explanation in 2.3

-  REQ.  ARv14-12

So basically, this is a generic requirement that ALTO is not suited for any real-time rating criterion. Do I get this right?
Should you then write something such as: ALTO client protocol specifications MUST NOT define any rating criteria that vary at an order of magnitude equivalent to the RTT

- 

   REQ.  ARv14-5: An ALTO client protocol MUST be extensible to enable
   support of other host group descriptor types in future.  An ALTO
   client protocol specification MUST define an appropriate procedure
   for adding new host group descriptor types, e.g., by establishing an
   IANA registry.

Why don't you reuse an existing registry, in which you will have all the Information Elements already defined? I have in mind: the IPFIX I.E. in IANA
When you will control your applications with ALTO, you will anyway want to apply a flow measurement to monitor your changes, and to serve as a feedback loop for more optimizations.
Therefore, it would make sense to have consistent data models between ALTO and IPFIX.
Proposal:
1. New text

   REQ.  ARv14-5: An ALTO client protocol MUST be extensible to enable
   support of other host group descriptor types in future.  An ALTO
   client protocol specification MUST define an appropriate procedure
   for adding new host group descriptor types, e.g., by establishing or
   reusing an IANA registry.

2. At the protocol design time, reusing the IPFIX ElementID

-   REQ.  ARv14-28: An ALTO client protocol MUST use TCP based transport.

I don't understand why you impose this? If SCTP is ever deemed to be beneficial...
However, if you have a good reason to explicitly mandate TCP, please explain it.

- REQ.  ARv14-48

   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).

I don't understand this requirement.
Do you want to express that the ALTO protocol must return his full database if the data field is empty?
Then, where is the guidance?


========
Editorial suggestions.  No need to respond to these; take them or
modify them as you please:

- Section 1. Introduction

   The goal of
   these informed decisions is to improve performance or Quality of
   Experience in the application while reducing resource consumption in
   the underlying network infrastructure.
QoE, please give a reference to RFC6390, where it's defined.

-  Section 2.3

   The ALTO problem statement [RFC5693] defines a terminology (see
   Section 2 of [RFC5693] and Section 2.2 of this document), introduces
   several components.  It presents a figure that gives a high-level
   overview of protocol interaction between these components.
Personal taste: copy the figure over. Up to you.

- DHT to be expanded.

- I don't see any requirements on the placement of the server.
There are none?  Do you want to add a sentence about it?

I agree with Barry that some of the requirements should be re-worded.  Otherwise, I have no issues with publishing this document.

Please review Ted Hardie's comments in his Apps Directorate review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03337.html> and address as appropriate.

I'm throwing my lot in with Stephen and Pete.

I'm (still:-) a bit confused by what might be a conflict
between sections 3.3 and 5.2. The former says that
nothing is mandatory-to-use, but the latter says
that "neither the ALTO server nor a third party
using or misusing the ALTO service should be able to
infer the application behavior, e.g., who is
exchanging which files with whom using a P2P file
sharing application." I can't see how the latter can
be guaranteed if the former is true.

Thank you for addressing my concern.