Application-Layer Traffic Optimization (ALTO) Protocol
RFC 7285

Note: This ballot was opened for revision 25 and is now closed.

Spencer Dawkins Yes

(Martin Stiemerling) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2014-02-07 for -25)
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.

(Richard Barnes) (was Discuss) No Objection

Comment (2014-02-05 for -25)
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.

(Stewart Bryant) No Objection

Comment (2014-02-05 for -25)
"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.

(Gonzalo Camarillo) No Objection

Benoit Claise No Objection

Comment (2014-02-04 for -25)
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/

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-02-18 for -26)
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.

(Barry Leiba) No Objection

Comment (2014-02-17 for -25)
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...).

(Pete Resnick) No Objection

Comment (2014-02-19 for -26)
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.

(Joel Jaeggli) (was Discuss) Abstain

Comment (2014-02-14 for -25)
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.