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

[Ballot comment]

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.

[Ballot discuss]
Thank you for explaining that other groups potentially (or even likely) *will* be using this document in the future; I think that makes it worth publishing. However, that also makes it all the more important that the open issues get addressed.

In his Apps Directorate review , Ted Hardie expressed concerns that some privacy issues are not properly addressed by this document. I agree, and these issues were not addressed in the latest revisions to the document. As he notes in particular:

- I do not equate "disclosure of application behavior" to "disclosure of privacy sensitive user data", and I do not think the document is clear enough on this point.

- Disclosure of aggregated data about queries is not addressed.

[Ballot discuss]
Both the document and the reviewer are confused over the transport protocol to be used.

REQ.  ARv14-12: uses TCP as an example, as does REQ.  ARv14-13, but REQ.  ARv14-28: makes TCP a MUST.

I am not clear why a connection oriented transport protocol is REQUIRED for either the ALTO enquiry protocol or the user data transport protocol.

I am further unclear why a particular transport protocol is required (TCP is named).

I would have expected that at least SCCP would have been permitted, but I can also see a case to be made for any existing or new transport protocol to be allowed.

[Ballot discuss]
1. In his Apps Directorate review , Ted Hardie expressed concerns that some privacy issues are not properly addressed by this document. I agree, and these issues were not addressed in the latest revisions to the document. As he notes in particular:

- I do not equate "disclosure of application behavior" to "disclosure of privacy sensitive user data", and I do not think the document is clear enough on this point.

- Disclosure of aggregated data about queries is not addressed.

2. I am not clear on the desirability of publishing this document at all. As is apparent from the discussion of Ted's review, there are places where the requirements document did not keep up with the actual completed protocol spec. (See discussion of ARv11-23 and ARv11-24.) That's fine, but it does make one question why this is being published once the spec is finished. Is there an expectation that future specs are going to have to rely on this document? As Enrico's response to Ted's review makes clear:

  All in all, the document has been extremely useful, basically
  replacing the issue tracker tool the WG -- despite trying quite hard
  -- has never found a way to use effectively. The document has proved
  to be extremely useful in archival sense of recording and tracking
  the evolution of the ALTO protocol as it progressed in the WG and as
  new capabilities, actions and use cases were raised.

If the issue tracker had been used instead of this document, there would be nothing to publish, and AFAICT, that would have been fine. Instead of fighting with this document to make it agree with the spec and cover cases that have been overtaken by events, why not drop it?

I'm especially curious about the note in the shepherd report:

  (1.e) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with it?

  Strong consensus for publishing.

Was there strong consensus for publishing because people thought this document would be of importance for people to read in the future in order to base work on it, or did people simply think that, "We've put so much work into this, we think it should be published."? I don't see a need to publish, and I'd like to hear some justification to do so.

[Ballot discuss]
1. In his Apps Directorate review , Ted Hardie expressed concerns that some privacy issues are not properly addressed by this document. I agree, and these issues were not addressed in the latest revisions to the document. As he notes in particular:

- I do not equate "disclosure of application behavior" to "disclosure of privacy sensitive user data", and I do not think the document is clear enough on this point.

- Disclosure of aggregated data about queries is not addressed.

2. I am not clear on the desirability of publishing this document at all. As is apparent from the discussion of Ted's review, there are places where the requirements document did not keep up with the actual spec that got published. (See discussion of ARv11-23 and ARv11-24.) That's fine, but it does make one question why this is being published once the spec is out. Is there an expectation that future specs are going to have to rely on this document? As Enrico's response to Ted's review makes clear:

  All in all, the document has been extremely useful, basically
  replacing the issue tracker tool the WG -- despite trying quite hard
  -- has never found a way to use effectively. The document has proved
  to be extremely useful in archival sense of recording and tracking
  the evolution of the ALTO protocol as it progressed in the WG and as
  new capabilities, actions and use cases were raised.

If the issue tracker had been used instead of this document, there would be nothing to publish, and AFAICT, that would have been fine. Instead of fighting with this document to make it agree with the spec and cover cases that have been overtaken by events, why not drop it?

I'm especially curious about the note in the shepherd report:

  (1.e) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with it?

  Strong consensus for publishing.

