Subject: [p2p-sip] Names (was Re: Problem statement for P2P SIP NAT tr aversal)

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Tue, 14 Mar 2006 10:09:24 -0500

Dean:

The only problem that I have with your suggestion is the word: "NAMING."

NAMING seems to be very "limited" in scope. I believe that it has also
another aspect that we might be looking for: "PROTOCOL."

So, still my vote will be as follows:

1. P2P-ONP (P2P Overlay Networking Protocol)
2. Others

BR/Radhika

-----Original Message-----
From: Dean Willis [mailto:dean.willis at softarmor.com] 
Sent: Tuesday, March 14, 2006 1:31 AM
To: Michael Slavitch
Cc: Roy, Radhika R.; P2P-SIP
Subject: Names (was Re: [p2p-sip] Problem statement for P2P SIP NAT
traversal)

On Mar 13, 2006, at 9:51 PM, Michael Slavitch wrote:

>
> P2PONP?  Good.  Let's poll for alternatives, but I like it.  
> Personally I like mine, but P2PONP is more IETF-ish. I don't care  
> as long as it meets the requirements above.
>

I'm struggling to find something that could use the acronym P2PONY.  
How about P2PONI? "Peer 2 Peer Overlay Naming for Internet"  . . .  
Maybe "Peer Overlay Naming for Internet Element Signaling", PONIES.  
It has, well, spirit.

A good catchy acronym nets one a world of marketing power.

But we do have to be very careful.

If we stay laser-focused on applying P2P techniques to solve the  
rendezvous problem for SIP, we have a solvable problem. If we  
generalize, we could be in a world of hurt. The lesson here -- don't  
generalize.

SIP does Offer/Answer. I think that narrows our focus for media  
negotiation to O/A. But that's not the same thing as correspondent  
discovery, which does not have to be an O/A problem.

Without generalizing we still have a couple of Big Questions:

1) Is the Insert/Search method SIP or some other protocol, and if  
some other, then what?

2) If we make our supernodes do STUN/TURN, does ICE solve our NAT  
traversal problem?

3) How do we solve routing topology security in a way that makes EKR  
happy and still works? I suppose one solution is to put all the  
supernodes into the trust domain and have all the user functions on  
ordinary nodes, but I suspect that isn't an optimal model for  
distribution of labor. Might work OK for the "self organizing proxy  
farm" use case, however.

--
Dean

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 14 Mar 2006 10:27:33 -0500

Hi Radhika,

Let's not change the name.

We're here to work on SIP related P2P only.

Even if we don't change the SIP protocol,
we still have to define operations for devices
which perform both P2P and CS SIP.

Certainly, we have presence work to do, and that's
not just a naming issue, it's a state and protocol
issue too (and one which has been simply, but neatly
described by Kundan and Henning in their technical
report.), but I don't think it needs to modify the name
of the WG.

If other P2P operations need to be performed,
let another WG worry about it: they can use our
protocols and tools if need be.

Greg

Roy, Radhika R. wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 14 Mar 2006 16:57:41 +0100

> 1. P2P-ONP (P2P Overlay Networking Protocol)

It sounds good, it ends in "P", but it doesn't meet the first 
requirement for any *successful* protocol: it MUST be 4-letter-long (not 
3: 4!).
Moreover, it has the following drowbacks:
+ it shows a number in the middle;
+ it has an hyphen;
+ it has nothing to do with my favourite text editor.

Thereby my suggestion would be "Serverless Kill Yank Protocol": SKYP, 
and you've got what you need!

Think about it...

Enrico
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060314/f0ed6b64/attachment.html

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 14 Mar 2006 12:36:21 -0500

I'll throw my support here too. I really would like to see the focus
stay narrow and limited to P2P as it applies to SIP, and keeping SIP
in the name makes that a good bit easier, from my perspective.

David