Subject: [P2PSIP] Just to be clear...

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 10:17:05 -0400

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?

Spencer 

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Mar 2008 16:23:13 +0200

Let's be honest: The truely important question for most people is just 
who are the authors of the document.
 
The document will be quite likely modified to a large extend anyway as 
part of the usual working group process.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 10:38:59 -0400

I am not challenging Hannes here (one way or the other).

> Let's be honest: The truely important question for most people is just who 
> are the authors of the document.

That's unfortunate. RELOAD-03 already has more authors than the IESG 
guidelines allow now (before the working group actually does any work), so 
this needs to be a minor consideration at most (although it may be a real 
consideration for specific authors).

> part of the usual working group process.

I expect this is likely true.

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Mar 2008 10:54:42 -0400

Reload-04 will undoubtedly have the same authors as present, but that is up
to them.

If Reload-04 is adopted as a WG item, the chairs will appoint an editor.
The editor will be charged with making sure the working group consensus is
reflected accurately in the text of the document.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Friday, March 14, 2008 10:23 AM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Just to be clear...

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 11:03:44 -0400

> Reload-04 will undoubtedly have the same authors as present, but that is 

I would not be a bit surprised.

> reflected accurately in the text of the document.

And that's the way I think the process works.

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 11:11:30 -0400

> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Mar 2008 17:19:48 +0200

The authors of RELOAD are well-known persons in the IETF; I have no 
doubt that they would work through the technical issues raised within 
the working group pretty quickly.

Brian Rosen wrote:
>> I really AM thinking that RELOAD-04 will be adopted as a working group
>>     
> item 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 11:30:08 -0400

> the working group pretty quickly.

Neither do I; but we cannot allow the perception that their standing  
allows their relatively immature draft to squelch ostensibly more  
mature drafts from participants who are newer to the IETF. All  
participants must be held to equitable standards. To do otherwise  
would reinforce the "secret handshake" reputation that has plagued the  
IETF for many years.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 11:33:38 -0400

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-masked]>

> 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.
>
> 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"
>
> arguments against the proposal or will be willing to accept the  proposal 
> as a consensus position.
>
> 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
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Mar 2008 17:38:05 +0200

> would reinforce the "secret handshake" reputation that has plagued the 
I certainly understand that.

I have to note, however, that based on my past IETF work the initial 
proposal (regardless of how mature it looked like) was substantially 
changed afterwards and a significant amount of work was done as part of 
the working group process even though some folks believed that their 
document is already 80% finished at the time when it was submitted as a 
working group item. This probably reflect the 80:20 rule.

Ciao
Hannes

---

From: "John Buford" <[email-masked]>
Date: Fri, 14 Mar 2008 13:37:26 -0400

I am wondering about the strategy of merging everything
into one mega-document.  Seems like there might be
advantages to putting modules in different documents.
For example I could see P2PP as a piece that could
stand alone.

John

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 15 Mar 2008 06:06:21 -0700

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-masked] [mailto:[email-masked]] 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...

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.

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