Was there strong consensus for publishing because people thought this document would be of importance for people to read in the future in order to base work on it, or did people simply think that, "We've put so much work into this, we think it should be published."? I don't see a need to publish, and I'd like to hear some justification to do so.

[Ballot discuss]

I'm 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. (And as a
side-issue, maybe s/should/SHOULD/ above.)

[Ballot comment]

Its surprising that most of the text in section 5 is
about protecting the operator's interests. If that's
just because the user's interests are taken as
given, that might not be a good plan, since people
might point back at this document and draw some
conclusions from the relative amounts of text.

[Ballot discuss]
Looking at Adrian's feedback on this draft, I support his DISCUSS:
    Section 3.1 needs to discuss manageability requirements for the new
    protocol(s). RFC 5706 may give you some guidance.

And as OPS A.D., I would like to carefully double-check this.
Hence this new DISCUSS position... on the top of the having some COMMENTS (the ones mentioned "Substantive suggestions; please adopt or respond to these:") that could potentially be DISCUSS

[Ballot discuss]
In general I support this document, but I have a number of points that
need to be looked at before publication. A couple of them are
significant enough to merit points in this Discuss. The rest would not
normally result in a Discuss, but I do feel that the volume of issues
and the large number of Comments from other ADs suggest the need to
carefully revise the whole document.

---

Section 3.1 needs to discuss manageability requirements for the new
protocol(s). RFC 5706 may give you some guidance.

---

REQ.  ARv14-28

Two issues here:
1. This is a very solutions-oriented requirement. Shouldn't you actually
  state the functional requirements that would lead a protocol designer
  to either re-invent many of the features of TCP or t specify the use
  of TCP?
2. Whatever happened to SCTP?

---

3.2 does not appear to support an alto client being configured with the
location of one or more alto servers. Shouldn't you allow that? That
would seem to mean that it is not a requirement that every alto client
be able to use discovery.

But, in any case, REQ.  ARv14-35 seems to be about implementation, not
about protocol design.

[Ballot comment]
Although not part of the Discuss, I would strongly recommend that you
work through these Comments before publication.

---

I think you need to be really careful in your use of the word
"resource". It is very clear from the first sentence of the Abstract
what you mean by resource andthis is important in interpretation of the
whole problem space. Unfortunately, the last sentence of the first
paragraph of the Abstract muddies the waters by also using the word
with less precision.

The problem surfaces in the body of the text as well.

I think you might do well to talk about "application resources" and
"network infrastructure resources" and include clear definitions early
in the document (probably Section 1; i.e., before the terminology
section).

---

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.

Something wrong. problem with parentheses?

---

REQ.  ARv14-1

A little surprised that the requirement is only that the client and
server must each implement *an* alto client protocol. Wouldn't it be
helpful if they implemented the same protocol? Maybe a forward pointer
to section 3.2?

---

REQ.  AR14-6 and 14-7

I don't understand how all host group descriptors can easily be mapped
to one or a set of IP addresses. You have cited as an example in the
terminology section's definition of host group descriptor that such a
description may be an AS. While it is nominally possible to map an AS
to a set of IP addresses, it is not necessarily very clean.

However, I read the definition as meaning that there are some additional
qualifiers to a host group that may be useful. Thus a host group may be
described by an IP prefix *and* an AS to give additional information
that is more helpful than just the IP prefix.

---

REQ.  ARv14-20

Should this requirement make clear that separate instances of alto
servers are not required to generate the same results? Or, conversely,
if you want to surprise me by saying this is a requirement, you will
need to state it in the document.

---

REQ.  ARv14-24

I am uneasy about the mother-knows-best nature of the control of re-use
in this requirement. Why is it not possible to state the issues with the
supplied response data and allow the client to decide whether it wants
to re-use the response or not? In practice, the fact that a response is
marked "no re-use should occur" is not compelling to a client. But
marking the response "this data is only valid for the requesting client
for 38 seconds" is likely to suggest to the client that redistribution
is pointless.

---

REQ.  ARv14-25

Can the alto server be behind a NAT?                                   

---

Section 3.1.6 is all about leveraging "mechanisms provided by underlying
protocol layers". Surely, that is just one of the congestion indicators
at an alto server. What about queues at the message layer? What about
CPU load?

In fact, this section could be easily rewritten to say that:

