Skip to main content

Application-Layer Traffic Optimization (ALTO) Protocol
draft-ietf-alto-protocol-27

Revision differences

Document history

Date Rev. By Action
2014-08-26
27 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-06-17
27 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-06-09
27 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-05-23
27 Martin Thomson Request for Last Call review by GENART Completed: Not Ready. Reviewer: Martin Thomson.
2014-03-20
27 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-03-19
27 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-03-18
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-03-18
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-03-07
27 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-03-07
27 (System) RFC Editor state changed to EDIT
2014-03-07
27 (System) Announcement was received by RFC Editor
2014-03-06
27 (System) IANA Action state changed to In Progress
2014-03-06
27 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-03-06
27 Cindy Morgan IESG has approved the document
2014-03-06
27 Cindy Morgan Closed "Approve" ballot
2014-03-06
27 Cindy Morgan Ballot approval text was generated
2014-03-06
27 Cindy Morgan Ballot writeup was changed
2014-03-05
27 Y. Richard Yang IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-03-05
27 Y. Richard Yang New version available: draft-ietf-alto-protocol-27.txt
2014-02-20
26 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation - Defer
2014-02-20
26 Cindy Morgan [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel by Cindy Morgan
2014-02-20
26 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-02-20
26 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2014-02-19
26 Pete Resnick
[Ballot comment]
I'd like to hear your response to Barry on his worry about a conflict between 1.1 and 8.3.2. I don't really see the …
[Ballot comment]
I'd like to hear your response to Barry on his worry about a conflict between 1.1 and 8.3.2. I don't really see the conflict; just because a client can ask particular questions and get particular answers, or that some of the data in the answers is dynamic, doesn't make the information any less "published". I might agree that "unidirectional" is a strange term to use, but it is certainly "read-only".

Throughout the document: I'm not a big fan of the "we" language. I think it makes it sounds like an academic paper rather than a protocol spec. I prefer "this document" or "this protocol".

6.1.2:

  An ALTO Client SHOULD be cognizant of operations when a
  desired Cost Mode is not supported.

I don't know what an implementer is supposed to do with that sentence. There's nothing actionable there. What I think you mean is, "An ALTO Client MUST be able to support either mode." If that's not what you mean, then I don't know what is intended here.
 
6.1.2.2:

  It is important to note that the values in the Cost Map provided with
  the ordinal Cost Mode are not necessarily the actual costs known to
  the ALTO Server.

I ask this seriously: Why is it important to note that? And who exactly should note that? Are you trying to tell server implementers that they MAY produce values in the Cost Map based on things other than their internal cost metrics? Or are you telling client implementers that the Cost Map may not be completely representational of...something? I don't know what that sentence means or what it's import is.

8.3.3:

  ...the ALTO Server MAY provide...or return an ALTO error object...

That's a strange use of MAY. Giving the answer or giving an error don't seem like "options" in the traditional sense. I'd just say, "...the ALTO Server either provides...or returns an ALTO error object..."

8.3.6: s/MAY/can There's no protocol option being described here.

10.1 (and elsewhere in the document): If you want to be precise, you might change "alphanumeric characters" to "US-ASCII alphanumeric characters".

10.3: I don't think "and 'tag' is a case-sensitive string" adds anything, and in fact it might be confusing. You don't talk about case-sensitivity anywhere in the document, and the below paragraph already talks about "byte-for-byte equal". How about simply, "and tag is is an identifier string, as described in section 6.3".

11.5.1: "It is important to note..." It seems to me that this paragraph is simply saying, "How an ALTO Server calculates costs between individual endpoints is implementation dependent. For example, an ALTO Server could simply use the cost between the PIDs corresponding to the endpoints." I suggest that replacement.
2014-02-19
26 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-02-18
26 Stephen Farrell
[Ballot comment]

Thanks for sorting my discuss points.

I'm not that keen on the "same trust domain" term in 12.3
to be honest. That is …
[Ballot comment]

Thanks for sorting my discuss points.

I'm not that keen on the "same trust domain" term in 12.3
to be honest. That is not something a client programmer
can check, and is also pretty weasel-wordy. I'd suggest
changing that to saying "deployed by the same entity"
or something.

---- OLD COMMENTS BELOW, not sure if they've been
handled.

- 2.2: How is a phone number an endpoint address?  Its not
really that good an idea to have not entirely obvious jokes.

- 3.2: I'm surprised that expiry isn't specified, or do you
mean ALTO depends on HTTP cache controls alone? (For
signatures, I can buy you want to wait for JOSE.)

- 8.3.7 is puzzling, is it a corollary that an ALTO server
MUST NOT set cookies? Good if so, maybe make that explicit
though?

- 12.3 - I agree with Joel's discuss.

- 15 - all environments and use-cases require consideration
about attacks, its just easier for some.
2014-02-18
26 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2014-02-18
26 Cindy Morgan New revision available
2014-02-17
25 Barry Leiba
[Ballot comment]
Nothing blocking here, just comments... but please consider them, and I'd appreciate a chat about the last one.

-- Section 1.1 --

  …
[Ballot comment]
Nothing blocking here, just comments... but please consider them, and I'd appreciate a chat about the last one.

-- Section 1.1 --

  At a high level, the ALTO Protocol specified in this document is a
  unidirectional interface that allows a network to publish its network
  information such as network locations, costs between them at
  configurable granularities, and endhost properties to network
  applications.  The information published by the ALTO Protocol should
  benefit both the network and the applications (i.e., the consumers of
  the information).  Either the operator of the network or a third-
  party (e.g., an information aggregator) can retrieve or derive
  related information of the network and publish it using the ALTO
  Protocol.  When a network provides information through the ALTO
  Protocol, we say that the network provides the ALTO Service.

But in Section 8.3.2, we have this:

  Where possible, the ALTO Protocol uses the HTTP GET method to request
  resources.  However, some ALTO services provide Information Resources
  that are the function of one or more input parameters.  Input
  parameters are encoded in the HTTP request's entity body, and the
  ALTO Client MUST use the HTTP POST method to send the parameters.

That says to me that this isn't unidirectional, and that it's not a question of "publishing" network information.  The client is actively querying, asking for specific information, sometimes using input parameters to pass query information to the server... and the server is responding to a specific query, not publishing common information -- the response will be different for different queries, and perhaps for the same query sent by different clients.

If I'm right, that's very different from publishing information, and it has very different security, privacy, and integrity properties.  A lot of information can be gleaned from specific queries a client might make and parameters it might use, especially when information is aggregated from many queries over time.

You do talk about risks to the client in Section 15.4.1, so I think the only issue here is that Section 1.1 is misleading.  Perhaps a bit of rephrasing will help?

-- Section 10.6 --

  Identifiers prefixed with 'priv:' are reserved for Private Use
  [RFC5226].  Identifiers prefixed with 'exp:' are reserved for
  Experimental use.  For an identifier with the 'priv:' or 'exp:'
  prefix, an additional string (e.g., company identifier or random
  string) MUST follow to reduce potential collisions.  For example, a
  short string after 'exp:' to indicate the starting time of a specific
  experiment is recommended.  All other identifiers that appear in an
  HTTP request or response with an 'application/alto-*' media type and
  indicate Cost Metrics MUST be registered in the ALTO Cost Metrics
  registry Section 14.2.

These aren't really "reserved"; the idea is that anyone can freely use such identifiers without worrying about registration?  This needs to be clear both to IANA and to implementors.  I'm also not sure how to interpret the "MUST" here.  The example gives a good clue, but... suppose Apple wants to use a private identifier.  Should that be "priv:apple:myid", "priv:apple-myid", "priv:apple_myid", "priv:applemyid", any of the above?  All "an additional string MUST follow" tells me is that I can't just use "priv:"... but "priv:x" would satisfy the MUST.  Is that sufficiently specified for you?

Similar comment for 10.8.2.

-- Section 14.2 --

  Identifiers prefixed with 'priv:' are reserved for Private Use.
  Identifiers prefixed with 'exp:' are reserved for Experimental use.

Related to the comment above, this should refer to Section 10.6 for more information.  You have a reference to 10.6 right before this, but I don't think it's enough to draw the eye there for this.  Maybe, "As specified in Section 10.6, indentifiers prefixed with 'priv:' are for Private Use, and identifiers prefixed with 'exp:' are for Experimental use."

-- Section 14.3 --

  The maintenance of this registry is similar to that of the preceding
  ALTO Cost Metrics.

I'd feel lots better if you explicitly pointed to Section 10.8.2 here.  Maybe, "The maintenance of this registry is similar to that of the preceding ALTO Cost Metrics, subject to the description in Section 10.8.2."

-- Sections 14.2, 14.3, 14.4, 14.5 --

All the new registries use IETF Review as their policy.  They do give a reason for that (thanks!), and I accept that reason.  I just have one question: is there really no desire for a provision for other SDOs, such as W3C, to create new entries?  Is the desire really for them to go through the IETF in the event that they want to do that?  You're probably fine here, but because this sort of requirement often paints us into a corner, I wanted to double check (or triple, or...).
2014-02-17
25 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-02-14
25 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2014-02-14
25 Joel Jaeggli
[Ballot comment]
was discuss

I can live with the proposed text that came out of the discussion. in any event I said I would do …
[Ballot comment]
was discuss

I can live with the proposed text that came out of the discussion. in any event I said I would do this.

formerly:
so I raised this issue during the LC,  and I'm I'm pretty sure I will clear
without changes but I wanted to discuss it.

section 12.3 has some pretty dire consequences in terms of the potential for
abuse  on the form of inadvertent disclosure or malicious (from the vantage
point of the client) traffic engineering. while the document deals with those
why/recommend/include it at all? The only cases where I would consider it
appropriate are where the alto server and either the client or server endpoints
are under a single administrative span of control.
2014-02-14
25 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to Abstain from Discuss
2014-02-07
25 Jari Arkko
[Ballot comment]
The discussion about the Gen-ART review identified US-ASCII vs. UTF-8 string as a potential issue, and I agree. I can see that there …
[Ballot comment]
The discussion about the Gen-ART review identified US-ASCII vs. UTF-8 string as a potential issue, and I agree. I can see that there was agreement on e-mail that a change shall be made. Expecting a new version to make the change.
2014-02-07
25 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2014-02-06
25 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Jürgen Schönwälder.
2014-02-06
25 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins.
2014-02-05
25 Richard Barnes
[Ballot discuss]
The "endpoint property service" seems like an attractive nuisance.  On the one hand, it doesn't really provide anything that you don't get from …
[Ballot discuss]
The "endpoint property service" seems like an attractive nuisance.  On the one hand, it doesn't really provide anything that you don't get from the network map, so it's not clear why I would want this rather than just fetching the whole map (especially since the map isn't that huge).  On the other hand, it seems to create a huge privacy risk, providing ISPs a hole they can drive truckloads of user data through.  If there's not a compelling use case for this feature, can we eliminate it?  If it stays in, please add some text discussing privacy considerations around this service.
2014-02-05
25 Richard Barnes
[Ballot comment]
Section 7.1.1. doesn't seem like it says what it means; it seems like a network map contains multiple PIDs.

