Thanks for the comments Richard. Responses online....
On 3/1/09 10:52 AM, "Y. R. Yang" <[email protected]> wrote: > > 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? Okay by me. My confusing was if this was the interface between client and server, client and "service" or something else. > >> 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." I think the most important is to say that between say, client and server, there must be one protocol. This protocol supports many types of queries. Is that what you mean by "a set of interfaces"? > >> 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. Sounds okay. > > >> 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. Okay, thanks. > ...snip... >> >> 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. I agree, just that... I think there is a confusion/mix between amount of data vs. precision. You can have very fine-grained precision and still exchange small amounts of data. It depends on the number of peers/servers that are providing data or maybe if there are caches around, etc. In other words, high precision/quality of data does not mean tons of data. > >> 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? Yes, agreed. > > > Thanks. > > Richard > >> Thanks, >> >> Reinaldo _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
