Application-Layer Traffic Optimization (ALTO) Protocol
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. 126.96.36.199: 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.