The protocol MUST allow a server that experiences or is aware of
congestion in the network, in processing of alto messages, or in its
overall processing load to report any of the following advice through an
alto response:
...

---

Shouldn't section 3.2 also require disclosure of server capabilities?
And isn't there a meta-alto point here that the discovery should use
exactly the same Rating Criteria and Host Characteristic Attributes as
defined in the altoclient protocol?

---

Section 3.3

Given the security requirements described here, shouldn't there also be
security for the discovery mechanism?

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup.
I reviewed -13-
It appears to me that comments from Bert Wijnen and Ted Hardie have not been addressed adequately.

1) I share the concerns about interoperability that Bert raised. I understand the protocol document specifies one mandatory to implement mode, but if two implementations are allowed to use different protocols, and one protocol mandates target-independent-query mode, and the other protocol mandates target-aware-query mode, these implementations will not interoperate.

2) I agree RFC5693 should be normative.

3) I think the discussion of user privacy is not adequate. The text that has been added is ambiguous; I cannot tell whether you are saying that "user privacy should not be a problem" in the sense that this is RECOMMENDED in a protocol design, or that user information CANNOT be correlated for some unstated reason. If this is saying that it CANNOT be done, I think an explanation of why it CANNOT be done is needed. If it is a RECOMMENDATION, then I think it should be documented as a REQ-13-xx with a fuller explanation that currently provided.

4) You didn't address Ted's comments about ARv11-8 or ARv11-12 (and I stopped checking the rest, assuming you simply chose not to address Ted's comments. Please address Ted's comments.

State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
Last Call comments from Ted Hardie and bert Wijnen should be addressed in the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Application-Layer Traffic Optimization (ALTO) Requirements) to Informational RFC


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'Application-Layer Traffic Optimization (ALTO) Requirements'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many Internet applications are used to access resources, such as
  pieces of information or server processes, which are available in
  several equivalent replicas on different hosts.  This includes, but
  is not limited to, peer-to-peer file sharing applications.  The goal
  of Application-Layer Traffic Optimization (ALTO) is to provide
  guidance to applications, which have to select one or several hosts
  from a set of candidates capable of providing a desired resource.
  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.

  This document enumerates requirements for specifying, assessing, or
  comparing protocols and implementations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-alto-reqs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-alto-reqs/


No IPR declarations have been submitted directly on this I-D.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Application-Layer Traffic Optimization (ALTO) Requirements) to Informational RFC


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'Application-Layer Traffic Optimization (ALTO) Requirements'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many Internet applications are used to access resources, such as
  pieces of information or server processes, which are available in
  several equivalent replicas on different hosts.  This includes, but
  is not limited to, peer-to-peer file sharing applications.  The goal
  of Application-Layer Traffic Optimization (ALTO) is to provide
  guidance to applications, which have to select one or several hosts
  from a set of candidates capable of providing a desired resource.
  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.

  This document enumerates requirements for specifying, assessing, or
  comparing protocols and implementations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-alto-reqs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-alto-reqs/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review of draft-ietf-alto-reqs

draft-ietf-alto-reqs-11

1) in abstract, s/candidates, that/candidates that/

2) in 1, the text describing how ALTO might be useful for other applications should not be the first thing discussed. You should discuss what it does and how P2P would find it useful before discussing that other applications could find it useful.

3) in 1, the first sentence points to another application to see the motivation (without summarizing that motivation), and then states the goals (aren't these similar to the motivation?).

4) in 1, [the goal is to "improve performance (or Quality of Experience)"; I recommend taking the Quality of Experience out of parentheses. Using parentheses makes it appear you treat these as being equivalent, but they are distinctly different measures. Both appear to be valid goals for informed decisions.

5) Let me provide some general editing advice (already also provided by the RFC Editor) - use of passive voice frequently makes sentences ambiguous, and in standards it is really important to know whose responsibility it is to take a specific action (such as enforcing a rule of the specification). In 1, you are using passive voice, and your writing could be much more concise and easier to follow if you used active voice. Your writing could also be more concise if you limited your use of pronouns, such as "it", "they", etc. For example,
OLD:
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.
NEW:
Application entities can have difficulty acquiring this information by other mechanisms (e.g., using measurements between the peers of a P2P overlay), because network providers might not want to disclose the details of network topology, network operational costs, or network policies.

