Sebastian, Please see inline for my responses. I've explicitly ack'd some of your responses to indicate the changes you've made have addressed my previous comment.
On 11 May 2011, at 10:58, Sebastian Kiesel wrote: > 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. It wasn't in the -09 version I downloaded. >> 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. OK. It might be worth including a short RFC Editor's note to instruct them to normalise the numbering on publication. >> 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... I have significant concerns with the idea of the WG producing multiple competing ALTO protocol specifications but that's a conversation to be had if any alternative proposals are brought to the WG. >> 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. I am OK with the intent and the actual text in the abstract. What I object to is ARv08-5 strengthening that into "MUST be compliant" as I am not sure what the expectation is for a protocol specification to demonstrate such compliance. I assume it MUST provide protocol mechanisms for all MUST-level requirements in this document and also for SHOULD-level requirements otherwise it MUST provide justification for their absence. That would appear to be stating that the scope of the document is not a set of requirements "that should be considered when specifying, assessing, or comparing protocols and implementations" but is in fact a formal compliance checklist. Additionally given that some of the requirements appear to be aimed at the client protocol specification and others appear to be aimed at ALTO server implementations or ALTO discovery mechanisms then if the intent is to mandate compliance in order to be able to call something ALTO I think you need be more explicit about which requirements apply to the protocol specification Versus individual implementations >> 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. I much prefer the new text of ARv09-6 & -7 to ARv08-6,7,8,9. However I would suggest removing "It is also possible to specify a broader address range (i.e., a shorter prefix length) than the intended group of hosts actually uses, in order to conceal their exact identity." because it's simply a statement of fact [it is possible to do many things :-)] and not a requirement that influences the protocol specification. Or alternatively make it into a MUST level requirement but ARv08-52 already covers that use case I think. >> 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. Ok I now understand the intent. However, I think the text of ARv09-10 could be improved, e.g. "SHOULD be made available by the same entity that wants to use these host group descriptors within the ALTO client protocol" is getting quite specific about the possible implementation, how about something like: REQ. ARv09-10: Protocol functions for mapping other host group descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and specified as part of the ALTO client protocol. The corresponding address mapping information SHOULD be accessible via the ALTO client protocol. However, an ALTO server or an ALTO client MAY utilise an external mapping facility, e.g., a translation table obtained via an alternative mechanism. >> 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. OK I missed that. >> 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. Thanks. The second sentence of ARv09-14 appears to duplicate the text of ARv09-15 ("The ALTO client protocol specification MUST define an appropriate procedure for adding new rating criteria types, e.g., by establishing an IANA registry.") I guess that's a copy & paste error :-) >> 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? Ah I understand the intent now. Yes making the change you suggest would clarify the intent perfectly. >> 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. Ok. I personally do not like the references to query/response messages as it comes across as a specific solution rather than a requirement but I won't get too hung up about it :-) >> 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. OK I think text such as the following might make that clearer/more explicit: The ALTO query message SHOULD allow the ALTO client to express which rating criteria should be considered, as well as the order in which to apply the rating criteria for the specific application that will eventually make use of the guidance. >> 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 I struggle to see that myself. For example I can easily look at a protocol specification and determine what assumptions it makes regarding encoding & transporting information. I can not easily look at a protocol specification and determine if it is possible to embed it in all possible third party applications. >> 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. OK. >> 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..." That would clarify the requirements as stated (BTW there are many other requirements throughout the document that refer to "The ALTO client protocol") However, my original point was really that maybe ARv09-25 (ex-ARv08-28) should really be: "The ALTO client protocol MUST support both the target-aware and the target-independent query mode." Different implementations may decide to support only one mode but any protocol specification should define both IMO. >> 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. Ok. >> 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. OK I don't see any value in such a mechanism myself. >> 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. Ah I think I see. The requirement is talking about an ALTO client being able to communicate with an ALTO server when NAT is in the middle. That's a well understood problem. At first I assumed you were making a statement about the ALTO protocol having to support scenarios where the same private IP address may be assigned to multiple consumers/clients that exist in multiple places in the network and that is not a well scoped problem in the context of ALTO IMO (the current ALTO protocol draft doesn't support such a scenario for example). >> 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. Ok >> 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. 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. I see but I still think it needs to be explicitly clarified that this section does not apply to the ALTO client protocol specification conformance requirement stated in ARv09-5. >> 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 Ok I won't get hung up about it :-) >> 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. Ok >> 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. Is it only meant to apply to host descriptors (in which case can that be made more explciit?) or is it meant to convey that any item of information MUST be supported at different levels of details. For example, I could intepret it to mean that the ALTO client protocol MUST support a mode where a client queries for a numerical cost between some set of Host Group Descriptors and the ALTO server responds with an ordinal ranking of the supplied Host Group Descriptors? Is that a mode of operation that it is intended that ALTO protocol specification MUST conform to? >> 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. Ok I can see that it could fit in either section. I'm not passionate about which one it goes in. >> 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. If it is a requirement on server implementation then it shouldn't be a requirement on the ALTO protocol. I'd suggest removing it as a requirement entirely as I don't think this document is the right place to be covering generic ALTO implementation & deployment details. IMO stating a server MUST support anti-DOS mechanisms is like stating that the server MUST scale to the required transaction rate for an operator. It's a reasonable thing for an operator to require from their vendors but a protocol requirements document isn't the place to document it IMO. Thanks Ben >> 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
