To answer your question about participation, I can definitely volunteer to work on the requirements and solution for this effort. We will try to produce a draft explaining the problem and need for peer participation in ALTO by the deadline for Minneapolis. With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, was brought into the IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now into a WG proposal for APP with little to no explanation to the wider audience on the rationale. So, it may be best if we didn't really get into the process discussion with this effort. I'm just hoping that at this stage, the ADs are going to hear all opinions and also use technical judgment on the relative points that are being made. Best regards, Vidya > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@xxxxxxxxxxxxxxxxx] > Sent: Thursday, October 16, 2008 12:34 PM > To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani > Cc: p2pi@xxxxxxxx; ietf@xxxxxxxx > Subject: RE: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Vidya, > > >This would be a big mistake on our part. b) is not a > research problem > and it is very much related to the same problem being solved in ALTO. > > Personally, I can see that there is value in "b): information > that peers decide to make available about themselves to other > peers for this purpose". Your example below was information > about whether a client is on a wireless network. In an > earlier thread, I had suggested that clients may want to > reveal their "available access bandwidth" in a similar > fashion; see > <http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.ht ml>. So even as an "ISP person", I can see where you are coming > from. > > But if I am interpreting RFC 2418 correctly > <http://tools.ietf.org/html/rfc2418>, it is not sufficient to > decide if "b)" is a worthy IETF activity, but that there are > enough participants working on "b)" for an IETF effort to be > successful. Quoting from parts of RFC 2418 section 2.1: > > "Is there sufficient interest within the IETF in the working > group's topic with enough people willing to expend the effort > to produce the desired result (e.g., a protocol specification)?" > > "Is there enough expertise within the IETF in the working > group's topic, and are those people interested in > contributing in the working group?" > > "Does a base of interested consumers (end-users) appear to > exist for the planned work? Consumer interest can be > measured by participation of end-users within the IETF > process, as well as by less direct means." > > You said: > > >Given that Lisa is looking for solutions, I almost wish I have a > solution thought out :) But, I don't. > > Are you volunteering to work on requirements and/or solutions > for "b)"? > Would others? > > (I may be interested and supportive in the future, although > right now I am predictably focused on activities related to "a)".) > > If there isn't a quorum to work on "b)" right now, this could > be revisited in the future with a re-charter of ALTO, when > such a quorum does exist. > > If there is a quorum, it would be helpful to hear about it. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@xxxxxxxx [mailto:p2pi-bounces@xxxxxxxx] On > Behalf Of Narayanan, Vidya > Sent: Wednesday, October 15, 2008 7:48 PM > To: Lisa Dusseault; Vijay K. Gurbani > Cc: p2pi@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization > (alto) > > Lisa, > > > > > > > There's plenty of work to do in a). My recommendation based on > > estimation of appropriate scope as well as an estimation of the > > consensus here, would be to do that first -- to have a > charter that is > > scoped to (a). Then the possibilities for > > (b) include working in the P2P research group, individual > submissions, > > and /or a new BoF/WG. Another option would be a future > charter update > > for ALTO if it's successful and there's consensus for it to be the > > basis for (b). > > > > This would be a big mistake on our part. b) is not a > research problem and it is very much related to the same > problem being solved in ALTO. > Letting each p2p application come up with its own mechanism > of doing b) only kills the interoperability and > extensibility. We keep talking about scope creep here, but, > we seem to miss something critical. By not keeping the > related problems together in producing solutions, we are only > increasing the number of different mechanisms that are going > to be needed in future to provide this one service - I cannot > understand why that is a good thing. > > Without allowing for b), I think information that a) gives > you can be more or less useless in some circumstances. Let > me provide some additional context here. One of the pieces > of information that is important to allow wireless devices to > participate in p2p networks is the basic fact that a given > node is wireless. This may place some fundamentally > different criteria on path selection decisions that cannot be > deduced simply with topology information. > > For any forward looking work we do at the IETF, we must stop > designing just for wired (and stationary) devices. These are > the designs that tend to look horrible when adapted to the > wireless (and mobile) world and I seriously hope that that is > not where we are headed with this work. > > Best regards, > Vidya > > > Lisa > > > _______________________________________________ > p2pi mailing list > p2pi@xxxxxxxx > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf