Ben, Thanks for the extensive review. Martin and I have posted a new version of the draft (-09) yesterday, which addresses many of your comments.
So far we only made changes that make the doc clearer to read but did not change the intention of any requirement. Therefore we did not resolve all issues. Please see inline below as well as separate email threads for more details on specific issues. On Fri, Apr 29, 2011 at 12:52:49PM +0100, Ben Niven-Jenkins wrote: > 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 ok, fixed. > > 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? yes, this is the intent. as numbering of the reqs changes whenever we add or delete a req, we decided to have a unique numbering for every version of the draft. > 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. RFC 5693 defines the term "ALTO client protocol" and draft-ietf-alto-protocol-07 is one possible protocol specification. See also next comment... > > 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. Although draft-ietf-alto-protocol-07 is the only active WG item that specifies an ALTO client protocol, the ALTO reqs draft assumes that there can be several different protocols, as have been in the past. I also heard about rumors that there might be alternate protocols appearing soon... See also the abstract: This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations. ARv09-1 to -5 aim at setting ground for this multiplicity, by defining the very basics of ALTO: It is a client-server-protocol, with the client asking for guidance wrt. peer selection and the server providing that guidance. There may be many protocols, but if you want to call your protocol ALTO you have to fulfill these requirements. > > 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. ok, fixed. > 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. In the early days of this WG there were proposals that the ALTO server could give guidance to P2P apps like "prefer peers in AS (autonomous system) No. ???" or "avoid peers in <country of the world>". This is problematic as p2p software nowadays usually doesn't know about AS numbers etc, it only knows about the IP addresses of candidate resource providers it has to select. The intent of these requirements is to discourage using hosts group discriptors other than IP addresses. However, we do not want to prohibit it, given that there is a reasonable mapping mechanism provided. The PID mechanism specified in draft-ietf-alto-protocol-07 is IMO OK. > 11) > ARv08-14 appears to be a duplicate of ARv08-13 No, the roles of client and server are interchanged. These two requirements used to be one, but there were comments that some clause about informing "the other party" is difficult to understand. > > 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? OK, fixed. > 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. The intent of this req is: Nobody should ever try to use ALTO for providing a map with current link/path capacities (or even worse: provisioned link/path capacities) and then allow the clients to send data at the indicated rates without any additional congestion avoidance strategies. In other words: ALTO is not intended as admission control system. I guess we should better change the first sentence to "... MUST NOT rely on the ALTO guidance to avoid ***causing*** network congestion ..." does this make sense? > 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. ARv08-3 & 4 aim at defining the very basic mode of operation for ALTO. ARv08-21 & 22 are about dealing with multiple rating criteria within one query. > 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" In the sorting oracle query style, it is useful to have a second sorting criterion if two candidate resource providers are equal or very similar according to the primary criterion. > 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. technically we agree but we think that the old wording is better in the sense of having a checklist for assessing protocol specs or implementations > 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"? ok. fixed. > > 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. in the sense of my reply to your comment no. 8) we should change this to "An ALTO client protocol..." > 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"? yes. fixed. > 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". the original idea was to have some kind of soft fade-out of recommendations instead of switching from 100% to 0% consideration at the end of the TTL. We're discussing with the proponents of this idea whether this still makes sense. > 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? Again, this is due to the idea that there might be several protocols. For the current draft-ietf-alto-protocol-07 using HTTP transport the req is fulfilled. But please do not design an alternate prococol using FTP-style backconnects, etc. > 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? ok. removed. > > 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/ > ok. > 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"? The problem here is that this section basically enumerates use cases that have to be supported by the set of (one or more) discovery protocols as a whole, not by an individual 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. technically we agree but we think that the old wording is better in the sense of having a checklist for assessing protocol specs or implementations > 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)? right. made it more explicit. > 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? it is a req on the protocol, e.g., it should be allowed to give an IP prefix instead of a single IP address for describing a host, in order to obfuscate the host's identity. > 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. The intent of this req ist to say "we do not want to use DRM (digital rights management) to prevent ALTO clients from redistributing the guidance they received". That's why this req is in the security&privacy section. > 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. see Martin's separate mail on this topic. > 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? the latter - again in the sense of a checklist for assessing implementations. > 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. right. we are checking how to make crossrefs to the req. numbers. Thanks Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