6) in 1, "They may be placed" - They is ambiguous; it could be "the logical entities" or it could be "the functions for relaying"

7) in 2.2, I find the distinctions difficult to understand. Why, for example, is a single IP address a Host Group Descriptor rather than a Host Characteristic Attribute? An attribute is "in particular related to its attachment to the network"; well. this certainly would seem to include a Host's IP address. I think these definitions need greater clarity. It might be sufficient to provide a meaningful exampe of how this gets used.
8) in 2.3, there is discussion of the ALTO WG and its charter. This document should long outlive any WG or charter. Therefore, this is not really the right place to discuss charters and WGs. It would be better to simply state that there are expected to be certain components within an architecture, and protoocls that are used between components. I recommend utilizing a consistent terminology for this. in 2.3, you talk about there are components, and then there are protocol interactions between elements. Is an element that same thing as a component? This inconsistent use of terminology creates ambiguities that are bad for standards work.
9) in 2.3, "This document itemizes requirements for the following components and information elements that are part of the above-mentioned architecture: " Neither component nor element are defined in the terminology section.
10) The "above-mentioned" says explicitly it is NOT defining a specific architecture; so how can these components and information elements be part of that above-mentioned architecture?
11) I think it is really important to make a distinction between a documentation architecture and an implementation architecture. You ARE specifying an architecture comprised of components, protocols, and information elements. Implementations are not required to IMPLEMENT the architecture used in the documentation. The acrhitecture used in the documentation should favor clarity of specification; the architecture used in implementation might favor performance.
12) in 2.3, "Host group descriptors, which are used to describe the location of a host in the network topology" seems sliughtly different than the definition in 2.2.
13) in 3, I think the document editor, not the RFC Editor, should take responsibility for removing the "v11" tags from the requirements.
14) I question whether 3.1.1 adds anything to this document. Should we also add that an ALTO protocol must be able to work over a network?
15) in 3.1.2, and throughout the document, it is important to use "which" and "that" to prevent ambiguity. This is a style issue, but it has a big impact on ambiguity of a specification. "That" is the defining or restrictive pronoun, whereas "which" is non-restrictive. From Strunk and White's Elements of Style:
"The lawnmower that is broken is in the garage" indicates the speciifc lawnmower being considered.
"The lawnmower, which is broken, is in the garage" indicates an extra fact relating to the lawnmower.
In addition, using commas to separate the which can make it unclear what the phrase refers to.
16) ARv11-5: An ALTO client protocol MUST support the host group descriptor types "IPv4 address prefix" and "IPv6 address prefix".
Using "the" in "the host group descriptor types" implies this is already defined someplace. If so, please provide a referenece. However, I think you should be specifying requirements without reference to specific solutions, so this might be better leaving out the "the":
17) An ALTO client protocol MUST support host group descriptor types for "IPv4 address prefix" and "IPv6 address prefix".
There hasn't been any discussion of there being host group descriptor **types**. Should ther be a requirement that states that the client protocol must support different **types** of host group descriptors? And how would **types** be defined? That is not included in section 2. Before useing "type" in the requirements, you need to identify what a "type" means.
18) ARv11-8 says "type identification MUST be supplemented by a reference to a facility"; I have no idea what a facility is, and section 2 doesn't mention anything about facilities. Therefore, i would have no idea how to reference such a facility. Facility can mena many difefrent things; see http://dictionary.reference.com/browse/facility. So should I provide a street address for my facility?
19) *** I think that part of the problem in this document, is your requirements are not in a logical order. It appears to me that if R7 preceded R5, things would be clearer.
20) ARv11-10 - the use of ", which ...," makes this sentence not parse correctly. If I remove the phrase that is separated by commas (which implies it contains extra non-restrictive information) I end up with "An ALTO client protocol specification MUST define mechanisms or that the indicated mapping mechanism could not be used." This senetence would be better written as "An ALTO client protocol specification MUST define mechanisms that can be used by the ALTO client to indicate that a host group descriptor used by the ALTO server is of an unsupported type or that the indicated mapping mechanism could not be used."
21) Another style issue that is relevant - you use quite a few parenthetical phrases. Many of the users of these documents are not native English speakers. These parenthetical asides are distracting, and can make it unnecessarily difficult for non native speakers to grasp the important part of the sentence. If the information is important to understand the specification, then take it out of the parentheses. If needed for clarity, put it into a separate sentence. If it is not important, get rid of it.
22) ARv11-14  it is fine to include discussion of the requirement not being suitable as a replacement for TCP-like congestion control, but please remove the discussion of the charter and non-goals of the WG.
23) I don't understand what "whose primary aim" refers to. Its placement in the sentence seems to imply that "whose" refers to "instantaneous network congestion state", but it doesn't make snese to me that "the primary aim of instantaneous network congestion state is to serve an alternative to established congestion control strategies".
24) ARv11-15. I don't understand why applications using ALTO guidance MUST NOT use the guidance to avoid causing network congestion. The Transport Area is deliberately developing a number of technologies, such as decade and PCN, that an application can use to pro-actively avoid causing network congestion. If this information, such as the location of decade servers near the destination, were included in ALTO information, why is an application prohibited from using that information? There may be valid reasons for prohibiting this, and applications could certainly get things wrng if they applied ALTO inofrmation in a mannert that coiflicted with underlying physical network optimization, but this requirement doesn't explain why this is a MUST NOT. I think this should be reworded to better explain the problematic usage that must be avoided.
25) ARv11-16 "which rating criteria should be considered" is pretty nebulous. This relates to the use of passive veruss active voice. WHO should consider which rating criteria? Do you mean "which rating criteria the server should report in the response message"? or do you mean "which rating criteria the server should utilize in formulae for calculating a relative preference"? I'm not sure who is supposed to consider these hints contained in the query message, or how that translates into protocol design.
26) I think ARv11-11 and ARv11-18 are very similar. I am not sure when each is used. I assume -11 can be included in a response to a query requesting a particular type of mechaism. But in what protocol interaction is -18 used? Is there somehow a multi-stage handshake between client and server? Or is this somethign that a client can specify in a query "I don't support mechanism X, so don't bother sending mechanism X information"?
27) ARv11-22 (or is ti a preamble for -23?), where is "target-aware query mode” defined? please provide a reference. Ditto target-independent. This might be better moved to Terminology, so -23 can use the terms.
28) “With respect to the timing of ALTO queries, several modes of operation exist:” There are only two modes defined here. What are the others?
29) ARv11-23 “at least one of these two modes”. So there are only two modes desacribed. If I implemented and didn’t support at least one of the two modes, what would I actually have? How could I NOT implement at least one of these? If that is nto possible to do (and still have some type of fucntioning client), why specify it? Without more than two, it feels like this: “There can be two parts of a day - daytime and nighttime; a client must support at least one of the two.” Well, yeah!!! because there isn’t anyway to implement that doesn’t support “at least one” of those binary choices.
30) ARv11-48 you cannot realistically use MUST NOT when talking about an operator. You really can only say that an operator should be aware that the protocol cannot prevent the abuse/disclosure of information.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Enrico Marocco is the document shepherd. I have personally reviewed
this version of the document, and it is ready for forwarding to the
IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had reviews by key WG members, as well as by members
of WGs that are considering the work of the alto WG as the basis for
their standardization work (esp. decade and cdni WGs). It has been
intetionally kept alive, refined and reviewed in several iterations,
for quite a long time to track new requirements during the early phase
of the specification work. Since the specs are now generally
considered mature, the WG has expressed consensus to move it toward
publication.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Strong consensus for publishing.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Checked with ID nits 2.12.12: no issues nor nits found.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative, with the
former only consisting of 2119.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document raises no actions for the IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is no formal language in the document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This is a procedural document, listing requirements for the protocol
the ALTO WG is chartered to standardize. The abstract of the draft
provides an accurate summary:

Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications, which have to select one or several hosts
from a set of candidates, that are able to provide a desired
resource. 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.

This document enumerates requirements for specifying, assessing, or
comparing protocols and implementations.

Working Group Summary

This document lists the requirements the protocol the ALTO WG is
chartered to standardize has to satisfy.

Document Quality

The document has received extended review by WG members, as well as by
contributors of other WGs (esp. decade and cdni) that are considering
the ALTO protocol as the basis for their specification work.