Hi Reinaldo, Thanks a lot for the wonderful feedback! Kiesel is the editor, and sure will respond to your great suggestions. Here are my take. Please see below.
On Fri, 27 Feb 2009, 12:57pm -0800, Reinaldo Penno wrote: > Hello, > > As a general comment, the draft does not feel like requirements and more > like a possible protocol solution and at the same time many REQs need to be > more specific about what the requirement actually is. > > I think this draft needs quite a bit of work. Are there plans for an update > for the next IETF? > > Specific comments: > > 1) "ALTO Interface" > > What is an ALTO interface? How about change to ALTO Query/Response Protocol? > 2) > > " REQ. 1: The ALTO service MUST implement one or several well-defined > interfaces, which can be queried from ALTO clients." > > This seems a recipe for interoperability issues. Standardization means in a > basic level lack of flexibility so people can interoperate. > > So, "ALTO must implement _one_ well-defined interface as specified in....". > Only one interface must be a MUST, otherwise people can pick and choose. How about change to "The ALTO service MUST implement a set of interfaces, which can be queried from ALTO clients." > 3) > > " REQ. 4: One mode of ALTO operation is that ALTO clients may be > embedded directly in the resource consumer (e.g., peer of an > unstructured P2P application), which wants to access a resource. > > However, another mode of operation is to perform ALTO queries > indirectly, via resource directories. These translate a resource > identifier to a list of resource providers with their corresponding > transport addresses. The resource directories may issue ALTO queries > to solicit preference on such lists, considering the respective > resource consumer." > > At this day and age of v4<->v6 transition we should try to avoid embedding > IP addresses from a client in a control protocol. You have NATs everywhere > and if we uphold the second mode of operation we would be asking for ALGs in > devices, and more importantly v4<->v6 ALGs. REQ. 4 is more on protocol design than requirements. How about the following wording: REQ. 4: One mode of ALTO operation is that ALTO clients may be embedded directly in the resource consumer (e.g., peer of an unstructured P2P application), which wants to access a resource. However, another mode of operation is to perform ALTO queries indirectly, via resource directories (e.g., tracker of an unstructured P2P application), who may issue ALTO queries to solicit preference on potential resource providers, considering the respective resource consumer. The ALTO protocol MUST support both modes of operation. > 4) > > " REQ. 6: The information available from the ALTO service is not a > replacement for congestion control mechanisms. Applications using > ALTO MUST ensure that they do not cause congestion in the network, > e.g., by using TCP transport, which includes congestion control > mechanisms." > > This does not seem to belong here. What we have here is basically an ALTO > draft mandating through a "MUST" how clients behave in the transport layer > in a requirements draft. I agree that this may not belong to here. Following your line, I also see problem with REQ. 5: The syntax and semantics of the ALTO protocol MUST be extensible to allow the requirements of future applications to be adopted. This requirement will be hard to objectively validate/test. We may revise this as your suggestion on REQ. 7, just say that the protocol should be extensible. > 5) > > " REQ. 7: Any application designed to use ALTO MUST also work > reasonably if no ALTO servers can be found or if no responses to ALTO > queries are received, e.g., due to connectivity problems or overload > situation." > > The word "reasonably" gives a wrong idea here. How reasonable? I suggest > just saying the "protocol should be robust..." Agree. > > 6) > > " REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after > a reasonable amount of time, or it MAY query a different server. > Otherwise, or if all retransmissions or queries to different servers > have failed as well, the ALTO client MUST report to the application > that no ALTO information is available. In this case, the application > has to perform the resource provider selection without ALTO guidance." > > The application is always free to perform resource provider selection > without ALTO guidance with or without failures. One does not follow from the > other. > > Moreover, this seems very protocol specific. I would bundle this with "ALTO > protocol must implement a retransmission strategy...". I suggest staying > away from exactly how it will be done, this would be in the protocol or some > other spec. Agree. > > 7) > > " REQ. 10: An ALTO client MUST limit the total number of unanswered > ALTO queries on a per-server basis. This limit MUST be reduced if a > request times out and MAY be increased if several subsequent queries > succeed without a timeout." > > > This is really, really implementation specific on both client and servers. > It is the same as dictating how HTTP client and servers will behave in > overloaded situations. Also, you seem to imply some sort to incremental > increase in the protocol if responses are received on time. Are we > implementing some sort of congestion control and backoff on application > level? Agree. This is implementation and may be second order at this stage. Your suggestion below makes sense. > 8) > > I would suggest leaving REQ-10, REQ-11 and REQ-12 our of this draft and > work on these items in a future "overloading draft" where we hash out > requirements, specific messages, etc. These requirements will complicate > the protocol unnecessarily at this stage. I'm not saying we should not > do it, just saying to postpone it for this iteration of the charter or > leave to possible extensions by vendors. > > Again, protocol design needs to allow us to build upon it (already > covered in another REQ), but the implementation needs to start simple. > > 9) > > " REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO > client can specify the required level of precision. If only a medium > amount of data has to be exchanged, it may be sufficient to get a > quick answer from the ALTO service, which results in a certain > improvement compared to a resource provider selection without any > ALTO guidance. If, however, very large amounts" > > > This is very vague. What is medium, what is large? For which networks, > types? Mobile, FTTH? I think this should be rewritten without talking about > precision. There are other reasons to want less information such as less > reduced memory and power such mobile devices. In P4P design field tests, we tried different granularities of information (e.g., Comcast fine-grained, coarse-grained). How about REQ. 13: The ALTO protocol MAY have a mechanism to allow different granularities (e.g., IP level, subnet level, or higher level of abstraction) of information to be exchanged. > 10) > > " REQ. 16: Different instances of the ALTO service operated by > different providers must be able to coexist." > > Why this is under security and privacy? Can you expand on this req? I agree. This does not belong to here. > > 11) > > "REQ. 17: The ALTO protocol MUST support mechanisms for mutual > authentication and authorization of ALTO clients and servers." > > Must support "a" mechanism....Otherwise we are saying the protocol will be > able to negotiate between different authentication and authorization > schemes. Are we? > > I'm not even sure this needs to be a MUST but I have no strong feelings > about this. ALTO will probably be a add-on to protocols like Bittorrent > running in the background, so in practical terms, are we assuming the user > will put username and password, implement TLS, etc? How does this > requirement translate to the actual protocol, ISP and user experience? ALTO may not be an add-on to protocols like BitTorrent. A setting is the following: an ALTO Server gives different information to different ALTO Clients (e.g., an ISP gives more information to its own CDN network than to public P2P applications). Then authentication is needed. Does this make sense to you? > 12) > > " REQ. 21: If the ALTO protocol supports including privacy-sensitive > information (such as resource identifiers or transport addresses) in > the ALTO queries or replies, the protocol MUST also support > encryption, in order to protect the privacy of users with respect to > third parties." > > Quite a tall order. The user might be using a legal P2P streaming service > and does not care about privacy and confidentiality. > > I think this needs to be reworded. Just because a resource identifier is > present in the query, does not mean encryption is automatically needed. If > we say ALTO is going to work over TLS or something like it, we need to > specify how exactly this will work. It took quite some time for SIP over TLS > to converge. > > Are we going to do that on the protocol spec, an ALTO over TLS spec? Nice comment. I do not have strong feeling on doing in the ALTO protocol directly or ALTO over TLS. I feel that ALTO over TLS is easier (https). Any comments from others? Thanks. Richard > Thanks, > > Reinaldo _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