Section 7.1.1 would be …
[Ballot comment]
Section 7.1.1. doesn't seem like it says what it means; it seems like a network map contains multiple PIDs.

Section 7.1.1 would be more helpful if it said explicitly that the "pid" attribute is the PID for the endpoint in question.
2014-02-05
25 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2014-02-05
25 Barry Leiba Telechat date has been changed to 2014-02-20 from 2014-02-06
2014-02-05
25 Barry Leiba IESG state changed to IESG Evaluation - Defer from Waiting for AD Go-Ahead
2014-02-05
25 Jari Arkko
[Ballot discuss]
Thank you for this important and well-written document. I am happy to recommend the approval soon, but before that I just wanted to …
[Ballot discuss]
Thank you for this important and well-written document. I am happy to recommend the approval soon, but before that I just wanted to ensure that something we already discussed earlier gets incorporated in a new draft version.

The discussion about the Gen-ART review identified US-ASCII vs. UTF-8 string as a potential issue, and I agree. I can see that there was agreement on e-mail that a change shall be made. Expecting a new version to make the change.
2014-02-05
25 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko
2014-02-05
25 Stewart Bryant
[Ballot comment]
"The maintenance of this registry is similar to that of the preceding
ALTO Cost Metrics."

You should be guided by IANA, but I …
[Ballot comment]
"The maintenance of this registry is similar to that of the preceding
ALTO Cost Metrics."

You should be guided by IANA, but I think it would be better to
explicitly state the registration policy.
2014-02-05
25 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2014-02-04
25 Benoît Claise
[Ballot comment]
From Jürgen, part of his OPS DIR review:

I enjoyed reading a very clear and well written document. As usual, I
appreciate the …
[Ballot comment]
From Jürgen, part of his OPS DIR review:

I enjoyed reading a very clear and well written document. As usual, I
appreciate the "Manageability Considerations" section, which provides
useful guidance.

For the monitoring part (16.1.4.), the document refers to
[I-D.ietf-alto-deployments]. While this I-D provides more discussion,
it still leaves it somewhat open how to effectively monitor the impact
ALTO has on the traffic. It seems difficult to me, within an ISP
network, to separate flows that are influences by an ALTO server from
other flows. The assumption that ALTO-enabled applications provide
that information back to an ISP running ALTO servers sounds a bit
idealistic to me. I also believe it is useful to distinguish
'measurement' from 'monitoring'. One likes to measure the impact an
ALTO server has on the traffic mix and one monitors the ALTO servers
whether they provides say function properly and achieve acceptable
response times.

Section 16.2.3. says "Monitoring ALTO Servers and Clients is described
in [I-D.ietf-alto-deployments]". Appendix A of this I-D talks about
monitoring (actually measuring) the effects of ALTO, but it does not
really talk about monitoring of ALTO servers or clients (e.g., is my
ALTO server getting overloaded?). Yes, some of this overlaps with
16.2.5 - perhaps provide a pointer.

Overall, I once again like to thank the authors for a very well
written document.

Editorial nits:

- p12: s/a defined groupings/defined groupings/

- p24: s/InforResourceDirectory/InfoResourceDirectory/

- p27: s/a the Retry-After/the Retry-After/

- p81: s/from a ALTO/from ALTO/

- p81: "The following is a list of suggested ALTO-specific to be
  monitored [...]" Missing noun?

- p86: s/are the rule/are the rules/
2014-02-04
25 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-02-04
25 Stephen Farrell
[Ballot comment]

- 2.2: How is a phone number an endpoint address?  Its not
really that good an idea to have not entirely obvious jokes. …
[Ballot comment]

- 2.2: How is a phone number an endpoint address?  Its not
really that good an idea to have not entirely obvious jokes.

- 3.2: I'm surprised that expiry isn't specified, or do you
mean ALTO depends on HTTP cache controls alone? (For
signatures, I can buy you want to wait for JOSE.)

- 8.3.7 is puzzling, is it a corollary that an ALTO server
MUST NOT set cookies? Good if so, maybe make that explicit
though?

- 12.3 - I agree with Joel's discuss.

- 15 - all environments and use-cases require consideration
about attacks, its just easier for some.
2014-02-04
25 Stephen Farrell Ballot comment text updated for Stephen Farrell
2014-02-04
25 Stephen Farrell
[Ballot discuss]

Two easily sorted discuss points I hope:

(1) 8.3.5 - is TLS mandatory to implement (MTI) or not? If
yes, that's fine but …
[Ballot discuss]

Two easily sorted discuss points I hope:

(1) 8.3.5 - is TLS mandatory to implement (MTI) or not? If
yes, that's fine but you could say it clearly. If not, why
not?  Saying "When  server MUST support TLS" just
seems broken and "may not be needed" also implies not MTI. I
think a plain "Servers MUST support TLS" is what you want.
Calling it SSL is ancient and wrong - 5246 does not specify
SSL. 15.1.8 makes the same mistake saying "TLS MUST be
supported when " which is just not clear.

(2) 15.4.2 - I think the weak recommendation to send a shorter
prefix (and adding in a random or zero low order set of
address bits) would be better as a SHOULD that's done
routinely, with e.g. the full /32 only sent exceptionally.
What'd be wrong with that? (Maybe it'd be dumb for some
reason, in which case you'll tell me, I'l be embarrassed and
then I'll clear;-) That could apply to every address emitted
by a client I guess - why not? And that might sort Joel's
discuss nicely (assuming it was actually done).
2014-02-04
25 Stephen Farrell
[Ballot comment]

- 2.2: How is a phone number an endpoint address?  Its not
really that good an idea to have not entire
ly obvious …
[Ballot comment]

- 2.2: How is a phone number an endpoint address?  Its not
really that good an idea to have not entire
ly obvious jokes.

- 3.2: I'm surprised that expiry isn't specified, or do you
mean ALTO depends on HTTP cache controls alone? (For
signatures, I can buy you want to wait for JOSE.)

- 8.3.7 is puzzling, is it a corollary that an ALTO server
MUST NOT set cookies? Good if so, maybe make that explicit
though?

- 12.3 - I agree with Joel's discuss.

- 15 - all environments and use-cases require consideration
about attacks, its just easier for some.
2014-02-04
25 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2014-02-04
25 Joel Jaeggli
[Ballot discuss]
so I raised this issue during the LC,  and I'm I'm pretty sure I will clear without changes but I wanted to discuss …
[Ballot discuss]
so I raised this issue during the LC,  and I'm I'm pretty sure I will clear without changes but I wanted to discuss it.

section 12.3 has some pretty dire consequences in terms of the potential for abuse  on the form of inadvertent disclosure or malicious (from the vantage point of the client) traffic engineering. while the document deals with those why/recommend/include it at all? The only cases where I would consider it appropriate are where the alto server and either the client or server endpoints are under a single administrative span of control.
2014-02-04
25 Joel Jaeggli [Ballot Position Update] New position, Discuss, has been recorded for Joel Jaeggli
2014-02-04
25 (System) IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed
2014-02-04
25 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-02-04
25 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-alto-protocol-25.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-alto-protocol-25.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has one question:

Should the new registries be created at an existing URL, or a new one?

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

First, this document will add ten media types to the applications media type registry at

http://www.iana.org/assignments/media-types

The two media types to be added are:

