From jf.wauthy at gmail.com Tue Oct 3 09:05:03 2006 From: jf.wauthy at gmail.com (=?ISO-8859-1?Q?Jean-Fran=E7ois_Wauthy?=) Date: Tue, 3 Oct 2006 15:05:03 +0200 Subject: [p2p-sip] Possible infinite loop in draft-bryan-sipping-p2p-02 Message-ID: <675a4d9d0610030605j3511f9a8n1ea93277c3121812@mail.gmail.com> Hi, I'm currently trying to prototype draft-bryan-sipping-p2p-02 and have run into what could be a big issue: If you take the simple network used in the example (section 11), start with only node 3 connected and add node 10. After joining the overlay, node 10 state is the following: - predecessor: 3 - successor: 3 Just after node 10 joining the overlay (and before stabilizing) node 3 state is: - predecessor: 10 - successor: 3 Then, stabilization begins and node 3 discovers its successor is now 10, it updates that information and sends a REGISTER structured as if it is entering the system to node 10 (subsection 9.8). Node 10 receives the message and answers with a 302 response to redirect the request to node 3 because it doesn't manage the registering node id. Node 3 state is now: - predecessor: 10 - successor: 10 Thus, node 3 performs registration with itself and must set its successor to be the admitting node and its predecessor to be the admitting node's predecessor (subsection 9.4). Therefore node 3 state becomes: - predecessor: 10 - successor: 3 The joining process finishes by performing a stabilization (as strongly suggested at the end of 8.2.2.2) which discovers that node 10 is the actual successor of node 3 and the same process starts looping infinitely. Did i miss something ? -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061003/5beb7e6c/attachment.html From enrico.marocco at telecomitalia.it Tue Oct 3 09:28:55 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Tue, 03 Oct 2006 15:28:55 +0200 Subject: [p2p-sip] Possible infinite loop in draft-bryan-sipping-p2p-02 In-Reply-To: <675a4d9d0610030605j3511f9a8n1ea93277c3121812@mail.gmail.com> References: <675a4d9d0610030605j3511f9a8n1ea93277c3121812@mail.gmail.com> Message-ID: <45226597.5030706@telecomitalia.it> Jean-Fran?ois Wauthy wrote: > I'm currently trying to prototype draft-bryan-sipping-p2p-02 and have > run into what could be a big issue: Actually that draft has many open issues. In fact, other than leading to loops as happened to you, it doesn't even deal with failures. It is likely that it will be fixed in the future; in the meantime, you could think about possible solutions and propose them. The sipdht project is an attempt to do that too. -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From spencer at mcsr-labs.org Tue Oct 3 15:30:30 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 3 Oct 2006 14:30:30 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> Message-ID: <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> More cleanup on pictures... I'm explicitly showing a proxy that provides overlay clients access to the overlay (Proxy Peer Q). This addresses the discussion earlier in this thread, since UA Client C will be sending GET/PUT requests via unicast to a specific overlay peer. I agree with David that the Proxy Peer may provide more than just forwarding/redirection - specifically, David mentioned Registrar functionality, and if I understood correctly, Eunsoo agreed. I'll start working on text that covers these three pictures, starting with what's in Section 3.2 (which would cover the first figure). I'll keep it short, to avoid conflicts with Section 3.3. We're just under three weeks away from the final ID cutoff date for IETF 67. I'm assuming that we'll submit an updated version of this (excellent) draft in time for discussion at the second BOF meeting - if so, when do the editors expect to submit 02? I should have asked this already - is this draft in XML? Just so I know what to provide to the editors... Spencer --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | +------+ +------+ +-------+ | | |N| | | # | UA |#|A|##| UA | # | Peer | |T| | Peer | # | D | | E | # +------+ +------+ # Peer Protocol # +-------+ +-------+ # # | | | | # ####| Proxy |########| Redir |#### | Peer | | Peer | | P | | R | +-------+ +-------+ \__/ \__/ /\ /\ / \ / \ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: P2PSIP Overlay Reference Model In the following picture, I'm showing normal SIP signaling through from SIP UA A to UA Peer E, through Proxy Peer C. --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | +------+ +------+ +-------+ | | |N| | | # | UA |#|A|##| UA |----- SIP # | Peer | |T| | Peer | | INVITE/200 OK # | D | | E | | # +------+ +------+ | # Peer Protocol # +-------+ +-------+ # # | | | | # ####| Proxy |########| Redir |#### | Peer | | Peer | | P | | R | +-------+ +-------+ / / \__/ / SIP \__/ /\ / INVITE/200 OK /\ / \/ / \ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer Proxy In the following figure, I'm showing the SIP signaling for a call initiated from outside the P2PSIP Overlay to a Client, with redirect from a Redirect Peer. --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | ^ +------+ +------+ +-------+ | | | |N| | | # | | UA |#|A|##| UA | # | | Peer | |T| | Peer | # | | D | | E | # | +------+ +------+ # SIP | Peer Protocol # +-------+ +-------+ # INVITE/200 OK # | | | | # | ####| Proxy |########| Redir |#### | | Peer | | Peer | | | P | | R | / +-------+ +-------+ / \ / SIP \ / \__/ INVITE/302 Moved \ \__/ / /\ \ /\ / / \ \/ \/ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: Redirect from P2PSIP Overlay From spencer at mcsr-labs.org Tue Oct 3 16:13:34 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 3 Oct 2006 15:13:34 -0500 Subject: [p2p-sip] Use cases attributes References: <8b2769930608211057g48c9172ch3841f62e01e1715d@mail.gmail.com> <021401c6c54c$67dd4aa0$0600a8c0@china.huawei.com> <44EB258A.6080909@telecomitalia.it> Message-ID: <0a6c01c6e728$69de6b10$0300a8c0@china.huawei.com> Enrico sent a note to the list about the Use Case matrix at http://www.p2psip.org/P2PUseCases.php, pointing out that the matrix had "no" for "Interaction with CS-SIP" for the following use cases: + Impeded Access + Ad-Hoc and Ephemeral Groups + Extending the Reach of Mobile Devices and suggesting that these be listed as "when available". My thinking (which may be questionable, because it's already been questioned :-) was that + "Impeded Access" is not likely to have CS-SIP "available", because the motivation for the use case, as I understood it, was that the CS-SIP infrastructure wasn't available, wasn't usable, or was actively hostile to SIP users. In this case, it seemed unlikely that the overlay peers would want to use CS-SIP, especially via the overlay itself. + "Ad-Hoc and Ephemeral Groups" and "Extending the Reach of Mobile Devices" did seem like more likely candidates for "Interaction with CS-SIP", at least based on the motivation. My hesitation here is more about identity - if I'm the Proxy Peer providing "Interaction with CS-SIP", how much do I know about the other peers in these use cases, and am I willing to provide the Peer Proxy service, since I certainly wasn't configured to know anything special about my peers in the first case, and likely in the second case as well? So I could go for "when available" in "Ad-Hoc and Ephemeral Groups" and in "Extending the Reach of Mobile Devices", if it seems useful to others. Does it seem useful to others? Thanks, Spencer ----- Original Message ----- From: "Enrico Marocco" Spencer Dawkins wrote: > I would like to keep this spreadsheet in sync with the drafts, of course, > so the contents will change as people discuss use cases. > > I should add that this spreadsheet is the product of discussions with a > number of people, including Seaward, so please view me as the editor, not > as the author. > > As always for editors, comments are welcome. First of all, thank you for the great work! Then, a couple of comments on the "Interaction with CS-SIP" column, which is the one I care more about ;-) I expected to see a "when available" instead of a cold "no" at least in the following rows: + Impeded Access + Ad-Hoc and Ephemeral Groups + Extending the Reach of Mobile Devices In such use cases, when some peer in the overlay shares the resources for relaying SIP and media traffic to and from the Internet, the overlay itself should act exactly as a conventional SIP network, IMHO. -- Enrico From spencer at mcsr-labs.org Tue Oct 3 18:17:51 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 3 Oct 2006 17:17:51 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com><8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com><451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> Message-ID: <0af901c6e739$c46a70e0$0300a8c0@china.huawei.com> This is my first shot at Section 3.2. Please let me know if I have misunderstood, or misspoken. I'm also wondering if the second and third figures would be clearer if I showed only one SIP UA in each figure, so it would be easier to spot the SIP UA that's involved in the dialog. Thanks! Spencer 3.2. Reference Model The following diagram depicts a reference or "boxes and arrows" model showing several of the above peer and client types, along with two conventional SIP user agents. --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | +------+ +------+ +-------+ | | |N| | | # | UA |#|A|##| UA | # | Peer | |T| | Peer | # | D | | E | # +------+ +------+ # Peer Protocol # +-------+ +-------+ # # | | | | # ####| Proxy |########| Redir |#### | Peer | | Peer | | P | | R | +-------+ +-------+ \__/ \__/ /\ /\ / \ / \ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: P2PSIP Overlay Reference Model Here, the large perimeter depicted by "#" represents the P2PSIP Overlay and its associated routing data. Around the periphery of the P2PSIP Overlay rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN gateway, a user-agent, two proxies, and a redirector. To the left we have two UA peers, which are included in the overlay even though they are behind network address translators. On the right side, we have a P2PSIP Overlay "UA client", which uses the P2PSIP Overlay Client Protocol depicted by "=" to communicate with Peer Proxy P, and indirectly interacting with the P2PSIP Overlay. Below the P2PSIP Overlay, we have conventional SIP UAs "A" and "B", which are not part of the P2PSIP Overlay, either directly as a peer or indirectly as a client. Instead, they use SIP to interact with with the P2PSIP Overlay. Note that the Proxy Peers and the UA Peers interact using the P2PSIP Overlay Peer Protocol, which is also presumably used on the keepalive links between the UA Peers and their neighbors. (Spencer's note: I'm not happy about either "keepalive" OR "links" in this sentence. I understand Dean's point that "keepalive" may derive from the Outbound draft, but these aren't "links" in the normal sense of the word, and if we're mandating operation of "keepalive" signaling, that has some fairly serious implications for some of the use cases. Suggest "which is also presumably used between the UA Peers and their neighbors".) Both the "Proxy Peers" and "Redir Peer" serve as adapters between ordinary SIP devices and the the P2PSIP Overlay. Each accepts SIP requests and resolves the next-hop by using the P2PSIP overlay Peer Protocol to interact with the routing knowledge of the P2PSIP Overlay, then processes the SIP requests as appropriate (proxying or redirecting towards the next-hop). Note that proxy operation is bidirectional - the proxy may be forwarding a request from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP overlay to an ordinary SIP device. The Gateway Peer provides a similar sort of adaptation to and from the public switched telephone network (PSTN). However, there is a subtle distinction. The gateway function itself can be viewed as a "user" or within the P2PSIP overlay, and is addressed using a P2PSIP Overlay User Identifier. This gateway functionality could also be located in a P2PSIP Overlay Client, or even in a traditional SIP UA that is reached via P2P (using a P2P proxy or redirector) or conventional SIP mechanisms. The following diagram shows a conventional SIP device, SIP UA A, establishing a dialog with UA Peer E, by sending a SIP INVITE to Proxy Peer P, which forwards the request towards its next-hop, which happens to be part of the P2PSIP Overlay. --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | +------+ +------+ +-------+ | | |N| | | # | UA |#|A|##| UA |----- SIP # | Peer | |T| | Peer | | INVITE/200 OK # | D | | E | | # +------+ +------+ | # Peer Protocol # +-------+ +-------+ # # | | | | # ####| Proxy |########| Redir |#### | Peer | | Peer | | P | | R | +-------+ +-------+ / / \__/ / SIP \__/ /\ / INVITE/200 OK /\ / \/ / \ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer Proxy The following diagram shows a second SIP UA "B" establishing a dialog with a P2PSIP Client UA "C", by sending a SIP INVITE to the Redirect Peer "R", which redirects SIP UA "B" to P2PSIP Overlay Client "C", using the normal SIP 302 mechanism. The conventional SIP UA "B" device can then establish the dialog directly with UA Client "C", even though "B" has no awareness of the P2PSIP Overlay, or of the P2PSIP Overlay Client Protocol. --->PSTN +---------+ / +------+ |N| | Gateway |-/ | |########|A|########| Peer |############## | UA | |T| | G | # Client Protocol | Peer | +---------+ # GET/PUT | C | # | +------+ # | \__/ # +-------+ v / \ |NAT| | |=====/ UA \ # P2PSIP Overlay | Proxy | /Client\ # | Peer | |___C__| # Route Data | Q | ^ +------+ +------+ +-------+ | | | |N| | | # | | UA |#|A|##| UA | # | | Peer | |T| | Peer | # | | D | | E | # | +------+ +------+ # SIP | Peer Protocol # +-------+ +-------+ # INVITE/200 OK # | | | | # | ####| Proxy |########| Redir |#### | | Peer | | Peer | | | P | | R | / +-------+ +-------+ / \ / SIP \ / \__/ INVITE/302 Moved \ \__/ / /\ \ /\ / / \ \/ \/ / UA \ / UA \ /______\ /______\ SIP UA A SIP UA B Figure: Redirect from P2PSIP Overlay From abum at aftek.com Wed Oct 4 01:53:58 2006 From: abum at aftek.com (Abu M. Muttalib) Date: Wed, 4 Oct 2006 11:23:58 +0530 Subject: [p2p-sip] Dialing PSTN no from application... Message-ID: Hi, I am using an application to dial a PSTN no. I am not able to dial the same. I am getting the 503 response at times and no response at all, only the retransmission of previous responses. In the same environment, with same user ID and password, I tried to call the PSTN no from XPro and was able to dial successfully. I am not able to figure out why I am not able to dial PSTN no from application. Any help or pointer in appropriate direction will be appreciated. Thanks and regards, Abu. From enrico.marocco at telecomitalia.it Wed Oct 4 03:48:09 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 04 Oct 2006 09:48:09 +0200 Subject: [p2p-sip] Use cases attributes In-Reply-To: <0a6c01c6e728$69de6b10$0300a8c0@china.huawei.com> References: <8b2769930608211057g48c9172ch3841f62e01e1715d@mail.gmail.com> <021401c6c54c$67dd4aa0$0600a8c0@china.huawei.com> <44EB258A.6080909@telecomitalia.it> <0a6c01c6e728$69de6b10$0300a8c0@china.huawei.com> Message-ID: <45236739.7090808@telecomitalia.it> Spencer Dawkins wrote: > Enrico sent a note to the list about the Use Case matrix at > http://www.p2psip.org/P2PUseCases.php, pointing out that the matrix had "no" > for "Interaction with CS-SIP" for the following use cases: > > + Impeded Access > + Ad-Hoc and Ephemeral Groups > + Extending the Reach of Mobile Devices > > and suggesting that these be listed as "when available". > > My thinking (which may be questionable, because it's already been questioned > :-) was that > > + "Impeded Access" is not likely to have CS-SIP "available", because the > motivation for the use case, as I understood it, was that the CS-SIP > infrastructure wasn't available, wasn't usable, or was actively hostile to > SIP users. In this case, it seemed unlikely that the overlay peers would > want to use CS-SIP, especially via the overlay itself. Generally speaking, a P2PSIP Overlay has CS-SIP "available" when at least one of the participating peers is able (and willing) to provide the Proxy and Media Relay services. This could certainly not happen when all peers have "impeded access", but if one has additional resources (e.g. an additional DSL link) the interworking is possible. Obviously the decision depends on considering the "Impeeded Access" for some or all peers. > + "Ad-Hoc and Ephemeral Groups" and "Extending the Reach of Mobile Devices" > did seem like more likely candidates for "Interaction with CS-SIP", at least > based on the motivation. My hesitation here is more about identity - if I'm > the Proxy Peer providing "Interaction with CS-SIP", how much do I know about > the other peers in these use cases, and am I willing to provide the Peer > Proxy service, since I certainly wasn't configured to know anything special > about my peers in the first case, and likely in the second case as well? As above, here the availability depends also on the willingness to provide the needes services. > So I could go for "when available" in "Ad-Hoc and Ephemeral Groups" and in > "Extending the Reach of Mobile Devices", if it seems useful to others. Does > it seem useful to others? My vote doesn't count, does it? ;-) -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From spencer at mcsr-labs.org Wed Oct 4 08:19:58 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 4 Oct 2006 07:19:58 -0500 Subject: [p2p-sip] Use cases attributes References: <8b2769930608211057g48c9172ch3841f62e01e1715d@mail.gmail.com> <021401c6c54c$67dd4aa0$0600a8c0@china.huawei.com> <44EB258A.6080909@telecomitalia.it> <0a6c01c6e728$69de6b10$0300a8c0@china.huawei.com> <45236739.7090808@telecomitalia.it> Message-ID: <0bab01c6e7af$68b6c7a0$0300a8c0@china.huawei.com> Hi, Enrico, (Well, of COURSE your vote counts!) My view of "impeded" may be more draconian than most - where the infrastructure provider is actively searching for traffic they don't like/approve of, and doing what they can to obstruct it. I'm thinking of something like the practice (in the United States) of prohibiting server operation on residential access networks, and dropping customers who violate this contract condition, and I'm pretty sure that enterprises who don't want to use SIP internally would not be amused by people who participate in P2PSIP overlays that cross its enterprise firewalls. So I was assuming that no one would want to call attention to themselves by sending P2PSIP traffic over network boundaries where we find firewalls, policy enforcement points, etc. In a more benign view of "impeded", the infrastructure provider would love to provide SIP but isn't competent to do so, and is willing to watch someone else provide SIP connectivity for its customers. In this case, "when available" makes much more sense. So I'm trying to understand how often "impeded" is draconian, and how often it's incompetent :-) Thanks, Spencer ----- Original Message ----- From: "Enrico Marocco" To: "Spencer Dawkins" Cc: "P2P-SIP" Sent: Wednesday, October 04, 2006 2:48 AM Subject: Re: [p2p-sip] Use cases attributes Spencer Dawkins wrote: > Enrico sent a note to the list about the Use Case matrix at > http://www.p2psip.org/P2PUseCases.php, pointing out that the matrix had > "no" > for "Interaction with CS-SIP" for the following use cases: > > + Impeded Access > + Ad-Hoc and Ephemeral Groups > + Extending the Reach of Mobile Devices > > and suggesting that these be listed as "when available". > > My thinking (which may be questionable, because it's already been > questioned > :-) was that > > + "Impeded Access" is not likely to have CS-SIP "available", because the > motivation for the use case, as I understood it, was that the CS-SIP > infrastructure wasn't available, wasn't usable, or was actively hostile to > SIP users. In this case, it seemed unlikely that the overlay peers would > want to use CS-SIP, especially via the overlay itself. Generally speaking, a P2PSIP Overlay has CS-SIP "available" when at least one of the participating peers is able (and willing) to provide the Proxy and Media Relay services. This could certainly not happen when all peers have "impeded access", but if one has additional resources (e.g. an additional DSL link) the interworking is possible. Obviously the decision depends on considering the "Impeeded Access" for some or all peers. > + "Ad-Hoc and Ephemeral Groups" and "Extending the Reach of Mobile > Devices" > did seem like more likely candidates for "Interaction with CS-SIP", at > least > based on the motivation. My hesitation here is more about identity - if > I'm > the Proxy Peer providing "Interaction with CS-SIP", how much do I know > about > the other peers in these use cases, and am I willing to provide the Peer > Proxy service, since I certainly wasn't configured to know anything > special > about my peers in the first case, and likely in the second case as well? As above, here the availability depends also on the willingness to provide the needes services. > So I could go for "when available" in "Ad-Hoc and Ephemeral Groups" and in > "Extending the Reach of Mobile Devices", if it seems useful to others. > Does > it seem useful to others? My vote doesn't count, does it? ;-) -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From enrico.marocco at telecomitalia.it Wed Oct 4 10:46:36 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 04 Oct 2006 16:46:36 +0200 Subject: [p2p-sip] Use cases attributes In-Reply-To: <0bab01c6e7af$68b6c7a0$0300a8c0@china.huawei.com> References: <8b2769930608211057g48c9172ch3841f62e01e1715d@mail.gmail.com> <021401c6c54c$67dd4aa0$0600a8c0@china.huawei.com> <44EB258A.6080909@telecomitalia.it> <0a6c01c6e728$69de6b10$0300a8c0@china.huawei.com> <45236739.7090808@telecomitalia.it> <0bab01c6e7af$68b6c7a0$0300a8c0@china.huawei.com> Message-ID: <4523C94C.8000901@telecomitalia.it> Spencer Dawkins wrote: > My view of "impeded" may be more draconian than most - where the > infrastructure provider is actively searching for traffic they don't > like/approve of, and doing what they can to obstruct it. I'm thinking of > something like the practice (in the United States) of prohibiting server > operation on residential access networks, and dropping customers who violate > this contract condition, and I'm pretty sure that enterprises who don't want > to use SIP internally would not be amused by people who participate in > P2PSIP overlays that cross its enterprise firewalls. > > So I was assuming that no one would want to call attention to themselves by > sending P2PSIP traffic over network boundaries where we find firewalls, > policy enforcement points, etc. > > In a more benign view of "impeded", the infrastructure provider would love > to provide SIP but isn't competent to do so, and is willing to watch someone > else provide SIP connectivity for its customers. In this case, "when > available" makes much more sense. > > So I'm trying to understand how often "impeded" is draconian, and how often > it's incompetent :-) My view of "impeded" is actually less draconian than yours. When I think about impeded access, I immediately think about guests in my company's network. In fact, since I'm a registered user, even behind a firewall I can use the local SIP service for talking with people on the Internet, but there is no way for a visitor on the same LAN to access the same service. However, I'd be happy to share my permissions with guests attending a meeting or a conference with me and, hopefully, P2PSIP will let me do that. The same result could more easily be achieved using a system for provisioning temporary accounts on the SIP server, so I have to admit that this is a clear matter of incompetence, but I'm pretty sure it is quite a common case. -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From dean.willis at softarmor.com Wed Oct 4 17:38:13 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 4 Oct 2006 16:38:13 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> Message-ID: <4135EB1C-5899-4F20-81BC-EB93F58676C1@softarmor.com> On Sep 28, 2006, at 7:41 AM, Spencer Dawkins wrote: > ... I'm still working on precision here ... > > I may have misunderstood this point in the original draft, but I > thought the > Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called > "Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php. > > But, looking back at draft-willis-p2psip-concepts-01 more closely, > I find > > 6. Proxy: A peer or client that accepts SIP requests, resolves the > next hop or hops using the routing information of the P2PSIP > Overlay, and passes the request on towards the next hop. > > If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what > should I > call the node providing "Interaction with CS-SIP"? > Your understanding is consistent with mine. David's "adaptor nodes" are something else. -- Dean From dean.willis at softarmor.com Wed Oct 4 17:42:32 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 4 Oct 2006 16:42:32 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> Message-ID: <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> On Oct 3, 2006, at 2:30 PM, Spencer Dawkins wrote: > More cleanup on pictures... > > I'm explicitly showing a proxy that provides overlay clients access > to the > overlay (Proxy Peer Q). This addresses the discussion earlier in this > thread, since UA Client C will be sending GET/PUT requests via > unicast to a > specific overlay peer. > I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" > I agree with David that the Proxy Peer may provide more than just > forwarding/redirection - specifically, David mentioned Registrar > functionality, and if I understood correctly, Eunsoo agreed. > I'd argue that those are added, but different, roles -- "P2PSIP Peer and SIP Redirector", P2PSIP Peer and SIP Registrar". > I'll start working on text that covers these three pictures, > starting with > what's in Section 3.2 (which would cover the first figure). I'll > keep it > short, to avoid conflicts with Section 3.3. > > We're just under three weeks away from the final ID cutoff date for > IETF 67. > I'm assuming that we'll submit an updated version of this > (excellent) draft > in time for discussion at the second BOF meeting - if so, when do the > editors expect to submit 02? > > I should have asked this already - is this draft in XML? Just so I > know what > to provide to the editors... > Yes. David has the master XML file now for the next revision. > Spencer > --->PSTN > +---------+ / > +------+ |N| | Gateway |-/ > | |########|A|########| Peer |############## > | UA | |T| | G | # Client > Protocol > | Peer | +---------+ # GET/PUT > | C | # | > +------+ # | \__/ > # +-------+ v / \ > |NAT| | |=====/ > UA \ > # P2PSIP Overlay | Proxy | / > Client\ > # | Peer | | > ___C__| > # Route Data | Q | > +------+ +------+ +-------+ > | | |N| | | # > | UA |#|A|##| UA | # > | Peer | |T| | Peer | # > | D | | E | # > +------+ +------+ # > Peer Protocol # +-------+ +-------+ # > # | | | | # > ####| Proxy |########| Redir |#### > | Peer | | Peer | > | P | | R | > +-------+ +-------+ > > > \__/ \__/ > /\ /\ > / \ / \ > / UA \ / UA \ > /______\ /______\ > SIP UA A SIP UA B > > Figure: P2PSIP Overlay Reference Model -- Dean From eunsoo at research.panasonic.com Wed Oct 4 19:05:41 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 04 Oct 2006 19:05:41 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <4135EB1C-5899-4F20-81BC-EB93F58676C1@softarmor.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <4135EB1C-5899-4F20-81BC-EB93F58676C1@softarmor.com> Message-ID: <45243E45.1030907@research.panasonic.com> My comments are line. Dean Willis wrote: >On Sep 28, 2006, at 7:41 AM, Spencer Dawkins wrote: > > > >>... I'm still working on precision here ... >> >>I may have misunderstood this point in the original draft, but I >>thought the >>Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called >>"Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php. >> >>But, looking back at draft-willis-p2psip-concepts-01 more closely, >>I find >> >> 6. Proxy: A peer or client that accepts SIP requests, resolves the >> next hop or hops using the routing information of the P2PSIP >> Overlay, and passes the request on towards the next hop. >> >>If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what >>should I >>call the node providing "Interaction with CS-SIP"? >> >> >> > > > In my understanding, Proxy Peer = Peer + SIP Proxy. Similarly Redirect Peer = Peer + SIP Redirect Server. The only difference between Proxy Peer and plain SIP Proxy is that Proxy Peer understands the P2PSIP Peer Protocol and Client Protocol in addition to the (plain) SIP protocol and Proxy Peer can look up location information from the P2PSIP overlay network using the Peer Protocol in addition to from DNS. Proxy Peer understands CS-SIP messages and thus can interact with CS-SIP nodes naturally. So I am not sure whether we need any special node for interaction with CS-SIP other than Proxy Peer and Registrar Peer (Peer + SIP Registrar). >Your understanding is consistent with mine. David's "adaptor nodes" >are something else. > > > > Is my understanding consistent with yours? Thanks. Eunsoo From abum at aftek.com Thu Oct 5 10:45:43 2006 From: abum at aftek.com (Abu M. Muttalib) Date: Thu, 5 Oct 2006 20:15:43 +0530 Subject: [p2p-sip] Dialing PSTN no from application... Message-ID: Hi, I am using an application to dial a PSTN no. Though I am getting the 200 OK response, I am not able to hear anything. In the same environment, with same user ID and password, I tried to call the PSTN no from XPro and was able to dial successfully. I am not able to figure out why I am not able to dial PSTN no from application. I am attaching the logs for both the scenarios. Its ethereal capture of SIP packets. Any help or pointer in appropriate direction will be appreciated. Thanks and regards, Abu. -------------- next part -------------- A non-text attachment was scrubbed... Name: VoIP-Telefonica.zip Type: application/octet-stream Size: 4433 bytes Desc: not available Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/1538d417/VoIP-Telefonica.obj From enrico.marocco at telecomitalia.it Thu Oct 5 10:51:37 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 05 Oct 2006 16:51:37 +0200 Subject: [p2p-sip] Dialing PSTN no from application... In-Reply-To: References: Message-ID: <45251BF9.9010907@telecomitalia.it> Abu M. Muttalib wrote: > I am using an application to dial a PSTN no. Though I am getting the 200 OK > response, I am not able to hear anything. The p2p-sip list is the wrong place both for addressing operational problems and for sending binary attachments. Really. -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From spencer at mcsr-labs.org Thu Oct 5 16:24:42 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 5 Oct 2006 15:24:42 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> Message-ID: <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> >> I'm explicitly showing a proxy that provides overlay clients access to >> the >> overlay (Proxy Peer Q). This addresses the discussion earlier in this >> thread, since UA Client C will be sending GET/PUT requests via unicast >> to a >> specific overlay peer. > > I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client > Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" I would like to think that Spencer, Dean, David and Eunsoo are all talking about similar ideas using different words... If I understand correctly, David and Eunsoo are thinking that a "Proxy Peer" would make a next-hop forwarding decision, which could be either to a conventional SIP next-hop or to a p2pSIP next-hop, while Dean is thinking of several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, SIP Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact phrase in his note). Speaking only for myself, I've already gotten wrapped around the axle on "Proxy Peer". I'm not sure ANYbody made it most of the way to the bottom of https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html (my apologies, it was long), but anyone who did would have seen this conversation on 3.5.5: >>> 3.3.5. Bootstrapping >>> >>> After discovering the address of a peer, the behavior of the >>> starting >>> node will vary depending on whether it is intending to be a peer or >>> a >>> >>> Ouch - if I have a peer, I would think that I'm a peer, too. Is the >>> client >>> actually discovering something like a "P2PSIP Overlay Server"? >> >> nope. It's discovering a P2PSIP Overlay Peer. > > I'm with you as far as the current text goes. What I'm trying to point out > is that there is nothing in the reference architecture that allows me to > distinguish between P2PSIP overlay peers that DO "serve" clients and peers > that do not. This seems to be a missing concept that I'd like to see > discussed. > > I seem to have confused more people than just Dean when I used the term > P2PSIP Overlay Server, but this captured what I was trying to say - the > P2PSIP Overlay is the resource, made up entirely of peers, and the client > wants a participant in the P2PSIP Overlay to allow an endpoint that is not > an overlay peer to store and retrieve information in the overlay. > > So, I'm thinking of a picture that looks like this > > +---+ +---+---+ +---+ > | p1|==========| p2| s5|------| c6| > +---+ +---+---+ +---+ > # # > # overlay # > # # > +---+ +---+ > | p3|==========| p4| > +---+ +---+ > > Where p1,p2,p3,and p4 make up a P2PSIP overlay, c6 is the client that > wants to use P2PSIP resources, and s5 is the server entity that allows the > client to put and get P2PSIP Overlay entries without being a peer. There > is no "s5" in the reference architecture today. Today's picture would look > like this > > +---+ +---+ +---+ > | p1|==========| p2|-----------| c6| > +---+ +---+ +---+ > # # > # overlay # > # # > +---+ +---+ > | p3|==========| p4| > +---+ +---+ > >>> client. If it is intending to be a peer, it goes into the P2PSIP >>> Overlay Peer Insertion process, at the conclusion of which it is >>> actively participating in the target overlay as a peer and is >>> capable >>> of routing requests and storing records on behalf of the P2PSIP >>> overlay. If it is intending to be a client, it does not bother with >>> insertion, but merely contacts the discovered peer in order to use >>> the overlay. So, I think +---+---+ +---+ | p2| s5|------| c6| +---+---+ +---+ was the way I was drawing Dean's "P2PSIP Proxy AND Client Adapter" (p2/s5), and the P2PSIP Client (c6). I'm not suggesting this format, only hoping it helps describe what I'm talking about. So the real question is, how much of this needs to be precisely described in the "concepts" draft? I'd really like to get the terminology down, but right now, I just need a suggestion about direction. Thanks, Spencer From RADHIKA.R.ROY at saic.com Thu Oct 5 17:52:02 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Thu, 5 Oct 2006 17:52:02 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CEA1@0591-ITS-EXMP02.us.saic.com> Spencer: https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html You are right that we have go to the bottom of this removing all technical confusions. Let me provide my suggestions how we can solve those logically step-by-step. Let us consider the following Figure used in the discussion (a figure is a thousand words): +---+ +---+---+ +---+ | p1|========== | p2 | c5|---- | c6| +---+ +---+---+ +---+ # # # overlay # # # +---+ +---+ | p3|==========| p4| +---+ +---+ This figure is the correct one because p1, p2, p3, and p4 use the same protocol and have the same functionalities. The same is the case for c5 and c6. However, p1/p2/p3/p4 and c5/c6 are different because the protocol and functionalities are different. In the same way, the p2p-SIP concept draft needs to be re-written to reflect the description and figure with one-to-one mapping. The problems with draft are as follows: p2 and c5 entities have been merged into a "single entity" both in figure and in description while entities like p1/p3/p4 have also shown as a single entity both in figure and description. As a result, we know what has happened: A mountain of technical confusions. Let the authors re-write p2p-SIP concept draft clarifying the things as described above with one-to-one mapping both in description and in figure leaving no room for any technical confusions. Best regards, Radhika -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/4ba7191b/attachment.html From spencer at mcsr-labs.org Thu Oct 5 18:07:49 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 5 Oct 2006 17:07:49 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <62D92A9A02BCC845B202323D49A48426E1CEA1@0591-ITS-EXMP02.us.saic.com> Message-ID: <147401c6e8ca$b339b820$0300a8c0@china.huawei.com> Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01Hi, Radhika, In my limited understanding, c5 and c6 are actually acting as a server and as client, respectively - c6 would send PUTs and GETs to c5, and p2 would do insertions and retrievals into/from the overlay on behalf of c6, but c5 would not send PUTs to c6, because c6 is not a participant in an overlay. So, if you're saying c5 and c6 know the same protocol, I agree, but I'm not sure whether you're also saying that the protocol between c5 and c6 is symmetrical. I thought it was asymmetrical - that's why I was trying to figure out where the "server" was, for the P2PSIP Overlay client. Anyone can tell me I'm misreading the draft text, but that's what I was getting out of it. Thanks, Spencer ----- Original Message ----- From: Roy, Radhika R. To: Spencer Dawkins Cc: p2p-sip at cs.columbia.edu Sent: Thursday, October 05, 2006 4:52 PM Subject: RE: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 Spencer: https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html You are right that we have go to the bottom of this removing all technical confusions. Let me provide my suggestions how we can solve those logically step-by-step. Let us consider the following Figure used in the discussion (a figure is a thousand words): +---+ +---+---+ +---+ | p1|========== | p2 | c5|---- | c6| +---+ +---+---+ +---+ # # # overlay # # # +---+ +---+ | p3|==========| p4| +---+ +---+ This figure is the correct one because p1, p2, p3, and p4 use the same protocol and have the same functionalities. The same is the case for c5 and c6. However, p1/p2/p3/p4 and c5/c6 are different because the protocol and functionalities are different. In the same way, the p2p-SIP concept draft needs to be re-written to reflect the description and figure with one-to-one mapping. The problems with draft are as follows: p2 and c5 entities have been merged into a "single entity" both in figure and in description while entities like p1/p3/p4 have also shown as a single entity both in figure and description. As a result, we know what has happened: A mountain of technical confusions. Let the authors re-write p2p-SIP concept draft clarifying the things as described above with one-to-one mapping both in description and in figure leaving no room for any technical confusions. Best regards, Radhika -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/ef14d958/attachment.html From RADHIKA.R.ROY at saic.com Thu Oct 5 19:58:54 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Thu, 5 Oct 2006 19:58:54 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <62D92A9A02BCC845B202323D49A48426E1CEA1@0591-ITS-EXMP02.us.saic.com> <147401c6e8ca$b339b820$0300a8c0@china.huawei.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CEA3@0591-ITS-EXMP02.us.saic.com> Spencer: I guess that we are in agreement. Let me explain the fact, even if there is p2p-SIP protocol, one acts as the server while other acts as the client and vice versa. In the case of CS-SIP, it is not the case. So, it is the protocol itself that will automatically determine who is what and when. However, the logical separation that I have generalized at a very high level is the very important first step for all of us to clarify. Then the second step will be to clarify further minor differences while using the same protocol by different entities. It is quite understandable. More inline [RRR]. BR/Radhika ________________________________ From: p2p-sip-bounces at cs.columbia.edu on behalf of Spencer Dawkins Sent: Thu 10/5/2006 6:07 PM To: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 Hi, Radhika, In my limited understanding, c5 and c6 are actually acting as a server and as client, respectively - c6 would send PUTs and GETs to c5, and p2 would do insertions and retrievals into/from the overlay on behalf of c6, but c5 would not send PUTs to c6, because c6 is not a participant in an overlay. [RRR] Right. That is, they are communicating using the same protocol. In this way, they have same protocol functionality. If one is server or the other one is client, it is their behavior that may use differently, but the same protocol. So, if you're saying c5 and c6 know the same protocol, I agree, but I'm not sure whether you're also saying that the protocol between c5 and c6 is symmetrical. I thought it was asymmetrical - that's why I was trying to figure out where the "server" was, for the P2PSIP Overlay client. [RRR] Right. It is the same protocol that will derive the fact who is sever and who is client. The description in the draft will clrify the use case of the protocol for a given configuration further. The key is that the logical entitiies like c5-c6 can be used for any one of p1, p2, p3, or p4 for that matter. [RRR] The other thing is this: For communications between p2 and c5, an interworking function (IWF) is needed. If both p2 and c5 are physically co-located, we may not need interworking protocol per se - an API may be good enough that may be defined at appropriate time. Otherwise, we may say that we will deal with this IWF later. In this way, we keep all the technical steps crystal clear without creating technical confusions as it is happening now. Anyone can tell me I'm misreading the draft text, but that's what I was getting out of it. [RRR] No, you are not mis-reading the draft. In fact, I would say that you have the third eye. This is what we expected when we would go for standardization of p2p-SIP. Thanks, Spencer ----- Original Message ----- From: Roy, Radhika R. To: Spencer Dawkins Cc: p2p-sip at cs.columbia.edu Sent: Thursday, October 05, 2006 4:52 PM Subject: RE: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 Spencer: https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html You are right that we have go to the bottom of this removing all technical confusions. Let me provide my suggestions how we can solve those logically step-by-step. Let us consider the following Figure used in the discussion (a figure is a thousand words): +---+ +---+---+ +---+ | p1|========== | p2 | c5|---- | c6| +---+ +---+---+ +---+ # # # overlay # # # +---+ +---+ | p3|==========| p4| +---+ +---+ This figure is the correct one because p1, p2, p3, and p4 use the same protocol and have the same functionalities. The same is the case for c5 and c6. However, p1/p2/p3/p4 and c5/c6 are different because the protocol and functionalities are different. In the same way, the p2p-SIP concept draft needs to be re-written to reflect the description and figure with one-to-one mapping. The problems with draft are as follows: p2 and c5 entities have been merged into a "single entity" both in figure and in description while entities like p1/p3/p4 have also shown as a single entity both in figure and description. As a result, we know what has happened: A mountain of technical confusions. Let the authors re-write p2p-SIP concept draft clarifying the things as described above with one-to-one mapping both in description and in figure leaving no room for any technical confusions. Best regards, Radhika -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/9ebbed17/attachment-0001.html From dean.willis at softarmor.com Mon Oct 9 02:34:23 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 09 Oct 2006 01:34:23 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> Message-ID: <4529ED6F.9070006@softarmor.com> Spencer Dawkins wrote: >>> I'm explicitly showing a proxy that provides overlay clients access to >>> the >>> overlay (Proxy Peer Q). This addresses the discussion earlier in this >>> thread, since UA Client C will be sending GET/PUT requests via unicast >>> to a >>> specific overlay peer. >> I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client >> Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" > > I would like to think that Spencer, Dean, David and Eunsoo are all talking > about similar ideas using different words... > > If I understand correctly, David and Eunsoo are thinking that a "Proxy Peer" > would make a next-hop forwarding decision, which could be either to a > conventional SIP next-hop or to a p2pSIP next-hop, while Dean is thinking of > several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, SIP > Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact > phrase in his note). > Ok, let's explore my mental model of how I think P2PSIP works. I presume that any P2PSIP peer will, if presented with a valid P2PSIP "get" or "put" request, either process the request, pass the request to another peer and stand by to return the result, or return a URI for another peer that the requestor should contact directly. Further, I presume that these operations happen at the level of the P2PSIP Peer protocol, which may well not be SIP. I further presume that every P2PSIP peer speaks the P2PSIP client protocol in addition to the P2PSIP peer protocol, assuming those are actually different protocols. The above behavior is completely independent of SIP proxy, redirection, and registration server functions. So, here are a couple of things I think result:what 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP peer understand P2PSIP Client Protocol and will, if presented with a valid P2PSIP Client Protocol "Get" or "Put" request, do something reasonable with that request. 2) There are peers and/or clients in the P2PSIP world that also serve as SIP "server" nodes. These have SIP proxy and/or SIP redirector (I hate the term "location server"), and/or SIP registrar functionality, and they use the data of the P2PSIP overlay to assist in responding to SIP request messages. 3) Most (ok,all) P2PSIP peers will act as either SIP proxy/registrar nodes or as SIP redirector nodes when presented with a SIP request that does not target the user of a UA colocated with that peer. Said otherwise, they either process SIP requests into the P2PSIP overlay, or they redirect them to another node that is expected to do the overlay processing needed to resolve those SIP requests. -- Dean From spencer at mcsr-labs.org Mon Oct 9 15:09:14 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 9 Oct 2006 14:09:14 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> Message-ID: <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> Hi, Dean, > 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP peer > understand P2PSIP Client Protocol and will, if presented with a valid > P2PSIP Client Protocol "Get" or "Put" request, do something reasonable > with that request. Far out. I am still absorbing an also-helpful previous note from you, so let me ask a question using that context. >From a previous conversation: >> - I'm very confused about how both clients and peers can be "endpoints". >> For >> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I >> suspect >> that this is conflating P2P endpoints (peers) with SIP endpoints (either >> a >> UA-peer or a UA-client). If you guys understand this perfectly, please >> keep >> typing... >> > > Peers are supersets of clients. Everything a client can do, a peer can > do. Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP Overlay Client PROTOCOL? Thanks, Spencer From bryan at ethernot.org Mon Oct 9 15:21:53 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 9 Oct 2006 15:21:53 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> Message-ID: <8b2769930610091221i17e912b3l76b9c4a9fa71908f@mail.gmail.com> I'll take a stab at answering Spencer's question...inline On 10/9/06, Spencer Dawkins wrote: > Hi, Dean, > > > 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP peer > > understand P2PSIP Client Protocol and will, if presented with a valid > > P2PSIP Client Protocol "Get" or "Put" request, do something reasonable > > with that request. > > Far out. I am still absorbing an also-helpful previous note from you, so let > me ask a question using that context. > > >From a previous conversation: > > >> - I'm very confused about how both clients and peers can be "endpoints". > >> For > >> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I > >> suspect > >> that this is conflating P2P endpoints (peers) with SIP endpoints (either > >> a > >> UA-peer or a UA-client). If you guys understand this perfectly, please > >> keep > >> typing... > >> > > > > Peers are supersets of clients. Everything a client can do, a peer can > > do. > > Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP > Overlay Client PROTOCOL? Logically, yes. However, because there has been hotly debated discussion on which/neither/both are SIP, they may be syntactically different, but yes, the set of things you can do in the peer protocol is a superset of the things you can do in the client protocol. David > Thanks, > > Spencer > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From RADHIKA.R.ROY at saic.com Mon Oct 9 16:12:24 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Mon, 9 Oct 2006 16:12:24 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com><451B47C4.5070000@research.panasonic.com><0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com><8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com><451BDE55.5070402@research.panasonic.com><09f801c6e722$6538bf80$0300a8c0@china.huawei.com><0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com><13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com><4529ED6F.9070006@softarmor.com><1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <8b2769930610091221i17e912b3l76b9c4a9fa71908f@mail.gmail.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CEBA@0591-ITS-EXMP02.us.saic.com> Inline [RRR] > Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP > Overlay Client PROTOCOL? Logically, yes. However, because there has been hotly debated discussion on which/neither/both are SIP, they may be syntactically different, but yes, the set of things you can do in the peer protocol is a superset of the things you can do in the client protocol. [RRR] So, let make it clear separating into two: 1. Peer Protocol and 2. Client Protocol. In this way, we will remove technical ambiguities. David > Thanks, > > Spencer > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061009/b8f5ec29/attachment.html From bryan at ethernot.org Mon Oct 9 16:22:08 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 9 Oct 2006 16:22:08 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CEBA@0591-ITS-EXMP02.us.saic.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <8b2769930610091221i17e912b3l76b9c4a9fa71908f@mail.gmail.com> <62D92A9A02BCC845B202323D49A48426E1CEBA@0591-ITS-EXMP02.us.saic.com> Message-ID: <8b2769930610091322u2e4792ds4ab869f7be1651ca@mail.gmail.com> Well, right now the draft does clearly distinguish the two, while noting they may eventually be determined to be the same. I personally am still an advocate of doing it all (client and peer protocol) in SIP, in which case the two are one and the same. David On 10/9/06, Roy, Radhika R. wrote: > > > > Inline [RRR] > > > Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP > > Overlay Client PROTOCOL? > > Logically, yes. However, because there has been hotly debated > discussion on which/neither/both are SIP, they may be syntactically > different, but yes, the set of things you can do in the peer protocol > is a superset of the things you can do in the client protocol. > > [RRR] So, let make it clear separating into two: 1. Peer Protocol and 2. > Client Protocol. In this way, we will remove technical ambiguities. > > > David > > > > Thanks, > > > > Spencer > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From marcia at sipeerior.com Mon Oct 9 16:27:49 2006 From: marcia at sipeerior.com (Marcia Z Bryan) Date: Mon, 9 Oct 2006 16:27:49 -0400 Subject: [p2p-sip] Possible infinite loop in draft-bryan-sipping-p2p-02 In-Reply-To: <675a4d9d0610030605j3511f9a8n1ea93277c3121812@mail.gmail.com> References: <675a4d9d0610030605j3511f9a8n1ea93277c3121812@mail.gmail.com> Message-ID: <9e298a4a0610091327w55a6f45bl5cf34fd451133bf7@mail.gmail.com> I think part of the problem you are experiencing is that all of the startup/base cases haven't explicitly been dealt with in the draft. Also in the course of building our company's implementation, I've found two errors in the draft that might cause some confusion. STARTUP/BASE cases: - The draft fails to discuss intervals that contain NULL predecessors. When the 2nd node is joining the system, the admitting node (original node) in the system has to determine if the joining node's node ID is between the admitting node's predecessor ID and the admitting node's ID. In this case, the admitting node's predecessor is NULL. The draft should, but does not currently, state the following in section 9.4: "...the admitting node MUST reply with a 200 response if the joining node has a Node-ID between the admitting node's predecessor's Node-ID and the admitting node's Node-ID or if the admitting node's predecessor's Node-ID is NULL." - Likewise, when the 2nd node joining the system receives a 200 response from the other node in the system, the 200 response will have a NULL predecessor (or no predecessor at all? This needs to be made explicit in the draft) in the response. So the joining node will set it's predecessor = NULL. ERRORS: - In section 9.4, Node admission, there is a typo error that switches the order of the interval that the admitting node uses to determine if a 200 response should be generated. The draft currently says "When handling an initial join from a node, the admitting node MUST reply with a 200 response if the joining node has a Node-ID between the admitting node's Node-ID and the admitting node's predecessor's Node-ID." but what it should say (including the earlier change I mentioned) is: "When handling an initial join from a node, the admitting node MUST reply with a 200 response if the joining node has a Node-ID between the admitting node's predecessor's Node-ID and the admitting node's Node-ID or if the admitting node's predecessor's Node-ID is NULL." To summarize: Check if joining node's Node-ID is in (admitting node's Node-ID, admitting node's predecessor's ID) should be replaced with check if joining node's Node-ID is in (admitting node's predecessor's ID, admitting node's Node-ID) - The second is more of an unclear statement than an error. It deals with the Chord Periodic Stabilization in section 9.8. The draft currently says "If it is not, the node MUST update their own successor with the predecessor returned, and additionally MUST send a REGISTER to this node, structured as if the stabilizing node had just entered the system. This will serve to properly update the overlay. This is analogous to the notify procedure in Chord." What is confusing here is that the stabilizing node does not process the response to this register as a joining node would. Rather, the stabilizing node ignores the response to the REGISTER (though it may do something if it doesn't receive a 200??). The REGISTER sent by the stabilizing node serves only as a notify. Here's just a summary of what should happen for Node Admission and Chord Periodic Stabilization: Node Admission: 1) Joining Node Tasks: send REGISTER to admitting node and wait for 200 response a) set joining node's successor = admitting node b) set joining node's predecessor = admitting node's predecessor (this can be NULL) 2) Admitting Node Tasks: check if joining node's Node-ID is in (admitting node's predecessor's Node-ID, admitting node's Node-ID) a) if yes or if admitting node's predecessor == NULL - send 200 response with successor and predecessor in the message - set admitting node's predecessor = joining node b) else, send 302 Chord Periodic Stabilization: 1) Stabilizing Node's Tasks: query successor for successor's Node-ID and check to see if successor's predecessor returned in the response is equal to stabilizing node a) if predecessor in response message == stabilizing node, great, move along nothing to do here... b) but if predecessor in response message != stabilizing node - set stabilizing node's successor = predecessor in response message - stabilizing node sends REGISTER to predecessor in response message (and does nothing with the response) 2) (If REGISTER sent by stabilizing node) Notified Node's Tasks: check if stabilizing node's Node-Id is in (notified node's predecessor's Node-Id, notified node's Node-Id) a) if yes, then set notified node's predecessor = stabilizing node Now here's an example of how this works: 1) Node 3 Starts overlay. Node 3 State--> Succ= 3, Pred = NULL 2) Node 10 joins system (asks node 3 for admission) Node 3 State--> Succ = 3, Pred = 10 Node 10 State-->Succ = 3, Pred = NULL 3) Node 10 runs periodic stabilization Node 3 State--> Succ = 3, Pred = 10 Node 10 State--> Succ = 3, Pred = NULL 4) Node 3 runs periodic stabilization Node 3 State--> Succ = 10, Pred = 10 Node 10 State--> Succ = 3, Pred = 3 5) Node 14 joins the system Node 3 State--> Succ = 10, Pred = 14 Node 10 State--> Succ = 3, Pred = 3 Node 14 State--> Succ = 3, Pred = 10 6) Node 14 runs periodic stabilization Node 3 State--> Succ = 10, Pred = 14 Node 10 State--> Succ = 3, Pred = 3 Node 14 State--> Succ = 3, Pred = 10 7) Node 10 runs periodic stabilization Node 3 State--> Succ = 10, Pred = 14 Node 10 State--> Succ = 14, Pred = 3 Node 14 State--> Succ = 3, Pred = 10 --Marcia On 10/3/06, Jean-Fran?ois Wauthy wrote: > > Hi, > > I'm currently trying to prototype draft-bryan-sipping-p2p-02 and have run > into what could be a big issue: > > If you take the simple network used in the example (section 11), start > with only node 3 connected and add node 10. After joining the overlay, node > 10 state is the following: > > - predecessor: 3 > - successor: 3 > > Just after node 10 joining the overlay (and before stabilizing) node 3 > state is: > > - predecessor: 10 > - successor: 3 > > Then, stabilization begins and node 3 discovers its successor is now 10, > it updates that information and sends a REGISTER structured as if it is > entering the system to node 10 (subsection 9.8). Node 10 receives the > message and answers with a 302 response to redirect the request to node 3 > because it doesn't manage the registering node id. Node 3 state is now: > > - predecessor: 10 > - successor: 10 > > Thus, node 3 performs registration with itself and must set its successor > to be the admitting node and its predecessor to be the admitting node's > predecessor (subsection 9.4). Therefore node 3 state becomes: > > - predecessor: 10 > - successor: 3 > > The joining process finishes by performing a stabilization (as strongly > suggested at the end of 8.2.2.2) which discovers that node 10 is the > actual successor of node 3 and the same process starts looping infinitely. > > Did i miss something ? > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061009/e6850a32/attachment-0001.html From RADHIKA.R.ROY at saic.com Mon Oct 9 17:46:22 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Mon, 9 Oct 2006 17:46:22 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com><8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com><451BDE55.5070402@research.panasonic.com><09f801c6e722$6538bf80$0300a8c0@china.huawei.com><0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com><13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com><4529ED6F.9070006@softarmor.com><1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com><8b2769930610091221i17e912b3l76b9c4a9fa71908f@mail.gmail.com><62D92A9A02BCC845B202323D49A48426E1CEBA@0591-ITS-EXMP02.us.saic.com> <8b2769930610091322u2e4792ds4ab869f7be1651ca@mail.gmail.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CEBE@0591-ITS-EXMP02.us.saic.com> It is true, but the draft is yet to clear as it is supposed to be. Radhika ________________________________ From: davidbryan at gmail.com on behalf of David A. Bryan Sent: Mon 10/9/2006 4:22 PM To: Roy, Radhika R. Cc: Spencer Dawkins; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 Well, right now the draft does clearly distinguish the two, while noting they may eventually be determined to be the same. I personally am still an advocate of doing it all (client and peer protocol) in SIP, in which case the two are one and the same. David On 10/9/06, Roy, Radhika R. wrote: > > > > Inline [RRR] > > > Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP > > Overlay Client PROTOCOL? > > Logically, yes. However, because there has been hotly debated > discussion on which/neither/both are SIP, they may be syntactically > different, but yes, the set of things you can do in the peer protocol > is a superset of the things you can do in the client protocol. > > [RRR] So, let make it clear separating into two: 1. Peer Protocol and 2. > Client Protocol. In this way, we will remove technical ambiguities. > > > David > > > > Thanks, > > > > Spencer > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061009/617356f0/attachment.html From spencer at mcsr-labs.org Mon Oct 9 17:50:46 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 9 Oct 2006 16:50:46 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <8b2769930610091221i17e912b3l76b9c4a9fa71908f@mail.gmail.com> <62D92A9A02BCC845B202323D49A48426E1CEBA@0591-ITS-EXMP02.us.saic.com> <8b2769930610091322u2e4792ds4ab869f7be1651ca@mail.gmail.com> Message-ID: <1d5d01c6ebec$fa13f920$0300a8c0@china.huawei.com> OK, if we still need to have a more detailed discussion, I'll leave the pictures distinguishing between Overlay Clients and SIP UAs, with an option to remove this if SIP is used as the client protocol. Thanks for the clarification. Spencer > Well, right now the draft does clearly distinguish the two, while > noting they may eventually be determined to be the same. I personally > am still an advocate of doing it all (client and peer protocol) in > SIP, in which case the two are one and the same. > > David From dean.willis at softarmor.com Tue Oct 10 12:27:56 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 10 Oct 2006 11:27:56 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> Message-ID: On Oct 9, 2006, at 2:09 PM, Spencer Dawkins wrote: > Hi, Dean, > >> 1) There are no "P2PSIP Client Adaptors" because any and every >> P2PSIP peer >> understand P2PSIP Client Protocol and will, if presented with a valid >> P2PSIP Client Protocol "Get" or "Put" request, do something >> reasonable >> with that request. > > Far out. I am still absorbing an also-helpful previous note from > you, so let > me ask a question using that context. > >> From a previous conversation: > >>> - I'm very confused about how both clients and peers can be >>> "endpoints". >>> For >>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I >>> suspect >>> that this is conflating P2P endpoints (peers) with SIP endpoints >>> (either >>> a >>> UA-peer or a UA-client). If you guys understand this perfectly, >>> please >>> keep >>> typing... >>> >> >> Peers are supersets of clients. Everything a client can do, a >> peer can >> do. > > Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the > P2PSIP > Overlay Client PROTOCOL? > No, I see the inverse -- the P2PSIP Client Protocol is a "functional subset" of the P2PSIP Peer Protocol. It may well also be a syntactic subset, or even the exact same protocolbut with some of it not exercised while in client mode. In my world view, the "client" vs. "peer" role is ideally something that a node decides at run time based on its perception of current configuration, network reachability, and other operational constraints. -- Dean From dean.willis at softarmor.com Tue Oct 10 13:27:09 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 10 Oct 2006 12:27:09 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> Message-ID: <07F03123-6B08-4D38-9899-E4A57FC92661@softarmor.com> On Oct 10, 2006, at 11:27 AM, Dean Willis wrote: > > On Oct 9, 2006, at 2:09 PM, Spencer Dawkins wrote: > >> Hi, Dean, >> >>> 1) There are no "P2PSIP Client Adaptors" because any and every >>> P2PSIP peer >>> understand P2PSIP Client Protocol and will, if presented with a >>> valid >>> P2PSIP Client Protocol "Get" or "Put" request, do something >>> reasonable >>> with that request. >> >> Far out. I am still absorbing an also-helpful previous note from >> you, so let >> me ask a question using that context. >> >>> From a previous conversation: >> >>>> - I'm very confused about how both clients and peers can be >>>> "endpoints". >>>> For >>>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I >>>> suspect >>>> that this is conflating P2P endpoints (peers) with SIP endpoints >>>> (either >>>> a >>>> UA-peer or a UA-client). If you guys understand this perfectly, >>>> please >>>> keep >>>> typing... >>>> >>> >>> Peers are supersets of clients. Everything a client can do, a >>> peer can >>> do. >> >> Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the >> P2PSIP >> Overlay Client PROTOCOL? >> > > No, I see the inverse -- the P2PSIP Client Protocol is a "functional > subset" of the P2PSIP Peer Protocol. It may well also be a syntactic > subset, or even the exact same protocolbut with some of it not > exercised while in client mode. > > In my world view, the "client" vs. "peer" role is ideally something > that a node decides at run time based on its perception of current > configuration, network reachability, and other operational > constraints. Well, that was a stupid response. Yes, I see P2PSIP Overlay Peer Protocol as a superset of the P2PSIP Overlay Client Protocol. But while necessarily a functional superset, it may not be a syntactic superset -- it might be an entirely different protocol. -- Dean From spencer at mcsr-labs.org Tue Oct 10 13:24:44 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 10 Oct 2006 12:24:44 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> Message-ID: <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> Hi, Dean, >>> Peers are supersets of clients. Everything a client can do, a peer can >>> do. >> >> Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP >> Overlay Client PROTOCOL? >> > > No, I see the inverse -- the P2PSIP Client Protocol is a "functional > subset" of the P2PSIP Peer Protocol. It may well also be a syntactic > subset, or even the exact same protocolbut with some of it not exercised > while in client mode. Based on your note (and David's note yesterday), I think the pictures I've been working on are OK for now. > In my world view, the "client" vs. "peer" role is ideally something that > a node decides at run time based on its perception of current > configuration, network reachability, and other operational constraints. This seems very reasonable, from the peer's perspective. The pictures I've been thinking of are most appropriate if the P2PSIP Overlay Client protocol is not a syntactic subset. We may have different ideas about when two protocols are "the same protocol" or not, but we don't have to figure that out until we have agreement on the functional subsetting. Thanks, Spencer From spencer at mcsr-labs.org Tue Oct 10 13:32:40 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 10 Oct 2006 12:32:40 -0500 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <07F03123-6B08-4D38-9899-E4A57FC92661@softarmor.com> Message-ID: <223c01c6ec92$16a3ed20$0300a8c0@china.huawei.com> Hi, Dean, > Well, that was a stupid response. It's been a long week here, too (and it's only Tuesday :-) > Yes, I see P2PSIP Overlay Peer Protocol as a superset of the P2PSIP > Overlay Client Protocol. But while necessarily a functional superset, > it may not be a syntactic superset -- it might be an entirely > different protocol. Agree, and I'll leave the pictures in a state that allows this distinction. Thanks! Spencer From dean.willis at softarmor.com Tue Oct 10 15:53:43 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 10 Oct 2006 14:53:43 -0500 Subject: [p2p-sip] Proposed call on concepts and terminology draft October 16 1300 USPDT (GMT+9) Message-ID: David Bryan is currently editing a new version of the Concepts and Terminology draft that we expect to have in circulation by this weekend. We'd like to host an open conference call next week to talk through some points on the draft, then issue another rev before the IETF 67 cutoff. The availability of our potentially-sponsoring AD is limited (Cullen), so I'd like to propose Tuesday, October 17, at 1300 PDT (2100 GMT if my math is right). My apologies for those of you whom find this to be in the middle of eating, sleeping, drinking, or other traditional after-hours occupations. I need to get an estimate of the number of people who plan to attend so I can size the conference bridge, so please RSVP by COB Friday, October 13. A more detailed agenda will be forthcoming, along with the revised draft. -- Dean From dean.willis at softarmor.com Tue Oct 10 16:15:53 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 10 Oct 2006 15:15:53 -0500 Subject: [p2p-sip] Proposed call on concepts and terminology draft October 16 1300 USPDT (GMT+9) In-Reply-To: References: Message-ID: <70D073E4-7376-4358-85EA-0A35DF187549@softarmor.com> Duration: Not to exceed two hours, 90 minutes preferred. On Oct 10, 2006, at 2:53 PM, Dean Willis wrote: > > > David Bryan is currently editing a new version of the Concepts and > Terminology draft that we expect to have in circulation by this > weekend. > > > We'd like to host an open conference call next week to talk through > some points on the draft, then issue another rev before the IETF 67 > cutoff. > > > The availability of our potentially-sponsoring AD is limited > (Cullen), so I'd like to propose Tuesday, October 17, at 1300 PDT > (2100 GMT if my math is right). My apologies for those of you whom > find this to be in the middle of eating, sleeping, drinking, or other > traditional after-hours occupations. > > > I need to get an estimate of the number of people who plan to attend > so I can size the conference bridge, so please RSVP by COB Friday, > October 13. > > A more detailed agenda will be forthcoming, along with the revised > draft. > > -- > Dean > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From bryan at ethernot.org Wed Oct 11 15:08:40 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 11 Oct 2006 15:08:40 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <4529ED6F.9070006@softarmor.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> Message-ID: <8b2769930610111208v7c6fef8l628bc766fb81758d@mail.gmail.com> A bit late, noticed a few things on a subsequent re-read here I wanted to comment on. Inline... On 10/9/06, Dean Willis wrote: > Spencer Dawkins wrote: > >>> I'm explicitly showing a proxy that provides overlay clients access to > >>> the > >>> overlay (Proxy Peer Q). This addresses the discussion earlier in this > >>> thread, since UA Client C will be sending GET/PUT requests via unicast > >>> to a > >>> specific overlay peer. > >> I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client > >> Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" > > > > I would like to think that Spencer, Dean, David and Eunsoo are all talking > > about similar ideas using different words... > > > > If I understand correctly, David and Eunsoo are thinking that a "Proxy Peer" > > would make a next-hop forwarding decision, which could be either to a > > conventional SIP next-hop or to a p2pSIP next-hop, while Dean is thinking of > > several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, SIP > > Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact > > phrase in his note). > > > > Ok, let's explore my mental model of how I think P2PSIP works. > > I presume that any P2PSIP peer will, if presented with a valid P2PSIP > "get" or "put" request, either process the request, pass the request to > another peer and stand by to return the result, or return a URI for > another peer that the requestor should contact directly. Further, I > presume that these operations happen at the level of the P2PSIP Peer > protocol, which may well not be SIP. I further presume that every P2PSIP > peer speaks the P2PSIP client protocol in addition to the P2PSIP peer > protocol, assuming those are actually different protocols. > > The above behavior is completely independent of SIP proxy, redirection, > and registration server functions. > > > So, here are a couple of things I think result:what > > 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP > peer understand P2PSIP Client Protocol and will, if presented with a > valid P2PSIP Client Protocol "Get" or "Put" request, do something > reasonable with that request. > > 2) There are peers and/or clients in the P2PSIP world that also serve as > SIP "server" nodes. These have SIP proxy and/or SIP redirector (I hate > the term "location server"), and/or SIP registrar functionality, and > they use the data of the P2PSIP overlay to assist in responding to SIP > request messages. This is what I think of as an adaptor node. In my architecture, there is only SIP. A regular P2PSIP Peer speaks SIP with P2P enhancements, enough to be a P2PSIP Peer (process and store resources), but might not support all the translating or processing of non-P2P SIP to proxy/redirect it to the DHT for service. In my view of the world. P2PSIP Client protocol is vanilla SIP. P2PSIP Peer Protocol is SIP + P2P extensions. A given P2PSIP Peer may NOT be fully able to support a connection from a non P2P aware client. It requires some extra logic -- basically being a "translator" that recognizes the traffic is vanilla SIP, and puts in the P2P content and sends it along. It might need to keep state for that vanilla node even. Not every P2PSIP Peer may implement or want to provide that. Those that do will logically be P2PSIP Proxy or P2PSIP Redirect peers, and in my mind are adaptor nodes. Your assessment below is right, I just don't expect every node will implement that behavior. --David > 3) Most (ok,all) P2PSIP peers will act as either SIP proxy/registrar > nodes or as SIP redirector nodes when presented with a SIP request that > does not target the user of a UA colocated with that peer. Said > otherwise, they either process SIP requests into the P2PSIP overlay, or > they redirect them to another node that is expected to do the overlay > processing needed to resolve those SIP requests. > > -- > Dean > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From hsinnrei at adobe.com Wed Oct 11 15:43:29 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Wed, 11 Oct 2006 12:43:29 -0700 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <8b2769930610111208v7c6fef8l628bc766fb81758d@mail.gmail.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221411B9@namail5.corp.adobe.com> Folks, We have to prepare a hum vote on the decision on what the p2p protocol should be: 1. Chord, Bamboo, etc., 2. SIP as David argues here, 3. Open for flexibility to accommodate future P2P protocols. This will not be an easy decision. Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Wednesday, October 11, 2006 12:09 PM To: Dean Willis Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 A bit late, noticed a few things on a subsequent re-read here I wanted to comment on. Inline... On 10/9/06, Dean Willis wrote: > Spencer Dawkins wrote: > >>> I'm explicitly showing a proxy that provides overlay clients access to > >>> the > >>> overlay (Proxy Peer Q). This addresses the discussion earlier in this > >>> thread, since UA Client C will be sending GET/PUT requests via unicast > >>> to a > >>> specific overlay peer. > >> I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client > >> Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" > > > > I would like to think that Spencer, Dean, David and Eunsoo are all talking > > about similar ideas using different words... > > > > If I understand correctly, David and Eunsoo are thinking that a "Proxy Peer" > > would make a next-hop forwarding decision, which could be either to a > > conventional SIP next-hop or to a p2pSIP next-hop, while Dean is thinking of > > several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, SIP > > Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact > > phrase in his note). > > > > Ok, let's explore my mental model of how I think P2PSIP works. > > I presume that any P2PSIP peer will, if presented with a valid P2PSIP > "get" or "put" request, either process the request, pass the request to > another peer and stand by to return the result, or return a URI for > another peer that the requestor should contact directly. Further, I > presume that these operations happen at the level of the P2PSIP Peer > protocol, which may well not be SIP. I further presume that every P2PSIP > peer speaks the P2PSIP client protocol in addition to the P2PSIP peer > protocol, assuming those are actually different protocols. > > The above behavior is completely independent of SIP proxy, redirection, > and registration server functions. > > > So, here are a couple of things I think result:what > > 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP > peer understand P2PSIP Client Protocol and will, if presented with a > valid P2PSIP Client Protocol "Get" or "Put" request, do something > reasonable with that request. > > 2) There are peers and/or clients in the P2PSIP world that also serve as > SIP "server" nodes. These have SIP proxy and/or SIP redirector (I hate > the term "location server"), and/or SIP registrar functionality, and > they use the data of the P2PSIP overlay to assist in responding to SIP > request messages. This is what I think of as an adaptor node. In my architecture, there is only SIP. A regular P2PSIP Peer speaks SIP with P2P enhancements, enough to be a P2PSIP Peer (process and store resources), but might not support all the translating or processing of non-P2P SIP to proxy/redirect it to the DHT for service. In my view of the world. P2PSIP Client protocol is vanilla SIP. P2PSIP Peer Protocol is SIP + P2P extensions. A given P2PSIP Peer may NOT be fully able to support a connection from a non P2P aware client. It requires some extra logic -- basically being a "translator" that recognizes the traffic is vanilla SIP, and puts in the P2P content and sends it along. It might need to keep state for that vanilla node even. Not every P2PSIP Peer may implement or want to provide that. Those that do will logically be P2PSIP Proxy or P2PSIP Redirect peers, and in my mind are adaptor nodes. Your assessment below is right, I just don't expect every node will implement that behavior. --David > 3) Most (ok,all) P2PSIP peers will act as either SIP proxy/registrar > nodes or as SIP redirector nodes when presented with a SIP request that > does not target the user of a UA colocated with that peer. Said > otherwise, they either process SIP requests into the P2PSIP overlay, or > they redirect them to another node that is expected to do the overlay > processing needed to resolve those SIP requests. > > -- > Dean > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From bryan at ethernot.org Wed Oct 11 16:06:09 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 11 Oct 2006 16:06:09 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221411B9@namail5.corp.adobe.com> References: <8b2769930610111208v7c6fef8l628bc766fb81758d@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D221411B9@namail5.corp.adobe.com> Message-ID: <8b2769930610111306gc7ba34fo5078d6f0015ee78@mail.gmail.com> I don't think those decisions will be made at the BOF. The Charter is designed to leave that open, but of course, it will be one of (if not the first) important questions that the (hopefully!) newly formed WG will make as a group. David On 10/11/06, Henry Sinnreich wrote: > Folks, > > We have to prepare a hum vote on the decision on what the p2p protocol > should be: > > 1. Chord, Bamboo, etc., > 2. SIP as David argues here, > 3. Open for flexibility to accommodate future P2P protocols. > > This will not be an easy decision. > > Thanks, Henry > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan > Sent: Wednesday, October 11, 2006 12:09 PM > To: Dean Willis > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 > > A bit late, noticed a few things on a subsequent re-read here I wanted > to comment on. Inline... > > On 10/9/06, Dean Willis wrote: > > Spencer Dawkins wrote: > > >>> I'm explicitly showing a proxy that provides overlay clients > access to > > >>> the > > >>> overlay (Proxy Peer Q). This addresses the discussion earlier in > this > > >>> thread, since UA Client C will be sending GET/PUT requests via > unicast > > >>> to a > > >>> specific overlay peer. > > >> I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client > > >> Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy" > > > > > > I would like to think that Spencer, Dean, David and Eunsoo are all > talking > > > about similar ideas using different words... > > > > > > If I understand correctly, David and Eunsoo are thinking that a > "Proxy Peer" > > > would make a next-hop forwarding decision, which could be either to > a > > > conventional SIP next-hop or to a p2pSIP next-hop, while Dean is > thinking of > > > several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, > SIP > > > Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this > exact > > > phrase in his note). > > > > > > > Ok, let's explore my mental model of how I think P2PSIP works. > > > > I presume that any P2PSIP peer will, if presented with a valid P2PSIP > > "get" or "put" request, either process the request, pass the request > to > > another peer and stand by to return the result, or return a URI for > > another peer that the requestor should contact directly. Further, I > > presume that these operations happen at the level of the P2PSIP Peer > > protocol, which may well not be SIP. I further presume that every > P2PSIP > > peer speaks the P2PSIP client protocol in addition to the P2PSIP peer > > protocol, assuming those are actually different protocols. > > > > The above behavior is completely independent of SIP proxy, > redirection, > > and registration server functions. > > > > > > So, here are a couple of things I think result:what > > > > 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP > > peer understand P2PSIP Client Protocol and will, if presented with a > > valid P2PSIP Client Protocol "Get" or "Put" request, do something > > reasonable with that request. > > > > 2) There are peers and/or clients in the P2PSIP world that also serve > as > > SIP "server" nodes. These have SIP proxy and/or SIP redirector (I > hate > > the term "location server"), and/or SIP registrar functionality, and > > they use the data of the P2PSIP overlay to assist in responding to SIP > > request messages. > > This is what I think of as an adaptor node. In my architecture, there > is only SIP. A regular P2PSIP Peer speaks SIP with P2P enhancements, > enough to be a P2PSIP Peer (process and store resources), but might > not support all the translating or processing of non-P2P SIP to > proxy/redirect it to the DHT for service. In my view of the world. > P2PSIP Client protocol is vanilla SIP. P2PSIP Peer Protocol is SIP + > P2P extensions. A given P2PSIP Peer may NOT be fully able to support a > connection from a non P2P aware client. It requires some extra logic > -- basically being a "translator" that recognizes the traffic is > vanilla SIP, and puts in the P2P content and sends it along. It might > need to keep state for that vanilla node even. Not every P2PSIP Peer > may implement or want to provide that. Those that do will logically be > P2PSIP Proxy or P2PSIP Redirect peers, and in my mind are adaptor > nodes. Your assessment below is right, I just don't expect every node > will implement that behavior. > > --David > > > 3) Most (ok,all) P2PSIP peers will act as either SIP proxy/registrar > > nodes or as SIP redirector nodes when presented with a SIP request > that > > does not target the user of a UA colocated with that peer. Said > > otherwise, they either process SIP requests into the P2PSIP overlay, > or > > they redirect them to another node that is expected to do the overlay > > processing needed to resolve those SIP requests. > > > > -- > > Dean > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From philip_matthews at magma.ca Wed Oct 11 18:27:50 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 11 Oct 2006 18:27:50 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221411B9@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D221411B9@namail5.corp.adobe.com> Message-ID: On 11-Oct-06, at 15:43 , Henry Sinnreich wrote: > Folks, > > We have to prepare a hum vote on the decision on what the p2p protocol > should be: > > 1. Chord, Bamboo, etc., > 2. SIP as David argues here, > 3. Open for flexibility to accommodate future P2P protocols. > > This will not be an easy decision. > > Thanks, Henry > Are these really the right choices? Chord, Bamboo, etc are DHT algorithms, while SIP is a signaling protocol, so I don't think it is an either/or choice. David's draft, for example, uses SIP as the protocol for carrying the P2P messages, while implementing a Chord DHT. We could imagine an alternative protocol that was (say) XML-based for encoding the P2P message, while still using Chord as the DHT. - Philip From philip_matthews at magma.ca Wed Oct 11 18:38:28 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 11 Oct 2006 18:38:28 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com> <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> Message-ID: <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> One of the problems with the Concepts draft right now is that a lot of aspects of the design are not decided upon, so the draft needs to be rather vague in a number of places. For example, the proposed WG has not yet decided if the protocol will be based on a DHT lookup algorithm or some other algorithm, so the draft needs to use language that accommodates both choices. As another example, the proposed WG has not decided what the format of protocols would be, so the distinction between SIP UAs, Clients, and Peers are not as crisp as they might be. One option might be to provide one or two concrete examples of how to instantiate the concepts in the draft, either in the document itself or in separate documents. - Philip On 10-Oct-06, at 13:24 , Spencer Dawkins wrote: > Hi, Dean, > >>>> Peers are supersets of clients. Everything a client can do, a >>>> peer can >>>> do. >>> >>> Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the >>> P2PSIP >>> Overlay Client PROTOCOL? >>> >> >> No, I see the inverse -- the P2PSIP Client Protocol is a "functional >> subset" of the P2PSIP Peer Protocol. It may well also be a syntactic >> subset, or even the exact same protocolbut with some of it not >> exercised >> while in client mode. > > Based on your note (and David's note yesterday), I think the > pictures I've > been working on are OK for now. > >> In my world view, the "client" vs. "peer" role is ideally >> something that >> a node decides at run time based on its perception of current >> configuration, network reachability, and other operational >> constraints. > > This seems very reasonable, from the peer's perspective. The > pictures I've > been thinking of are most appropriate if the P2PSIP Overlay Client > protocol > is not a syntactic subset. We may have different ideas about when two > protocols are "the same protocol" or not, but we don't have to > figure that > out until we have agreement on the functional subsetting. > > Thanks, > > Spencer > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From slavitch at gmail.com Wed Oct 11 19:25:42 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 11 Oct 2006 19:25:42 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> Message-ID: <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> A P2P algorithm (like DHT) can be tunneled over SIP messages in the same way PPP can be tunneled over Ethernet. This allows two DHT realms to form a union over a common signalin protocol via a super-peer that understands the babel. I'm not sure which algorithm will be used most in practise but it may not be for us to decide which is best given the applications that will come down the line. A careful choice will allow: 1. Signalling that declares the P2P algorithm in use. 2. The ability to nest (or tunnel) P2P algorithms over each other. 3. The ability to define hash table characteristics. Some algorithms will prefer to have complete tables noisily updated with all members. Others will have more sparse tables that have the potential for many hash collisions. Each have their reasons. I suspect that we will choose two or three well-known algorithms to start. Some smart effort will not limit us to these choices or to non-recursive algorithms. Regards M From ekr at networkresonance.com Wed Oct 11 19:44:00 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Wed, 11 Oct 2006 16:44:00 -0700 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> (Michael Slavitch's message of "Wed, 11 Oct 2006 19:25:42 -0400") References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> Message-ID: <86pscyfmf3.fsf@raman.networkresonance.com> "Michael Slavitch" writes: > A P2P algorithm (like DHT) can be tunneled over SIP messages in the > same way PPP can be tunneled over Ethernet. This allows two DHT > realms to form a union over a common signalin protocol via a > super-peer that understands the babel. I'm not sure which algorithm > will be used most in practise but it may not be for us to decide which > is best given the applications that will come down the line. I don't understand how you expect this to work with DHTs that implement different algorithms/topologies. How are you going to have a "union" of Chord and CAN, for instance? At a more meta-level, it seems to me that carrying the intra-DHT messages over SIP has a number of disadvantages and very few advantages. First, it imposes a very substantial burden on any other IETF protocol that wants to use DHTs--you have to implement SIP! Whenever possible, one should try to build generic tools. Second, it's not like the semantics of SIP messages aren't a particularly good fit for DHT maintenance messages. You'd just be picking some arbitrary SIP message and stuffing the upper-layer protocol in it. What's the advantage of this? -Ekr From eunsoo at research.panasonic.com Thu Oct 12 06:40:49 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 12 Oct 2006 06:40:49 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <86pscyfmf3.fsf@raman.networkresonance.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <451BDE55.5070402@research.panasonic.com> <09f801c6e722$6538bf80$0300a8c0@china.huawei.com> <0F9652DB-5224-4277-96B7-4F28DC2703FD@softarmor.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> <86pscyfmf3.fsf@raman.networkresonance.com> Message-ID: <452E1BB1.102@research.panasonic.com> Eric Rescorla wrote: >"Michael Slavitch" writes: > > >>A P2P algorithm (like DHT) can be tunneled over SIP messages in the >>same way PPP can be tunneled over Ethernet. This allows two DHT >>realms to form a union over a common signalin protocol via a >>super-peer that understands the babel. I'm not sure which algorithm >>will be used most in practise but it may not be for us to decide which >>is best given the applications that will come down the line. >> >> > >I don't understand how you expect this to work with DHTs that >implement different algorithms/topologies. How are you going >to have a "union" of Chord and CAN, for instance? > > > Salman, Henning and I looked into the possibility of forming a "union" of different DHT algorithms(networks). So far it seems difficult if not impossible. >At a more meta-level, it seems to me that carrying the intra-DHT >messages over SIP has a number of disadvantages and very few >advantages. First, it imposes a very substantial burden on any other >IETF protocol that wants to use DHTs--you have to implement SIP! >Whenever possible, one should try to build generic tools. Second, >it's not like the semantics of SIP messages aren't a particularly >good fit for DHT maintenance messages. You'd just be picking some >arbitrary SIP message and stuffing the upper-layer protocol in >it. What's the advantage of this? > > Therefore, I think we need to roughly define what fields the DHT protocol messages should carry and compare candidate base protocols (eg. SIP, SOAP, or any other) about how the fields can be carried by each base protocol. Certainly this should be a task for the (future) WG. Thanks. Eunsoo From bryan at ethernot.org Thu Oct 12 11:02:44 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 12 Oct 2006 11:02:44 -0400 Subject: [p2p-sip] Updated concepts and terminology draft available Message-ID: <8b2769930610120802m52bb8ad8v3332eb373c9c8214@mail.gmail.com> I've just completed updating the concepts and terminology draft to revision -02. I ran out of time (I wanted folks on the list to get time to look at this) and didn't get a chance to run it by all of my co-authors, so I'll take responsibility for all stupid mistakes or incorrect/controversial changes :) Major changes are far better diagrams, and shortened terminology (we don't always say "P2PSIP Overlay Whatever" but just "P2PSIP Whatever" to make the terms a bit less of a mouthful. I've also tried to capture and clarify as much of the mailing list discussion/confusion as I could. Thanks to Spencer for all the input and doing the ASCII art for me! There will be a conference call Tuesday, Oct. 17 at 4pm Eastern time to discuss edits to this draft. RSVP to Dean. His email announcing this can be found here: https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/001453.html Until the newest version shows up the I-D archive, it can be found here: http://www.p2psip.org/drafts/draft-willis-p2psip-concepts-02.html (or .txt) Thanks, David Bryan From bryan at ethernot.org Thu Oct 12 11:02:54 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 12 Oct 2006 11:02:54 -0400 Subject: [p2p-sip] I-D list at P2PSIP.org Message-ID: <8b2769930610120802m2b8ce0c8ka88f0a8d303847e1@mail.gmail.com> For those of you who have submitted IETF internet-drafts on P2PSIP: Can you please take a moment to look at http://www.p2psip.org/ietf.php, and verify we 1) have your draft listed and 2) that we have the most current revision listed (they are in newest first order)? I'd like to make sure that page is current going into the BOF. If not, please send an email describing the problem, and if possible attaching the .txt and/or .html files for me and I'll make sure things are caught up. (just send directly to me to avoid extra traffic on the list) Thanks for your time. David Bryan From slavitch at gmail.com Thu Oct 12 12:13:36 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 12 Oct 2006 12:13:36 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <452E1BB1.102@research.panasonic.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <13a401c6e8bc$4ad7f340$0300a8c0@china.huawei.com> <4529ED6F.9070006@softarmor.com> <1c6d01c6ebd6$69b47280$0300a8c0@china.huawei.com> <21ad01c6ec90$fae25320$0300a8c0@china.huawei.com> <0FF57626-DCDC-4071-92FB-CF0B31C4DEB2@magma.ca> <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> <86pscyfmf3.fsf@raman.networkresonance.com> <452E1BB1.102@research.panasonic.com> Message-ID: <1fc32c8f0610120913s1a2cd984jb5271ea8a96de91@mail.gmail.com> > Therefore, I think we need to roughly define what fields the DHT > protocol messages should carry and compare candidate base protocols (eg. > SIP, SOAP, or any other) about how the fields can be carried by each > base protocol. Certainly this should be a task for the (future) WG. > Absolutely. But bear in mind that the fields that will be carried will be highly context-dependent and these fields will evolve over time. There may be one of many possible DHT choices each supporting a set of objects that they can carry. In the OO age it may be better to refer to objects and not fields. Some of these objects will have more sticky definitions than others. Others will be overloaded depending on the application or network at hand. In that case while the base messaging protocol would be common the objects carried by the protocol become far more open. Some common elements must of course exist, so part of the protocol definition should mandate that all mandatory base common elements still appear if a field/object is overloaded with a new object definition. From br at brianrosen.net Thu Oct 12 13:51:24 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 12 Oct 2006 13:51:24 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: Message-ID: <008a01c6ee27$0ac4c240$640fa8c0@cis.neustar.com> I agree that we have separate choices: 1. We choose a DHT for the "mandatory to implement" mechanism 2. We choose two protocols "Choice" implies there is more than one proposal "Proposal" implies there are documents to define a proposal So, although the document we care about right now is the charter (and PLEASE comment on anything you don't like now, or be prepared to humm in favor of it at the BoF), I don't really see any proposals on the table to make choices from. I don't consider a simple email like "I want to use Chord" a proposal. Write up a draft about WHY is the best choice for p2psip. Also, note that we are talking in terms of "which DHT". That implies the p2p basic mandatory to implement algorithm IS A DHT. If that is not your intention speak now. Brian > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of Philip Matthews > Sent: Wednesday, October 11, 2006 6:28 PM > To: Henry Sinnreich > Cc: P2P-SIP > Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 > > > On 11-Oct-06, at 15:43 , Henry Sinnreich wrote: > > > Folks, > > > > We have to prepare a hum vote on the decision on what the p2p protocol > > should be: > > > > 1. Chord, Bamboo, etc., > > 2. SIP as David argues here, > > 3. Open for flexibility to accommodate future P2P protocols. > > > > This will not be an easy decision. > > > > Thanks, Henry > > > > Are these really the right choices? > Chord, Bamboo, etc are DHT algorithms, while SIP is a signaling > protocol, > so I don't think it is an either/or choice. > > David's draft, for example, uses SIP as the protocol for carrying the > P2P messages, > while implementing a Chord DHT. > > We could imagine an alternative protocol that was (say) XML-based for > encoding the P2P message, > while still using Chord as the DHT. > > - Philip > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From br at brianrosen.net Thu Oct 12 13:58:59 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 12 Oct 2006 13:58:59 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> Message-ID: <009301c6ee28$198580c0$640fa8c0@cis.neustar.com> We agreed at the last BoF that we would choose ONE mandatory-to-implement DHT. That guarantees interoperability of implementations. Other algorithms can also be implemented. That possibility implies there is a way to discover which algorithms a domain implements. That leads me to a question. I understand Mandatory-To-Implement. It means that a piece of code is guaranteed to work with any other piece of code if the DEPLOYMENT decrees that the mandatory to implement part is used. In this case, it means that within a p2p domain, if the chosen DHT is deployed, every client will be able to work. If another DHT is deployed, some clients may not work. Is that the end of the discussion, or is there a possibility to make things better? For example, is there any sensible way to run more than one DHT simultaneously with some kind of shared state? Brian > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of Michael Slavitch > Sent: Wednesday, October 11, 2006 7:26 PM > To: Philip Matthews > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 > > A P2P algorithm (like DHT) can be tunneled over SIP messages in the > same way PPP can be tunneled over Ethernet. This allows two DHT > realms to form a union over a common signalin protocol via a > super-peer that understands the babel. I'm not sure which algorithm > will be used most in practise but it may not be for us to decide which > is best given the applications that will come down the line. > > A careful choice will allow: > > 1. Signalling that declares the P2P algorithm in use. > 2. The ability to nest (or tunnel) P2P algorithms over each other. > 3. The ability to define hash table characteristics. Some algorithms > will prefer to have complete tables noisily updated with all members. > Others will have more sparse tables that have the potential for many > hash collisions. Each have their reasons. > > I suspect that we will choose two or three well-known algorithms to > start. Some smart effort will not limit us to these choices or to > non-recursive algorithms. > > Regards > > M > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From slavitch at gmail.com Thu Oct 12 14:51:18 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 12 Oct 2006 14:51:18 -0400 Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 In-Reply-To: <009301c6ee28$198580c0$640fa8c0@cis.neustar.com> References: <1fc32c8f0610111625x36de535dx90c8a67ee79aad63@mail.gmail.com> <009301c6ee28$198580c0$640fa8c0@cis.neustar.com> Message-ID: <1fc32c8f0610121151p45f7de79j591d2a47dae0ef0b@mail.gmail.com> On 10/12/06, Brian Rosen
wrote: > We agreed at the last BoF that we would choose ONE mandatory-to-implement > DHT. That guarantees interoperability of implementations. Other algorithms > can also be implemented. That possibility implies there is a way to > discover which algorithms a domain implements. Good. I agree that one base DHT must be there and fully supported as per mandatory in the spec by all nodes. It solves the critical first problem: Connecting the members of the network, with some form of base (ultimately canonical) identification. Then what? Now that we're connected, what's next? For example: Let's say I want to "send 10 whuffies" from my bag of whuffies to Ensoo''s bag of whuffies, but I've got a Microsoft P2PSIP whuffie-bag while Ensoo has a Pansonic P2PSIP whuffie-bag. What's worse is that my whuffies are Canadian in French while Ensoo's is American and in English, and the rules of the network is that the network gets a 2% whuffie transfer surcharge to pay for its operations, the current instantaneous settlement exchange rate is 0.90 Canadian Whuffies to the US variety, and my government charges 6% GST for the transaction Just Because It Can. I very much doubt that a Whuffie Definition (P2PSIP-WHUFFIE) will make the first spec. But I sure hope that the first cut of the object/field definition of the DHT does not preclude any FUTURE possibility for a Whuffie Definitions and Mechanisms For Peer To Peer SIP Internet-Draft, and not the April 1st variety. For the uninitiated, more on Whuffies here: http://en.wikipedia.org/wiki/Whuffie It would be a heck of a whole lot easier to implement an object extension to the current DHT than to implement a whole new DHT with new and different objects, and it would be even better if these objects were true objects and not fields. Interoperability is far more likely if it is easy to extend a well-defined DHT protocol. But I suggest that as protocol developers a hook be put in making it MANDATORY that any such extensions use well-understood, broadly implemented and well-documented means (including as a start the MANDATORY 'hello, object extensions to this DHT protocol exist, these are they, and they are defined 'here') much like we see with protocols like SMTP and HTTP. If the DHT mechanism doesn't satisfy these requirements a different DHT >may< be used for the purpose of the application (one nefarious non-scalable but I suspect pending rule may be 'no hashes allowed, only complete tables containing all members, but only for members supporting paranoid application type X), but it should not preclude a MANDATORY that such a DHT extension also carry an equally well-understood, broadly implemented and well-documented DHT definition not covered by an NDA, if it is to be considered interoperable P2PSIP. (Mil-Spec Seekrit DHT's can of course ignore this as they always do) If the existing DHT allows objects to be inserted in its list of fields, this would mean that any other DHT will only be used if the existing DHT is not up to the job, which would reduce such occurances to 1.) exception cases where it does not meet the requirements and 2.) competitive reasons to bury key features within proprietary extensions. The latter becomes somewhat more difficult if any proprietary extension must describe itself if the implementation has claims to be standards compliant, and that a rule of the protocol is that seekrit undocumented extensions are always verboten. Given that, I suspect the number of cases based on real technical limitations will be rare, meaning that other DHT types will only be used per regulatory fiat or per typical behavior of a large dominant vendor. You still will have vendors thumbing their noses at true compliance, but at least you have a strong contract to point to rather than a weak document with too much wiggle room. Regards Michael > > Is that the end of the discussion, or is there a possibility to make things > better? For example, is there any sensible way to run more than one DHT > simultaneously with some kind of shared state? > > Brian > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > > bounces at cs.columbia.edu] On Behalf Of Michael Slavitch > > Sent: Wednesday, October 11, 2006 7:26 PM > > To: Philip Matthews > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 > > > > A P2P algorithm (like DHT) can be tunneled over SIP messages in the > > same way PPP can be tunneled over Ethernet. This allows two DHT > > realms to form a union over a common signalin protocol via a > > super-peer that understands the babel. I'm not sure which algorithm > > will be used most in practise but it may not be for us to decide which > > is best given the applications that will come down the line. > > > > A careful choice will allow: > > > > 1. Signalling that declares the P2P algorithm in use. > > 2. The ability to nest (or tunnel) P2P algorithms over each other. > > 3. The ability to define hash table characteristics. Some algorithms > > will prefer to have complete tables noisily updated with all members. > > Others will have more sparse tables that have the potential for many > > hash collisions. Each have their reasons. > > > > I suspect that we will choose two or three well-known algorithms to > > start. Some smart effort will not limit us to these choices or to > > non-recursive algorithms. > > > > Regards > > > > M > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From ggb at tid.es Mon Oct 16 03:40:50 2006 From: ggb at tid.es (=?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?=) Date: Mon, 16 Oct 2006 09:40:50 +0200 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-02 Message-ID: <011801c6f0f6$69d25190$02595f0a@hi.inet> Hi, Some minor comments on the new version of draft: * The ?P2PSIP Record (user) record? definition is duplicated. They should be mixed or deleted one of them. * 3.1. Media relay: not limited to RTP. Also MSRP for example. * 3.4.3. "which speaks the P2PSIP server protocol" ==> "which speaks the P2PSIP peer protocol" * 3.4.3. "as part of enrollment of through" ==> "as part of enrollment or through" * 3.4.4. The P2PSIP client/peer could discover directly other peers (for instance using multicast) without discovering a bootstrap server before. * Although in section 3.4.2. the client protocol is defined as put/get/send, the send message is not explained/used in the rest of the draft. For example before sending a SIP message in the example signalling flows always there are Lookups operations followed by direct SIP session establishment, instead of a possible Send operation. Best regards. G. From dean.willis at softarmor.com Mon Oct 16 12:14:26 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 16 Oct 2006 11:14:26 -0500 Subject: [p2p-sip] Correction: Proposed call on concepts and terminology draft October 16 1300 USPDT (GMT+9) should be 17 Oct In-Reply-To: <453395FD.1080609@sipstation.com> References: <453395FD.1080609@sipstation.com> Message-ID: <4533AFE2.5030605@softarmor.com> I had one date on the subject line and another in the body. The correct date, as far as I know, is the one in the body -- Tuesday, October 17. I'm sorry for confusing you folks. > Dean Willis wrote: >> David Bryan is currently editing a new version of the Concepts and >> Terminology draft that we expect to have in circulation by this weekend. >> >> >> We'd like to host an open conference call next week to talk through >> some points on the draft, then issue another rev before the IETF 67 >> cutoff. >> >> >> The availability of our potentially-sponsoring AD is limited >> (Cullen), so I'd like to propose Tuesday, October 17, at 1300 PDT >> (2100 GMT if my math is right). My apologies for those of you whom >> find this to be in the middle of eating, sleeping, drinking, or other >> traditional after-hours occupations. >> >> >> I need to get an estimate of the number of people who plan to attend >> so I can size the conference bridge, so please RSVP by COB Friday, >> October 13. >> >> A more detailed agenda will be forthcoming, along with the revised >> draft. From philip_matthews at magma.ca Mon Oct 16 13:36:23 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Mon, 16 Oct 2006 13:36:23 -0400 Subject: [p2p-sip] Bridge information for conf call on Concepts draft on Oct 17th Message-ID: Folks: Dean may be tied up tomorrow, so I am going to host the conference call on the Concepts draft. Here is the bridge info: Phone number: 1-720-356-2070 Toll Free in North America: 1-866-AVAYA-22 Access Code: 159607 The call will start at 13:00 Pacific Time (or 16:00 Eastern Time or 21:00 GMT) on Tuesday, October 17th and is planned for 90 minutes. There is also a shared whiteboard application available if we find this useful. It can be activated as follows. In your browser, go to http:// webconferencing.avaya.com Enter: - Your name - Your phone number - Conference reference 158488 - Security code 159607 You will need Java and Javascript enabled on your browser, and pop-up blocking disabled. This works best with IE, but it mostly works with Safari and Firefox as well. I believe it also works with Netscape, but have not tested it. No information on other browsers, sorry. - Philip From hsinnrei at adobe.com Mon Oct 16 19:14:01 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Mon, 16 Oct 2006 16:14:01 -0700 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <4529ED6F.9070006@softarmor.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS Systems" has been posted by the IETF: http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt The I-D is also available at p2psip.org The number of SIP related standards can be significantly reduced for various application scenarios by (1) using SIP without "network based services" and (2) without emulating the telephone network. Such an approach reduces the number of SIP related standards (as by mid 2006) from roughly 100 to about 11. Core SIP interoperability and SIP compliance can be preserved without relying on complex server based networks. Successful IP communications must also include the relevant standards for NAT traversal, some of which are not directly related to SIP and also several standards for security. These standards are included here as well. Any suggestions and your FRANK opinion would be most welcome. Please use the list. Thanks, Henry From spencer at mcsr-labs.org Tue Oct 17 13:33:41 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 17 Oct 2006 12:33:41 -0500 Subject: [p2p-sip] Checking "My notes on draft-willis-p2psip-concepts-01" against version 02 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> Message-ID: <394401c6f212$63948a10$0300a8c0@china.huawei.com> Sorry for not sending this sooner. But... I'm really pleased with the changes that are now in 02. (although we might reasonably change some terminology when we make some decisions that are still open issues now, and I'm not totally sure *I* understand what an endpoint is). Just for completeness, I compared my notes on the previous version against 02. Many were addressed, so I deleted those comments from the list shown below - anything remaining is still something I'm wondering about. Please note that several of my notes are from the section on open questions, and I'm ok with these questions being open at charter time. Thanks, Spencer > P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP > Overlay Peers or Clients who are attempting to enter to locate an > entry into the P2P Overlay Network. It may return an entry point > (address of a Peer) to the P2PSIP Overlay or act as one itself. > This should be a quasi-stable and well known host, located using a > configuration or discovered via , DNS, broadcast, or other > mechanism. Example: a P2PSIP Overlay Peer that reboots and has no > knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to > find other peers in the P2P Overlay Network and establish P2PSIP > Overlay Peer Insertion. (Note: An overlay peer might or might not > provide this functionality). Short forms: bootstrap server, boot > server. > > These short forms seem very likely to conflict with lower-layer usage of > the > same terms, where "bootstrap server" and "boot server" have a > well-understood usage. "Overlay bootstrap server" as short form? This is now "bootstrap peer". That's an improvement. > 3.3. Conceptual Outline of Operations > > 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer > > Peers are the full-function "routing and storage" nodes of a P2PSIP > Overlay. When a new peer is first created, it must enroll in the > P2PSIP Overlay. We currently have no defined mechanism for this (do > we need one?), but we know that once the process is complete, the new > > I think this is required for the ad hoc scenarios, isn't it? > > peer will have at least a P2PSIP Overlay Peer Key and a set of > credentials. This is now in section 3.4.1, and has changed, but still says Peers are the full-function "routing and storage" nodes of a P2PSIP Overlay. When a new peer is first created, it must enroll in the P2PSIP Overlay. We currently have no defined mechanism for this (should this group define one?), I would like stronger text, something like "and this is required for P2PSIP interoperation in at least some scenarios". The current text allows us to say "no, it's fine for us to leave this to vendor-specific operation", so users would have to use the right vendor's product to participate in the overlay - this is a big deal, but it's a bigger deal for ad hoc scenarios where you could walk into an overlay using enrollment from any vendor. > 3.3.2. More on The Difference Between a Peer, Client, and User Agent > > P2PSIP Overlay Peers directly interact with and contain the routing > and storage fabric of the overlay. P2PSIP Overlay Clients just use > the routing and storage facilities provided by the peers. The peers > speak the P2PSIP Overlay Peer Protocol, which presumably has a full > range of expressivity for the routing and storage facilities of the > > "expressivity" is a great word. Is it defined anywhere? ;-) Dean pointed out that expressivity is a real word, but I still struggling with the usage here. "Functionality"? > overlay. Clients speak the P2PSIP Overlay Client protocol, which is > presumably a subset of the peer protocol, and is limited to storage > insertion (put), storage retrieval (get), and message routing (send). > > 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent > > To get started, users must be enrolled in the overlay. We do not > have a process or protocol for this, nor are we certain we need a > standardized mechanism. We presume that after enrollment, the user > has a distinguished name within the overlay (example: > sip:bob at example.com) and a set of credentials useful for > authenticating its usage of the distinguished name. One possible > mechanism for these credentials would be an x.509 certificate. It > might also be possible to use a PGP key, a password, or some other > mechanism. Presumably following enrollment, the user is also > equipped with the information needed to connect to the overlay, such > as the address of a bootstrap server. Whether this startup > information is delivered as a part of enrollment of through some > separate configuration process remains an open question. > > I would like to define this, but am concerned that the choice may differ > per-overlay. Do others agree? The text moved to 3.4.3, and changed in 02. It is now Whether this startup information is delivered as a part of enrollment of through some separate configuration process remains an open question, and it is not clear it is within the scope of the proposed WG. I would be concerned if at least the requirements for enrolling and inserting users are out of scope for P2PSIP. Is this text saying that P2PSIP might not be chartered to develop the mechanism (I could agree) or that P2PSIP might not be chartered to specify requirements for this mechanism, whether it is developed in P2PSIP or in another appropriate working group (this is harder to accept)? > 3.3.5. Bootstrapping > > If a client or peer is just starting up and has no knowledge of how > to reach the other nodes of the overlay, it may exercise a bootstrap > server to find one. Presumably it discovers the bootstrap server by > some mechanism such as a DNS lookup, multicast, broadcast or > configuration, then queries the bootstrap server and receives an > address for a peer or set of peers that can be used to reach the > overlay. Ideally, these target peers will be selected from a > relatively large pool of peers that are currently online and > reachable. > > This last sentence seems awfully use case-specific, doesn't it? This text is now in 3.4.5, but hasn't changed. The point I was trying to make in my notes was made more clearly by David Bryan in an e-mail onlist: "One of the many reasons I am so keen on using pure SIP for the client protocol is that if one bootstraping peer is overloaded, it can simply 302 (or perhaps 301 if it wants this requestor to keep using another peer) incoming requests off to a less loaded peer." I think what the paragraph SHOULD say is, "Ideally, P2PSIP will allow target peer selection in a way that allows recovery from overload situations". > 4.9. Cryptotransparency > > When forwarding requests, are the bodies of the requests visible to > peers? If so, this creates substantial security problems that the > deployers of conventional SIP have been willing to mostly ignore. > Can we make peers cryptotransparent (like HTTP proxies) when security > is requested? > > I believe this question is key when we discuss what an endpoint is (see > previous comments on whether clients are endpoints). This is now 4.6, but hasn't changed in 02. I am still confused about the expected trust model in a peer/UA-to-peer/UA dialog versus a peer/UA-to-peer/UA-to-client/UA dialog (assuming that there are only two endpoints of the trust relationship, does the first peer/UA NOT trust the second peer/UA, or does the first peer/UA NOT trust the client/UA? I don't think we have to know the answer to this question to charter the working group, but I think we need to agree on whether it's an interesting question or not. > 4.13. Bootstrapping > > We know that sometimes peers or clients will start up without > knowledge of how to find a peer for insertion. Do we need to define > a bootstrap mechanism or mechanisms? Do we need to define supporting > protocols? > > I believe the answer to both of these is "yes" to support anything like ad > hoc use cases. This is now 4.10, but the text has not changed. Again, I would like stronger text, something like, "Do we need to define a bootstrap mechanism, or mechanisms, and do we need to define the supporting protocols? If P2PSIP has interoperability except at boot time, this means P2PSIP does not have interoperability." Or something. Mumble. > 4.16. Hybrid Domains > > It appears possible to have some hosts within a domain using > conventional SIP and some using P2PSIP. This potentially raises a > number of questions: 1) What should happen if we want to run a P2PSIP > overlay in an existing SIP domain? 2) Do the existing redir/proxy > servers need to be coupled with a peer layer? 3) When would an > overlay peer want to discover them as opposed to looking in the > overlay? 4) Is better not to run conventional SIP with overlay SIP? > 5) When conventional and P2PSIP are run together, shall the existing > redir servers keep their local databases or switch to the overlay > storage. > > We've had some discussion on-list here about whether I have the same AOR > in > conventional SIP and P2PSIP overlays or not. Did we converge? Dean says, and I agree, that we have not converged. This text is now 4.13, but has not changed. Could we add a note something like "One related question is whether a UA could use the same AOR in conventional SIP and in P2PSIP. This isn't known yet, and the answer affects the ability of P2PSIP to support "hybrid domains" ? From arjun.lists at hsc.com Tue Oct 17 13:58:55 2006 From: arjun.lists at hsc.com (Arjun Roychowdhury) Date: Tue, 17 Oct 2006 13:58:55 -0400 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> References: <4529ED6F.9070006@softarmor.com> <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> Message-ID: Henry, Comments: * I find the title of the draft confusing. It seems to be a first step in trying to put one's arms around what is the minimal feature set of SIP we need for a P2P system and what architectural assumptions we may/may not make - to that extent not sure 'tools' fit in at all, more like 'minimal architecture and feature assumptions for P2P SIP' - actually it sounds very much like a subset profile, though you explictly state it is not (why ?) * 2.b) . "Analyze the main SIP related specifications as highlighted in [14] and eliminate all network based services residing in servers and various other network elements. " You need to either specify what you mean by "network based services" concretely, or drop this term, since later you state that Locating SIP servers is a 'core requirement' - location/routing is also a network based service. * You may need to add a section on interoperability with nonp2p SIP networks - what are the assumptions, who you delegate the role of interoperability to etc. regds arjun On 10/16/06, Henry Sinnreich wrote: > The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS > Systems" has been posted by the IETF: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt > > The I-D is also available at p2psip.org > > The number of SIP related standards can be significantly > reduced for various application scenarios by (1) using SIP > without "network based services" and (2) without emulating the > telephone network. > > Such an approach reduces the number of SIP related standards > (as by mid 2006) from roughly 100 to about 11. Core SIP > interoperability and SIP compliance can be preserved without > relying on complex server based networks. > > Successful IP communications must also include the relevant > standards for NAT traversal, some of which are not directly > related to SIP and also several standards for security. These > standards are included here as well. > > Any suggestions and your FRANK opinion would be most welcome. > Please use the list. > > Thanks, Henry > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Arjun Roychowdhury From swb at employees.org Tue Oct 17 14:47:52 2006 From: swb at employees.org (Scott W Brim) Date: Tue, 17 Oct 2006 14:47:52 -0400 Subject: [p2p-sip] Checking "My notes on draft-willis-p2psip-concepts-01" against version 02 In-Reply-To: <394401c6f212$63948a10$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <394401c6f212$63948a10$0300a8c0@china.huawei.com> Message-ID: <20061017184752.GA5436@sbrim-wxp01> Excerpts from Spencer Dawkins on Tue, Oct 17, 2006 12:33:41PM -0500: > Sorry for not sending this sooner. But... I thought I was way late with my comments so I just sent them to the authors. They're small but I'll post them after this. > Peers are the full-function "routing and storage" nodes of a > P2PSIP Overlay. When a new peer is first created, it must enroll > in the P2PSIP Overlay. We currently have no defined mechanism > for this (should this group define one?), > > I would like stronger text, something like "and this is required for > P2PSIP interoperation in at least some scenarios". The current text > allows us to say "no, it's fine for us to leave this to > vendor-specific operation", so users would have to use the right > vendor's product to participate in the overlay - this is a big deal, > but it's a bigger deal for ad hoc scenarios where you could walk > into an overlay using enrollment from any vendor. Regarding peer enrollment and user enrollment (below). Enrollment is completely separate from the actual functioning of the P2P system, so if we specify anything it should not be more than a default -- for example configuration. There are so many possible mechanisms. > > the routing and storage facilities provided by the peers. The > > peers speak the P2PSIP Overlay Peer Protocol, which presumably > > has a full range of expressivity for the routing and storage > > facilities of the > > > > "expressivity" is a great word. Is it defined anywhere? ;-) > > Dean pointed out that expressivity is a real word, but I still > struggling with the usage here. "Functionality"? Simplest would be "has a full range of capability for expressing the routing and storage ...". Scott From philip_matthews at magma.ca Tue Oct 17 15:36:36 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 17 Oct 2006 15:36:36 -0400 Subject: [p2p-sip] Reminder: Conf call on Concepts draft is ON for today Message-ID: <7C1D76B4-B8B6-461C-9157-8B622BEF782E@magma.ca> The call is today. 13:00 Pacific, 16:00 Eastern, 21:00 GMT I have added some extra ports to the bridge, so even if you haven't RSVP'ed to Dean, we can probably accommodate you. I sent out bridge information yesterday. Spencer has offered to take jabber minutes, so if you can get your jabber client running in the next 30 minutes, that would also be good. - Philip From spencer at mcsr-labs.org Tue Oct 17 15:43:17 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 17 Oct 2006 14:43:17 -0500 Subject: [p2p-sip] jabber for p2psip today References: <20061017193901.GD4232@sbrim-wxp01> Message-ID: <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> Hi, Scott, > what's the jabber conf room? > > swb ... and then I woke up ... I have suggested to Philip that attendees on today's call use jabber.ietf.org/p2p-sip ("the normal jabber room for us, because we're a BOF"). Non-attendees would be welcome to watch (in amazement?), as well, of course. Thanks, Spencer From edpimentl at gmail.com Tue Oct 17 16:08:37 2006 From: edpimentl at gmail.com (Ed Pimentel) Date: Tue, 17 Oct 2006 16:08:37 -0400 Subject: [p2p-sip] jabber for p2psip today In-Reply-To: <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> References: <20061017193901.GD4232@sbrim-wxp01> <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> Message-ID: Just became aware of this meeting. Can I get the logistics on how to join? -E http://agilesip.com http://agilepay.ws On Oct 17, 2006, at 3:43 PM, Spencer Dawkins wrote: > Hi, Scott, > >> what's the jabber conf room? >> >> swb > > ... and then I woke up ... > > I have suggested to Philip that attendees on today's call use > jabber.ietf.org/p2p-sip ("the normal jabber room for us, because > we're a > BOF"). > > Non-attendees would be welcome to watch (in amazement?), as well, > of course. > > Thanks, > > Spencer > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From slavitch at gmail.com Tue Oct 17 16:34:41 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Tue, 17 Oct 2006 16:34:41 -0400 Subject: [p2p-sip] jabber for p2psip today In-Reply-To: <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> References: <20061017193901.GD4232@sbrim-wxp01> <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> Message-ID: <1fc32c8f0610171334j2ffb66b6l7942e9f01440c004@mail.gmail.com> 404 for me on jabber.ietf.org. On 10/17/06, Spencer Dawkins wrote: > Hi, Scott, > > > what's the jabber conf room? > > > > swb > > ... and then I woke up ... > > I have suggested to Philip that attendees on today's call use > jabber.ietf.org/p2p-sip ("the normal jabber room for us, because we're a > BOF"). > > Non-attendees would be welcome to watch (in amazement?), as well, of course. > > Thanks, > > Spencer > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From swb at employees.org Tue Oct 17 16:49:51 2006 From: swb at employees.org (Scott W Brim) Date: Tue, 17 Oct 2006 16:49:51 -0400 Subject: [p2p-sip] jabber for p2psip today In-Reply-To: <1fc32c8f0610171334j2ffb66b6l7942e9f01440c004@mail.gmail.com> References: <20061017193901.GD4232@sbrim-wxp01> <3a4101c6f224$7e501600$0300a8c0@china.huawei.com> <1fc32c8f0610171334j2ffb66b6l7942e9f01440c004@mail.gmail.com> Message-ID: <20061017204951.GG4232@sbrim-wxp01> Excerpts from Michael Slavitch on Tue, Oct 17, 2006 04:34:41PM -0400: > 404 for me on jabber.ietf.org. Try again? Works for me. From dean.willis at softarmor.com Tue Oct 17 17:04:42 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 17 Oct 2006 16:04:42 -0500 Subject: [p2p-sip] Comments on concepts-02 Message-ID: 1) We have an inconsistency between "short form" and "other form" in definitions. The original intent here was to include "also known as" terms that people are likely to use accidentally. I think as we harden the vocabulary consensus, we can withdraw some or most of these. 2) Need to reconcile Resource and User. Question: Is a STUN relay a user or a resource? If it differs from a "user", what are the implications from a definitional perspective? Is its identifier of a different class? Do we have different classes of resources? How does this relate to having multiple types of resource records? 3) Definition P2PSIP Overlay Neighbor can be reduced to P2PSIP Neighbor, as we did with other terms. 4) Need to reconcile two instances of user record definition. Both definitions have useful content, and I don't want to lose the "stored route" text. 5) Currently, question 4.9 is written as: 4.9. Peer and User Credentials We believe we need some sort of credentials for authenticating peers and users of each P2PSIP Overlay. What should we use for these credentials? Certificates? PGP keys? Passwords? If certificates, should these be signed by a CA associated with the overlay, or can self-signed certificates work in some or all cases? Do we need to specify a standard credential format, or should we allow different implementations to use different credential formats? Cullen suggested instead something like: We assume a security model based on the issuance of credentials by an authority (presumably centralized) for each P2PSIP Overlay. What form of credential should be used? Do we need to specify a standard certificate format, or should we allow different implementations to use different certificate formats? Note that the above doesn't actually work in some of the use cases, such as the anonymous-communication scenarios or the overlay that requires initial self-organization under ad-hoc network conditions and lacks a centralized source of authority. Under certain circumstances, it might be suitable to do something like generate randomized distinguished names and self-signed certificates for those names. How shall we account for this in the draft? -- Dean From fluffy at cisco.com Tue Oct 17 18:25:46 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 17 Oct 2006 15:25:46 -0700 Subject: [p2p-sip] Chairs for upcoming P2PSIP BOF Message-ID: <24030964-49BE-43BE-BEEF-F4953371319F@cisco.com> Brian Rosen and David Bryan have graciously agreed to co-chair the BOF. Thank you both, Cullen From hsinnrei at adobe.com Tue Oct 17 21:17:49 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Tue, 17 Oct 2006 18:17:49 -0700 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141206@namail5.corp.adobe.com> Arjun, > what is the minimal feature set of SIP we need for a P2P system and what > architectural assumptions we may/may not make This is good point - we will cover in the next version. >You need to either specify what you mean by "network based services" This is also a good point since what is meant by "network based" services needs some examples, such as voice mail, conferencing, (hosted) PBX functions. Maybe an acceptable definition is "anything else but a proxy/redirect SIP server" since these functions are basically message routing functions only. >* You may need to add a section on interoperability with nonp2p SIP > networks. The above could also take care of p2p-cs interoperability. Thanks for the comments, Henry -----Original Message----- From: arjunrc at gmail.com [mailto:arjunrc at gmail.com] On Behalf Of Arjun Roychowdhury Sent: Tuesday, October 17, 2006 12:59 PM To: Henry Sinnreich Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems Henry, Comments: * I find the title of the draft confusing. It seems to be a first step in trying to put one's arms around what is the minimal feature set of SIP we need for a P2P system and what architectural assumptions we may/may not make - to that extent not sure 'tools' fit in at all, more like 'minimal architecture and feature assumptions for P2P SIP' - actually it sounds very much like a subset profile, though you explictly state it is not (why ?) * 2.b) . "Analyze the main SIP related specifications as highlighted in [14] and eliminate all network based services residing in servers and various other network elements. " You need to either specify what you mean by "network based services" concretely, or drop this term, since later you state that Locating SIP servers is a 'core requirement' - location/routing is also a network based service. * You may need to add a section on interoperability with nonp2p SIP networks - what are the assumptions, who you delegate the role of interoperability to etc. regds arjun On 10/16/06, Henry Sinnreich wrote: > The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS > Systems" has been posted by the IETF: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt > > The I-D is also available at p2psip.org > > The number of SIP related standards can be significantly > reduced for various application scenarios by (1) using SIP > without "network based services" and (2) without emulating the > telephone network. > > Such an approach reduces the number of SIP related standards > (as by mid 2006) from roughly 100 to about 11. Core SIP > interoperability and SIP compliance can be preserved without > relying on complex server based networks. > > Successful IP communications must also include the relevant > standards for NAT traversal, some of which are not directly > related to SIP and also several standards for security. These > standards are included here as well. > > Any suggestions and your FRANK opinion would be most welcome. > Please use the list. > > Thanks, Henry > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Arjun Roychowdhury From zhuxian at huawei.com Wed Oct 18 08:55:56 2006 From: zhuxian at huawei.com (zhuxian) Date: Wed, 18 Oct 2006 20:55:56 +0800 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: Message-ID: <000101c6f2b4$c0d44650$76244e0a@china.huawei.com> Hi: As to the peer and user credentials, I think using certificate is a reasonable selection. Because it has already been used in many p2p platform design, such as JXTA and microsoft PNRP. And also, it is a reasonable distributed authentication mechanism for p2p. If we use password, who know your password, except the centralized user server. A big question is, whether we use a CA or self-signed certificate. I think it is related to the security level we want to attain in the p2p sip world. Just using the self-signed certificate work well in some situation. But it can not defend the sybil and eclipse attacking, whick may turn the p2p sip overlay down in some situation. Use a certificate be signed by a CA is Ok. But we need to do more in the p2p sip world. Because anonymous-communication is an important character we want to achieve. And also the revoke problem in CA is more serious in p2p sip as the number of user may be huge and user may be dynamic. As for the overlay that requires initial self-organization under ad-hoc network conditions and lacks a centralized source of authority, we can not get the security level when the overlay is accompany with a CA. Use the self-signed ceritficate is ok in these scenarios. But i think it's compatible with the CA approach in the peer/client implementation. Peer/client can just downgrade the security level in these sitution. As to the credential format, why don't we use a standard credential format, such as X.509? Does the standard credential format can't fulfill the credential requirement in p2p sip? Xian Zhu ----- Original Message ----- from : p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] Dean Willis wrote: send: Oct 18, 2006 5:05 am to: p2p-sip at cs.columbia.edu subject: [p2p-sip] Comments on concepts-02 4.9. Peer and User Credentials We believe we need some sort of credentials for authenticating peers and users of each P2PSIP Overlay. What should we use for these credentials? Certificates? PGP keys? Passwords? If certificates, should these be signed by a CA associated with the overlay, or can self-signed certificates work in some or all cases? Do we need to specify a standard credential format, or should we allow different implementations to use different credential formats? Cullen suggested instead something like: We assume a security model based on the issuance of credentials by an authority (presumably centralized) for each P2PSIP Overlay. What form of credential should be used? Do we need to specify a standard certificate format, or should we allow different implementations to use different certificate formats? Note that the above doesn't actually work in some of the use cases, such as the anonymous-communication scenarios or the overlay that requires initial self-organization under ad-hoc network conditions and lacks a centralized source of authority. Under certain circumstances, it might be suitable to do something like generate randomized distinguished names and self-signed certificates for those names. How shall we account for this in the draft? -- Dean _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From drage at lucent.com Wed Oct 18 09:22:15 2006 From: drage at lucent.com (Drage, Keith (Keith)) Date: Wed, 18 Oct 2006 15:22:15 +0200 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems Message-ID: <5D1A7985295922448D5550C94DE29180625857@DEEXC1U01.de.lucent.com> First, I believe the proposed charter for p2p-sip precludes discussion of this in the new working group if it is formed. Having said that, lets discuss it. Rather than trying to make mileage out of 100 versus 11, presumably based on the fact that a lot of things that are useful are simulating the telephone network and not therefore required (like the ability to describe a voice only session in SDP - no RFC 4566 reference), can I suggest that the better way of doing this would be to describe what is in the current sip hitchhiker document that is NOT needed because it is a centralised function that is no longer required in the p2p-sip architecture. As such it will need to track the SIP hitchhiker document as that develops. If the feature is still required, then it would need to indicate the means of supporting that feature. Further, to take an example, it does not show the sip-identity document (RFC 4474). Either authenticated identity is regarded as too telephony like and it is eliminated for those purposes (in which case I note some email systems seem to be doing it), or it is eliminated because it needs some sort of server to provide a certification body. My understanding is that even p2p-sip will have to have centralised certification, and therefore that criteria for elimination would be unreasonable. I do accept that RFC 3325 would not figure because it requires centralised capabilities. Regards Keith > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich > Sent: 17 October 2006 00:14 > To: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic > CS Systems > > The Internet Draft "Lightweight SIP Toolkit for P2P and Basic > CS Systems" has been posted by the IETF: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt > > The I-D is also available at p2psip.org > > The number of SIP related standards can be significantly > reduced for various application scenarios by (1) using SIP > without "network based services" and (2) without emulating the > telephone network. > > Such an approach reduces the number of SIP related standards > (as by mid 2006) from roughly 100 to about 11. Core SIP > interoperability and SIP compliance can be preserved without > relying on complex server based networks. > > Successful IP communications must also include the relevant > standards for NAT traversal, some of which are not directly > related to SIP and also several standards for security. These > standards are included here as well. > > Any suggestions and your FRANK opinion would be most welcome. > Please use the list. > > Thanks, Henry > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From swb at employees.org Wed Oct 18 11:07:36 2006 From: swb at employees.org (Scott W Brim) Date: Wed, 18 Oct 2006 11:07:36 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <000101c6f2b4$c0d44650$76244e0a@china.huawei.com> References: <000101c6f2b4$c0d44650$76244e0a@china.huawei.com> Message-ID: <20061018150736.GC4468@sbrim-wxp01> Excerpts from zhuxian on Wed, Oct 18, 2006 08:55:56PM +0800: > Hi: > As to the peer and user credentials, I think using certificate is a > reasonable selection. Because it has already been used in many p2p platform > design, such as JXTA and microsoft PNRP. And also, it is a reasonable > distributed authentication mechanism for p2p. If we use password, who know > your password, except the centralized user server. > A big question is, whether we use a CA or self-signed certificate. I > think it is related to the security level we want to attain in the p2p sip > world. Just using the self-signed certificate work well in some situation. > But it can not defend the sybil and eclipse attacking, whick may turn the > p2p sip overlay down in some situation. Use a certificate be signed by a CA > is Ok. But we need to do more in the p2p sip world. Because > anonymous-communication is an important character we want to achieve. And > also the revoke problem in CA is more serious in p2p sip as the number of > user may be huge and user may be dynamic. > > As for the overlay that requires initial self-organization under ad-hoc > network conditions and lacks a centralized source of authority, we can not > get the security level when the overlay is accompany with a CA. Use the > self-signed ceritficate is ok in these scenarios. But i think it's > compatible with the CA approach in the peer/client implementation. > Peer/client can just downgrade the security level in these sitution. This all makes sense, and should all be included in security discussions -- not just in the concepts draft but in protocol drafts. We need to ensure that the mechanisms _can_ provide the security needed for global deployments, with the possibility of less overhead in more casual environments. That should all be explained (as above) as background for mechanism selection. swb From spencer at mcsr-labs.org Wed Oct 18 11:10:13 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 18 Oct 2006 10:10:13 -0500 Subject: [p2p-sip] Comments on concepts-02 References: <000101c6f2b4$c0d44650$76244e0a@china.huawei.com> <20061018150736.GC4468@sbrim-wxp01> Message-ID: <3e3701c6f2c7$833b19a0$0300a8c0@china.huawei.com> I mentioned to Zhuxian privately that my understanding from yesterday's call is that the authors agree with his statement, and that Dean was likely documenting the issue for the mailing list so that we are all thinking about it, not just people on the call. Thanks, Spencer From: "Scott W Brim" > Excerpts from zhuxian on Wed, Oct 18, 2006 08:55:56PM +0800: >> Hi: >> As to the peer and user credentials, I think using certificate is a >> reasonable selection. Because it has already been used in many p2p >> platform >> design, such as JXTA and microsoft PNRP. And also, it is a reasonable >> distributed authentication mechanism for p2p. If we use password, who >> know >> your password, except the centralized user server. >> A big question is, whether we use a CA or self-signed certificate. >> I >> think it is related to the security level we want to attain in the p2p >> sip >> world. Just using the self-signed certificate work well in some >> situation. >> But it can not defend the sybil and eclipse attacking, whick may turn the >> p2p sip overlay down in some situation. Use a certificate be signed by a >> CA >> is Ok. But we need to do more in the p2p sip world. Because >> anonymous-communication is an important character we want to achieve. And >> also the revoke problem in CA is more serious in p2p sip as the number of >> user may be huge and user may be dynamic. >> >> As for the overlay that requires initial self-organization under >> ad-hoc >> network conditions and lacks a centralized source of authority, we can >> not >> get the security level when the overlay is accompany with a CA. Use the >> self-signed ceritficate is ok in these scenarios. But i think it's >> compatible with the CA approach in the peer/client implementation. >> Peer/client can just downgrade the security level in these sitution. > > This all makes sense, and should all be included in security > discussions -- not just in the concepts draft but in protocol drafts. > We need to ensure that the mechanisms _can_ provide the security > needed for global deployments, with the possibility of less overhead > in more casual environments. That should all be explained (as above) > as background for mechanism selection. > > swb > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Wed Oct 18 11:59:15 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 08:59:15 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <000101c6f2b4$c0d44650$76244e0a@china.huawei.com> Message-ID: <003801c6f2ce$5f4c2b90$030aa8c0@comcast.net> X.509 for P2P-SIP is like butcher knife for tomato. Even in known C/S deployments X.509 is rarely seen used with CPEs for signaling or provisioning. Peter ----- Original Message ----- From: "zhuxian" To: "'Dean Willis'" Cc: Sent: Wednesday, October 18, 2006 5:55 AM Subject: Re: [p2p-sip] Comments on concepts-02 > Hi: > As to the peer and user credentials, I think using certificate is a > reasonable selection. Because it has already been used in many p2p platform > design, such as JXTA and microsoft PNRP. And also, it is a reasonable > distributed authentication mechanism for p2p. If we use password, who know > your password, except the centralized user server. > A big question is, whether we use a CA or self-signed certificate. I > think it is related to the security level we want to attain in the p2p sip > world. Just using the self-signed certificate work well in some situation. > But it can not defend the sybil and eclipse attacking, whick may turn the > p2p sip overlay down in some situation. Use a certificate be signed by a CA > is Ok. But we need to do more in the p2p sip world. Because > anonymous-communication is an important character we want to achieve. And > also the revoke problem in CA is more serious in p2p sip as the number of > user may be huge and user may be dynamic. > > As for the overlay that requires initial self-organization under ad-hoc > network conditions and lacks a centralized source of authority, we can not > get the security level when the overlay is accompany with a CA. Use the > self-signed ceritficate is ok in these scenarios. But i think it's > compatible with the CA approach in the peer/client implementation. > Peer/client can just downgrade the security level in these sitution. > > As to the credential format, why don't we use a standard credential > format, such as X.509? Does the standard credential format can't fulfill the > credential requirement in p2p sip? > > > Xian Zhu > > ----- Original Message ----- > from : p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] Dean Willis wrote: > send: Oct 18, 2006 5:05 am > to: p2p-sip at cs.columbia.edu > subject: [p2p-sip] Comments on concepts-02 > > > 4.9. Peer and User Credentials > > We believe we need some sort of credentials for authenticating peers > and users of each P2PSIP Overlay. What should we use for these > credentials? Certificates? PGP keys? Passwords? If certificates, > should these be signed by a CA associated with the overlay, or can > self-signed certificates work in some or all cases? Do we need to > specify a standard credential format, or should we allow different > implementations to use different credential formats? > > Cullen suggested instead something like: > > We assume a security model based on the issuance of credentials by > an authority (presumably centralized) for each P2PSIP Overlay. What > form of credential should be used? Do we need to specify a standard > certificate format, or should we allow different implementations to > use different certificate formats? > > Note that the above doesn't actually work in some of the use cases, such as > the anonymous-communication scenarios or the overlay that requires initial > self-organization under ad-hoc network conditions and lacks a centralized > source of authority. Under certain circumstances, it might be suitable to do > something like generate randomized distinguished names and self-signed > certificates for those names. How shall we account for this in the draft? > > -- > Dean > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From slavitch at gmail.com Wed Oct 18 12:08:52 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 18 Oct 2006 12:08:52 -0400 Subject: [p2p-sip] Authorities and signing, based on comments on concepts-02 Message-ID: <1fc32c8f0610180908t29b14612v843c61afac9db4cc@mail.gmail.com> Some questions on making self-signing acceptable to security AD's: 1. Is self-signing better if the identity that is self-signing for the network persistent and assured? Would it be considered better? For example, Phil Zimmerman's zRTP is somewhat useful for creating RTP sessions but the concept is far more useful in day to day life for creating persistent trust of identity. 2. If the identity of the signer is trusted by the P2P universe (and the identity mechanism is trustworty) isn't this as good as a CA for the context at hand? And given how many people properly maintain their issued certs isn't in fact better? 3. Who decides trust? Does trust >need< an external CA authority? Is this a requirement of the security AD's? 4. If self-signing could only be done by entities having 'perceived trust' does this mean that the "Central Authority" is now a role that could be distributed or shared? 5. Essentially, what does "Central Authority" mean in a world of peers? From philip_matthews at magma.ca Wed Oct 18 14:20:41 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 14:20:41 -0400 Subject: [p2p-sip] Jabber logs and audio playback of conf call on Concepts draft Message-ID: Folks: An audio playback of yesterday's conference call on the Concepts draft is available. To access it: 1) Phone: 720-356-2070 (or 1-866-AVAYA-22) 2) Enter participant code of 910573# 3) Enter *3 4) Enter file number of 26602# The playback lasts approximately 1 hour and 46 minutes. The jabber chat logs of the call are also available. These serve as rough minutes of the call. They are at http://www.ietf.org/meetings/ietf-logs/p2p-sip/2006-10-17.html - Philip From philip_matthews at magma.ca Wed Oct 18 15:20:58 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 15:20:58 -0400 Subject: [p2p-sip] My notes from the Conference Call on the Concepts draft Message-ID: Folks: Below are my notes from the conference call on Oct 17th on the Concepts draft. - Philip ================ Attendees: Philip Matthews Spencer Dawkins Adrian Georgescu Cullen Jennings David Bryan Eunsoo Shim Arjun Roychowdhury Alan Johnston Frank Miller Scott Brim Sathya Narayanan Dean Willis Keith Drage Michael Slavich Decisions: 1) "P2PSIP Peer-ID" Should we use a different name? No, for now, stick with this term. 2) Section 4.9 should state that a central certificate authority will be used to hand out certificates. 3) "P2PSIP Client": If SIP is used as the client protocol, then a SIP Client could be identical to a "standard SIP entity" (rather than a "standard SIP user agent" as -02 says). In other words, in this case, a client could be any form of SIP entity, not just a UA. [Similar wording changes may be required elsewhere in the document] 4) In section 4, add text that says that these are questions that the WG will have to address. In other words, the document will not take a stand on these until an official decision has been made by the WG. 5) Remove most of the "Short forms" or "Other forms" in the terminology section. If someone feels some alternative forms must be listed, they should send e-mail to Philip ASAP. 6) "P2PSIP Client". Can we find a better term? No better suggestion right now. However, will add text saying that a Client is not the same as a SIP UAC. 7) Discussion of "User" vs. "Resource". No consensus. Will leave the text as "Resource (User)" for now and continue the debate later. 8) Delete second occurrence of "P2PSIP Resource (User) Record", since the first definition is the more general. 9) Will add a section before 3.3 that briefly describes the Get and Put operations of the Client protocol. Will delete the "Send" operation for now, but add some text saying that there needs to be a way to relay messages through intermediate nodes to get to peers behind NATs. From philip_matthews at magma.ca Wed Oct 18 15:25:34 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 15:25:34 -0400 Subject: [p2p-sip] Short forms in Concepts draft Message-ID: <400B395A-077F-449E-9CEE-6E62A8500ABF@magma.ca> As stated in the conference call yesterday, I am planning to remove most of the "short forms" and "other forms" from the terminology section. I know that David had a few he thought really needed to be kept. If anyone else has any, please send them to the list ASAP. - Philip From philip_matthews at magma.ca Wed Oct 18 15:29:54 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 15:29:54 -0400 Subject: [p2p-sip] Working on -03 version of Concepts draft Message-ID: In case people missed it, I am currently working on the -03 revision of the Concepts draft. (There are 4 co-authors, and we are passing the editing baton around). The deadline is Monday, and I don't like working on weekends, so the next couple of days would be a REALLY GOOD TIME to send comments on this draft. - Philip From philip_matthews at magma.ca Wed Oct 18 15:42:49 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 15:42:49 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: Message-ID: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> On 17-Oct-06, at 17:04 , Dean Willis wrote: > > > 1) We have an inconsistency between "short form" and "other form" in > definitions. The original intent here was to include "also known as" > terms that people are likely to use accidentally. I think as we > harden the vocabulary consensus, we can withdraw some or most of > these. Yup. I am planning to remove all but those that people tell me are critical to keep. > > 2) Need to reconcile Resource and User. Question: Is a STUN relay a > user or a resource? If it differs from a "user", what are the > implications from a definitional perspective? Is its identifier of a > different class? Do we have different classes of resources? How does > this relate to having multiple types of resource records? Very good question. I didn't see any consensus on how to do this on yesterday's call, so I am planning to leave things as is in the -03 version. [But folks, let's discuss so we can fix things for the -04 version!] > > 3) Definition P2PSIP Overlay Neighbor can be reduced to P2PSIP > Neighbor, as we did with other terms. Yup. > > 4) Need to reconcile two instances of user record definition. Both > definitions have useful content, and I don't want to lose the "stored > route" text. On yesterday's call, I read the consensus as being to remove the second definition, because the first definition subsumed it. So right now, this is what I am planning to do. I don't see this as a big loss, because "stored route" is just one more piece of data about a user, and we don't have document that describes what this might really look like yet. > > > 5) Currently, question 4.9 is written as: > > 4.9. Peer and User Credentials > > We believe we need some sort of credentials for authenticating > peers > and users of each P2PSIP Overlay. What should we use for these > credentials? Certificates? PGP keys? Passwords? If > certificates, > should these be signed by a CA associated with the overlay, or can > self-signed certificates work in some or all cases? Do we need to > specify a standard credential format, or should we allow different > implementations to use different credential formats? > > Cullen suggested instead something like: > > We assume a security model based on the issuance of credentials by > an authority (presumably centralized) for each P2PSIP Overlay. > What > form of credential should be used? Do we need to specify a > standard > certificate format, or should we allow different > implementations to > use different certificate formats? > > Note that the above doesn't actually work in some of the use cases, > such as the anonymous-communication scenarios or the overlay that > requires initial self-organization under ad-hoc network conditions > and lacks a centralized source of authority. Under certain > circumstances, it might be suitable to do something like generate > randomized distinguished names and self-signed certificates for those > names. How shall we account for this in the draft? > [Disclaimer: I am a security neophyte, so take this response with a big grain of salt.] My view, which I tried to express yesterday, is that the use of such a centralized authority is optional. In other words, if a P2PSIP Overlay doesn't want to use it (because it wants to allow anonymous peers and/or is running under conditions where contacting a central authority is not practical or desired), then it just doesn't. I will try to add this somehow to the text above which you ascribe to Cullen. - Philip From petithug at acm.org Wed Oct 18 16:25:19 2006 From: petithug at acm.org (Marc Petit-Huguenin) Date: Wed, 18 Oct 2006 13:25:19 -0700 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> Message-ID: <45368DAF.6020508@acm.org> Hi Henry, I like your I-D a lot. I think that it is time for SIP to go back to a strong support of the end-to-end principle, and to clearly indicate to implementors what part of SIP is SIP, and what part is for supporting legacy systems (PSTN, IMS, etc...). This remind me of what was done ten years ago for movies, when independent filmmakers defined Dogma 95[1] as a set of rules to purify movie making. I see a lot of parallels, so I am proposing the name "Dogma 06" for this effort to purify SIP. Thanks. [1] http://en.wikipedia.org/wiki/Dogma_95 Henry Sinnreich wrote: > The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS > Systems" has been posted by the IETF: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt > > The I-D is also available at p2psip.org > > The number of SIP related standards can be significantly > reduced for various application scenarios by (1) using SIP > without "network based services" and (2) without emulating the > telephone network. > > Such an approach reduces the number of SIP related standards > (as by mid 2006) from roughly 100 to about 11. Core SIP > interoperability and SIP compliance can be preserved without > relying on complex server based networks. > > Successful IP communications must also include the relevant > standards for NAT traversal, some of which are not directly > related to SIP and also several standards for security. These > standards are included here as well. > > Any suggestions and your FRANK opinion would be most welcome. > Please use the list. > > Thanks, Henry > -- Marc Petit-Huguenin [ ] Home: marc at petit-huguenin.org [ This RFC1855-compliant space ] Work: marc at 8x8.com [ for rent ] From edpimentl at gmail.com Wed Oct 18 17:25:10 2006 From: edpimentl at gmail.com (Ed Pimentel) Date: Wed, 18 Oct 2006 17:25:10 -0400 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <45368DAF.6020508@acm.org> References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> <45368DAF.6020508@acm.org> Message-ID: <8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> This is a case when "perfect" is not good enough. We all recall the failure of X.400/500 and a more pragmatic/workable solution LDAP has provided Or the failure of OSI - NMS and how SNMP came to the rescue. What we need now is a SSIP a SIMPLE Session Initiation Protocol that simply just works and does not try to replicate the CLASS5 Services but in turns innovates with what I call CLASS 6 Services.... Where as CLASS 5 services schackled you to the black 2500 ma-bell phone.... Class 6 cuts the unbilical chords and innovates by providing beyond voip services that are not necessarily to the PSTN/SS7/IN/SCP network. -E On Oct 18, 2006, at 4:25 PM, Marc Petit-Huguenin wrote: > Hi Henry, > > I like your I-D a lot. I think that it is time for SIP to go back > to a > strong support of the end-to-end principle, and to clearly indicate to > implementors what part of SIP is SIP, and what part is for supporting > legacy systems (PSTN, IMS, etc...). > > This remind me of what was done ten years ago for movies, when > independent filmmakers defined Dogma 95[1] as a set of rules to purify > movie making. I see a lot of parallels, so I am proposing the name > "Dogma 06" for this effort to purify SIP. > > Thanks. > > > [1] http://en.wikipedia.org/wiki/Dogma_95 > > Henry Sinnreich wrote: >> The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS >> Systems" has been posted by the IETF: >> >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt >> >> The I-D is also available at p2psip.org >> >> The number of SIP related standards can be significantly >> reduced for various application scenarios by (1) using SIP >> without "network based services" and (2) without emulating the >> telephone network. >> >> Such an approach reduces the number of SIP related standards >> (as by mid 2006) from roughly 100 to about 11. Core SIP >> interoperability and SIP compliance can be preserved without >> relying on complex server based networks. >> >> Successful IP communications must also include the relevant >> standards for NAT traversal, some of which are not directly >> related to SIP and also several standards for security. These >> standards are included here as well. >> >> Any suggestions and your FRANK opinion would be most welcome. >> Please use the list. >> >> Thanks, Henry >> > > -- > Marc Petit-Huguenin [ ] > Home: marc at petit-huguenin.org [ This RFC1855-compliant space ] > Work: marc at 8x8.com [ for rent ] > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From philip_matthews at magma.ca Wed Oct 18 17:39:07 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 17:39:07 -0400 Subject: [p2p-sip] The terms I want to save... In-Reply-To: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> Message-ID: Copying the list, since we really should have this discussion in public. On 18-Oct-06, at 16:58 , David A. Bryan wrote: > Assuming we cut all the short versions (be prepared for folks to still > use them...I'm not going to have the word "P2PSIP" in front of every > time I say peer or overlay in all my drafts), I really care about > (some of which I noticed aren't there now): I am proposing to blow away all these "P2PSIP" prefixes. See separate e-mail. > > P2PSIP Peer: node I added the text "(Note: The P2P literature often uses the term "node" instead of "peer")" > > P2PSIP Peer-ID: Node-ID I added the text: "(Note: This is often called a "Node-ID" in the P2P literature)." > > P2PSIP User Agent: P2PSIP UA The hanging text now reads "P2PSIP User Agent (UA):" > > P2PSIP Bootstrap Server: bootstrap peer, bootstrap node See separate e-mail. > > P2PSIP Peer Insertion: peer or node join, peer or node registration I added the text: (Note: In the P2P literature, this operation is often called "joining" or "registering" with the overlay). > > P2PSIP Resource (User) Record Insertion: user registration I think this one is controversial, since we have not yet resolved the "resource" vs. "user" debate. From philip_matthews at magma.ca Wed Oct 18 17:40:58 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 17:40:58 -0400 Subject: [p2p-sip] Fwd: Concepts draft: dropping "P2PSIP" in terms References: <760DD15A-7FB1-412F-8E78-AEA57899D91E@magma.ca> Message-ID: Copying the list, since others need to have input into this decision. - Philip Begin forwarded message: > From: Philip Matthews > Date: October 18, 2006 17:08:45 EDT (CA) > To: Dean Willis , "David A. Bryan" > , Eunsoo Shim > Subject: Concepts draft: dropping "P2PSIP" in terms > > Right now, almost all the terms in the Concepts draft start with > "P2PSIP". > But in practice, everyone drops this. > > So I am proposing to blow all these away and say (for example) > "Peer-ID" rather than "P2PSIP Peer-ID". > This is consistent with what I have seen almost everywhere else. > For example, SIP documents usually talk about a "User Agent", not a > "SIP User Agent", > MPLS documents talk about an "LSP", not an "MPLS LSP", > the HTTP document talk about a "Get operation", not an "HTTP Get > operation", etc. etc. > > Comments? > > - Philip From bryan at ethernot.org Wed Oct 18 17:42:42 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 17:42:42 -0400 Subject: [p2p-sip] The terms I want to save... In-Reply-To: References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> Message-ID: <8b2769930610181442y6089e155s2b59a741bc7235d5@mail.gmail.com> In response to removing P2PSIP prefix in most places in the draft: Although I don't intend to use the long form in all places in my *other* drafts, in this one we just agreed to blow away the short form "Peer-ID" in all the definitions. I think it is really bad to define P2PSIP Peer-ID, not list Peer-ID as a short form, and then use the short form anyway. Either we leave all the short versions in the definitions, or we use the full versions in the text, at least within this document. Besides, if it is there, just leave it. I think hacking out existing text to make it less specific isn't really worth the time. My 2 cents. On 10/18/06, Philip Matthews wrote: > Copying the list, since we really should have this discussion in public. > > On 18-Oct-06, at 16:58 , David A. Bryan wrote: > > > Assuming we cut all the short versions (be prepared for folks to still > > use them...I'm not going to have the word "P2PSIP" in front of every > > time I say peer or overlay in all my drafts), I really care about > > (some of which I noticed aren't there now): > I am proposing to blow away all these "P2PSIP" prefixes. > See separate e-mail. > > > > > P2PSIP Peer: node > I added the text > "(Note: The P2P literature often uses the term "node" > instead of "peer")" > > > > P2PSIP Peer-ID: Node-ID > I added the text: > "(Note: This is often called a "Node-ID" in the P2P > literature)." > > > > > P2PSIP User Agent: P2PSIP UA > The hanging text now reads "P2PSIP User Agent (UA):" > > > > > P2PSIP Bootstrap Server: bootstrap peer, bootstrap node > See separate e-mail. > > > > > P2PSIP Peer Insertion: peer or node join, peer or node registration > I added the text: > (Note: In the P2P literature, this operation is often called > "joining" or > "registering" with the overlay). > > > > > P2PSIP Resource (User) Record Insertion: user registration > > I think this one is controversial, since we have not yet resolved the > "resource" vs. "user" debate. > > > > From huang-ming.pan at comcast.net Wed Oct 18 17:48:25 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 14:48:25 -0700 Subject: [p2p-sip] Comments on concepts-02 Message-ID: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> By "X.509 is rarely seen used with CPEs" I meant that it is rare for server to authenticate clients, not to mention to verify "realworld identity" of the clients. That is why I think in P2P environment "detailed" or realworld identity (first/last name, common name, organization...) is less essential than merely ensuring the peer not to be a malicious peer so that we can correctly fulfill peer-to-peer functionality of a P2P-SIP network. In such a try-and-error environment full of uninsured attempts, very often you just want to make sure that the peer you're talking to is indeed belonging to the network and is helpful; you don't care which of John or Mary the peer is. There is "Simple Public Key Infrastructure" (SPKI). Just don't know whether there is "simple certificate". Duh, I know THERE IS. Skype uses PKI but not X.509 !! My point is just: P2P-SIP seems to me not "so simple" in the long run as you define and implement it for serious commercial competence. Maybe it is time to rid of unnecessary code such like ASN.1. Simplicity or small footprint (of protocol or code) is always a mercy to others as well as to yourself. Maybe this is what was exactly in minds of the two authors of the Touring-Machine awarded PDP-11 UNIX. Peter ----- Original Message ----- From: "Peter Pan" To: "zhuxian" ; "'Dean Willis'" Cc: Sent: Wednesday, October 18, 2006 8:59 AM Subject: Re: [p2p-sip] Comments on concepts-02 > X.509 for P2P-SIP is like butcher knife for tomato. > > Even in known C/S deployments X.509 is rarely seen used with CPEs for > signaling or provisioning. > > Peter > ----- Original Message ----- > From: "zhuxian" > To: "'Dean Willis'" > Cc: > Sent: Wednesday, October 18, 2006 5:55 AM > Subject: Re: [p2p-sip] Comments on concepts-02 > > > > Hi: > > As to the peer and user credentials, I think using certificate is a > > reasonable selection. Because it has already been used in many p2p > platform > > design, such as JXTA and microsoft PNRP. And also, it is a reasonable > > distributed authentication mechanism for p2p. If we use password, who know > > your password, except the centralized user server. > > A big question is, whether we use a CA or self-signed certificate. I > > think it is related to the security level we want to attain in the p2p sip > > world. Just using the self-signed certificate work well in some situation. > > But it can not defend the sybil and eclipse attacking, whick may turn the > > p2p sip overlay down in some situation. Use a certificate be signed by a > CA > > is Ok. But we need to do more in the p2p sip world. Because > > anonymous-communication is an important character we want to achieve. And > > also the revoke problem in CA is more serious in p2p sip as the number of > > user may be huge and user may be dynamic. > > > > As for the overlay that requires initial self-organization under ad-hoc > > network conditions and lacks a centralized source of authority, we can not > > get the security level when the overlay is accompany with a CA. Use the > > self-signed ceritficate is ok in these scenarios. But i think it's > > compatible with the CA approach in the peer/client implementation. > > Peer/client can just downgrade the security level in these sitution. > > > > As to the credential format, why don't we use a standard credential > > format, such as X.509? Does the standard credential format can't fulfill > the > > credential requirement in p2p sip? > > > > > > Xian Zhu > > > > ----- Original Message ----- > > from : p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] Dean Willis wrote: > > send: Oct 18, 2006 5:05 am > > to: p2p-sip at cs.columbia.edu > > subject: [p2p-sip] Comments on concepts-02 > > > > > > 4.9. Peer and User Credentials > > > > We believe we need some sort of credentials for authenticating peers > > and users of each P2PSIP Overlay. What should we use for these > > credentials? Certificates? PGP keys? Passwords? If certificates, > > should these be signed by a CA associated with the overlay, or can > > self-signed certificates work in some or all cases? Do we need to > > specify a standard credential format, or should we allow different > > implementations to use different credential formats? > > > > Cullen suggested instead something like: > > > > We assume a security model based on the issuance of credentials by > > an authority (presumably centralized) for each P2PSIP Overlay. What > > form of credential should be used? Do we need to specify a standard > > certificate format, or should we allow different implementations to > > use different certificate formats? > > > > Note that the above doesn't actually work in some of the use cases, such > as > > the anonymous-communication scenarios or the overlay that requires initial > > self-organization under ad-hoc network conditions and lacks a centralized > > source of authority. Under certain circumstances, it might be suitable to > do > > something like generate randomized distinguished names and self-signed > > certificates for those names. How shall we account for this in the draft? > > > > -- > > Dean > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From philip_matthews at magma.ca Wed Oct 18 17:47:28 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 17:47:28 -0400 Subject: [p2p-sip] Concepts draft: dropping "P2PSIP" in terms In-Reply-To: <8b2769930610181439s6a090762yb5f60260a2a33f24@mail.gmail.com> References: <760DD15A-7FB1-412F-8E78-AEA57899D91E@magma.ca> <8b2769930610181439s6a090762yb5f60260a2a33f24@mail.gmail.com> Message-ID: <61B1C752-F1CD-405E-8CDC-362E17F3A62B@magma.ca> I didn't express myself well. I am proposing to replace "P2PSIP Peer-ID" with "Peer-ID" EVERYWHERE it appears in the document. And similarly replace "P2PSIP Client Protocol" with "Client Protocol", "P2PSIP Peer Insertion" with "Peer Insertion", etc. etc. - Philip On 18-Oct-06, at 17:39 , David A. Bryan wrote: > Although I don't intend to use the long form in all places in my other > drafts, in this one we just agreed to blow away the short form > "Peer-ID" in all the definitions. I think it is really bad to define > P2PSIP Peer-ID, not list Peer-ID as a short form, and then use the > short form anyway. > > Besides, if it is there, just leave it. > > My 2 cents. > > On 10/18/06, Philip Matthews wrote: >> Right now, almost all the terms in the Concepts draft start with >> "P2PSIP". >> But in practice, everyone drops this. >> >> So I am proposing to blow all these away and say (for example) "Peer- >> ID" rather than "P2PSIP Peer-ID". >> This is consistent with what I have seen almost everywhere else. >> For example, SIP documents usually talk about a "User Agent", not a >> "SIP User Agent", >> MPLS documents talk about an "LSP", not an "MPLS LSP", >> the HTTP document talk about a "Get operation", not an "HTTP Get >> operation", etc. etc. >> >> Comments? >> >> - Philip >> From philip_matthews at magma.ca Wed Oct 18 17:51:28 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 17:51:28 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer References: Message-ID: Copying the list on this one too. - Philip Begin forwarded message: > From: Philip Matthews > Date: October 18, 2006 17:27:33 EDT (CA) > To: Dean Willis , Eunsoo Shim > , "David A. Bryan" > Subject: Concepts draft: Bootstrap server vs. bootstrap peer > > Right now, the Concepts draft lists "bootstrap peer" as an alias > for "bootstrap server". > > I think these two terms are quite distinct. > > As I see it, a bootstrap server is a node (usually not a peer) in > the Internet that allows > a node to find peers that are already in the overlay. This is often > called a "Rendezvous > Server" in the literature. > > By contrast, a "bootstrap peer" is a peer in the overlay that > registers with the bootstrap > server. This peer serves as the initial point of contact into the > overlay for the new peer > that is trying to join. > > In my view, the peers in the overlay elect one or more of their > number to act as bootstrap > peers. These bootstrap peers register with (one or more) bootstrap > servers. When a new > peer wants to join the overlay, it contacts the bootstrap servers > that it knows about (using > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted > a bootstrap peer, > the new peer does not need the services of the bootstrap server any > more. > > I am planning to write this up as a draft shortly. > > In the meantime, I am proposing to: > > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and > 2) Introduce "bootstrap peer" as a distinct term. > > If people find (2) to be too controversial, then I can stick with > just (1) > (until I write my draft ;-). > > Comments? > > - Philip > From bryan at ethernot.org Wed Oct 18 17:54:10 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 17:54:10 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> Message-ID: <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> > In such a try-and-error environment full of uninsured attempts, very often > you just want to make sure that the peer you're talking to is indeed > belonging to the network and is helpful; you don't care which of John or > Mary the peer is. If the different John's are just different UAs all associated with the same user (human), probably true, but if you mean I try call John Smith and reach John Doe (different human), that scenario seems pretty useless. I think just proving you are part of the overlay isn't really that useful, if people can clobber user names. Even if everyone is well behaved, it wouldn't even have to be malicious -- could just be that two people with the same name, intending to play by the rules, both log on (say at different times, not realizing there is a collision) and may not even realize they are confusing folks who are trying to call them and getting different people. It is really hard to assert identity (as opposed to ensuring it was the same person you talked to last time, which is easier) in the absence of some sort of centralized server. Not everyone can be lonelygirl15. --David From bryan at ethernot.org Wed Oct 18 17:56:19 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 17:56:19 -0400 Subject: [p2p-sip] Concepts draft: dropping "P2PSIP" in terms In-Reply-To: <61B1C752-F1CD-405E-8CDC-362E17F3A62B@magma.ca> References: <760DD15A-7FB1-412F-8E78-AEA57899D91E@magma.ca> <8b2769930610181439s6a090762yb5f60260a2a33f24@mail.gmail.com> <61B1C752-F1CD-405E-8CDC-362E17F3A62B@magma.ca> Message-ID: <8b2769930610181456s5a25b388saa957b16a1f317da@mail.gmail.com> Personally I like it as is, at least for now with the BOF coming up and trying to minimize confusion and give us common lingo. Some or even many of them work without it, but some shortened (say Client Protocol, particularly) could be very confusing. David On 10/18/06, Philip Matthews wrote: > I didn't express myself well. > > I am proposing to replace "P2PSIP Peer-ID" with "Peer-ID" > EVERYWHERE it appears in the document. > > And similarly replace "P2PSIP Client Protocol" with "Client Protocol", > "P2PSIP Peer Insertion" with "Peer Insertion", etc. etc. > > - Philip > > On 18-Oct-06, at 17:39 , David A. Bryan wrote: > > > Although I don't intend to use the long form in all places in my other > > drafts, in this one we just agreed to blow away the short form > > "Peer-ID" in all the definitions. I think it is really bad to define > > P2PSIP Peer-ID, not list Peer-ID as a short form, and then use the > > short form anyway. > > > > Besides, if it is there, just leave it. > > > > My 2 cents. > > > > On 10/18/06, Philip Matthews wrote: > >> Right now, almost all the terms in the Concepts draft start with > >> "P2PSIP". > >> But in practice, everyone drops this. > >> > >> So I am proposing to blow all these away and say (for example) "Peer- > >> ID" rather than "P2PSIP Peer-ID". > >> This is consistent with what I have seen almost everywhere else. > >> For example, SIP documents usually talk about a "User Agent", not a > >> "SIP User Agent", > >> MPLS documents talk about an "LSP", not an "MPLS LSP", > >> the HTTP document talk about a "Get operation", not an "HTTP Get > >> operation", etc. etc. > >> > >> Comments? > >> > >> - Philip > >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From bryan at ethernot.org Wed Oct 18 17:58:28 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 17:58:28 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: References: Message-ID: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> logical vs. physical role. I guess my 2 cents is that anything that serves as a bootstrap server can be one (could also happen to be a peer). Being a bootstrap server is a logical role that can be co-located with a peer/node. On 10/18/06, Philip Matthews wrote: > Copying the list on this one too. > - Philip > > Begin forwarded message: > > > From: Philip Matthews > > Date: October 18, 2006 17:27:33 EDT (CA) > > To: Dean Willis , Eunsoo Shim > > , "David A. Bryan" > > Subject: Concepts draft: Bootstrap server vs. bootstrap peer > > > > Right now, the Concepts draft lists "bootstrap peer" as an alias > > for "bootstrap server". > > > > I think these two terms are quite distinct. > > > > As I see it, a bootstrap server is a node (usually not a peer) in > > the Internet that allows > > a node to find peers that are already in the overlay. This is often > > called a "Rendezvous > > Server" in the literature. > > > > By contrast, a "bootstrap peer" is a peer in the overlay that > > registers with the bootstrap > > server. This peer serves as the initial point of contact into the > > overlay for the new peer > > that is trying to join. > > > > In my view, the peers in the overlay elect one or more of their > > number to act as bootstrap > > peers. These bootstrap peers register with (one or more) bootstrap > > servers. When a new > > peer wants to join the overlay, it contacts the bootstrap servers > > that it knows about (using > > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted > > a bootstrap peer, > > the new peer does not need the services of the bootstrap server any > > more. > > > > I am planning to write this up as a draft shortly. > > > > In the meantime, I am proposing to: > > > > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and > > 2) Introduce "bootstrap peer" as a distinct term. > > > > If people find (2) to be too controversial, then I can stick with > > just (1) > > (until I write my draft ;-). > > > > Comments? > > > > - Philip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From hgs at cs.columbia.edu Wed Oct 18 18:04:43 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Wed, 18 Oct 2006 18:04:43 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> Message-ID: <4536A4FB.4090809@cs.columbia.edu> I think there's a middle ground, namely where one leverages existing structures to assert identity uniqueness. In practical terms: it is fairly straightforward for a node to ascertain whether somebody new is indeed the owner of an email address - just send a message to that address and see if the destination agrees. This doesn't really require a "centralized server" as such, but does require leveraging some other infrastructure and mechanisms of identity generation. There are numerous variations on this concept: - Prove ownership of a bank account by reporting on small deposits made; - Prove ownership of a DNS domain by adding or modifying a host entry in the domain - Prove ownership of a phone number by getting a call and entering number - Prove ownership of an IP address by responding to a nonce or random identifier sent (e.g., a variation in TCP) I think that in many practical cases, leveraging such identities will be the lowest-cost way to avoiding collisions, both intentional and otherwise. Henning David A. Bryan wrote: >> In such a try-and-error environment full of uninsured attempts, very often >> you just want to make sure that the peer you're talking to is indeed >> belonging to the network and is helpful; you don't care which of John or >> Mary the peer is. > > If the different John's are just different UAs all associated with the > same user (human), probably true, but if you mean I try call John > Smith and reach John Doe (different human), that scenario seems pretty > useless. > > I think just proving you are part of the overlay isn't really that > useful, if people can clobber user names. Even if everyone is well > behaved, it wouldn't even have to be malicious -- could just be that > two people with the same name, intending to play by the rules, both > log on (say at different times, not realizing there is a collision) > and may not even realize they are confusing folks who are trying to > call them and getting different people. > > It is really hard to assert identity (as opposed to ensuring it was > the same person you talked to last time, which is easier) in the > absence of some sort of centralized server. Not everyone can be > lonelygirl15. > > --David > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From philip_matthews at magma.ca Wed Oct 18 18:10:10 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Oct 2006 18:10:10 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> Message-ID: Sure. A bootstrap server can be a bootstrap peer as well, or even just a peer and not a bootstrap peer (though this one is a bit weird!). However, in the typical deployment, I strongly suspect that bootstrap servers will be distinct from bootstrap peers. As I see it, there will be lots and lots of distinct overlays, each of which elects one or more bootstrap peers to register with a fairly small number of bootstrap servers. - Philip On 18-Oct-06, at 17:58 , David A. Bryan wrote: > logical vs. physical role. I guess my 2 cents is that anything that > serves as a bootstrap server can be one (could also happen to be a > peer). Being a bootstrap server is a logical role that can be > co-located with a peer/node. > > On 10/18/06, Philip Matthews wrote: >> Copying the list on this one too. >> - Philip >> >> Begin forwarded message: >> >> > From: Philip Matthews >> > Date: October 18, 2006 17:27:33 EDT (CA) >> > To: Dean Willis , Eunsoo Shim >> > , "David A. Bryan" >> >> > Subject: Concepts draft: Bootstrap server vs. bootstrap peer >> > >> > Right now, the Concepts draft lists "bootstrap peer" as an alias >> > for "bootstrap server". >> > >> > I think these two terms are quite distinct. >> > >> > As I see it, a bootstrap server is a node (usually not a peer) in >> > the Internet that allows >> > a node to find peers that are already in the overlay. This is often >> > called a "Rendezvous >> > Server" in the literature. >> > >> > By contrast, a "bootstrap peer" is a peer in the overlay that >> > registers with the bootstrap >> > server. This peer serves as the initial point of contact into the >> > overlay for the new peer >> > that is trying to join. >> > >> > In my view, the peers in the overlay elect one or more of their >> > number to act as bootstrap >> > peers. These bootstrap peers register with (one or more) bootstrap >> > servers. When a new >> > peer wants to join the overlay, it contacts the bootstrap servers >> > that it knows about (using >> > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted >> > a bootstrap peer, >> > the new peer does not need the services of the bootstrap server any >> > more. >> > >> > I am planning to write this up as a draft shortly. >> > >> > In the meantime, I am proposing to: >> > >> > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and >> > 2) Introduce "bootstrap peer" as a distinct term. >> > >> > If people find (2) to be too controversial, then I can stick with >> > just (1) >> > (until I write my draft ;-). >> > >> > Comments? >> > >> > - Philip >> > >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> From huang-ming.pan at comcast.net Wed Oct 18 18:11:38 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 15:11:38 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> Message-ID: <00b701c6f302$64a7a3b0$030aa8c0@comcast.net> ----- Original Message ----- From: "David A. Bryan" To: "Peter Pan" Cc: "zhuxian" ; "Dean Willis" ; Sent: Wednesday, October 18, 2006 2:54 PM Subject: Re: [p2p-sip] Comments on concepts-02 > If the different John's are just different UAs all associated with the > same user (human), probably true, but if you mean I try call John > Smith and reach John Doe (different human), that scenario seems pretty > useless. You seems out of the condition :) After your initial bootstrap with the central authority, the certificate associated with you in every later p2p operation can fully prove who you really are. For example, you might be assigned a unique 64bit identifier and the certificate proves the identifier is with you "David A. Bryan". Once the certificate is signed, it is no possible that you can manipulate the certificate to pretend you're another David or Mary. Simpy put, if your concern is valid, Skype is not as safe as it declare. When I registered "Peter Pan" on Skype, I'm actually not Peter but H.M.Pan. Actually I could change myself to "David A. Bryan" if I wish. > > I think just proving you are part of the overlay isn't really that > useful, if people can clobber user names. Even if everyone is well > behaved, it wouldn't even have to be malicious -- could just be that > two people with the same name, intending to play by the rules, both > log on (say at different times, not realizing there is a collision) > and may not even realize they are confusing folks who are trying to > call them and getting different people. As for how to make sure the one you're calling is the one you want to call, it seems to me not at all an issue of certificate. For example, I dont identify my wife (she uses Skype too) by inspecting her certificate like we inspect BofA certificate to not be fished; I'm some sure neither does Skype program itself. I dentify my wife because Skype presented her correct email address and that information may/can not be in Skype certificate. Before presenting my wife to me, Skype server verifies it somwehere else. > > It is really hard to assert identity (as opposed to ensuring it was > the same person you talked to last time, which is easier) in the > absence of some sort of centralized server. Not everyone can be > lonelygirl15. This is agreed. > > --David From huang-ming.pan at comcast.net Wed Oct 18 18:15:59 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 15:15:59 -0700 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrappeer References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> Message-ID: <00c601c6f302$fdf53eb0$030aa8c0@comcast.net> ----- Original Message ----- From: "David A. Bryan" To: "Philip Matthews" Cc: "P2P-SIP" Sent: Wednesday, October 18, 2006 2:58 PM Subject: Re: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrappeer > logical vs. physical role. I guess my 2 cents is that anything that > serves as a bootstrap server can be one (could also happen to be a > peer). Being a bootstrap server is a logical role that can be > co-located with a peer/node. Sorry. Cannot fully agree with you again. If any peer can colocate CA or bootstrap server, no bootstrap server is needed. Of course, if you're talking of "web of trust", it is another case. > > On 10/18/06, Philip Matthews wrote: > > Copying the list on this one too. > > - Philip > > > > Begin forwarded message: > > > > > From: Philip Matthews > > > Date: October 18, 2006 17:27:33 EDT (CA) > > > To: Dean Willis , Eunsoo Shim > > > , "David A. Bryan" > > > Subject: Concepts draft: Bootstrap server vs. bootstrap peer > > > > > > Right now, the Concepts draft lists "bootstrap peer" as an alias > > > for "bootstrap server". > > > > > > I think these two terms are quite distinct. > > > > > > As I see it, a bootstrap server is a node (usually not a peer) in > > > the Internet that allows > > > a node to find peers that are already in the overlay. This is often > > > called a "Rendezvous > > > Server" in the literature. > > > > > > By contrast, a "bootstrap peer" is a peer in the overlay that > > > registers with the bootstrap > > > server. This peer serves as the initial point of contact into the > > > overlay for the new peer > > > that is trying to join. > > > > > > In my view, the peers in the overlay elect one or more of their > > > number to act as bootstrap > > > peers. These bootstrap peers register with (one or more) bootstrap > > > servers. When a new > > > peer wants to join the overlay, it contacts the bootstrap servers > > > that it knows about (using > > > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted > > > a bootstrap peer, > > > the new peer does not need the services of the bootstrap server any > > > more. > > > > > > I am planning to write this up as a draft shortly. > > > > > > In the meantime, I am proposing to: > > > > > > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and > > > 2) Introduce "bootstrap peer" as a distinct term. > > > > > > If people find (2) to be too controversial, then I can stick with > > > just (1) > > > (until I write my draft ;-). > > > > > > Comments? > > > > > > - Philip > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From bryan at ethernot.org Wed Oct 18 18:15:40 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 18:15:40 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <4536A4FB.4090809@cs.columbia.edu> References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> <4536A4FB.4090809@cs.columbia.edu> Message-ID: <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> Fully agree that approach could work. We actually proposed using email based protection just like this as out auth mechanism in the -00 version of draft-bryan-sipping-p2p, but felt it might not be as secure as we wanted in all scenarios. Technically, as many people pointed out to us, that is still a "centralized authority" -- in this case the DNS/mail servers. It also won't work in truly ad-hoc/disconnected scenarios (DNS dependent). The other problem is who checks the authenticity before admitting a node (in other words, who prompts by sending email?) You have a bit of a risk of a malicious node "confirming" that someone is who they say they are falsely, and the question of how often this check needs to be performed (each time they start their client and the overlay? If only once, how do we persist the authentication in the overlay so an email challenge doesn't have to be resent?) Some of the other ideas you mentioned make very good sense too, with the same (possible) problems, but I still believe this kind of approach could work and is worth exploring a bit more to see if we tighten up the holes. David On 10/18/06, Henning Schulzrinne wrote: > I think there's a middle ground, namely where one leverages existing > structures to assert identity uniqueness. In practical terms: it is > fairly straightforward for a node to ascertain whether somebody new is > indeed the owner of an email address - just send a message to that > address and see if the destination agrees. This doesn't really require a > "centralized server" as such, but does require leveraging some other > infrastructure and mechanisms of identity generation. There are numerous > variations on this concept: > > - Prove ownership of a bank account by reporting on small deposits made; > > - Prove ownership of a DNS domain by adding or modifying a host entry in > the domain > > - Prove ownership of a phone number by getting a call and entering number > > - Prove ownership of an IP address by responding to a nonce or random > identifier sent (e.g., a variation in TCP) > > I think that in many practical cases, leveraging such identities will be > the lowest-cost way to avoiding collisions, both intentional and otherwise. > > Henning > > David A. Bryan wrote: > >> In such a try-and-error environment full of uninsured attempts, very often > >> you just want to make sure that the peer you're talking to is indeed > >> belonging to the network and is helpful; you don't care which of John or > >> Mary the peer is. > > > > If the different John's are just different UAs all associated with the > > same user (human), probably true, but if you mean I try call John > > Smith and reach John Doe (different human), that scenario seems pretty > > useless. > > > > I think just proving you are part of the overlay isn't really that > > useful, if people can clobber user names. Even if everyone is well > > behaved, it wouldn't even have to be malicious -- could just be that > > two people with the same name, intending to play by the rules, both > > log on (say at different times, not realizing there is a collision) > > and may not even realize they are confusing folks who are trying to > > call them and getting different people. > > > > It is really hard to assert identity (as opposed to ensuring it was > > the same person you talked to last time, which is easier) in the > > absence of some sort of centralized server. Not everyone can be > > lonelygirl15. > > > > --David > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From spencer at mcsr-labs.org Wed Oct 18 18:14:27 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 18 Oct 2006 17:14:27 -0500 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrappeer References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> Message-ID: <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> Darn. I thought I was already agreeing with this one. I sent mail previously expressing a desire to call the bootstrap server something else, and Philip says it's usually called something else in P2P literature. On my planet, a bootstrap server/boot server is a BOOTP/DHCP thing, a couple of levels down. I thought we liked "bootstrap peer", but see that we are talking about two things (with one term, usually a bad sign). My preference is to use "rendezvous server" and "bootstrap peer" for the two concepts Philip describes, which I think Philip might agree with (I hope so, because I'm trying to agree with HIM). I think this clearly points out that we might have a variety of ways to locate the bootstrap peer, which makes sense to me as well. I hope this either helps or first does no harm :-) And I don't think this change needs to be made before Monday. Thanks, Spencer > logical vs. physical role. I guess my 2 cents is that anything that > serves as a bootstrap server can be one (could also happen to be a > peer). Being a bootstrap server is a logical role that can be > co-located with a peer/node. > > On 10/18/06, Philip Matthews wrote: >> Copying the list on this one too. >> - Philip >> >> Begin forwarded message: >> >> > From: Philip Matthews >> > Date: October 18, 2006 17:27:33 EDT (CA) >> > To: Dean Willis , Eunsoo Shim >> > , "David A. Bryan" >> > Subject: Concepts draft: Bootstrap server vs. bootstrap peer >> > >> > Right now, the Concepts draft lists "bootstrap peer" as an alias >> > for "bootstrap server". >> > >> > I think these two terms are quite distinct. >> > >> > As I see it, a bootstrap server is a node (usually not a peer) in >> > the Internet that allows >> > a node to find peers that are already in the overlay. This is often >> > called a "Rendezvous >> > Server" in the literature. >> > >> > By contrast, a "bootstrap peer" is a peer in the overlay that >> > registers with the bootstrap >> > server. This peer serves as the initial point of contact into the >> > overlay for the new peer >> > that is trying to join. >> > >> > In my view, the peers in the overlay elect one or more of their >> > number to act as bootstrap >> > peers. These bootstrap peers register with (one or more) bootstrap >> > servers. When a new >> > peer wants to join the overlay, it contacts the bootstrap servers >> > that it knows about (using >> > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted >> > a bootstrap peer, >> > the new peer does not need the services of the bootstrap server any >> > more. >> > >> > I am planning to write this up as a draft shortly. >> > >> > In the meantime, I am proposing to: >> > >> > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and >> > 2) Introduce "bootstrap peer" as a distinct term. >> > >> > If people find (2) to be too controversial, then I can stick with >> > just (1) >> > (until I write my draft ;-). >> > >> > Comments? >> > >> > - Philip From petithug at acm.org Wed Oct 18 18:18:18 2006 From: petithug at acm.org (Marc Petit-Huguenin) Date: Wed, 18 Oct 2006 15:18:18 -0700 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> <45368DAF.6020508@acm.org> <8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> Message-ID: <4536A82A.1050705@acm.org> Ed Pimentel wrote: > This is a case when "perfect" is not good enough. > We all recall the failure of X.400/500 and a more pragmatic/workable > solution LDAP has provided > Or the failure of OSI - NMS and how SNMP came to the rescue. > > What we need now is a SSIP a SIMPLE Session Initiation Protocol that > simply just works and does not try to replicate the CLASS5 Services but > in turns > innovates with what I call CLASS 6 Services.... Excepted that the IETF work is "above the wire and below the application." I think that the proposal of Henry and the other authors, to do not define another SIP but just define the subset of SIP to use, is the way to go. Let's the implementors do not have to juggle with 100+ RFCs and I-Ds and let them design the services that the PSTN/IMS will be jealous of. Well, this said, I would be happy if the B2BUA definition can be removed from RFC 3261. And all the SHOULD rewritten to MUST. And adding a sentence that makes fun of SBC. But I am a reasonable person. > Where as CLASS 5 services schackled you to the black 2500 ma-bell phone.... > Class 6 cuts the unbilical chords and innovates by providing beyond > voip services that are not necessarily to the PSTN/SS7/IN/SCP network. > > -E > > On Oct 18, 2006, at 4:25 PM, Marc Petit-Huguenin wrote: > >> Hi Henry, >> >> I like your I-D a lot. I think that it is time for SIP to go back to a >> strong support of the end-to-end principle, and to clearly indicate to >> implementors what part of SIP is SIP, and what part is for supporting >> legacy systems (PSTN, IMS, etc...). >> >> This remind me of what was done ten years ago for movies, when >> independent filmmakers defined Dogma 95[1] as a set of rules to purify >> movie making. I see a lot of parallels, so I am proposing the name >> "Dogma 06" for this effort to purify SIP. >> >> Thanks. >> >> >> [1] http://en.wikipedia.org/wiki/Dogma_95 >> >> Henry Sinnreich wrote: >>> The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS >>> Systems" has been posted by the IETF: >>> >>> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt >>> >>> The I-D is also available at p2psip.org >>> >>> The number of SIP related standards can be significantly >>> reduced for various application scenarios by (1) using SIP >>> without "network based services" and (2) without emulating the >>> telephone network. >>> >>> Such an approach reduces the number of SIP related standards >>> (as by mid 2006) from roughly 100 to about 11. Core SIP >>> interoperability and SIP compliance can be preserved without >>> relying on complex server based networks. >>> >>> Successful IP communications must also include the relevant >>> standards for NAT traversal, some of which are not directly >>> related to SIP and also several standards for security. These >>> standards are included here as well. >>> >>> Any suggestions and your FRANK opinion would be most welcome. >>> Please use the list. >>> >>> Thanks, Henry >>> -- Marc Petit-Huguenin [ ] Home: marc at petit-huguenin.org [ This RFC1855-compliant space ] Work: marc at 8x8.com [ for rent ] From huang-ming.pan at comcast.net Wed Oct 18 18:23:38 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 15:23:38 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> <4536A4FB.4090809@cs.columbia.edu> <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> Message-ID: <00dc01c6f304$0f64c980$030aa8c0@comcast.net> I vote for the email approach only for initial identity verification by the bootstrap server or CA. I won't, if you're meaning the daily peer-to-peer identity verification. Peter ----- Original Message ----- From: "David A. Bryan" To: "Henning Schulzrinne" Cc: "Peter Pan" ; Sent: Wednesday, October 18, 2006 3:15 PM Subject: Re: [p2p-sip] Comments on concepts-02 > Fully agree that approach could work. We actually proposed using email > based protection just like this as out auth mechanism in the -00 > version of draft-bryan-sipping-p2p, but felt it might not be as secure > as we wanted in all scenarios. > > Technically, as many people pointed out to us, that is still a > "centralized authority" -- in this case the DNS/mail servers. It also > won't work in truly ad-hoc/disconnected scenarios (DNS dependent). The > other problem is who checks the authenticity before admitting a node > (in other words, who prompts by sending email?) You have a bit of a > risk of a malicious node "confirming" that someone is who they say > they are falsely, and the question of how often this check needs to be > performed (each time they start their client and the overlay? If only > once, how do we persist the authentication in the overlay so an email > challenge doesn't have to be resent?) > > Some of the other ideas you mentioned make very good sense too, with > the same (possible) problems, but I still believe this kind of > approach could work and is worth exploring a bit more to see if we > tighten up the holes. > > David > > On 10/18/06, Henning Schulzrinne wrote: > > I think there's a middle ground, namely where one leverages existing > > structures to assert identity uniqueness. In practical terms: it is > > fairly straightforward for a node to ascertain whether somebody new is > > indeed the owner of an email address - just send a message to that > > address and see if the destination agrees. This doesn't really require a > > "centralized server" as such, but does require leveraging some other > > infrastructure and mechanisms of identity generation. There are numerous > > variations on this concept: > > > > - Prove ownership of a bank account by reporting on small deposits made; > > > > - Prove ownership of a DNS domain by adding or modifying a host entry in > > the domain > > > > - Prove ownership of a phone number by getting a call and entering number > > > > - Prove ownership of an IP address by responding to a nonce or random > > identifier sent (e.g., a variation in TCP) > > > > I think that in many practical cases, leveraging such identities will be > > the lowest-cost way to avoiding collisions, both intentional and otherwise. > > > > Henning > > > > David A. Bryan wrote: > > >> In such a try-and-error environment full of uninsured attempts, very often > > >> you just want to make sure that the peer you're talking to is indeed > > >> belonging to the network and is helpful; you don't care which of John or > > >> Mary the peer is. > > > > > > If the different John's are just different UAs all associated with the > > > same user (human), probably true, but if you mean I try call John > > > Smith and reach John Doe (different human), that scenario seems pretty > > > useless. > > > > > > I think just proving you are part of the overlay isn't really that > > > useful, if people can clobber user names. Even if everyone is well > > > behaved, it wouldn't even have to be malicious -- could just be that > > > two people with the same name, intending to play by the rules, both > > > log on (say at different times, not realizing there is a collision) > > > and may not even realize they are confusing folks who are trying to > > > call them and getting different people. > > > > > > It is really hard to assert identity (as opposed to ensuring it was > > > the same person you talked to last time, which is easier) in the > > > absence of some sort of centralized server. Not everyone can be > > > lonelygirl15. > > > > > > --David > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From hgs at cs.columbia.edu Wed Oct 18 18:23:22 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Wed, 18 Oct 2006 18:23:22 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> <4536A4FB.4090809@cs.columbia.edu> <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> Message-ID: <4536A95A.2070104@cs.columbia.edu> David A. Bryan wrote: > Fully agree that approach could work. We actually proposed using email > based protection just like this as out auth mechanism in the -00 > version of draft-bryan-sipping-p2p, but felt it might not be as secure > as we wanted in all scenarios. > > Technically, as many people pointed out to us, that is still a > "centralized authority" -- in this case the DNS/mail servers. It also Not really centralized - there are millions of them. It would be centralized if all users for one P2P cloud would have to use a single server. > won't work in truly ad-hoc/disconnected scenarios (DNS dependent). The I don't see how anything except random (public key) identities and ensuring uniqueness is workable in a disconnected environment. > other problem is who checks the authenticity before admitting a node > (in other words, who prompts by sending email?) You have a bit of a > risk of a malicious node "confirming" that someone is who they say > they are falsely, and the question of how often this check needs to be > performed (each time they start their client and the overlay? If only > once, how do we persist the authentication in the overlay so an email > challenge doesn't have to be resent?) This problem isn't solved with certs, either, as a malicious node can simply pretend that someone presented a valid cert. > > Some of the other ideas you mentioned make very good sense too, with > the same (possible) problems, but I still believe this kind of > approach could work and is worth exploring a bit more to see if we > tighten up the holes. This is not ironclad, but I believe this provides sufficient real-world security for most usages. From huang-ming.pan at comcast.net Wed Oct 18 18:33:29 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 15:33:29 -0700 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com><45368DAF.6020508@acm.org><8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> <4536A82A.1050705@acm.org> Message-ID: <00ec01c6f305$6fae5580$030aa8c0@comcast.net> > Well, this said, I would be happy if the B2BUA definition can be removed > from RFC 3261. And all the SHOULD rewritten to MUST. And adding a > sentence that makes fun of SBC. > B2BUA is for those who are incapable of taking on a feature-enriched service through light-weight approaches (eg. by means of a transaction-stateful proxy seasoned with just a little dialog-statefulness). If I may add, the sentence to make fun of SBC is "SBC is redundant and made only by those who cannot find position either on CPE or on Softswitch market." Even the regulated Lawful Interception by 2007 can be without SBC. From bryan at ethernot.org Wed Oct 18 18:32:20 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 18:32:20 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> Message-ID: <8b2769930610181532i75b474beqf1b374bc96871344@mail.gmail.com> Seems how this would work would likely a deployment issue for the person building the system. In the model you are proposing the bootstrap server is a server that is not part of any one overlay, and keeps info for multiple overlay, and the bootstrap peers in your model register with it? What protocol is used for that registration? I'm a bit worried that is another protocol (and really more of a config problem) creeping in here, but I might just be missing your point. In any case, based on the scenario you mention/your definition these are clearly two different and distinct things -- not just the logical role I was picturing in my head. In the scenario I think you are proposing, however, I think we leave what you are calling the bootstrap server out of the draft for now. That would be one of many (along with using broadcast, DNS lookup for "boot.example.com", preconfiguration etc.) ways to find a bootstrap peer to get going, which would be deployment dependent. --David On 10/18/06, Philip Matthews wrote: > Sure. > A bootstrap server can be a bootstrap peer as well, > or even just a peer and not a bootstrap peer (though this one is a > bit weird!). > > However, in the typical deployment, I strongly suspect that bootstrap > servers > will be distinct from bootstrap peers. > As I see it, there will be lots and lots of distinct overlays, > each of which elects one or more bootstrap peers to register with a > fairly > small number of bootstrap servers. > > - Philip > > On 18-Oct-06, at 17:58 , David A. Bryan wrote: > > > logical vs. physical role. I guess my 2 cents is that anything that > > serves as a bootstrap server can be one (could also happen to be a > > peer). Being a bootstrap server is a logical role that can be > > co-located with a peer/node. > > > > On 10/18/06, Philip Matthews wrote: > >> Copying the list on this one too. > >> - Philip > >> > >> Begin forwarded message: > >> > >> > From: Philip Matthews > >> > Date: October 18, 2006 17:27:33 EDT (CA) > >> > To: Dean Willis , Eunsoo Shim > >> > , "David A. Bryan" > >> > >> > Subject: Concepts draft: Bootstrap server vs. bootstrap peer > >> > > >> > Right now, the Concepts draft lists "bootstrap peer" as an alias > >> > for "bootstrap server". > >> > > >> > I think these two terms are quite distinct. > >> > > >> > As I see it, a bootstrap server is a node (usually not a peer) in > >> > the Internet that allows > >> > a node to find peers that are already in the overlay. This is often > >> > called a "Rendezvous > >> > Server" in the literature. > >> > > >> > By contrast, a "bootstrap peer" is a peer in the overlay that > >> > registers with the bootstrap > >> > server. This peer serves as the initial point of contact into the > >> > overlay for the new peer > >> > that is trying to join. > >> > > >> > In my view, the peers in the overlay elect one or more of their > >> > number to act as bootstrap > >> > peers. These bootstrap peers register with (one or more) bootstrap > >> > servers. When a new > >> > peer wants to join the overlay, it contacts the bootstrap servers > >> > that it knows about (using > >> > RFC 3263 methods) to locate a bootstrap peer. Once it has contacted > >> > a bootstrap peer, > >> > the new peer does not need the services of the bootstrap server any > >> > more. > >> > > >> > I am planning to write this up as a draft shortly. > >> > > >> > In the meantime, I am proposing to: > >> > > >> > 1) Remove "bootstrap peer" as an alias for "bootstrap server", and > >> > 2) Introduce "bootstrap peer" as a distinct term. > >> > > >> > If people find (2) to be too controversial, then I can stick with > >> > just (1) > >> > (until I write my draft ;-). > >> > > >> > Comments? > >> > > >> > - Philip > >> > > >> > >> _______________________________________________ > >> p2p-sip mailing list > >> p2p-sip at cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From edpimentl at gmail.com Wed Oct 18 18:36:08 2006 From: edpimentl at gmail.com (Ed Pimentel) Date: Wed, 18 Oct 2006 18:36:08 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <00dc01c6f304$0f64c980$030aa8c0@comcast.net> References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> <4536A4FB.4090809@cs.columbia.edu> <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> <00dc01c6f304$0f64c980$030aa8c0@comcast.net> Message-ID: CA is fine and HIP (Host Identity Protocol) is better and more suitable for P2P and SIP; and or IBE Identity Based Encryption. -Edpimentl On Oct 18, 2006, at 6:23 PM, Peter Pan wrote: > I vote for the email approach only for initial identity > verification by the > bootstrap server or CA. > > I won't, if you're meaning the daily peer-to-peer identity > verification. > > Peter > ----- Original Message ----- > From: "David A. Bryan" > To: "Henning Schulzrinne" > Cc: "Peter Pan" ; sip at cs.columbia.edu> > Sent: Wednesday, October 18, 2006 3:15 PM > Subject: Re: [p2p-sip] Comments on concepts-02 > > >> Fully agree that approach could work. We actually proposed using >> email >> based protection just like this as out auth mechanism in the -00 >> version of draft-bryan-sipping-p2p, but felt it might not be as >> secure >> as we wanted in all scenarios. >> >> Technically, as many people pointed out to us, that is still a >> "centralized authority" -- in this case the DNS/mail servers. It also >> won't work in truly ad-hoc/disconnected scenarios (DNS dependent). >> The >> other problem is who checks the authenticity before admitting a node >> (in other words, who prompts by sending email?) You have a bit of a >> risk of a malicious node "confirming" that someone is who they say >> they are falsely, and the question of how often this check needs >> to be >> performed (each time they start their client and the overlay? If only >> once, how do we persist the authentication in the overlay so an email >> challenge doesn't have to be resent?) >> >> Some of the other ideas you mentioned make very good sense too, with >> the same (possible) problems, but I still believe this kind of >> approach could work and is worth exploring a bit more to see if we >> tighten up the holes. >> >> David >> >> On 10/18/06, Henning Schulzrinne wrote: >>> I think there's a middle ground, namely where one leverages existing >>> structures to assert identity uniqueness. In practical terms: it is >>> fairly straightforward for a node to ascertain whether somebody >>> new is >>> indeed the owner of an email address - just send a message to that >>> address and see if the destination agrees. This doesn't really >>> require a >>> "centralized server" as such, but does require leveraging some other >>> infrastructure and mechanisms of identity generation. There are >>> numerous >>> variations on this concept: >>> >>> - Prove ownership of a bank account by reporting on small >>> deposits made; >>> >>> - Prove ownership of a DNS domain by adding or modifying a host >>> entry in >>> the domain >>> >>> - Prove ownership of a phone number by getting a call and entering > number >>> >>> - Prove ownership of an IP address by responding to a nonce or >>> random >>> identifier sent (e.g., a variation in TCP) >>> >>> I think that in many practical cases, leveraging such identities >>> will be >>> the lowest-cost way to avoiding collisions, both intentional and > otherwise. >>> >>> Henning >>> >>> David A. Bryan wrote: >>>>> In such a try-and-error environment full of uninsured attempts, >>>>> very > often >>>>> you just want to make sure that the peer you're talking to is >>>>> indeed >>>>> belonging to the network and is helpful; you don't care which >>>>> of John > or >>>>> Mary the peer is. >>>> >>>> If the different John's are just different UAs all associated >>>> with the >>>> same user (human), probably true, but if you mean I try call John >>>> Smith and reach John Doe (different human), that scenario seems >>>> pretty >>>> useless. >>>> >>>> I think just proving you are part of the overlay isn't really that >>>> useful, if people can clobber user names. Even if everyone is well >>>> behaved, it wouldn't even have to be malicious -- could just be >>>> that >>>> two people with the same name, intending to play by the rules, both >>>> log on (say at different times, not realizing there is a collision) >>>> and may not even realize they are confusing folks who are trying to >>>> call them and getting different people. >>>> >>>> It is really hard to assert identity (as opposed to ensuring it was >>>> the same person you talked to last time, which is easier) in the >>>> absence of some sort of centralized server. Not everyone can be >>>> lonelygirl15. >>>> >>>> --David >>>> _______________________________________________ >>>> p2p-sip mailing list >>>> p2p-sip at cs.columbia.edu >>>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Wed Oct 18 18:45:10 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 18 Oct 2006 15:45:10 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> <8b2769930610181454i48f6a836vc344f0d2a75309c@mail.gmail.com> <4536A4FB.4090809@cs.columbia.edu> <8b2769930610181515r16c09585v80a1336aaa005425@mail.gmail.com> <00dc01c6f304$0f64c980$030aa8c0@comcast.net> Message-ID: <010b01c6f307$11df5f10$030aa8c0@comcast.net> Seemingly, we discussed HIP approach before and concluded it to be not working at least "commercially". To be compatible or interoperate with existing service networks, sometimes (way of generating) identity is predetermined, for example, Local Number Portability or One Consolidation (phone) Number. You cannot generate these "randomly". Peter ----- Original Message ----- From: "Ed Pimentel" To: "Peter Pan" Cc: "David A. Bryan" ; "Henning Schulzrinne" ; Sent: Wednesday, October 18, 2006 3:36 PM Subject: Re: [p2p-sip] Comments on concepts-02 > CA is fine and HIP (Host Identity Protocol) is better and more > suitable for P2P and SIP; and or IBE Identity Based Encryption. > -Edpimentl > > On Oct 18, 2006, at 6:23 PM, Peter Pan wrote: > > > I vote for the email approach only for initial identity > > verification by the > > bootstrap server or CA. > > > > I won't, if you're meaning the daily peer-to-peer identity > > verification. > > > > Peter > > ----- Original Message ----- > > From: "David A. Bryan" > > To: "Henning Schulzrinne" > > Cc: "Peter Pan" ; > sip at cs.columbia.edu> > > Sent: Wednesday, October 18, 2006 3:15 PM > > Subject: Re: [p2p-sip] Comments on concepts-02 > > > > > >> Fully agree that approach could work. We actually proposed using > >> email > >> based protection just like this as out auth mechanism in the -00 > >> version of draft-bryan-sipping-p2p, but felt it might not be as > >> secure > >> as we wanted in all scenarios. > >> > >> Technically, as many people pointed out to us, that is still a > >> "centralized authority" -- in this case the DNS/mail servers. It also > >> won't work in truly ad-hoc/disconnected scenarios (DNS dependent). > >> The > >> other problem is who checks the authenticity before admitting a node > >> (in other words, who prompts by sending email?) You have a bit of a > >> risk of a malicious node "confirming" that someone is who they say > >> they are falsely, and the question of how often this check needs > >> to be > >> performed (each time they start their client and the overlay? If only > >> once, how do we persist the authentication in the overlay so an email > >> challenge doesn't have to be resent?) > >> > >> Some of the other ideas you mentioned make very good sense too, with > >> the same (possible) problems, but I still believe this kind of > >> approach could work and is worth exploring a bit more to see if we > >> tighten up the holes. > >> > >> David > >> > >> On 10/18/06, Henning Schulzrinne wrote: > >>> I think there's a middle ground, namely where one leverages existing > >>> structures to assert identity uniqueness. In practical terms: it is > >>> fairly straightforward for a node to ascertain whether somebody > >>> new is > >>> indeed the owner of an email address - just send a message to that > >>> address and see if the destination agrees. This doesn't really > >>> require a > >>> "centralized server" as such, but does require leveraging some other > >>> infrastructure and mechanisms of identity generation. There are > >>> numerous > >>> variations on this concept: > >>> > >>> - Prove ownership of a bank account by reporting on small > >>> deposits made; > >>> > >>> - Prove ownership of a DNS domain by adding or modifying a host > >>> entry in > >>> the domain > >>> > >>> - Prove ownership of a phone number by getting a call and entering > > number > >>> > >>> - Prove ownership of an IP address by responding to a nonce or > >>> random > >>> identifier sent (e.g., a variation in TCP) > >>> > >>> I think that in many practical cases, leveraging such identities > >>> will be > >>> the lowest-cost way to avoiding collisions, both intentional and > > otherwise. > >>> > >>> Henning > >>> > >>> David A. Bryan wrote: > >>>>> In such a try-and-error environment full of uninsured attempts, > >>>>> very > > often > >>>>> you just want to make sure that the peer you're talking to is > >>>>> indeed > >>>>> belonging to the network and is helpful; you don't care which > >>>>> of John > > or > >>>>> Mary the peer is. > >>>> > >>>> If the different John's are just different UAs all associated > >>>> with the > >>>> same user (human), probably true, but if you mean I try call John > >>>> Smith and reach John Doe (different human), that scenario seems > >>>> pretty > >>>> useless. > >>>> > >>>> I think just proving you are part of the overlay isn't really that > >>>> useful, if people can clobber user names. Even if everyone is well > >>>> behaved, it wouldn't even have to be malicious -- could just be > >>>> that > >>>> two people with the same name, intending to play by the rules, both > >>>> log on (say at different times, not realizing there is a collision) > >>>> and may not even realize they are confusing folks who are trying to > >>>> call them and getting different people. > >>>> > >>>> It is really hard to assert identity (as opposed to ensuring it was > >>>> the same person you talked to last time, which is easier) in the > >>>> absence of some sort of centralized server. Not everyone can be > >>>> lonelygirl15. > >>>> > >>>> --David > >>>> _______________________________________________ > >>>> p2p-sip mailing list > >>>> p2p-sip at cs.columbia.edu > >>>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >>> > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Wed Oct 18 22:19:07 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 18 Oct 2006 22:19:07 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: References: Message-ID: <4536E09B.2030708@research.panasonic.com> I agree to the distinction Philip made. A minor comment - saying the overlay ELECT one or more peers as bootstrap server is not general enough. Actually I am not sure whethere any kind of electing/election is necessary for a bootstrap server to know peers in the overlay. There can be many ways for a bootstrap server to know existing peers, for example, by configuration or through any known peer. So it should be sufficient to say that a bootstrap server provides information about one or multiple existing peers to a joining peer if requested. Any peer somehow known to the bootstrap server becomes a bootstrap peer. Thanks. Eunsoo Philip Matthews wrote: >Copying the list on this one too. >- Philip > >Begin forwarded message: > > > >>From: Philip Matthews >>Date: October 18, 2006 17:27:33 EDT (CA) >>To: Dean Willis , Eunsoo Shim >>, "David A. Bryan" >>Subject: Concepts draft: Bootstrap server vs. bootstrap peer >> >>Right now, the Concepts draft lists "bootstrap peer" as an alias >>for "bootstrap server". >> >>I think these two terms are quite distinct. >> >>As I see it, a bootstrap server is a node (usually not a peer) in >>the Internet that allows >>a node to find peers that are already in the overlay. This is often >>called a "Rendezvous >>Server" in the literature. >> >>By contrast, a "bootstrap peer" is a peer in the overlay that >>registers with the bootstrap >>server. This peer serves as the initial point of contact into the >>overlay for the new peer >>that is trying to join. >> >>In my view, the peers in the overlay elect one or more of their >>number to act as bootstrap >>peers. These bootstrap peers register with (one or more) bootstrap >>servers. When a new >>peer wants to join the overlay, it contacts the bootstrap servers >>that it knows about (using >>RFC 3263 methods) to locate a bootstrap peer. Once it has contacted >>a bootstrap peer, >>the new peer does not need the services of the bootstrap server any >>more. >> >>I am planning to write this up as a draft shortly. >> >>In the meantime, I am proposing to: >> >>1) Remove "bootstrap peer" as an alias for "bootstrap server", and >>2) Introduce "bootstrap peer" as a distinct term. >> >>If people find (2) to be too controversial, then I can stick with >>just (1) >>(until I write my draft ;-). >> >>Comments? >> >>- Philip >> >> >> > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From bryan at ethernot.org Wed Oct 18 22:39:46 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 18 Oct 2006 22:39:46 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <4536E09B.2030708@research.panasonic.com> References: <4536E09B.2030708@research.panasonic.com> Message-ID: <8b2769930610181939u6632f665u6e7adb3f4e8c0935@mail.gmail.com> Definitely agree with Eunsoo here. A biz deploying something like this might actually set up a few of these peers actively rather than election. David On 10/18/06, Eunsoo Shim wrote: > I agree to the distinction Philip made. > > A minor comment - saying the overlay ELECT one or more peers as > bootstrap server is not general enough. Actually I am not sure whethere > any kind of electing/election is necessary for a bootstrap server to > know peers in the overlay. There can be many ways for a bootstrap server > to know existing peers, for example, by configuration or through any > known peer. > So it should be sufficient to say that a bootstrap server provides > information about one or multiple existing peers to a joining peer if > requested. > Any peer somehow known to the bootstrap server becomes a bootstrap peer. > > Thanks. > > Eunsoo > > Philip Matthews wrote: > > >Copying the list on this one too. > >- Philip > > > >Begin forwarded message: > > > > > > > >>From: Philip Matthews > >>Date: October 18, 2006 17:27:33 EDT (CA) > >>To: Dean Willis , Eunsoo Shim > >>, "David A. Bryan" > >>Subject: Concepts draft: Bootstrap server vs. bootstrap peer > >> > >>Right now, the Concepts draft lists "bootstrap peer" as an alias > >>for "bootstrap server". > >> > >>I think these two terms are quite distinct. > >> > >>As I see it, a bootstrap server is a node (usually not a peer) in > >>the Internet that allows > >>a node to find peers that are already in the overlay. This is often > >>called a "Rendezvous > >>Server" in the literature. > >> > >>By contrast, a "bootstrap peer" is a peer in the overlay that > >>registers with the bootstrap > >>server. This peer serves as the initial point of contact into the > >>overlay for the new peer > >>that is trying to join. > >> > >>In my view, the peers in the overlay elect one or more of their > >>number to act as bootstrap > >>peers. These bootstrap peers register with (one or more) bootstrap > >>servers. When a new > >>peer wants to join the overlay, it contacts the bootstrap servers > >>that it knows about (using > >>RFC 3263 methods) to locate a bootstrap peer. Once it has contacted > >>a bootstrap peer, > >>the new peer does not need the services of the bootstrap server any > >>more. > >> > >>I am planning to write this up as a draft shortly. > >> > >>In the meantime, I am proposing to: > >> > >>1) Remove "bootstrap peer" as an alias for "bootstrap server", and > >>2) Introduce "bootstrap peer" as a distinct term. > >> > >>If people find (2) to be too controversial, then I can stick with > >>just (1) > >>(until I write my draft ;-). > >> > >>Comments? > >> > >>- Philip > >> > >> > >> > > > >_______________________________________________ > >p2p-sip mailing list > >p2p-sip at cs.columbia.edu > >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Wed Oct 18 23:48:04 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 18 Oct 2006 23:48:04 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <4536E09B.2030708@research.panasonic.com> References: <4536E09B.2030708@research.panasonic.com> Message-ID: <4536F574.7090708@research.panasonic.com> A correction in my message below. 'saying the overlay ELECT one or more peers as bootstrap server is not ...' should be changed into 'saying the overlay ELECT one or more peers as bootstrap peers is not...'. Sorry about it. Eunsoo Eunsoo Shim wrote: >I agree to the distinction Philip made. > >A minor comment - saying the overlay ELECT one or more peers as >bootstrap server is not general enough. Actually I am not sure whethere >any kind of electing/election is necessary for a bootstrap server to >know peers in the overlay. There can be many ways for a bootstrap server >to know existing peers, for example, by configuration or through any >known peer. >So it should be sufficient to say that a bootstrap server provides >information about one or multiple existing peers to a joining peer if >requested. >Any peer somehow known to the bootstrap server becomes a bootstrap peer. > >Thanks. > >Eunsoo > >Philip Matthews wrote: > > > >>Copying the list on this one too. >>- Philip >> >>Begin forwarded message: >> >> >> >> >> >>>From: Philip Matthews >>>Date: October 18, 2006 17:27:33 EDT (CA) >>>To: Dean Willis , Eunsoo Shim >>>, "David A. Bryan" >>>Subject: Concepts draft: Bootstrap server vs. bootstrap peer >>> >>>Right now, the Concepts draft lists "bootstrap peer" as an alias >>>for "bootstrap server". >>> >>>I think these two terms are quite distinct. >>> >>>As I see it, a bootstrap server is a node (usually not a peer) in >>>the Internet that allows >>>a node to find peers that are already in the overlay. This is often >>>called a "Rendezvous >>>Server" in the literature. >>> >>>By contrast, a "bootstrap peer" is a peer in the overlay that >>>registers with the bootstrap >>>server. This peer serves as the initial point of contact into the >>>overlay for the new peer >>>that is trying to join. >>> >>>In my view, the peers in the overlay elect one or more of their >>>number to act as bootstrap >>>peers. These bootstrap peers register with (one or more) bootstrap >>>servers. When a new >>>peer wants to join the overlay, it contacts the bootstrap servers >>>that it knows about (using >>>RFC 3263 methods) to locate a bootstrap peer. Once it has contacted >>>a bootstrap peer, >>>the new peer does not need the services of the bootstrap server any >>>more. >>> >>>I am planning to write this up as a draft shortly. >>> >>>In the meantime, I am proposing to: >>> >>>1) Remove "bootstrap peer" as an alias for "bootstrap server", and >>>2) Introduce "bootstrap peer" as a distinct term. >>> >>>If people find (2) to be too controversial, then I can stick with >>>just (1) >>>(until I write my draft ;-). >>> >>>Comments? >>> >>>- Philip >>> >>> >>> >>> >>> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> >> > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From dean.willis at softarmor.com Thu Oct 19 00:02:48 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 18 Oct 2006 23:02:48 -0500 Subject: [p2p-sip] The terms I want to save... In-Reply-To: References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> Message-ID: On Oct 18, 2006, at 4:39 PM, Philip Matthews wrote: > Copying the list, since we really should have this discussion in > public. > > On 18-Oct-06, at 16:58 , David A. Bryan wrote: > >> Assuming we cut all the short versions (be prepared for folks to >> still >> use them...I'm not going to have the word "P2PSIP" in front of every >> time I say peer or overlay in all my drafts), I really care about >> (some of which I noticed aren't there now): > I am proposing to blow away all these "P2PSIP" prefixes. > See separate e-mail. I really hope you don't. If you do, just take my name off the draft please. -- Dean From dean.willis at softarmor.com Thu Oct 19 00:10:28 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 18 Oct 2006 23:10:28 -0500 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> Message-ID: On Oct 18, 2006, at 2:42 PM, Philip Matthews wrote: >> >> 4) Need to reconcile two instances of user record definition. Both >> definitions have useful content, and I don't want to lose the "stored >> route" text. > > On yesterday's call, I read the consensus as being to remove the > second > definition, because the first definition subsumed it. So right now, > this is > what I am planning to do. > > I don't see this as a big loss, because "stored route" is just one > more piece > of data about a user, and we don't have document that describes > what this > might really look like yet. > > I do see it as a major loss, because the "stored route" is the most important piece of data to have about a user. Without it, we have absolutely no means of ever contacting them. -- dean From philip_matthews at magma.ca Thu Oct 19 08:18:54 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 19 Oct 2006 08:18:54 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <4536F574.7090708@research.panasonic.com> References: <4536E09B.2030708@research.panasonic.com> <4536F574.7090708@research.panasonic.com> Message-ID: <4FE11FAC-A703-4B3E-B099-96E9F2C1890A@magma.ca> Hi Eunsoo: You make some good points. I agree that bootstrap servers may know about bootstrap peers via mechanisms other than registration (e.g., configuration). I also agree that bootstrap peers may be chosen by mechanisms other than election. - Philip On 18-Oct-06, at 23:48 , Eunsoo Shim wrote: > A correction in my message below. > > 'saying the overlay ELECT one or more peers as bootstrap server is > not ...' > should be changed into > 'saying the overlay ELECT one or more peers as bootstrap peers is > not...'. > > Sorry about it. > > Eunsoo > > Eunsoo Shim wrote: > >> I agree to the distinction Philip made. >> >> A minor comment - saying the overlay ELECT one or more peers as >> bootstrap server is not general enough. Actually I am not sure >> whethere >> any kind of electing/election is necessary for a bootstrap server to >> know peers in the overlay. There can be many ways for a bootstrap >> server >> to know existing peers, for example, by configuration or through any >> known peer. >> So it should be sufficient to say that a bootstrap server provides >> information about one or multiple existing peers to a joining peer if >> requested. >> Any peer somehow known to the bootstrap server becomes a bootstrap >> peer. >> >> Thanks. >> >> Eunsoo >> >> Philip Matthews wrote: >> >> >> >>> Copying the list on this one too. >>> - Philip >>> >>> Begin forwarded message: >>> >>> >>> >>> >>> >>>> From: Philip Matthews >>>> Date: October 18, 2006 17:27:33 EDT (CA) >>>> To: Dean Willis , Eunsoo Shim >>>> , "David A. Bryan" >>>> >>>> Subject: Concepts draft: Bootstrap server vs. bootstrap peer >>>> >>>> Right now, the Concepts draft lists "bootstrap peer" as an alias >>>> for "bootstrap server". >>>> >>>> I think these two terms are quite distinct. >>>> >>>> As I see it, a bootstrap server is a node (usually not a peer) in >>>> the Internet that allows >>>> a node to find peers that are already in the overlay. This is often >>>> called a "Rendezvous >>>> Server" in the literature. >>>> >>>> By contrast, a "bootstrap peer" is a peer in the overlay that >>>> registers with the bootstrap >>>> server. This peer serves as the initial point of contact into the >>>> overlay for the new peer >>>> that is trying to join. >>>> >>>> In my view, the peers in the overlay elect one or more of their >>>> number to act as bootstrap >>>> peers. These bootstrap peers register with (one or more) bootstrap >>>> servers. When a new >>>> peer wants to join the overlay, it contacts the bootstrap servers >>>> that it knows about (using >>>> RFC 3263 methods) to locate a bootstrap peer. Once it has contacted >>>> a bootstrap peer, >>>> the new peer does not need the services of the bootstrap server any >>>> more. >>>> >>>> I am planning to write this up as a draft shortly. >>>> >>>> In the meantime, I am proposing to: >>>> >>>> 1) Remove "bootstrap peer" as an alias for "bootstrap server", and >>>> 2) Introduce "bootstrap peer" as a distinct term. >>>> >>>> If people find (2) to be too controversial, then I can stick with >>>> just (1) >>>> (until I write my draft ;-). >>>> >>>> Comments? >>>> >>>> - Philip >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> p2p-sip mailing list >>> p2p-sip at cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> >>> >>> >>> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> > From philip_matthews at magma.ca Thu Oct 19 09:15:57 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 19 Oct 2006 09:15:57 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> Message-ID: <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> Below is my proposed text for bootstrap server and bootstrap peer. For now, I have kept the term "bootstrap" (rather than changing to "rendezvous" as Spencer suggested) because it seems easier to agree on definitions first, then choose names. P2PSIP Bootstrap Peer: A P2PSIP Peer in the P2PSIP Overlay which is willing to help new Peers join the Overlay or help new Clients find Peers to associate with. A node that wishes to become a Peer or Client contacts a P2PSIP Bootstrap Peer and, with the help this Bootstrap Peer, gets the information it requires to become a fully functioning Peer or Client (the details of this process is still TBD). The new Peer or Client may locate a P2PSIP Peer through multicast, though a P2PSIP Bootstrap Server, or through other means. P2PSIP Bootstrap Server: A network node used by other nodes which are attempting to contact a P2PSIP Bootstrap Peer. It may return the address of a P2PSIP Bootstrap Peer, or act as a proxy to relay messages to and from the Bootstrap Peer, or act as a Bootstrap Peer itself, The P2PSIP Bootstrap Peer itself should be a fairly stable and well-known host. To be useful, there must be an easy way to other nodes to locate it -- one way this might happen is for it to have a well-known DNS entry. A P2PSIP Bootstrap Server may or may not also be a P2PSIP Peer or P2PSIP Client in one or more P2PSIP Overlays. - Philip From spencer at mcsr-labs.org Thu Oct 19 09:47:29 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 19 Oct 2006 08:47:29 -0500 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> Message-ID: <025701c6f385$21b444e0$0300a8c0@china.huawei.com> > Below is my proposed text for bootstrap server and bootstrap peer. > For now, I have kept the term "bootstrap" (rather than changing to > "rendezvous" > as Spencer suggested) > because it seems easier to agree on definitions first, then choose names. FWIW, I agree with Philip here. We're all supposed to be reading the definitions, at this point in the game. Thanks, Spencer From enrico.marocco at telecomitalia.it Thu Oct 19 09:56:49 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 19 Oct 2006 15:56:49 +0200 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> Message-ID: <45378421.9070703@telecomitalia.it> Philip Matthews wrote: > P2PSIP Bootstrap Peer: > A P2PSIP Peer in the P2PSIP Overlay which is willing > to help new Peers join the Overlay or help new Clients > find Peers to associate with. > A node that wishes to become a Peer or Client contacts a > P2PSIP Bootstrap Peer and, > with the help this Bootstrap Peer, gets the information it > requires to become a fully > functioning Peer or Client (the details of this process is > still TBD). > The new Peer or Client may locate a P2PSIP Peer through > multicast, though a P2PSIP Bootstrap > Server, or through other means. The new Peer needs to locate a P2PSIP Bootstrap Peer, not a P2PSIP Peer, no? If so, I'd restate the last sentence like this: "The potential new Peer or Client may locate a P2PSIP Bootstrap Peer through multicast, through DNS or through other means." I'd defenitely drop the definition of "P2PSIP Bootstrap Server"; right now we need to agree on something *simple* and it only seems to be a matter of argument we just don't need at the moment. -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From philip_matthews at magma.ca Thu Oct 19 09:58:47 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 19 Oct 2006 09:58:47 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> Message-ID: <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> On 19-Oct-06, at 00:10 , Dean Willis wrote: > > On Oct 18, 2006, at 2:42 PM, Philip Matthews wrote: > >>> >>> 4) Need to reconcile two instances of user record definition. Both >>> definitions have useful content, and I don't want to lose the >>> "stored >>> route" text. >> >> On yesterday's call, I read the consensus as being to remove the >> second >> definition, because the first definition subsumed it. So right >> now, this is >> what I am planning to do. >> >> I don't see this as a big loss, because "stored route" is just one >> more piece >> of data about a user, and we don't have document that describes >> what this >> might really look like yet. >> >> > > I do see it as a major loss, because the "stored route" is the most > important piece of data to have about a user. Without it, we have > absolutely no means of ever contacting them. > How about the following definition for "P2PSIP Resource (User) Record"? This is a slightly modified version of the text of the first definition. Does this satisfy your concern? A block of data, stored using the data mechanism of the P2PSIP Overlay, that includes information relevant to a specific resource. We presume that there may be multiple types of resource records. Some may describe routes to a P2PSIP Peer or Client at which the user or resource is presumed reachable (e.g., a "user routing record" like a SIP "Contact:"). Others might store presence information. The types, usages, and formats of user records are a question for future study. - Philip From zhuxian at huawei.com Thu Oct 19 10:18:29 2006 From: zhuxian at huawei.com (zhuxian) Date: Thu, 19 Oct 2006 22:18:29 +0800 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <009701c6f2ff$265f4d40$030aa8c0@comcast.net> Message-ID: <000001c6f389$730feb10$76244e0a@china.huawei.com> I partly agree with Perter the following : >That is why I think in P2P environment "detailed" or realworld identity (first/last name, >common name, organization...) is less essential than merely ensuring the peer not to be a >malicious peer so that we can correctly fulfill peer-to-peer functionality of a P2P-SIP >network. But in p2p environment, how did you know a peer is not a malicious peer? Without some third-party mechanism, it's very difficult. X.509 is rarely used for server to authenticate clients, because the server usally keep the user's account information, or deploy some IP filter mechanisms. But in the P2P environment, peer may need to authenticate each other and they don't even know before. So we need some distributed authentication mechanism, such as X.509 authentication. Although there are some complex code related to ASN.1 when use the X.509 certificate, but it doesn't mean using X.509 cert is a bad choice. As to the SPKI, it has many function related to authorization, not only related to authentication. The author named it as "simple", because it can provide authorization and authentication service at the same time, and need not to build a infrastructure from bottom-up. And also, the field and s-expression is easy to understand. But i think that is not the main point. And SPKI certificate is also rarely used. Does Skype use a PKI? I used to think it just use a centralized user database. Xian Zhu -----Original Message----- From: Peter Pan [mailto:huang-ming.pan at comcast.net] Send: 10,19, 2006 5:48 To: zhuxian; 'Dean Willis' Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Comments on concepts-02 By "X.509 is rarely seen used with CPEs" I meant that it is rare for server to authenticate clients, not to mention to verify "realworld identity" of the clients. That is why I think in P2P environment "detailed" or realworld identity (first/last name, common name, organization...) is less essential than merely ensuring the peer not to be a malicious peer so that we can correctly fulfill peer-to-peer functionality of a P2P-SIP network. In such a try-and-error environment full of uninsured attempts, very often you just want to make sure that the peer you're talking to is indeed belonging to the network and is helpful; you don't care which of John or Mary the peer is. There is "Simple Public Key Infrastructure" (SPKI). Just don't know whether there is "simple certificate". Duh, I know THERE IS. Skype uses PKI but not X.509 !! My point is just: P2P-SIP seems to me not "so simple" in the long run as you define and implement it for serious commercial competence. Maybe it is time to rid of unnecessary code such like ASN.1. Simplicity or small footprint (of protocol or code) is always a mercy to others as well as to yourself. Maybe this is what was exactly in minds of the two authors of the Touring-Machine awarded PDP-11 UNIX. Peter ----- Original Message ----- From: "Peter Pan" To: "zhuxian" ; "'Dean Willis'" Cc: Sent: Wednesday, October 18, 2006 8:59 AM Subject: Re: [p2p-sip] Comments on concepts-02 > X.509 for P2P-SIP is like butcher knife for tomato. > > Even in known C/S deployments X.509 is rarely seen used with CPEs for > signaling or provisioning. > > Peter > ----- Original Message ----- > From: "zhuxian" > To: "'Dean Willis'" > Cc: > Sent: Wednesday, October 18, 2006 5:55 AM > Subject: Re: [p2p-sip] Comments on concepts-02 > > > > Hi: > > As to the peer and user credentials, I think using certificate > > is a reasonable selection. Because it has already been used in many > > p2p > platform > > design, such as JXTA and microsoft PNRP. And also, it is a > > reasonable distributed authentication mechanism for p2p. If we use > > password, who know > > your password, except the centralized user server. > > A big question is, whether we use a CA or self-signed certificate. I > > think it is related to the security level we want to attain in the > > p2p sip > > world. Just using the self-signed certificate work well in some situation. > > But it can not defend the sybil and eclipse attacking, whick may > > turn the > > p2p sip overlay down in some situation. Use a certificate be signed > > by a > CA > > is Ok. But we need to do more in the p2p sip world. Because > > anonymous-communication is an important character we want to achieve. And > > also the revoke problem in CA is more serious in p2p sip as the > > number of > > user may be huge and user may be dynamic. > > > > As for the overlay that requires initial self-organization under ad-hoc > > network conditions and lacks a centralized source of authority, we > > can not > > get the security level when the overlay is accompany with a CA. Use > > the self-signed ceritficate is ok in these scenarios. But i think > > it's compatible with the CA approach in the peer/client implementation. > > Peer/client can just downgrade the security level in these sitution. > > > > As to the credential format, why don't we use a standard > > credential format, such as X.509? Does the standard credential > > format can't fulfill > the > > credential requirement in p2p sip? > > > > > > Xian Zhu > > > > ----- Original Message ----- > > from : p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] Dean Willis wrote: > > send: Oct 18, 2006 5:05 am > > to: p2p-sip at cs.columbia.edu > > subject: [p2p-sip] Comments on concepts-02 > > > > > > 4.9. Peer and User Credentials > > > > We believe we need some sort of credentials for authenticating peers > > and users of each P2PSIP Overlay. What should we use for these > > credentials? Certificates? PGP keys? Passwords? If certificates, > > should these be signed by a CA associated with the overlay, or can > > self-signed certificates work in some or all cases? Do we need to > > specify a standard credential format, or should we allow different > > implementations to use different credential formats? > > > > Cullen suggested instead something like: > > > > We assume a security model based on the issuance of credentials by > > an authority (presumably centralized) for each P2PSIP Overlay. What > > form of credential should be used? Do we need to specify a standard > > certificate format, or should we allow different implementations to > > use different certificate formats? > > > > Note that the above doesn't actually work in some of the use cases, > > such > as > > the anonymous-communication scenarios or the overlay that requires initial > > self-organization under ad-hoc network conditions and lacks a centralized > > source of authority. Under certain circumstances, it might be > > suitable to > do > > something like generate randomized distinguished names and > > self-signed certificates for those names. How shall we account for > > this in the draft? > > > > -- > > Dean > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From salman at cs.columbia.edu Thu Oct 19 10:28:45 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Thu, 19 Oct 2006 10:28:45 -0400 (EDT) Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> Message-ID: Node and peer definitions. The concept draft considers 'peer' as an entity that participates in the p2p network (routing decisions, storage) and equates 'peer' with a 'node'. The peer typically means 'super node' in the unstructured P2P literature and a 'node' in the DHT literature. A 'node' encompasses both 'peer' and 'client' functionality in some papers and architectures. See for example, "Understanding KaZaA" paper where it is prefixed with 'super'-node and 'ordinary' node. I think it will be helpful to make those distinctions a bit more clear in the concepts draft. Regards, Salman From philip_matthews at magma.ca Thu Oct 19 10:31:03 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 19 Oct 2006 10:31:03 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <45378421.9070703@telecomitalia.it> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> <45378421.9070703@telecomitalia.it> Message-ID: <29B473E5-DB51-4B48-B24D-6EAE02E48B43@magma.ca> On 19-Oct-06, at 09:56 , Enrico Marocco wrote: > Philip Matthews wrote: >> P2PSIP Bootstrap Peer: >> A P2PSIP Peer in the P2PSIP Overlay which is willing >> to help new Peers join the Overlay or help new Clients >> find Peers to associate with. >> A node that wishes to become a Peer or Client contacts a >> P2PSIP Bootstrap Peer and, >> with the help this Bootstrap Peer, gets the information it >> requires to become a fully >> functioning Peer or Client (the details of this process is >> still TBD). >> The new Peer or Client may locate a P2PSIP Peer through >> multicast, though a P2PSIP Bootstrap >> Server, or through other means. > > The new Peer needs to locate a P2PSIP Bootstrap Peer, not a P2PSIP > Peer, > no? If so, I'd restate the last sentence like this: "The > potential new > Peer or Client may locate a P2PSIP Bootstrap Peer through multicast, > through DNS or through other means." Whoops! The last sentence in the definition about should have read: The new Peer or Client may locate a P2PSIP Bootstrap Peer through multicast, through a P2PSIP Bootstrap Server, or through other means. Thanks for pointing out the error. > > I'd defenitely drop the definition of "P2PSIP Bootstrap Server"; right > now we need to agree on something *simple* and it only seems to be a > matter of argument we just don't need at the moment. The definition of a "P2PSIP Bootstrap Server" has been in the document since the -00 version. I am trying to see if I can get consensus on adding "P2PSIP Bootstrap Peer" (since the -02 draft added this term as an alias for "P2PSIP Bootstrap Server", which I think was a mistake). If I make the wording change above, does this satisfy your concerns? - Philip From enrico.marocco at telecomitalia.it Thu Oct 19 11:53:50 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 19 Oct 2006 17:53:50 +0200 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <29B473E5-DB51-4B48-B24D-6EAE02E48B43@magma.ca> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> <45378421.9070703@telecomitalia.it> <29B473E5-DB51-4B48-B24D-6EAE02E48B43@magma.ca> Message-ID: <45379F8E.7040700@telecomitalia.it> Philip Matthews wrote: >> I'd defenitely drop the definition of "P2PSIP Bootstrap Server"; right >> now we need to agree on something *simple* and it only seems to be a >> matter of argument we just don't need at the moment. > > The definition of a "P2PSIP Bootstrap Server" has been in the document > since the -00 version. > I am trying to see if I can get consensus on adding "P2PSIP Bootstrap > Peer" > (since the -02 draft added this term as an alias for "P2PSIP Bootstrap > Server", which I think > was a mistake). > > If I make the wording change above, does this satisfy your concerns? It seems to me that there is enough agreement for renaming "P2PSIP Bootstrap Peer" the old "P2PSIP Bootstrap Server" and I'm fine with it, expecially after your rewording. What I think would produce more costs than benefits is the _new_ definition of "P2PSIP Bootstrap Server". -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From philip_matthews at magma.ca Thu Oct 19 11:01:20 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 19 Oct 2006 11:01:20 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> Message-ID: <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> On 19-Oct-06, at 10:28 , Salman Abdul Baset wrote: > Node and peer definitions. > > The concept draft considers 'peer' as an entity that participates in > the p2p network (routing decisions, storage) and equates 'peer' with a > 'node'. > > The peer typically means 'super node' in the unstructured P2P > literature > and a 'node' in the DHT literature. > > A 'node' encompasses both 'peer' and 'client' functionality in some > papers and architectures. See for example, "Understanding KaZaA" paper > where it is prefixed with 'super'-node and 'ordinary' node. > > I think it will be helpful to make those distinctions a bit more > clear in > the concepts draft. > As I see it, a key difference between a P2PSIP Overlay and some other P2P systems is that we are not making the peer / super-peer distinction, but are allowing peers with full functionality to lie behind NATs. In other words "P2PSIP Peer" != super-peer (or super-node), and "P2PSIP Client" != peer (or ordinary node). I think this is what you are driving at with your comments. I will add some text to try to make this clear. - Philip From enrico.marocco at telecomitalia.it Thu Oct 19 12:10:24 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 19 Oct 2006 18:10:24 +0200 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <45379F8E.7040700@telecomitalia.it> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> <45378421.9070703@telecomitalia.it> <29B473E5-DB51-4B48-B24D-6EAE02E48B43@magma.ca> <45379F8E.7040700@telecomitalia.it> Message-ID: <4537A370.8000605@telecomitalia.it> Enrico Marocco wrote: > Philip Matthews wrote: >>> I'd defenitely drop the definition of "P2PSIP Bootstrap Server"; right >>> now we need to agree on something *simple* and it only seems to be a >>> matter of argument we just don't need at the moment. >> The definition of a "P2PSIP Bootstrap Server" has been in the document >> since the -00 version. >> I am trying to see if I can get consensus on adding "P2PSIP Bootstrap >> Peer" >> (since the -02 draft added this term as an alias for "P2PSIP Bootstrap >> Server", which I think >> was a mistake). >> >> If I make the wording change above, does this satisfy your concerns? > > It seems to me that there is enough agreement for renaming "P2PSIP > Bootstrap Peer" the old "P2PSIP Bootstrap Server" and I'm fine with it, > expecially after your rewording. What I think would produce more costs > than benefits is the _new_ definition of "P2PSIP Bootstrap Server". Ops.. I've forgotten to say that I'd drop the reference to the P2PSIP Bootstap Server form the definition of "P2PSIP Bootstrap Peer". And I don't mean to misinterpret the agreement of the group: please correct me if I'm wrong ;-) -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From spencer at mcsr-labs.org Thu Oct 19 12:09:32 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 19 Oct 2006 11:09:32 -0500 Subject: [p2p-sip] My notes from the Conference Call on the Concepts draft References: Message-ID: <035f01c6f398$f750e410$0300a8c0@china.huawei.com> > Folks: > > Below are my notes from the conference call on Oct 17th on the > Concepts draft. > > - Philip Cullen asked that the jabber logs also be posted to the list, just so they are archived. We probably had about 40-percent coverage (teleconference participants who were also on jabber), so many people got to review what I was typing in real time and offer corrections, but not everyone did... Thanks, Spencer [13:44:21] --- spencerdawkins has joined [15:39:42] --- philip_matthews has joined [15:49:32] --- swb has joined [15:49:38] Hey ho [15:51:44] Hi folks. I am going to start the bridge in a minute [15:52:07] I'm still on an internal call - be there soon [15:52:48] will dial in now... are people hooking up to the whiteboard application now, or should I wait? [15:52:50] Bridge is now live [15:53:08] I am going to start it now [15:56:23] Whiteboard is started [15:56:54] --- stonblue has joined [15:57:03] Hello [15:58:14] works for me [15:58:48] Recording has started ... [16:01:42] A bunch of people listed attending -- Philip has the complete list [16:02:19] --- cullenfluffyjennings at gmail.com has joined [16:02:32] We are watching :-) [16:03:11] Narayanan [16:03:22] sathya [16:05:42] agenda bashing --- [16:05:48] bigger issues first [16:06:32] what to say about client protocol being same as SIP? [16:06:44] not everybody is happy with version 02 text [16:06:52] remove section 4 completely? [16:07:07] what does SEND operation mean? [16:07:20] "other forms" in terminology section [16:07:26] other major issues? [16:07:45] dean? - text for resource and user need to be reconcilled [16:08:05] --- enrico has joined [16:08:33] dean - user record is defined twice, not the same thing, both have valid text [16:09:47] numeric sequence of digits that uniquely identifies a node - a key? id? or something else? [16:10:15] ID confuses with URI, and key implies a mechanism [16:10:40] david - key as hash term is what you hash to create an ID - the input, not the output [16:11:18] peer id and resource id? [16:11:50] resource name and resource identity are also terms [16:12:01] need to be able to talk about input and outputs [16:12:16] pick another name for the thing before it's hashed? [16:12:43] have never had a firm name for the input, but this is a sip identity... [16:12:59] ID is/'is not short form of identity [16:13:16] :-) [16:13:34] --- enrico has left: Replaced by new connection [16:13:36] --- enrico has joined [16:13:49] terms are already in code ... [16:14:01] are we talking about an index? That could be closer [16:15:06] could we have a peer id? [16:15:31] cullen - not going to be too confused? [16:15:48] dean - list discussion didn't go this direction [16:16:12] dean - willing to accept existing text, just want to make sure we agree [16:16:19] anyone looking for a change? [16:16:44] key isn't good, id isn't good ... if people understand, id is OK [16:18:05] propose that we stick with current terms until we make some decisions that may show us what the right term is [16:18:49] ---------------------- [16:19:08] obtw, this is an official call and covered by note well, and being recorded [16:19:16] ------------- [16:19:21] --- enrico has left [16:19:25] clients vs SIP UAs [16:19:48] text in 02 says IF client protocol is SIP, client and SIP UA are the same thing (or maybe not) [16:20:51] would a client be different from a SIP UA if the client protocol was SIP? [16:21:18] Today is says "In cases where conventional SIP is used for the P2PSIP Client protocol, this entity could be identical to a standard SIP user agent. " [16:21:48] (speaking as me) I'm OK with the current text until we know what the client protocol is [16:22:01] eunsoo - not incorrect, but confusing [16:22:30] "could be identical to a standard SIP COMPONENT"? [16:22:59] david's proposal didn't require a client protocol that wasn't SIP [16:23:16] david thinks that's (a) wave of the future [16:23:42] or other standard SIP component? [16:24:20] get/put as REGISTER? [16:24:49] REGISTER as GET would be unusual, but we think it would work [16:25:16] do we need a lookup protocol at all? [16:25:41] doing REGISTER as a search would be weird [16:26:08] why do all possible cases in this draft? this is what the working group is supposed to do [16:27:11] --- enrico has joined [16:27:11] don't preclude something the working group might need to do [16:27:24] by implication [16:27:40] why do we have the open questions section? [16:28:00] does it need to be the same draft? [16:28:34] leave them in a working document anyway? [16:29:47] questions in a tracker? [16:29:47] --- enrico has left: Logged out [16:29:54] --- enrico has joined [16:32:02] spencer is still whining about "endpoint" trust with peers versus clients [16:32:27] dean thinks this is a solvable problem. Spencer is happy [16:33:01] I think it's going to be a big one. [16:33:05] cullen - 4.9/user credentials [16:33:23] credentials that you get when you enroll? [16:33:59] but they can be passwords, or certificates, or ... asymmetric, right? So they are certificates [16:34:35] arjun - any discussion about identity-based encryption? [16:34:49] this has its own issues [16:35:24] assuming a central certificate authority and hiearchical signing [16:35:40] we can do this discussion as a working group [16:35:55] what text should appear in 4.9? [16:36:26] cullen - we've chosen a central authority, but the form of the certificates could still be listed as an open issue [16:37:31] --- arjunrc has joined [16:37:51] to identify a user SOME resource knows who the user is, but this may not be tied to a particular overlay [16:38:59] Michael - would user name be GUID? [16:40:08] --- enrico has left: Logged out [16:40:09] easily bound to a key, expand to anything, unique in an overlay [16:40:22] dean - but you need a distinguished name [16:40:30] how does this work with ad hoc networks? [16:41:32] if everyone chooses a 160-bit number ... but this is looking for problems [16:41:50] don't want to force a user to get a centralized certificate [16:42:20] don't want to prevent getting a certificate, just don't want to require one (for my private overlay shared with friends) [16:42:39] protocol should provide secure communications, but people can choose to use them [16:43:11] cullen - BCP 41 require implementation of reasonable security. Doesn't require deployment or use, just implementation [16:43:27] did we just use SIP proxies supporting TLS as the touchstone? [16:43:46] --------------- [16:44:04] back to "if client protocol is SIP" - anyone disagree with current language? [16:44:18] could be UA or other entity [16:44:41] statement appears a few places in the document [16:44:53] 3.3, last sentence is one example (there are others) [16:45:30] does eunsoo need all of the places to change? [16:45:52] sip ua, sip proxy, or any other SIP component [16:47:09] in diagrams - UA PLUS a client [16:48:02] just extending "or other client-server SIP entity" - just "any SIP entity" [16:48:28] No ... "identical to a standard sip entity" [16:49:40] have we already agreed? [16:49:44] :-) [16:50:46] we can define a client protocol, but we don't have to - anyone disagree? [16:52:37] we may need to describe the use of SIP as a client protocol in more detail, but we don't have to do that now [16:53:07] any other change around this issue? [16:53:23] need to be consistent throughout the document [16:53:56] ------------------ [16:54:01] remove section 4? [16:55:36] and say "these are questions that the working group will be answering as a working group" - don't confuse firsttime reviewers (on the IESG :-)) [16:55:43] ------------------------ [16:55:56] get/put with no description of SEND operation [16:56:12] add a section before 3.3 that talks about these operations and what they mean? [16:56:48] focus especially on what SEND means - send messages across overlays to peers that are on the other side of a NAT [16:58:02] tunnel SIP and/or overlay maintenance through SEND for NAT traversal [16:58:15] --- slavitch has joined [16:59:28] eunsoo thinks we need more discussion about this [16:59:51] Scott thinks we'll need a SEND, but don't put a lot of information in about this [17:00:01] because we don't know what it will be for [17:00:05] need agreement on this to charter? [17:00:45] cullen - people have addresses and we route through addresses to get to people [17:01:12] if we start saying "there's a SEND message and ..." people will think we don't have a good metaphor for the design [17:01:55] we'll have time to hash this out as a working group after the BOF [17:02:28] cullen - we know we will have to route from A to C through B, but that may not require a SEND message [17:02:51] I think a major topic is how are we going to work the signaling thought NATs [17:03:12] and WHAT we are going to need to work through NATs [17:03:24] spencer: yeah, but we said BEHAVE would worry about this, or MMUSIC, or ... [17:04:09] we're opening a can of worms that we can't defend - just say we need to get through NATs in section 4. [17:04:23] ------------------------- [17:04:43] short forms of names? useful, or remove them and use canonical terms? [17:05:12] only using short forms as "other people call it this" [17:06:28] "deprecated forms"? [17:06:43] did we invent the terms that are causing problems now ourselves? [17:07:17] mailing list is fairly new use one term now and ignore the past? but the past is two years long... [17:08:29] People have been calling peers nodes for a very long time... david will send the must-keep list [17:08:51] other people can send candidates, too [17:09:19] from a SIP perspective - "SIP client" means UAC. Won't this confuse developers? [17:09:34] --- stonblue has left [17:09:52] "node" and "enhanced node" in p2p [17:10:22] very difficult to disambiguate stuff unless we come up with completely new terms [17:11:30] spencer is confused about clients with no servers, but we have a hybrid architecture and we've been trying to figure this out for a while [17:11:52] "node" reuse would actually be worse... [17:12:35] let's discuss "client" in a bar in San Diego [17:12:43] --------------------- [17:13:01] two definitions of user record in the draft [17:13:12] do we need a separate user and resource? [17:13:28] blow away second definition in the current draft? [17:13:43] none are opposed [17:13:55] SORRY - I typed too fast [17:14:32] David just missed the second use or user resource record [17:14:50] "of" user resource record [17:15:56] agree - we blow the second definition away [17:16:24] resource is used in P2P literature already for something else [17:16:56] one object has SIP URI, other just has ID [17:17:09] (MIGHT have a SIP URI) [17:18:53] eunsoo thinks we are talking about two different categories of entities [17:19:42] is a user special (compared to SIP)? In a normal SIP environment, you don't HAVE to look for a relay, you don't HAVE to look where a voice mail is stored... [17:20:05] Scott - OK with resources, but confused about users... not just human users, right? [17:20:37] Off the phone but still watching jabber [17:20:37] users on the outside, resources on the inside? [17:21:28] scott thinks this, eunsoo thinks this ... [17:24:25] is a user a subset of resource, or is it something else? [17:25:04] philip - is UA in my SIP phone a user or a resource? [17:25:25] Scott is thinking hard - when you register, you become a resource [17:25:42] resources and user RECORDS - this is clearer [17:26:15] relay resource may not even be in the same namespace as the user... [17:26:28] is this a layering problem? we think so [17:26:39] entities in two different layers [17:27:33] scott - you can address my FTP client using FTP, but not my machine [17:28:02] philip - am I the user? is my UA a resource? [17:28:03] or rather ... you address my machine with IP, you address my FTP server with a port [17:28:31] arjun - this is a logical definition. Could be a user and a resource at the same time in two different sessions [17:29:15] this is a layering problem [17:30:00] philip doesn't know what to write by Monday. Do we have to write something by Monday? [17:32:31] (sorry - I was distracted by real life - back now) [17:33:06] user resource record - record doesn't participate in communication itself [17:33:44] (speaking for myself) it seems like we just need a nice object model here that we don't have, quite yet [17:33:50] do we need one before Monday? [17:34:58] point of the document at this stage is to get our hands around the entities that need to be named. We can talk more later [17:35:11] -------------------------- [17:35:46] one metaquestion - Philip planning to revise and submit update. Another call before San Diego? [17:36:35] No one is pushing for an ad hoc on Friday afternoon [17:39:27] Spencer pointed out that we're probably looking at more than two months after the BOF before a charter - so please don't wait until the charter to work some more [17:39:29] gtg - cya [17:39:35] --- arjunrc has left [17:40:06] cullen - some calls are to solve a problem, some calls are a forcing function [17:40:08] --- cavedon has joined [17:40:53] cullen - don't slow down progress, make sure you don't have a small group of people agree on a call that a large group of people doesn't agree on later [17:41:34] document won't be brought to closure any time soon, document will evolve as working group works [17:41:54] having another meeting? not before San Diego [17:42:31] schedule a call when we know why we need one [17:43:59] had a good turnout on this call, sign of success. [17:45:07] cullen - if you have a call, you'll generate an hour of issues on anything [17:45:27] make sure you're working on getting people to talk to each other, and to soften violent exchanges [17:45:40] Is there a way to cleave the difference between a charter discussion and a functional discussiom? [17:46:53] --- slavitch has left [17:47:08] --- swb has left [17:47:44] --- philip_matthews has left [17:52:25] --- slavitch has joined [17:52:58] --- slavitch has left [18:02:42] --- cavedon has left [18:22:53] --- cullenfluffyjennings at gmail.com has left From slavitch at gmail.com Thu Oct 19 15:01:31 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 19 Oct 2006 15:01:31 -0400 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <4536A82A.1050705@acm.org> References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> <45368DAF.6020508@acm.org> <8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> <4536A82A.1050705@acm.org> Message-ID: <1fc32c8f0610191201k3361a30cvbef9b511e1c90d03@mail.gmail.com> On 10/18/06, Marc Petit-Huguenin wrote: > Excepted that the IETF work is "above the wire and below the > application." I think that the proposal of Henry and the other authors, > to do not define another SIP but just define the subset of SIP to use, > is the way to go. Let's the implementors do not have to juggle with > 100+ RFCs and I-Ds and let them design the services that the PSTN/IMS > will be jealous of. > This is a perfect description of the problem being solved. Thank you. SIP as it stands is immensely powerful but is being obscured by arcana. It is vital that application developers have invariant common reference descriptions so they know what the foundations are and trust that those underpinnings are there. The draft starts us on a path that leads towards an open common communications platform that application developers can depend on. > Well, this said, I would be happy if the B2BUA definition can be removed A B2BUA is useful in many technical circumstances. My employer uses one such B2BUA in order to map a proprietary identity and authority regime with those of SIP and the public Internet. It solves many problems, and as long as these requirements are easily met our customers are happy. E2E is not one of these requirements. Far from it. They firewall/NAT up the wazoo and each circumstance and implementation is different. The B2BUA definition allowed SIP to be revolutionary enough to not scare the pants out of the people who want their revolutions to be easy and on their terms. It allowed SIP efforts to get green-lighted and budgeted by people who would otherwise have waved it off as too bleeding edge. It gave systems that were long in the tooth before they were even born a new lease on life. It was the B2BUA definition made SIP safe for the boardroom. It is like NAT in that manner. But like NAT the B2BUA genie is now out of the bottle. It got us here but it won't go away now that it is a problem. The answer? Make the B2BUA genie a non-issue with applications that can traverse any B2BUA in the same way that Skype turned NAT a non-issue. My Irish Wolfhound can jump any walled garden. Whomever slays the B2BUA genie becomes the next Skype. > And all the SHOULD rewritten to MUST. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Complete total utter agreement. It is the essential problem that is at hand. Henry, Alan and Kundan: Well-done. Regards M From slavitch at gmail.com Thu Oct 19 15:08:22 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 19 Oct 2006 15:08:22 -0400 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems In-Reply-To: <1fc32c8f0610191201k3361a30cvbef9b511e1c90d03@mail.gmail.com> References: <24CCCC428EFEA2469BF046DB3C7A8D221411EF@namail5.corp.adobe.com> <45368DAF.6020508@acm.org> <8E3CFC96-0397-4F1D-8A1A-19D3A5F18BB5@gmail.com> <4536A82A.1050705@acm.org> <1fc32c8f0610191201k3361a30cvbef9b511e1c90d03@mail.gmail.com> Message-ID: <1fc32c8f0610191208m4eec1ca8ybd4cbe4be774205b@mail.gmail.com> Ensoo too, of course. Forgive me for my initial omission. > Henry, Alan and Kundan: Well-done. From huang-ming.pan at comcast.net Thu Oct 19 15:13:31 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 19 Oct 2006 12:13:31 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <000001c6f389$730feb10$76244e0a@china.huawei.com> Message-ID: <008801c6f3b2$ab95b040$030aa8c0@comcast.net> Hi, Xian. > X.509 is rarely used for server to authenticate clients, because the server > usally keep the user's account information, or deploy some IP filter > mechanisms. But in the P2P environment, peer may need to authenticate each > other and they don't even know before. So we need some distributed > authentication mechanism, such as X.509 authentication. > > Although there are some complex code related to ASN.1 when use the X.509 > certificate, but it doesn't mean using X.509 cert is a bad choice. > As to the SPKI, it has many function related to authorization, not only > related to authentication. The author named it as "simple", because it can > provide authorization and authentication service at the same time, and need > not to build a infrastructure from bottom-up. And also, the field and > s-expression is easy to understand. But i think that is not the main point. > And SPKI certificate is also rarely used. > > Does Skype use a PKI? I used to think it just use a centralized user > database. > > > Xian Zhu Sometimes saying more confuses more. You could read this report of four-month code evaluation on Skype security and try to judge whether simplicity and sophistication can co-exist without compromising functionality. http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf I don't quite understand what it says of ASN.1 Attack. If you do, please convey your grasp to me at your kindly convenience. Thanks. Peter From slavitch at gmail.com Thu Oct 19 15:27:24 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 19 Oct 2006 15:27:24 -0400 Subject: [p2p-sip] Fwd: Concepts draft: Bootstrap server vs. bootstrap peer In-Reply-To: <4537A370.8000605@telecomitalia.it> References: <8b2769930610181458k6660ca64o4e969cabe7d80645@mail.gmail.com> <009f01c6f302$c717d5b0$0300a8c0@china.huawei.com> <04E60AEA-FB9B-4AC1-AD7E-FDC5B43B4793@magma.ca> <45378421.9070703@telecomitalia.it> <29B473E5-DB51-4B48-B24D-6EAE02E48B43@magma.ca> <45379F8E.7040700@telecomitalia.it> <4537A370.8000605@telecomitalia.it> Message-ID: <1fc32c8f0610191227t7341c83ay275391e73ab74a27@mail.gmail.com> A question: Does the defined "boostrap server" always need to communicate with other P2PSIP entities in order to perform the bootstrap? Some reasons why would be to fetch a fast-changing item that is local to the P2PSIP domain. If the answer is "not always" then the bootstrap mechanism need not be a server. It can be a secureid card, for example, operating from a common seed used by the overlay. If that is true a different name for the "bootstrap mechanism" is needed. From spencer at mcsr-labs.org Thu Oct 19 15:34:28 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 19 Oct 2006 14:34:28 -0500 Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems References: <5D1A7985295922448D5550C94DE29180625857@DEEXC1U01.de.lucent.com> Message-ID: <046d01c6f3b5$981ceb20$0300a8c0@china.huawei.com> Hi, Keith, > First, I believe the proposed charter for p2p-sip precludes discussion > of this in the new working group if it is formed. Just as an aside, I believe that one common AD metric for evaluating in-scope/out-of-scope discussions is whether the WG is making progress on the work it's already chartered to do. > Having said that, lets discuss it. :-) > Rather than trying to make mileage out of 100 versus 11, presumably > based on the fact that a lot of things that are useful are simulating > the telephone network and not therefore required (like the ability to > describe a voice only session in SDP - no RFC 4566 reference), can I > suggest that the better way of doing this would be to describe what is > in the current sip hitchhiker document that is NOT needed because it is > a centralised function that is no longer required in the p2p-sip > architecture. As such it will need to track the SIP hitchhiker document > as that develops. If the feature is still required, then it would need > to indicate the means of supporting that feature. I'm actually not finding a list of "about 11" references called out in the 00 draft. The draft has 11 normative references, but this includes 2119, so I think I'm missing something. Could the list be called out more clearly in the text? Having said this ... Jonathan has been trying valiantly to limit the scope of the hitchhiker's guide to SIP and its extensions. Will this limitation affect our ability to use the hitchhiker's guide for the purpose Keith suggests? > Further, to take an example, it does not show the sip-identity document > (RFC 4474). Either authenticated identity is regarded as too telephony > like and it is eliminated for those purposes (in which case I note some > email systems seem to be doing it), or it is eliminated because it needs > some sort of server to provide a certification body. My understanding is > that even p2p-sip will have to have centralised certification, and > therefore that criteria for elimination would be unreasonable. I do > accept that RFC 3325 would not figure because it requires centralised > capabilities. I agree with Keith mostly here. I'm not sure if Keith means "will have to have" as a default requirement, a mandatory-to-implement requirement, or a mandatory-to-deploy requirement. One of the use cases was "Presence Using Multimedia Consumer Electronics Devices", with something like P2PSIP as the application protocol over bluetooth, and mandatory-to-deploy centralized certification would be overkill in these situations. From swb at employees.org Thu Oct 19 16:30:37 2006 From: swb at employees.org (Scott W Brim) Date: Thu, 19 Oct 2006 16:30:37 -0400 Subject: [p2p-sip] Concepts draft: dropping "P2PSIP" in terms In-Reply-To: <61B1C752-F1CD-405E-8CDC-362E17F3A62B@magma.ca> References: <760DD15A-7FB1-412F-8E78-AEA57899D91E@magma.ca> <8b2769930610181439s6a090762yb5f60260a2a33f24@mail.gmail.com> <61B1C752-F1CD-405E-8CDC-362E17F3A62B@magma.ca> Message-ID: <20061019203037.GB2008@sbrim-wxp01> Excerpts from Philip Matthews on Wed, Oct 18, 2006 05:47:28PM -0400: > I didn't express myself well. > > I am proposing to replace "P2PSIP Peer-ID" with "Peer-ID" > EVERYWHERE it appears in the document. > > And similarly replace "P2PSIP Client Protocol" with "Client Protocol", > "P2PSIP Peer Insertion" with "Peer Insertion", etc. etc. I think it's important to keep these. We can drop the "P2PSIP" when speaking, for now, but we are establishing concept names which will last a long time and we don't know what's coming. I dunno, suppose we have a P2P infrastructure that is used for more than SIP? Multiple overlays using the same peers? Anyway lots of detail when laying a foundation never never hurts. From swb at employees.org Thu Oct 19 18:30:08 2006 From: swb at employees.org (Scott W Brim) Date: Thu, 19 Oct 2006 18:30:08 -0400 Subject: [p2p-sip] Updated concepts and terminology draft available In-Reply-To: <8b2769930610120802m52bb8ad8v3332eb373c9c8214@mail.gmail.com> References: <8b2769930610120802m52bb8ad8v3332eb373c9c8214@mail.gmail.com> Message-ID: <20061019223006.GC2008@sbrim-wxp01> Where did we end up on "user" and "resource"? I am not sure I can sort it all out but I believe I would completely separate the two. - Users are ultimate consumers, e.g. humans, and are not themselves resources. - Users _enroll_, and are authenticated based on enrollment information, but resources are what's directly visible in the overlay, not users. - When a resource joins the overlay the mapping between user and resource (e.g. something with an IP address) is not necessarily installed. It can come later, if ever. Therefore there are both resource records and user records and they may be distinct. Also, a user can participate using multiple resources, and a single user agent may support multiple simultaneous users. I think we need distinct concepts for both resource records and user records. So I would take "(user)" etc. out of the draft, and change "user" to "resource" except in relation to enrollment, user agents, issues around resources joining versus users authenticating, and a new definition for user record separate from resource record. I'll just launch that and see how it feels before proposing details. Scott From abum at aftek.com Thu Oct 19 23:28:01 2006 From: abum at aftek.com (Abu M. Muttalib) Date: Fri, 20 Oct 2006 08:58:01 +0530 Subject: [p2p-sip] Sending telephone events Message-ID: Hi, Is it MUST to send clock frequency and corresponding fmtp for telephone event? OR is it OPTIONAL?? I tried to interpretive the FRS but conclusion was not made. Please help. Thanks and regards, Abu. From bryan at ethernot.org Thu Oct 19 23:36:08 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 19 Oct 2006 23:36:08 -0400 Subject: [p2p-sip] The terms I want to save... In-Reply-To: References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> Message-ID: <8b2769930610192036w530d65b8s311e86fbaeca2211@mail.gmail.com> Philip: Suspect we are overwhelming the list with minutia here, but since this discussion thread got moved to the list, I'll leave it here. Sorry if folks are getting bored with the detail level on this. The terminology draft currently uses: P2PSIP Peer Insertion: peer or node join, peer or node registration In the past I used admission, rather than insertion. I went to change the term in one of my other drafts, and when I read the modified text (particular as it talks about challenges and the like), I am actually increasingly unhappy with insertion vs. admission. There are security aspects of checking to see if a node should be let in (for some scenarios), and I prefer something that has the sense of the action being on the part of the overlay, not the node. The overlay allows, or "admits" the node to join, rather than the forceful word choice of a node "inserting" itself. I'd at the least like to see as an alternate. Thoughts? David On 10/18/06, Philip Matthews wrote: > Copying the list, since we really should have this discussion in public. > > On 18-Oct-06, at 16:58 , David A. Bryan wrote: > > > Assuming we cut all the short versions (be prepared for folks to still > > use them...I'm not going to have the word "P2PSIP" in front of every > > time I say peer or overlay in all my drafts), I really care about > > (some of which I noticed aren't there now): > I am proposing to blow away all these "P2PSIP" prefixes. > See separate e-mail. > > > > > P2PSIP Peer: node > I added the text > "(Note: The P2P literature often uses the term "node" > instead of "peer")" > > > > P2PSIP Peer-ID: Node-ID > I added the text: > "(Note: This is often called a "Node-ID" in the P2P > literature)." > > > > > P2PSIP User Agent: P2PSIP UA > The hanging text now reads "P2PSIP User Agent (UA):" > > > > > P2PSIP Bootstrap Server: bootstrap peer, bootstrap node > See separate e-mail. > > > > > P2PSIP Peer Insertion: peer or node join, peer or node registration > I added the text: > (Note: In the P2P literature, this operation is often called > "joining" or > "registering" with the overlay). > > > > > P2PSIP Resource (User) Record Insertion: user registration > > I think this one is controversial, since we have not yet resolved the > "resource" vs. "user" debate. > > > > From dean.willis at softarmor.com Fri Oct 20 00:09:48 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Thu, 19 Oct 2006 23:09:48 -0500 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> Message-ID: <97D9635E-5093-4891-AAE2-3334771B028F@softarmor.com> On Oct 19, 2006, at 8:58 AM, Philip Matthews wrote: >> > > How about the following definition for "P2PSIP Resource (User) > Record"? > This is a slightly modified version of the text of the first > definition. > Does this satisfy your concern? > > A block of data, stored using the data > mechanism of the P2PSIP Overlay, that includes > information relevant to a specific > resource. We presume that there may be multiple types of > resource records. Some may describe > routes to a P2PSIP Peer or Client at which the user or > resource is presumed reachable > (e.g., a "user routing record" like a SIP "Contact:"). > Others might store presence information. > The types, usages, and formats of user records are a > question for future study. > I like it. Thanks. -- Dean From salman at cs.columbia.edu Fri Oct 20 11:36:12 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Fri, 20 Oct 2006 11:36:12 -0400 (EDT) Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> Message-ID: I want to clarify the relationship between a 'node' and the definitions of 'peer' and a 'client'. In one of your earlier posts, you had mentioned that you have added the following text to the concepts doc: "(Note: The P2P literature often uses the term "node" instead of "peer")" https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/001497.html I would rather say something like: "Note: The P2P literature often uses the term "super-node" instead of a "peer" and generally assumes that peers cannot be behind a NAT or a firewall. There is no such restriction for a peer as defined in this draft. Further, the P2P literature uses the term "ordinary-node" for a "client". regards, Salman > > As I see it, a key difference between a P2PSIP Overlay and some other > P2P systems > is that we are not making the peer / super-peer distinction, but are > allowing > peers with full functionality to lie behind NATs. In other words > "P2PSIP Peer" != super-peer (or super-node), and > "P2PSIP Client" != peer (or ordinary node). > > I think this is what you are driving at with your comments. > I will add some text to try to make this clear. > > - Philip > From slavitch at gmail.com Fri Oct 20 12:16:27 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 20 Oct 2006 12:16:27 -0400 Subject: [p2p-sip] The terms I want to save... In-Reply-To: <8b2769930610192036w530d65b8s311e86fbaeca2211@mail.gmail.com> References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> <8b2769930610192036w530d65b8s311e86fbaeca2211@mail.gmail.com> Message-ID: <1fc32c8f0610200916n49182529r96a4366aeaa1d445@mail.gmail.com> David; This is certainly not minutia, it creates implications regarding the essence of what the working group is building: networks. Admit is a more accurate word that is more in line with the requirements for authentication and security. It also places the onus of interoperability on the network, not the individual endpoint. If you admit something, you must accept it how it works. Correspondingly there are terms of acceptance, which implies that these terms must be advertised to the entity attempting acceptance. This not the case in insertion-based schemes. There the onus is moved to the endpoint to figure out how to get in, which is impossible to figure out. A NAT is one such insertion based scheme. ICE and Skype are both insertion mechanisms. Given that "Admit" creates stronger contracts and tighter systems, eliminating problems down the road. If there was such a standard NAT "admit" protocol life would be much easier and the VPN would be obsolete. "Admit", with terms, does that for P2PSIP. Regards M On 10/19/06, David A. Bryan wrote: > Philip: > > Suspect we are overwhelming the list with minutia here, but since this > discussion thread got moved to the list, I'll leave it here. Sorry if > folks are getting bored with the detail level on this. > > The terminology draft currently uses: > > P2PSIP Peer Insertion: peer or node join, peer or node registration > > In the past I used admission, rather than insertion. I went to change > the term in one of my other drafts, and when I read the modified text > (particular as it talks about challenges and the like), I am actually > increasingly unhappy with insertion vs. admission. > > There are security aspects of checking to see if a node should be let > in (for some scenarios), and I prefer something that has the sense of > the action being on the part of the overlay, not the node. The overlay > allows, or "admits" the node to join, rather than the forceful word > choice of a node "inserting" itself. > > I'd at the least like to see as an alternate. > > Thoughts? > > David > > On 10/18/06, Philip Matthews wrote: > > Copying the list, since we really should have this discussion in public. > > > > On 18-Oct-06, at 16:58 , David A. Bryan wrote: > > > > > Assuming we cut all the short versions (be prepared for folks to still > > > use them...I'm not going to have the word "P2PSIP" in front of every > > > time I say peer or overlay in all my drafts), I really care about > > > (some of which I noticed aren't there now): > > I am proposing to blow away all these "P2PSIP" prefixes. > > See separate e-mail. > > > > > > > > P2PSIP Peer: node > > I added the text > > "(Note: The P2P literature often uses the term "node" > > instead of "peer")" > > > > > > P2PSIP Peer-ID: Node-ID > > I added the text: > > "(Note: This is often called a "Node-ID" in the P2P > > literature)." > > > > > > > > P2PSIP User Agent: P2PSIP UA > > The hanging text now reads "P2PSIP User Agent (UA):" > > > > > > > > P2PSIP Bootstrap Server: bootstrap peer, bootstrap node > > See separate e-mail. > > > > > > > > P2PSIP Peer Insertion: peer or node join, peer or node registration > > I added the text: > > (Note: In the P2P literature, this operation is often called > > "joining" or > > "registering" with the overlay). > > > > > > > > P2PSIP Resource (User) Record Insertion: user registration > > > > I think this one is controversial, since we have not yet resolved the > > "resource" vs. "user" debate. > > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From philip_matthews at magma.ca Fri Oct 20 13:24:30 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 20 Oct 2006 13:24:30 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> Message-ID: <1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> On 20-Oct-06, at 11:36 , Salman Abdul Baset wrote: > I want to clarify the relationship between a 'node' and the > definitions of > 'peer' and a 'client'. > > In one of your earlier posts, you had mentioned that you have added > the > following text to the concepts doc: > > "(Note: The P2P literature often uses the term "node" instead of > "peer")" > https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/ > 001497.html > > I would rather say something like: > > "Note: The P2P literature often uses the term "super-node" instead > of a > "peer" and generally assumes that peers cannot be behind a NAT or a > firewall. There is no such restriction for a peer as defined in > this draft. Further, the P2P literature uses the term "ordinary- > node" for > a "client". > Yesterday, I added the following text to my working draft under the definition of P2PSIP Peer: A notable property of P2PSIP Peers is that they can be fully functional peers while residing behind NATs. Contrast this with some other P2P systems which make a distinction between "peer" and "super-peer" (or "node" and "super-node") where the latter must have a public IP address. I think this captures the first part of your comment (albeit in different words). Do you agree? As for the statement that client = ordinary-node, I am not sure that this is true. It seems to me that in our architecture, a client has a more limited role than a "ordinary-node" has in most P2P systems. Anyone else care to comment on this? - Philip From salman at cs.columbia.edu Fri Oct 20 14:29:19 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Fri, 20 Oct 2006 14:29:19 -0400 (EDT) Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: <1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> <1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> Message-ID: > Yesterday, I added the following text to my working draft under the > definition of > P2PSIP Peer: > A notable property of P2PSIP Peers is that > they can be fully functional peers while residing behind > NATs. Contrast this with > some other P2P systems which make a distinction between > "peer" and "super-peer" > (or "node" and "super-node") where the latter must have a > public IP address. > > I think this captures the first part of your comment (albeit in > different words). > Do you agree? Yes. > As for the statement that client = ordinary-node, I am not sure that > this is true. > It seems to me that in our architecture, a client has a more limited > role than > a "ordinary-node" has in most P2P systems. I think of an "ordinary-node" as an entity that does not participate in routing and storage functions which is similar to the definition of a 'P2PSIP client'. See for example "Understanding KaZaA" paper. My worry is about the mixing of the term 'node' with 'peer' and 'client'. Perhaps, there is no need for such a clarification. Maybe, others can comment? Regards, Salman > Anyone else care to comment on this? > > - Philip > From philip_matthews at magma.ca Fri Oct 20 14:32:46 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 20 Oct 2006 14:32:46 -0400 Subject: [p2p-sip] The terms I want to save... In-Reply-To: <8b2769930610192036w530d65b8s311e86fbaeca2211@mail.gmail.com> References: <8b2769930610181358g4a09b103w28f34dec6f2a3ed6@mail.gmail.com> <8b2769930610192036w530d65b8s311e86fbaeca2211@mail.gmail.com> Message-ID: On 19-Oct-06, at 23:36 , David A. Bryan wrote: > Philip: > > Suspect we are overwhelming the list with minutia here, but since this > discussion thread got moved to the list, I'll leave it here. Sorry if > folks are getting bored with the detail level on this. > > The terminology draft currently uses: > > P2PSIP Peer Insertion: peer or node join, peer or node registration > > In the past I used admission, rather than insertion. I went to change > the term in one of my other drafts, and when I read the modified text > (particular as it talks about challenges and the like), I am actually > increasingly unhappy with insertion vs. admission. > > There are security aspects of checking to see if a node should be let > in (for some scenarios), and I prefer something that has the sense of > the action being on the part of the overlay, not the node. The overlay > allows, or "admits" the node to join, rather than the forceful word > choice of a node "inserting" itself. > > I'd at the least like to see as an alternate. > I think you have a good point. The peer inserting itself will somehow have to show that it is allowed to do this, and "Insertion" doesn't quite have this connotation. However, I believe there are also actions that the peer has to take as well to build its finger table (or whatever), and here "admission" doesn't quite convey that either. I am thinking that "join" is the right verb, because it implies action on the part of the peer, but the overlay can also challenge. Unfortunately, I cannot find a good noun to go with this verb. I will somehow flag this in the document. I am starting to think that an open issues section, which lists things we want to fix in the document, might be a good thing to add. - Philip From huang-ming.pan at comcast.net Fri Oct 20 14:43:10 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 20 Oct 2006 11:43:10 -0700 Subject: [p2p-sip] Comments on concepts-02 References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca><15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca><4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca><1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> Message-ID: <004a01c6f477$97c00ff0$030aa8c0@comcast.net> ----- Original Message ----- From: "Salman Abdul Baset" To: "Philip Matthews" Cc: Sent: Friday, October 20, 2006 11:29 AM Subject: Re: [p2p-sip] Comments on concepts-02 > > > Yesterday, I added the following text to my working draft under the > > definition of > > P2PSIP Peer: > > A notable property of P2PSIP Peers is that > > they can be fully functional peers while residing behind > > NATs. Contrast this with > > some other P2P systems which make a distinction between > > "peer" and "super-peer" > > (or "node" and "super-node") where the latter must have a > > public IP address. > > > > I think this captures the first part of your comment (albeit in > > different words). > > Do you agree? > > Yes. > > > > As for the statement that client = ordinary-node, I am not sure that > > this is true. > > It seems to me that in our architecture, a client has a more limited > > role than > > a "ordinary-node" has in most P2P systems. > > I think of an "ordinary-node" as an entity that does not participate in > routing and storage functions which is similar to the definition of a > 'P2PSIP client'. See for example "Understanding KaZaA" paper. > > My worry is about the mixing of the term 'node' with 'peer' and 'client'. > Perhaps, there is no need for such a clarification. Maybe, others can > comment? > > Regards, > Salman There seems no need. 'Peer' vs 'Client' seems like 'MAY' vs 'MUST' (RFC 2119). From philip_matthews at magma.ca Fri Oct 20 15:33:12 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 20 Oct 2006 15:33:12 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> <1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> Message-ID: On 20-Oct-06, at 14:29 , Salman Abdul Baset wrote: > >> As for the statement that client = ordinary-node, I am not sure that >> this is true. >> It seems to me that in our architecture, a client has a more limited >> role than >> a "ordinary-node" has in most P2P systems. > > I think of an "ordinary-node" as an entity that does not > participate in > routing and storage functions which is similar to the definition of a > 'P2PSIP client'. See for example "Understanding KaZaA" paper. > > My worry is about the mixing of the term 'node' with 'peer' and > 'client'. > Perhaps, there is no need for such a clarification. Maybe, others can > comment? > On the conference call on Tuesday, some people were proposing alternative names for the term "Client", since Peer and Client doesn't mix very well, and Client makes people think of a SIP UAC. However, none of the alternatives seemed to resonate with the participants on the call. In the end, someone suggested a bar session in San Diego to try to come up with alternative names. Ignoring the names for now, are you happy with the definitions? - Philip From eunsoo at research.panasonic.com Sat Oct 21 10:26:19 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Sat, 21 Oct 2006 10:26:19 -0400 Subject: [p2p-sip] Comments on concepts-02 In-Reply-To: References: <1DF152D2-1B0A-46B6-ACFE-93C031AF83BB@magma.ca> <15BF1D92-0C72-44A6-A9E7-CF14C272C7E0@magma.ca> <4C51F258-BC8A-454A-A8D1-5462E40653BF@magma.ca> <1030F5C0-DD29-4C74-A936-2EBFDEC7F4D3@magma.ca> Message-ID: <453A2E0B.2070102@research.panasonic.com> Salman Abdul Baset wrote: >>Yesterday, I added the following text to my working draft under the >>definition of >>P2PSIP Peer: >> A notable property of P2PSIP Peers is that >> they can be fully functional peers while residing behind >>NATs. Contrast this with >> some other P2P systems which make a distinction between >>"peer" and "super-peer" >> (or "node" and "super-node") where the latter must have a >>public IP address. >> >>I think this captures the first part of your comment (albeit in >>different words). >>Do you agree? >> >> > >Yes. > > > > >>As for the statement that client = ordinary-node, I am not sure that >>this is true. >>It seems to me that in our architecture, a client has a more limited >>role than >>a "ordinary-node" has in most P2P systems. >> >> > >I think of an "ordinary-node" as an entity that does not participate in >routing and storage functions which is similar to the definition of a >'P2PSIP client'. See for example "Understanding KaZaA" paper. > > > I agree with Salman. I don't see any difference between the concept of ordinary node and the P2P SIP Client. >My worry is about the mixing of the term 'node' with 'peer' and 'client'. >Perhaps, there is no need for such a clarification. Maybe, others can >comment? > > Well, currently we have not found good names for these terms most of us are satisfied with. :-( Thanks. Eunsoo From philip_matthews at magma.ca Sun Oct 22 14:13:04 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Sun, 22 Oct 2006 14:13:04 -0400 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-02 In-Reply-To: <011801c6f0f6$69d25190$02595f0a@hi.inet> References: <011801c6f0f6$69d25190$02595f0a@hi.inet> Message-ID: Gustavo: Thanks for your comments on the document. See more inline. - Philip On 16-Oct-06, at 03:40 , Gustavo Garc?a Bernardo wrote: > Hi, > > Some minor comments on the new version of draft: > > * The ?P2PSIP Record (user) record? definition is duplicated. They > should > be mixed or deleted one of them. Deleted second definition and did some minor rewording on the first. > > * 3.1. Media relay: not limited to RTP. Also MSRP for example. The text now reads: Media relay: a P2PSIP peer or client capable of relaying media sessions. For example, an RTP relay as described in > > * 3.4.3. "which speaks the P2PSIP server protocol" ==> "which > speaks the > P2PSIP peer protocol" Fixed. > > * 3.4.3. "as part of enrollment of through" ==> "as part of > enrollment or > through" Fixed. > > * 3.4.4. The P2PSIP client/peer could discover directly other peers > (for > instance using multicast) without discovering a bootstrap server > before. I have rewritten this section to take into account the distinction between bootstrap server and bootstrap peer. It now explicitly mentions various ways of finding a bootstrap peer, of which using a bootstrap server is only one way. > > * Although in section 3.4.2. the client protocol is defined as put/ > get/send, > the send message is not explained/used in the rest of the draft. For > example before sending a SIP message in the example signalling > flows always > there are Lookups operations followed by direct SIP session > establishment, > instead of a possible Send operation. For now, I have removed any mention of a send operation and simply noted that there is an open issue of how to contact peers and clients behind NATs. The document notes that, because of NAT filtering rules, it may be necessary to relay messages through intermediate peers, but doesn't say anything about how this is done. - Philip From philip_matthews at magma.ca Sun Oct 22 14:46:56 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Sun, 22 Oct 2006 14:46:56 -0400 Subject: [p2p-sip] Checking "My notes on draft-willis-p2psip-concepts-01" against version 02 In-Reply-To: <394401c6f212$63948a10$0300a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <394401c6f212$63948a10$0300a8c0@china.huawei.com> Message-ID: <29A3071F-4A0A-4E5E-A18B-7354E44261B7@magma.ca> Hi Spencer: I have addressed some of your concerns. See inline. - Philip On 17-Oct-06, at 13:33 , Spencer Dawkins wrote: > Sorry for not sending this sooner. But... > > I'm really pleased with the changes that are now in 02. (although > we might > reasonably change some terminology when we make some decisions that > are > still open issues now, and I'm not totally sure *I* understand what an > endpoint is). > > Just for completeness, I compared my notes on the previous version > against > 02. Many were addressed, so I deleted those comments from the list > shown > below - anything remaining is still something I'm wondering about. > > Please note that several of my notes are from the section on open > questions, > and I'm ok with these questions being open at charter time. > > Thanks, > > Spencer > >> P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP >> Overlay Peers or Clients who are attempting to enter to >> locate an >> entry into the P2P Overlay Network. It may return an entry >> point >> (address of a Peer) to the P2PSIP Overlay or act as one itself. >> This should be a quasi-stable and well known host, located >> using a >> configuration or discovered via , DNS, broadcast, or other >> mechanism. Example: a P2PSIP Overlay Peer that reboots and >> has no >> knowledge of other peers uses a P2PSIP Overlay Bootstrap >> Server to >> find other peers in the P2P Overlay Network and establish P2PSIP >> Overlay Peer Insertion. (Note: An overlay peer might or >> might not >> provide this functionality). Short forms: bootstrap server, >> boot >> server. >> >> These short forms seem very likely to conflict with lower-layer >> usage of >> the >> same terms, where "bootstrap server" and "boot server" have a >> well-understood usage. "Overlay bootstrap server" as short form? > > This is now "bootstrap peer". That's an improvement. As previously discussed, the document now make a distinction between a bootstrap peer and a bootstrap server. > >> 3.3. Conceptual Outline of Operations >> >> 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer >> >> Peers are the full-function "routing and storage" nodes of a P2PSIP >> Overlay. When a new peer is first created, it must enroll in the >> P2PSIP Overlay. We currently have no defined mechanism for this >> (do >> we need one?), but we know that once the process is complete, >> the new >> >> I think this is required for the ad hoc scenarios, isn't it? >> >> peer will have at least a P2PSIP Overlay Peer Key and a set of >> credentials. > > This is now in section 3.4.1, and has changed, but still says > > Peers are the full-function "routing and storage" nodes of a P2PSIP > Overlay. When a new peer is first created, it must enroll in the > P2PSIP Overlay. We currently have no defined mechanism for this > (should this group define one?), > > I would like stronger text, something like "and this is required > for P2PSIP > interoperation in at least some scenarios". The current text allows > us to > say "no, it's fine for us to leave this to vendor-specific > operation", so > users would have to use the right vendor's product to participate > in the > overlay - this is a big deal, but it's a bigger deal for ad hoc > scenarios > where you could walk into an overlay using enrollment from any vendor. Scott expressed some concerns with this, so I have just left this alone for now. > >> 3.3.2. More on The Difference Between a Peer, Client, and User Agent >> >> P2PSIP Overlay Peers directly interact with and contain the routing >> and storage fabric of the overlay. P2PSIP Overlay Clients just use >> the routing and storage facilities provided by the peers. The >> peers >> speak the P2PSIP Overlay Peer Protocol, which presumably has a full >> range of expressivity for the routing and storage facilities of the >> >> "expressivity" is a great word. Is it defined anywhere? ;-) > > Dean pointed out that expressivity is a real word, but I still > struggling > with the usage here. "Functionality"? The sentence now reads The peers speak the P2PSIP Peer Protocol, which can express all the necessary routing and storage operations required for the overlay. > >> overlay. Clients speak the P2PSIP Overlay Client protocol, >> which is >> presumably a subset of the peer protocol, and is limited to storage >> insertion (put), storage retrieval (get), and message routing >> (send). >> >> 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent >> >> To get started, users must be enrolled in the overlay. We do not >> have a process or protocol for this, nor are we certain we need a >> standardized mechanism. We presume that after enrollment, the user >> has a distinguished name within the overlay (example: >> sip:bob at example.com) and a set of credentials useful for >> authenticating its usage of the distinguished name. One possible >> mechanism for these credentials would be an x.509 certificate. It >> might also be possible to use a PGP key, a password, or some other >> mechanism. Presumably following enrollment, the user is also >> equipped with the information needed to connect to the overlay, >> such >> as the address of a bootstrap server. Whether this startup >> information is delivered as a part of enrollment of through some >> separate configuration process remains an open question. >> >> I would like to define this, but am concerned that the choice may >> differ >> per-overlay. Do others agree? > > The text moved to 3.4.3, and changed in 02. It is now > > Whether this startup > information is delivered as a part of enrollment of through some > separate configuration process remains an open question, and it is > not clear it is within the scope of the proposed WG. > > I would be concerned if at least the requirements for enrolling and > inserting users are out of scope for P2PSIP. Is this text saying > that P2PSIP > might not be chartered to develop the mechanism (I could agree) or > that > P2PSIP might not be chartered to specify requirements for this > mechanism, > whether it is developed in P2PSIP or in another appropriate working > group > (this is harder to accept)? This seems to be more of a charter issue than a document issue. I suggest bringing this up at the BOF. > >> 3.3.5. Bootstrapping >> >> If a client or peer is just starting up and has no knowledge of how >> to reach the other nodes of the overlay, it may exercise a >> bootstrap >> server to find one. Presumably it discovers the bootstrap >> server by >> some mechanism such as a DNS lookup, multicast, broadcast or >> configuration, then queries the bootstrap server and receives an >> address for a peer or set of peers that can be used to reach the >> overlay. Ideally, these target peers will be selected from a >> relatively large pool of peers that are currently online and >> reachable. >> >> This last sentence seems awfully use case-specific, doesn't it? > > This text is now in 3.4.5, but hasn't changed. The point I was > trying to > make in my notes was made more clearly by David Bryan in an e-mail > onlist: > > "One of the many reasons I am so keen on using pure SIP for the client > protocol is that if one bootstraping peer is overloaded, it can > simply 302 > (or perhaps 301 if it wants this requestor to keep using another peer) > incoming requests off to a less loaded peer." > > I think what the paragraph SHOULD say is, "Ideally, P2PSIP will > allow target > peer selection in a way that allows recovery from overload > situations". I have rewritten this section in light of the distinction between bootstrap peers and bootstrap servers. There is now a sentence that reads: Ideally, the mechanism for locating a bootstrap peer and handling a new peer or client will attempt to distribute the load evenly across the various nodes involved. > >> 4.9. Cryptotransparency >> >> When forwarding requests, are the bodies of the requests visible to >> peers? If so, this creates substantial security problems that the >> deployers of conventional SIP have been willing to mostly ignore. >> Can we make peers cryptotransparent (like HTTP proxies) when >> security >> is requested? >> >> I believe this question is key when we discuss what an endpoint is >> (see >> previous comments on whether clients are endpoints). > > This is now 4.6, but hasn't changed in 02. I am still confused > about the > expected trust model in a peer/UA-to-peer/UA dialog versus a > peer/UA-to-peer/UA-to-client/UA dialog (assuming that there are > only two > endpoints of the trust relationship, does the first peer/UA NOT > trust the > second peer/UA, or does the first peer/UA NOT trust the client/UA? > > I don't think we have to know the answer to this question to > charter the > working group, but I think we need to agree on whether it's an > interesting > question or not. I decided not to try to tackle this one in the -03 rev. Sorry. > >> 4.13. Bootstrapping >> >> We know that sometimes peers or clients will start up without >> knowledge of how to find a peer for insertion. Do we need to >> define >> a bootstrap mechanism or mechanisms? Do we need to define >> supporting >> protocols? >> >> I believe the answer to both of these is "yes" to support anything >> like ad >> hoc use cases. > > This is now 4.10, but the text has not changed. Again, I would like > stronger > text, something like, "Do we need to define a bootstrap mechanism, or > mechanisms, and do we need to define the supporting protocols? If > P2PSIP has > interoperability except at boot time, this means P2PSIP does not have > interoperability." Or something. Mumble. I have also rewritten this section. It now reads: We know that sometimes peers or clients will start up without knowledge of how to find a peer for insertion. In this case, what is the mechanism that a new peer or client uses to find a P2PSIP Bootstrap peer? > >> 4.16. Hybrid Domains >> >> It appears possible to have some hosts within a domain using >> conventional SIP and some using P2PSIP. This potentially raises a >> number of questions: 1) What should happen if we want to run a >> P2PSIP >> overlay in an existing SIP domain? 2) Do the existing redir/proxy >> servers need to be coupled with a peer layer? 3) When would an >> overlay peer want to discover them as opposed to looking in the >> overlay? 4) Is better not to run conventional SIP with overlay SIP? >> 5) When conventional and P2PSIP are run together, shall the >> existing >> redir servers keep their local databases or switch to the overlay >> storage. >> >> We've had some discussion on-list here about whether I have the >> same AOR >> in >> conventional SIP and P2PSIP overlays or not. Did we converge? > > Dean says, and I agree, that we have not converged. This text is > now 4.13, > but has not changed. Could we add a note something like > > "One related question is whether a UA could use the same AOR in > conventional > SIP and in P2PSIP. This isn't known yet, and the answer affects the > ability > of P2PSIP to support "hybrid domains" I added the sentence: A related question is whether a UA could use the same AOR in conventional SIP and in P2PSIP? - Philip From philip_matthews at magma.ca Sun Oct 22 15:59:24 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Sun, 22 Oct 2006 15:59:24 -0400 Subject: [p2p-sip] Version -03 of Concepts draft submitted Message-ID: Folks: I have just submitted a new version of the P2PSIP Concepts draft. Until it is available in the official archives, you can pick up a copy at www.magma.ca/~philip_matthews I am sure that David will also post a copy to his www.p2psip.org website shortly. Major changes from the -02 version: - Removed most of the alternate forms for terms. (A few are still called out in the text of the definition). - Split the concept of a P2PSIP Bootstrap Server and P2PSIP Bootstrap Peer, and rewrote the sections on bootstrapping to split these two concepts. - Noted that the names for many of the concepts are still under debate (e.,g., P2PSIP Client and P2PSIP Peer Insertion) - Noted that there is still a debate over the difference, if any, between user and resource. (The text in the document itself is somewhat inconsistent on this point). - Added a new section that discusses the Client and Peer Protocols and their differences. - Removed references to the "Send" operation, and added a note that the examples do not currently address the problem of sending to a peer or client behind a NAT. - Added a section on NAT Traversal to the Questions section - Added some text to make it clear that a client is strictly more limited than a peer, and that you can have a P2PSIP Overlay of just peers, but not one of just clients. I also made lots of other minor changes based on comments received. I have noted most of these in e-mails sent to the list in the past 4 days. - Philip From spencer at mcsr-labs.org Sun Oct 22 22:30:23 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Sun, 22 Oct 2006 21:30:23 -0500 Subject: [p2p-sip] Checking "My notes on draft-willis-p2psip-concepts-01" against version 02 References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <394401c6f212$63948a10$0300a8c0@china.huawei.com> <29A3071F-4A0A-4E5E-A18B-7354E44261B7@magma.ca> Message-ID: <01c401c6f64b$321820e0$0600a8c0@china.huawei.com> Hi, Philip, > Hi Spencer: > > I have addressed some of your concerns. > See inline. > > - Philip Most, I think (and it's not like the remaining concerns needed to be addressed in 03, either). Thanks for the work you did this week and weekend supporting the 03 revision. See inline. >> >> This is now "bootstrap peer". That's an improvement. > > As previously discussed, the document now make a distinction between > a bootstrap peer and a bootstrap server. I recognize that we are still in mid-thought here, but I'm still happy with where we are. >>> 3.3. Conceptual Outline of Operations >>> >>> 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer >> This is now in section 3.4.1, and has changed, but still says >> >> Peers are the full-function "routing and storage" nodes of a P2PSIP >> Overlay. When a new peer is first created, it must enroll in the >> P2PSIP Overlay. We currently have no defined mechanism for this >> (should this group define one?), >> >> I would like stronger text, something like "and this is required for >> P2PSIP >> interoperation in at least some scenarios". The current text allows us >> to >> say "no, it's fine for us to leave this to vendor-specific operation", >> so >> users would have to use the right vendor's product to participate in the >> overlay - this is a big deal, but it's a bigger deal for ad hoc >> scenarios >> where you could walk into an overlay using enrollment from any vendor. > > Scott expressed some concerns with this, so I have just left this alone > for now. Looking back onlist, I saw Scott's note that said > Regarding peer enrollment and user enrollment (below). Enrollment is > completely separate from the actual functioning of the P2P system, so > if we specify anything it should not be more than a default -- for > example configuration. There are so many possible mechanisms. I think Scott and I are in rough agreement here, we just ran out of time before the I-D cutoff, or we would have closed this one. I think we should specify a default, but there is no expectation that one size fits all, or even most - I agree, and don't think this will be a problem. >>> 3.3.2. More on The Difference Between a Peer, Client, and User Agent >> Dean pointed out that expressivity is a real word, but I still >> struggling >> with the usage here. "Functionality"? > > The sentence now reads > The peers speak the P2PSIP > Peer Protocol, which can express all the necessary routing and > storage operations > required for the overlay. Thanks - works fine for me. >>> 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent >> The text moved to 3.4.3, and changed in 02. It is now >> >> Whether this startup >> information is delivered as a part of enrollment of through some >> separate configuration process remains an open question, and it is >> not clear it is within the scope of the proposed WG. >> >> I would be concerned if at least the requirements for enrolling and >> inserting users are out of scope for P2PSIP. Is this text saying that >> P2PSIP >> might not be chartered to develop the mechanism (I could agree) or that >> P2PSIP might not be chartered to specify requirements for this >> mechanism, >> whether it is developed in P2PSIP or in another appropriate working >> group >> (this is harder to accept)? > > This seems to be more of a charter issue than a document issue. > I suggest bringing this up at the BOF. Umm, yeah. The document is talking about charter scope, which is slightly circular, and I'm also thinking you couldn't have fixed it yourself by the ID cutoff, so you made the right call. >> >>> 3.3.5. Bootstrapping >> This text is now in 3.4.5, but hasn't changed. The point I was trying to >> make in my notes was made more clearly by David Bryan in an e-mail >> onlist: >> >> "One of the many reasons I am so keen on using pure SIP for the client >> protocol is that if one bootstraping peer is overloaded, it can simply >> 302 >> (or perhaps 301 if it wants this requestor to keep using another peer) >> incoming requests off to a less loaded peer." >> >> I think what the paragraph SHOULD say is, "Ideally, P2PSIP will allow >> target >> peer selection in a way that allows recovery from overload situations". > > I have rewritten this section in light of the distinction between > bootstrap peers > and bootstrap servers. There is now a sentence that reads: > Ideally, the mechanism for locating a bootstrap peer and handling a new > peer or client > will attempt to distribute the load evenly across the various nodes > involved. After all of us have a chance to look over the revised draft, I'd suggest removing "evenly", but this is definitely headed the right direction. Again, thanks. >>> 4.9. Cryptotransparency >> This is now 4.6, but hasn't changed in 02. I am still confused about the >> expected trust model in a peer/UA-to-peer/UA dialog versus a >> peer/UA-to-peer/UA-to-client/UA dialog (assuming that there are only two >> endpoints of the trust relationship, does the first peer/UA NOT trust >> the >> second peer/UA, or does the first peer/UA NOT trust the client/UA? >> >> I don't think we have to know the answer to this question to charter the >> working group, but I think we need to agree on whether it's an >> interesting >> question or not. > > I decided not to try to tackle this one in the -03 rev. Sorry. Again, I don't see how you could have fixed this one on your own. During the telechat last week, I asked for, and got, assurances from people on the call that we can figure out how the trust relationship really works when we have a peer/UA communicating with a client/UA through a peer. Given that, we didn't need to work this out before chartering (don't need to solve the problem, just need to know it's solvable). You made the right call. >>> 4.13. Bootstrapping >> >> This is now 4.10, but the text has not changed. Again, I would like >> stronger >> text, something like, "Do we need to define a bootstrap mechanism, or >> mechanisms, and do we need to define the supporting protocols? If P2PSIP >> has >> interoperability except at boot time, this means P2PSIP does not have >> interoperability." Or something. Mumble. > > I have also rewritten this section. It now reads: > We know that sometimes peers or clients will start up without knowledge > of how to > find a peer for insertion. In this case, what is the mechanism > that a new peer or client uses to find > a P2PSIP Bootstrap peer? Captures my question. Thanks. When the draft cools off, we might s/sometimes/in some scenarios/, but this is good enough for now. >>> 4.16. Hybrid Domains >> Dean says, and I agree, that we have not converged. This text is now >> 4.13, >> but has not changed. Could we add a note something like >> >> "One related question is whether a UA could use the same AOR in >> conventional >> SIP and in P2PSIP. This isn't known yet, and the answer affects the >> ability >> of P2PSIP to support "hybrid domains" > > I added the sentence: > A related question is whether a UA could use the same AOR in > conventional > SIP and in P2PSIP? Captures my question. Thanks. > - Philip From swb at employees.org Sun Oct 22 23:37:27 2006 From: swb at employees.org (Scott W Brim) Date: Mon, 23 Oct 2006 05:37:27 +0200 Subject: [p2p-sip] Checking "My notes on draft-willis-p2psip-concepts-01" against version 02 In-Reply-To: <01c401c6f64b$321820e0$0600a8c0@china.huawei.com> References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <394401c6f212$63948a10$0300a8c0@china.huawei.com> <29A3071F-4A0A-4E5E-A18B-7354E44261B7@magma.ca> <01c401c6f64b$321820e0$0600a8c0@china.huawei.com> Message-ID: <20061023033727.GB4960@sbrim-wxp01> Excerpts from Spencer Dawkins on Sun, Oct 22, 2006 09:30:23PM -0500: > Looking back onlist, I saw Scott's note that said > > > Regarding peer enrollment and user enrollment (below). Enrollment > > is completely separate from the actual functioning of the P2P > > system, so if we specify anything it should not be more than a > > default -- for example configuration. There are so many possible > > mechanisms. > > I think Scott and I are in rough agreement here, we just ran out of > time before the I-D cutoff, or we would have closed this one. I > think we should specify a default, but there is no expectation that > one size fits all, or even most - I agree, and don't think this will > be a problem. If I hadn't run out of time myself I would have gone further and suggested that the text about minimum capabilities of the peer and client protocols should not include enrollment, since it could be completely orthogonal. See you soon ... Scott From lowekamp at cs.wm.edu Sun Oct 22 23:46:19 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Sun, 22 Oct 2006 23:46:19 -0400 Subject: [p2p-sip] draft-bryan-sipping-p2p-03 Message-ID: I've sent in draft-bryan-sipping-p2p-03. Until it is officially posted you can get a copy at http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.txt or http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.html major changes with this revision include: - new terminology from the concepts draft - many details have been fixed after implementation experience - the initial formation explanation is clearer with inclusion of the use of the null predecessor - a security model based on sip-identity is now used and the security section has been significantly revised - a detailed example describing the formation of a 3-node system is included Many thanks to everyone who sent us comments on the previous version. We've tried to include as many suggestions and corrections as possible. As usual, we welcome feedback either directly or to the list. Bruce From enrico.marocco at telecomitalia.it Mon Oct 23 04:11:06 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 23 Oct 2006 10:11:06 +0200 Subject: [p2p-sip] draft-bryan-sipping-p2p-03 In-Reply-To: References: Message-ID: <453C791A.7000802@telecomitalia.it> Bruce Lowekamp wrote: > I've sent in draft-bryan-sipping-p2p-03. Until it is officially > posted you can get a copy at > > http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.txt > or > http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.html > > major changes with this revision include: > > - new terminology from the concepts draft > - many details have been fixed after implementation experience > - the initial formation explanation is clearer with inclusion of the > use of the null predecessor > - a security model based on sip-identity is now used and the security > section has been significantly revised > - a detailed example describing the formation of a 3-node system is included Bruce: I like the new flavour brought by the official terminology :-) However I cannot still find a convincing description of the procedure for dealing with node failures. In our implementation, when a peer performing periodic stabilization detects his first successor's failure, it sends a third-party unregister to his second successor in behalf of the dead peer, casing the receiving peer to update his predecessor. In the current version of the draft I cannot find an analogous mechanism and I cannot understand how fault tolerance is achieved. Is it just me, or is it really an open issue? -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From lowekamp at cs.wm.edu Mon Oct 23 07:21:56 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Mon, 23 Oct 2006 07:21:56 -0400 Subject: [p2p-sip] draft-bryan-sipping-p2p-03 In-Reply-To: <453C791A.7000802@telecomitalia.it> References: <453C791A.7000802@telecomitalia.it> Message-ID: Enrico, I think one of the open issues is whether we should support a third-party unregister; actually, I don't think we should support that for security reasons, but we should support one peer telling another to check on the status of one of its neighbors because it received a 302 to a node that timed out. This winds up being intertwined with NAT/Firewall traversal---I think they should be the same signal because a peer can't really know why its message failed. So right now when a communication fails you resend your message to the node that timed out routed through the node that redirected you to that node. If you keep that node on the return path, it will know whether the node is still there or not. This is currently described in 9.7 and 9.8, although you're right that I didn't explain the link between them the way I should have. Bruce On 10/23/06, Enrico Marocco wrote: > Bruce Lowekamp wrote: > > I've sent in draft-bryan-sipping-p2p-03. Until it is officially > > posted you can get a copy at > > > > http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.txt > > or > > http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.html > > > > major changes with this revision include: > > > > - new terminology from the concepts draft > > - many details have been fixed after implementation experience > > - the initial formation explanation is clearer with inclusion of the > > use of the null predecessor > > - a security model based on sip-identity is now used and the security > > section has been significantly revised > > - a detailed example describing the formation of a 3-node system is included > > Bruce: I like the new flavour brought by the official terminology :-) > > However I cannot still find a convincing description of the procedure > for dealing with node failures. In our implementation, when a peer > performing periodic stabilization detects his first successor's failure, > it sends a third-party unregister to his second successor in behalf of > the dead peer, casing the receiving peer to update his predecessor. In > the current version of the draft I cannot find an analogous mechanism > and I cannot understand how fault tolerance is achieved. > > Is it just me, or is it really an open issue? > > -- > Ciao, > Enrico > > Ahem.. Sorry, the notice below is not my fault :-( > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > From enrico.marocco at telecomitalia.it Mon Oct 23 11:10:13 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 23 Oct 2006 17:10:13 +0200 Subject: [p2p-sip] draft-bryan-sipping-p2p-03 In-Reply-To: References: <453C791A.7000802@telecomitalia.it> Message-ID: <453CDB55.90404@telecomitalia.it> Bruce Lowekamp wrote: > I think one of the open issues is whether we should support a > third-party unregister; actually, I don't think we should support that > for security reasons, but we should support one peer telling another > to check on the status of one of its neighbors because it received a > 302 to a node that timed out. The advantage of a third-party unregistration mechanism is that it allows peer to atomically update their successor's predecessors. OTOH, I agree that it has many security issues. > This winds up being intertwined with NAT/Firewall traversal---I think > they should be the same signal because a peer can't really know why > its message failed. So right now when a communication fails you > resend your message to the node that timed out routed through the node > that redirected you to that node. If you keep that node on the return > path, it will know whether the node is still there or not. This is > currently described in 9.7 and 9.8, although you're right that I > didn't explain the link between them the way I should have. It would be useful to have a section describing what happens when a peer detects the failure of its successor and how its second successor updates the predecessor field. That is the most critical procedure, because the consistency of the DHT heavily depends on it. -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( -------------------------------------------------------------------- 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 -------------------------------------------------------------------- From eunsoo at research.panasonic.com Mon Oct 23 16:35:19 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 23 Oct 2006 16:35:19 -0400 Subject: [p2p-sip] draft-baset-sipping-p2pcommon-00 Message-ID: <453D2787.1050804@research.panasonic.com> Hi, Salman, Henning and I submitted the following draft. Your comments would be appreciated. Title: A Protocol for Implementing Various DHT Algorithms Abstract: This document defines DHT-independent and DHT-dependent features of DHT algorithms and presents a comparison of Chord, Pastry and Kademlia. It then describes key DHT operations and their information requirements. http://www.ietf.org/internet-drafts/draft-baset-sipping-p2pcommon-00.txt Thanks. Eunsoo From jani.hautakorpi at ericsson.com Wed Oct 25 03:38:49 2006 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Wed, 25 Oct 2006 10:38:49 +0300 Subject: [p2p-sip] New draft: Logical structure of a P2PSIP node Message-ID: <453F1489.7090706@ericsson.com> Hi all, We have put together a draft describing the logical structure of a P2PSIP peer and client. You can find it from: http://www.ietf.org/internet-drafts/draft-hautakorpi-structure-of-p2psip-node-00.txt Our intention is to help implementers to understand the logical structure of a P2PSIP node, and not to impose any particular structures/mechanisms. The draft is really a work-in-progress and we plan to develop it as our prototyping efforts advance. If you have any comments or input to the draft, please contact us. -- Jani From jiqingwu at gmail.com Thu Oct 26 10:04:48 2006 From: jiqingwu at gmail.com (jiqing wu) Date: Thu, 26 Oct 2006 22:04:48 +0800 Subject: [p2p-sip] Comments on concepts-02 Message-ID: <43c9b2df0610260704p7e22fe8i258b739eba07f86f@mail.gmail.com> >Node and peer definitions. >The concept draft considers 'peer' as an entity that participates in >the p2p network (routing decisions, storage) and equates 'peer' with a >'node'. >The peer typically means 'super node' in the unstructured P2P literature >and a 'node' in the DHT literature. >A 'node' encompasses both 'peer' and 'client' functionality in some >papers and architectures. See for example, "Understanding KaZaA" paper >where it is prefixed with 'super'-node and 'ordinary' node. >I think it will be helpful to make those distinctions a bit more clear in >the concepts draft. >Regards, >Salman decentralized and unstructured p2p systems have no supernode. To them,peer is equal to node. From br at brianrosen.net Fri Oct 27 11:16:54 2006 From: br at brianrosen.net (Brian Rosen) Date: Fri, 27 Oct 2006 11:16:54 -0400 Subject: [p2p-sip] Proposed Agenda - BO Message-ID: <066101c6f9da$f19f3f10$640fa8c0@cis.neustar.com> Proposed: IETF 67 San Diego Peer to Peer SIP (p2psip) BOF Agenda MONDAY, November 6, 2006 1520-1720 Afternoon Session II Grande Ballroom A?????? RAI???? p2p-sip Peer to Peer Support for Session Initiation Protocol BOF Chair(s): Brian Rosen David Bryan RAI Director(s): Jon Peterson jon.peterson at neustar.biz Cullen Jennings fluffy at cisco.com RAI Area Advisor: Cullen Jennings fluffy at cisco.com 1. Agenda Bash - 5 min - Chairs 2. Concepts and Terminology - 30 min (including discussion) - Dean Willis & Philip Matthews http://www.ietf.org/internet-drafts/draft-willis-p2psip-concepts-03.txt 3. Charter Discussion - 60 min - Chairs 4. Wrap Up - 5 min - chairs From bryan at ethernot.org Fri Oct 27 17:20:59 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 27 Oct 2006 17:20:59 -0400 Subject: [p2p-sip] IMPORTANT!!! Updated Charter Message-ID: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> Folks, I have reviewed the (thankfully fairly few) comments from late September on the charter, and made a few changes, reflecting concensus of those discussions and/or changes in terms used in the terminology draft (for example removing the leading "overlay" from "P2P overlay peer" and "P2P overlay client" in about 20 places to reflect the change in the terminology draft). The changes are minor overall and few, since the list seemed generally happy about the charter, but please look and make sure nothing that changed raises concerns. You can view the new version at the end of this message. I've also put it, along with the old version and .pdf showing the differences marked (just so folks can see exactly what changed) on p2psip.org: http://www.p2psip.org/ietf.php PLEASE take a look and make sure this charter is something that folks can get behind and hum approval to the question "Should a WG with substantially this charter be formed..." when we have the BOF, one week from Monday. If there are issues, now is the last chance to raise them! Thanks! David --- Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: TBD RAI Area Director(s): Cullen Jennings Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2p-sip at cs.columbia.edu Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ Description of the Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, or P2PSIP peers, rather than centralized servers as in client-server SIP as currently deployed. A number of cases where such an architecture is desirable have been documented in [1]. The terminology and concepts draft [2] explains the terms and concepts used here. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP opeers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP correspondent discovery process of RFC 3263. Session management, messaging, and presence functions are performed using traditional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized serves. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. A proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the client protocol is a syntactic subset of the peer protocol, and whether the client protocol has SIP based syntax. 4. An applicability statement. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a user, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users, without relying on centralized servers. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP created in these groups. The working group takes it as a fact that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. Similarly, the group will attempt not to make design decisions that preclude anonymous communications systems from being crafted using the protocols defined by this WG. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism locating users and resources. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with traditional SIP. Goals and Milestones Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Sep 2008 Submit P2PSIP overlay client protocol document to the IESG (Standards track) Sep 2008 Submit P2PSIP overlay peer protocol document to the IESG (Standards track) May 2009 Submit P2PSIP applicability statement to the IESG (Standards track) References [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer Session Initiation Protocol (P2PSIP)", draft-bryan-sipping-p2p-usecases (work-in-progress) [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts (work-in-progress) From hsinnrei at adobe.com Fri Oct 27 17:59:16 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Fri, 27 Oct 2006 14:59:16 -0700 Subject: [p2p-sip] IMPORTANT!!! Updated Charter In-Reply-To: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2214127D@namail5.corp.adobe.com> This is an excellent charter and there is only a minor nit: >3. Locating resources based on something other than URIs. In other > words, arbitrary search of attributes is out of scope, but locating > resources based on their URIs is in scope. Add the sentence (or something like it): Using URIs may or may not imply using the DNS or having a record in the DNS for the URI. My apology for the late nit. Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Friday, October 27, 2006 4:21 PM To: P2P-SIP Subject: [p2p-sip] IMPORTANT!!! Updated Charter Folks, I have reviewed the (thankfully fairly few) comments from late September on the charter, and made a few changes, reflecting concensus of those discussions and/or changes in terms used in the terminology draft (for example removing the leading "overlay" from "P2P overlay peer" and "P2P overlay client" in about 20 places to reflect the change in the terminology draft). The changes are minor overall and few, since the list seemed generally happy about the charter, but please look and make sure nothing that changed raises concerns. You can view the new version at the end of this message. I've also put it, along with the old version and .pdf showing the differences marked (just so folks can see exactly what changed) on p2psip.org: http://www.p2psip.org/ietf.php PLEASE take a look and make sure this charter is something that folks can get behind and hum approval to the question "Should a WG with substantially this charter be formed..." when we have the BOF, one week from Monday. If there are issues, now is the last chance to raise them! Thanks! David --- Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: TBD RAI Area Director(s): Cullen Jennings Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2p-sip at cs.columbia.edu Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ Description of the Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, or P2PSIP peers, rather than centralized servers as in client-server SIP as currently deployed. A number of cases where such an architecture is desirable have been documented in [1]. The terminology and concepts draft [2] explains the terms and concepts used here. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP opeers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP correspondent discovery process of RFC 3263. Session management, messaging, and presence functions are performed using traditional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized serves. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. A proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the client protocol is a syntactic subset of the peer protocol, and whether the client protocol has SIP based syntax. 4. An applicability statement. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a user, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users, without relying on centralized servers. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP created in these groups. The working group takes it as a fact that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. Similarly, the group will attempt not to make design decisions that preclude anonymous communications systems from being crafted using the protocols defined by this WG. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism locating users and resources. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with traditional SIP. Goals and Milestones Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Sep 2008 Submit P2PSIP overlay client protocol document to the IESG (Standards track) Sep 2008 Submit P2PSIP overlay peer protocol document to the IESG (Standards track) May 2009 Submit P2PSIP applicability statement to the IESG (Standards track) References [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer Session Initiation Protocol (P2PSIP)", draft-bryan-sipping-p2p-usecases (work-in-progress) [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts (work-in-progress) _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fwmiller at cornfed.com Sat Oct 28 01:00:40 2006 From: fwmiller at cornfed.com (Frank W. Miller) Date: Fri, 27 Oct 2006 23:00:40 -0600 Subject: [p2p-sip] New p2p voip protocol In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2214127D@namail5.corp.adobe.com> Message-ID: <200610280500.k9S50gK18600@celine.siteprotect.com> Greetings, I know this isn't SIP but it seems like the people here would have good opinions on the work. I've been working on a new VoIP protocol for quite some time now. It has come from many frustrations both in implementing and operating SIP clients. The work is not anywhere near completed but I feel like there is enough material now to give a reader a good sketch of what its about. A draft describing the protocol can be found at: http://www.cornfed.com/msp.txt I would be interested in any comments from anyone on it. I'm in the process of implementing as well. From the abstract: The Media Sessions Protocol unifies many of the best ideas associated with the current crop of Voice-over-IP (VoIP) and media protocols used in the Internet. MSP uses peer-to-peer location discovery and signaling and a centralized user identifcation authority similar to Skype. MSP uses encryption of all message traffic similar to Skype using key exchanges similar to ZRTP. MSP uses a NAT-friendly design based on a single transport address similar to IAX2. MSP uses a simplified text-based signaling protocol similar to SIP. MSP uses standard RTP for media transport. One comment I'd like to head off immediately is that there are very substantial differences in the way signaling message are formatted and passed than SIP. It is not intended to be backward compatible with SIP. Thanks FM From swb at employees.org Sat Oct 28 02:12:09 2006 From: swb at employees.org (Scott W Brim) Date: Sat, 28 Oct 2006 08:12:09 +0200 Subject: [p2p-sip] IMPORTANT!!! Updated Charter In-Reply-To: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> References: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> Message-ID: <20061028061203.GE6564@sbrim-wxp01> First, you missed an "o" -- search for "opeer". Second, > service of establishing and managing sessions is principally handled > by a collection of intelligent endpoints, or P2PSIP peers, I think you want to take "and managing" out of the first line. Compare you have below ... > P2PSIP overlay. P2PSIP clients and peers use the resolution > services of the peers as an alternative to the SIP correspondent > discovery process of RFC 3263. Session management, messaging, and > presence functions are performed using traditional SIP. Thanks. Scott From swb at employees.org Sat Oct 28 02:13:17 2006 From: swb at employees.org (Scott W Brim) Date: Sat, 28 Oct 2006 08:13:17 +0200 Subject: [p2p-sip] IMPORTANT!!! Updated Charter In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2214127D@namail5.corp.adobe.com> References: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D2214127D@namail5.corp.adobe.com> Message-ID: <20061028061317.GF6564@sbrim-wxp01> Excerpts from Henry Sinnreich on Fri, Oct 27, 2006 02:59:16PM -0700: > This is an excellent charter and there is only a minor nit: > > >3. Locating resources based on something other than URIs. In other > > words, arbitrary search of attributes is out of scope, but locating > > resources based on their URIs is in scope. > > Add the sentence (or something like it): Using URIs may or may not imply > using the DNS or having a record in the DNS for the URI. I like it, but "need not" is easier. From slavitch at gmail.com Sat Oct 28 11:16:14 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Sat, 28 Oct 2006 11:16:14 -0400 Subject: [p2p-sip] IMPORTANT!!! Updated Charter In-Reply-To: <20061028061317.GF6564@sbrim-wxp01> References: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D2214127D@namail5.corp.adobe.com> <20061028061317.GF6564@sbrim-wxp01> Message-ID: <1fc32c8f0610280816q618c6535l6a6627f8c59c3fbe@mail.gmail.com> The charter doc is excellent. Scott's editing perfects Henry's subtle but vital distinction. Great work, folks, and good luck in San Diego. Let's finally bag a Working Group and then some strong standards. The world is waiting. M PS: This landlocked sailor recommends some time on blue water while you're out there. The daysail charters on either side of the border are great. Green with envy. On 10/28/06, Scott W Brim wrote: > Excerpts from Henry Sinnreich on Fri, Oct 27, 2006 02:59:16PM -0700: > > This is an excellent charter and there is only a minor nit: > > > > >3. Locating resources based on something other than URIs. In other > > > words, arbitrary search of attributes is out of scope, but locating > > > resources based on their URIs is in scope. > > > > Add the sentence (or something like it): Using URIs may or may not imply > > using the DNS or having a record in the DNS for the URI. > > I like it, but "need not" is easier. > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Sat Oct 28 11:35:01 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Sat, 28 Oct 2006 11:35:01 -0400 Subject: [p2p-sip] IMPORTANT!!! Updated Charter In-Reply-To: <20061028061203.GE6564@sbrim-wxp01> References: <8b2769930610271420n7162e480w7fbac933bc34e5d4@mail.gmail.com> <20061028061203.GE6564@sbrim-wxp01> Message-ID: <454378A5.8040404@research.panasonic.com> Scott W Brim wrote: >First, you missed an "o" -- search for "opeer". > >Second, > > > >>service of establishing and managing sessions is principally handled >>by a collection of intelligent endpoints, or P2PSIP peers, >> >> > > > Since 'P2PSIP Peer' has a certain meaning, narrower than 'intelligent endpoint', For example, P2PSIP Clients are also such intelligent endpoints. One remedy may be just removing 'or P2PSIP peers' from the sentence. >I think you want to take "and managing" out of the first line. >Compare you have below ... > > > >>P2PSIP overlay. P2PSIP clients and peers use the resolution >>services of the peers as an alternative to the SIP correspondent >>discovery process of RFC 3263. Session management, messaging, and >>presence functions are performed using traditional SIP. >> >> > > > Thanks. Eunsoo From jiang.x.f at huawei.com Mon Oct 30 04:09:37 2006 From: jiang.x.f at huawei.com (JiangXingFeng) Date: Mon, 30 Oct 2006 17:09:37 +0800 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: Message-ID: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> Hi, Philip: I have read the version-3 of Concepts draft. A comment is prsented as follows: In definition of P2PSIP peer, there is a statement :"Each P2PSIP Peer may or may not be coupled to one or more P2PSIP User Agents". In my opinion, P2PSIP Peer may be coupled to various SIP entities, such as proxy server, redirect server, not only SIP User Agent. In Reference modle in this draft, proxy peer p and redirect peer r is coupled with the peer and has proxy or redirect functions. From the definition of P2PSIP User Agents, I think P2PSIP User Agents is a counterpart of SIP User Agents, which have no proxy and redirect functions. We can descibe the function of a peer by using the following diagram. There may be two statcks equiped in the P2PSIP Peer. One is SIP-related, and the other is P2P-related. In SIP protocol, different core (transcation user) which a SIP entity has decide the role of this entity. If it is equipped with proxy core, it acts as a proxy. From P2P perspective, the peer runs P2P Peer protocol. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction User | | +-+-+-+-+-+-+-+-+-+-+-+ | | Treanscation | Peer Protocol | +-+-+-+-+-+-+-+-+-+-+-+ | | Transport | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So my suggestion is to modify this statement to: "Each P2PSIP Peer may or may not be coupled to one or more P2PSIP User Agents, it may also be coupled to one SIP entities such as proxy server, redirect server, other than SIP User Agent". The definition of P2P Client has the same problem. Jiang XingFeng -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------------------------------------------------------------- > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews > Sent: Monday, October 23, 2006 3:59 AM > To: P2P-SIP > Cc: David A. Bryan > Subject: [p2p-sip] Version -03 of Concepts draft submitted > > Folks: > > I have just submitted a new version of the P2PSIP Concepts draft. > Until it is available in the official archives, you can pick up a > copy at > www.magma.ca/~philip_matthews > > I am sure that David will also post a copy to his www.p2psip.org > website shortly. > > Major changes from the -02 version: > - Removed most of the alternate forms for terms. > (A few are still called out in the text of the definition). > - Split the concept of a P2PSIP Bootstrap Server and P2PSIP Bootstrap > Peer, > and rewrote the sections on bootstrapping to split these two > concepts. > - Noted that the names for many of the concepts are still under debate > (e.,g., P2PSIP Client and P2PSIP Peer Insertion) > - Noted that there is still a debate over the difference, if any, > between user and resource. > (The text in the document itself is somewhat inconsistent on this > point). > - Added a new section that discusses the Client and Peer Protocols > and their differences. > - Removed references to the "Send" operation, and added a note that > the examples > do not currently address the problem of sending to a peer or > client behind a NAT. > - Added a section on NAT Traversal to the Questions section > - Added some text to make it clear that a client is strictly more > limited than a peer, > and that you can have a P2PSIP Overlay of just peers, but not one > of just clients. > > I also made lots of other minor changes based on comments received. > I have noted most of these in e-mails sent to the list in the past 4 > days. > > - Philip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From philip_matthews at magma.ca Mon Oct 30 09:41:31 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Mon, 30 Oct 2006 09:41:31 -0500 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> Message-ID: <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> On 30-Oct-06, at 04:09 , JiangXingFeng wrote: > Hi, Philip: > I have read the version-3 of Concepts draft. A comment is > prsented as > follows: > In definition of P2PSIP peer, there is a statement :"Each P2PSIP > Peer may or > may not be coupled to one or more P2PSIP User Agents". In my opinion, > P2PSIP Peer may be coupled to various SIP entities, such as proxy > server, > redirect server, not only SIP User Agent. > In Reference modle in this draft, proxy peer p and redirect > peer r is > coupled with the peer and has proxy or redirect functions. From the > definition of P2PSIP User Agents, I think P2PSIP User Agents is a > counterpart of SIP User Agents, which have no proxy and redirect > functions. > We can descibe the function of a peer by using the following > diagram. > There may be two statcks equiped in the P2PSIP Peer. One is SIP- > related, and > the other is P2P-related. In SIP protocol, different core > (transcation > user) which a SIP entity has decide the role of this entity. If it is > equipped with proxy core, it acts as a proxy. From P2P perspective, > the peer > runs P2P Peer protocol. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transaction User | | > +-+-+-+-+-+-+-+-+-+-+-+ | > | Treanscation | Peer Protocol | > +-+-+-+-+-+-+-+-+-+-+-+ | > | Transport | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TCP/IP | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > So my suggestion is to modify this statement to: "Each P2PSIP Peer > may or > may not be coupled to one or more P2PSIP User Agents, it may also > be coupled > to one SIP entities such as proxy server, redirect server, other > than SIP > User Agent". > > The definition of P2P Client has the same problem. > > Jiang XingFeng Thanks for your comment. In my opinion, this is an area where the concepts in the draft could be improved. What I think you are saying is that there is a "peer function" and that this can be optionally combined with one or more "SIP functions" (such as a SIP UA, SIP Redirect server, SIP Proxy server, etc). If so, then I agree with this statement. (However, I don't know what my co-authors think about this! ;-). We will see if we cannot improve this aspect of the draft in the next version. - Philip From dean.willis at softarmor.com Mon Oct 30 12:23:39 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 30 Oct 2006 11:23:39 -0600 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> Message-ID: <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> On Oct 30, 2006, at 8:41 AM, Philip Matthews wrote: > > Thanks for your comment. > In my opinion, this is an area where the concepts in the draft could > be improved. > > What I think you are saying is that there is a "peer function" and > that this can > be optionally combined with one or more "SIP functions" (such as a > SIP UA, > SIP Redirect server, SIP Proxy server, etc). > > If so, then I agree with this statement. > (However, I don't know what my co-authors think about this! ;-). > > We will see if we cannot improve this aspect of the draft in the next > version. > I'd go so far as to say we could couple either a P2PSIP "peer function" or a P2PSIP "client function" with one or more SIP functions (UA, proxy, redirector, registrar, SBC, whatever). If you couple a P2PSIP peer or client with a SIP UA, you might get a "phone". If you couple a P2PSIP peer or client to a SIP proxy and a SIP registrar, you might get a SIP to P2PSIP adaptation server that would look like a "home proxy" to a SIP UA. If you couple a P2PSIP peer or client to a SIP SBC, you might get a SIP SBC with a P2PSIP backend. -- Dean From eunsoo at research.panasonic.com Mon Oct 30 10:57:09 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Oct 2006 10:57:09 -0500 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> Message-ID: <454620D5.8020605@research.panasonic.com> You are right. Actually this was pointed out at the conference call a couple of weeks ago and agreed to be fixed as you suggested (using a similar expression). I guess somehow the fix was missed. :-( Thanks. Eunsoo JiangXingFeng wrote: >Hi, Philip: > I have read the version-3 of Concepts draft. A comment is prsented as >follows: >In definition of P2PSIP peer, there is a statement :"Each P2PSIP Peer may or >may not be coupled to one or more P2PSIP User Agents". In my opinion, >P2PSIP Peer may be coupled to various SIP entities, such as proxy server, >redirect server, not only SIP User Agent. > > > In Reference modle in this draft, proxy peer p and redirect peer r is >coupled with the peer and has proxy or redirect functions. From the >definition of P2PSIP User Agents, I think P2PSIP User Agents is a >counterpart of SIP User Agents, which have no proxy and redirect functions. > We can descibe the function of a peer by using the following diagram. >There may be two statcks equiped in the P2PSIP Peer. One is SIP-related, and >the other is P2P-related. In SIP protocol, different core (transcation >user) which a SIP entity has decide the role of this entity. If it is >equipped with proxy core, it acts as a proxy. From P2P perspective, the peer >runs P2P Peer protocol. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transaction User | | > +-+-+-+-+-+-+-+-+-+-+-+ | > | Treanscation | Peer Protocol | > +-+-+-+-+-+-+-+-+-+-+-+ | > | Transport | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TCP/IP | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >So my suggestion is to modify this statement to: "Each P2PSIP Peer may or >may not be coupled to one or more P2PSIP User Agents, it may also be coupled >to one SIP entities such as proxy server, redirect server, other than SIP >User Agent". > >The definition of P2P Client has the same problem. > >Jiang XingFeng >-------------------------------------------------------------------- > >CONFIDENTIALITY NOTICE > >This e-mail and its attachments contain confidential information from >HUAWEI, which is intended only for the person or entity whose address is >listed above. Any use of the information contained herein in any way >(including, but not limited to, total or partial disclosure, reproduction, >or dissemination) by persons other than the intended recipient(s) is >prohibited. If you receive this e-mail in error, please notify the sender by >phone or email immediately and delete it! > >-------------------------------------------------------------------- > > >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews >>Sent: Monday, October 23, 2006 3:59 AM >>To: P2P-SIP >>Cc: David A. Bryan >>Subject: [p2p-sip] Version -03 of Concepts draft submitted >> >>Folks: >> >>I have just submitted a new version of the P2PSIP Concepts draft. >>Until it is available in the official archives, you can pick up a >>copy at >> www.magma.ca/~philip_matthews >> >>I am sure that David will also post a copy to his www.p2psip.org >>website shortly. >> >>Major changes from the -02 version: >>- Removed most of the alternate forms for terms. >> (A few are still called out in the text of the definition). >>- Split the concept of a P2PSIP Bootstrap Server and P2PSIP Bootstrap >>Peer, >> and rewrote the sections on bootstrapping to split these two >>concepts. >>- Noted that the names for many of the concepts are still under debate >> (e.,g., P2PSIP Client and P2PSIP Peer Insertion) >>- Noted that there is still a debate over the difference, if any, >>between user and resource. >> (The text in the document itself is somewhat inconsistent on this >>point). >>- Added a new section that discusses the Client and Peer Protocols >>and their differences. >>- Removed references to the "Send" operation, and added a note that >>the examples >> do not currently address the problem of sending to a peer or >>client behind a NAT. >>- Added a section on NAT Traversal to the Questions section >>- Added some text to make it clear that a client is strictly more >>limited than a peer, >> and that you can have a P2PSIP Overlay of just peers, but not one >>of just clients. >> >>I also made lots of other minor changes based on comments received. >>I have noted most of these in e-mails sent to the list in the past 4 >>days. >> >>- Philip >> >> >> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> > > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From hsinnrei at adobe.com Mon Oct 30 13:46:29 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Mon, 30 Oct 2006 10:46:29 -0800 Subject: [p2p-sip] draft-baset-sipping-p2pcommon-00 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141286@namail5.corp.adobe.com> The proposed DHT protocol in "A Protocol for Implementing Various DHT Algorithms" does not have a corresponding DHT operation (API) for handling delay information. Should delay not be the most important metric for neighbor node selection, used among other for selecting media relays and proxies? Related to this, the Internet-Draft does not include the Bamboo algorithm used in the openDHT system; http://www.bamboo-dht.org/ Bamboo seems however to be the most interesting algorithm, among other reasons since it has proximity neighbor selection based on delay and has been designed for better handling churn in membership. Is there a reason for not including Bamboo in the DHT algorithm comparison and if so, what may it be? I understand though that other DHT algorithms such as Chord have also recently added proximity neighbor selection based on delay. Is this true? If yes, the info in the draft should be updated. Thanks, Henry Sinnreich From eunsoo at research.panasonic.com Mon Oct 30 16:02:13 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Oct 2006 16:02:13 -0500 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> Message-ID: <45466855.7030702@research.panasonic.com> Dean Willis wrote: >On Oct 30, 2006, at 8:41 AM, Philip Matthews wrote: > > > >>Thanks for your comment. >>In my opinion, this is an area where the concepts in the draft could >>be improved. >> >>What I think you are saying is that there is a "peer function" and >>that this can >>be optionally combined with one or more "SIP functions" (such as a >>SIP UA, >>SIP Redirect server, SIP Proxy server, etc). >> >>If so, then I agree with this statement. >>(However, I don't know what my co-authors think about this! ;-). >> >>We will see if we cannot improve this aspect of the draft in the next >>version. >> >> >> > >I'd go so far as to say we could couple either a P2PSIP "peer >function" or a P2PSIP "client function" with one or more SIP >functions (UA, proxy, redirector, registrar, SBC, whatever). > >If you couple a P2PSIP peer or client with a SIP UA, you might get a >"phone". > >If you couple a P2PSIP peer or client to a SIP proxy and a SIP >registrar, you might get a SIP to P2PSIP adaptation server that would >look like a "home proxy" to a SIP UA. > >If you couple a P2PSIP peer or client to a SIP SBC, you might get a >SIP SBC with a P2PSIP backend. > >- > Wow, this is a good illustration. I like it. Thanks. Eunsoo From swb at employees.org Mon Oct 30 16:43:21 2006 From: swb at employees.org (Scott W Brim) Date: Mon, 30 Oct 2006 22:43:21 +0100 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> Message-ID: <20061030214321.GE360@sbrim-wxp01> Excerpts from Dean Willis on Mon, Oct 30, 2006 11:23:39AM -0600: > I'd go so far as to say we could couple either a P2PSIP "peer > function" or a P2PSIP "client function" with one or more SIP > functions (UA, proxy, redirector, registrar, SBC, whatever). > > If you couple a P2PSIP peer or client with a SIP UA, you might get a > "phone". > > If you couple a P2PSIP peer or client to a SIP proxy and a SIP > registrar, you might get a SIP to P2PSIP adaptation server that would > look like a "home proxy" to a SIP UA. > > If you couple a P2PSIP peer or client to a SIP SBC, you might get a > SIP SBC with a P2PSIP backend. Would the P2PSIP component need to have any idea what was using it? From eunsoo at research.panasonic.com Mon Oct 30 18:09:40 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Oct 2006 18:09:40 -0500 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <20061030214321.GE360@sbrim-wxp01> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> <20061030214321.GE360@sbrim-wxp01> Message-ID: <45468634.8070008@research.panasonic.com> Scott W Brim wrote: >Excerpts from Dean Willis on Mon, Oct 30, 2006 11:23:39AM -0600: > > >>I'd go so far as to say we could couple either a P2PSIP "peer >>function" or a P2PSIP "client function" with one or more SIP >>functions (UA, proxy, redirector, registrar, SBC, whatever). >> >>If you couple a P2PSIP peer or client with a SIP UA, you might get a >>"phone". >> >>If you couple a P2PSIP peer or client to a SIP proxy and a SIP >>registrar, you might get a SIP to P2PSIP adaptation server that would >>look like a "home proxy" to a SIP UA. >> >>If you couple a P2PSIP peer or client to a SIP SBC, you might get a >>SIP SBC with a P2PSIP backend. >> >> > >Would the P2PSIP component need to have any idea what was using it? > > I guess you mean P2PSIP Peer and Client by 'P2PSIP component'. Then my answer is 'NO'. No matter what is using it, the P2PSIP Peer or Client module/component will provide the same functionality. Thanks. Eunsoo From jiang.x.f at huawei.com Mon Oct 30 20:41:49 2006 From: jiang.x.f at huawei.com (JiangXingFeng) Date: Tue, 31 Oct 2006 09:41:49 +0800 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <45468634.8070008@research.panasonic.com> Message-ID: <000001c6fc8d$bbe31e90$7205a40a@china.huawei.com> I agree with Eunsoo. Whether Peer functions or Client functions in P2PSIP is to provide a method to store and lookup information in the P2PSIP Overlay. Peer functions or client functions are exercised by SIP entities, including SIP User Agent, Proxy server, Redirect Server. A Peer need not to know which SIP functions coexist with the Peer functions. So does a client. The Peer functions or Client functions is independent of the SIP functions which a peer or a client has. Best regards JiangXingFeng Eunsoo wrote: > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim > Sent: Tuesday, October 31, 2006 7:10 AM > To: Scott W Brim > Cc: 'P2P-SIP' > Subject: Re: [p2p-sip] Version -03 of Concepts draft submitted > > Scott W Brim wrote: > > >Excerpts from Dean Willis on Mon, Oct 30, 2006 11:23:39AM -0600: > > > > > >>I'd go so far as to say we could couple either a P2PSIP "peer > >>function" or a P2PSIP "client function" with one or more SIP > >>functions (UA, proxy, redirector, registrar, SBC, whatever). > >> > >>If you couple a P2PSIP peer or client with a SIP UA, you might get a > >>"phone". > >> > >>If you couple a P2PSIP peer or client to a SIP proxy and a SIP > >>registrar, you might get a SIP to P2PSIP adaptation server that would > >>look like a "home proxy" to a SIP UA. > >> > >>If you couple a P2PSIP peer or client to a SIP SBC, you might get a > >>SIP SBC with a P2PSIP backend. > >> > >> > > > >Would the P2PSIP component need to have any idea what was using it? > > > > > I guess you mean P2PSIP Peer and Client by 'P2PSIP component'. > Then my answer is 'NO'. > No matter what is using it, the P2PSIP Peer or Client module/component > will provide the same functionality. > Thanks. > > Eunsoo From ekr at networkresonance.com Mon Oct 30 20:51:42 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Mon, 30 Oct 2006 17:51:42 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 Message-ID: <20061031015443.7CEB45C01E@laser.networkresonance.com> $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $ GENERAL COMMENTS Overall, this document is pretty good, however I think the bit about the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of confusing. I definitely agree that there will be two kinds of nodes - Those which store other people's state data. - Those which don't. The terms you've chosen (Peers and Clients) seem to be as good as any for this purpose. With that said, there are three basic designs: 1. Clients understand the overlay network, they just don't store data. To take a concrete example from Chord, there's no reason you can't connect to a Chord node, suck down an appropriate finger/routing table and then send messages to other Chord nodes just as if you were a Peer. The only thing you don't do is *register* with the network. 2. Clients don't understand the overlay network, they just treat some subset of peers as servers to which they can do gets/puts. This is roughly the architecture that OpenDHT implements now. 3. Clients don't understand the overlay network and just treat it as one big clustered SIP server. I think the intention here is for this document to be agnostic between these three designs (and if it's not, it should be) but I don't think it does that that well in a number of cases. In particular, the question of whether the client protocol should be SIP sort of confuses two questions: the fundamental architectural issue above with the detail of wire encoding. DETAILED COMMENTS S 2. P2PSIP Client: A node participating in a P2PSIP Overlay that provides neither routing nor route storage and retrieval functions to that P2PSIP Overlay. The P2PSIP Client interacts with the P2PSIP Overlay by having an association (details TBD) with one or more P2PSIP peers. This wouldn't be that accurate a description of case (1) above, since there isn't an association with any peers. You just have a routing table and contact whoever is appropriate. P2PSIP Resource-ID: A non-human friendly value that uniquely determines which P2PSIP Peer is responsible for storing information about this resource (user). Well, "uniquely" isn't right here since most such schemes replicate for high availability. P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients and the P2PSIP Peer they use to store or retrieve information from the P2P Overlay. Who says there's just one? See above. is expected to be a principle topic of the detailed design work. s/principle/principal/ S 3.5.2. P2PSIP Peers directly interact with and contain the routing and storage fabric of the overlay. P2PSIP Clients simply use the routing and storage facilities provided by the peers to get and put information. The peers speak the P2PSIP Peer Protocol, which can express all the necessary routing and storage operations required for the overlay. Clients speak the P2PSIP Client protocol, which is presumably a subset of the peer protocol, and is limited to storage insertion (put) and storage retrieval (get). Some designs do not require a separate client protocol. If it's SIP, I don't see how it's a subset of the peer protocol. S 3.5.3. To get started, users must be enrolled in the overlay. We do not have a process or protocol for this, nor are we certain we need a standardized mechanism. We presume that after enrollment, the user has a distinguished name within the overlay (example: Don't use "distinguished name" here. It's a technical term from PKIX and it doesn't mean this. "unique name"? S 4.5. When forwarding requests, are the bodies of the requests visible to peers? If so, this creates substantial security problems that the deployers of conventional SIP have been willing to mostly ignore. Can we make peers cryptotransparent (like HTTP proxies) when security is requested? I don't think I understand what "cryptotransparent" means, and since HTTP proxies operate in a bunch of different modes, some quite transparent and some quite invasive. Maybe just rename this to "security of requests" and remove the last sentence? -Ekr From eunsoo at research.panasonic.com Mon Oct 30 21:53:42 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Oct 2006 21:53:42 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <20061031015443.7CEB45C01E@laser.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> Message-ID: <4546BAB6.2020606@research.panasonic.com> Thanks for the comments. Just let me quickly provide my thought on the first comment since it seems a quite significant point. Eric Rescorla wrote: >$Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $ > >GENERAL COMMENTS >Overall, this document is pretty good, however I think the bit about >the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of >confusing. > >I definitely agree that there will be two kinds of nodes > >- Those which store other people's state data. >- Those which don't. > > > I think whether a node participates in the routing in the overlay network is a more important point distinguishing Peers from Clients. So the concept draft assumes two kinds of nodes: - Those which route messages and store data for other nodes. - Those which don't either. >The terms you've chosen (Peers and Clients) seem to be as good as any >for this purpose. > >With that said, there are three basic designs: > > > >1. Clients understand the overlay network, they just don't > store data. To take a concrete example from Chord, there's > no reason you can't connect to a Chord node, suck down an > appropriate finger/routing table and then send messages > to other Chord nodes just as if you were a Peer. The > only thing you don't do is *register* with the network. > > > I guess you mean 'joining the overlay network' by 'register with the network'. Then, this design does not conflict with the concept presented in the draft. I don't know about other authors but at least I did not think of this design. I think this design is possible but the Clients do not need to understand the overlay algorithm or the routing tables. >2. Clients don't understand the overlay network, they just > treat some subset of peers as servers to which they can > do gets/puts. This is roughly the architecture that OpenDHT > implements now. > > > This is precisely what was assumed at least in my mind. >3. Clients don't understand the overlay network and just treat > it as one big clustered SIP server. > > > To be more precise, one can consider the overlay network as a big clustered LOCATION SERVER and STORAGE but not SIP proxy, SIP registrar or SIP redirect server. In that sense, it seems to me that design #3 is just a different expression of design #2. >I think the intention here is for this document to be agnostic between >these three designs (and if it's not, it should be) but I don't think >it does that that well in a number of cases. > I thought the design #2 was clear and good enough. Other designs are also valid views but wouldn't it make the concept more clear if we focus on and stick with design #2? >In particular, >the question of whether the client protocol should be SIP sort >of confuses two questions: the fundamental architectural issue >above with the detail of wire encoding. > > > > Please let me get to the comments below later. Thanks. Eunsoo >DETAILED COMMENTS >S 2. > P2PSIP Client: A node participating in a P2PSIP Overlay that > provides neither routing nor route storage and retrieval functions > to that P2PSIP Overlay. The P2PSIP Client interacts with the > P2PSIP Overlay by having an association (details TBD) with one or > more P2PSIP peers. > >This wouldn't be that accurate a description of case (1) above, since >there isn't an association with any peers. You just have a routing >table and contact whoever is appropriate. > > > P2PSIP Resource-ID: A non-human friendly value that uniquely > determines which P2PSIP Peer is responsible for storing > information about this resource (user). > >Well, "uniquely" isn't right here since most such schemes replicate >for high availability. > > P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients > and the P2PSIP Peer they use to store or retrieve information from > the P2P Overlay. > >Who says there's just one? See above. > > > is expected to be a principle topic of the detailed design work. > >s/principle/principal/ > > >S 3.5.2. > P2PSIP Peers directly interact with and contain the routing and > storage fabric of the overlay. P2PSIP Clients simply use the routing > and storage facilities provided by the peers to get and put > information. The peers speak the P2PSIP Peer Protocol, which can > express all the necessary routing and storage operations required for > the overlay. Clients speak the P2PSIP Client protocol, which is > presumably a subset of the peer protocol, and is limited to storage > insertion (put) and storage retrieval (get). Some designs do not > require a separate client protocol. > >If it's SIP, I don't see how it's a subset of the peer protocol. > > >S 3.5.3. > To get started, users must be enrolled in the overlay. We do not > have a process or protocol for this, nor are we certain we need a > standardized mechanism. We presume that after enrollment, the user > has a distinguished name within the overlay (example: > >Don't use "distinguished name" here. It's a technical term from >PKIX and it doesn't mean this. "unique name"? > >S 4.5. > > When forwarding requests, are the bodies of the requests visible to > peers? If so, this creates substantial security problems that the > deployers of conventional SIP have been willing to mostly ignore. > Can we make peers cryptotransparent (like HTTP proxies) when security > is requested? > >I don't think I understand what "cryptotransparent" means, and since >HTTP proxies operate in a bunch of different modes, some quite transparent >and some quite invasive. Maybe just rename this to "security of requests" >and remove the last sentence? > >-Ekr > > > > > > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From spencer at mcsr-labs.org Mon Oct 30 22:01:53 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 30 Oct 2006 21:01:53 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 References: <20061031015443.7CEB45C01E@laser.networkresonance.com> Message-ID: <02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com> Hi, Eric, > $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr > Exp $ > > GENERAL COMMENTS > Overall, this document is pretty good, however I think the bit about > the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of > confusing. > > I definitely agree that there will be two kinds of nodes > > - Those which store other people's state data. > - Those which don't. > > The terms you've chosen (Peers and Clients) seem to be as good as any > for this purpose. I'm still not happy with the combination of terms ("a Client-Peer architecture" should confuse anyone who has done protocol design since 1980), but they certainly seem to be less worse than most :-) I understand that we've tabled the choice of names while we nail down rough functionality. If I got this wrong, someone please say so. > With that said, there are three basic designs: > > 1. Clients understand the overlay network, they just don't > store data. To take a concrete example from Chord, there's > no reason you can't connect to a Chord node, suck down an > appropriate finger/routing table and then send messages > to other Chord nodes just as if you were a Peer. The > only thing you don't do is *register* with the network. > > 2. Clients don't understand the overlay network, they just > treat some subset of peers as servers to which they can > do gets/puts. This is roughly the architecture that OpenDHT > implements now. > > 3. Clients don't understand the overlay network and just treat > it as one big clustered SIP server. > > I think the intention here is for this document to be agnostic between > these three designs (and if it's not, it should be) but I don't think Could you say more about "and if it's not, it should be"? Is this a question about whether we would find each design useful in at least one P2PSIP use case, or are you saying we should allow for all three designs because they cover the waterfront on possible designs? > it does that that well in a number of cases. In particular, > the question of whether the client protocol should be SIP sort > of confuses two questions: the fundamental architectural issue > above with the detail of wire encoding. I agree with this concern. We've changed a fair amount of text fairly quickly, so it's probably still catching on internal consistency in a few places. It's just so easy to say "but if SIP is the client protocol, designs two and three are more or less the same". > DETAILED COMMENTS > > S 3.5.2. > P2PSIP Peers directly interact with and contain the routing and > storage fabric of the overlay. P2PSIP Clients simply use the routing > and storage facilities provided by the peers to get and put > information. The peers speak the P2PSIP Peer Protocol, which can > express all the necessary routing and storage operations required for > the overlay. Clients speak the P2PSIP Client protocol, which is > presumably a subset of the peer protocol, and is limited to storage > insertion (put) and storage retrieval (get). Some designs do not > require a separate client protocol. > > If it's SIP, I don't see how it's a subset of the peer protocol. I asked the same question earlier, and the answer at the time was that "subset" was talking about protocol functionality, not about a protocol specification that subsets another protocol specification. > S 4.5. > > When forwarding requests, are the bodies of the requests visible to > peers? If so, this creates substantial security problems that the > deployers of conventional SIP have been willing to mostly ignore. > Can we make peers cryptotransparent (like HTTP proxies) when security > is requested? > > I don't think I understand what "cryptotransparent" means, and since > HTTP proxies operate in a bunch of different modes, some quite transparent > and some quite invasive. Maybe just rename this to "security of requests" > and remove the last sentence? I confess to having been assimilated here. The word sort of made sense to me, and I "understood" the section, for some value of the word "understood". When I actually read the words in this section, I am slightly confused between concerns about whether - third party can tell there was a request, and what the request was, and read the request body - third party can tell there was a request, and what the request was, but can't read the request body - third party can tell there was a request, but can't tell what the request was, or - third party can't tell there was a request What was the question we were asking here? I don't think the third alternative is interesting, but can imagine that the others might be. The text seems to be talking specifically about request BODIES, and Eric is interpreting this as "security of requests", which seems broader. Thanks, Spencer From ekr at networkresonance.com Mon Oct 30 22:06:40 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Mon, 30 Oct 2006 19:06:40 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <4546BAB6.2020606@research.panasonic.com> (Eunsoo Shim's message of "Mon, 30 Oct 2006 21:53:42 -0500") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <4546BAB6.2020606@research.panasonic.com> Message-ID: <86odrt420v.fsf@raman.networkresonance.com> Eunsoo Shim writes: > Thanks for the comments. > Just let me quickly provide my thought on the first comment since it > seems a quite significant point. > > Eric Rescorla wrote: > >>$Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $ >> >>GENERAL COMMENTS >>Overall, this document is pretty good, however I think the bit about >>the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of >>confusing. >> >>I definitely agree that there will be two kinds of nodes >> >>- Those which store other people's state data. >>- Those which don't. >> >> >> > I think whether a node participates in the routing in the overlay > network is a more important point distinguishing Peers from Clients. > > So the concept draft assumes two kinds of nodes: > - Those which route messages and store data for other nodes. > - Those which don't either. Sure. In nearly every system I'm familiar with, the set of nodes which route messages is the same as the set of nodes which stores data. >>The terms you've chosen (Peers and Clients) seem to be as good as any >>for this purpose. >> >>With that said, there are three basic designs: >> >> >> >>1. Clients understand the overlay network, they just don't >> store data. To take a concrete example from Chord, there's >> no reason you can't connect to a Chord node, suck down an >> appropriate finger/routing table and then send messages >> to other Chord nodes just as if you were a Peer. The >> only thing you don't do is *register* with the network. >> >> >> > I guess you mean 'joining the overlay network' by 'register with the > network'. I mean that you don't take on a section of the data space or agree to route packets. > Then, this design does not conflict with the concept presented in the draft. > I don't know about other authors but at least I did not think of this > design. > I think this design is possible but the Clients do not need to > understand the overlay algorithm or the routing tables. Sorry? In this design they *do* need to understand the overlay algorithm. But that's not necessarily a bug. For instance, it's likely to have superior load spreading properties, since you don't need to find some way to load balance over the Peers who are willing to talk to Clients. >>2. Clients don't understand the overlay network, they just >> treat some subset of peers as servers to which they can >> do gets/puts. This is roughly the architecture that OpenDHT >> implements now. >> >> >> > This is precisely what was assumed at least in my mind. > >>3. Clients don't understand the overlay network and just treat >> it as one big clustered SIP server. >> >> >> > To be more precise, one can consider the overlay network as a big > clustered LOCATION SERVER and STORAGE but not SIP proxy, SIP registrar > or SIP redirect server. In that sense, it seems to me that design #3 is > just a different expression of design #2. Topologically, yes, but not necessarily in other ways. For starters, it begins to imply that you have to do a whole bunch of SIP things that are potentially more complicated than just store and retrieve data. >>I think the intention here is for this document to be agnostic between >>these three designs (and if it's not, it should be) but I don't think >>it does that that well in a number of cases. >> > I thought the design #2 was clear and good enough. Other designs are > also valid views but wouldn't it make the concept more clear if we focus > on and stick with design #2? Well, no, because it tends to lock design (1) out of the discussion, and since it's not like any actual conclusion has been reached on that point, it's premature. -Ekr From ekr at networkresonance.com Mon Oct 30 22:10:28 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Mon, 30 Oct 2006 19:10:28 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com> (Spencer Dawkins's message of "Mon, 30 Oct 2006 21:01:53 -0600") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com> Message-ID: <868xix41uj.fsf@raman.networkresonance.com> "Spencer Dawkins" writes: > Hi, Eric, > >> $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr >> Exp $ >> >> GENERAL COMMENTS >> Overall, this document is pretty good, however I think the bit about >> the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of >> confusing. >> >> I definitely agree that there will be two kinds of nodes >> >> - Those which store other people's state data. >> - Those which don't. >> >> The terms you've chosen (Peers and Clients) seem to be as good as any >> for this purpose. > > I'm still not happy with the combination of terms ("a Client-Peer > architecture" should confuse anyone who has done protocol design since > 1980), but they certainly seem to be less worse than most :-) > > I understand that we've tabled the choice of names while we nail down rough > functionality. If I got this wrong, someone please say so. That's my understanding as well. I'm OK with calling them Foo and Bar. >> I think the intention here is for this document to be agnostic between >> these three designs (and if it's not, it should be) but I don't think > > Could you say more about "and if it's not, it should be"? Is this a question > about whether we would find each design useful in at least one P2PSIP use > case, or are you saying we should allow for all three designs because they > cover the waterfront on possible designs? I'm saying that it's premature to decide on a single architecture, at this time and in each document. That's a topic to be decided *after* the WG is formed. >> DETAILED COMMENTS >> >> S 3.5.2. >> P2PSIP Peers directly interact with and contain the routing and >> storage fabric of the overlay. P2PSIP Clients simply use the routing >> and storage facilities provided by the peers to get and put >> information. The peers speak the P2PSIP Peer Protocol, which can >> express all the necessary routing and storage operations required for >> the overlay. Clients speak the P2PSIP Client protocol, which is >> presumably a subset of the peer protocol, and is limited to storage >> insertion (put) and storage retrieval (get). Some designs do not >> require a separate client protocol. >> >> If it's SIP, I don't see how it's a subset of the peer protocol. > > I asked the same question earlier, and the answer at the time was that > "subset" was talking about protocol functionality, not about a protocol > specification that subsets another protocol specification. Maybe some editorial work is in order here, then :) >> S 4.5. >> >> When forwarding requests, are the bodies of the requests visible to >> peers? If so, this creates substantial security problems that the >> deployers of conventional SIP have been willing to mostly ignore. >> Can we make peers cryptotransparent (like HTTP proxies) when security >> is requested? >> >> I don't think I understand what "cryptotransparent" means, and since >> HTTP proxies operate in a bunch of different modes, some quite transparent >> and some quite invasive. Maybe just rename this to "security of requests" >> and remove the last sentence? > > I confess to having been assimilated here. The word sort of made sense to > me, and I "understood" the section, for some value of the word "understood". > When I actually read the words in this section, I am slightly confused > between concerns about whether > > - third party can tell there was a request, and what the request was, and > read the request body > > - third party can tell there was a request, and what the request was, but > can't read the request body > > - third party can tell there was a request, but can't tell what the request > was, or > > - third party can't tell there was a request > > What was the question we were asking here? I don't think the third > alternative is interesting, but can imagine that the others might be. The > text seems to be talking specifically about request BODIES, and Eric is > interpreting this as "security of requests", which seems broader. Until we know what format requests are in, I'm not sure how we know what are bodies and what aren't. I.e., are we just talking about the SIP messages or about the P2PSIP Peer Protocol, which we don't even know has bodies.... -Ekr From eunsoo at research.panasonic.com Mon Oct 30 23:11:58 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Oct 2006 23:11:58 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <86odrt420v.fsf@raman.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <4546BAB6.2020606@research.panasonic.com> <86odrt420v.fsf@raman.networkresonance.com> Message-ID: <4546CD0E.4000000@research.panasonic.com> Eric Rescorla wrote: >Eunsoo Shim writes: > > > >>Thanks for the comments. >>Just let me quickly provide my thought on the first comment since it >>seems a quite significant point. >> >>Eric Rescorla wrote: >> >> >> >>>$Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $ >>> >>>GENERAL COMMENTS >>>Overall, this document is pretty good, however I think the bit about >>>the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of >>>confusing. >>> >>>I definitely agree that there will be two kinds of nodes >>> >>>- Those which store other people's state data. >>>- Those which don't. >>> >>> >>> >>> >>> >>I think whether a node participates in the routing in the overlay >>network is a more important point distinguishing Peers from Clients. >> >>So the concept draft assumes two kinds of nodes: >>- Those which route messages and store data for other nodes. >>- Those which don't either. >> >> > >Sure. In nearly every system I'm familiar with, the set of >nodes which route messages is the same as the set of nodes >which stores data. > > > > >>>The terms you've chosen (Peers and Clients) seem to be as good as any >>>for this purpose. >>> >>>With that said, there are three basic designs: >>> >>> >>> >>>1. Clients understand the overlay network, they just don't >>> store data. To take a concrete example from Chord, there's >>> no reason you can't connect to a Chord node, suck down an >>> appropriate finger/routing table and then send messages >>> to other Chord nodes just as if you were a Peer. The >>> only thing you don't do is *register* with the network. >>> >>> >>> >>> >>> >>I guess you mean 'joining the overlay network' by 'register with the >>network'. >> >> > >I mean that you don't take on a section of the data space or >agree to route packets. > > > > I guess you mean 'registering with the network means that it takes on a section of the data space or agree to route packets'. And you mean Clients don't do that. >>Then, this design does not conflict with the concept presented in the draft. >>I don't know about other authors but at least I did not think of this >>design. >>I think this design is possible but the Clients do not need to >>understand the overlay algorithm or the routing tables. >> >> > >Sorry? In this design they *do* need to understand the overlay >algorithm. But that's not necessarily a bug. For instance, >it's likely to have superior load spreading properties, since >you don't need to find some way to load balance over the >Peers who are willing to talk to Clients. > > > I guess my comment was confusing. I mean Clients do not need to understand the overlay network according to the concept draft (or the design I had). In design #1, yes, Clients *do* need to do so. > > >>>2. Clients don't understand the overlay network, they just >>> treat some subset of peers as servers to which they can >>> do gets/puts. This is roughly the architecture that OpenDHT >>> implements now. >>> >>> >>> >>> >>> >>This is precisely what was assumed at least in my mind. >> >> >> >>>3. Clients don't understand the overlay network and just treat >>> it as one big clustered SIP server. >>> >>> >>> >>> >>> >>To be more precise, one can consider the overlay network as a big >>clustered LOCATION SERVER and STORAGE but not SIP proxy, SIP registrar >>or SIP redirect server. In that sense, it seems to me that design #3 is >>just a different expression of design #2. >> >> > >Topologically, yes, but not necessarily in other ways. For starters, >it begins to imply that you have to do a whole bunch of SIP things >that are potentially more complicated than just store and retrieve >data. > > > > I am not sure I understand your comment. Do you mean that the overlay network should provide a bunch of things SIP Proxy, Registrar, and/or SIP redirect server do? Or do you mean such implication is bad or wrong? >>>I think the intention here is for this document to be agnostic between >>>these three designs (and if it's not, it should be) but I don't think >>>it does that that well in a number of cases. >>> >>> >>> >>I thought the design #2 was clear and good enough. Other designs are >>also valid views but wouldn't it make the concept more clear if we focus >>on and stick with design #2? >> >> > >Well, no, because it tends to lock design (1) out of the discussion, >and since it's not like any actual conclusion has been reached >on that point, it's premature. > > > Do you think it is important to consider design #1 in addition to design #2? Personally I don't see much benefit in letting/requiring Clients understand the overlay network. Could you elaborate why it should be considered? BTW, in deployments, the software package will typically contain both the Peer Protocol stack and the Client Protocol stack so that a physical node may become a Client or a Peer depending on its network environment. So whether to be a Peer or Client just depends on what role a particular physical node decides to play at a particular moment in typical cases. In this sense, it is true that even a Client node may actually have the capability to understand the overlay network. But I am not sure whether we should consider it in the architecture description. Thanks. Eunsoo From spencer at mcsr-labs.org Mon Oct 30 22:48:38 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 30 Oct 2006 21:48:38 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 References: <20061031015443.7CEB45C01E@laser.networkresonance.com><02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com> <868xix41uj.fsf@raman.networkresonance.com> Message-ID: <000201c6fca5$bd803fe0$0a07be48@china.huawei.com> Hi, Eric, From: "Eric Rescorla" > "Spencer Dawkins" writes: >> Could you say more about "and if it's not, it should be"? Is this a >> question >> about whether we would find each design useful in at least one P2PSIP use >> case, or are you saying we should allow for all three designs because >> they >> cover the waterfront on possible designs? > > I'm saying that it's premature to decide on a single architecture, > at this time and in each document. That's a topic to be decided > *after* the WG is formed. I got this, and it was even clearer in your note to Eunsoo > Well, no, because it tends to lock design (1) out of the discussion, > and since it's not like any actual conclusion has been reached > on that point, it's premature. Thanks for explaining what you were thinking. >>> DETAILED COMMENTS >>> >>> S 3.5.2. >>> P2PSIP Peers directly interact with and contain the routing and >>> storage fabric of the overlay. P2PSIP Clients simply use the routing >>> and storage facilities provided by the peers to get and put >>> information. The peers speak the P2PSIP Peer Protocol, which can >>> express all the necessary routing and storage operations required for >>> the overlay. Clients speak the P2PSIP Client protocol, which is >>> presumably a subset of the peer protocol, and is limited to storage >>> insertion (put) and storage retrieval (get). Some designs do not >>> require a separate client protocol. >>> >>> If it's SIP, I don't see how it's a subset of the peer protocol. >> >> I asked the same question earlier, and the answer at the time was that >> "subset" was talking about protocol functionality, not about a protocol >> specification that subsets another protocol specification. > > Maybe some editorial work is in order here, then :) "some *more* editorial work", of course. Thanks to all of the editors so far :-) >>> S 4.5. >>> >>> When forwarding requests, are the bodies of the requests visible to >>> peers? If so, this creates substantial security problems that the >>> deployers of conventional SIP have been willing to mostly ignore. >>> Can we make peers cryptotransparent (like HTTP proxies) when security >>> is requested? >>> >>> I don't think I understand what "cryptotransparent" means, and since >>> HTTP proxies operate in a bunch of different modes, some quite >>> transparent >>> and some quite invasive. Maybe just rename this to "security of >>> requests" >>> and remove the last sentence? >> >> What was the question we were asking here? I don't think the third >> alternative is interesting, but can imagine that the others might be. The >> text seems to be talking specifically about request BODIES, and Eric is >> interpreting this as "security of requests", which seems broader. > > Until we know what format requests are in, I'm not sure how we know > what are bodies and what aren't. I.e., are we just talking > about the SIP messages or about the P2PSIP Peer Protocol, which > we don't even know has bodies.... So, if I got your suggestion for the text, it would now look like 4.5. Security of Requests When forwarding requests, are the requests themselves visible to peers? If so, this creates substantial security problems that the deployers of conventional SIP have been willing to mostly ignore. This is still not QUITE working for me, for a couple of reasons... - are we talking about more than confidentiality here? I didn't think so in the original text, but am now wondering if Eric could be talking about more than confidentiality in his comments. - I take Eric's point about "don't even know has bodies", but I'm having a hard time thinking that we don't have at least two choices - peers can say "oh, look, a request", or peers can say "oh, look, a request from EKR to Spencer". Which one are we worried about in 4.5? Again, thanks for the comments and feedback - especially before the BOF. Spencer From spencer at mcsr-labs.org Tue Oct 31 00:48:05 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 30 Oct 2006 23:48:05 -0600 Subject: [p2p-sip] Version -03 of Concepts draft submitted References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com><20061030214321.GE360@sbrim-wxp01> <45468634.8070008@research.panasonic.com> Message-ID: <00b201c6fcb0$23135130$0a07be48@china.huawei.com> Hi, Scott, >>Would the P2PSIP component need to have any idea what was using it? >> >> > I guess you mean P2PSIP Peer and Client by 'P2PSIP component'. > Then my answer is 'NO'. > No matter what is using it, the P2PSIP Peer or Client module/component > will provide the same functionality. I understood the possible "using" relationships to include whether a P2PSIP Peer can tell if it is being used by another P2PSIP Peer, or by a P2PSIP Client. Is that part of the question? Thanks, Spencer From ekr at networkresonance.com Tue Oct 31 00:57:45 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Mon, 30 Oct 2006 21:57:45 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <4546CD0E.4000000@research.panasonic.com> (Eunsoo Shim's message of "Mon, 30 Oct 2006 23:11:58 -0500") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <4546BAB6.2020606@research.panasonic.com> <86odrt420v.fsf@raman.networkresonance.com> <4546CD0E.4000000@research.panasonic.com> Message-ID: <86psc92fja.fsf@raman.networkresonance.com> Eunsoo Shim writes: > Eric Rescorla wrote: > I guess my comment was confusing. > I mean Clients do not need to understand the overlay network according > to the concept draft (or the design I had). In design #1, yes, Clients > *do* need to do so. Yes, that's correct. >>Topologically, yes, but not necessarily in other ways. For starters, >>it begins to imply that you have to do a whole bunch of SIP things >>that are potentially more complicated than just store and retrieve >>data. >> >> >> >> > I am not sure I understand your comment. > Do you mean that the overlay network should provide a bunch of things > SIP Proxy, Registrar, and/or SIP redirect server do? > Or do you mean such implication is bad or wrong? I mean that being a SIP *anything* is more complicated than just storing and retrieving opaque data blobs. >>Well, no, because it tends to lock design (1) out of the discussion, >>and since it's not like any actual conclusion has been reached >>on that point, it's premature. >> >> >> > Do you think it is important to consider design #1 in addition to design #2? Yes. > Personally I don't see much benefit in letting/requiring Clients > understand the overlay network. Could you elaborate why it should be > considered? A number of reasons: 1. It lets you use a generic overlay network rather than one that's tied to P2PSIP. 2. It automatically load shares across all the Peers in the overlay without any additional load balancing. 3. It's architecturally cleaner. -Ekr From ekr at networkresonance.com Tue Oct 31 01:00:26 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Mon, 30 Oct 2006 22:00:26 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <000201c6fca5$bd803fe0$0a07be48@china.huawei.com> (Spencer Dawkins's message of "Mon, 30 Oct 2006 21:48:38 -0600") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com> <868xix41uj.fsf@raman.networkresonance.com> <000201c6fca5$bd803fe0$0a07be48@china.huawei.com> Message-ID: <86hcxl2fet.fsf@raman.networkresonance.com> "Spencer Dawkins" writes: > 4.5. Security of Requests > > When forwarding requests, are the requests themselves visible to > peers? If so, this creates substantial security problems that the > deployers of conventional SIP have been willing to mostly ignore. > > This is still not QUITE working for me, for a couple of reasons... > > - are we talking about more than confidentiality here? I didn't think so in > the original text, but am now wondering if Eric could be talking about more > than confidentiality in his comments. Definitely. Indeed, message integrity may be more important in many cases. -Ekr From spencer at mcsr-labs.org Tue Oct 31 01:09:08 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 31 Oct 2006 00:09:08 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 References: <20061031015443.7CEB45C01E@laser.networkresonance.com><02da01c6fc98$eb972ea0$6901a8c0@china.huawei.com><868xix41uj.fsf@raman.networkresonance.com><000201c6fca5$bd803fe0$0a07be48@china.huawei.com> <86hcxl2fet.fsf@raman.networkresonance.com> Message-ID: <00e401c6fcb3$144c2d40$0a07be48@china.huawei.com> Hi, Eric, >> 4.5. Security of Requests >> >> When forwarding requests, are the requests themselves visible to >> peers? If so, this creates substantial security problems that the >> deployers of conventional SIP have been willing to mostly ignore. >> >> This is still not QUITE working for me, for a couple of reasons... >> >> - are we talking about more than confidentiality here? I didn't think so >> in >> the original text, but am now wondering if Eric could be talking about >> more >> than confidentiality in his comments. > > Definitely. Indeed, message integrity may be more important in many > cases. So then, something like 4.5. Security of Requests When forwarding requests, are the requests themselves visible to peers? Is messaging integrity protected? Decisions in this area might create substantial security problems that the deployers of conventional SIP have been willing to mostly ignore. ? Thanks, Spencer From hu.xinyu at huawei.com Tue Oct 31 01:44:26 2006 From: hu.xinyu at huawei.com (Seaward Hu) Date: Tue, 31 Oct 2006 14:44:26 +0800 Subject: [p2p-sip] draft-baset-sipping-p2pcommon-00 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22141286@namail5.corp.adobe.com> Message-ID: <000401c6fcb8$026eddc0$1a05a40a@china.huawei.com> I agree that we should take the PNS (proximity neighbor selection) into consideration, for it can be a basis to select proximity resource in a large-scale network. May be it can be a optional requirement in peer or client protocol, but shouldn't be excluded. In most cases, it will change the steps of enrollment and follows. Thanks. Seaward >-----Original Message----- >From: p2p-sip-bounces at cs.columbia.edu >[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich >Sent: Tuesday, October 31, 2006 2:46 AM >To: sipping at ietf.org >Cc: P2P-SIP >Subject: Re: [p2p-sip] draft-baset-sipping-p2pcommon-00 > >The proposed DHT protocol in "A Protocol for Implementing >Various DHT Algorithms" does not have a corresponding DHT >operation (API) for handling delay information. Should delay >not be the most important metric for neighbor node selection, >used among other for selecting media relays and proxies? > >Related to this, the Internet-Draft does not include the >Bamboo algorithm used in the openDHT system; >http://www.bamboo-dht.org/ Bamboo seems however to be the most >interesting algorithm, among other reasons since it has >proximity neighbor selection based on delay and has been >designed for better handling churn in membership. > >Is there a reason for not including Bamboo in the DHT >algorithm comparison and if so, what may it be? > >I understand though that other DHT algorithms such as Chord >have also recently added proximity neighbor selection based on >delay. Is this true? >If yes, the info in the draft should be updated. > >Thanks, > >Henry Sinnreich > > > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From dean.willis at softarmor.com Tue Oct 31 02:13:06 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 01:13:06 -0600 Subject: [p2p-sip] Version -03 of Concepts draft submitted In-Reply-To: <20061030214321.GE360@sbrim-wxp01> References: <000001c6fc03$1fdfa610$7205a40a@china.huawei.com> <38A1130D-55E2-41BF-953F-DE4F3B6FC9A1@magma.ca> <6AE7CF46-8C4F-46DB-8D66-8A02B4ED1479@softarmor.com> <20061030214321.GE360@sbrim-wxp01> Message-ID: On Oct 30, 2006, at 3:43 PM, Scott W Brim wrote: > Excerpts from Dean Willis on Mon, Oct 30, 2006 11:23:39AM -0600: >> I'd go so far as to say we could couple either a P2PSIP "peer >> function" or a P2PSIP "client function" with one or more SIP >> functions (UA, proxy, redirector, registrar, SBC, whatever). >> >> If you couple a P2PSIP peer or client with a SIP UA, you might get a >> "phone". >> >> If you couple a P2PSIP peer or client to a SIP proxy and a SIP >> registrar, you might get a SIP to P2PSIP adaptation server that would >> look like a "home proxy" to a SIP UA. >> >> If you couple a P2PSIP peer or client to a SIP SBC, you might get a >> SIP SBC with a P2PSIP backend. > > Would the P2PSIP component need to have any idea what was using it? > Nope. -- Dean From dean.willis at softarmor.com Tue Oct 31 02:31:25 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 01:31:25 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <20061031015443.7CEB45C01E@laser.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> Message-ID: <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: > $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 > 20:44:54 ekr Exp $ > > GENERAL COMMENTS > Overall, this document is pretty good, however I think the bit about > the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of > confusing. > > I definitely agree that there will be two kinds of nodes > > - Those which store other people's state data. > - Those which don't. > > The terms you've chosen (Peers and Clients) seem to be as good as any > for this purpose. > > With that said, there are three basic designs: > > 1. Clients understand the overlay network, they just don't > store data. To take a concrete example from Chord, there's > no reason you can't connect to a Chord node, suck down an > appropriate finger/routing table and then send messages > to other Chord nodes just as if you were a Peer. The > only thing you don't do is *register* with the network. > Actually, I was originally trying to avoid design #1. > 2. Clients don't understand the overlay network, they just > treat some subset of peers as servers to which they can > do gets/puts. This is roughly the architecture that OpenDHT > implements now. > > 3. Clients don't understand the overlay network and just treat > it as one big clustered SIP server. > For clarity, the above design #3 doesn't have "clients" as per the current definition. It just has peers and conventional client-server SIP nodes. > I think the intention here is for this document to be agnostic between > these three designs (and if it's not, it should be) but I don't think > it does that that well in a number of cases. In particular, > the question of whether the client protocol should be SIP sort > of confuses two questions: the fundamental architectural issue > above with the detail of wire encoding. > Indeed it does. In later discussion, David and I reached an understanding that if the client protocol is really vanilla SIP, then we have neither a clinet protocol nor clients according to the current definition, and that's OK. So this question "is the client protocol SIP" is misleading. The question should be "Does the architecture have client nodes or not?" > DETAILED COMMENTS > S 2. > P2PSIP Client: A node participating in a P2PSIP Overlay that > provides neither routing nor route storage and retrieval > functions > to that P2PSIP Overlay. The P2PSIP Client interacts with the > P2PSIP Overlay by having an association (details TBD) with > one or > more P2PSIP peers. > > This wouldn't be that accurate a description of case (1) above, since > there isn't an association with any peers. You just have a routing > table and contact whoever is appropriate. > > Right, I had design #2 in-mind when writing this definition. > P2PSIP Resource-ID: A non-human friendly value that uniquely > determines which P2PSIP Peer is responsible for storing > information about this resource (user). > > Well, "uniquely" isn't right here since most such schemes replicate > for high availability. Good point. Should be "that determines which P2PSIP peer or peers are responsible / / / > > P2PSIP Client Protocol: The protocol spoken between P2PSIP > Clients > and the P2PSIP Peer they use to store or retrieve information > from > the P2P Overlay. > > Who says there's just one? See above. > I don't understand this comment. > > is expected to be a principle topic of the detailed design work. > > s/principle/principal/ > Yes. > S 3.5.2. > P2PSIP Peers directly interact with and contain the routing and > storage fabric of the overlay. P2PSIP Clients simply use the > routing > and storage facilities provided by the peers to get and put > information. The peers speak the P2PSIP Peer Protocol, which can > express all the necessary routing and storage operations > required for > the overlay. Clients speak the P2PSIP Client protocol, which is > presumably a subset of the peer protocol, and is limited to storage > insertion (put) and storage retrieval (get). Some designs do not > require a separate client protocol. > > If it's SIP, I don't see how it's a subset of the peer protocol. > Right you are. SIP is not a client protocol candidate by the current definition. It is an alternative to client protocol. > S 3.5.3. > To get started, users must be enrolled in the overlay. We do not > have a process or protocol for this, nor are we certain we need a > standardized mechanism. We presume that after enrollment, the user > has a distinguished name within the overlay (example: > > Don't use "distinguished name" here. It's a technical term from > PKIX and it doesn't mean this. "unique name"? Actually, "distinguished name" is a technical term from directory services work that predates PKIX, and AFAIK, the usage in this doc is correct. See: http://www.jguru.com/faq/view.jsp?EID=17639 or X.500 I believe the usage of DN in PKIX comes through X.509's inclusion of X.500 terminology. Of course, DN also occurs in LDAP. > > S 4.5. > > When forwarding requests, are the bodies of the requests visible to > peers? If so, this creates substantial security problems that the > deployers of conventional SIP have been willing to mostly ignore. > Can we make peers cryptotransparent (like HTTP proxies) when > security > is requested? > > I don't think I understand what "cryptotransparent" means, and since > HTTP proxies operate in a bunch of different modes, some quite > transparent > and some quite invasive. Maybe just rename this to "security of > requests" > and remove the last sentence? > Actually, it's intended to mean "like HTTPS proxies", as discussed in draft-gurbani-sip-sipsec-00.txt: RFC 2817 [11], on the other hand, secures HTTP in a manner that is much more amenable to how SIP operates today with intermediaries aiding in routing the request. In HTTP, cryptotransparency across intermediaries is obtained by upgrading a normal TCP connection from browser to origin server through proxies to use TLS once a tunnel is set up. After the the tunnel is established, an upgrade is requested and the X.509 certificates are exchanged and ciphers negotiated directly between the browser and the origin server. In the P2P model it's fairly important that the peers being transited NOT participate in the cryptography, since they can be expected to be hostile. -- Dean From hsinnrei at adobe.com Tue Oct 31 08:47:46 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Tue, 31 Oct 2006 05:47:46 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <20061031015443.7CEB45C01E@laser.networkresonance.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141291@namail5.corp.adobe.com> I would like to join Eric's comments (excellent paper!) and add that besides the types of nodes, there are also to type of interfaces to define: - the data interface, - the service interface. http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt The service interface is especially critical for using external overlays, such as the openDHT. Sorry for not proposing a complete wording to this effect, but the paper should consider adding these concepts. Maybe these extracts are a useful reminder and the detailed XML examples are given in the reference. -------- 5.1. Data Model In this model the DHT is used as a shared data storage and the P2P- SIP operations are performed by the user by directly updating the corresponding DHT data. For example, a user stores his contact information and a caller stores the offline messages in the DHT. Similarly a P2P proxy updates the data in the DHT on behalf of the user to provide transparent SIP service to non-P2P users. There are several limitations to this approach. For example, presence composition or programmable call routing are not easy to implement. Moreover, we need service discovery for STUN and TURN servers anyway. An alternative service model solves this problem as described below. 5.2. Service Model In this model, every P2P-SIP client or proxy, joins the DHT for the p2p-sip service namespace. The p2p-sip service includes SIP registrar, presence agent, offline message storage, and STUN and TURN servers at the minimum. When a user, Alice, wants to send a SIP message to, say sip:bob at example.net, she looks up the DHT to find the service node responsible for this user identifier, and sends the SIP request to that node. The service node acts as the proxy, registrar and presence server for all the users for which it is responsible. The service node also does any safe programmable call handling scripts and presence composition. For signed or encrypted data such as contact information, there are two approaches: either the user sends the signed contacts in the SIP message or the user authorizes the service node to sign the contacts on his behalf. The first approach requires changes in existing SIP clients, whereas the second approach just uses a chain of certificates for verification of signed contacts. The service model is more extensible than the data model. A P2P-SIP service node readily interworks with any non-P2P clients who just happen to know one or more service node addresses. The service mode readily extends to built-in DHT architecture since only the service interface (join and lookup) is used in the DHT, instead of the data interface (get and put) by the user agent. Typically, the data interface can be built on top of the service interface. Note however that the ReDiR interface of OpenDHT [Rhea0510:opendht], which is a service interface, is in fact built on top of the data interface and resides purely on the client side. Authors: Are you amenable to add text to this effect? ------ Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eric Rescorla Sent: Monday, October 30, 2006 7:52 PM To: p2p-sip at cs.columbia.edu Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $ GENERAL COMMENTS Overall, this document is pretty good, however I think the bit about the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of confusing. I definitely agree that there will be two kinds of nodes - Those which store other people's state data. - Those which don't. The terms you've chosen (Peers and Clients) seem to be as good as any for this purpose. With that said, there are three basic designs: 1. Clients understand the overlay network, they just don't store data. To take a concrete example from Chord, there's no reason you can't connect to a Chord node, suck down an appropriate finger/routing table and then send messages to other Chord nodes just as if you were a Peer. The only thing you don't do is *register* with the network. 2. Clients don't understand the overlay network, they just treat some subset of peers as servers to which they can do gets/puts. This is roughly the architecture that OpenDHT implements now. 3. Clients don't understand the overlay network and just treat it as one big clustered SIP server. I think the intention here is for this document to be agnostic between these three designs (and if it's not, it should be) but I don't think it does that that well in a number of cases. In particular, the question of whether the client protocol should be SIP sort of confuses two questions: the fundamental architectural issue above with the detail of wire encoding. DETAILED COMMENTS S 2. P2PSIP Client: A node participating in a P2PSIP Overlay that provides neither routing nor route storage and retrieval functions to that P2PSIP Overlay. The P2PSIP Client interacts with the P2PSIP Overlay by having an association (details TBD) with one or more P2PSIP peers. This wouldn't be that accurate a description of case (1) above, since there isn't an association with any peers. You just have a routing table and contact whoever is appropriate. P2PSIP Resource-ID: A non-human friendly value that uniquely determines which P2PSIP Peer is responsible for storing information about this resource (user). Well, "uniquely" isn't right here since most such schemes replicate for high availability. P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients and the P2PSIP Peer they use to store or retrieve information from the P2P Overlay. Who says there's just one? See above. is expected to be a principle topic of the detailed design work. s/principle/principal/ S 3.5.2. P2PSIP Peers directly interact with and contain the routing and storage fabric of the overlay. P2PSIP Clients simply use the routing and storage facilities provided by the peers to get and put information. The peers speak the P2PSIP Peer Protocol, which can express all the necessary routing and storage operations required for the overlay. Clients speak the P2PSIP Client protocol, which is presumably a subset of the peer protocol, and is limited to storage insertion (put) and storage retrieval (get). Some designs do not require a separate client protocol. If it's SIP, I don't see how it's a subset of the peer protocol. S 3.5.3. To get started, users must be enrolled in the overlay. We do not have a process or protocol for this, nor are we certain we need a standardized mechanism. We presume that after enrollment, the user has a distinguished name within the overlay (example: Don't use "distinguished name" here. It's a technical term from PKIX and it doesn't mean this. "unique name"? S 4.5. When forwarding requests, are the bodies of the requests visible to peers? If so, this creates substantial security problems that the deployers of conventional SIP have been willing to mostly ignore. Can we make peers cryptotransparent (like HTTP proxies) when security is requested? I don't think I understand what "cryptotransparent" means, and since HTTP proxies operate in a bunch of different modes, some quite transparent and some quite invasive. Maybe just rename this to "security of requests" and remove the last sentence? -Ekr _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From ekr at networkresonance.com Tue Oct 31 09:47:43 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Tue, 31 Oct 2006 06:47:43 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> (Dean Willis's message of "Tue, 31 Oct 2006 01:31:25 -0600") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> Message-ID: <868xiw35kg.fsf@raman.networkresonance.com> Dean Willis writes: > On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: >> 1. Clients understand the overlay network, they just don't >> store data. To take a concrete example from Chord, there's >> no reason you can't connect to a Chord node, suck down an >> appropriate finger/routing table and then send messages >> to other Chord nodes just as if you were a Peer. The >> only thing you don't do is *register* with the network. >> > > Actually, I was originally trying to avoid design #1. Well, as I said, that's premature, since there's been no adequate WG (or even pre-WG) discussion of the merits of the various designs. Let's not nitpick about details of the rest of this document just yet. My interest is in having the WG make the right architectural decision (whatever that is) and in order for that to happen we need not to have a set of founding documents that precludes one major architectural choice without first having an adequate architectural discussion. Do you disagree with this? >> 2. Clients don't understand the overlay network, they just >> treat some subset of peers as servers to which they can >> do gets/puts. This is roughly the architecture that OpenDHT >> implements now. >> >> 3. Clients don't understand the overlay network and just treat >> it as one big clustered SIP server. >> > > For clarity, the above design #3 doesn't have "clients" as per the > current definition. It just has peers and conventional client-server > SIP nodes. Exactly. That's why 2 and 3 are architecturally very different even though topologically the same. >> P2PSIP Resource-ID: A non-human friendly value that uniquely >> determines which P2PSIP Peer is responsible for storing >> information about this resource (user). >> >> Well, "uniquely" isn't right here since most such schemes replicate >> for high availability. > > Good point. Should be "that determines which P2PSIP peer or peers are > responsible / / / >> >> P2PSIP Client Protocol: The protocol spoken between P2PSIP >> Clients >> and the P2PSIP Peer they use to store or retrieve information >> from >> the P2P Overlay. >> >> Who says there's just one? See above. >> > > I don't understand this comment. There are a number of cases in which you'd talk to multiple Peers to store and retrieve information. One of which would be design 1. Another is if you open connections to two Peers for high availability. > >> S 3.5.3. >> To get started, users must be enrolled in the overlay. We do not >> have a process or protocol for this, nor are we certain we need a >> standardized mechanism. We presume that after enrollment, the user >> has a distinguished name within the overlay (example: >> >> Don't use "distinguished name" here. It's a technical term from >> PKIX and it doesn't mean this. "unique name"? > > Actually, "distinguished name" is a technical term from directory > services work that predates PKIX, Yes, it's from X.500. But since X.500 is basically dead and PKIX is basically alive, I figured I'd be kind and not point all the way back. > and AFAIK, the usage in this doc is > correct. Your distinguished names are going to be tree-based name structures with elements like C, O, OU and CN encoded in ASN.1? >> S 4.5. >> >> When forwarding requests, are the bodies of the requests visible to >> peers? If so, this creates substantial security problems that the >> deployers of conventional SIP have been willing to mostly ignore. >> Can we make peers cryptotransparent (like HTTP proxies) when >> security >> is requested? >> >> I don't think I understand what "cryptotransparent" means, and since >> HTTP proxies operate in a bunch of different modes, some quite >> transparent >> and some quite invasive. Maybe just rename this to "security of >> requests" >> and remove the last sentence? >> > > Actually, it's intended to mean "like HTTPS proxies", as discussed in > draft-gurbani-sip-sipsec-00.txt: > > RFC 2817 [11], on the other hand, secures HTTP in a manner that is > much more amenable to how SIP operates today with intermediaries > aiding in routing the request. In HTTP, cryptotransparency across > intermediaries is obtained by upgrading a normal TCP connection from > browser to origin server through proxies to use TLS once a tunnel is > set up. After the the tunnel is established, an upgrade is > requested > and the X.509 certificates are exchanged and ciphers negotiated > directly between the browser and the origin server. > > In the P2P model it's fairly important that the peers being transited > NOT participate in the cryptography, since they can be expected to be > hostile. In *which* cryptography and for which purpose? I don't think you've defined the usage or threat model anywhere near enough to make this kind of assertion. -Ekr From dean.willis at softarmor.com Tue Oct 31 11:15:02 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 10:15:02 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22141291@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22141291@namail5.corp.adobe.com> Message-ID: <24542CDD-49AE-4CFC-9804-7910BB6C4BE9@softarmor.com> On Oct 31, 2006, at 7:47 AM, Henry Sinnreich wrote: > -------- > > 5.1. Data Model > > In this model the DHT is used as a shared data storage and the P2P- > SIP operations are performed by the user by directly updating the > corresponding DHT data. For example, a user stores his contact > information and a caller stores the offline messages in the DHT. > Similarly a P2P proxy updates the data in the DHT on behalf of the > user to provide transparent SIP service to non-P2P users. > > There are several limitations to this approach. For example, > presence composition or programmable call routing are not easy to > implement. Moreover, we need service discovery for STUN and TURN > servers anyway. An alternative service model solves this > problem as > described below. > > 5.2. Service Model > > In this model, every P2P-SIP client or proxy, joins the DHT for the > p2p-sip service namespace. The p2p-sip service includes SIP > registrar, presence agent, offline message storage, and STUN and > TURN > servers at the minimum. > Henry has actually given a reasonably good description of the difference between "clients" and "peers" as described in the current document. Peers participate in the overlay via the "service model" above. Clients participate via the "data model". A given realization might or might not have clients. It might have peers that use a new protocol, or it might have peers that do something like run OpenDHT. We could do something as small as declare that OpenDHT provides the peers and define a simple XML-RPC for the client protocol. -- Dean From dean.willis at softarmor.com Tue Oct 31 11:36:33 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 10:36:33 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <868xiw35kg.fsf@raman.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> Message-ID: <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> On Oct 31, 2006, at 8:47 AM, Eric Rescorla wrote: > Dean Willis writes: >> On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: >>> 1. Clients understand the overlay network, they just don't >>> store data. To take a concrete example from Chord, there's >>> no reason you can't connect to a Chord node, suck down an >>> appropriate finger/routing table and then send messages >>> to other Chord nodes just as if you were a Peer. The >>> only thing you don't do is *register* with the network. >>> >> >> Actually, I was originally trying to avoid design #1. > > Well, as I said, that's premature, since there's been > no adequate WG (or even pre-WG) discussion of the merits > of the various designs. > > Let's not nitpick about details of the rest of this document just > yet. My interest is in having the WG make the right architectural > decision (whatever that is) and in order for that to happen we need > not to have a set of founding documents that precludes one major > architectural choice without first having an adequate architectural > discussion. Do you disagree with this? I'm torn. I see your argument, but I'm hesitant to design vampire nodes (things that look like peers, but don't actually contribute resources) into the protocol. >>> P2PSIP Client Protocol: The protocol spoken between P2PSIP >>> Clients >>> and the P2PSIP Peer they use to store or retrieve information >>> from >>> the P2P Overlay. >>> >>> Who says there's just one? See above. >>> >> >> I don't understand this comment. > > There are a number of cases in which you'd talk to multiple Peers > to store and retrieve information. One of which would be design > 1. Another is if you open connections to two Peers for high > availability. > So you'd change the text to something like: P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients and the P2PSIP Peers they use to store or retrieve information from the P2P Overlay. >> >>> S 3.5.3. >>> To get started, users must be enrolled in the overlay. We do not >>> have a process or protocol for this, nor are we certain we need a >>> standardized mechanism. We presume that after enrollment, the >>> user >>> has a distinguished name within the overlay (example: >>> >>> Don't use "distinguished name" here. It's a technical term from >>> PKIX and it doesn't mean this. "unique name"? >> >> Actually, "distinguished name" is a technical term from directory >> services work that predates PKIX, > > Yes, it's from X.500. But since X.500 is basically dead and PKIX > is basically alive, I figured I'd be kind and not point all the > way back. > > >> and AFAIK, the usage in this doc is >> correct. > > Your distinguished names are going to be tree-based name structures > with elements like C, O, OU and CN encoded in ASN.1? > What's the format (aka ASN.1) got to do with anything? The thing that makes a name distinguished within a directory is that its credential association is unique: that is, every DN is unique within the directory. You might have several John Smiths, but they are DIFFERENT John Smiths. There are distinguishing components of the identity that differentiate where the common name does not. Certainly I envision it having parts that correspond to C and CN, whereas I suspect the O and OU may correspond to the overlay identifier. However, some models where we posit multiple "domain names" within a single overlay seem to require O and OU-like elements. >>> S 4.5. >>> >>> When forwarding requests, are the bodies of the requests >>> visible to >>> peers? If so, this creates substantial security problems that >>> the >>> deployers of conventional SIP have been willing to mostly ignore. >>> Can we make peers cryptotransparent (like HTTP proxies) when >>> security >>> is requested? >>> >>> I don't think I understand what "cryptotransparent" means, and since >>> HTTP proxies operate in a bunch of different modes, some quite >>> transparent >>> and some quite invasive. Maybe just rename this to "security of >>> requests" >>> and remove the last sentence? >>> >> >> Actually, it's intended to mean "like HTTPS proxies", as discussed in >> draft-gurbani-sip-sipsec-00.txt: >> >> RFC 2817 [11], on the other hand, secures HTTP in a manner >> that is >> much more amenable to how SIP operates today with intermediaries >> aiding in routing the request. In HTTP, cryptotransparency >> across >> intermediaries is obtained by upgrading a normal TCP >> connection from >> browser to origin server through proxies to use TLS once a >> tunnel is >> set up. After the the tunnel is established, an upgrade is >> requested >> and the X.509 certificates are exchanged and ciphers negotiated >> directly between the browser and the origin server. >> >> In the P2P model it's fairly important that the peers being transited >> NOT participate in the cryptography, since they can be expected to be >> hostile. > > In *which* cryptography and for which purpose? I don't think you've > defined the usage or threat model anywhere near enough to make > this kind of assertion. Ok, help us out here, because this is pretty fundamental. To me this means that nodes relaying messages between endpoints only see the cyphertext of those messages and do not possess the keys for those cyphertexts. This is unlike SIP's commonly-deployed proxy model, where the proxies are generally expected (and in practice, often required) to see the plaintext of the messages. Since most of the nodes in a P2P overlay are expected to be end-user controlled, one could reasonably believe that all of them are data-mining within the messages they relay. In practice, this means you can't have a P2PSIP peer node that also serves as a SIP proxy running on Joe User's home PC that acts as an "outbound proxy" for users other than Joe, unless we change the way the SIP proxy function works so that Joe can't see all the message contents. Today's proposals for doing this include S/MIME and HTTPS- style proxy tunneling (aka sipsec:). -- Dean From hsinnrei at adobe.com Tue Oct 31 12:19:08 2006 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Tue, 31 Oct 2006 09:19:08 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <24542CDD-49AE-4CFC-9804-7910BB6C4BE9@softarmor.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141298@namail5.corp.adobe.com> Thanks Dean for accepting to include terminology for the data model and the service model! BTW: The descriptions were copied from the paper http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt > define a simple XML-RPC for the client protocol Section 6 in the paper defines an XML schema definition that may be a useful starting point. Henry -----Original Message----- From: Dean Willis [mailto:dean.willis at softarmor.com] Sent: Tuesday, October 31, 2006 10:15 AM To: Henry Sinnreich Cc: Eric Rescorla; p2p-sip at cs.columbia.edu; Kundan Singh Subject: Re: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 On Oct 31, 2006, at 7:47 AM, Henry Sinnreich wrote: > -------- > > 5.1. Data Model > > In this model the DHT is used as a shared data storage and the P2P- > SIP operations are performed by the user by directly updating the > corresponding DHT data. For example, a user stores his contact > information and a caller stores the offline messages in the DHT. > Similarly a P2P proxy updates the data in the DHT on behalf of the > user to provide transparent SIP service to non-P2P users. > > There are several limitations to this approach. For example, > presence composition or programmable call routing are not easy to > implement. Moreover, we need service discovery for STUN and TURN > servers anyway. An alternative service model solves this > problem as > described below. > > 5.2. Service Model > > In this model, every P2P-SIP client or proxy, joins the DHT for the > p2p-sip service namespace. The p2p-sip service includes SIP > registrar, presence agent, offline message storage, and STUN and > TURN > servers at the minimum. > Henry has actually given a reasonably good description of the difference between "clients" and "peers" as described in the current document. Peers participate in the overlay via the "service model" above. Clients participate via the "data model". A given realization might or might not have clients. It might have peers that use a new protocol, or it might have peers that do something like run OpenDHT. We could do something as small as declare that OpenDHT provides the peers and define a simple XML-RPC for the client protocol. -- Dean From dean.willis at softarmor.com Tue Oct 31 12:25:17 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 11:25:17 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22141298@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22141298@namail5.corp.adobe.com> Message-ID: <87F84F5E-B7E4-4B42-B600-2C93AC32CCB0@softarmor.com> On Oct 31, 2006, at 11:19 AM, Henry Sinnreich wrote: > Thanks Dean for accepting to include terminology for the data model > and > the service model! > > BTW: The descriptions were copied from the paper > > http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt > >> define a simple XML-RPC for the client protocol > > Section 6 in the paper defines an XML schema definition that may be a > useful starting point. > Actually, I was more thinking that we should use the Singh definitions of service and data model to supplement the existing definitions of client and peer, rather than adding service and data model as terminology in their own right. -- Dean From ekr at networkresonance.com Tue Oct 31 13:19:06 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Tue, 31 Oct 2006 10:19:06 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> (Dean Willis's message of "Tue, 31 Oct 2006 10:36:33 -0600") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> Message-ID: <86lkmw1h7p.fsf@raman.networkresonance.com> Dean Willis writes: > On Oct 31, 2006, at 8:47 AM, Eric Rescorla wrote: > >> Dean Willis writes: >>> On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: >>>> 1. Clients understand the overlay network, they just don't >>>> store data. To take a concrete example from Chord, there's >>>> no reason you can't connect to a Chord node, suck down an >>>> appropriate finger/routing table and then send messages >>>> to other Chord nodes just as if you were a Peer. The >>>> only thing you don't do is *register* with the network. >>>> >>> >>> Actually, I was originally trying to avoid design #1. >> >> Well, as I said, that's premature, since there's been >> no adequate WG (or even pre-WG) discussion of the merits >> of the various designs. >> >> Let's not nitpick about details of the rest of this document just >> yet. My interest is in having the WG make the right architectural >> decision (whatever that is) and in order for that to happen we need >> not to have a set of founding documents that precludes one major >> architectural choice without first having an adequate architectural >> discussion. Do you disagree with this? > > I'm torn. I see your argument, but I'm hesitant to design vampire > nodes (things that look like peers, but don't actually contribute > resources) into the protocol. Huh? The basic design of all these protocols is that there are nodes (what you're calling Clients) who use the services of the Peers but don't contribute resources. This question is purely about how they interact with the Peers. > P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients > and the P2PSIP Peers they use to store or retrieve information from > the P2P Overlay. Sure. >>> and AFAIK, the usage in this doc is >>> correct. >> >> Your distinguished names are going to be tree-based name structures >> with elements like C, O, OU and CN encoded in ASN.1? >> > > What's the format (aka ASN.1) got to do with anything? > > The thing that makes a name distinguished within a directory is that > its credential association is unique: that is, every DN is unique > within the directory. You might have several John Smiths, but they > are DIFFERENT John Smiths. There are distinguishing components of the > identity that differentiate where the common name does not. Yes, that's what makes a name "distinguished". But a Distinguished Name is this: DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DEFINED BY AttributeType RDNSequence ::= SEQUENCE OF RelativeDistinguishedName And since you don't mean that you're going to use the construct from PKIX, it's super-confusing to use this term. >> In *which* cryptography and for which purpose? I don't think you've >> defined the usage or threat model anywhere near enough to make >> this kind of assertion. > > Ok, help us out here, because this is pretty fundamental. To me this > means that nodes relaying messages between endpoints only see the > cyphertext of those messages and do not possess the keys for those > cyphertexts. This is unlike SIP's commonly-deployed proxy model, > where the proxies are generally expected (and in practice, often > required) to see the plaintext of the messages. Since most of the > nodes in a P2P overlay are expected to be end-user controlled, one > could reasonably believe that all of them are data-mining within the > messages they relay. > > In practice, this means you can't have a P2PSIP peer node that also > serves as a SIP proxy running on Joe User's home PC that acts as an > "outbound proxy" for users other than Joe, unless we change the way > the SIP proxy function works so that Joe can't see all the message > contents. Today's proposals for doing this include S/MIME and HTTPS- > style proxy tunneling (aka sipsec:). Well, let's take a step back here and examine model (3), in which each Client speaks SIP to some Peer. 1. Client A does a REGISTER of name "Alice" to proxy P. Now, P doesn't control the section of the overlay corresponding to Alice so it stores Alice's contact info with the appropriate node. This is all done with the P2PSIP Peer Protocol. So, there's the issue of security for these messages. 2. Client B is associated with proxy Q and wants to call A. It sends an INVITE to Q (see S 3.4.3) which then forwards it to P and then on to A. So, there's the issue of security for these messages. And this all goes back to the threat model of what you think the trust relationships are between the various Peers in the overlay ring. -Ekr From philip_matthews at magma.ca Tue Oct 31 13:33:48 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 31 Oct 2006 13:33:48 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <20061031015443.7CEB45C01E@laser.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> Message-ID: On 30-Oct-06, at 20:51 , Eric Rescorla wrote: > $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 > 20:44:54 ekr Exp $ > > GENERAL COMMENTS > Overall, this document is pretty good, however I think the bit about > the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of > confusing. > > I definitely agree that there will be two kinds of nodes > > - Those which store other people's state data. > - Those which don't. > > The terms you've chosen (Peers and Clients) seem to be as good as any > for this purpose. > > With that said, there are three basic designs: > > 1. Clients understand the overlay network, they just don't > store data. To take a concrete example from Chord, there's > no reason you can't connect to a Chord node, suck down an > appropriate finger/routing table and then send messages > to other Chord nodes just as if you were a Peer. The > only thing you don't do is *register* with the network. > > 2. Clients don't understand the overlay network, they just > treat some subset of peers as servers to which they can > do gets/puts. This is roughly the architecture that OpenDHT > implements now. > > 3. Clients don't understand the overlay network and just treat > it as one big clustered SIP server. > > I think the intention here is for this document to be agnostic between > these three designs (and if it's not, it should be) but I don't think > it does that that well in a number of cases. In particular, > the question of whether the client protocol should be SIP sort > of confuses two questions: the fundamental architectural issue > above with the detail of wire encoding. > I agree that the document should be agnostic between these three designs. If we interprete #3 as being equivalent to "the client protocol is just SIP" then I think the document does an OK job of presenting #2 and #3. (Of course, it could be better ... ;-). However, #1 had never come up in our discussions, which is why it is not discussed in the document. - Philip From bryan at ethernot.org Tue Oct 31 14:45:45 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 31 Oct 2006 14:45:45 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <86lkmw1h7p.fsf@raman.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> Message-ID: <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> Inline... On 10/31/06, Eric Rescorla wrote: > Dean Willis writes: > > > On Oct 31, 2006, at 8:47 AM, Eric Rescorla wrote: > > > >> Dean Willis writes: > >>> On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: > >>>> 1. Clients understand the overlay network, they just don't > >>>> store data. To take a concrete example from Chord, there's > >>>> no reason you can't connect to a Chord node, suck down an > >>>> appropriate finger/routing table and then send messages > >>>> to other Chord nodes just as if you were a Peer. The > >>>> only thing you don't do is *register* with the network. > >>>> > >>> > >>> Actually, I was originally trying to avoid design #1. > >> > >> Well, as I said, that's premature, since there's been > >> no adequate WG (or even pre-WG) discussion of the merits > >> of the various designs. > >> > >> Let's not nitpick about details of the rest of this document just > >> yet. My interest is in having the WG make the right architectural > >> decision (whatever that is) and in order for that to happen we need > >> not to have a set of founding documents that precludes one major > >> architectural choice without first having an adequate architectural > >> discussion. Do you disagree with this? > > > > I'm torn. I see your argument, but I'm hesitant to design vampire > > nodes (things that look like peers, but don't actually contribute > > resources) into the protocol. > > Huh? The basic design of all these protocols is that there are > nodes (what you're calling Clients) who use the services of > the Peers but don't contribute resources. This question is > purely about how they interact with the Peers. So would a case where they client protocol is a (proper logical and syntactic, that is, you can't tell if a query is coming from another client or a peer) subset of the peer protocol, and a client just happened to know about many peers (and which is "closest" to send the search to) rather than a single one that services it, an example of a case 1? It seems that many optimizations of case 2 would start looking like 1 (which might be an ok or even good thing) --David > > P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients > > and the P2PSIP Peers they use to store or retrieve information from > > the P2P Overlay. > > Sure. > > > >>> and AFAIK, the usage in this doc is > >>> correct. > >> > >> Your distinguished names are going to be tree-based name structures > >> with elements like C, O, OU and CN encoded in ASN.1? > >> > > > > What's the format (aka ASN.1) got to do with anything? > > > > The thing that makes a name distinguished within a directory is that > > its credential association is unique: that is, every DN is unique > > within the directory. You might have several John Smiths, but they > > are DIFFERENT John Smiths. There are distinguishing components of the > > identity that differentiate where the common name does not. > > Yes, that's what makes a name "distinguished". But a Distinguished Name > is this: > > DistinguishedName ::= RDNSequence > > RelativeDistinguishedName ::= > SET OF AttributeTypeAndValue > > AttributeTypeAndValue ::= SEQUENCE { > type AttributeType, > value AttributeValue } > > AttributeType ::= OBJECT IDENTIFIER > > AttributeValue ::= ANY DEFINED BY AttributeType > > RDNSequence ::= SEQUENCE OF RelativeDistinguishedName > > And since you don't mean that you're going to use the construct > from PKIX, it's super-confusing to use this term. > > > >> In *which* cryptography and for which purpose? I don't think you've > >> defined the usage or threat model anywhere near enough to make > >> this kind of assertion. > > > > Ok, help us out here, because this is pretty fundamental. To me this > > means that nodes relaying messages between endpoints only see the > > cyphertext of those messages and do not possess the keys for those > > cyphertexts. This is unlike SIP's commonly-deployed proxy model, > > where the proxies are generally expected (and in practice, often > > required) to see the plaintext of the messages. Since most of the > > nodes in a P2P overlay are expected to be end-user controlled, one > > could reasonably believe that all of them are data-mining within the > > messages they relay. > > > > In practice, this means you can't have a P2PSIP peer node that also > > serves as a SIP proxy running on Joe User's home PC that acts as an > > "outbound proxy" for users other than Joe, unless we change the way > > the SIP proxy function works so that Joe can't see all the message > > contents. Today's proposals for doing this include S/MIME and HTTPS- > > style proxy tunneling (aka sipsec:). > > Well, let's take a step back here and examine model (3), in > which each Client speaks SIP to some Peer. > > 1. Client A does a REGISTER of name "Alice" to proxy P. Now, P > doesn't control the section of the overlay corresponding to > Alice so it stores Alice's contact info with the appropriate > node. This is all done with the P2PSIP Peer Protocol. > So, there's the issue of security for these messages. > > 2. Client B is associated with proxy Q and wants to call A. > It sends an INVITE to Q (see S 3.4.3) which then forwards > it to P and then on to A. So, there's the issue of > security for these messages. > > And this all goes back to the threat model of what you think > the trust relationships are between the various Peers in > the overlay ring. > > -Ekr > > > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From ekr at networkresonance.com Tue Oct 31 14:54:09 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Tue, 31 Oct 2006 11:54:09 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> (David A. Bryan's message of "Tue, 31 Oct 2006 14:45:45 -0500") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> Message-ID: <86lkmwz2fy.fsf@raman.networkresonance.com> "David A. Bryan" writes: > Inline... > > On 10/31/06, Eric Rescorla wrote: >> Dean Willis writes: >> >> > On Oct 31, 2006, at 8:47 AM, Eric Rescorla wrote: >> > >> >> Dean Willis writes: >> >>> On Oct 30, 2006, at 7:51 PM, Eric Rescorla wrote: >> >>>> 1. Clients understand the overlay network, they just don't >> >>>> store data. To take a concrete example from Chord, there's >> >>>> no reason you can't connect to a Chord node, suck down an >> >>>> appropriate finger/routing table and then send messages >> >>>> to other Chord nodes just as if you were a Peer. The >> >>>> only thing you don't do is *register* with the network. >> >>>> >> >>> >> >>> Actually, I was originally trying to avoid design #1. >> >> >> >> Well, as I said, that's premature, since there's been >> >> no adequate WG (or even pre-WG) discussion of the merits >> >> of the various designs. >> >> >> >> Let's not nitpick about details of the rest of this document just >> >> yet. My interest is in having the WG make the right architectural >> >> decision (whatever that is) and in order for that to happen we need >> >> not to have a set of founding documents that precludes one major >> >> architectural choice without first having an adequate architectural >> >> discussion. Do you disagree with this? >> > >> > I'm torn. I see your argument, but I'm hesitant to design vampire >> > nodes (things that look like peers, but don't actually contribute >> > resources) into the protocol. >> >> Huh? The basic design of all these protocols is that there are >> nodes (what you're calling Clients) who use the services of >> the Peers but don't contribute resources. This question is >> purely about how they interact with the Peers. > > So would a case where they client protocol is a (proper logical and > syntactic, that is, you can't tell if a query is coming from another > client or a peer) subset of the peer protocol, and a client just > happened to know about many peers (and which is "closest" to send the > search to) rather than a single one that services it, an example of a > case 1? > > It seems that many optimizations of case 2 would start looking like 1 > (which might be an ok or even good thing) Under some circumstances, perhaps, but it's not clear it goes the other way. I.e., I don't think it's the case with all DHTs that you can just talk to a single node and have it route arbitrary traffic to a node of your choice. It certainly doesn't have great performance properties. -Ekr From bryan at ethernot.org Tue Oct 31 15:17:16 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 31 Oct 2006 15:17:16 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <86lkmwz2fy.fsf@raman.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> <86lkmwz2fy.fsf@raman.networkresonance.com> Message-ID: <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> > > So would a case where they client protocol is a (proper logical and > > syntactic, that is, you can't tell if a query is coming from another > > client or a peer) subset of the peer protocol, and a client just > > happened to know about many peers (and which is "closest" to send the > > search to) rather than a single one that services it, an example of a > > case 1? > > > > It seems that many optimizations of case 2 would start looking like 1 > > (which might be an ok or even good thing) > > Under some circumstances, perhaps, but it's not clear it goes the > other way. I.e., I don't think it's the case with all DHTs that you > can just talk to a single node and have it route arbitrary traffic to > a node of your choice. It certainly doesn't have great performance > properties. I'm a bit confused about what you have in mind above, I think I am missing part of what you are getting at. I can't really see how using an arbitrary peer as a proxy for a client can result in the cost to the client being worse than the cost of messages originating from that peer itself+1 to communicate between client and peer...or am I missing a subtle point of your distinction? That said, obviously having more clients to choose from is better (and I see the many ways 1 is different than 2 in your email), but in many designs, very often the reason for being a client (rather than a peer) in the first place is NAT related, that is, it is difficult to have connections to many peers, so you let one serve on your behalf. (personally I think we can be more clever than that, but it is the motivation in many traditional P2P implementations that have both peers and clients) David From philip_matthews at magma.ca Tue Oct 31 14:55:38 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 31 Oct 2006 14:55:38 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> Message-ID: On 31-Oct-06, at 02:31 , Dean Willis wrote: >> S 3.5.2. >> P2PSIP Peers directly interact with and contain the routing and >> storage fabric of the overlay. P2PSIP Clients simply use the >> routing >> and storage facilities provided by the peers to get and put >> information. The peers speak the P2PSIP Peer Protocol, which can >> express all the necessary routing and storage operations >> required for >> the overlay. Clients speak the P2PSIP Client protocol, which is >> presumably a subset of the peer protocol, and is limited to >> storage >> insertion (put) and storage retrieval (get). Some designs do not >> require a separate client protocol. >> >> If it's SIP, I don't see how it's a subset of the peer protocol. >> > > Right you are. SIP is not a client protocol candidate by the current > definition. It is an alternative to client protocol. > Dean: I don't see why you say that SIP is an alternative to the client protocol. Say SIP is NOT the client protocol. Then I think we have both clients (that speak the client protocol) and SIP UAs (that speak SIP) that can connect to the P2PSIP Overlay. Presumably, clients could do more than ordinary SIP UAs. So if there is a client protocol, then I think it exists in addition to SIP. - Philip From dean.willis at softarmor.com Tue Oct 31 15:47:27 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 14:47:27 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> Message-ID: On Oct 31, 2006, at 1:55 PM, Philip Matthews wrote: > > On 31-Oct-06, at 02:31 , Dean Willis wrote: > >>> S 3.5.2. >>> P2PSIP Peers directly interact with and contain the routing and >>> storage fabric of the overlay. P2PSIP Clients simply use the >>> routing >>> and storage facilities provided by the peers to get and put >>> information. The peers speak the P2PSIP Peer Protocol, which can >>> express all the necessary routing and storage operations >>> required for >>> the overlay. Clients speak the P2PSIP Client protocol, which is >>> presumably a subset of the peer protocol, and is limited to >>> storage >>> insertion (put) and storage retrieval (get). Some designs do not >>> require a separate client protocol. >>> >>> If it's SIP, I don't see how it's a subset of the peer protocol. >>> >> >> Right you are. SIP is not a client protocol candidate by the current >> definition. It is an alternative to client protocol. >> > > Dean: > > I don't see why you say that SIP is an alternative to the client > protocol. > > Say SIP is NOT the client protocol. Then I think we have both > clients (that speak the client protocol) and SIP UAs (that speak SIP) > that can connect to the P2PSIP Overlay. Presumably, clients could > do more than ordinary SIP UAs. > Using SIP as David does is a design alternative to using a client protocol. If you use SIP that way, you don't need a client protocol, because you don't have any "clients" as defined in the draft. Therefore SIP (used that way) is an alternative to using a client protocol. > So if there is a client protocol, then I think it exists in > addition to SIP. Right, but you may well design a system that uses IP instead of using a client protocol. Or to reverse your words: So if there is no client protocol, then I think its existence was obviated by a usage of SIP. -- Dean From dean.willis at softarmor.com Tue Oct 31 15:50:31 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Oct 2006 14:50:31 -0600 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> <86lkmwz2fy.fsf@raman.networkresonance.com> <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> Message-ID: <4F21983F-69D1-4311-8D3F-492646181083@softarmor.com> On Oct 31, 2006, at 2:17 PM, David A. Bryan wrote: > > That said, obviously having more clients to choose from is better (and > I see the many ways 1 is different than 2 in your email), but in many > designs, very often the reason for being a client (rather than a peer) > in the first place is NAT related, that is, it is difficult to have > connections to many peers, so you let one serve on your behalf. > (personally I think we can be more clever than that, but it is the > motivation in many traditional P2P implementations that have both > peers and clients) I actually envision an "outbound peer" that has the same kind of relationship to a client (or to another peer) as an "outbound proxy" does to a UA. It acts as the NAT-traversal anchor for requests from outside the NAT to reach the peer or client behind a NAT. Of course, a robust design requires each behind-nat node to have multiple "outbound" relationships. That's why I talk about storing a set of route vectors into the overlay -- one route vector for each outbound relationship that is being maintained. -- Dean From ekr at networkresonance.com Tue Oct 31 15:53:30 2006 From: ekr at networkresonance.com (Eric Rescorla) Date: Tue, 31 Oct 2006 12:53:30 -0800 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> (David A. Bryan's message of "Tue, 31 Oct 2006 15:17:16 -0500") References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> <86lkmwz2fy.fsf@raman.networkresonance.com> <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> Message-ID: <86slh4xl4l.fsf@raman.networkresonance.com> "David A. Bryan" writes: >> > So would a case where they client protocol is a (proper logical and >> > syntactic, that is, you can't tell if a query is coming from another >> > client or a peer) subset of the peer protocol, and a client just >> > happened to know about many peers (and which is "closest" to send the >> > search to) rather than a single one that services it, an example of a >> > case 1? >> > >> > It seems that many optimizations of case 2 would start looking like 1 >> > (which might be an ok or even good thing) >> >> Under some circumstances, perhaps, but it's not clear it goes the >> other way. I.e., I don't think it's the case with all DHTs that you >> can just talk to a single node and have it route arbitrary traffic to >> a node of your choice. It certainly doesn't have great performance >> properties. > > I'm a bit confused about what you have in mind above, I think I am > missing part of what you are getting at. I can't really see how using > an arbitrary peer as a proxy for a client can result in the cost to > the client being worse than the cost of messages originating from that > peer itself+1 to communicate between client and peer...or am I missing > a subtle point of your distinction? The issue is the cost to the peer, which is suddenly in the middle of every communication. See previous comments about load sharing, etc., as well as potentially suboptimal routes. > That said, obviously having more clients to choose from is better (and > I see the many ways 1 is different than 2 in your email), but in many > designs, very often the reason for being a client (rather than a peer) > in the first place is NAT related, that is, it is difficult to have > connections to many peers, so you let one serve on your behalf. > (personally I think we can be more clever than that, but it is the > motivation in many traditional P2P implementations that have both > peers and clients) Now, I must be missng something here. You don't need connections tied up to everyone in your routing table. You create them on demand. Even if you feel like you have to cache them, we're only talking order 10 connections, and of course you can only partially populate the routing table. -Ekr From bryan at ethernot.org Tue Oct 31 16:02:49 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 31 Oct 2006 16:02:49 -0500 Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03 In-Reply-To: <86slh4xl4l.fsf@raman.networkresonance.com> References: <20061031015443.7CEB45C01E@laser.networkresonance.com> <6F914E17-0377-4F4A-B794-9DFF64E1A2BD@softarmor.com> <868xiw35kg.fsf@raman.networkresonance.com> <13F6728B-6CD3-4F23-BBD0-DB5E01067E53@softarmor.com> <86lkmw1h7p.fsf@raman.networkresonance.com> <8b2769930610311145w4089f2datac58a32384e8291c@mail.gmail.com> <86lkmwz2fy.fsf@raman.networkresonance.com> <8b2769930610311217h29bd1a37wb1c0f1566f271414@mail.gmail.com> <86slh4xl4l.fsf@raman.networkresonance.com> Message-ID: <8b2769930610311302u46648bafu841432a3acb6f38c@mail.gmail.com> On 10/31/06, Eric Rescorla wrote: > "David A. Bryan" writes: > > >> > So would a case where they client protocol is a (proper logical and > >> > syntactic, that is, you can't tell if a query is coming from another > >> > client or a peer) subset of the peer protocol, and a client just > >> > happened to know about many peers (and which is "closest" to send the > >> > search to) rather than a single one that services it, an example of a > >> > case 1? > >> > > >> > It seems that many optimizations of case 2 would start looking like 1 > >> > (which might be an ok or even good thing) > >> > >> Under some circumstances, perhaps, but it's not clear it goes the > >> other way. I.e., I don't think it's the case with all DHTs that you > >> can just talk to a single node and have it route arbitrary traffic to > >> a node of your choice. It certainly doesn't have great performance > >> properties. > > > > I'm a bit confused about what you have in mind above, I think I am > > missing part of what you are getting at. I can't really see how using > > an arbitrary peer as a proxy for a client can result in the cost to > > the client being worse than the cost of messages originating from that > > peer itself+1 to communicate between client and peer...or am I missing > > a subtle point of your distinction? > > The issue is the cost to the peer, which is suddenly in the > middle of every communication. See previous comments about > load sharing, etc., as well as potentially suboptimal > routes. Ok, fully agree there is more cost to the peer serving. Optimizing something else. Gotcha. > > That said, obviously having more clients to choose from is better (and > > I see the many ways 1 is different than 2 in your email), but in many > > designs, very often the reason for being a client (rather than a peer) > > in the first place is NAT related, that is, it is difficult to have > > connections to many peers, so you let one serve on your behalf. > > (personally I think we can be more clever than that, but it is the > > motivation in many traditional P2P implementations that have both > > peers and clients) > > Now, I must be missng something here. You don't need connections > tied up to everyone in your routing table. You create them on demand. > Even if you feel like you have to cache them, we're only talking > order 10 connections, and of course you can only partially populate > the routing table. Might be true in this case, now that I think about it, since these are going to be outbound only (since you aren't serving/storing information). (Obviously a peer behind a NAT may not be able to do the same, since it must accept incoming connections and would possibly need to keep the connections open) Of course the number of connections needed decision is very different for different DHT implementations and the size (total number of participants) for a DHT, but I agree for a client it can likely be a fairly small number. Think I understand your thoughts a bit better now... David > > -Ekr > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >