Hi Vidya, Comments inline. (I've only preserved the points I have comments on. Others are fine with me.) Thanks, yushun > -----Original Message----- > From: p2pi-bounces@xxxxxxxx [mailto:p2pi-bounces@xxxxxxxx] On Behalf Of > Narayanan, Vidya > Sent: Wednesday, October 22, 2008 5:51 PM > > > -----Original Message----- > > From: ietf-announce-bounces@xxxxxxxx > > [mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of IESG Secretary > > Sent: Monday, October 06, 2008 1:36 PM <...> > > A significant part of the Internet traffic today is generated > > by peer-to-peer (P2P) applications used for file sharing, > > real-time communications, and live media streaming. P2P > > applications exchange large amounts of data, often uploading > > as much as downloading. In contrast to client/server > > architectures, P2P applications often have a selection of > > peers and must choose. > > Add: "Peer selection is also a problem that has many different > applications in p2p systems - e.g., identifying the best peer to > download content from, identifying the best super peer to contact in a > system, using the best relay for NAT traversal, identifying the best > next hop for a query based on several criteria (e.g., quality, > reputation, semantic expertise, etc.), etc." I actually think the proposed addition is somewhat redundant, and could easily lead into ratholes on what are the metrics for "best" and whether it is even possible to get the best. The current charter tries to avoid that by saying "better-than- random" selection gating mostly on getting better performance and lowering the costs (as two examples). Also, what's the "best" depends heavily on whom you ask. ISP's notions of "best" may not align with those of the end users. I am fine with the examples (targets for selections), but let's try to avoid the debates on "best" again. <...> > > yet applications have at best incomplete > > information about the topology of the network. > > s/incomplete information about the topology of the network/incomplete > information to help the selection, e.g., topology of the network. I'm neutral to this. I think the intention is to narrow the initial scope to avoid confusion w/ TANA. The charter does leave the door open to future re-chartering/work. <...> > > Other usages will be considered as extensions to the charter > > once the work for the initial services has been completed. > > I think we should delete the sentence above. While it may seem redundant, I don't see anything wrong with that. It just means we may have a narrow scope now, but we will think about new extensions once we are done. <...> > > When the WG considers standardizing information that the ALTO > > server could provide, the following criteria are important to > > ensure real feasibility. > > In the context of standardization, I don't think we should be trying to > evaluate the importance of any information. The idea for us should be > to standardize mechanisms to exchange peer selection related > information. The value of the actual information exchanged is very > contextual and not for general evaluation. I read the list below somewhat differently. These are not for relative importance of the information, but kind of a min bar for what we want to do. While some may need re-wording, the intent is fine, IMO. > > - Can the ALTO service technically provide that information? > > - Is the ALTO service willing to obtain and divulge that information? > > - Is it information that a client will find useful? > > - Can a client get that information without excessive privacy > > concerns(e.g. by sending large lists of peers)? > > - Is it information that a client cannot find easily some other way? > > > > After these criteria are met, the generality of the data will > > be considered for prioritizing standardization work, for > > example the number of operators and clients that are likely > > to be able to provide or use that particular data. > > The above again gets into our evaluation of what is important based on > what we know today and is limiting. This point does need some clarification and rewording. Thanks, yushun _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf