Henry, I don't know what I can do to convince you I am not lying. I have said many times that there are other open source implementations of P2P SIP proposals in addition to the fine work from Columbia. Cisco has open source one that I have helped with. You can get it yourself from the b-20070702-p2p branch of the resiprocate.org site. Or browse the code at http://svn.resiprocate.org/rep/resiprocate/branches/b-20070702-p2p/ . It is under a BSD like license. This was provided as open source for the general public on September 17, 2007 which I suspect was actually before any others were publicly available. I announced that this existed at the microphone in one of the p2psip adhocs. I have told you this several times in person. It upsets me when you say this does not exist. I really don't know what to say.
I have also see demonstrations of the P2PSIP system Bruce is working on. It's real - I imagine that several other people on this list have also seen it. Perhaps they can collaborate my story that they really have seen it to help convince you I am not lying. Cullen On Mar 15, 2008, at 9:06 AM, Henry Sinnreich wrote: > Leaving the process issue aside for a moment, it is useful to look at > the root causes of the problem. One of them is the authors clearly did > not have time for this document, let alone do research and run code, > except for Columbia University. > > Most authors of the (overly large number as has been pointed out) > document are truly world class and no doubt the best in the IETF. > Reload-03 has not had the benefit of their expertise and capability by > any stretch of the imagination. > > So the core issue #1 is IMO: Do the listed authors really want to make > the tough choice of dedicating their time and priorities to P2P and > give > up all countless other engagements to provide such time and focus? > _P2P > work cannot be delegated_. > > What about #2 generating and sharing code as the Columbia University > folks have done? Or are we expected to trust invisible work and > assurances that code and measurements we cannot see are more than a > claim? > > My understanding from the meeting is the P2PP authors will take a turn > to edit the next version of the document and also the name may be > changed. > > Yes?/No ? > > So let's keep our fingers crossed... > > Henry > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Spencer Dawkins > Sent: Friday, March 14, 2008 11:34 AM > To: P2PSIP Mailing List > Cc: Lars Eggert; Jon Peterson > Subject: Re: [P2PSIP] Just to be clear... > > I agree with Dean on several points. One difference - I am not > concerned > > that the ADs might be pushing (we have both RAI ADs in this room plus > more > ADs than most WG meetings, so anything suspicious that I'm missing is > happening in front of witnesses). > > Like Dean, I don't have concerns that this draft is being strong- > armed, > but > like Dean, I also have a sense from listening to people that (for > example) > it wasn't even worth getting up at the mike and saying "I think this > other > proposal should be considered". > > I especially agree that a clearer, revised draft will make it easier > to > agree that we are doing the right thing if we do what it looks like we > are > going to do. > > I believe that the short interval between IETF 70 and IETF 71 forced > the > > slamming merge that we saw, and I believe the slamming merge output > explains > the rest of the problematic situation. No harm, no foul, but we need > to > LOOK > as "clear" (procedurally) as we are. > > In summary... this was only a small elephant, but it is an elephant. > It > could even be a nice pet elephant, but we need to make sure that we > don't > trip over it while walking through the room. > > Thanks, > > Spencer > > From: "Dean Willis" <[EMAIL PROTECTED]> > >> On Mar 14, 2008, at 10:17 AM, Spencer Dawkins wrote: >> >>> I really AM thinking that RELOAD-04 will be adopted as a working > group >>> item >>> after it is submitted (under whatever name is finally chosen). >>> >>> Is anyone expecting something else to happen? >>> >> >> Since it is my apparent self-appointed role to point out the >> elephants > in >> the room . . . >> >> There are people who feel that RELOAD is being "strong- >> armed" (coerced > by >> people with procedural authority) into place. I've personally heard > this >> perception expressed by several working group participants, even > though I >> don't have the same perception. This sort of problem happens anytime > a >> candidate draft has contributor support from a chair, area director, > or >> area technical advisor (and RELOAD has all three!). The WG's only > counter >> is to be meticulous about the application of process and propriety > with >> respect to such a draft. >> >> The relative unreadability of the hastily merged RELOAD draft makes >> comparing and discussing the merits/demerits of the proposal against >> alternatives difficult. >> >> Strong pressure from the chairs, ADs, and area technical adviser to > adopt >> the draft in the light of this "difficult to compare and discuss" >> condition aggravate the perception of being "strong-armed" >> >> I believe that a more mature draft will eliminate the argument that >> debate on the technical issues is too difficult. >> >> So once we have a better draft, people will either have good >> technical > >> arguments against the proposal or will be willing to accept the > proposal >> as a consensus position. >> >> In the end, I expect that the RELOAD draft will be accepted as the WG >> baseline document. But we need to more-than-fairly exercise the > process >> to get there if we want the working group to continue to move > smoothly. >> >> -- >> Dean >> > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