alto-directory+json
alto-networkmap+json
alto-networkmapfilter+json
alto-costmap+json
alto-costmapfilter+json
alto-endpointprop+json
alto-endpointpropparams+json
alto-endpointcost+json
alto-endpointcostparams+json
alto-error+json

IANA understands that expert review is not required.

Second, IANA will create a new registry called the ALTO Cost Metric Registry, to be maintained via IETF Review as defined in RFC 5226.

These are the initial registrations:

Identifier  Intended Semantics                          Reference
------------+-------------------------------------------+--------------
routingcost  See section 6.1.1.1 of [ RFC-to-be ]        [ RFC-to-be ]
priv:        Private use                                [ RFC-to-be ]
exp:        Experimental use                            [ RFC-to-be ]

Third,  IANA will create a new registry called ALTO Endpoint Property Types, to be maintained via IETF Review as defined in RFC 5226.

These are the initial registrations:

Identifier  Intended Semantics                          Reference
------------+-------------------------------------------+--------------
pid          See section 7.1.1 of [ RFC-to-be ]          [ RFC-to-be ]
priv:        Private use                                [ RFC-to-be ]
exp:        Experimental use                            [ RFC-to-be ]

Fourth,  IANA will create a new registry called ALTO Address Types, to be maintained via IETF Review as defined in RFC 5226.

These are the initial registrations:

Identifier: ipv4
Address Encoding: See section 10.4.3 of [ RFC-to-be ]
Prefix Encoding: See section 10.4.4 of [ RFC-to-be ]
Mapping to/from IPv4/IPv6: Direct mapping to IPv4
Reference: [ RFC-to-be ]

Identifier: ipv6
Address Encoding: See section 10.4.3 of [ RFC-to-be ]
Prefix Encoding: See section 10.4.4 of [ RFC-to-be ]
Mapping to/from IPv4/IPv6: Direct mapping to IPv6
Reference: [ RFC-to-be ]

Fifth, IANA will create a new registry called ALTO Error Codes,  to be maintained via IETF Review as defined in RFC 5226.

These are the initial registrations:

ALTO Error Code          Description                                      Reference
------------------------+-----------------------+-----------------------
E_SYNTAX                Parsing error in request (including identifiers) [ RFC-to-be ]
E_MISSING_FIELD          A required JSON field is missing                [ RFC-to-be ]
E_INVALID_FIELD_TYPE    The type of the value of a JSON field is invalid [ RFC-to-be ]
E_INVALID_FIELD_VALUE    The value of a JSON field is invalid            [ RFC-to-be ]

IANA understands that these six actions are the only ones required to be completed upon approval of this document.
2014-02-04
25 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2014-02-04
25 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-02-03
25 Spencer Dawkins Ballot has been issued
2014-02-03
25 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-02-03
25 Spencer Dawkins Created "Approve" ballot
2014-02-03
25 Spencer Dawkins Ballot writeup was changed
2014-01-31
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-01-31
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-01-28
25 Cindy Morgan Note field has been cleared
2014-01-27
25 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2014-01-27
25 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2014-01-23
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2014-01-23
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2014-01-23
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-01-23
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-01-21
25 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-01-21
25 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Protocol) to Proposed Standard …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Protocol) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'ALTO Protocol'
  as Proposed Standard

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 2014-02-04. 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


  Applications using the Internet already have access to some topology
  information of Internet Service Provider (ISP) networks.  For
  example, views to Internet routing tables at looking glass servers
  are available and can be practically downloaded to many network
  application clients.  What is missing is knowledge of the underlying
  network topologies from the point of view of ISPs.  In other words,
  what an ISP prefers in terms of traffic optimization -- and a way to
  distribute it.

  The Application-Layer Traffic Optimization (ALTO) Service provides
  network information (e.g., basic network location structure and
  preferences of network paths) with the goal of modifying network
  resource consumption patterns while maintaining or improving
  application performance.  The basic information of ALTO is based on
  abstract maps of a network.  These maps provide a simplified view,
  yet enough information about a network for applications to
  effectively utilize them.  Additional services are built on top of
  the maps.

  This document describes a protocol implementing the ALTO Service.
  Although the ALTO Service would primarily be provided by ISPs, other
  entities such as content service providers could also operate an ALTO
  Service.  Applications that could use this service are those that
  have a choice to which end points to connect.  Examples of such
  applications are peer-to-peer (P2P) and content delivery networks.





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

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


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


2014-01-21
25 Amy Vezza State changed to In Last Call from Last Call Requested
2014-01-21
25 Amy Vezza Last call announcement was changed
2014-01-20
25 Spencer Dawkins Placed on agenda for telechat - 2014-02-06
2014-01-20
25 Spencer Dawkins Last call announcement was generated
2014-01-20
25 Spencer Dawkins Last call was requested
2014-01-20
25 Spencer Dawkins State changed to Last Call Requested from Publication Requested::AD Followup
2014-01-19
25 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-01-19
25 Y. Richard Yang New version available: draft-ietf-alto-protocol-25.txt
2014-01-16
24 Spencer Dawkins Working out a couple of questions with the authors.
2014-01-16
24 Spencer Dawkins State changed to Publication Requested::Revised I-D Needed from Publication Requested
2013-12-12
24 Enrico Marocco
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  The document specifies a new protocol and as such is being submitted
  as a Proposed Standard on the Standards Track, as indicated in the
  title page header.

(2) 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:

  The Application-Layer Traffic Optimization (ALTO) Service provides
  network information (e.g., basic network location structure,
  preferences of network paths) with the goal of modifying network
  resource consumption patterns while maintaining or improving
  application performance.  The basic information of ALTO is based on
  abstract maps of a network.  These maps provide a simplified view,
  yet enough information about a network for applications to
  effectively utilize them.  Additional services are built on top the
  maps.

  This document describes a protocol implementing the ALTO Service.
  Although the ALTO service would primarily be provided by the network
  operator (e.g., an ISP), content providers and third parties could
  also operate this service.  Applications that could use this service
  are those that have a choice in connection endpoints.  Examples of
  such applications are peer-to-peer (P2P) and content delivery
  networks.

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  The specification process has been particularly long and
  articulated. The WG had to make many decisions -- the architectural
  ones reflected in the related requirements document -- that took
  time. However, quite broad consensus was reached on almost all of
  them.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Implementations: three implementations with some interoperability
  were demostrated during a "running code show" organized at
  IETF80. Seven client and five server implementations were tested in
  an "interoperability event" at IETF81, with pretty good results
  (http://www.ietf.org/mail-archive/web/alto/current/msg01181.html). A
  second interoperability event was arranged during IETF85, were four
  server and two client implementations were tested against 21 test
  cases, with again good success rates (last slide of
  http://www.ietf.org/proceedings/85/slides/slides-85-alto-0.pdf).

  Expert supervision: since the protocol, despite being developed in
  TSV, is an application level protocol, based on HTTP and following a
  REST-ful approach, Peter Saint-Andre (also former responsible AD for
  ALTO, before the WG was moved to TSV) was appointed as APPS expert
  and has supervised the specification process in its crucial phases
  (Peter stepped back as Tech advisor at a later phase). Other experts
  from APPS (Martin Thomson, Alexey Melnikov), SEC (Richard Barnes,
  Hannes Tshofenig) and OPS (David Harrington, Benoit Claise) have at
  some point been involved and provided feedback on various aspects.

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request, no issues were raised.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Enrico Marocco is the document shepherd, Spencer Dawkins is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has followed the specification process
  closely, implementing a proof-of-concept client application himself
  (http://alto.tilab.com/alto-xkcd/). He has proofread the final
  version of the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  Each and every word has been read by litteraly hundreds of
  eyes. However, the document shepherd believes that additional
  external reviews (e.g. apps-dir and/or gen-art) would be beneficial,
  esp. to spot areas in the document that may turn out unclear to the
  unexperienced reader.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document specifies an HTTP-based application layer protocol,
  following the best practices generally referenced as REST-ful and
  requesting the registration of several media types. All these
  aspects have been approached under the supervision of APPS experts
  (Peter Saint-Andre, Martin Thomson, Richard Barnes, Alexey
  Melnikov) and should probably be re-checked for consistency. The
  document has also received a review from OPS perspective (from
  Benoit Claise).

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request no issues were raised.

(6) Describe any specific concerns or issues that the Document
Shepherd has 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.

  According to the document shepherd the document is good. In
  particulary, all that could be removed has been removed.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

  The authors (at the time of publication request) are not aware of
  any IPR on the document and believe that it is compliant with IETF
  copyright and IPR policy rules.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosure references this document. Two IPR disclosures
  (#1628 and #1718) were filed regarding proposed extensions to the
  protocol, but the WG decided not to integrate them in the base
  specs.

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

(10) 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 publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  IDnits only returns a bunch of tabulation warnings, regarding
  pseudo-code intdentation.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Media types are being nailed down under the supervision of the APPS
  tech advisor and with the help of APPS experts.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request no issues were raised.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. Please note that this specification heavily relies on JSON,
  currently defined in the soon-to-be-updated Informational RFC
  4627
. Such reference, despite normative in nature, is at this point
  listed as informative.

(14) 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 plan for their completion?

  The document builds up on JSON specs (currently RFC 4627), de-facto
  standard despite being defined in an Informational RFC. A fix for
  such an incostincency is being worked on in the JSON WG.
  Pragmatically the WG does not see any issue with referencing RFC
  4627
in either the normative section or informative
  section. Updating the reference and adding a normative dependency to
  draft-ietf-json-rfc4627bis seems less desirable as it would delay
  the publication indefinitely. The process-wise decision is anyway
  deferred to the IESG.

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  With the exception of the potentialy issue described in (14), there
  are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

  The document requests registration of ten media types and the
  creation of four registries. All IANA actions have been carefully
  ponderated, in accordance to guidelines in RFC 5226.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  The document defines four new registries: an ALTO Cost Metric
  Registry, an ALTO Endpoint Property Type Registry, an ALTO Address
  Type Registry and an ALTO Error Code Registry. This is the minimum
  set identified in the working group for achieving proper
  extensibility of the new protocol. The review process identified at
  this point for future allocations is "IETF Review".

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks were required other than IDnits.
2013-12-12
24 Enrico Marocco IETF WG state changed to Submitted to IESG for Publication
2013-12-12
24 Enrico Marocco IESG state changed to Publication Requested
2013-12-12
24 Enrico Marocco Working group state set to Submitted to IESG for Publication
2013-12-12
24 Enrico Marocco IESG state set to Publication Requested
2013-12-12
24 Enrico Marocco
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  The document specifies a new protocol and as such is being submitted
  as a Proposed Standard on the Standards Track, as indicated in the
  title page header.

(2) 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:

  The Application-Layer Traffic Optimization (ALTO) Service provides
  network information (e.g., basic network location structure,
  preferences of network paths) with the goal of modifying network
  resource consumption patterns while maintaining or improving
  application performance.  The basic information of ALTO is based on
  abstract maps of a network.  These maps provide a simplified view,
  yet enough information about a network for applications to
  effectively utilize them.  Additional services are built on top the
  maps.

  This document describes a protocol implementing the ALTO Service.
  Although the ALTO service would primarily be provided by the network
  operator (e.g., an ISP), content providers and third parties could
  also operate this service.  Applications that could use this service
  are those that have a choice in connection endpoints.  Examples of
  such applications are peer-to-peer (P2P) and content delivery
  networks.

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  The specification process has been particularly long and
  articulated. The WG had to make many decisions -- the architectural
  ones reflected in the related requirements document -- that took
  time. However, quite broad consensus was reached on almost all of
  them.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Implementations: three implementations with some interoperability
  were demostrated during a "running code show" organized at
  IETF80. Seven client and five server implementations were tested in
  an "interoperability event" at IETF81, with pretty good results
  (http://www.ietf.org/mail-archive/web/alto/current/msg01181.html). A
  second interoperability event was arranged during IETF85, were four
  server and two client implementations were tested against 21 test
  cases, with again good success rates (last slide of
  http://www.ietf.org/proceedings/85/slides/slides-85-alto-0.pdf).

  Expert supervision: since the protocol, despite being developed in
  TSV, is an application level protocol, based on HTTP and following a
  REST-ful approach, Peter Saint-Andre (also former responsible AD for
  ALTO, before the WG was moved to TSV) was appointed as APPS expert
  and has supervised the specification process in its crucial phases
  (Peter stepped back as Tech advisor at a later phase). Other experts
  from APPS (Martin Thomson, Alexey Melnikov), SEC (Richard Barnes,
  Hannes Tshofenig) and OPS (David Harrington, Benoit Claise) have at
  some point been involved and provided feedback on various aspects.

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request, no issues were raised.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Enrico Marocco is the document shepherd, Spencer Dawkins is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has followed the specification process
  closely, implementing a proof-of-concept client application himself
  (http://alto.tilab.com/alto-xkcd/). He has proofread the final
  version of the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  Each and every word has been read by litteraly hundreds of
  eyes. However, the document shepherd believes that additional
  external reviews (e.g. apps-dir and/or gen-art) would be beneficial,
  esp. to spot areas in the document that may turn out unclear to the
  unexperienced reader.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document specifies an HTTP-based application layer protocol,
  following the best practices generally referenced as REST-ful and
  requesting the registration of several media types. All these
  aspects have been approached under the supervision of APPS experts
  (Peter Saint-Andre, Martin Thomson, Richard Barnes, Alexey
  Melnikov) and should probably be re-checked for consistency. The
  document has also received a review from OPS perspective (from
  Benoit Claise).

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request no issues were raised.

(6) Describe any specific concerns or issues that the Document
Shepherd has 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.

  According to the document shepherd the document is good. In
  particulary, all that could be removed has been removed.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

  The authors (at the time of publication request) are not aware of
  any IPR on the document and believe that it is compliant with IETF
  copyright and IPR policy rules.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosure references this document. Two IPR disclosures
  (#1628 and #1718) were filed regarding proposed extensions to the
  protocol, but the WG decided not to integrate them in the base
  specs.

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

(10) 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 publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  IDnits only returns a bunch of tabulation warnings, regarding
  pseudo-code intdentation.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Media types are being nailed down under the supervision of the APPS
  tech advisor and with the help of APPS experts.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request no issues were raised.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. Please note that this specification heavily relies on JSON,
  currently defined in the soon-to-be-updated Informational RFC
  4627
. Such reference, despite normative in nature, is at this point
  listed as informative.

(14) 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 plan for their completion?

  The document builds up on JSON specs (currently RFC 4627), de-facto
  standard despite being defined in an Informational RFC. A fix for
  such an incostincency is being worked on in the JSON WG.
  Pragmatically the WG does not see any issue with referencing RFC
  4627
in either the normative section or informative
  section. Updating the reference and adding a normative dependency to
  draft-ietf-json-rfc4627bis seems less desirable as it would delay
  the publication indefinitely. The process-wise decision is anyway
  deferred to the IESG.

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  With the exception of the potentialy issue described in (14), there
  are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

  The document requests registration of ten media types and the
  creation of four registries. All IANA actions have been carefully
  ponderated, in accordance to guidelines in RFC 5226.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  The document defines four new registries: an ALTO Cost Metric
  Registry, an ALTO Endpoint Property Type Registry, an ALTO Address
  Type Registry and an ALTO Error Code Registry. This is the minimum
  set identified in the working group for achieving proper
  extensibility of the new protocol. The review process identified at
  this point for future allocations is "IETF Review".

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks were required other than IDnits.
2013-12-11
24 Enrico Marocco Document shepherd changed to Enrico Marocco
2013-12-11
24 Y. Richard Yang New version available: draft-ietf-alto-protocol-24.txt
2013-12-09
23 Y. Richard Yang New version available: draft-ietf-alto-protocol-23.txt
2013-12-04
22 Y. Richard Yang New version available: draft-ietf-alto-protocol-22.txt
2013-11-20
21 Y. Richard Yang New version available: draft-ietf-alto-protocol-21.txt
2013-10-02
20 Y. Richard Yang New version available: draft-ietf-alto-protocol-20.txt
2013-10-02
19 Y. Richard Yang New version available: draft-ietf-alto-protocol-19.txt
2013-09-14
18 Y. Richard Yang New version available: draft-ietf-alto-protocol-18.txt
2013-07-14
17 Richard Alimi New version available: draft-ietf-alto-protocol-17.txt
2013-05-21
16 Y. Richard Yang New version available: draft-ietf-alto-protocol-16.txt
2013-05-20
15 Cindy Morgan Shepherding AD changed to Spencer Dawkins
2013-05-08
15 Richard Alimi New version available: draft-ietf-alto-protocol-15.txt
2013-03-06
14 Martin Stiemerling
The ALTO protocol is returned to the WG, as there are still a number of issues beyond the ones out of the AD review that …
The ALTO protocol is returned to the WG, as there are still a number of issues beyond the ones out of the AD review that require WG attention and a new WGLC before submitting it to the IESG. See also this email: http://www.ietf.org/mail-archive/web/alto/current/msg01729.html
2013-03-06
14 Martin Stiemerling State changed to AD is watching from AD Evaluation::AD Followup
2013-02-25
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-02-25
14 Y. Richard Yang New version available: draft-ietf-alto-protocol-14.txt
2012-10-29
13 Martin Stiemerling
The AD review for draft-ietf-alto-protocol-13:

A few points to be discussed, probably also at the IETF meeting to get an agreement with the WG …
The AD review for draft-ietf-alto-protocol-13:

A few points to be discussed, probably also at the IETF meeting to get an agreement with the WG rapidly:
- I do have concerns that the filtering services can degenerate into a full map service, i.e., if no inputs on what pid are given.

- There is not a single good place where there is a consolidate information about services are mandatory to implement (i.e., the map service) and what services are optional (e.g., the the map filtering service).

- I have a hard time to understand how the Endpoint Properties are defined. The draft uses them but there is no Endpoint Properties defined, or I haven't seen it. Of course the JSON is there, but are those properties?
Furthermore, I assume Endpoint Properties would require a registry to register properties?

- I still wonder about the message of Section 8. It is trying to discuss some issues, but it fails in really doing so.

- Security:
I do not see that this is discussed in larger detail:
What security mechanism to use in what scenario. The considerations elaborate on the use of SSL/TLS, but it is not clear when to use it. In general, it seems to be really good, at least by today, to mandate the use of HTTPS in almost any scenario where the traffic crosses a publicly available infrastructure, e.g., the general Internet, wireless access networks, etc. Conversely, it can be good to always mandate the use of HTTPS and to list exceptional cases where it is required, i.e., CDNI peering point.

- Comparison of PDINames: How are PDINames compared? Byte-wise? Please specify this.

***********************************************
INTRODUCTION, paragraph 4:

> Networking applications today already have access to a great amount
> of Inter-Provider network topology information.  For example, views
> of the Internet routing table are easily available at looking glass
COMMENT:A couple of comments about this:
- What are networking applications? This reads such as traceroute, but
rather a 'applications using the network' would say that we talk more
about apps like p2p, jabber, etc.
- I am not sure that 'great amount' is the right term, as there is such
information available, but whether it is great amount or not is
questionable. How about just saying 'access to inter-provider'
- s/routing table are easy/routing table are available. Otherwise we
can debate what is easy is and what skill you need to have to have it
easiy. The 'easy' here is also in sharp contrast to Section 1.1 of this
draft -- as this doesn't read that it is so easy.


INTRODUCTION, paragraph 5:

> servers and entirely practical to be downloaded by clients.  What is
> missing is knowledge of the underlying network topology from the ISP
> or Content Provider (henceforth referred as Provider) point of view.
> In other words, what a Provider prefers in terms of traffic
> optimization -- and a way to distribute it.

  Expand 'ISP'


INTRODUCTION, paragraph 6:

> The ALTO Service provides network information (e.g., basic network
> location structure, preferences of network paths) with the goal of
> modifying network resource consumption patterns while maintaining or
> improving application performance.  The basic information of ALTO is
> based on abstract maps of a network.  These maps provide a
> simplified view, yet enough information about a network for
> applications to effectively utilize them.  Additional services are
> built on top the maps.

  Please expand ALTO on its first use in the title of the draft,
  here, and also later on in the introduction.


INTRODUCTION, paragraph 7:

> This document describes a protocol implementing the ALTO Service.
> Although the ALTO service would primarily be provided by the network
> operator (e.g., an ISP), content providers and third parties could
> also operate this service.  Applications that could use this service
> are those that have a choice in connection endpoints.  Examples of
> such applications are peer-to-peer (P2P) and content delivery
> networks.

  A nit, just to avoid any doubt: 'have a choice in connection
  endpoints' sounds like you already have a connection to the other
  endpoint in order to apply ALTO. I would propose to change it to
  'have a choice in endpoints to connect to'.


Section 1.1., paragraph 3:

> The goal of this document is to specify a simple and unified
> protocol that meets the ALTO requirements [I-D.ietf-alto-reqs] while
> providing

  Do we have reached the goal? If your answer is 'no', the document
  isn't worth the publication as RFC. If you say 'yes' we should say
  'This document is defining the ALTO protocol...'. You could add
  more words about how the ALTO protocol materialized, but in
  something like Section 1.2, but in an appendix. See also next
  comment.


Section 1.1., paragraph 4:

> a migration path for Internet Service Providers (ISP), Content
> Providers, and clients that have deployed protocols with similar
> intentions (see Section 1.2).

  I cannot see out of Section 1.2 why migration is supported or not
  supported by the protocol. Do you really need to say this here?


Section 1.1., paragraph 5:

> The ALTO Protocol design uses a REST-ful design with the goal of
> leveraging current HTTP [RFC2616] implementations and
> infrastructure.

  REST-ful is well-known in the HTTP/HTML-community, but in other
  fields not. Adding a reference to it would be very beneficially.


Section 1.1., paragraph 6:

> The REST-ful design supports flexible deployment strategies and
> provides extensibility.  ALTO requests and responses are encoded
> with JSON [RFC4627].

  There will be confusion by reads that have not been participating
  in ALTO about what the ALTO service is and what the ALTO protocol
  is. This could need some clarifying words.


Section 1.3., paragraph 1:

> At a high level, the ALTO Service allows a Service Provider (e.g.,
> an ISP) to publish information about network locations and costs
> between them at configurable granularities.

  The abstract makes a definition which isn't re-used here: 'ISP or
  Content Provider (henceforth referred as Provider)'. Why is this
  definition not repeated in the early parts of the introduction.


Section 1.3., paragraph 2:

> The ALTO Service offers many benefits to both end-users (consumers
> of the service) and Internet Service Providers (providers of the
> service).

  I am not sure whether this Section 1.3 is only marketing and has
  real value. But what is the value of, e.g., 'offers many benefits
  to both end-users' if there is no list of proven benefits?


Section 1.3.1., paragraph 1:

> The ALTO Service enables Service Providers to influence the peer or
> resource selection process in distributed applications in order to
> increase locality of traffic, improve user-experience, amongst
> others.  It also helps ISPs to efficiently manage traffic that
> traverses more expensive links such as transit and backup links,
> thus allowing a better provisioning of the networking
> infrastructure.

  To be honestly: I am not that confident that 'enable' (1st sentence)
  or 'ISPs to efficiently manage traffic' are the right language
  here. The ALTO protocol is a tool that allows ISPs to interact
  with apps with the goal of . The text above reads like
  that ISPs can turn knobs in p2p apps which isn't true. There is
  the possibility to do this and therefore my comment


Section 1.3.2., paragraph 1:

> Applications that use the ALTO Service can benefit in multiple ways.
> For example, they may no longer need to infer topology information,
> and some applications can reduce reliance on measuring path
> performance metrics themselves.  They can take advantage of the
> ISP's knowledge to avoid bottlenecks and boost performance.

  The message of this Section is perfect and should be a guiding
  example for Section 1.3.1.


Section 2.1.4., paragraph 1:

> Network Location is a generic term denoting a single endpoint or
> group of endpoints.

  I would add: "For instance, it can be a single IPv4 address, an
  IPv4 prefix, or a set of IPv4 prefixes". Just to make it clear to
  any reader.


Section 2.2., paragraph 1:

> An ALTO Server conveys the network information from the perspective
> of a network region; the ALTO Server presents its "my-Internet View"
> of the network region.  In particular, an ALTO Server defines
> network Endpoints (and aggregations thereof) and generic costs
> amongst them from the network region's own perspective.  A network
> region in this context can be an Autonomous System, an ISP, or
> perhaps a smaller region or set of ISPs; the details depend on the
> ALTO deployment scenario and ALTO service discovery mechanism.

  Why does the "my-Internet View" depend on the scenario or srv
  discovery mechanism? I know what you are targeting, but I find it
  misleading. The primary reason is that 'somebody' is defining the
  "my-Internet View". However, depending which server you ask you
  will see a different instance of the "my-Internet View".


Section 2.2., paragraph 2:

> To better understand the ALTO Service and the role of the ALTO
> Protocol, we show in Figure 1 the overall ALTO system architecture.
> In this architecture, an ALTO Server prepares ALTO Information; an
> ALTO Client uses ALTO Service Discovery to identify an appropriate
> ALTO Server; and the ALTO Client requests available ALTO Information
> from the ALTO Server using the ALTO Protocol.

  I like this paragraph and I would only suggest to replace the
  'ALTO Protocol' line in Figure 1 with some characters which make
  this line better visible, e.g., using '=' instead of '-'.


Section 2.2., paragraph 4:

> More specifically, the ALTO Information provided by an ALTO Server
> may be influenced (at the operator's discretion) by other systems.
> The ALTO Server aggregates information from multiple systems to

  Since the sentence about says 'may be influenced' it might better
  to write here 'The ALTO Server can aggregate'. It is a nit, but
  there is no need that has always to aggregate information, but it
  is able to do so, if needed.


Section 2.2., paragraph 6:

> It may also be possible for ALTO Servers to exchange network
> information with other ALTO Servers (either within the same
> administrative domain or another administrative domain with the
> consent of both parties) in order to adjust exported ALTO
> Information.  Such a protocol is also outside the scope of this
> specification.

  So, after this section, what is the ALTO service?



Section 2.3., paragraph 2:

> Beyond integration with existing HTTP caching infrastructure, ALTO
> information may also be cached or redistributed using application-
> dependent mechanisms, such as P2P DHTs or P2P file-sharing.  This
> document does not define particular mechanisms for such
> redistribution.  See [I-D.gu-alto-redistribution] for further
> discussion.

  I would remove the reference [I-D.gu-alto-redistribution], as this
  didn't progress.


Section 2.3., paragraph 3:

> Additional protocol mechanisms (e.g., expiration times and digital
> signatures for returned ALTO information) are left for extension

  a proposal: s/left for extension/left for future investigation/


Section 3., paragraph 0:

3.  Service Framework

  shouldn't it read 'ALTO Service Framework'? Just to be precise.


Section 3., paragraph 3:

> The ALTO Protocol is built on a common transport protocol, messaging
> structure and encoding, and transaction model.  The protocol is
> subdivided into services of related functionality.  The Map Service
> provides the core ALTO information to clients.  Other ALTO
> Information services provide additional functionalities.  There are
> three such services defined in this document: the Map Filtering
> Service, Endpoint Property Service, and Endpoint Cost Service.
> Additional services may be defined in companion documents.

  s/may be defined/can be defined/.


Section 3., paragraph 4:

> Functionalities offered in different services may overlap (e.g., the
> Map Service and Map Filtering Service).

  s/may overlap/can overlap/. Even though may would be also Ok,
  as the it is allowed to have overlapping functionality.


Section 3.1.3., paragraph 1:

> This service allows ALTO Clients to look up properties for
> individual Endpoints.  An example endpoint property is its Network
> Location (its grouping defined by the ALTO Server) or connectivity
> type (e.g., ADSL, Cable, or FTTH).

  Expand 'ADSL' and 'FTTH' here.


Section 4., paragraph 1:

> The Network Location Endpoint Property allows an ALTO Server to
> group endpoints together to indicate their proximity.  The resulting
> set of groupings is called the ALTO Network Map.

  'The resulting' means 'the resulting set of Network Location Endpoint
  Properties',isn't it? Better to spell it out.


Section 4., paragraph 3:

> The definition of proximity varies depending on the granularity of
> the ALTO information configured by the provider.  In one deployment,
> endpoints on the same subnet may be considered close; while in
> another deployment, endpoints connected to the same PoP may be
> considered close.

  Expand 'PoP'


Section 4.1., paragraph 1:

> Each group of Endpoints is identified by a provider-defined Network
> Location identifier called a PID.  A PID is a US-ASCII string of
> type

  Expand PID in the text and also in the section heading.

Section 5., paragraph 2:

> An ALTO Cost Map defines Path Costs pairwise amongst sets of source
> and destination Network Locations.  Each Path Cost is the end-to-end
> cost from the source to the destination.

  Isn't the costed defined between PIDs and not the Network
  Locations? Just to ensure that the correct terminology is being used.


Section 5.1.2., paragraph 4:

> An ALTO Server MUST support at least one of 'numerical' and
> 'ordinal' costs.  ALTO Clients SHOULD be cognizant of operations when
> a desired cost mode is not supported.  For example, an ALTO Client
> desiring

  The 'ALTO Clients SHOULD be' isn't correct, as it is not a protocol
  issue but more it should read 'ALTO Clients should be', in oder
  to let people know that this can happen. On the other hand, would
  it make a big difference if the both, 'numerical' and 'ordinal',
  are supported, i.e., 'MUST support both'?



Section 5.2., paragraph 4:

> If the Cost Mode is 'ordinal', the Path Cost of each communicating
> pair is relative to the m*n entries.

  What is the 'm*n entries'? It has not been used before, nor
  defined. I do know what it is, but an stranger to ALTO does not.


Section 5.3., paragraph 2:

> A Version Tag is an opaque string associated with a Network Map
> maintained by the ALTO Server.  When the Network Map changes, the
> Version Tag MUST also be changed.  (Thus, the Version Tag is defined
> similarly to HTTP's Entity Tags; see Section 3.11 of [RFC2616].)
> Possibilities for generating a Version Tag include the last-modified
> timestamp for the Network Map, or a hash of its contents.

  Is there any required to never ever have the same version tag? And
  what is the scope of this requirement, e.g., per server?


Section 5.3., paragraph 3:

> A Network Map distributed by the ALTO Server includes its Version
> Tag. A Cost Map referring to PIDs also includes the Version Tag of
> the Network Map on which it is based.

  How are the version tags to be compared? Byte-wise?


Section 6.3.4.2., paragraph 1:

> If an ALTO Client does not successfully receive a desired
> Information Resource from a particular ALTO Server, it can either
> choose another server (if one is available) or fall back to a default
> behavior (e.g., perform peer selection without the use of ALTO
> information). An ALTO Client may also retry the request at a later
> time.

  A suggestion to change this to improve readability/giving a better
  context to the reader that it is about p2p:
OLD
(e.g., perform peer selection without the use of ALTO information).
NEW
(e.g., perform peer selection without the use of ALTO information, if
used with a peer-to-peer system).


Section 6.3.5., paragraph 1:

> An ALTO Server MAY support SSL/TLS [RFC5246] to implement server
> and/or client authentication, encryption, and/or integrity
> protection.  See [RFC6125] for considerations regarding verification
> of server identity.

  This will raise questions from the security point of view. It would
  be better that SSL/TLS is mandatory to implement. You can leave it
  open whether it is used in deployments.



Section 6.5.3., paragraph 1:

> This document defines ALTO Error Codes to support the error
> conditions needed for purposes of this document.  Additional status
> codes may be defined in companion or extension documents.

  A purily editorial comment: You use a lot of 'may' in the text
  though a 'can' would be more appropriate. The text here is more
  about the ability to define additional status code but not about
  the permission. I'm just noting this, as this is a re-occurring
  comment during the next review stages.


Section 6.5.3., paragraph 2:

> The HTTP status codes corresponding to each ALTO Error Code are
> defined to provide correct behavior with HTTP intermediaries and
> clients.  When an ALTO Server returns a particular ALTO Error Code,
> it MUST indicate one of the corresponding HTTP status codes in Table
> 1 in the HTTP response.

  What is the guidance to clients that receive, for instance, an
  E_SYNTAX with a 200 OK on the HTTP level?


Section 6.5.3., paragraph 5:

> Table 1: Defined ALTO Error Codes

  There is no IANA registry for error codes? That is missing.


Section 6.6.5., paragraph 2:

> Identifiers prefixed with 'priv:' are reserved for Private Use
> [RFC5226].  Identifiers prefixed with 'exp:' are reserved for
> Experimental use.  All other identifiers appearing in an HTTP
> request or response with an 'application/alto-*' media type MUST be
> registered in the ALTO Cost Types registry Section 9.2.

  A general point to 'priv:' and 'exp:'. The current specification is
  relative dangerous, as it only says 'use priv: for your private use'
  and add something afterwards. However, there is the likely risk that
  two implementers choose the same tag after 'priv:'. In order to avoid
  that, the specification should mandate that, if somebody wants to use
  this type of extension you MUST append a further tag, e.g., company
  name or random string, to the 'priv:' or 'exp:' tags to make them
  unique. For experiments I would recommend to make the recommendation
  use a short randomstring the start time of the experiement.


Section 6.7., paragraph 3:

> An ALTO Server MUST make an Information Resource Directory available
> via the HTTP GET method to a URI discoverable by an ALTO Client.
> Discovery of this URI is out of scope of this document, but could be
> accomplished by manual configuration or by returning the URI of an
> Information Resource Directory from the ALTO Discovery Protocol
> [I-D.ietf-alto-server-discovery].

  I wonder if there should be a non-binding recommendation of how
  this URI should look like.


Section 6.8.1.1.6., paragraph 1:

> GET /networkmap HTTP/1.1 Host: alto.example.com Accept:
> application/alto-networkmap+json,application/alto-error+json

  What happens actually if the client does not set
  'Accept:application/alto-error+json'?

> HTTP/1.1 200 OK Content-Length: 370 Content-Type:
> application/alto-networkmap+json


Section 6.8.1.2., paragraph 1:

> The Cost Map resource lists the Path Cost for each pair of source/
> destination PID defined by the ALTO Server for a given Cost Type and
> Cost Mode.  This resource MUST be provided for at least the
> 'routingcost' Cost Type and 'numerical' Cost Mode.

  Section 5.1.2. says that numerical or ordinal MUST be supported,
  but not at the same time. How does the text here fit this? I do
  implement ordinal according to Section 5.1.2., but now I have also
  to implement numerical according this here.


Section 6.8.2.1., paragraph 1:

> A Filtered Network Map is a Network Map Information Resource (Section
> 6.8.1.1) for which an ALTO Client may supply a list of PIDs to be
> included.  A Filtered Network Map MAY be provided by an ALTO Server.

  Not sure the 'MAY' is correct here. Or at least until here it is
  not fully clear to me what parts of the service is mandatory to
  implement and what is not.


Section 6.8.2.1.3., paragraph 4:

> pids  Specifies list of PIDs to be included in the returned Filtered
> Network Map. If the list of PIDs is empty, the ALTO Server MUST
> interpret the list as if it contained a list of all currently-
> defined PIDs.  The ALTO Server MUST interpret entries appearing
> multiple times as if they appeared only once.

  What is the expected output, if the client turns over an emtpy set
  of PIDNames?


Section 6.8.2.1.3., paragraph 5:

> address-types  Specifies list of address types to be included in the
> returned Filtered Network Map. If the list of address types is empty,
> the ALTO Server MUST interpret the list as if it contained a list of
> all address types known to the ALTO Server.  The ALTO Server MUST
> interpret entries appearing multiple times as if they appeared only
> once.

  It does not look right that the server is forced to deliver an
  arbitrary amount of address-types back, if no address-type is
  specified. Is there any good reason to leave this, as it is right
  now? I would imagine that client is forced to say what AddressType
  it is interested in. Also given that I would set zero PIDNames and
  zero AddressTypes looks strange as this would be the regular map
  service, isn't it?


Section 6.8.2.2., paragraph 1:

> A Filtered Cost Map is a Cost Map Information Resource (Section
> 6.8.1.2) for which an ALTO Client may supply additional parameters
> limiting the scope of the resulting Cost Map. A Filtered Cost Map MAY
> be provided by an ALTO Server.

  Same comment as in Section 6.8.2.1.


Section 6.8.2.2.3., paragraph 7:

> constraints  Defines a list of additional constraints on which
> elements of the Cost Map are returned.  This parameter MUST NOT be
> specified if this resource's capabilities ( Section 6.8.2.2.4)
> indicate that constraint support is not available.  A constraint
> contains two entities separated by whitespace: (1) an operator, 'gt'
> for greater than, 'lt' for less than, 'ge' for greater than or equal
> to, 'le' for less than or equal to, or 'eq' for equal to

  s/for equal to/for equal to./



Section 6.8.2.2.3., paragraph 8:

> pids  A list of Source PIDs and a list of Destination PIDs for which
> Path Costs are to be returned.  If a list is empty, the ALTO Server
> MUST interpret it as the full set of currently-defined PIDs.  The
> ALTO Server MUST interpret entries appearing in a list multiple times
> as if they appeared only once.  If the "pids" member is not present,
> both lists MUST be interpreted by the ALTO Server as containing the
> full set of currently-defined PIDs.

  Similar to Section 6.8.2.1.3.. It looks strange that we have a cost
  map retrieval service and filtered service which degenerates to the
  cost map service.


Section 6.8.2.2.5., paragraph 2:

> The returned Cost Map MUST NOT contain any source/destination pair
> that was not indicated (implicitly or explicitly) in the input
> parameters.  If the input parameters contain a PID name that is not

  Can you rephrase this to avoid the 'MUST NOT' and 'not indicated',
  just to avoid any doubt what is meant?


Section 6.8.3.1., paragraph 1:

> The Endpoint Property resource provides information about properties
> for individual endpoints.  It MAY be provided by an ALTO Server.  If

  Again, it is really to good to have a section right in the beginning
  to state what service is MUST or what is MAY.


Section 6.8.3.1.4., paragraph 4:

> prop-types  The Endpoint Property Types (see Section 6.6.6)
> supported by the corresponding URI.  If not present, this member MUST
> be interpreted as an empty array.

  Where are the Endpoint Properties defined ?


Section 6.8.3.1.5., paragraph 8:

> The ALTO Server MAY include the Version Tag (Section 5.3) of the
> Network Map used to generate the response (if desired and
> applicable) as the 'map-vtag' member in the response.  If the 'pid'
> property is returned for any endpoints in the response, the
> 'map-vtag' member is

  Why isn't required to always return the Version Tag? This construct
  looks overly complex. Any by the way the map-vtag is missing the
  example even though the 'pid' is included.

> REQUIRED instead of OPTIONAL.


Section 6.8.4.1.6., paragraph 0:

> EndpointCostMapData is a JSON object with each member representing a
> single Source Endpoint specified in the input parameters; the name
> for a member is the TypedEndpointAddr string identifying the
> corresponding Source Endpoint.  For each Source Endpoint, a
> EndpointDstCosts object denotes the associated cost to each
> Destination Endpoint specified in the input parameters; the name for
> each member in the object is the TypedEndpointAddr string
> identifying the corresponding Destination Endpoint.  An
> implementation of the protocol in this document SHOULD assume that
> the cost value is a JSONNumber and fail to parse if it is not, unless
> the implementation is using an extensions to this document that
> indicates when and how costs of other data types are signaled.  If
> the ALTO Server does not define a cost value from a Source Endpoint
> to a particular Destination Endpoint, it MAY be omitted from the
> response.

  The 'MAY be omitted' is contradicting the sentence in the beginning
  of this subsection that says 'has "data" member equal to', isn't it?
6.8.4.1.6.  Example


Section 7.1., paragraph 1:

> Many currently-deployed P2P systems use a Tracker to manage swarms
> and perform peer selection.  P2P trackers may currently use a
> variety

  s/may/can/


Section 8.2., paragraph 1:

> In practical deployments, especially during the transition from IPv4
> to IPv6, a particular host may be reachable using multiple
> addresses. Furthermore, the particular network path followed when
> sending packets to the host may differ based on the address that is
> used. Network providers may prefer one path over another (e.g., one
> path may have a NAT64 middlebox).  An additional consideration may be
> how to handle private address spaces (e.g., behind carrier-grade
> NATs).

  Again revise the usage of 'may'.


Section 8.2., paragraph 2:

> To support such behavior, this document allows multiple types of
> endpoint addresses.  In supporting multiple address types, the ALTO
> Protocol also allows ALTO Service Provider the flexibility to
> indicate preferences for paths from an endpoint address of one type
> to an endpoint address of a different type.  Note that in general,
> the path through the network may differ dependent on the types of
> addresses that are used.

  Again revise the usage of 'may'.


Section 8.2., paragraph 3:

> Note that there are limitations as to what information ALTO can
> provide in this regard.  In particular, a particular ALTO Service
> provider may not be able to determine if connectivity with a
> particular endhost will succeed over IPv4 or IPv6, as this may
> depend upon information unknown to the ISP such as particular
> application implementations.

  This section will ensure that this spec runs into multiple
  DISCUSS, as it touches IPv4 to IPv6 transisition in a very unsafe
  way. There is in general no means to see whether a path from an
  IPv4 address to an IPv6 is in existence. Furthermore, the section
  heading is about multiple address which is different from IPv4/IPv6
  tranisition. Please remove the IPv4 to IPv6 aspect and if you like
  write a separate draft about it, as this section here is incomplete
  and misleading.


Section 8.3., paragraph 6:

> ALTO Clients should be cognizant that the network path between
> Endpoints can be dependent on the network interfaces, source
> address, and destination address used for communication.  An ALTO
> Server

  To be precise please change to '...can be dependent, e.g., on the
  network interfaces,...'


Section 8.3., paragraph 7:

> provides information based on Endpoint Addresses (more generally,
> Network Locations), but the mechanisms used for determining
> existence of connectivity or usage of NAT between Endpoints are out
> of scope of this document.

  I still wonder what the benefit of this section is?


Section 9.2., paragraph 10:

> This specification requests registration of the identifier
> 'routingcost'.  Semantics for the this Cost Type are documented in
> Section 5.1.1.1, and security considerations are documented in
> Section 10.1.

  It is better to summarize here, how the registry should look like
  and what first value(s) to be registered are. Making a table in the
  document, just to remove any doubt.


Section 9.3., paragraph 10:

> This specification requests registration of the identifier 'pid'.
> Semantics for the this Endpoint Property are documented in Section
> 4.1, and security considerations are documented in Section 10.1.

  It is better to summarize here, how the registry should look like
  and what first value(s) to be registered are. Making a table in the
  document, just to remove any doubt.


Section 9.4., paragraph 11:

> This specification requests registration of the identifiers 'ipv4'
> and 'ipv6'.  Endpoint Address Encoding is documented in Section
> 6.6.3.2.1 and Section 6.6.3.2.2.  Endpoint Prefix Encoding is
> documented in Section 6.6.3.3.1 and Section 6.6.3.3.2.  Since these
> are registrations for IPv4 and IPv6 address types, no mapping is
> required.  Security considerations are documented in Section 10.1
> and Section 10.2.

  It is better to summarize here, how the registry should look like
  and what first value(s) to be registered are. Making a table in the
  document, just to remove any doubt.


Section 10.1., paragraph 2:

> It is possible that one or multiple ALTO Clients issue queries in an
> effort to reverse-engineer specific details (e.g., network topology)
> that was used to produce ALTO information.  Operators should have
> security policies in place such that confidential information or
> information that could be reverse-engineered to reveal confidential
> information is not sent to unauthorized ALTO Clients.
COMMENT:
- I would add that this is issue is caused by the backend, i.e., the
databases and how information is processed there.
- There is also another concern that the ISP might reveal additional
information about IP addresses and associated information about it.
E.g., when adding the line bitrate as endpoint information which can be
potentially linked to the income of the habitants of a house. Rich
Woundy brought this up when the ALTO WG discussed adding additional
information to the endpoint service.


Section 10.2., paragraph 3:

> In addition, ALTO clients should be cautious not to unintentionally
> or indirectly disclose the resource identifier (of which they try to
> improve the retrieval through ALTO-guidance), e.g., the name/
> identifier of a certain video stream in P2P live streaming, to the
> ALTO server.  Note that the ALTO Protocol specified in this document
> does not explicitly reveal any resource identifier to the ALTO
> Server.  However, for instance, depending on the popularity or other
> specifics (such as language) of the resource, an ALTO server could
> potentially deduce information about the desired resource from
> information such as the Network Locations the client sends as part
> of its request to the server.

  Wouldn't be also the possbility that the ALTO server is collecting
  information from multiple clients and also queries to deduct
  what application or content is being used? That is also a threat
  to clients.


Section 10.5., paragraph 1:

> ISPs should be cognizant of the workload at the ALTO Server
> generated by certain ALTO Queries, such as certain queries to the Map
> Filtering Service and Ranking Service.  In particular, queries which
> can be generated with low effort but result in expensive workloads at
> the ALTO Server could be exploited for Denial-of-Service attacks.
> For instance, a simple ALTO query with n Source Network Locations and
> m Destination Network Locations can be generated fairly easily but
> results in the computation of n*m Path Costs between pairs by the
> ALTO Server (see Section 5.2).  One way to limit Denial-of-Service
> attacks is to employ access control to the ALTO server.  Another
> possible mechanism for an ALTO Server to protect itself against a
> multitude of computationally expensive bogus requests is to demand
> that each ALTO Client to solve a computational puzzle first before
> allocating resources for answering a request (see, e.g.,
> [I-D.jennings-sip-hashcash]).  The current specification does not
> use such computational puzzles, and discussion regarding tradeoffs
> of such an approach would be needed before including such a technique
> in

  Wouldn't it be useful to allow the ALTO server to stop computing
  a response and to return an appropriate error code?



Section 11.1.4., paragraph 2:

> Deployment of an ALTO Server may shift network traffic patterns.
> Thus, operators should consider impacts on (or integration with)
> traffic engineering.

  I would suggest to add the aspect of monitoring the network to
  observe the outcome of ALTO operations.


Section 11.1.5., paragraph 1:

> ALTO-specific monitoring and metrics are discussed in 6.3 of
> [I-D.ietf-alto-deployments] and future versions of that document.

  I would move this up to my earlier comment and discuss here the fact
  that ALTO clients are not bound to the guidance and that therefore
  it can be challenging to verify the correct operations. Also due
  to the fact that correct is ahrd to judge, as this depends on the
  application that uses the guidance. bittorrent vs. ppplive can gay
  different understandings of what is correct.


Section 11.2.3., paragraph 1:

> Monitoring ALTO Servers and Clients is described in Section 6.3 of
> [I-D.ietf-alto-deployments] and future versions of that document.

  I would remove the current text and repeat what has been said before
  that the guidance is provided to the client as is and that fault
  management is not in scope for this side. For the server side I
  would recommend to say that there is operational experience in
  running web servers at large scale.


Section 11.2.4., paragraph 6:

> Multiple ALTO Servers my be deployed for horizontal scalability.  A

  s/my/can/, and horizontal scalability will need some words on what
  is meant.


Section 11.2.5., paragraph 1:

> Monitoring ALTO Servers and Clients is described in Section 6.3 of
> [I-D.ietf-alto-deployments] and future versions of that document.

  I do not see that we have to discuss Accounting mgmt. You can IMHO
  safely remove this section.


Section 11.2.6., paragraph 7:

> Additional information for monitoring performance of ALTO Servers
> and Clients is described in Section 6.3 of
> [I-D.ietf-alto-deployments] and future versions of that document.

  Remove this paragraph.
2012-10-26
13 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2012-10-08
13 Martin Stiemerling State changed to AD Evaluation from Publication Requested
2012-10-02
13 Amy Vezza State changed to Publication Requested from AD is watching
2012-10-02
13 Amy Vezza
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  The document specifies a new protocol and as such is being submitted
  as a Proposed Standard on the Standards Track, as indicated in the
  title page header.

(2) 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:

  The Application-Layer Traffic Optimization (ALTO) Service provides
  network information (e.g., basic network location structure,
  preferences of network paths) with the goal of modifying network
  resource consumption patterns while maintaining or improving
  application performance.  The basic information of ALTO is based on
  abstract maps of a network.  These maps provide a simplified view,
  yet enough information about a network for applications to
  effectively utilize them.  Additional services are built on top the
  maps.

  This document describes a protocol implementing the ALTO Service.
  Although the ALTO service would primarily be provided by the network
  operator (e.g., an ISP), content providers and third parties could
  also operate this service.  Applications that could use this service
  are those that have a choice in connection endpoints.  Examples of
  such applications are peer-to-peer (P2P) and content delivery
  networks.

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  The specification process has been particularly long and
  articulated. The WG had to make many decisions -- the architectural
  ones reflected in the related requirements document -- that took
  time. However, quite broad consensus was reached on almost all of
  them.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Implementations: three implementations with some interoperability
  were demostrated during a "running code show" organized at
  IETF80. Seven client and five server implementations were tested in
  an "interoperability event" at IETF81, with pretty good results
  (http://www.ietf.org/mail-archive/web/alto/current/msg01181.html). A
  second interoperability event has been arranged for IETF85.

  Expert supervision: since the protocol, despite being developed in
  TSV, is an application level protocol, based on HTTP and following a
  REST-ful approach, Peter Saint-Andre (also former responsible AD for
  ALTO, before the WG was moved to TSV) was appointed as APPS expert
  and has supervised the specification process in its crucial
  phases. Other experts from APPS (Martin Thomson, Alexey Melnikov),
  SEC (Richard Barnes) and OPS (David Harrington, Benoit Claise) have
  at some point been involved and provided feedback on various
  aspects.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Enrico Marocco is the document shepherd, Martin Stiemerling is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has followed the specification process
  closely, implementing a proof-of-concept client application himself
  (http://alto.tilab.com/alto-xkcd/). He has proofread the final
  version of the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  Each and every word has been read by litteraly hundreds of
  eyes. However, the document shepherd believes that additional
  external reviews (e.g. apps-dir and/or gen-art) would be beneficial,
  esp. to spot areas in the document that may turn out unclear to the
  unexperienced reader.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document specifies an HTTP-based application layer protocol,
  following the best practices generally referenced as REST-ful and
  requesting the registration of several media types. All these
  aspects have been approached under the supervision of APPS experts
  (Peter Saint-Andre, Martin Thomson, Richard Barnes, Alexey
  Melnikov) and should probably be re-checked for consistency. The
  document has also received a review from OPS perspective (from
  Benoit Claise).

(6) Describe any specific concerns or issues that the Document
Shepherd has 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.

  According to the document shepherd the document is good, all that
  could be removed has been removed.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

  The authors are not aware of any IPR on the document and believe
  that it is compliant with IETF copyright and IPR policy rules.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosure references this document. Two IPR disclosures
  (#1628 and #1718) were filed regarding proposed extensions to the
  protocol, but the WG decided not to integrate them in the base
  specs.

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

(10) 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 publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  IDnits returns a bunch of warnings about missing references, one in
  an informative "ChangeLog" section whose removal will be discusse
  with the RFC Editor and the remaining caused by the square brakets
  used in the JSON code examples.

  IDnits also returns a downref error as it lists JSON specs (RFC
  4627
) in the normative section. Guidance on this is expected from
  the IESG, as, despite being an Invormative document, JSON is in fact
  a standard this protocol as well as most of today's web technologies
  are based on. To the best of my knowledge APPSAWG is fixing the
  incosistency, but unfortunately a proper 4627bis is not going to be
  published in time.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Media types have been nailed down under the supervision of the APPS
  tech advisor and with the help of APPS experts. See (2) and (5).

(13) Have all references within this document been identified as
either normative or informative?

  Yes. Please note the expection described in (11) to which the WG
  defers any decision to the IESG.

(14) 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 plan for their completion?

  The document build up on JSON specs, de-facto standard despite being
  defined in an Informational RFC. A fix for such an incostincency is
  being worked on by APPSAWG. Pragmatically the WG does not see any
  issue with referencing such a document in the normative section. The
  process-wise decision is deferred to the IESG.

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  Two downrefs, one to IEEE Standard 754, supposedly compliant with RFC
  3967
, and on to RFC 4627 as described in (11) and (14).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

  The document requests registration of ten media types and the
  creation of three registries. All IANA actions have been carefully
  ponderated, in accordance to guidelines in RFC 5226.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  The document defines three new registries: an ALTO Cost Type
  Registry, an ALTO Endpoint Property Registry and an ALTO Address
  Type Registry. This is the minimum set identified in the working
  group for achieving proper extensibility of the new protocol.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks were required other than IDnits.
2012-10-02
13 Amy Vezza Note added 'Enrico Marocco (enrico.marocco@telecomitalia.it) is the document shepherd. '
2012-09-07
13 Richard Alimi New version available: draft-ietf-alto-protocol-13.txt
2012-07-11
12 Richard Alimi New version available: draft-ietf-alto-protocol-12.txt
2012-04-16
11 Enrico Marocco IETF state changed to In WG Last Call from WG Document
2012-03-29
11 Enrico Marocco No outstanding issues, starting WGLC.
2012-03-29
11 Martin Stiemerling Responsible AD changed to Martin Stiemerling from David Harrington
2012-03-11
11 Richard Alimi New version available: draft-ietf-alto-protocol-11.txt
2011-10-31
10 (System) Ballot writeup text was added
2011-10-31
10 (System) Last call text was added
2011-10-31
10 (System) Ballot approval text was added
2011-10-31
10 (System) New version available: draft-ietf-alto-protocol-10.txt
2011-06-27
09 (System) New version available: draft-ietf-alto-protocol-09.txt
2011-05-20
08 (System) New version available: draft-ietf-alto-protocol-08.txt
2011-03-14
07 (System) New version available: draft-ietf-alto-protocol-07.txt
2010-11-09
10 Cindy Morgan Responsible AD has been changed to David Harrington from Peter Saint-Andre
2010-10-25
06 (System) New version available: draft-ietf-alto-protocol-06.txt
2010-07-16
10 Peter Saint-Andre Draft Added by Peter Saint-Andre in state AD is watching
2010-07-12
05 (System) New version available: draft-ietf-alto-protocol-05.txt
2010-06-01
04 (System) New version available: draft-ietf-alto-protocol-04.txt
2010-03-09
03 (System) New version available: draft-ietf-alto-protocol-03.txt
2010-03-04
02 (System) New version available: draft-ietf-alto-protocol-02.txt
2009-12-16
01 (System) New version available: draft-ietf-alto-protocol-01.txt
2009-12-16
00 (System) New version available: draft-ietf-alto-protocol-00.txt