> Since it is my apparent self-appointed role to point out the elephants
in 
> There are people who feel that RELOAD is being "strong-armed" (coerced
by 
> Strong pressure from the chairs, ADs, and area technical adviser to
adopt 

> arguments against the proposal or will be willing to accept the
proposal 
> baseline document. But we need to more-than-fairly exercise the
process

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Mar 2008 13:10:06 -0400

The authors indicated they planned to split out a few parts into separate
documents.

They wish to avoid the "hitchhiker's guide" effect if the document is in too
many pieces. I agree; I'd rather see one longer document that several
smaller ones if it was hard to see the forest from the trees.

For the moment, it's up to them how they split it.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Buford
Sent: Friday, March 14, 2008 1:37 PM
To: Hannes Tschofenig; P2PSIP Mailing List
Subject: Re: [P2PSIP] Just to be clear...

John

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Mar 2008 13:10:06 -0400

Brian

-----Original Message-----

John

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 17 Mar 2008 16:18:00 -0400

I personally encouraged the merger.

The alternative was a beauty contest.  We have experience with such things,
and none of them are good experiences.  All of the candidate protocols had
several things to commend them to the work group.  All of them had faults
that were significant to more than a few participants.

I was very happy that all three of the leading candidate protocols merged.
The merger was messy.  It was uneven.  It was not pleasing to ANY of the
authors.  I talked to them about that before the meeting.  None were happy.
They made that clear in the meeting.  They did think that the merger was a
good idea, and they were confident that they could get a good protocol, and
a good protocol document, in relatively short order.

We knew there was opposition.  The opposition did not ask for agenda time.
We made some anyway.  We asked for supporters of alternatives to come
forward.  The SEP proposers want to make sure their ideas will be considered
in what ever protocol is brought forward.  We have asked them several times
if they wish to have SEP considered as the candidate protocol, or as ideas
to be incorporated.  They have always indicated the latter choice.

There was a great deal of discussion on the list that P2PP should be
considered instead of the merged protocol.  However, when it came time to
propose that formally, there was silence.  If someone had proposed that,
they would have been in the awkward position of being against the authors of
the P2PP protocol, who are part of the merged protocol author team.
However, no one proposed that we consider P2PP. 

The only protocol on the table currently is the merged protocol.  The
authors are free to do whatever they want, but I for one don't expect to see
a complete rework of the merge (i.e. I don't expect to see it look like P2PP
with additions).  I expect to see a more polished, readable document that
pretty much follows the design in the document now, with attention paid to
specific issues raised at the meeting and on the list.

Cullen does wear the AD dot.  In my dealings with him in p2psip since he
became an author, he has ALWAYS behaved as an individual contributor.  Jon
Peterson is the AD for this work group.  Jon has been interested in
progress, and generally positive in the direction we were going, but he has
not, to my knowledge, pressured anyone to do anything.  It is a complete
mischaracterization to claim any AD pressure.

You can claim that there was chair bias towards a merged protocol; I
specifically asked for the merger to happen, and I'm happy that it did.  You
can't claim, I believe, that we unfairly handle the issue.  We invited
alternatives, let the debate run on over its scheduled time, and reworded
hum "text" to suit participants.  That's the process.  Chairs are allowed to
encourage competing voices to come together, and are allowed to support the
result.  They must be fair to any dissenting voices.  I believe that is what
happened.

Personally speaking, I am very disappointed in the outcome.  What we have is
delay.  Instead of being able to move forward in many different dimensions,
we have to wait.  We'll try for list consensus after the merged protocol has
another draft.  It may be that everyone is happy, or it may be that some
alternative takes the work group by surprise.  I am very pessimistic that we
can discern consensus entirely on the list.  That means we are going to lose
an entire cycle, until Dublin.  I believe the delay is not recoverable; the
end date is set back.

Let me cite a specific example.  If we had a protocol document as a work
group item, it would have made sense to have an interim meeting to work on
two or three big items, say: data model and routing.  Without it, I believe
an interim meeting won't work: we'd be consumed with the present debate, and
something like this level of discontent cannot reasonably be settled in an
interim because participation is too limited. 

Another example: I had hoped to elicit volunteers to start work on torture
tests, interoperability testing rigs, service examples and other
accoutrements that, in the SIP experience, tended to follow deployments
instead of lead them.  That will have to wait until there is a protocol to
work from.

Nevertheless, the process did what it was supposed to do.  We looked for
consensus, didn't find it, and have a work plan going forward.  It was a
fairly good IETF moment, even if I was very disappointed.  If we voted, the
outcome could well have been different.  If we held meetings that went on
well into the next morning, and then voted, who knows what could have
happened.  Instead, the work group split, and the result was "do more work
and we'll try again".   

So yes, we encouraged authors to come together.  They did, thankfully.  We
did not "strong arm" anything.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Friday, March 14, 2008 11:12 AM
To: Spencer Dawkins
Cc: P2PSIP Mailing List; Jon Peterson
Subject: Re: [P2PSIP] Just to be clear...

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 18 Mar 2008 08:38:16 -0500

It is, of course, reasonable to point out that the chairs have to determine 
consensus on the mailing list, no matter what that sense of the room was, so 
if the sense of the room wasn't the right thing to do, this would be a great 
time for the working group to figure that out.

Thanks,

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Mar 2008 09:58:19 -0400

Well, we do have to wait until the minutes are posted (coming very soon I
hope).  Usually, the language we use is "confirm" consensus on the list.  In
this case, we had no meeting consensus.  I think it would be quite unlikely
that there will be list consensus given the result of the hum in the
meeting.  

Now, if we do see list consensus in some direction, great.

Just to be clear, in the meeting, there was no consensus to adopt RELOAD-03
as a working group item, and there was not even a proposal to adopt any
other document.  The sense of the room was to let the authors of RELOAD-03
do another revision, and then revisit the issue after that.  "Sense of the
room" means nothing, process-wise.  

Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 9:38 AM
To: Brian Rosen; 'Dean Willis'
Cc: 'P2PSIP Mailing List'; Peterson, Jon
Subject: Re: [P2PSIP] Just to be clear...

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Mar 2008 14:04:40 -0500

> room" means nothing, process-wise.

The document as it is barely reflects the consensus of the authors,  
and it fails to communicate such to the wider working group. It's just  
not ready. People who might propose an alternative quite possibly  
don't understand enough of the document to be able to frame their  
alternative.

I expect that most of the critical design goals of the working group  
will be met by the merged RELOAD proposal. I further expect most  
people that might propose an alternative will, in good conscience, be  
able to decide NOT to once they understand what's in RELOAD.

I further believe that when we have a clear and readable document that  
we will reasonably be able to ask on-list for a consensus around that  
document.

So, DON'T PANIC. Get the work done, and if it is as good as I expect  
it will be, consensus will appear.

--
Dean

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Mar 2008 14:10:44 +0100

Hey all,

There is something funny about this whole situation:

> don't understand enough of the document to be able to frame their  

If the draft is so unreadable and "not ready" (and there seems to be no
argument about this) then how come it is the only candidate that is
being seriously considered for adoption by the working group?

> will be met by the merged RELOAD proposal. 

I guess this answers my question and it would probably also explain most
of the tension that has been discussed in this thread. People generally
trust the authors of RELOAD to do a good job because of their background
 and reputation and because they have shown commitment to this group. I
guess this is also the point that Hannes was making.

I am not arguing about their ability to do so and I am actually quite
positive that they won't fail. Just as Brian I was disappointed with the
Philadelphia hums for pretty much the same reasons. I don't think that
RELOAD has been strong-armed by the chairs, nor by the authors, so
technically speaking I doubt there is anything procedurally wrong with
the whole situation.

However, we should stop pretending that everything went perfectly OK and
that the current situation is the mere result of applying IETF rules. I
think we would all agree (or at least I hope so) that the choices for
the mergers that led to RELOAD-03 were not entirely technical and were
greatly influenced by the relations between the authors of the
participating proposals. Again, there's nothing technically wrong about
this but it is probably not the most community friendly policy.

I guess this is where all the frustration is coming from: if it all
comes down to having a good reputation and IETF experience then why
should newcomers contribute in the first place?

Brian, I doubt there's any point in trying to convince everyone that the
process respected IETF procedures, I don't think anyone is contesting
this and insisting only makes things worse. There is also little need to
explain how badly the WG needs to move on. The fact that authors of
competing drafts did not ask that their proposals be considered as an
alternative, proves that they (we) are already aware of that.

However, it would probably be a good idea to try to understand what's
causing the commotion and think of how not to get into it again. If the
IETF is to remain a successful community effort then it is up to its
current members to make sure it does.

Cheers
Emil

> I further expect most

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Mar 2008 00:25:41 -0400

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

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 20 Mar 2008 08:48:11 +0100

> does not exist. I really don't know what to say.

For some reasons I don't undestand, people tend to forget about projects
they are not directly involved in.  Guess what, we have had the SIPDHT
project running on sourceforge since May '05, providing firstly a
working implementation of initial David's drafts and then, from July
'07, a full implementation of XPP and XPP-PCAN; no matter how many times
we have pointed it out, during live meetings and on this list too,
people keep ignoring it.  But, Cullen, please, don't get upset: I'm sure
they are not lying, they are just "forgetting".

-- 
Ciao,
Enrico

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Mar 2008 07:39:18 -0400

> they are not lying, they are just "forgetting".

Makes sense and a good perspective. I'll go with that explanation - I  
certainly like it better than the alternative explanations.

Now, if only we could have a web page that pointed at all of the  
work :-)

