Colleagues, Today I read draft-ietf-alto-reqs-08 in detail and my reading of the draft generated a number of comments which I have detailed below.
I appreciate that WG Last Call for draft-ietf-alto-reqs ended on the 25th February and that therefore my comments are somewhat late, for that I apologise and can only offer the excuse that I was not actually active in ALTO work during the Last Call period. I hope my comments can still be taken into account as I believe that addressing them will result in am improved document. My comments: 1) I'm not sure it's reasonable to reference the ALTO Charter without giving a link as the charter will change over time and the reference is likely intended to be a reference to a historical version of the charter. The current [ALTO-charter] reference refers to the Feb 2009 charter for which a suitable link may be: http://tools.ietf.org/wg/alto/charters?item=charter-alto-2009-02-11.txt 2) The requirement numbering appears to embed the draft's version number within the requirement number. Is the intent to remove that when published as an RFC and have numbers like AR-1? 3) Throughout the document I find the use of "client protocol" confusing. Surely it is just the "ALTO protocol". draft-ietf-alto-protocol-07 does not use the term "client protocol" at all. 4) ARv08-1 would appear to be redundant as it essentially states "An ALTO server MUST implement the ALTO Protocol" which is simply obvious and I wouldn't think need to be explicitly stated, although stating it is harmless. 5) The same comment as for ARv08-1 applies to ARv08-2 except s/server/client/ 6) ARv08-3: The format of the ALTO query message MUST allow the ALTO client to solicit guidance for selecting appropriate resource providers. I'm struggling to parse what this requirement actually means. I think what is trying to be conveyed is that the ALTO protocol MUST support a service to enable an ALTO client to present a list of candidates resource providers and have the ALTO server provide guidance on the ranking of those candidates? I don't see what that really has to do with the format of query message. 7) Similarly for ARv08-4 if there is a requirement for the ALTO protocol to support a service where to ALTO server offers guidance to clients is it really necessary to explicitly state that the format of the ALTO response message MUST support encoding that guidance. The phrase teaching granny to suck eggs comes to mind. 8) REQ. ARv08-5: The detailed specification of a protocol is out of the scope of this document. However, any protocol specification that claims to implement the ALTO client protocol MUST be compliant to the requirements itemized in this document. I'm not sure what is meant by "MUST be compliant" in this context - the ALTO protocol it MUST include protocol elements for all MUST requirements, for all MUST & SHOULD requirements, something else? Anyway this requirement seems aimed at setting some ground rules for comparing different proposed protocol solutions against one another and as far as I can see there is only one candidate protocol being developed and therefore the requirement would seem somewhat redundant. 9) REQ. ARv08-6: The ALTO client protocol MUST support the usage of several different host group descriptor types. "MUST support … several" is very vague for a MUST level requirement. A pedant could say a protocol that only supports 3 different host group descriptors is sufficient and I don't think that's really the intent of the requirement. I would suggest re-wording/re-structuring ARv08-6, ARv08-7, ARv08-8 & ARv08-9 to more clearly express the following intent (if you agree I can work with the authors to produce exact text): - The ALTO protocol MUST support Host group descriptors of type IPv4 prefix & IPv6 prefix - The ALTO protocol MUST be extensible to enable support of other host group descriptor types in future, for example by explicitly typing host group descriptor records and maintaining an IANA registry of defined types. - The ALTO protocol MUST define a minimum set of host group descriptor types that MUST be supported by all implementations in order to aid inter-operability. 10) ARv08-11 & ARv08-12. While the intent of these requirements may be laudable I really struggle to envision how they could actually be implemented or whether they are actually achievable in all circumstances. 11) ARv08-14 appears to be a duplicate of ARv08-13 12) ARv08-15 is similar to ARv08-6 in that it states the protocol "MUST support … several" and the following requirements 16, 17 & 18 are similar than requirements 7, 8 & 9. I'd suggest removing ARv08-15 and then either inserting a requirement between 17 & 18 (or including some text in 18) to state that the protocol MUST be extensible to enable the support of new rating criteria. Also you may want to consider explicitly stating what the "basic set of criteria types, which MUST be supported are". "Relative operator's preference" is obviously one as it's an explicit requirement for the protocol to support it but are there others? 13) REQ. ARv08-20: Applications using ALTO guidance MUST NOT rely on the ALTO guidance to avoid network congestion. Instead, applications MUST use other appropriate means, such as TCP based transport, to avoid causing excessive congestion. I struggle to see the relevance of the second sentence to the requirement. The first sentence essentially says "in the presence of congestion you MUST NOT rely on ALTO to avoid that congestion" which seems reasonable, however the second sentence says "applications should avoid causing excessive congestion" which doesn't appear to relate to the requirement to not use ALTO to avoid congestion that has already been caused (quite possibly by a different application/client/user). I'd suggest removing the second sentence. 14) ARv08-21 & 22 are similar to ARv08-3 & 4. I don't think the query message/response is relevant. I think you want the protocol to allow an ALTO client to request guidance based on the client's preferred rating criteria. Also ARv08-21 mentions the client being able to express a relative relevance between different rating criteria but it is unclear to me how an ALTO server could satisfy such a requirement given that it may not be possible to directly compare (and therefore order) different rating criteria. If this part of the requirement is to remain I think you need to be more explicit about what you mean by "relative relevance" 15) ARv08-24 & 25. I don't think the placement of the ALTO client relative to the ultimate consumer of the information really affects the mode of operation of the protocol. I think what you want to express is: - An ALTO server MUST NOT assume that the ALTO client making requests will be the ultimate consumer of the information contained in any response. - The ALTO protocol MUST support embedding any required consumer related information in the protocol itself. 16) ARv08-26. Do you really mean to restrict this requirement to only separation from "the operator of the IP access network" or do you actually mean to say "The ALTO protocol MUST be designed in a way that the ALTO service can be provided by an entity which is not the operator of the underlying [IP?] network"? 17) REQ. ARv08-28: The ALTO client protocol MUST support at least one of these two modes, either the target-aware or the target-independent query mode. REQ. ARv08-29: The ALTO client protocol SHOULD support both the target-aware and the target-independent query mode. Do you really mean this? I can see that an implementation may only want to support one or other mode, but if both modes are valid then surely the protocol itself should provide support for both and I believe the ALTO protocol spec does in fact support both modes. 18) REQ. ARv08-30: The ALTO client protocol SHOULD support lifetime attributes, to enable caching of recommendations at ALTO clients. What is a "lifetime attribute"? It implies to me an attribute that is permanent whereas I suspect you really mean "a TTL or similar mechanism, to enable caching"? 19) REQ. ARv08-31: The ALTO client protocol SHOULD specify an aging mechanism, which allows to give newer recommendations precedence over older ones. I don't really understand the motivation for this requirement. Surely more recent responses always take precedence over earlier responses? I'm struggling to see a situation where a client would receive a "younger" recommendation before an "older" one and need the capability to say "although I received recommendation X after recommendation Y I can see that Y is younger so I will discard X". 20) ARv08-33 is pretty vague. I'm not sure a requirement that essentially states that the protocol MUST support scenarios where the client is behind NAT by itself is implementable. Are there specific use cases that could be articulated that the protocol needs to accommodate for? 21) REQ. ARv08-40: An ALTO server, which is operating close to its capacity limit, MUST be able to inform clients about its impending overload situation, and reject new conversation attempts. I'm not sure how this would be implemented. If the server is able to inform the client about its impending overload, has it not by definition already entered into a conversation with the client and therefore the situation is already covered by ARv08-39? 22) In the first sentence of section 3.2 I think "one or more" is better language to use rather than "one or several". I would also s/is supported/may be supported/ Additionally the introduction text in section 3.2 seems to end rather abruptly and not be entirely related to the rest of the section. Was there an intent to have some additional text, for example "The following requirements apply to any ALTO server discovery mechanism"? 23) ARv08-41, 42, 43 & 44. Is there really any value in separating out requirements between "resource consumer initiated ALTO server discovery" and "third-party ALTO server discovery" given that the requirements are actually identical? I think the actual requirements are: - An ALTO server discovery mechanism MUST support ALTO server discovery by ALTO clients irrespective of whether the ALTO client will be the ultimate consumer of the ALTO information or whether the ALTO client will be making queries on behalf on another entity which is the ultimate consumer. - ALTO clients MUST be able to perform ALTO server discovery irrespective of whether they or the ultimate consumer of the ALTO information are located behind NAT. 24) ARv08-49, 50 & 51. The intent is not that authentication and encryption mechanisms MUST be built-in to the protocol itself but that the requirement can be adequately met by a substrate over which the ALTO protocol operates (e.g. mechanisms already provided by HTTP/HTTPS)? 25) REQ. ARv08-52: The ALTO client protocol MUST support different levels of detail in queries and responses, in order for the operator of an ALTO service to be able to control how much information (e.g., about the network topology) is disclosed. Is this really a requirement on the ALTO protocol or is it a requirement on the ALTO server? The same comment also applies to ARv08-54. 26) ARv08-53. This requirement seems related to ARv08-32 on reuse of responses and may be better place after that requirement to make the association between the two clearer. 27) REQ. ARv08-55: The ALTO client protocol SHOULD be defined in a way, that the operator of one ALTO server cannot easily deduce the resource identifier (e.g., file name in P2P file sharing) which the resource consumer seeking ALTO guidance wants to access. Is the intent A) A P2P (or other) client does not want to expose themselves or their clients to revealing the actual resources they intend to access/distribute; or B) A P2P (or other) client may be willing to reveal the resource they intend to access to their local ALTO server but does not want that information being redistributed? Given that ALTO is independent of resource identifier and is about relationships between end points not between resources it seems to be an irrelevant requirement. Or if the intent is (A) it is probably better stated along those lines, e.g. that the ALTO protocol SHOULD NOT require the specific resource to be accessed to be included in ALTO requests. I can see that an ALTO server may want to return different responses depending on the category of resource (or possibly more precisely the category of consumer) and we don't want to preclude that, e.g. returning a different response to a P2P client than it would to a CDN. 28) REQ. ARv08-56: The ALTO client protocol MUST support appropriate mechanisms to protect the ALTO service against DoS attacks. Is this actually a requirement on the protocol itself, i.e. that it needs specific protocol machinery to protect against DoS attacks or is it a more general requirement on server implementation and deployment strategy? 29) Section 5.2.1 & 5.2.3 cover a number of potential security issues and cite examples of how they may be addressed. It might be useful to also refer to specific requirements stated earlier in the document that address those scenarios. Even if not included directly within the document such an exercise (if it hasn't been done already) might help to ensure a possible requirement has not been inadvertently overlooked. Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
