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? 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. 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. 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. 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..." 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. 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? 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. 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? 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? 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? Thanks, Reinaldo _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