Thanks, Cullen

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 20 Mar 2008 09:05:25 -0400

I think I can help with the problem of pointers to the work...

If you have an open source project that has a P2PSIP implementation
(an implementation of some draft -- current or past that was presented
in this WG), please send me a link and I'll put it on P2PSIP.org.
Also, if you have a commercially available project (something that can
be purchased) that implements a draft from this WG, send me the link,
and I'll list those in a different section on the same page. That way,
we'll have a record of available implementations. Just make sure it is
for something presented in the WG -- not just an open source
implementation of a DHT (I know all the ones discussed so far in this
email thread are of drafts in this WG, so everything mentioned so far
is the kind of thing I do want to link from there)

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Mar 2008 08:24:39 -0500

Hi, David,

>I think I can help with the problem of pointers to the work...

Thank you for taking this on.

If I might make one additional suggestion, the SIP working group (for 
example) has this on the charter page:

In addition to this official charter maintained by the IETF Secretariat, 
there is additional information about this working group on the Web at:

Additional SIP Page (which points to http://www.softarmor.com/sipwg/)

Perhaps it would be appropriate to add a pointer to your (updated) web page 
on the P2PSIP charter page.

Spencer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Mar 2008 08:26:01 -0700

> Now, if only we could have a web page that pointed at all of the  

What about having a "Running Code References" section in the I-D/RFC?

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 20 Mar 2008 10:16:06 -0700

Dan,

> Can we not get a wiki page set up for the P2PSIP working group

As has been pointed out by Lars Eggert, the IETF has a wiki for the RAI area:

http://www3.tools.ietf.org/area/rai/trac/wiki 

The generous offer to use the SIPeerio web site is also very good.
Why not use both, since wiki's and web sites are really complementary.

I suggest the contributors that have links to post should start by posting the links to the wiki, so we have them all in one place. The first contributor to post their link should get the bonus of naming the page, such as "P2P SIP Links".
If you do, please announce the page to the list.

What do you think?

Henry

________________________________________
From: Dan York [mailto:[email-masked]] On Behalf Of Dan York
Sent: Thursday, March 20, 2008 6:28 AM
To: Cullen Jennings
Cc: Enrico Marocco; Henry Sinnreich; Lars Eggert; Jon Peterson; P2PSIP Mailing List
Subject: Re: [P2PSIP] Cullen Lying

On Mar 20, 2008, at 7:39 AM, Cullen Jennings wrote:

Cullen Jennings wrote:
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

There are also *commercial* implementations of P2PSIP technology available today. For instance, (P2PSIP WG Chair) David Bryan's SIPeerior Technologies has a P2PSIP toolkit available. (And by the way, David gave a great high-level talk about P2PSIP here at VoiceCon yesterday morning.)

Can we not get a wiki page set up for the P2PSIP working group?    Or could links like these be added to a page associated with the WG?

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 20 Mar 2008 13:32:52 -0400

I just want to correct one error below -- my offer is to put the page
up at P2PSIP.org, not at SIPeerior. P2PSIP.org is a community site,
not a company site. I have worked very hard from day one to make sure
that work from all folks was included there, even before we had any
IETF page we could use to put information up on as a community.

While I will now be listing our implementation there as a commercial
implementation along with the open source efforts as a result of this
discussion, to present, there hasn't even been a link to SIPeerior
from P2PSIP.org (although the name obviously appears in some drafts),
explicitly to ensure it was a community site.

David (as an individual and representing P2PSIP.org)

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 20 Mar 2008 13:35:47 -0400

Might I suggest that further discussion use a topic title that is not
personal?

Regards

Michael Slavitch

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David A. Bryan
Sent: Thursday, March 20, 2008 1:33 PM
To: Henry Sinnreich
Cc: P2PSIP Mailing List; Jon Peterson; Dan York
Subject: Re: [P2PSIP] Cullen Lying

On Thu, Mar 20, 2008 at 1:16 PM, Henry Sinnreich <[email-masked]>
wrote:
>  I suggest the contributors that have links to post should start by
posting the links to the wiki, so we have them all in one place. The
first contributor to post their link should get the bonus of naming the
page, such as "P2P SIP Links".
>  There are also *commercial* implementations of P2PSIP technology
available today. For instance, (P2PSIP WG Chair) David Bryan's SIPeerior
Technologies has a P2PSIP toolkit available. (And by the way, David gave
a great high-level talk about P2PSIP here at VoiceCon yesterday
morning.)
>  Can we not get a wiki page set up for the P2PSIP working group?    Or
could links like these be added to a page associated with the WG?

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Mar 2008 13:27:11 -0500

> Might I suggest that further discussion use a topic title that is not

I thought the same thing, nanoseconds after I posted in the previous thread. 
My bad.

Sorry,

Spencer

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 12:24:49 +0200

Hi Cullen,

>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/

This sounds very interesting. Could you please explain us what you
implemented (I could only find a number of files without any explanation
what they are etc..)? Is this the implementation of ASP-00? What
experiments did you perform? What was the size of the P2PSIP network? Is
this activity terminated or are some people in Cisco continuing
open-source development?

There is a number of P2PSIP implementations. I think it would be good to
share our implementation experience.

Marcin

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Cullen Jennings
>Sent: Thursday, March 20, 2008 6:26 AM
>To: Henry Sinnreich
>Cc: Jon Peterson; Eggert Lars (Nokia-NRC/Helsinki); P2PSIP Mailing List
>Subject: [P2PSIP] Cullen Lying
>
>
>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
>
>
>> 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
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Spencer Dawkins
>> 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)
>> 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.
>>
>> 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
>> don't trip over it while walking through the room.
>>
>> Thanks,
>>
>> Spencer
>>
>>> There are people who feel that RELOAD is being "strong- armed" 
>>> (coerced
>> by
>>> don't have the same perception. This sort of problem 
>happens  anytime
>> a
>>> candidate draft has contributor support from a chair, area  
>director,
>> or